AWS DevOps Agent 接入实战：从可观测性集成到 MCP 扩展
前言
前文分析了传统 on-call 的五个结构性问题。本文进入实操环节——如何把亚马逊云科技的 DevOps Agent 接入你的环境，实现 AI 自动排障。
架构概览
DevOps Agent 的数据流分三层：
┌─────────────────────────────────────────────────┐
│ 告警触发层 │
│ CloudWatch Alarm / PagerDuty / ServiceNow │
└────────────────────┬────────────────────────────┘
▼
┌─────────────────────────────────────────────────┐
│ DevOps Agent 调查引擎 │
│ 告警关联 → 三维关联分析 → 根因定位 → 修复建议 │
└────┬──────────┬──────────┬──────────┬───────────┘
▼ ▼ ▼ ▼
┌─────────┐ ┌────────┐ ┌────────┐ ┌──────────┐
│可观测工具 │ │代码仓库 │ │CI/CD │ │MCP Server│
│CW/DD/SPK│ │GH/GL │ │流水线 │ │自定义扩展 │
└─────────┘ └────────┘ └────────┘ └──────────┘
第一步：开通 DevOps Agent
在亚马逊云科技控制台 CloudOps 分类下找到 DevOps Agent。按秒计费 $0.0083/agent-second，无预付要求。开通后获得 Agent workspace。
第二步：连接可观测性数据源
CloudWatch：同账号自动接入，零配置。
第三方工具需要配 API 凭证。以 Datadog 和 Splunk 为例：
# Datadog 集成
type: datadog
api_key: ${DATADOG_API_KEY}
app_key: ${DATADOG_APP_KEY}
site: datadoghq.com # 或 datadoghq.eu
# Splunk 集成
type: splunk
host: your-splunk-instance.splunkcloud.com
token: ${SPLUNK_HEC_TOKEN}
index: main
权限原则：只读即可。DevOps Agent 只需要 query metrics/logs/traces，不需要写权限。
完整支持列表：CloudWatch、Datadog、Dynatrace、Grafana、New Relic、Prometheus、Splunk。
第三步：连接代码仓库和 CI/CD
| 平台 | 接入方式 | Agent 获取的数据 |
|---|---|---|
| GitHub | GitHub App 授权 | commit、PR、部署事件、代码 diff |
| GitLab | Access Token | commit、MR、pipeline 事件 |
| Azure DevOps | Service Connection | commit、PR、release 事件 |
这一步是让 Agent 能把"什么时候部署了什么代码"和"什么时候开始告警"关联起来。缺了这个环节，Agent 只能看到"出了问题"，看不到"为什么出问题"。
第四步：配置告警路由
模式 A — ServiceNow 工单驱动（推荐已有 ITSM 流程的团队）：
CloudWatch Alarm → SNS → ServiceNow (创建 Incident)
↓
DevOps Agent 自动调查
↓
结果回写 Incident Work Notes
不改变现有告警路由，只在 ServiceNow 侧加了 AI 调查层。
模式 B — 直接触发：
CloudWatch Alarm → DevOps Agent 直接启动调查
PagerDuty Alert → DevOps Agent 直接启动调查
适合小团队或没有 ServiceNow 的场景。
第五步：配置协作通道
- Slack：调查结果推送到指定 channel，支持双向对话（追问、让 Agent 深入查某个方向）
- ServiceNow：结果自动回写 Work Notes
- PagerDuty：更新 Incident 状态和注释
Slack 集成体验很不错——不只是通知，是真正的对话式排障。
第六步：MCP Server 扩展
对于官方集成列表之外的工具——自研 CMDB、内部变更管理系统、自建 wiki 等——可以通过 MCP Server 接入。
from mcp import Server
server = Server("internal-cmdb")
@server.tool("get_service_dependencies")
async def get_deps(service_name: str):
"""查询服务依赖关系图谱"""
deps = await cmdb_client.get_dependency_tree(service_name)
return {
"service": service_name,
"upstream": deps.upstream,
"downstream": deps.downstream,
"infra": deps.infrastructure
}
@server.tool("get_recent_changes")
async def get_changes(service_name: str, hours: int = 24):
"""查询最近变更记录"""
changes = await change_mgmt.query_by_service(
service_name,
since_hours=hours
)
return {"changes": [c.to_dict() for c in changes]}
@server.tool("get_runbook")
async def get_runbook(service_name: str, issue_type: str):
"""获取服务对应的排障手册"""
doc = await wiki.search_runbook(service_name, issue_type)
return {"runbook": doc.content if doc else "No runbook found"}
MCP Server 部署在 VPC 内，通过 PrivateLink 与 DevOps Agent 通信。这样 Agent 排障时就能查你的内部依赖图、变更记录、甚至 runbook。
第七步：冷启动策略
刚接入时 Agent 没有你环境的历史调查数据。建议：
- 前两周主动复盘：挑最近 10 个有代表性的告警，手动让 Agent 做调查。快速积累不同类型的排障经验
- 观察学习循环：积累 30-50 次调查后，Agent 会开始复用之前学到的排障技能
- 校准期：前 10 次调查仔细验证 Agent 的根因判断是否准确，发现偏差及时反馈
安全最佳实践
| 维度 | 建议 |
|---|---|
| 凭证权限 | 所有集成凭证只给只读权限 |
| 网络 | MCP Server 在 VPC 内，PrivateLink 通信 |
| 审计 | 所有调查记录保留完整 audit trail |
| 修复执行 | 默认需人工批准，自动修复需显式开启 |
| 数据范围 | 按需授权 repo 和指标，不给全量访问 |
真实效果：United Airlines
- 规模：500+ AWS 账号，38,000 Dynatrace OneAgent，20,000 Lambda 函数
- 之前：多工具跨域排查有盲区，凌晨 3 点拉电话会议
- 之后：Dynatrace 检测 → DevOps Agent 调查 → 修复步骤直接推送 → 单一面板闭环
- United 首席工程师原话："不用再凌晨 3 点拉电话会议切换工具了，答案已经准备好了"
成本参考
| 团队规模 | 月调查次数 | 平均时长 | 月成本 |
|---|---|---|---|
| 小（5 服务） | 50 | 3 分钟 | ~$75 |
| 中（20 服务） | 200 | 5 分钟 | ~$500 |
| 大（100+ 服务） | 1000 | 5 分钟 | ~$2,500 |
AWS Support 集成：调查中一键升级，上下文自动带过去。Enterprise Support 客户每月有 DevOps Agent credits。
参考资料：
浙公网安备 33010602011771号