2026 年 9 月 28 日 Property Finder 公开复盘：生产事故从告警到修复 PR 的全流程由数小时至数天压到 14 分钟。 前置部署 Forward Deployed Engineer（FDE）把智能体交付进客户生产环境之后，真正决定成败的是 Day 2 运维这一段；这份复盘把告警、查因、建单、电话唤醒、修复 PR 五个环节的耗时逐段量了出来。 前置部署 FDE 交付的这类系统，价值不在告警能不能自动发出来，而在告警之后能不能自动完成关联、判断与记录；Property Finder 的这条流水线正是把这三件事从人身上挪到了智能体上。 原文把这条流水线称为自主事故管理，前置部署 FDE 可以把它按检测触发、自主调查、事件驱动输出三段来对照自己客户环境里的 on-call 流程，再决定哪一段先自动化。 复盘发布在亚马逊云科技 AWS DevOps 博客，署名作者三人：Nada Tlohi（AWS 技术客户经理，常驻迪拜）、Conor Manton（AWS 首席技术客户经理，常驻旧金山）与Jaydeep Singh（Property Finder 高级 DevOps 工程师）。 Property Finder 是中东与北非 MENA 地区的头部房产门户，业务覆盖五个市场；其核心房产搜索微服务 example-service 每天处理数百万次查询，架构是运行在 Amazon Elastic Container Service（ECS）上的一组微服务，前面挂 Application Load Balancer（ALB）。 一、原来的做法：告警唤起 on-call，人要在五个以上工具之间来回关联指标 改造前的流程是：告警触发、on-call 工程师被叫醒、花 20 至 40 分钟跨工具关联指标、手工记录结论、再开一个修复工单；非关键问题的平均解决时间（Mean Time to Resolution，MTTR）被拉到 2 至 3 天。 亚马逊云科技把原流程总结成三个缺口：检测滞后，非关键异常可能几天都没被发现；上下文切换，单个事故人均要在五个以上工具之间跳；知识孤岛，runbook 存在工程师脑子里而不是自动化里。 前置部署 FDE 在客户现场遇到的同类问题是同一个：不是没有告警，而是告警之后的关联、判断与记录全靠人。 这三个缺口对应三种交付动作：把检测阈值与告警状态机写进配置、把跨工具取数收进一次并行查询、把 runbook 从文档变成可执行的事件规则。前置部署 Forward Deployed Engineer（FDE）在别的客户环境里补的也是这三样。 二、新做法：Detection and Trigger、Autonomous Investigation、Event-Driven Output 三段流水线 第一段是检测与触发。CloudWatch Metrics Insights 监控所有 ECS 集群的健康状态，当持续 CPU 超过 98% 时告警进入 ALARM 状态；告警动作只在 ALARM 状态跃迁时直接调用一个 Lambda 函数。 这个 Lambda 做三件事：从 AWS Secrets Manager 取 webhook 密钥；给 CloudWatch 告警事件补上 ECS 服务元数据（cluster name、service name、task count）；用 HMAC-SHA256 对 payload 签名后 POST 到 webhook。 签名口径是 f"{ts}:{body}"，也就是时间戳与 JSON 正文用冒号拼接；请求头带 x-amzn-event-timestamp 与 x-amzn-event-signature（base64 编码的摘要）。前置部署 FDE 自建 webhook 触发链时可以直接照抄这两个头名与这条拼接规则。 第二段是自主调查。AWS DevOps Agent 启动后并行拉起四个子智能体，分别查询 ECS 指标、AWS CloudTrail、ALB 流量形态与 Grafana 遥测栈（Prometheus、Loki、Pyroscope），并读取 GitHub 上的相关源码做关联。 调查进度通过原生 Slack 集成实时发到 #incidents 频道，完整的根因分析、影响评估与缓解方案在话题末尾一次性给出。 第三段是事件驱动输出。Investigation Completed 事件发到 Amazon EventBridge，触发一个编排 Lambda 同时扇出到三个目标。 三个目标分别是：用 Lambda 从 journal records 取调查摘要并在 Jira 建单，带根因、严重级别与受影响服务；用 Lambda 向 Grafana IRM webhook 投一条 Grafana Alerting 兼容 payload，触发电话升级链，把「什么坏了、为什么坏、建议怎么修」一起念给 on-call 工程师；以及调用修复智能体生成代码修复。 三、一个真实事故：example-service 的 CPU 饱和到 99.11%，1:21 AM 告警、1:35 AM 修复 PR 已打开 原文给出一条逐分钟时间线：1:21 AM 告警触发（ECS CPU 超过 98%）；1:22 AM 调查开始并向 Slack 发帖；1:22 AM 四个并行子智能体启动；1:32 AM 根因确定；1:33 AM Jira 建单；1:34 AM 通过电话唤醒 on-call；1:35 AM GitHub 上的修复 PR 打开。 端到端 14 分钟。原文对改造前的口径是数小时至数天，因此这篇复盘自称端到端时间的降幅超过 88 percent。 查因这一段单独计时：智能体自主调查 10 分钟，原文对人工口径的估算是 20 至 40 分钟，降幅 50 至 75 percent。 原文把三行指标写成英文对照：End-to-end time 由 Hours to days 变为 14 minutes；Investigation 由 20 to 40 minutes（manual）变为 10 minutes（autonomous）；Documentation 由 Manual, incomplete 变为 100 percent documented。前置部署 Forward Deployed Engineer（FDE）引用这套数字时要注意，前两行是同口径测量，第三行只是完成度描述。 四、根因是两条互相冲突的自动扩缩策略，不是应用代码 根因是 CPU 目标追踪策略（target 70%）与内存目标追踪策略（target 75%）同时存在并互相冲突，而实际内存使用只有 3 至 8%，两条策略的结论长期相反。 叠加 MinCapacity 设置过低，服务无法维持吸收 CPU 负载所需的任务数；原文观察到 22 次以上的扩缩抖动，服务实际上被钉在 2 个任务上，没有 CPU 余量。 原文对这个根因的定性值得记住：团队同时配了两个扩缩维度却没有意识到它们会互相作用，尤其在容量下限没有按基线流量设定时。前置部署 FDE 在客户现场做容量评审时，这属于必查项。 智能体用 10 分钟识别出这个模式。原文承认，同样的模式通常需要具备深层扩缩经验的资深工程师花数小时做 CloudWatch 指标关联才能定位。 给出的缓解方案是三步：删掉基于内存的扩缩策略；抬高 MinCapacity 以覆盖基线流量；改成仅 CPU 的 target tracking，目标 70%。 五、修复层最有复用价值：调查只读、修复单独一个窄权限智能体、产出永远是草稿 PR AWS DevOps Agent 在调查阶段对基础设施强制只读：有效权限是执行角色 IAM 策略与 per-session guardrail 的交集，写操作被排除在这个交集之外。 修复由一个独立的 pr-creation-agent 完成，只在调查结束后被调用，它唯一的外部集成是 GitHub MCP server。 安全边界不依赖智能体内置的 directed actions 审批机制，而是靠两个控制：第一，修复智能体是独立且范围极窄的，只接 GitHub MCP；第二，它的每一个输出都是需要人工 review 与合并的 Draft PR。前置部署 FDE 在做权限设计时可以直接照搬这条切分，它把「能看」与「能改」拆成了两个智能体与两套凭据。 编排 Lambda 通过 CreateChat 与 SendMessage API 调用修复智能体，传入 investigation ID 与根因上下文。 修复智能体的工作顺序是：从 journal records 读结论；按资源 ARN 里的 account ID 把事故映射到正确的仓库——Property Finder 按团队维护 6 个基础设施仓库（B2B、B2C、core-platform、growth、data-engineering、shared-infra），这套映射由自动化测试校验，并随新账号或新仓库上线而更新；查重时在已有 PR 的标题与正文里搜 investigation ID，命中就直接回报 URL 并退出，不重复开单。 然后它用 GITHUB-MCP_get_file_contents 读相关 Terraform 文件，建一个 fix/{investigation_id} 分支，提交改动并打开 Draft PR，PR 模板固定包含问题摘要、根因、改动内容与测试清单四段。 GitHub MCP 的凭据是细粒度 personal access token，只授权到指定的基础设施仓库，带过期与轮换策略；原文明确说这条路径不需要提权 IAM 角色或额外智能体权限。 PR 永远是 Draft，工程师要跑 terraform plan、在 staging 验证后再合并，智能体从不自动合并。 原文引用的客户侧结论来自 Yasitha Bogamuwa（Property Finder 云工程经理）：他们现在完全依赖 AWS DevOps Agent 找基础设施问题，多个复杂问题没有开支持工单就定位了；原文补充说即使开了工单，支持工程师大概也要数小时才能找到根因。 六、照抄的四个前置条件与三步上线 前置条件有四项：账号里已经有配置好的 Agent Space；已启用 CloudWatch 与 CloudTrail 做可观测；Slack、Grafana、GitHub 已经作为 capability 接入，Grafana 侧需要 IRM；基础设施资源已打标签用于拓扑映射。 第一步配 webhook 触发：把 CloudWatch 告警动作指向一个 Lambda，由该 Lambda 富化 payload、做 HMAC 签名、POST 到 Agent Space 的 webhook 端点。 第二步配事件驱动输出：为 Investigation Completed 事件建 EventBridge 规则（事件源是 aws.aidevops），挂上面向 Jira、Grafana IRM 以及可选修复智能体的 Lambda 目标。 第三步做端到端测试：手动触发一次测试告警，确认调查启动、Slack 发帖、Jira 建单、on-call 被叫、PR 被打开五件事都发生。 清理清单原文也给了：如果只是照做试验，记得删掉 CloudWatch Alarms、Lambda 函数、EventBridge 规则与 Agent Space 配置，避免持续计费。前置部署 Forward Deployed Engineer（FDE）在客户环境里试完不清理，是很常见的成本泄漏点。 七、成本口径与原文自述的局限 成本口径只给了计费方式：每个事故调用两次智能体会话（调查一次、修复一次），单次最多四个并行子智能体，按 agent minutes 计费；原文把详细价格指向 AWS DevOps Agent 的定价页，没有给出单次事故的金额。 第一条局限是故障类型覆盖。完整时间线只有一例，且是 CPU 饱和这一种场景；内存泄漏、依赖超时、数据层故障等类型没有给数据，因此 14 分钟不能当成通用承诺。 第二条局限是前后对比表的成色不均。只有端到端时间与查因耗时两行有可比的数字；Documentation 一行从 Manual, incomplete 变成 100 percent documented，Remediation 一行从人工开 PR 变成自动生成草稿 PR，这两行是定性描述而不是同口径测量。 第三条局限是 10 分钟与 20 至 40 分钟并非严格同口径：前者是智能体自主调查的墙钟耗时，后者里包含人在多个工具间关联指标的时间，两者的计时边界不同。 第四条局限是没有误报数据。原文没有给误建 Jira 单、误叫 on-call 或误开 PR 的比例，去重逻辑也只按 investigation ID 匹配已有 PR 的标题与正文。 第五条局限是人工仍在环内。修复一律走 Draft PR 加人工 review 与合并，这套方案压缩的是定位与初稿时间，不是审批时间；原文对这一点写得很明确，智能体加速、工程师决定。 第六条局限是样本与技术栈单一。样本是一家 MENA 房产门户的 ECS 加 ALB 架构，未覆盖 Kubernetes 或 GKE、未覆盖自建 Prometheus 之外的遥测栈，也未给出多团队冲突或跨账号治理下的表现。 第七条是本文未覆盖的路线。原文提到 AWS 也支持用 Kiro CLI 配合 AWS CodeBuild 或 Kiro 提示词做修复；Property Finder 选择的是适配其多团队仓库结构的自建智能体路线，本文没有对 Kiro 路线做对比。 第八条是运行时长与样本量的关系。原文说这条流水线自 2026 年初已在生产运行，但没有公布累计处理的事故数、成功率或人工推翻智能体结论的次数。 八、该谁动手、具体怎么做、怎么退 该动手的是三类角色。前置部署 Forward Deployed Engineer（FDE）在做企业级运维智能体的现场交付；SRE 与平台团队在管 on-call 与事故响应；负责可靠性预算的团队负责人在决定要不要把钱从人工值班挪到智能体会话。 第一件具体的事是先把触发链的签名做对。用 AWS Secrets Manager 存 webhook 密钥，请求头固定为 x-amzn-event-timestamp 与 x-amzn-event-signature，摘要算法取 HMAC-SHA256，签名原文是时间戳与 JSON 正文用冒号拼接。这一层做错，后面的调查根本不会启动。 第二件是把授权切在两层上。调查层用执行角色 IAM 策略与 per-session guardrail 的交集做只读上限；修复层单独起一个只接 GitHub MCP 的窄权限智能体，凭据用限定到具体仓库的细粒度 personal access token，并设置过期与轮换。 第三件是强制产出为草稿 PR。让修复智能体的唯一出口是 Draft PR 加人工 review 与合并，并在 PR 模板里固定要求问题摘要、根因、改动内容与测试清单四段；这样即使根因判断错了，代价也只是一个不合并的草稿。 第四件是加一层按 investigation ID 的查重。在开 PR 之前先在已有 PR 的标题与正文里搜 investigation ID，命中就回报 URL 并退出，避免同一事故反复开单。 第五件是把扩缩策略纳入现场容量评审清单。CPU 与内存两个目标追踪策略同时存在、MinCapacity 没有按基线流量设定，是这次事故的直接原因，也是客户现场最容易漏配的两项；评审时把这两个检查项写进交付清单。 第六件是资源标签。拓扑映射依赖标签，标签不全时智能体拼不出服务拓扑，并行取数的四个子智能体就会退回盲查；上这条流水线之前先把 ECS 集群、服务与 ALB 的标签补齐。 适用条件有三条：架构是 ECS 加 ALB 这一类，且已开 CloudWatch 与 CloudTrail；Slack、Grafana、GitHub 已可作为 capability 接入，Grafana 侧需要 IRM；基础设施资源已打标签用于拓扑映射。不符合这三条的环境，先补可观测与标签，再谈自主处置。 回退方式做在事件与出口两层。第一层，把 Investigation Completed 的 EventBridge 规则禁用，三个下游目标（Jira 建单、Grafana IRM 电话、修复智能体）全部停下，Slack 频道里的调查通知保留为只读观察，on-call 回到人工流程。第二层，如果只想停修复，保留 Jira 与电话通知、把修复智能体的调用摘掉即可，两种回退都不需要改动被监控的服务本身。 最后一层兜底是草稿 PR 机制本身：修复永远不自动合并，因此即使整条流水线关掉也不需要回滚任何生产改动，只需要清理掉 CloudWatch Alarms、Lambda 函数、EventBridge 规则与 Agent Space 配置。 不适用这条方案的场景也说明白：如果客户的故障以应用代码缺陷为主而不是基础设施配置为主，这套只读调查加配置类草稿 PR 的组合收益会明显下降；如果客户还没有稳定的告警阈值与标签体系，先做可观测治理比先做自治划算。 原始来源： - https://aws.amazon.com/blogs/devops/how-property-finder-automated-incident-management-with-aws-devops-agent/ - https://aws.amazon.com/blogs/devops/building-an-end-to-end-agentic-sre-using-aws-devops-agent/ - https://aws.amazon.com/blogs/devops/automating-incident-investigation-with-aws-devops-agent-and-salesforce-mcp-server/ - https://docs.aws.amazon.com/devopsagent/latest/userguide/getting-started-with-aws-devops-agent.html - https://aws.amazon.com/devops-agent/ - https://aws.amazon.com/devops-agent/pricing/ - https://grafana.com/docs/grafana-cloud/alerting-and-irm/irm/