AWS DevOps Agent 实战：如何使用生成式 AI 加速故障演练

摘要：本文将通过示例介绍，如何借助 Kiro 与 AWS DevOps Agent，把原本高度依赖人力的演练，转变为低成本、可复现、并能在每次演练中自动产出调查结论的流程。读完本文，您将了解如何为每一类故障切换信号设计可靠的检测、如何运行基础演练并设计其他演练流程，以及如何把 DevOps Agent 集成到您的 on-call 流程。

一、前言

任何生产系统都可能出现各类故障，例如服务器宕机、数据库主从切换、缓存节点失联、中间件依赖变慢等。更关键的是，日常的监控与告警是被动的，它们只在故障真正发生时才起作用；在故障未发生时，团队无法确认告警是否有效、响应流程能否按预先设计快速执行。演练的目的正是将这种不确定转化为可掌握的确定性：在真实故障发生之前，主动在测试或预生产环境中制造已知故障，以检验架构的可靠性设计与响应流程，并借此提升团队的响应速度。一次完整的演练，通常是在检验故障响应流程中的几个关键环节：

• 可观测性与检测：故障发生后，系统能否在第一时间发出告警。例如数据库刚发生一次主从切换、某个节点掉线，是否有对应的告警？告警又需要多久才能送达值班工程师？如果告警滞后，甚至没有触发，业务可能已经受到影响，而运维团队仍无从知晓。
• 调查与定位（根因分析）：告警触发之后，能否快速定位问题并查清根因。这一步通常最为耗时，也最考验能力，工程师不仅需要对业务系统有深入的了解，还要在大量监控图表、日志与近期变更记录中反复检索、逐一排除。
• 复盘与持续改进：故障处理完成后，将本次的时间线、根因与处理过程记录下来，总结发生原因与后续的规避措施，将经验沉淀为可落地的改进项，避免同类问题重复发生。

在 Kiro 与 DevOps Agent 这类生成式 AI 工具出现之前，演练流程几乎全靠人工完成：运维工程师需要专门维护一套手册与脚本，并在环境每次变更后手动更新。正因为每个环节都高度依赖人力，它们才难以被持续做好，许多运维团队实际上并没有足够的人力去持续完善演练。本文将通过示例介绍，如何借助 Kiro 与 AWS DevOps Agent，把原本高度依赖人力的演练，转变为低成本、可复现、并能在每次演练中自动产出调查结论的流程。读完本文，您将了解如何为每一类故障切换信号设计可靠的检测、如何运行基础演练并设计其他演练流程，以及如何把 DevOps Agent 集成到您的 on-call 流程。

二、关于 DevOps Agent

AWS DevOps Agent 是一个由生成式 AI 驱动的自主运维智能体，可以将其理解为一位随时待命的站点可靠性工程（SRE）协作者。它解决的核心问题是：线上出现异常时，自动展开调查、定位根因，并给出可执行的缓解建议，将事件的平均恢复时间（MTTR）从小时级缩短至分钟级。DevOps Agent 需要在收到触发信号（例如一条 Amazon CloudWatch 告警或一张支持工单）后创建调查，先理解现象、制定调查计划，再把具体的排查任务分派给多个专职的子智能体并行执行。它的调查是“联邦式”的，会跨越您的可观测性栈（指标、日志、链路追踪）、基础设施配置乃至代码与部署变更，将表象一路追溯到真正的变更来源，最后输出一份结构化的根因分析与缓解方案。

在本文中，我们将 DevOps Agent 定义为演练的“自动首响者”：演练一旦注入故障、触发告警，DevOps Agent便自动接手调查、产出调查报告，随后交接给 on-call 工程师。我们还可以让 Kiro 作为工程师的生成式 AI 助手，调用 DevOps Agent API 获取信息，检查可观测性系统是否触发告警、告警是否及时、自动生成演练报告、提出流程改进、对可观测性基础提出建议等，将演练固化为一套可反复执行的流程。Kiro和DevOps Agent将负责完成大部分的文字工作和演练、调查流程，可以反复对演练流程进行验证和完善，大大减少了人的工作和实现效率提升。

三、示例应用

在接下来的部分，我们将通过一个示例应用，用轻量的故障切换演练来验证故障响应流程。示例应用是一个虚拟的电商微服务应用，整套部署跨三个可用区，前端与各业务服务都以容器形式运行。四个托管服务分别支撑不同的业务能力：

• Amazon EKS容器编排平台，运行前端 UI 以及商品、购物车、订单等全部微服务。
• Amazon Aurora关系型数据库，存放商品目录、订单等核心业务数据。
• Amazon ElastiCache for Redis缓存层，存放购物车这类对时延敏感的数据。
• Amazon MSK（Kafka）消息队列，承载下单等异步事件流，将下单动作与后续处理解耦。

下图（图 1）展示了该应用的整体架构：模拟出的用户请求经前端 UI 进入，商品服务读写 Aurora、购物车服务读写 Redis、下单流程通过 MSK 异步串联，所有微服务都运行在跨三个可用区的 EKS 集群上。这样，后续我们对任意一个托管服务做故障切换演练时，您都能清楚它对应用的哪一部分产生影响。

[图 1. 示例电商应用架构]

需要说明的是，该示例应用的流量并非真实用户产生，而是由一个内置的负载生成器（load generator）持续模拟。它会不间断地执行一遍典型的购物流程，反复访问前端 UI 的主要接口，例如打开首页（GET /）、浏览商品目录（GET /catalog）、查看商品详情（GET /catalog/{id}）、加入购物车以及下单结算，这些请求再由 UI 扇出到后端的商品、购物车、订单等服务。这样做的目的，是让系统始终保持一个稳定的基线流量：当我们对某个托管服务做故障切换时，它对请求成功率与时延的影响才能被清楚地观测到，而不会因缺乏流量而无法观测。

前面提到，DevOps Agent 是“被触发”才创建调查的，它不会主动推测故障位置，而是需要一个明确的入口信号（一个 webhook 请求）来启动调查。在接入方式上，DevOps Agent 既可以由告警或事件通过 webhook 触发，也能与工单系统、Slack 以及 Datadog、PagerDuty 等第三方工具集成，覆盖 AWS、多云与本地环境。我们为演练准备了两条互补的触发链路：

• 事件路径：许多故障本身就会产生“事件”，例如 Amazon Aurora 完成一次故障切换会发出一条 RDS 事件，或者某个 CloudWatch 告警从 OK 变为 ALARM。这类事件由一条 Amazon EventBridge 规则捕获，触发一个中继 AWS Lambda 函数，再由它将事件包装成 incident 并 POST 到 DevOps Agent 的 webhook。
• 指标路径：另一些故障需要靠“指标”才能识别，例如节点掉线、副本欠同步。这类指标先被采集进 Prometheus，由 Grafana 的告警规则每分钟评估一次；一旦越过阈值（firing），Grafana 就将其 POST 到同一个 webhook。

[图 2. DevOps Agent 的两条触发链路]

在真实场景中，同一个根因往往会同时触发多个异常，例如一次 Amazon Aurora 故障切换，可能既发出 RDS 事件、又让上游服务的错误率告警、还带动多个监控指标越过阈值。DevOps Agent 支持事件关联：它会自动将相似的、时间接近的、或指向同一资源与根因的多个事件，归拢到同一次调查中，形成“一个主调查加若干关联事件”的结构，而不是并行拉起多条互不相干的调查。这样，无论一次故障在您的观测栈中触发多少关联信号，工程师最终看到的都是一条聚合后的时间线和一份统一的根因分析，既压制了告警噪声，也避免同一个问题被反复排查。与此同时，工程师应确保可观测性基础足够完善，让尽可能多的故障信号都能在第一时间被捕获并告警。

关于 DevOps Agent 的基础使用以及如何配置 webhook，请参考 AWS DevOps Agent 用户指南。

四、故障响应场景设计

有了触发链路，接下来要为每个托管服务设计一个故障响应场景：注入什么故障、这个故障又会经哪条路径触发 DevOps Agent 创建调查。我们为四个服务各设计了一个基础场景，都用服务自带的原生命令触发一次真实的故障切换：

在示例应用中，我们将展示上述几类基础设施场景的演练过程与结果。在真实演练中，除了这些基础设施类场景外，可以按同样的思路设计更多演练（例如依赖变慢、网络分区、依赖限流等），如果希望将这些更复杂的演练做得更规范、更安全，可以使用 AWS Fault Injection Service（FIS），一个托管的混沌工程服务。相比手动执行一条原生命令，FIS 能注入更丰富的故障类型（例如网络延迟与丢包、可用区断电、批量终止节点等），支持自定义实验模板、设置“停止条件（stop condition）”作为安全护栏并在触发后自动回滚，还能将演练编排成可定时执行的 game day。本文的四个基础场景用原生命令即可演示；当您需要更贴近真实故障、或更大范围的实验时，FIS 是自然的下一步。如需进一步的定制化演练方案，也可以联系您的 AWS account 团队。更多内容可参考 AWS FIS 用户指南。

五、用 Kiro 生成演练手册（示例）

在真正注入故障之前，先为每个场景写一份演练手册作为执行计划，写清注入命令、预期触发路径、预期现象与预期恢复方式，供人工确认后再执行。手册是“演练前”的文档，此时还没有任何调查可参考，因此我们把上一节确定的演练设计（服务、注入命令、触发路径）直接提供给 Kiro，让它据此把手册补全：注入命令与触发路径来自设计，预期现象与预期恢复方式则由 Kiro 结合该服务的高可用机制推断。下面是一个示例提示词，只需替换其中的设计信息：

以下是一个故障演练的设计，请据此生成一份故障演练手册：
- 服务：{例如 Amazon Aurora}
- 注入方式：{例如 aws rds failover-db-cluster 触发一次数据库故障切换}
- 触发路径：{例如 事件路径——RDS 故障切换事件经 EventBridge 与中继 Lambda 送到 DevOps Agent}

请按以下结构补全手册：
1) 注入命令：写出完整的原生命令与必要参数（占位处标注需在演练时替换的实际标识，如集群名、实例 ID）
2) 预期触发路径：复述走事件路径还是指标路径、由哪类信号触发 DevOps Agent 创建调查
3) 预期现象：结合该服务的高可用机制，说明故障切换期间对应用可能产生的影响
4) 预期恢复方式：是否自愈、依赖哪种高可用机制（如 Multi-AZ 提升 / ASG 补节点 / 副本因子≥2），是否需要人工介入

以「# 故障演练手册：<服务> <故障>」作为标题直接开头，随后依次给出上述四段内容，不要添加任何额外的说明、注释或前后缀。

将以上四个场景信息各提供给 Kiro 跑一次，就得到覆盖全部场景的演练手册。手册在演练前明确了“预期会发生什么”，演练结束后再用 DevOps Agent 的真实调查结论与它对照，即可判断实际行为是否符合预期。如果使用了 FIS，还可以让 Kiro 参考 FIS 的 playbook 生成这份手册。您可以在这个提示词的基础上进行完善或自定义来生成演练文档。

六、运行演练与查看调查（示例）

手册确认之后，就可以把它交给 Kiro 来驱动整个演练过程。相比人工逐条敲命令再守着控制台刷新，Kiro 能按手册自动完成注入、并全程跟踪 DevOps Agent 的调查直到结束。这里有两个容易被忽视的关键点:其一是演练隔离，DevOps Agent 会把时间接近、指向同一资源的事件关联进同一次调查，因此在注入前应先结束尚未完成的调查，确保本次演练的结论独立、不被其它事件干扰;其二是必须等待调查跑到 COMPLETED 再停手，调查的根因摘要只有在完成后才可获取,中途取消会永久丢失本次结论。下面这条提示词只需替换其中的手册内容: