过去这段时间，我系统看了一批海外头部厂商的 AI SRE / AI RCA 产品，包括 Datadog、Dynatrace、New Relic、Splunk、Grafana、Elastic、Honeycomb、Sentry、PagerDuty、incident.io、Rootly、ServiceNow、BigPanda、Resolve AI、Neubird，以及 AWS、Azure、Google Cloud、IBM 等云和企业软件厂商。
看完之后，我有一个很明确的判断：
AI RCA 的核心竞争力，不是模型，而是生产上下文、证据链、工作流和治理。
如果把 AI RCA 理解成“用户点一个按钮，AI 告诉你根因是什么”，这个方向大概率会失败。真实的生产故障太复杂，单靠大模型在几条告警、几段日志上做自由推理，很容易把症状说成根因，把时间相关说成因果，把猜测包装成结论。
更合理的方向是：把 AI RCA 做成一套生产调查系统。
它应该从告警、指标、日志、链路、拓扑、变更、代码、工单、历史事故、runbook、权限、自动化流程中收集证据，然后形成可验证的假设，逐步验证或推翻，最后把结论推进到处置、复盘和预防。
头部厂商其实在走不同路线
看这些厂商，不能简单说“大家都在做 AI RCA”。它们的出发点完全不同。
Datadog、Dynatrace、New Relic、Splunk、Grafana、Elastic、Honeycomb 这类厂商是 observability-native 路线。它们掌握 metrics、logs、traces、APM、拓扑、变更、dashboard、SLO，所以更适合做技术证据和根因调查。
PagerDuty、incident.io、Rootly 是 incident-native 路线。它们不一定拥有最深的 telemetry，但拥有事故现场：on-call、升级、Slack/Teams 频道、事故角色、状态更新、复盘、follow-up、历史事故。它们的价值不是比 Datadog 更懂 trace，而是把事故变成一个可协同、可沉淀、可复盘的 workspace。
ServiceNow、BigPanda、LogicMonitor、ScienceLogic 是 ITSM / AIOps / NOC 路线。它们面对的是更传统、更复杂的企业运维现场：CMDB、工单、变更、服务台、网络设备、机房、虚拟化、外包运维、自动化脚本。
AWS、Azure、Google Cloud 则是 cloud-native 路线。它们天然掌握云资源、控制面、IAM、审计日志、平台健康、资源拓扑和标准 runbook。
Resolve AI、Neubird 这类公司走的是独立 AI SRE 层路线：不替代 Datadog、Splunk、Prometheus、CloudWatch，而是连接它们，在客户已有工具栈之上做跨工具调查。
这些路线不一样，但底层共识是一致的：
AI RCA 不是让 LLM 猜根因，而是让 AI 基于事实组织调查。
真正的 AI RCA 产品链路
我认为 AI RCA 至少要分成十层。
第一层是数据质量。服务名、环境、版本、团队、集群、namespace、trace id、resource id、deployment id 这些字段如果不统一，AI 一开始就不知道该查什么。
第二层是实体模型。平台要知道服务、主机、容器、数据库、队列、云资源、业务系统之间是什么关系，谁依赖谁，谁归哪个团队负责。
第三层是事件治理。告警要先标准化、去重、抑制、聚合，不能让 AI 面对一堆散乱的 alert storm。
第四层是问题对象。不要围绕单条告警做 RCA，而要先形成 issue、problem、incident、episode 这样的对象。一个真实故障往往包含多条告警、多种症状、多条证据。
第五层是调查入口。AI investigation 可以从 alert、SLO、incident、dashboard、日志查询、chat、API 多个入口启动，而不是只放在一个孤立聊天框里。
第六层是调查引擎。AI 要生成假设、调用工具、查询数据、验证或推翻假设。每一步都应该留下轨迹。
第七层是证据链。每个结论都要能展开看到指标、日志、trace、变更、拓扑、代码 diff、历史事故和查询链接。
第八层是协作工作台。真实事故经常涉及多个团队，所以要展示不同 investigation thread：谁在查数据库，谁在查发布，谁在查网络，哪些方向已排除，哪些方向仍然开放。
第九层是行动闭环。RCA 不是终点，后面还要有 rollback 建议、runbook、工单、PR、status update、postmortem、follow-up。
第十层是学习和评估。用户是否接受 AI 结论？最终复盘根因是否一致？AI 是否漏查关键证据？是否给过危险建议？这些都要进入评估体系。
这十层里，LLM 只是其中一部分。前面的数据、拓扑、事件、权限、工作流不稳，后面的 AI 一定不稳。
最容易犯的错：把 AI RCA 做成聊天框
很多团队做 AI RCA，第一反应是加一个“AI 运维助手”。
用户问：“这次故障根因是什么？”
AI 回答：“可能是数据库连接池耗尽。”
这类 demo 看起来很漂亮，但在生产里很危险。
一线工程师真正需要的不是一句话答案，而是：
为什么你认为是数据库？
哪些指标支持？
哪些日志支持？
有没有 trace 证据？
近期是否有变更？
有没有其他候选原因？
哪些方向已经被排除？
这个结论置信度是多少？
下一步应该怎么验证？
如果要修复，需要谁审批？
所以 AI RCA 的输出不应该是一段总结，而应该是一个 investigation package。
这个 package 至少包括：当前事实、影响范围、时间窗口、受影响服务、关联告警、近期变更、候选根因、支持证据、反证、已排除方向、置信度、下一步检查和建议动作。
不要把症状说成根因
这是 AI RCA 最大的坑之一。
CPU 高不是根因。延迟高不是根因。错误率高也不是根因。它们多数时候只是症状。
真正的根因通常是某个状态变化：
一次发布。
一次配置修改。
一个数据库 schema 变更。
一个下游依赖退化。
一个 feature flag 打开。
一个云资源限制。
一个证书过期。
一个权限策略变化。
一个重试风暴。
好的 RCA 产品应该在语义上区分 trigger、symptom、critical failure、root cause 和 impact。
告警只是 trigger。
错误率升高是 symptom。
某个服务最早出现退化是 critical failure。
导致退化的状态变化才可能是 root cause。
用户、业务、SLO、客户受影响情况是 impact。
如果产品不做这层区分，AI 很容易把“发生了什么”误写成“为什么发生”。
变更必须是一等公民
看完这些产品，我越来越确定一件事：AI RCA 如果不看变更，能力会很弱。
变更包括很多类型：
代码发布、配置变更、Kubernetes rollout、feature flag、数据库 schema、云资源调整、IAM 权限、网络策略、CMDB change request、CI/CD pipeline、依赖版本升级。
大量故障的关键问题不是“哪个指标异常”，而是“异常之前发生了什么变化”。
所以可观测性平台做 AI RCA，必须把 change event 纳入数据底座。并且不是简单展示一条发布记录，而是要和服务、环境、版本、负责人、trace、日志、SLO、告警关联起来。
Timeline 不够，应该有 Investigation Workspace
很多 incident 产品喜欢展示 timeline。timeline 对复盘有用，但对实时调查不够。
真实事故不是线性的。它通常是多个团队并行排查：
A 团队查最近发布。
B 团队查数据库。
C 团队查网络。
D 团队查第三方依赖。
E 团队查客户影响。
某个工程师在 Codex / Cursor 里查代码 diff。
这些事情在时间上交错，但在逻辑上是多个 investigation thread。
所以我认为更好的产品形态是 structured investigation workspace。
它应该展示：
当前有哪些排查方向；
每个方向的 owner 是谁；
状态是 proposed、investigating、confirmed、refuted 还是 inconclusive；
每个方向有哪些证据；
哪些结论已被人确认；
哪些只是 AI hypothesis；
下一步谁要做什么。
Timeline 可以自动生成，但不应该是唯一主视图。
Codex、Cursor 会参与 RCA，但不应该成为事故主系统
未来工程师一定会在 Codex、Cursor、Claude Code 里做一部分 RCA。尤其是代码相关问题，它们会非常强。
比如某次事故怀疑由最新 PR 导致，工程师可以让 Codex 结合 GitHub diff、Datadog trace、Splunk 日志，分析哪段代码可能引入问题，甚至生成修复 PR。
但这不意味着企业级 RCA 应该只发生在 IDE 里。
事故通常涉及多团队协作、共享状态、权限审计、客户沟通、复盘和 follow-up。Codex / Cursor 更像个人调查工作台，incident workspace 才是事故 system of record。
合理分工应该是：
Codex / Cursor 做本地技术调查和代码分析。
Datadog / Splunk / Grafana / Prometheus / Elastic 做证据源。
PagerDuty / incident.io / Rootly 或自研 incident workspace 做事故协同和结论沉淀。
可观测性平台提供技术 RCA engine 和 MCP 工具层。
自动修复不能太着急
很多厂商都在讲 autonomous SRE，但真正落地时都很谨慎。
原因很简单：生产修复动作风险太高。
重启服务、扩容、rollback、改配置、执行 SQL、修改 IAM、切流量，这些动作一旦出错，可能造成二次事故。
所以 AI RCA 的自动化应该分阶段：
先做只读调查。
再做证据链。
再做建议动作。
再生成 runbook、命令、PR 草稿。
再由人审批执行。
最后才是低风险动作自动化。
高风险动作必须有权限、审批、审计、回滚和责任归属。
在国内金融、政企、电信、能源客户里，这一点尤其重要。直接宣传“AI 自动修复生产故障”，很容易在安全评审阶段被卡死。
可观测性平台应该怎么做
如果我们站在一个可观测性平台厂商的视角，最合理的定位不是做另一个 PagerDuty，也不是做一个通用聊天机器人。
更合理的定位是：
observability-native technical RCA engine + incident workflow integration + agent context provider。
也就是说，技术证据和调查能力应该在可观测性平台里最强；事故协作可以和外部 incident / ITSM / IM 系统集成；同时通过 MCP / API 把生产上下文开放给 Codex、Cursor、Claude Code、企业内部 Agent。
我建议的建设路径是：
第一步，补数据底座。统一服务、环境、版本、团队、拓扑、变更、trace、日志字段和告警上下文。
第二步，做低风险 AI 能力。告警摘要、日志摘要、查询生成、dashboard 解释、similar incidents、runbook 推荐。
第三步，做限定场景 RCA。比如服务延迟升高、错误率升高、Kubernetes OOM、发布后回归、日志模式突增、SLO burn。
第四步，标准化 investigation package。每次 AI 调查都产出结构化结果，而不是一段自然语言。
第五步，做 investigation workspace。支持多方向排查、owner、状态、证据、结论、反证和下一步动作。
第六步，集成 incident / ITSM / IM。把调查结果推送到 PagerDuty、ServiceNow、Jira、飞书、企微、钉钉、Slack。
第七步，开放 MCP / Agent 工具层。让外部 AI 工具能安全调用服务健康、指标、日志、trace、变更、告警、SLO、dashboard deep link。
第八步，建立评估体系。用历史事故回放测试 AI 是否找对证据、是否漏查、是否误判、是否给危险建议。
第九步，再做受控 remediation。先建议，再审批，再执行，最后才谈自动化。
最后
AI RCA 会是可观测性平台未来几年非常重要的方向。但它不会以“AI 根因按钮”的形式成熟。
它更像是一次产品架构升级：把过去分散在指标、日志、链路、告警、拓扑、变更、工单、事故复盘、代码仓库里的上下文，组织成一个可调查、可验证、可协作、可行动的系统。
大模型当然重要，但它不是根本。
根本是：平台是否拥有足够完整的生产事实；是否能把告警变成问题对象；是否能基于证据提出和验证假设；是否能让团队共享调查状态；是否能把结论推进到处置和复盘；是否能在权限、审计、成本和安全上让企业放心。
一句话总结：
AI RCA 的目标不是让 AI 替 SRE 拍脑袋，而是让 AI 帮 SRE 更快、更完整、更可信地完成生产调查。
编者：秦晓辉，ToB 软件创业者，长期关注监控、可观测性、RCA、SRE 方向。曾主导 Open-Falcon、Nightingale 等开源项目建设。极客时间专栏《运维监控系统实战笔记》作者，公众号 SRETALK 主理人。
觉得有用？望不吝转发点赞 :)
