凌晨三点被告警轰炸?用 AWS DevOps Agent 让 AI 自动帮你查故障根因

半夜三点,PagerDuty 疯响,CloudWatch 连续 12 条告警。你爬起来翻 CloudWatch 指标、查 CloudTrail 记录、看 VPC Flow Logs、对比 Config 变更……折腾两小时,发现是个 SSM Session 里有人跑了个吃 CPU 的脚本。

这种事干多了真的会秃。

今天聊一个刚 GA 的服务——AWS DevOps Agent。说白了就是一个 AI 驱动的运维代理,告警来了它自己查、自己分析、自己出报告,你醒来看结论就行。

这东西到底干嘛的

AWS DevOps Agent 2025 年 12 月在 re:Invent 发的预览版,2026 年 3 月底正式 GA。核心能力一句话概括:接收告警 → 自动跨服务关联数据 → 输出根因分析报告

具体来说它能做这些:

自动构建应用拓扑——不需要你预先告诉它有哪些服务,Agent 自己调 AWS API 把你账户里的资源关系画出来。EC2、RDS、EKS、Lambda、ALB 之间谁依赖谁,它自己搞定。

AI 自主调查——告警来了之后,Agent 自己决定先查什么再查什么。不需要你写 runbook,它会自动去翻 CloudWatch 指标、CloudTrail 操作记录、代码仓库、CI/CD 流水线、部署历史。

深度根因分析——不只是告诉你"CPU 高了",而是追到"为什么高"。比如:CPU 飙升 → 分析进程行为 → 追踪到某个 SSM 会话里的异常工作负载 → 建议升级实例类型。

结构化输出——调查结果用 Markdown 格式保存,包含症状(Symptom)、发现(Finding)、观测数据(Observation)、调查缺口(Gap)和最终摘要(Summary),能直接归桥审计。

三种触发方式

Agent 支持三种方式启动调查:

方式 模式 适用场景
Backlog Task 异步,Agent 自主调查完通过 EventBridge 通知 自动化运维流水线、CloudWatch 告警触发
Chat API 同步流式响应,支持多轮对话 交互式排查、On-Call 实时问答
Webhook 第三方 POST 到 webhook URL 对接 PagerDuty、Datadog、Grafana 等

GA 版还支持了 Azure 和本地基础设施(通过 MCP 协议),这意味着它不只是 AWS 单云工具,而是在往统一运维中枢的方向走。

实战:EC2 CPU 告警自动调查 + 飞书通知

下面用一个真实 Demo 演示完整链路。场景很简单:EC2 的 CPU 飙了,Agent 自动查根因,查完发飞书通知。

架构

整个数据流 8 步走:

  1. EC2 CPU 飙升(stress --cpu 4 模拟)
  2. CloudWatch Alarm 触发(CPU > 80% 持续 2 个周期)
  3. EventBridge Rule-1 匹配告警事件
  4. Lambda-A 调用 create_backlog_task 创建调查任务
  5. DevOps Agent 自主调查(5~15 分钟)
  6. 调查完成,Agent 发布 Investigation Completed 事件
  7. EventBridge Rule-2 触发 Lambda-B
  8. Lambda-B 获取调查摘要,发飞书通知

核心就是两个 Lambda + 两条 EventBridge 规则,Serverless 全托管。

Lambda-A:触发调查

收到 CloudWatch Alarm 事件后,提取告警信息,调用 DevOps Agent API:

import json, os, boto3

DEVOPS_AGENT_SPACE_ID = os.environ["DEVOPS_AGENT_SPACE_ID"]

def lambda_handler(event, context):
    detail = event.get("detail", {})
    # 只在 ALARM 状态时触发
    if detail.get("state", {}).get("value") != "ALARM":
        return {"statusCode": 200, "body": "Skipped"}

    alarm_name = detail.get("alarmName", "Unknown")
    reason = detail.get("state", {}).get("reason", "N/A")
    # 提取 EC2 实例 ID
    metrics = detail.get("configuration", {}).get("metrics", [])
    instance_id = ""
    if metrics:
        dims = metrics[0].get("metricStat", {}).get("metric", {}).get("dimensions", {})
        instance_id = dims.get("InstanceId", "")

    client = boto3.client("devops-agent", region_name="us-west-2")
    response = client.create_backlog_task(
        agentSpaceId=DEVOPS_AGENT_SPACE_ID,
        taskType="INVESTIGATION",
        title=f"Investigate: {alarm_name} - {instance_id}",
        priority="HIGH",
        description=f"CloudWatch Alarm '{alarm_name}' triggered.\n"
                    f"EC2 Instance: {instance_id}\nReason: {reason}",
    )
    task = response["task"]
    return {"statusCode": 200, "body": json.dumps({
        "taskId": task["taskId"],
        "executionId": task["executionId"],
        "status": task["status"],  # PENDING_START
    })}

踩坑提醒:Lambda 运行时内置的 boto3 不包含 devops-agent 服务,必须通过 Layer 提供新版 boto3。这个坑了我半小时。

Lambda-B:获取结果 + 通知

调查完成后,从 Journal Records 里取摘要:

def get_investigation_summary(agent_space_id, execution_id):
    client = boto3.client("devops-agent", region_name="us-west-2")
    response = client.list_journal_records(
        agentSpaceId=agent_space_id,
        executionId=execution_id,
    )
    for record in response.get("records", []):
        # investigation_summary_md 是 Markdown 格式的完整摘要
        if record.get("recordType") == "investigation_summary_md":
            return record.get("content", "")
    return "No summary available."

Journal Records 有好几种类型:symptom(症状)、finding(发现)、observation(观测数据)、investigation_gap(信息缺口)、investigation_summary_md(Markdown 完整摘要)。通知场景直接取 investigation_summary_md 就够了。

EventBridge 规则

两条规则,一条接告警,一条接调查完成:

# Rule-1:CloudWatch Alarm → Lambda-A
aws events put-rule --name "DevOps-Agent-Alarm-Trigger" \
  --event-pattern '{
    "source": ["aws.cloudwatch"],
    "detail-type": ["CloudWatch Alarm State Change"],
    "detail": { "alarmName": ["DevOps-Agent-Demo-CPU-High"] }
  }'

# Rule-2:Investigation Completed → Lambda-B
aws events put-rule --name "DevOps-Agent-Investigation-Done" \
  --event-pattern '{
    "source": ["aws.aidevops"],
    "detail-type": ["Investigation Completed"]
  }'

注意事件源是 aws.aidevops,不是 aws.devops-agent——IAM action 前缀也是 aidevops

进阶:Chat API 做交互式排查

Backlog Task 是异步的,适合自动化流水线。如果你想做交互式排查——比如集成到企业内部的运维平台或者聊天工具里——可以用 Chat API:

client = boto3.client("devops-agent", region_name="us-west-2")
# 创建聊天会话
chat = client.create_chat(
    agentSpaceId="<SPACE_ID>",
    userId="my-user", userType="IAM",
)
execution_id = chat["executionId"]

# 发消息,流式返回
response = client.send_message(
    agentSpaceId="<SPACE_ID>",
    executionId=execution_id,
    content="What EC2 instances are running?",
    userId="my-user",
)
for event in response["events"]:
    if "contentBlockDelta" in event:
        text = event["contentBlockDelta"].get("delta", {}).get("textDelta", {}).get("text", "")
        if text:
            print(text, end="", flush=True)

多轮对话用同一个 executionId,Agent 会记住上下文。第一轮问"列出所有运行中的 EC2",第二轮追问"哪个 CPU 占用高",它知道你在说之前列出的那些实例。

第三方集成:不只是 AWS 的事

GA 版原生支持一堆第三方工具:

  • 可观测性:Datadog、Dynatrace、New Relic、Splunk、Grafana
  • 事件管理:PagerDuty、ServiceNow
  • 代码/CI-CD:GitHub、GitLab、Azure DevOps
  • 通知:Slack
  • 自定义:通过 MCP 协议对接任何工具

这意味着你不需要把所有监控都搬到 CloudWatch——已有的 Datadog 告警可以直接通过 Webhook 喂给 Agent,Agent 调查时也会去去去去去 Datadog 拉数据做关联分析。

安全方面,Agent 通过 IAM 角色(服务主体 aidevops.amazonaws.com)调用 API,所有操作 CloudTrail 可审计。调查记录持久保存,审计合规没问题。

我的判断

DevOps Agent 代表的方向是对的——运维从"人驱动、规则执行"往"AI 驱动、人审核"走。但目前有几个现实问题:

  1. 调查耗时 5~15 分钟——对 P0 故障来说还是偏长,紧急场景还得靠人先顶上
  2. 需要新版 boto3——Lambda 内置版本不支持,多了一个 Layer 依赖要维护
  3. IAM 权限要给够——Agent 需要 CloudWatch、CloudTrail、EC2、Config 等多个服务的读权限

但优势也很明显:跨服务关联这件事,人工做极其痛苦,Agent 可以在几分钟内扫完你手动翻一小时的数据量。特别是凌晨告警场景,先让 Agent 跑完调查,你醒来看报告决定要不要介入,效率差别是真实的。

参考

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐