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 同账号自动接入。其他工具需要手动配置集成：

yaml 复制代码

# 概念示意
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 调用你的私有数据源。

python 复制代码

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 集成成本低，团队适应快
不急着开自动修复：先跑几周"只建议不执行"模式，建立信任
重视冷启动：前两周每天喂几个历史告警让它学

工具本身不难配，难的是让团队信任它。先让它在小范围证明价值，再逐步扩大。

参考：