过去这段时间，我系统看了一批海外头部厂商的 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 不是“根因按钮”，而是一套面向生产事故的调查系统；模型只是其中一个推理和编排组件。
- 真正有价值的 AI RCA，要先拥有生产上下文：服务、环境、版本、团队、拓扑、变更、告警、SLO、日志、trace、历史事故和 runbook。
- AI RCA 的输出不应该只有自然语言总结，而应该是可展开、可验证、可审计的 investigation package。
- 症状、触发器、关键故障点、根因和影响范围必须被区分，否则 AI 很容易把“发生了什么”误写成“为什么发生”。
- 可观测性平台更适合承担 observability-native technical RCA engine 的角色，同时连接 incident / ITSM / IM 系统，并把上下文开放给 Codex、Cursor、Claude Code 和企业内部 Agent。
一句话结论
AI RCA 的目标不是让 AI 替 SRE 拍脑袋，而是让 AI 帮 SRE 更快、更完整、更可信地完成生产调查。
这句话里有三个关键词：
- 更快：减少人工在指标、日志、链路、变更、告警、工单和代码之间来回切换的时间。
- 更完整：系统性覆盖候选根因、支持证据、反证、已排除方向和下一步验证动作。
- 更可信：每个结论都能回到原始证据、查询链接、变更记录、历史事故或人工确认。
头部厂商其实在走不同路线
看这些厂商，不能简单说“大家都在做 AI RCA”。它们的出发点完全不同。
| 路线 | 代表厂商 | 更擅长的上下文 | 对 AI RCA 的启示 |
|---|---|---|---|
| observability-native | Datadog、Dynatrace、New Relic、Splunk、Grafana、Elastic、Honeycomb | metrics、logs、traces、APM、拓扑、变更、dashboard、SLO | 更适合做技术证据组织和根因调查 |
| incident-native | PagerDuty、incident.io、Rootly | on-call、升级、Slack / Teams 频道、事故角色、状态更新、复盘、follow-up、历史事故 | 价值不在于比可观测性平台更懂 trace，而在于把事故变成可协同、可沉淀、可复盘的 workspace |
| ITSM / AIOps / NOC | ServiceNow、BigPanda、LogicMonitor、ScienceLogic | CMDB、工单、变更、服务台、网络设备、机房、虚拟化、外包运维、自动化脚本 | 更贴近传统企业运维现场，需要强工单、流程和治理能力 |
| cloud-native | AWS、Azure、Google Cloud | 云资源、控制面、IAM、审计日志、平台健康、资源拓扑、标准 runbook | 云厂商天然掌握资源和控制面上下文 |
| 独立 AI SRE 层 | Resolve AI、Neubird | 跨工具连接、已有工具栈之上的调查编排 | 不替代 Datadog、Splunk、Prometheus、CloudWatch，而是连接它们做跨工具调查 |
这些路线不一样，但底层共识是一致的：
AI RCA 不是让 LLM 猜根因，而是让 AI 基于事实组织调查。
AI RCA 产品框架总览
我认为 AI RCA 至少要分成十层。把这十层拆开看，能避免把产品做成一个孤立聊天框，也能看清可观测性平台、事故协同系统、代码助手和自动化平台各自应该承担什么。
| 层级 | 产品能力 | 关键问题 | 典型产物 |
|---|---|---|---|
| 1. 数据质量 | 统一服务名、环境、版本、团队、集群、namespace、trace id、resource id、deployment id | AI 能不能知道该查什么 | 标准字段、标签规范、上下文索引 |
| 2. 实体模型 | 建模服务、主机、容器、数据库、队列、云资源、业务系统的关系 | 谁依赖谁，谁归哪个团队负责 | 服务拓扑、依赖图、owner 映射 |
| 3. 事件治理 | 标准化、去重、抑制、聚合告警 | AI 面对的是问题，还是 alert storm | 事件聚合、降噪规则、关联告警 |
| 4. 问题对象 | 把多条告警、多种症状、多条证据组织成 issue、problem、incident、episode | RCA 是围绕单条告警，还是围绕真实故障 | 事故对象、问题对象、影响范围 |
| 5. 调查入口 | 从 alert、SLO、incident、dashboard、日志查询、chat、API 启动 AI investigation | 用户能不能在当前工作流里发起调查 | 多入口调查、上下文传递 |
| 6. 调查引擎 | 生成假设、调用工具、查询数据、验证或推翻假设 | AI 是在自由发挥，还是在按证据调查 | hypothesis、tool call、query、验证轨迹 |
| 7. 证据链 | 展开指标、日志、trace、变更、拓扑、代码 diff、历史事故和查询链接 | 结论能不能被复核 | evidence graph、deep link、反证记录 |
| 8. 协作工作台 | 展示不同 investigation thread、owner、状态、确认结论和开放问题 | 多团队能不能共享调查状态 | investigation workspace、状态流转、人工确认 |
| 9. 行动闭环 | 连接 rollback 建议、runbook、工单、PR、status update、postmortem、follow-up | RCA 之后能不能进入处置和预防 | 建议动作、审批、工单、复盘项 |
| 10. 学习和评估 | 记录用户是否接受 AI 结论、最终复盘是否一致、是否漏查、是否给过危险建议 | AI RCA 能不能持续变好 | 历史回放、评估集、风险审计 |
这十层里，LLM 只是其中一部分。前面的数据、拓扑、事件、权限、工作流不稳，后面的 AI 一定不稳。
从上下文到证据链：调查系统应该如何工作
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、查变更、查拓扑、查历史事故、查 runbook、查代码 diff。工具调用越结构化，AI RCA 越接近工程系统，而不是演示脚本。
证据链决定结论可信度
第七层是证据链。每个结论都要能展开看到指标、日志、trace、变更、拓扑、代码 diff、历史事故和查询链接。
一个可用的 AI RCA 结论，至少要能回答这些问题：
- 为什么认为这个方向更可能是根因？
- 哪些指标、日志、trace 或变更支持这个判断？
- 有没有反证？
- 哪些候选原因已经被排除？
- 这个判断是 AI hypothesis，还是已经被人确认？
- 下一步应该查什么？
没有证据链的 RCA，本质上只是摘要。摘要可以提高沟通效率，但不能支撑生产事故决策。
人机协作决定能否进生产
第八层是协作工作台。真实事故经常涉及多个团队，所以要展示不同 investigation thread：谁在查数据库，谁在查发布，谁在查网络，哪些方向已排除，哪些方向仍然开放。
第九层是行动闭环。RCA 不是终点，后面还要有 rollback 建议、runbook、工单、PR、status update、postmortem、follow-up。
第十层是学习和评估。用户是否接受 AI 结论？最终复盘根因是否一致？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 | 触发调查的信号 | 告警触发、SLO burn、用户反馈 |
| symptom | 系统表现出来的异常 | 错误率升高、延迟升高、CPU 高 |
| critical failure | 最早或最关键的技术故障点 | 某个服务最早出现退化 |
| root cause | 导致退化的状态变化 | 发布、配置、依赖、权限、资源限制变化 |
| impact | 对用户、业务、SLO、客户的影响 | 某类请求失败、某个区域受影响 |
如果产品不做这层区分，AI 很容易把“发生了什么”误写成“为什么发生”。
变更必须是一等公民
看完这些产品，我越来越确定一件事：AI RCA 如果不看变更，能力会很弱。
变更包括很多类型：代码发布、配置变更、Kubernetes rollout、feature flag、数据库 schema、云资源调整、IAM 权限、网络策略、CMDB change request、CI/CD pipeline、依赖版本升级。
大量故障的关键问题不是“哪个指标异常”，而是“异常之前发生了什么变化”。
所以可观测性平台做 AI RCA，必须把 change event 纳入数据底座。并且不是简单展示一条发布记录，而是要和服务、环境、版本、负责人、trace、日志、SLO、告警关联起来。
从产品设计上看，变更不应该只是 timeline 里的一行信息，而应该参与候选根因排序、证据链构建、反证判断和行动建议。
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 工具层。
这里的关键是边界：代码助手可以深入代码和 PR，事故工作台负责共享状态和组织协同，可观测性平台负责生产证据和调查工具。三者应该互相传递上下文，而不是互相替代。
自动修复不能太着急
很多厂商都在讲 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。
我建议的建设路径是：
| 阶段 | 建设重点 | 目的 |
|---|---|---|
| 1 | 补数据底座，统一服务、环境、版本、团队、拓扑、变更、trace、日志字段和告警上下文 | 让 AI 能拿到稳定上下文 |
| 2 | 做低风险 AI 能力，包括告警摘要、日志摘要、查询生成、dashboard 解释、similar incidents、runbook 推荐 | 先在低风险场景建立信任 |
| 3 | 做限定场景 RCA，比如服务延迟升高、错误率升高、Kubernetes OOM、发布后回归、日志模式突增、SLO burn | 避免一开始就做通用根因判断 |
| 4 | 标准化 investigation package | 每次 AI 调查都产出结构化结果，而不是一段自然语言 |
| 5 | 做 investigation workspace | 支持多方向排查、owner、状态、证据、结论、反证和下一步动作 |
| 6 | 集成 incident / ITSM / IM | 把调查结果推送到 PagerDuty、ServiceNow、Jira、飞书、企微、钉钉、Slack |
| 7 | 开放 MCP / Agent 工具层 | 让外部 AI 工具能安全调用服务健康、指标、日志、trace、变更、告警、SLO、dashboard deep link |
| 8 | 建立评估体系 | 用历史事故回放测试 AI 是否找对证据、是否漏查、是否误判、是否给危险建议 |
| 9 | 再做受控 remediation | 先建议，再审批，再执行，最后才谈自动化 |
这条路径的本质是先做调查能力，再做协同闭环，最后做受控执行。顺序不能反过来。
FAQ
AI RCA 和传统 AIOps 有什么区别？
传统 AIOps 更常见的切入点是告警降噪、事件关联、异常检测和工单自动化。AI RCA 更强调围绕一次生产问题建立调查对象，组织上下文、候选根因、工具调用、证据链、反证、协作状态和行动闭环。两者可以结合，但 AI RCA 不能只停留在告警聚合。
AI RCA 为什么不能只做成聊天机器人？
因为生产事故需要可验证的证据和协作状态。聊天机器人可以作为入口，但不能成为唯一产品形态。工程师需要看到指标、日志、trace、变更、拓扑、历史事故、候选原因、已排除方向、置信度和下一步动作，而不只是一段“可能是什么原因”的回答。
可观测性平台做 AI RCA 的优势是什么？
可观测性平台天然接近 metrics、logs、traces、APM、拓扑、变更、dashboard、SLO 和告警上下文。它最适合做技术证据和调查引擎，再通过 incident / ITSM / IM 集成补齐事故协同、审批、复盘和 follow-up。
变更为什么在 AI RCA 里这么重要？
很多故障的关键不只是“哪个指标异常”，而是“异常之前发生了什么变化”。代码发布、配置修改、Kubernetes rollout、feature flag、数据库 schema、云资源、IAM、网络策略等变更，往往是候选根因排序和证据链构建的核心输入。
AI RCA 什么时候可以自动修复？
不要一开始就追求自动修复。更稳的路径是先做只读调查和证据链，再给建议动作、runbook、命令或 PR 草稿，然后由人审批执行。只有低风险、权限清晰、审计完整、可回滚的动作，才适合逐步自动化。
最后
AI RCA 会是可观测性平台未来几年非常重要的方向。但它不会以“AI 根因按钮”的形式成熟。
它更像是一次产品架构升级：把过去分散在指标、日志、链路、告警、拓扑、变更、工单、事故复盘、代码仓库里的上下文，组织成一个可调查、可验证、可协作、可行动的系统。
大模型当然重要，但它不是根本。
根本是：平台是否拥有足够完整的生产事实；是否能把告警变成问题对象；是否能基于证据提出和验证假设；是否能让团队共享调查状态；是否能把结论推进到处置和复盘；是否能在权限、审计、成本和安全上让企业放心。
一句话总结：
AI RCA 的目标不是让 AI 替 SRE 拍脑袋，而是让 AI 帮 SRE 更快、更完整、更可信地完成生产调查。
编者：秦晓辉，ToB 软件创业者，长期关注监控、可观测性、RCA、SRE 方向。曾主导 Open-Falcon、Nightingale 等开源项目建设。极客时间专栏《运维监控系统实战笔记》作者，公众号 SRETALK 主理人。
觉得有用？望不吝转发点赞 :)
