AWS DevOps Agent 自动修复实战：从诊断到一键审批

AWS DevOps Agent 能够诊断生产环境事故，但出于安全考虑，它被限制在"观察与报告"模式——只分析问题、给出结论，却不会直接修改任何资源。这种设计避免了自动化系统在未经人工确认的情况下误操作生产环境，但也留下了一道鸿沟：从拿到诊断报告，到真正落地修复，中间仍需要工程师手动介入。

这篇来自 AWS 的技术文章给出了一套填补这道鸿沟的方案：借助 AWS Lambda Durable Functions、Amazon EventBridge 和 Amazon Bedrock，把 DevOps Agent 的调查摘要转化为"预验证的修复动作"，让值班工程师只需一次点击即可批准执行。

为什么 DevOps Agent 默认只观察不动手

生产环境事故处理有一条基本原则：诊断可以自动化，执行必须谨慎。AWS DevOps Agent 被刻意保留在 observe-and-report（观察并报告）模式，意味着它可以深入分析指标、日志、资源配置，定位问题根因，但不会自主改动任何云资源。

这一设计的合理性显而易见。生产事故本身已经处于高压状态，如果让 AI 代理在没有人工确认的情况下直接修改资源，一旦判断失误，可能造成二次故障甚至更大范围的影响。保持"只报告"的边界，等于把最终决策权牢牢交还给人类工程师。

但问题在于，诊断和修复之间存在明显的效率损耗。工程师拿到一份详尽的调查摘要后，仍需要自己理解结论、设计修复方案、编写并验证操作命令，再手动执行。在凌晨被告警叫醒的值班场景下，这段流程既耗时又容易出错。

用三件 AWS 服务串起修复闭环

文章提出的核心思路，是在"诊断"和"执行"之间插入一个自动化的"修复准备"环节，由三个 AWS 服务协同完成：

Amazon EventBridge：事件驱动的触发器

EventBridge 承担事件路由的角色。当 DevOps Agent 完成一次调查并产出摘要后，这份结果可以作为事件被 EventBridge 捕获，进而触发后续的处理流程。这种事件驱动架构让整个链路保持松耦合，各环节各司其职。

Amazon Bedrock：把调查摘要翻译成修复方案

Bedrock 提供的生成式 AI 能力，负责理解 DevOps Agent 的调查摘要，并据此生成针对性的修复动作。换句话说，Agent 负责"诊断"，Bedrock 则负责把诊断结论"翻译"成可执行的修复步骤。这一步是整套方案的智能核心，它让非结构化的调查文本变成结构化、可操作的修复方案。

AWS Lambda Durable Functions：编排有状态的长流程

Lambda Durable Functions（持久化函数）负责编排整个修复工作流。相比传统的无状态 Lambda，持久化函数能够维护流程状态，支持长时间运行和分步执行——这对于需要"等待人工审批"这类暂停与恢复的场景尤为关键。它可以暂停流程、等待工程师批准，再根据批准结果继续执行或终止。

Lambda Durable Functions 是 AWS 对微软 Azure Durable Functions 概念的跟进实现，于2024年底进入预览阶段。传统 AWS Lambda 函数是无状态的，每次调用最长执行15分钟，函数之间无法直接共享运行时状态，难以表达"等待外部事件后继续"这类工作流逻辑。Durable Functions 通过引入持久化的执行历史（存储于后端如 Amazon DynamoDB），让函数可以在任意时刻"休眠"并在条件满足后恢复，同时保留完整的上下文和局部变量。在审批场景中，工作流会在发送通知后挂起（不消耗计算资源），等到工程师点击批准链接触发回调时再唤醒，继续执行后续的资源变更步骤。这一特性使得原本需要借助 AWS Step Functions 才能实现的人机交互式长流程，可以用更轻量、更贴近代码的方式表达。

"预验证"是方案的关键价值

整套设计中最值得关注的词是 pre-validated（预验证）。生成的修复方案并非直接丢给工程师一份模糊的建议，而是经过验证、随时可执行的具体动作。

这意味着当值班工程师收到修复提案时，他看到的是一个明确的、已经被检查过可行性的操作，而不是需要自己再推敲和实现的草稿。工程师的角色从"方案设计者"转变为"方案审批者"——只需判断是否批准，而无需从零构建解决方案。

这种"single action approve（一键批准）"的交互模式，在保留人工决策把关的同时，极大压缩了从诊断到修复的时间。既没有牺牲安全性，又显著提升了响应效率。

这套模式的更广泛意义

这一方案折射出当前 AI 代理在运维领域落地的一种典型思路：人机协作而非完全自治。AI 承担信息处理和方案生成这类高强度、重复性的工作，人类则在关键决策节点保留否决权。

对于正在探索 AIOps 的团队而言，这套"诊断 Agent + 事件总线 + 生成式方案 + 有状态编排 + 人工审批"的组合提供了一个可借鉴的架构范式。它既不是把一切交给 AI 的激进自动化，也不是让工程师从头到尾手工处理的传统模式，而是在二者之间找到了一个务实的平衡点。

随着 AI 代理能力的持续增强，这种"AI 准备、人类拍板"的协作范式，很可能成为生产环境自动化演进的一个重要方向。

AIOps（AI for IT Operations）是将机器学习和生成式 AI 应用于 IT 运维全生命周期的实践方向，涵盖异常检测、根因分析、容量预测和自动修复等场景。区别于规则驱动的传统自动化运维（如基于阈值的自动扩缩容），AIOps 的核心价值在于处理非结构化数据（日志、告警文本、变更记录）和跨系统关联分析，从而应对传统规则难以覆盖的模糊故障场景。本文方案中，Bedrock 将非结构化的调查摘要翻译为结构化修复步骤，正是 AIOps 中"AI 增强的根因到修复"链路的典型实现。当前业界在该方向的主要挑战包括：AI 生成修复方案的准确率与置信度评估、如何构建针对运维场景的反馈闭环以持续改进模型，以及在多云和混合云环境下跨平台编排的复杂性。