DevOps Agent 接入实操：手把手配置 AI 自动排障，从告警到修复方案
配 AI 值班员，不是装个软件那么简单
上一篇聊了 on-call 的痛点。这篇进入实操——怎么把亚马逊云科技的 DevOps Agent 接入你的环境，让它开始替你值班。
先说结论：接入本身不复杂，核心在于想清楚让它看到什么、对接什么、输出到哪。
接入前三个问题
- 可观测性工具是什么？ CloudWatch 肯定有，但大多数团队还有 Datadog / Splunk / Grafana / Prometheus / New Relic / Dynatrace
- 工单和协作工具是什么？ ServiceNow / PagerDuty / Slack
- 代码在哪？ GitHub / GitLab / Azure DevOps
这三类工具决定了 DevOps Agent 的数据输入、触发方式和结果输出。
七步接入流程
第一步：开通
DevOps Agent 在亚马逊云科技控制台的 CloudOps 下。按秒计费，$0.0083/agent-second。不需要预付，用多少算多少。
开通后得到一个 Agent workspace——所有配置都在这里面做。
第二步：连接可观测性工具
这步决定 Agent 能看到什么。看不到的东西它查不了。
CloudWatch 同账号自动接入。其他工具需要手动配置集成：
# 概念示意
integrations:
- type: datadog
api_key: ${DATADOG_API_KEY}
app_key: ${DATADOG_APP_KEY}
- type: splunk
host: your-splunk-instance.com
token: ${SPLUNK_HEC_TOKEN}
- type: grafana
url: https://your-grafana.com
api_key: ${GRAFANA_API_KEY}
- type: prometheus
endpoint: https://your-prometheus:9090
注意：给 Agent 的凭证只需只读权限。它只查看 metrics/logs/traces，不需要写。
第三步：连接代码仓库
Agent 需要看到代码变更和部署时间线，才能把告警关联到具体的 commit。
支持 GitHub（GitHub App 授权）、GitLab（Access Token）、Azure DevOps（Service Connection）。
接入后它能看到：最近的 commit 和 PR、部署时间线、代码 diff。这些信息让它在排查时能直接说出"这个问题是今天下午 3 点那次部署引入的，具体在 commit abc123 的第 47 行"。
第四步：配置告警路由
两种模式：
模式一：ServiceNow 工单触发
告警 → ServiceNow 创建 Incident → DevOps Agent 自动调查 → 结果回写工单
适合已有 ITSM 流程的团队。不改变现有告警路由，只在 ServiceNow 环节加一层 AI 调查。
模式二：直接告警触发
CloudWatch Alarm / PagerDuty → DevOps Agent 直接启动调查
更轻量，适合小团队或没有 ServiceNow 的场景。
第五步：配置输出通道
Agent 调查完要推给人审。支持三个通道：
- Slack：推到指定 channel，团队可以在 Slack 里追问。这个最灵活——不是单向推送，是可以对话的
- ServiceNow：结果写到 Incident 的 Work Notes
- PagerDuty：更新 Incident 状态
Slack 集成体验最好。你在 channel 里看到调查报告，觉得某个方向需要深入，直接 @ Agent 让它继续查。
第六步：MCP 扩展（进阶）
如果有内部工具不在官方集成列表——比如自研 CMDB、内部 wiki、自建部署系统——可以通过 MCP Server 接入。
MCP（Model Context Protocol）让 Agent 调用你的私有数据源。
from mcp import Server
server = Server(\"internal-cmdb\")
@server.tool(\"get_service_dependencies\")
async def get_deps(service_name: str):
\"\"\"查询服务依赖关系\"\"\"
deps = await cmdb_client.query_dependencies(service_name)
return {\"dependencies\": deps}
@server.tool(\"get_recent_changes\")
async def get_changes(service_name: str, hours: int = 24):
\"\"\"查询最近的变更记录\"\"\"
changes = await change_mgmt.query(service_name, hours)
return {\"changes\": changes}
这意味着 Agent 的能力边界不限于官方工具列表。任何能暴露 MCP 接口的系统都能成为数据源。
第七步：学习循环冷启动
刚接入时 Agent 没有你环境的历史调查数据。前几周是冷启动期：
- 每次调查完自动学习排障路径
- 积累几十次后学习循环开始发挥作用
- 类似场景再出现会复用已学到的排障技能
建议：冷启动期主动发起"练习赛"——挑最近的告警让 Agent 复盘，快速积累经验。不要只等自动触发。
实际效果参考
United Airlines 的数据：
- 每天 50 万旅客
- 38,000 个 Dynatrace OneAgent 监控混合云
- 500+ AWS 账号，20,000 个 Lambda 函数
接入前：多工具跨域排查有盲区，凌晨还要拉会切工具。 接入后：Dynatrace 检测问题 → 定位应用层 → DevOps Agent 深入调查出修复方案 → 单一面板搞定。
安全注意事项
- 最小权限：集成凭证只给只读
- 网络隔离：MCP Server 部署在 VPC 内，PrivateLink 连接
- 审计：所有调查记录有完整 audit trail
- 修复审批：Agent 只给建议，执行需人批准（除非开启自动修复）
成本估算
| 场景 | 月调查次数 | 每次时长 | 月成本 |
|---|---|---|---|
| 小团队（5 服务） | 50 | 3 min | ~$75 |
| 中等（20 服务） | 200 | 5 min | ~$500 |
| 大规模（100+ 服务） | 1000 | 5 min | ~$2,500 |
对比 SRE 的人力成本，怎么算都划算。
我的建议
- 先小范围试：挑一两个最常出问题的服务接入，验证效果
- 从 Slack 开始：Slack 集成成本低，团队适应快
- 不急着开自动修复：先跑几周"只建议不执行"模式，建立信任
- 重视冷启动：前两周每天喂几个历史告警让它学
工具本身不难配，难的是让团队信任它。先让它在小范围证明价值，再逐步扩大。
参考：
