新上线今天0 投票
让 AI 不只诊断还能修复：AWS DevOps Agent 自动化补救方案解析
从「只诊断」到「可执行」：AWS 补上事故响应的最后一公里
在生产环境中，缩短事故从发现、调查到修复的时间（MTTR） 始终是运维团队的核心目标。但现实往往是：工程师需要在深夜快速定位跨组件问题、找到根因，再手动执行修复。
AWS 的 DevOps Agent 是一款由 AI 驱动的代理，能够基于关联的指标、日志和应用拓扑，全天候自动对事故进行分诊，并提供根因分析（RCA） 与修复建议。不过，出于对生产环境安全性的考量，多数企业会将这类可观测性代理保持在**「观察并报告」模式**——它能诊断问题，但不会直接改动生产资源。
这留下了一个缺口：AI 给出了答案，最后一步仍需人工完成。
解决方案：用无服务器工作流补齐修复环节
AWS 官方博客介绍了一套自动化补救工作流，将 AWS DevOps Agent 的调查总结转化为经过预验证的修复方案，让值班工程师只需一次审批动作即可完成处置。
该方案整合了三项服务：
- AWS Lambda Durable Functions：用于构建具备弹性的多步骤应用与 AI 工作流，最长可运行一年，无需管理额外基础设施或编写自定义状态管理与错误处理代码。函数会自动检查点进度、在长时间任务中挂起执行，并在中断后恢复，保持可靠推进。
- Amazon EventBridge：接收调查完成事件，并触发后续处理函数。
- Amazon Bedrock：用于生成或验证修复方案。
工作流如何运转
根据文章描述，整体流程如下：
- AWS DevOps Agent 完成事故调查，发出包含症状、发现和根因分析的事件。
- Amazon EventBridge 接收该调查完成事件，触发
devops-agent-trigger函数，并传入调查内容。 - Lambda 函数打包调查摘要，进入后续自动化处理链路。
- 结合 Amazon Bedrock 将调查总结转化为预验证的修复动作。
- 在变更真正触达基础设施之前，可选地加入人工审批环节，值班工程师一键确认即可执行。
为什么值得关注
这套方案的价值在于平衡了自动化与可控性：既保留了 AI 代理在诊断阶段的高效，又通过单次审批机制避免了 AI 直接改动生产资源带来的风险。对于希望降低 MTTR、同时又不愿放弃人工把关的团队来说，这是一种务实的折中路径。
目前该方案仍以官方技术博客形式呈现，具体的部署细节、Bedrock 提示词设计以及审批机制实现，需参考原文完整内容。
