Runbooks 不调查，AWS DevOps Agent 调查。

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line, formatting, markdown, and any code blocks exactly as you specify.

概览

我完成了 DR Toolkit，以为已经涵盖了灾难恢复的关键部分：运行手册、RTO/RPO 目标、事后分析。随后我绘制了实际的事件生命周期，才发现我构建的所有内容都位于边缘。中间的部分（检测事件、跨区域关联信号、在主区域正经历故障时寻找根本原因）没有覆盖。这一空白正是本系列要讨论的内容。

在 BuildWithAI: DR Toolkit on AWS 系列中，我演示了如何构建六个 AI 驱动的工具，自动化 DR 规划中繁琐的前置工作，全部运行在 ap‑southeast‑1 的无服务器 AWS 上。这些工具处理的是事件前和事件后的工作。但介于两者之间的实际事件响应——没有任何工具涉及。

本系列使用 AWS DevOps Agent 来填补这中间阶段。演示应用是 PayLedger，一个专为本博客构建的多区域无服务器支付账本。它不是真实产品，也不包含真实用户数据。

• 第 1 部分 绘制空白，介绍 DevOps Agent，并 walkthrough 架构。
• 第 2 部分 完整设置与实际演示，包括我对其运行三个真实故障时，代理的调查过程。

DR Toolkit 在 Prepare 阶段表现稳健。CloudWatch 和 Route 53 负责 Detect——警报触发，Route 53 故障转移会自动将流量路由到健康的区域。但 Investigate 阶段缺乏真正的工具，除非有人自行构建。弄清楚为何主区域的服务宕机、跨服务信号关联，并向团队提供恢复该区域所需的信息——这正是 AWS DevOps Agent 所针对的。

AWS DevOps Agent

AWS DevOps Agent 是用于云运维的 前沿代理。 “前沿代理” 是 AWS 对自主系统的称呼，这类系统能够：

• 独立工作，
• 在并发任务之间横向扩展，且
• 持续运行，无需持续的人为监督。

代理在警报触发的瞬间即开始工作——无需手动触发。

三大核心能力

1. 自主事故响应

   • 当警报到达时，代理立即开始调查。
   • 它在服务和区域之间关联信号。
   • 如果多个警报源于同一根本原因，代理会将它们归为一组。
   • 代理调查的根本原因类别包括：
     • 系统变更
     • 输入异常
     • 资源限制
     • 组件故障
     • 依赖问题

2. 主动事故预防

   • 调查结束后，代理会在四个方面提出改进建议：
     • 可观测性
     • 基础设施优化
     • 部署流水线
     • 应用弹性

3. 按需 SRE 任务

   • 与实际基础设施进行对话式聊天。
   • 可查询资源状态、警报状态、部署历史等，无需切换控制台。

架构

该服务采用 双控制台架构：

更多功能信息：

• [AWS DevOps Agent features]
• [About AWS DevOps Agent]

可用性

截至本文撰写时，AWS DevOps Agent 尚未在 ap‑southeast‑1（新加坡）正式推出。支持的区域包括：

us-east-1
us-west-2
eu-central-1
eu-west-1
ap-southeast-2
ap-northeast-1

AWS 未来可能会添加更多区域，请在开始使用前查看 Supported Regions 页面。

• 对于东南亚的构建者来说，最近的两个区域是 ap‑southeast‑2（悉尼）和 ap‑northeast‑1（东京）。
• 本次演示使用了 ap‑southeast‑2，但任何受支持的区域都可以使用。
• Agent Space 及其调查数据位于所选区域；您的工作负载仍然保持在原有位置。
• 跨区域监控意味着代理能够发现并监控任何已关联 AWS 账户中的资源，无论其所在区域如何。

注意： PayLedger 是为本系列博客专门构建的演示项目。它与任何真实业务无关，不处理真实交易，也不包含任何个人身份信息。所有数据均为合成数据，由种子脚本生成。

PayLedger 演示应用

支付账本是 DR 演示的实用选择，因为需求很明确：任何停机都会导致交易失败，余额变得过时。多区域部署是正确的响应，而不是过度设计。

接口

架构图

payledger.yourdomain.com  (CloudFront + S3)
        |
   Next.js UI
   (balance, transactions, region indicator)
        | calls
        v
api-payledger.yourdomain.com
        |
   Route 53 (failover routing)
        |-- PRIMARY   --> ap-southeast-1 (Singapore)
        +-- SECONDARY --> ap-northeast-1 (Tokyo)

ap-southeast-1                         ap-northeast-1
+-- API Gateway                        +-- API Gateway
+-- Lambda: createTransaction           +-- Lambda: createTransaction
+-- DynamoDB Global Table (replicated)  +-- DynamoDB Global Table (replicated)

• Route 53 在两个区域之间执行主动‑被动故障转移。
• DynamoDB 全局表 将账本数据复制到各区域，确保一致性。

---

后续步骤

• 第 1 部分 – 绘制差距图，引入 DevOps Agent，并 walkthrough 架构（本页）。
• 第 2 部分 – 完整搭建和现场演示，包括三次真实故障注入以及 Agent 的调查输出。

敬请期待！

架构概览

+-- Lambda: listTransactions           +-- Lambda: listTransactions
+-- Lambda: getBalance                 +-- Lambda: getBalance
+-- Lambda: health                     +-- Lambda: health
+-- Lambda: devopsAgentTrigger         +-- Lambda: devopsAgentTrigger
+-- DynamoDB       +-- DynamoDB (replica)
+-- SNS Topic (alarm notifications)    +-- SNS Topic (alarm notifications)
+-- CloudWatch alarms                  +-- CloudWatch alarms

                    ap-southeast-2 (Sydney)
                    +-- AWS DevOps Agent
                        +-- Agent Space
                        +-- Slack (optional)
                        +-- GitHub (optional)

---

服务层概述

---

故障切换行为

• 健康检查 – Route 53 每 10 秒 调用一次 /health。
• 故障切换触发 – 如果检查 失败两次（≈ 20 秒），DNS 将流量切换到次要区域。
• 前端指示器 – UI 每 5 秒 轮询 /health 并显示彩色徽章：
  • 绿色 – 新加坡（PRIMARY）
  • 琥珀色 – 东京（FAILOVER）
• 数据复制 – DynamoDB 全局表在各区域保持余额和交易历史同步。故障切换后数据保持一致，仅服务区域发生变化。
• 故障注入场景 – 当在 ap‑southeast‑1（新加坡）注入故障时，健康检查开始失败，Route 53 在约 20 秒内将流量重新路由到 ap‑northeast‑1（东京）。用户继续从东京获取服务，DevOps Agent 进行调查。根本原因修复后，主区域恢复，Route 53 再次切回。

故障注入矩阵

所有三个故障会通过 python scripts/fault.py inject 同时触发。默认模式为每个服务分配一个独立故障。

• 在 ap‑southeast‑1 触发了一个告警。
• 调查中出现了三种不同的根本原因。
• DevOps Agent 必须在一次运行中理清这三项故障——这比单独处理每个故障更具挑战性。

灾难恢复（DR）工具包背景

• Prepare 阶段已由 DR 工具包覆盖。
• 本系列聚焦于 Investigate 和 Recover —— 即在警报触发 之后 进行的步骤。

AWS DevOps Agent 在调查时 不需要 DR 工具包。它：

1. 读取拓扑结构。
2. 跨服务关联信号。
3. 确定根本原因。
4. 自动将发现结果发布到 Slack。

可选地，您可以预加载由 DR 工具包生成的运行手册作为 Custom Skill，为代理提供额外的架构知识。

---

第2部分 – 实操演示

在接下来的部分，我们将：

1. 将 PayLedger 部署到两个区域。
2. 配置 Route 53 故障切换。
3. 搭建 Agent Space（Slack、GitHub 等）。
4. 运行三个同时发生的故障。

我们将逐步回顾代理的时间线、发现、根本原因识别以及缓解建议。

---

开始 / Fork It

• 代码仓库:
• 项目名称: payledger-aws-devops-agent

PayLedger – 一个多区域无服务器支付账本（仅演示）。
部署在 ap‑southeast‑1（新加坡，主区域）和 ap‑northeast‑1（东京，备份区域），使用 Lambda、DynamoDB 全局表和 Route 53 故障切换路由。
注意：这是一个演示项目。它不处理真实交易，也不包含任何个人身份信息（PII）。

---

架构图（高级）

payledger.yourdomain.com (CloudFront + S3)
          │
   Next.js static UI (balance, transactions, region indicator)
          │
          ▼
api-payledger.yourdomain.com
          │
Route 53 fail‑over routing
├── PRIMARY   ──▶ apse1-api-payledger.yourdomain.com  ← health check
└── SECONDARY ──▶ apne1-api-payledger.yourdomain.com  ← health check
TTL: 60 s | health check: 10 s interval, 2 failures to trip
          │
 ┌────────┴─────────┐
 │                  │
ap‑southeast‑1      ap‑northeast‑1
(Singapore)         (Tokyo)
│                   │
│  API Gateway      │  API Gateway
│  (regional)      │  (regional)
│  Lambda: createTransaction
│  Lambda: listTransactions
│  … (other functions)
│
└─ DynamoDB Global Table (replicated)

---

参考文献

• AWS DevOps Agent – 功能、支持的地区和概览。
• Amazon DynamoDB Global Tables – 多区域复制。
• Amazon Route 53 – 故障切换路由配置。
• Disaster Recovery of Workloads on AWS – 最佳实践指南。