亚马逊AWS官方博客
基于 AWS DevOps Agent 构建 AI 驱动的运维分析系统
摘要:随着企业在 AWS 上的工作负载日益复杂——EC2 集群、RDS 数据库、ECS/EKS 容器、Lambda 函数、网络与负载均衡等多种服务交织运行——运维团队面临严峻挑战。AWS DevOps Agent 正是为解决这些运维痛点而生。它是一个 AI 驱动的自主运维代理,能够自动接收来自任何 AWS 服务的告警、跨服务关联数据(CloudWatch 指标、CloudTrail 事件、AWS Config 变更、VPC 网络日志等)、执行深度根因分析,并生成结构化的调查报告——整个过程无需人工干预。
目录
1. 背景与痛点
随着企业在 AWS 上的工作负载日益复杂——EC2 集群、RDS 数据库、ECS/EKS 容器、Lambda 函数、网络与负载均衡等多种服务交织运行——运维团队面临严峻挑战:
- 告警爆炸:CloudWatch、第三方监控(Datadog、PagerDuty、Grafana 等)每天产生数百条告警,涉及 CPU、内存、磁盘、网络、错误率等数十种指标,运维团队疲于应对
- 跨服务关联困难:一个故障追溯可能需要人工从 CloudWatch 指标、CloudTrail 操作记录、VPC Flow Logs、Config 变更中逐一关联,效率极低
- 响应延迟:从告警触发到定位根因,往往需要 30 分钟到数小时,甚至更久。对于生产环境的 P1 故障,每分钟的延误都意味着业务损失
- 知识难以沉淀:资深工程师的排查经验分散在个人脑海和零散的 runbook 中,团队扩张时知识传递成本高
- 多环境多区域管理:跨 Region、跨账户的故障排查更加复杂,单靠人工难以全面覆盖
AWS DevOps Agent 正是为解决这些运维痛点而生。它是一个 AI 驱动的自主运维代理,能够自动接收来自任何 AWS 服务的告警、跨服务关联数据(CloudWatch 指标、CloudTrail 事件、AWS Config 变更、VPC 网络日志等)、执行深度根因分析,并生成结构化的调查报告——整个过程无需人工干预。
2. AWS DevOps Agent 产品介绍
AWS DevOps Agent 于 2025 年 12 月 re:Invent 大会发布公开预览版(Public Preview),并于 2026 年 3 月 31 日正式 GA。它是一款 AI 驱动的自主运维服务,内置了对 AWS 全栈服务的深度理解,能够像一位资深 SRE 工程师一样,自动接收告警、主动收集证据、跨服务关联分析,并输出结构化的根因分析报告。GA 版本还新增了对 Azure 云环境和本地基础设施的支持。
2.1 核心能力
- 全栈服务分析 — Agent 自动构建应用拓扑(Application Topology),动态发现并映射 AWS 账户中的资源及其依赖关系。无需预先指定服务列表,Agent 能自动调用相关 AWS API 收集指标、日志和配置信息。GA 版本还支持 Azure 和本地环境(通过 MCP)
- AI 自主调查 — 接收告警后 Agent 自主决定调查策略——先查什么、再查什么、如何关联——无需预定义 runbook。调查范围涵盖 CloudWatch 指标与日志、CloudTrail 操作记录、代码仓库、CI/CD 流水线数据、部署历史等
- 深度根因分析 — 不仅识别”发生了什么”,更能分析”为什么发生”——从表面症状追溯到根因,给出修复建议。例如:CPU 飙升 → 分析进程行为 → 追踪到 SSM 会话中的异常工作负载 → 建议升级实例类型
- 结构化输出 — 调查结果以 Markdown 格式的 Journal Records 保存,包含症状(Symptom)、发现(Finding)、观测数据(Observation)、调查缺口(Gap)和最终摘要(Summary),便于归档和审计
- 事件驱动集成 — 调查生命周期通过 EventBridge 发布事件(Investigation Created / Priority Updated / In Progress / Completed / Failed、Mitigation In Progress / Cancelled),可与任何下游系统无缝对接
- 丰富的第三方集成 — 原生支持 Datadog、Dynatrace、New Relic、Splunk、Grafana(可观测性)、PagerDuty、ServiceNow(事件管理)、GitHub、GitLab、Azure DevOps(代码/CI-CD)、Slack(通知)。还可通过 MCP 协议对接自定义工具
- 安全与合规 — Agent 通过 IAM 角色(服务主体
aidevops.amazonaws.com)调用 AWS API,所有操作可通过 CloudTrail 审计;调查记录持久保存,满足合规要求
2.2 多种触发方式
- Backlog Task(
create_backlog_task)— 异步模式,Agent 自主调查,通过 EventBridge 通知完成。适用于自动化运维流水线、CloudWatch / 自定义告警触发 - Chat(
create_chat+send_message)— 同步流式响应,支持多轮对话,Agent 实时调用 AWS API。适用于交互式排查、实时问答、On-Call 辅助 - Webhook(第三方 POST 到 webhook URL)— Agent 自动接收并智能判断是否需要调查。适用于对接 PagerDuty、Datadog、Grafana、GitLab 等
[图1] |
3. Demo 方案架构
本文以 EC2 CPU 告警 作为演示场景,展示完整的事件驱动架构。同一架构模式可直接适用于上述所有场景——只需调整 EventBridge Rule 的事件匹配模式和 Lambda-A 中的告警解析逻辑即可。该架构具有通用性——将 CloudWatch Alarm 替换为任意 AWS 服务的告警源(RDS、Lambda、ECS 等),即可复用同一套事件驱动流水线。
3.1 架构图
[图2] |
3.2 数据流(8 步)
- EC2 CPU 飙升 —
stress --cpu 4模拟高负载 - CloudWatch Alarm 触发 — CPU > 80% 持续 2 个评估周期,状态 OK → ALARM
- EventBridge Rule-1 匹配 — 捕获
aws.cloudwatch/CloudWatch Alarm State Change事件 - Lambda-A 触发调查 — 调用
create_backlog_task(taskType='INVESTIGATION') - DevOps Agent 自主调查 — 分析 CloudWatch 指标、CloudTrail 事件、EC2 配置(5~15 分钟)
- 调查完成事件 — DevOps Agent 发布
aws.aidevops/Investigation Completed事件 - Lambda-B 获取结果 — 调用
list_journal_records(),提取investigation_summary_md记录 - 飞书通知 — 将 Markdown 格式的调查摘要发送到飞书群
3.3 Investigation Completed 事件格式
当调查完成时,DevOps Agent 自动向 EventBridge 默认总线发布以下事件:
ℹ️ 注意:
事件源是 aws.aidevops(不是 aws.devops-agent),IAM action 前缀也是 aidevops。
4. 部署步骤
4.1 环境变量配置
4.2 IAM 角色与权限
创建 Lambda 执行角色,并添加 DevOps Agent 权限:
4.3 Lambda Layer(最新 boto3)
⚠️ 重要:
Lambda 运行时内置的 boto3 不包含 devops-agent 服务,必须通过 Layer 提供最新版本。
4.4 部署两个 Lambda 函数
Lambda-A(触发调查):
Lambda-A 关键代码:收到 CloudWatch Alarm 事件后,提取告警详情并调用 DevOps Agent API 创建调查任务。
Lambda-B(获取结果 + 飞书通知):
Lambda-B 关键代码:收到 Investigation Completed 事件后,调用 list_journal_records 获取调查摘要:
要点:list_journal_records 返回多种类型的记录,其中 investigation_summary_md 是 Markdown 格式的完整调查摘要,可直接用于通知展示。
4.5 Journal Record 类型一览
investigation_summary_md— 完整调查摘要(Markdown 格式)investigation_summary— 结构化调查摘要(JSON 格式)symptom— 发现的症状finding— 调查发现(含根因)observation— 观测数据investigation_gap— 调查中的信息缺口message— Agent 的对话消息
4.5 EventBridge 规则
Rule-1:CloudWatch Alarm → Lambda-A
Rule-2:Investigation Completed → Lambda-B
5. 进阶:Chat API 实时对话
除了异步的 Backlog Task 方式,DevOps Agent 还提供 Chat API,支持实时对话式交互。企业可以基于此功能,将 AWS Devops Agent的能力集成至企业自己的运维系统或者通讯工具(如feishu/lark)中。
5.1 基本用法
5.2 EventStream 事件类型
send_message 返回的是一个流式 EventStream,包含以下事件类型:
responseCreated— 响应开始responseInProgress— Agent 正在处理contentBlockStart— 新的内容块开始(文本或工具调用)contentBlockDelta— 增量内容:textDelta(文本)或jsonDelta(工具调用/结果)contentBlockStop— 内容块结束heartbeat— 长时间操作的保活信号responseCompleted— 响应完成responseFailed— 发生错误
5.3 多轮对话与上下文保持
使用相同的 executionId 可以进行多轮对话,Agent 会保持上下文:
6. 总结
AWS DevOps Agent 代表了云运维领域的一个重要趋势:从被动响应走向主动治愈。本文演示的是”告警 → 调查 → 通知”这一闭环的第一步,而可以预见的演进方向远不止于此。
在自动修复层面,Agent 未来不仅能给出修复建议,还能在人工审批后(或在预设策略下自动地)直接执行修复操作——扩容实例、回滚部署、调整安全组规则——从”告诉你怎么修”进化到”帮你修好”。在预测性运维层面,随着调查记录的持续积累,Agent 对特定业务环境的理解会越来越深入,结合历史数据和趋势分析,它将能够在故障真正发生之前识别风险并预警,把运维模式从”事后灭火”推进到”事前预防”。在覆盖范围层面,GA 版本已经支持 Azure 和本地环境的接入,Agent 正在从 AWS 单云工具演进为跨云、跨本地的统一智能运维中枢。
AI Agent 在运维场景的应用,不是对现有监控工具的简单替代,而是一次范式升级。 它将运维从”人驱动、规则执行”的模式,推进到”AI 驱动、人审核”的新阶段。对于正在管理复杂云环境的团队来说,现在正是拥抱这一变革的最佳时机——从一个 EC2 告警的 Demo 开始,构建属于自己的智能运维体系。
➡️ 下一步行动:
相关产品:
- AWS Lambda — 无需服务器即可运行代码
- Amazon DevOps Agent — 解决和预防事故的代理
- Amazon CloudWatch — 可观测性工具
- Amazon EC2 — 安全且可调整大小的计算容量
- Amazon EventBridge — 大规模构建事件驱动应用程序
相关文章:
- AWS DevOps Agent 与 GitHub 集成实践:如何实现从代码变更到故障调查的端到端闭环
- AWS DevOps Agent 可帮助您加快事件响应并提高系统可靠性(预览版)
- AWS 每周综述:AWS DevOps 代理和安全代理正式发布、产品生命周期更新等(2026 年 4 月 6 日)
- 简化故障注入,读懂应用影响:用 AI Agent 做混沌工程
- 用 Hermes Agent 在 AWS 上搭建投研助手
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。



