凌晨1点生产服务CPU突然飙升，传统流程需要工程师在多个工具间找线索。Property Finder把告警、根因分析、工单、电话通知和修复草案连成自动化链路，在一次公开案例中，从告警到修复草案缩短至14分钟。

9月28日，AWS披露中东和北非房产平台Property Finder使用AWS DevOps Agent改造故障管理的实践。该平台面向五个市场、服务数百万找房用户，生产故障会直接影响搜索、房源更新和业务收入。此前非关键问题的平均解决时间可能延伸至2至3天，工程师还要花20至40分钟手工关联不同工具中的指标。

四个子智能体同时寻找根因

新的流程以Amazon CloudWatch告警作为入口。当ECS服务CPU持续超过设定阈值时，Lambda补充服务元数据，用HMAC-SHA256对请求签名，再把事件发送给智能体。随后四个并行子智能体分别查询ECS指标、CloudTrail、应用负载均衡流量以及Grafana中的Prometheus、Loki和Pyroscope遥测，并读取GitHub中的相关源代码。

调查进度实时发布到团队协作频道。分析完成后，EventBridge触发三个并行出口：创建包含根因和影响范围的Jira工单；通过Grafana IRM向值班工程师发出带上下文的电话通知；调用独立的修复智能体生成代码或Terraform修改，并创建草稿拉取请求。

一次CPU故障暴露两个扩缩容策略冲突

在AWS公开的案例中，核心搜索微服务CPU达到99.11%。智能体发现，CPU目标跟踪策略设为70%，内存策略设为75%，但实际内存占用仅3%至8%。两个策略持续产生相反的扩缩容信号，加上最低容量设置不足，导致22次以上的反复切换，服务实际上被限制在两个任务实例。

告警在1时21分触发，1时32分根因被识别，1时33分工单建立，1时34分值班电话发出，1时35分修复草案进入代码仓库。AWS称，智能体约10分钟完成根因分析，完整链路用时14分钟。

调查只读，修复必须由人合并

该方案没有让同一个智能体直接修改生产基础设施。AWS DevOps Agent的调查会话保持只读权限；独立的修复智能体仅能通过GitHub MCP访问指定仓库，使用有范围和到期时间的细粒度凭据。它只能创建草稿拉取请求，不能自动合并。

工程师仍需检查修改、运行Terraform计划、在预发布环境验证后再决定是否上线。这种职责分离把“快速生成修复建议”和“批准生产变更”分开，降低单个智能体权限过大带来的风险。

编辑观察：自动化的价值在于缩短找证据的时间

这项案例最值得借鉴的，不是14分钟这一单一数字，而是把监控、日志、代码、工单和通知纳入同一条有记录的事件链。智能体承担证据收集、关联分析和文档生成，人类保留变更决定权。

相关结果来自Property Finder的具体架构和一次公开故障案例，不能直接外推到所有企业。每次事件还会调用两个智能体会话和最多四个子智能体，企业应同步评估调用费用、误报、访问权限和日志保留。

更稳妥的落地路径，是先让AI执行只读调查和工单整理，建立命中率与误判率基线，再逐步开放生成修复草案。任何生产变更都应保留审批、测试、回滚和审计记录。

配图为AIcent原创AI生成实景风格示意图，非官方新闻现场照片，不使用第三方新闻图片。

参考来源：AWS官方DevOps博客（2026年9月28日）。正文为基于官方消息的中文整理，编辑观察与事实披露分开呈现。