传统 on-call 的 5 个致命问题——从人肉值班到 AI Agent 自动排障
引子
凌晨三点被 PagerDuty 叫醒。打开 CloudWatch，20 多条告警。翻了 40 分钟发现其中 15 条来自同一个 DynamoDB 限流。修复本身只花了 5 分钟。
on-call 的核心痛苦不是技术难度，是重复劳动和信息过载。亚马逊云科技最近推出的 DevOps Agent 正是针对这些痛点设计的。本文展开聊聊传统 on-call 的 5 个致命问题，以及 AI 运维的破局思路。
一、告警风暴：信噪比极低
一个 DynamoDB 写入限流能触发：Lambda 超时 → API Gateway 5xx → SNS 投递失败 → 前端健康检查红灯。十几条告警，本质是同一件事。
传统应对方案是告警聚合规则。问题在于：规则是死的，架构是活的。每次变更都要手动更新依赖图谱，维护成本极高。
DevOps Agent 的解法是 自动告警关联（Alarm Correlation）——通过分析告警的时间序列和因果关系，自动识别同源告警，无需手写规则。本质上是用 AI 替代了人工维护的"告警依赖图"。
二、MTTR 被定位环节拖长
修复时间通常几分钟，但定位根因经常要几十分钟甚至数小时。需要翻日志、查 metrics、看最近的部署记录、对比代码变更。
DevOps Agent 同时接入可观测工具（CloudWatch / Datadog / Splunk / New Relic / Grafana / Prometheus）、代码仓库和 CI/CD 流水线，做三维关联分析：
| 故障类型 | 具体场景 | Agent 定位路径 | 建议 |
|---|---|---|---|
| 代码变更 | 新部署引入低效 DynamoDB 查询 | commit diff + 限流时间线 | 回滚 |
| 代码变更 | 部署后 SNS 消息结构超限 | 消息体变更 + size error | 加消息校验 |
| 流量异常 | 突增流量打满 Lambda 并发 | 并发指标 + 流量曲线 | 调高 concurrency |
| 资源上限 | API 调用超过 rate limit | throttling 指标 | 提高限额 |
| 组件故障 | 冷启动延迟导致性能退化 | P99 延迟 + 冷启动比例 | Provisioned Concurrency |
从告警到根因到修复建议，几分钟内完成。对比传统 on-call，MTTR 从"小时级"降到"分钟级"。
三、团队知识断层
老运维走了，排障经验跟着走了。Runbook 写了一堆但半年没更新，跟实际架构对不上。新人出了问题不知道从哪开始查。
DevOps Agent 有 学习循环（Learned Investigation Skills） 机制：
- 每次调查完成后，自动提取排障路径
- 形成可复用的"调查技能"
- 下次类似事件时自动应用
这比 Runbook 可靠得多——Runbook 需要人维护，DevOps Agent 的知识库是自动更新的。
四、只灭火不防火
传统 on-call 是纯被动响应。谁来做"为什么这类故障反复出现"的深度分析？
DevOps Agent 的 主动预防（Proactive Prevention） 功能从四个维度给出改进建议：
- 可观测性：检测盲区、告警调优
- 基础设施：资源配置不合理的点
- 部署流水线：测试覆盖的盲区
- 应用韧性：架构薄弱环节
每条建议附带 agent-ready specs，可以直接交给 Kiro 等编码 Agent 去实现。形成"发现问题 → 分析模式 → 生成方案 → 自动修复"的闭环。
五、跨平台排障，工具链割裂
现实中很少有纯亚马逊云科技环境。Datadog 看监控、Splunk 查日志、Grafana 看 dashboard、ServiceNow 管工单——出了事要在五六个工具间跳转。
DevOps Agent 内置了这些集成，一个 Agent 拉通所有数据源做关联分析：
- 可观测性：CloudWatch、Dynatrace、Datadog、New Relic、Splunk、Grafana、Prometheus
- 协作：ServiceNow（自动创建/更新工单）、Slack（团队对话）
- 代码：代码仓库、CI/CD 流水线
还可以通过自定义连接器接入其他工具。
成本
按秒计费：$0.0083/agent-second。一次 5 分钟调查约 $2.5。
调查中可一键升级到 AWS Support，所有上下文（根因分析、telemetry 关联、修复方案）自动带过去，不用手动写 case 描述。
本质
DevOps Agent 不是替代 SRE，而是把 on-call 的模式从"人肉值班"变成"AI 调查 + 人审批执行"。
on-call 的核心痛苦——重复劳动、信息过载、知识断层——恰好是 AI 擅长处理的。决策权仍在人手里，但人不用再做数据搬运工了。
参考资料：
浙公网安备 33010602011771号