上周三凌晨两点我被一个 EKS 集群的告警叫醒。Pod 在 CrashLoopBackOffCloudWatch 一片红。我迷迷糊糊打开笔记本正准备 kubectl describe 的时候突然想起来——等等我不是接了 AWS DevOps Agent 吗打开控制台一看Agent 已经在跑了。从告警触发到它给出根因分析总共花了不到4分钟。一个 ConfigMap 被人误删了Agent 通过审计日志追溯到了具体的操作人和时间戳还给出了修复方案。我愣了一下把手机调成了静音翻身继续睡。这玩意到底是什么AWS DevOps Agent 今年3月底 GA 了。官方定位是永远在线的运维队友——不只是监控告警那一套它能自主调查事件、做根因分析、甚至给出修复计划。说白了就是一个 AI SRE。但跟之前那些 AIOps 工具不一样的是这货不只是给你推荐可能的原因然后让你自己去查。它是真的会动手——当然是在你设定的权限范围内。架构上它是个多 Agent 系统。一个 Lead Agent 充当事件指挥官理解症状、制定调查计划然后把具体的任务分派给专门的子 Agent。有点像一个老练的值班长带着几个新人在干活值班长负责拿主意新人负责跑腿查数据。接入过程我的环境是一套跑在 us-east-1 的 EKS 集群大概二十几个微服务监控用的 CloudWatch PrometheusCI/CD 是 GitLab。接入过程比我预想的简单。在控制台创建一个 Agent Space然后一步步把数据源接进去1. CloudWatchMetrics Logs 2. EKS 集群访问read-only kubectl 3. GitLab 代码仓库 4. Slack 通知通道EKS 的接入需要注意一点Agent 是通过 read-only 的 kubectl 权限来查集群的不管是 public 还是 private endpoint 的集群都支持。你可以把多个集群接到同一个 Agent Space 里。代码仓库的接入是 GA 后新加的功能——Agent 会索引你的代码库在调查的时候能理解代码结构甚至定位到具体哪行代码可能有 bug。整个接入大概花了我一个小时。大部分时间是在配 IAM Role 和确认权限——是的AWS 的老传统了。第一次被惊到接好第二天一个服务的响应时间突然飙到了平时的5倍。告警一触发Agent 就自动开始调查了。我在 Slack 里收到了它的实时汇报。它做了这些事先查 CloudWatch 指标确认异常范围然后去 EKS 里看 Pod 状态、Node 资源使用对比了最近24小时的部署记录翻了 GitLab 里最近的 commit最后关联了一个40分钟前的部署变更结论最近一次部署把一个数据库连接池的参数从20改成了5一个 PR review 没注意的配置变更导致在高并发时连接排队。从告警到给出根因6分钟。我承认如果是我自己查大概率也能定位到但可能得花二三十分钟。而且凌晨的状态下大脑转速是真的慢Agent 没有这个问题。日常使用On-Demand SRE 模式除了自动响应告警它还有一个 On-Demand 模式就像一个随时在线的 SRE 同事。你可以用自然语言问它问题“过去一周哪个服务的错误率增长最快”“上次部署之后 P99 延迟有变化吗”“帮我画一个最近30天的 Pod 重启趋势图”它能直接生成图表还能保存分享给团队。这个功能我用得特别多以前写周报整理指标都得自己翻 Grafana 截图现在直接让它出。真正有意思的MCP 扩展Agent 有个能力边界——它能看 CloudWatch 和 EKS 的 Kubernetes 对象但看不到节点操作系统层面的东西。iptables 规则、CNI 配置、dmesg 内核消息、containerd 日志……这些东西在节点上。6月11号 AWS 官方出了一篇博客讲怎么用 MCPModel Context Protocol扩展 Agent 的能力边界。大意是你可以自己写一个 MCP Server把节点级别的诊断数据暴露给 Agent。思路很巧妙Agent 调用 collect 工具 → MCP Server 触发 SSM Automation → 目标节点执行日志收集 → 打包上传 S3 → 预处理索引错误分类 严重程度标记→ Agent 通过后续工具读取分析核心设计原则有三条返回结构化数据不是原始文本——带严重等级和 finding ID永远不给 Agent 一个 shell——所有操作通过 SSM Automation 中转工具输出可组合——一个工具的输出能作为下一个工具的输入这个 MCP Server 能让 Agent 访问20多种节点级日志源。博客里演示了一个场景Pod 状态是 Running 但 DNS 解析失败kubectl 看着一切正常问题藏在节点的 iptables 规则里。Agent 通过 MCP 拿到 iptables 数据后直接定位了被注入的阻断规则。这种 kubectl 看不出来的问题恰恰是生产环境里最头疼的那种。实际效果数据官方给的数据是preview 用户平均 MTTR 降低75%调查速度提升80%根因准确率94%。我自己这一周的体感一共触发了7次告警其中2次是误报它自己识别出来了5次真实问题里有4次它独立完成了调查给出了准确的根因有1次涉及跨服务的级联故障它定位了直接原因但没追到根本原因最后还是需要人工介入On-Demand 问答用了十几次体验像是有个一直在线的、记得住你整个架构的同事坦率讲它不是万能的。遇到那种涉及业务逻辑的 bug或者几个月前埋下的设计缺陷它分析不出来。它擅长的是基础设施层面的、有清晰遥测数据支撑的、运维操作类的问题。一些坑和注意事项费用这个不便宜按调查次数和 Agent 运行时间计费。如果你的集群本来就很稳定、一个月只有一两次告警ROI 可能不够高。但如果你是那种一天十几次告警的环境减少的人工时间绝对能覆盖成本。权限设计要上心Agent 默认是 read-only 的但如果你给它配了修复能力比如重启 Pod、回滚部署IAM 策略一定要收紧。我的建议是先只给读权限跑两周确认它的判断靠谱了再逐步放开。Learned Skills 是个双刃剑Agent 会从你团队的处理模式中学习。如果你团队之前的做法本身就有问题比如出事先重启大法它也会学到。给它投喂 Custom Skills 的时候要认真写别把坏习惯传给它。多云支持还在早期GA 版加了 Azure 支持但我试了一下跨云的关联分析没有纯 AWS 环境那么丝滑。如果你主力在 AWS 那没问题。它会取代运维吗不会。至少这一代不会。它取代的是那些重复性的、凌晨三点被叫醒做的、模式化的调查工作。那种需要理解业务上下文、做架构决策、处理人际沟通的事情还是得靠人。更准确地说它把运维工程师从 Tier-1 响应者变成了 Tier-2 审核者。你不再需要每次告警都亲自下场翻日志了而是审核 Agent 的调查报告在它搞不定的时候介入。Forrester 的一份报告说得挺好长期运行的 Agent 本质上是分布式系统——需要编排、身份管理和上下文纪律。大多数公司从来没建过这些东西。所以真正要担心的不是AI取代运维而是你的组织有没有能力治理一个自主运行的 AI 系统。这听起来像是一个新的运维挑战——嗯确实是。值不值得上如果你的环境满足这几个条件我觉得值得试跑在 AWS 上废话服务数量多、拓扑复杂有比较完善的可观测性基础CloudWatch 或 Datadog/New Reliconcall 频率高、团队人手紧张愿意花时间配好权限和喂 Skills如果你就几台 EC2 跑着一个单体应用那真没必要。我这一周的结论是它不是一个完美的银弹但它确实是我用过的第一个真的有用的 AI 运维工具。不是那种 PPT 里很好看、落地一塌糊涂的产品。它解决的是一个很具体的痛点——告警来了之后那段是什么坏了、为什么坏了的调查过程。凌晨被叫醒的次数变少了这就够了。如果觉得这篇文章对你有帮助欢迎点赞、转发、在看三连让更多人看到。
AWS DevOps Agent 体验一周后，我决定把 oncall 手机调成静音了
发布时间：2026/6/15 1:05:45
上周三凌晨两点我被一个 EKS 集群的告警叫醒。Pod 在 CrashLoopBackOffCloudWatch 一片红。我迷迷糊糊打开笔记本正准备 kubectl describe 的时候突然想起来——等等我不是接了 AWS DevOps Agent 吗打开控制台一看Agent 已经在跑了。从告警触发到它给出根因分析总共花了不到4分钟。一个 ConfigMap 被人误删了Agent 通过审计日志追溯到了具体的操作人和时间戳还给出了修复方案。我愣了一下把手机调成了静音翻身继续睡。这玩意到底是什么AWS DevOps Agent 今年3月底 GA 了。官方定位是永远在线的运维队友——不只是监控告警那一套它能自主调查事件、做根因分析、甚至给出修复计划。说白了就是一个 AI SRE。但跟之前那些 AIOps 工具不一样的是这货不只是给你推荐可能的原因然后让你自己去查。它是真的会动手——当然是在你设定的权限范围内。架构上它是个多 Agent 系统。一个 Lead Agent 充当事件指挥官理解症状、制定调查计划然后把具体的任务分派给专门的子 Agent。有点像一个老练的值班长带着几个新人在干活值班长负责拿主意新人负责跑腿查数据。接入过程我的环境是一套跑在 us-east-1 的 EKS 集群大概二十几个微服务监控用的 CloudWatch PrometheusCI/CD 是 GitLab。接入过程比我预想的简单。在控制台创建一个 Agent Space然后一步步把数据源接进去1. CloudWatchMetrics Logs 2. EKS 集群访问read-only kubectl 3. GitLab 代码仓库 4. Slack 通知通道EKS 的接入需要注意一点Agent 是通过 read-only 的 kubectl 权限来查集群的不管是 public 还是 private endpoint 的集群都支持。你可以把多个集群接到同一个 Agent Space 里。代码仓库的接入是 GA 后新加的功能——Agent 会索引你的代码库在调查的时候能理解代码结构甚至定位到具体哪行代码可能有 bug。整个接入大概花了我一个小时。大部分时间是在配 IAM Role 和确认权限——是的AWS 的老传统了。第一次被惊到接好第二天一个服务的响应时间突然飙到了平时的5倍。告警一触发Agent 就自动开始调查了。我在 Slack 里收到了它的实时汇报。它做了这些事先查 CloudWatch 指标确认异常范围然后去 EKS 里看 Pod 状态、Node 资源使用对比了最近24小时的部署记录翻了 GitLab 里最近的 commit最后关联了一个40分钟前的部署变更结论最近一次部署把一个数据库连接池的参数从20改成了5一个 PR review 没注意的配置变更导致在高并发时连接排队。从告警到给出根因6分钟。我承认如果是我自己查大概率也能定位到但可能得花二三十分钟。而且凌晨的状态下大脑转速是真的慢Agent 没有这个问题。日常使用On-Demand SRE 模式除了自动响应告警它还有一个 On-Demand 模式就像一个随时在线的 SRE 同事。你可以用自然语言问它问题“过去一周哪个服务的错误率增长最快”“上次部署之后 P99 延迟有变化吗”“帮我画一个最近30天的 Pod 重启趋势图”它能直接生成图表还能保存分享给团队。这个功能我用得特别多以前写周报整理指标都得自己翻 Grafana 截图现在直接让它出。真正有意思的MCP 扩展Agent 有个能力边界——它能看 CloudWatch 和 EKS 的 Kubernetes 对象但看不到节点操作系统层面的东西。iptables 规则、CNI 配置、dmesg 内核消息、containerd 日志……这些东西在节点上。6月11号 AWS 官方出了一篇博客讲怎么用 MCPModel Context Protocol扩展 Agent 的能力边界。大意是你可以自己写一个 MCP Server把节点级别的诊断数据暴露给 Agent。思路很巧妙Agent 调用 collect 工具 → MCP Server 触发 SSM Automation → 目标节点执行日志收集 → 打包上传 S3 → 预处理索引错误分类 严重程度标记→ Agent 通过后续工具读取分析核心设计原则有三条返回结构化数据不是原始文本——带严重等级和 finding ID永远不给 Agent 一个 shell——所有操作通过 SSM Automation 中转工具输出可组合——一个工具的输出能作为下一个工具的输入这个 MCP Server 能让 Agent 访问20多种节点级日志源。博客里演示了一个场景Pod 状态是 Running 但 DNS 解析失败kubectl 看着一切正常问题藏在节点的 iptables 规则里。Agent 通过 MCP 拿到 iptables 数据后直接定位了被注入的阻断规则。这种 kubectl 看不出来的问题恰恰是生产环境里最头疼的那种。实际效果数据官方给的数据是preview 用户平均 MTTR 降低75%调查速度提升80%根因准确率94%。我自己这一周的体感一共触发了7次告警其中2次是误报它自己识别出来了5次真实问题里有4次它独立完成了调查给出了准确的根因有1次涉及跨服务的级联故障它定位了直接原因但没追到根本原因最后还是需要人工介入On-Demand 问答用了十几次体验像是有个一直在线的、记得住你整个架构的同事坦率讲它不是万能的。遇到那种涉及业务逻辑的 bug或者几个月前埋下的设计缺陷它分析不出来。它擅长的是基础设施层面的、有清晰遥测数据支撑的、运维操作类的问题。一些坑和注意事项费用这个不便宜按调查次数和 Agent 运行时间计费。如果你的集群本来就很稳定、一个月只有一两次告警ROI 可能不够高。但如果你是那种一天十几次告警的环境减少的人工时间绝对能覆盖成本。权限设计要上心Agent 默认是 read-only 的但如果你给它配了修复能力比如重启 Pod、回滚部署IAM 策略一定要收紧。我的建议是先只给读权限跑两周确认它的判断靠谱了再逐步放开。Learned Skills 是个双刃剑Agent 会从你团队的处理模式中学习。如果你团队之前的做法本身就有问题比如出事先重启大法它也会学到。给它投喂 Custom Skills 的时候要认真写别把坏习惯传给它。多云支持还在早期GA 版加了 Azure 支持但我试了一下跨云的关联分析没有纯 AWS 环境那么丝滑。如果你主力在 AWS 那没问题。它会取代运维吗不会。至少这一代不会。它取代的是那些重复性的、凌晨三点被叫醒做的、模式化的调查工作。那种需要理解业务上下文、做架构决策、处理人际沟通的事情还是得靠人。更准确地说它把运维工程师从 Tier-1 响应者变成了 Tier-2 审核者。你不再需要每次告警都亲自下场翻日志了而是审核 Agent 的调查报告在它搞不定的时候介入。Forrester 的一份报告说得挺好长期运行的 Agent 本质上是分布式系统——需要编排、身份管理和上下文纪律。大多数公司从来没建过这些东西。所以真正要担心的不是AI取代运维而是你的组织有没有能力治理一个自主运行的 AI 系统。这听起来像是一个新的运维挑战——嗯确实是。值不值得上如果你的环境满足这几个条件我觉得值得试跑在 AWS 上废话服务数量多、拓扑复杂有比较完善的可观测性基础CloudWatch 或 Datadog/New Reliconcall 频率高、团队人手紧张愿意花时间配好权限和喂 Skills如果你就几台 EC2 跑着一个单体应用那真没必要。我这一周的结论是它不是一个完美的银弹但它确实是我用过的第一个真的有用的 AI 运维工具。不是那种 PPT 里很好看、落地一塌糊涂的产品。它解决的是一个很具体的痛点——告警来了之后那段是什么坏了、为什么坏了的调查过程。凌晨被叫醒的次数变少了这就够了。如果觉得这篇文章对你有帮助欢迎点赞、转发、在看三连让更多人看到。
