夜雨聆风★ 点击名片，关注我们不迷路 ★
如果 AI 已经能帮我们看 Kubernetes 资源异常了，那再往前走一步，它能不能帮运维调查一次真正的生产故障？这里我说的不是自动修复。生产故障刚发生的时候，最怕的不是没人执行命令，而是大家还没看清现场，就已经开始猜原因。
告警在 Alertmanager 里、指标在 Prometheus 里、日志在 Loki 或 ELK 里、服务状态在 Kubernetes 里，最近一次发布记录可能在 Argo CD、GitHub、GitLab 或 Jenkins 里。
再加上值班群里的几句描述，整个现场很容易碎成一地。这时候 AI 如果直接说“我来修”，我一般不敢信。但如果它能先帮我把证据捞出来，告诉我它看到了哪些异常、这些异常之间有没有关系、下一步应该查什么，这个方向就比较靠谱。
一、HolmesGPT 是什么
HolmesGPT 是一个开源的 SRE Agent。官方对它的定位很直接：用来调查生产环境故障并帮助定位根因。它支持任何 Kubernetes，也可以连接虚拟机、云服务、数据库、SaaS 平台和各种可观测性系统（目前为 CNCF 沙盒项目）。
从运维角度看，我更愿意把它理解成一个“排障调查助手”。它不是替你点重启按钮的人。它更像是值班时坐在旁边的人，你问它：
这个服务为什么不健康？这个 Pod 为什么起不来？当前有哪些 Prometheus 告警？这个 namespace 里最近有什么异常？
然后它会去查自己能访问的数据源。
Kubernetes 资源状态、Pod 日志、Prometheus 指标、Grafana 面板、Loki 日志、Datadog、AlertManager、PagerDuty、Jira、GitHub、GitLab、Jenkins，这些都在它官方列出的集成范围里。
HolmesGPT：围绕一次事故，把告警、指标、日志、资源状态和变更信息串起来看。这个方向很像真实运维现场。
二、它解决的是哪一段问题
我觉得 HolmesGPT 解决的不是“最后怎么修”，而是“前面怎么查”。
很多线上故障，真正耗时间的是前 10 到 20 分钟。告警来了，先看哪个服务？是应用问题，还是 Kubernetes 调度问题？是新版本引入的，还是依赖服务挂了？是流量变大了，还是资源限制太小？这些问题都不难，但现场信息分散的时候，人会很容易绕。
尤其是凌晨值班。人一困，第一反应就容易去翻自己最熟悉的地方。熟悉日志的人先看日志，熟悉 Prometheus 的人先看指标，熟悉 Kubernetes 的人先 kubectl describe。这些动作都没错。问题是，它们未必是这次故障最短的路径。
HolmesGPT 的价值：它可以先按一个 Agent 的方式去调用工具，查资源、查日志、查指标、查告警，再给出一个排查结论。这个结论不一定百分百对。但如果它能把证据列出来，就已经有用了。比如告诉你：
某个 Deployment 的 Pod 正在 CrashLoopBackOff； Pod 之前的日志里出现数据库连接超时； 同一时间 Prometheus 里数据库连接数打满； 最近一次发布刚好改过连接池参数。
三、先跑起来看看
macOS 或 Linux 可以用 Homebrew：
brew tap robusta-dev/homebrew-holmesgptbrew install holmesgptholmes ask --help
入门阶段，我建议先用本地 kubeconfig 测试。先确认当前 kubectl 指向的是你想看的集群：
kubectl config current-context 然后配置模型 API。HolmesGPT 通过 LiteLLM 调用大模型，也支持 OpenAI 兼容接口。（模型必须支持 Function Call）
3.1 跑一次测试
配置完成后，先问一个具体问题：
holmes ask "请用中文检查当前集群中状态异常的 Pod，说明异常原因，并列出判断依据。" 如果你想按官方 walkthrough 做一次测试，可以创建一个有问题的测试 Pod：
kubectl apply -f https://raw.githubusercontent.com/robusta-dev/kubernetes-demos/main/pending_pods/pending_pod_node_selector.yaml 再让 HolmesGPT 调查：
holmes ask "请用中文调查 user-profile-import Pod 为什么无法调度，并给出证据和建议的处理步骤。" 这一步跑通以后，你基本就能理解它的工作方式了。
四、我会怎么在生产里用
我会先放在三个位置。
第一个位置：只读排查。
给它一个只读权限的 kubeconfig 或 ServiceAccount，让它只能看资源、看日志、查指标，不允许改资源。
先在测试集群或预发集群跑。我关心的不是它回答得多漂亮，而是它有没有稳定找到真实异常，有没有乱推断，有没有把无关信息说成根因。
第二个位置：告警辅助分析。
比如 Alertmanager 里来了一个服务不可用告警，不要直接让 HolmesGPT 修。可以让它先回答几个固定问题：
你看到了哪些异常？这些异常来自哪些数据源？你认为最可能的方向是什么？下一步建议人工检查哪几个点？
这个提示词比“帮我解决这个故障”更适合生产环境。因为它把工具限制在调查和建议层。
第三个位置：事故复盘素材。
很多事故结束后，大家才发现现场证据没有留好。当时 Pod 是什么状态？有没有重启？当时的错误日志是什么？Prometheus指标有没有一起抖？
如果 HolmesGPT 的调查过程能保留下来，它可以成为复盘材料的一部分。
五、它比普通脚本强在哪里
以前我们也会写巡检脚本。脚本查 Pod 状态、查重启次数、查 PVC、查 Node、查证书过期、查磁盘、查资源配额。
但脚本的问题也明显：它只会按你写好的规则工作。规则里没写，它就看不到。HolmesGPT 这类工具多了一层 Agent 调用能力。它可以根据问题决定下一步查什么，而不是固定跑一串命令。
比如你问的是 Pod 为什么不健康，它可能会先查 Pod 状态，再看 Event，再看日志，再看相关 Deployment。如果你接了 Prometheus，它还可能去看指标。这个过程有点像一个有经验的运维在排障，只不过它的判断质量取决于工具配置、数据质量和模型能力。所以我不会说它替代脚本。
更合适的关系是：脚本负责稳定巡检，HolmesGPT 负责临时调查。
六、真用的时候，别跳过这些边界
第一，不要让它一开始就有写权限。
HolmesGPT 官方有 Kubernetes Remediation 相关能力，可以做扩缩容、回滚、修改资源等动作。但这类能力不适合一上来就在生产环境打开。先只读。等团队对它的输出质量、审计方式、回滚流程都熟了，再讨论能不能进入执行层。这个顺序不要反。
第二，注意数据出网和敏感信息。
虽然 Kubernetes 工具集默认排除 secrets，但日志里可能有 token、内部域名、用户信息、数据库错误、接口路径。如果公司对数据出网有要求，就要考虑本地模型、内网模型，或者先做脱敏。不要因为工具看起来方便，就把生产日志整包丢给外部模型。
第三，AI 给的是调查结论，不是事故定责。
它可以说“我观察到这些现象，所以怀疑某个方向”。但最终根因要靠++证据闭环++。有没有发布记录？有没有指标拐点？有没有日志时间线？有没有回滚验证？这些东西缺一块，结论就不要写得太死。
第四，别让新人绕过基础能力。
这类工具对新人很有帮助。但帮助的方式应该是让新人更快理解现场，而不是让新人不用学 Kubernetes、Prometheus、日志和发布流程。比较好的用法是：先看 HolmesGPT 的结论，再用 kubectl describe、kubectl logs、PromQL 和原始日志去验证。
验证几次，比单纯看 AI 输出更长本事。
七、最后的判断
HolmesGPT 比 K8sGPT 更像一个面向事故调查的 AI 运维助手。K8sGPT 的入口更聚焦 Kubernetes 资源诊断。HolmesGPT 的野心更大，它想把告警、日志、指标、资源状态、工单和代码平台都接进一次调查里。这个方向我觉得值得关注。但在生产环境里，我对这类工具的态度还是那句话：
先让它读。再让它解释。再让它建议。最后才讨论能不能执行。
如果你现在已经在用 K8s、Prometheus、Loki 或 Grafana，又想试试 AI 在运维排障里到底能不能帮上忙，HolmesGPT 可以作为 K8sGPT 之后的下一个工具来看。
不要指望它一上来替你处理事故。先让它帮你把现场看清楚。这一步做好，已经能省不少时间。
地址：github.com/HolmesGPT/holmesgpt
2026年，想了解过国内大厂运维/研发/测试 AI Agent 企业级落地指南？GOPS 2026・上海站（10.16-17），扫码锁定早鸟票👇
近期好文：
弃用 Docker Desktop！开源、更强大、轻量的替代神器来了？
金融 SRE 如何从零构建多 AI Agent ，实现效能助推？
“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱：jiachen@huayou-tech.com，或添加联系人微信：greatops1118。
