AWS 发布自动化修复方案：DevOps Agent 完成根因分析后，用 Lambda Durable Functions 与 Bedrock 执行修复
来源AWS Machine Learning查看原文
速览
- 方案定位是补上 DevOps Agent 之后的修复执行环节，而非替代其诊断能力
- 核心安全设计是工具白名单加人工审批门，变更类操作必须显式授权
- 持久化函数在等待审批时可挂起数分钟到数天，且不占用计算资源
- 新增修复能力只需更新工具注册表配置，不必改动编排器代码
- 官方强调调查摘要与修复建议均为 AI 生成，批准前必须人工复核完整工具参数
- 示例中 3 秒超时被改为 30 秒，全程只需工程师一次批准动作
AWS 在其机器学习博客上发布了一套参考实现，用于补上 AWS DevOps Agent 的最后一环——修复执行。AWS DevOps Agent 本身是 AI 驱动的运维代理，能基于关联后的指标、日志和应用拓扑自主分诊事件并给出根因分析（RCA）与修复建议，但企业出于控制风险考虑，通常让它停留在「只观察、只报告」模式，不直接改动生产资源。新方案用 Amazon EventBridge 接收 DevOps Agent 的「调查完成」事件，触发 Lambda 函数调用 Lambda Durable Functions 编排的持久化工作流，再由 Amazon Bedrock 分析调查结论、从预先批准的 Lambda 工具白名单中挑选修复动作。只读操作自动执行；会修改基础设施状态的操作则挂起工作流，等待人工批准后再执行。整套方案通过 AWS CDK 部署，代码已放在 GitHub 的 aws-samples 仓库中。
关键事实
- AWS DevOps Agent 是 AI 驱动的运维代理，基于关联的指标、日志和应用拓扑自主分诊事件，输出根因分析（RCA）与修复建议
- 企业通常将包括 AWS DevOps Agent 在内的可观测性代理保持在 observe-and-report 模式，即只诊断、不直接修改生产资源
- 工作流链路为：DevOps Agent 发出调查完成事件 → Amazon EventBridge 触发 devops-agent-trigger 函数 → 调用 devops-agent-remediation-durable 持久化函数 → 调用 Amazon Bedrock 分析并选择修复工具
- AWS Lambda Durable Functions 支持最长运行一年，自动对进度做检查点、在长任务期间挂起执行、从失败中恢复，且挂起等待审批期间不消耗计算资源
- 修复工具来自预先批准的白名单，每个工具是一个专用 Lambda 函数，执行单一且范围明确的操作，例如读取 Lambda 函数配置或更新 IAM 策略语句
- 只读工具自主执行；修改基础设施状态的变更类操作会让持久化函数挂起，等待人工批准信号后才继续
本站视角
对在 AWS 上跑生产负载的中小团队和平台工程团队来说，这套方案的价值不在于技术新颖，而在于它给出了一个可直接抄的「半自动运维」骨架：诊断交给 AI，执行卡在人工审批门后面。这解决了一个真实矛盾——团队既想压缩 MTTR，又不敢让 AI 直接动生产。具体受益的是 on-call 轮值压力大的团队，尤其是人手有限、没有专职 SRE 的中小公司，因为方案把「翻配置、比对根因、准备变更」这些重复劳动前置完成了，工程师到场时只需点一次批准。 我们的判断是：这是实质性的工程参考，但不是产品级的开箱能力。它是一篇博客加一个 CDK 示例仓库，需要自己部署、自己维护工具白名单、自己接审批通道。真正决定它好不好用的是工具库的丰富度——示例里只有读取函数配置和更新函数配置这类基础动作，而现实中的故障修复往往涉及回滚部署、调整扩缩容策略、修改网络配置等更复杂的操作，这些都需要团队自行封装成白名单工具。换句话说，编排框架 AWS 给了，修复能力的沉淀仍要团队自己做。 需要指出的可疑之处有两点。其一，示例场景过于理想：一个测试函数超时从 3 秒改到 30 秒，根因单一、修复动作明确、无副作用，这与真实生产故障的模糊性和连锁影响差距很大，博客并未展示多根因、修复失败或审批被拒后的处理路径。其二，文章由 AWS 技术客户经理撰写，本质是推广 Lambda Durable Functions、Bedrock 与 DevOps Agent 的组合用法，对方案局限性的讨论自然有限。另外，文中提到 Bedrock 在推理时依据函数名「devops-agent-timeout」判断这是测试函数，这种基于命名的推断在生产环境里恰恰是风险来源，也侧面说明人工审批门不是可选项而是必需项。
背景与影响
在 AWS 上跑生产负载的团队，长期面对的核心痛点是缩短事件从发现、调查到修复的时间。on-call 工程师往往要在深夜跨多个应用组件定位问题、找根因、再动手修。AWS DevOps Agent 解决的是前半段：它自主关联 CloudWatch 指标、日志和函数配置，给出根因分析与建议动作。但出于防止意外变更的考虑，多数组织不让这类代理直接改生产资源，于是「诊断完了谁来修」成了断点。这套参考实现正是针对这个断点：用 EventBridge 做事件入口，用 Lambda Durable Functions 做有状态编排，用 Bedrock 做决策，用白名单 Lambda 工具做受控执行。值得注意的是，Durable Functions 的检查点与挂起能力是这套设计成立的前提——审批可能要等几小时甚至几天，传统 Lambda 无法在等待期间既不超时又不烧计算资源。从行业角度看，这延续了 2025 年以来「Agent 负责诊断与提议、人类负责授权」的运维自动化范式，与单纯追求全自动修复的路线形成对照。需要观察的是：白名单机制虽然控制了风险，但也意味着每新增一种修复能力都要先写好并注册对应工具，实际落地时的维护成本取决于团队的工具库积累速度。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。