在 AWS 上用多智能体自愈式 SRE 方案实现故障自动解决
全球大型企业都希望尽量减少庞杂工作负载在站点可靠性工程（SRE）和运维上的投入，包括人力、时间和成本，从而把资源转向创新和生产力提升。Daimler Truck 是全球最大的商用汽车制造商之一，其 IT 售后团队与 AWS 合作伙伴 CGI 合作，借助 AWS 最新的 AI 能力，打造了一套新颖且有效的方案，能够自动诊断并修复问题。本文介绍 Amazon Bedrock AgentCore、AWS DevOps Agent 和 AWS Lambda 如何支撑起一套全自动方案：检测与 SRE 相关的错误、执行根因分析，并生成附带修复建议的拉取请求（PR）。系统在部署前设有一个人工审核环节，由人确认并批准。这套方案省去了耗时的调试和代码修复生成阶段，把故障解决时间缩短约 88%，原本需要 2 到 3 小时的工作，现在几分钟就能完成。这意味着支持团队的工作量有望减少 10% 到 20%，让工程团队从被动救火中解放出来，专注于更有价值的工作。同时，自动生成的拉取请求会带上完整的故障时间线，自然而然地改善了文档记录和审计准备。
挑战
Truck After Sales Portal（TASP!）是 Daimler Truck 的核心售后门户，服务于 Mercedes-Benz Truck 各市场。它提供一套构建在 AWS 之上的平台即服务（PaaS），上面运行着 36 个以上的应用，这些应用分布在 7 个 Amazon Elastic Kubernetes Service（Amazon EKS）集群中，各自使用独立的子账户和命名空间。全球有超过 13 万名用户访问 TASP!，覆盖售后运营的各个阶段；每天有 80 多名开发人员在这套门户的不同模块上工作。
在这种规模的运维下，配置或部署出错就可能引发服务中断。比如，开发者预估某个服务需要一定量的内存，但实际部署后服务消耗更多内存，最终导致内存不足（OOM）错误。错误出现后，监控和告警机制触发警报，SRE 开发者介入调查、定位根因、做小范围代码修复，再部署修复版本。整个过程很耗时，平均每起事故要花开发者 2-3 小时。
方案概览
团队希望有一套自动化方案，能对错误做根因分析（RCA）并交付代码改动，减少整个流程中的人工投入。他们用 AWS DevOps Agent 搭建了一套端到端、多智能体（multi-agent）的自愈 SRE 方案，可以检测、分析应用错误和缺陷，并准备好修复方案。所有修复在部署前都要经过开发者审核。系统还会统计关键指标，包括解决时长和修复带来的成本影响。
方案架构
图 1：端到端多智能体自愈 SRE 方案
流程说明
这套 AI 辅助运维流程把生产环境中的实时问题和一份经过验证的修复方案自动串了起来。出现有缺陷的部署时，Amazon CloudWatch 监控会发现故障并向 SRE Agent 发送告警。SRE Agent 对告警做校验和规范化，通过 DevOps Agent 排查根因，并在 Microsoft Teams 中通知工程师。如果确认适合修复，Dev Agent 会应用建议的改动、运行验证检查，并自动创建一个内容详尽的 GitHub 拉取请求（PR）。随后工程团队收到通知，进行审核和批准，从而在人工监督下完成整个自愈闭环。
示例工作流：内存限制设置错误
- 部署了有缺陷的变更：开发者提交了一处代码改动，其中设置的内存限制过低，并通过 CI/CD 流水线部署到了开发用的 Kubernetes 集群。
- 运行时故障被检测到：流量高峰期间，Pod 超出了分配给它的内存上限。Linux 内核终止了容器，Kubernetes 随即报告 OOMKilled 状态，并进入 CrashLoopBackOff 循环。
- 告警被接收：Instana 检测到反复重启，通过 HTTP POST 将结构化告警载荷经 Amazon API Gateway 发送到运行在 Amazon Bedrock AgentCore Runtime 上的 SRE Agent 的
/invocations端点。 - 事件校验与规范化：SRE Agent 校验
alert_id、severity、service、environment等必填字段，然后把告警规范化为 SRE Skill Envelope，并调用只读的 DevOps Agent。 - 事件分诊：AWS DevOps Agent 分析遥测数据，向 SRE Agent 返回
investigation_summary，同时附上一份统一的 diff，给出修复内存限制的建议。
图 2：根因分析报告与修复建议
- 修复被调度：SRE Agent 把结构化的
investigation_summary输出直接送入 Dev Agent 的调用端点。 - 修复经门禁校验与测试：Dev Agent 确认仓库在允许的仓库列表中，且
fix_applicable = true。它通过 RS256 JWT 交换以 GitHub App 身份完成认证，在沙箱中应用建议的补丁，并运行Terraform fmt或pytest等检查。 - 生成拉取请求：如果校验通过，Dev Agent 会创建一个工作分支，用其机器人身份提交变更、推送，并打开一个详细的 GitHub 拉取请求，其中包含事件时间线、根因、建议的修复方案和测试结果。
图 3：生成的拉取请求通知
- 通知工程团队评审：Dev Agent 在 Amazon CloudWatch 中记录完成事件，并发送一条 Microsoft Teams 通知，附上拉取请求链接，让工程师可以在合并前评审并批准这次变更。
图 4：自愈修复流程
安全保障机制的实际运作
团队在系统中加入了多层防护措施，确保整套方案能在大规模场景下稳定运行。这些措施包括：
- 触发 SRE Agent 的 AWS Lambda 函数借助 Amazon DynamoDB 做了去重，短时间内出现相同或相似的告警时会被忽略，避免同一个问题被反复处理。
- Dev Agent 只在允许的代码仓库里做改动，不会在无关仓库上浪费精力。
- Dev Agent 在提交 pull request 之前，会先在沙盒里验证拟定的修复方案，这大大提升了修复的可靠性。
- 我们使用了 Amazon Bedrock AgentCore 的最新特性，借助时序策略实现有状态智能体的授权，并对 AI 流量做限流，作为额外一层安全保障。
- 我们加了一个成本触发的熔断机制：通过 Amazon CloudWatch 告警和 AWS Lambda 实现，一旦总成本超过合理阈值，就停掉整套系统，相当于给异常用量加了一道硬性保险丝。
关键决策
团队在开发这套方案时，基于以下情况做出了一些关键决策：
- 开发期间，AWS DevOps agent 还不支持代码修复，因此我们采用了多智能体架构，专门设置了一个负责编码和验证的智能体。
- Amazon Bedrock AgentCore 现在内置了时序策略和限流功能，但这些功能是在项目的概念验证和原型阶段之后才推出的。在它发布之前，我们通过触发用的 AWS Lambda 函数单独做限流。后来我们已经把方案更新为使用 Amazon Bedrock AgentCore 的这项能力。
- 这套方案只针对经过反复验证、测试充分的错误场景执行动作，因此成功率高且稳定可靠。
- 未来，我们会扩大方案能处理的错误范围。
效果衡量与后续计划
在引入这套方案之前，平均每起事故要花 2–3 小时做人工排查、准备代码修复。用上 TASP! 之后，自动流程加上人工审核批准只需 15 分钟，平均解决时间缩短了约 88%。
接下来几周，我们打算把方案覆盖的事故类型进一步扩大，包括：
- 自动处理应用层错误
- 提前拦截有问题的代码
- 建设定制知识库，纳入 Daimler Truck 编码规范
- 在沙箱中运行测试，在开发者批准前验证拉取请求