企业官网建设流程全解析

上周三凌晨两点，我被一个 EKS 集群的告警叫醒。Pod 在 CrashLoopBackOff，CloudWatch 一片红。我迷迷糊糊打开笔记本，正准备 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 + Prometheus，CI/CD 是 GitLab。

接入过程比我预想的简单。在控制台创建一个 Agent Space，然后一步步把数据源接进去：

1. CloudWatch（Metrics + 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 官方出了一篇博客，讲怎么用 MCP（Model Context Protocol）扩展 Agent 的能力边界。大意是你可以自己写一个 MCP Server，把节点级别的诊断数据暴露给 Agent。

思路很巧妙：

Agent 调用 collect 工具 → MCP Server 触发 SSM Automation → 目标节点执行日志收集 → 打包上传 S3 → 预处理索引（错误分类 + 严重程度标记）→ Agent 通过后续工具读取分析

核心设计原则有三条：

1. 返回结构化数据，不是原始文本——带严重等级和 finding ID
2. 永远不给 Agent 一个 shell——所有操作通过 SSM Automation 中转
3. 工具输出可组合——一个工具的输出能作为下一个工具的输入

这个 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 Relic）
• oncall 频率高、团队人手紧张
• 愿意花时间配好权限和喂 Skills

如果你就几台 EC2 跑着一个单体应用，那真没必要。

我这一周的结论是：它不是一个完美的银弹，但它确实是我用过的第一个"真的有用"的 AI 运维工具。不是那种 PPT 里很好看、落地一塌糊涂的产品。它解决的是一个很具体的痛点——告警来了之后那段"是什么坏了、为什么坏了"的调查过程。

凌晨被叫醒的次数变少了，这就够了。

如果觉得这篇文章对你有帮助，欢迎点赞、转发、在看三连，让更多人看到。