很多团队试 AI 根因分析（AI RCA），最开始都会很兴奋。把一条告警丢进去，AI 能总结；把一段日志丢进去，AI 能解释；把一张指标曲线描述给它，AI 能列出可能原因。问题是，一到真实生产事故，输出经常变成几句看似合理但不够有用的话：可能是下游依赖异常，建议检查数据库、网络、资源瓶颈和最近发布。
这些建议不一定错，但它们离根因分析很远。事故现场真正需要的是更具体的判断：哪个服务异常，影响哪个业务，异常从什么时候开始，和哪次发布有关，哪条日志能证明，哪段 Trace 显示慢在哪里，历史上有没有类似故障，当前结论有多大把握，下一步应该由谁确认。
AI RCA 经常不准，不是因为模型不会推理，而是因为它拿到的上下文质量太差。模型只能放大已有上下文质量；上下文散，AI 输出就像猜测。建设 AI-Ready 可观测性，比直接采购一个“AI 根因分析功能”更重要。
核心摘要
- AI RCA 的关键不是把更多原始日志塞给模型，而是把可观测数据组织成可调查、可调用、可审计的上下文。
- 可用的根因分析需要同时看到系统拓扑、服务目录、指标、日志、Trace、变更事件、告警历史、响应过程、runbook 和历史故障。
- 缺少对象关系时，AI 很难判断一条日志、一个慢 span 或一个告警是原因、结果，还是无关噪声。
- 灭火图这类对象模型能把接口、服务、数据库、缓存、消息队列、Pod、主机和网络链路组织起来，让 AI 沿着真实依赖调查。
- 可靠的 AI RCA 输出应该包含事实、推理链、置信边界和下一步动作，而不是只给一个自信的根因结论。
AI RCA 为什么不能只靠模型
AI 根因分析不是“让模型读一段文本，然后猜一个答案”。真实事故调查至少包含三件事：
- 确定异常对象：是接口、服务、数据库、缓存、消息队列、Pod、主机、网络链路，还是某个业务系统。
- 建立证据链：哪些指标异常，哪些日志集中出现，哪些 Trace span 变慢，哪些事件发生在异常前后。
- 给出行动边界：哪些判断已有证据支持，哪些仍是候选根因，下一步应该由谁确认或处理。
如果 AI 只拿到一条告警或几行日志，它只能在有限信息里补全故事。补全得再流畅，也不等于完成根因分析。AI RCA 要可靠，核心是让模型进入一个有对象、有关系、有时间线、有证据、有权限边界的调查环境。
AI RCA 所需上下文总览
AI-Ready 不是把所有日志和指标都丢给大模型。那既不经济，也不可靠，还会引入权限和安全问题。更合理的做法，是把可观测数据组织成 AI 能理解、能调用、能审计的上下文。
| 上下文类型 | AI RCA 中的作用 | 缺失后的典型问题 |
|---|---|---|
| 系统拓扑 | 说明接口、服务、组件、实例、集群、机房和网络链路之间的依赖关系 | AI 不知道该沿着哪些上下游继续查，只能泛化建议“检查依赖服务” |
| 服务目录 | 记录服务名、团队、负责人、环境、业务线、等级、值班路径、SLO 和权限边界 | 技术异常很难转成业务影响、责任人和升级路径 |
| 指标 | 提供成功率、延迟、错误率、资源使用、队列积压等状态信号 | AI 看不到异常是否真实发生、何时开始、影响是否扩大 |
| 日志 | 提供错误码、异常堆栈、请求参数、资源标签和业务语义细节 | AI 缺少证明细节，无法解释指标为什么变化 |
| Trace | 串联一次请求经过的服务、span 和耗时分布 | AI 很难定位慢在哪里，也难判断瓶颈在调用链哪一段 |
| 变更和事件 | 把发布、配置、扩缩容、Kubernetes 事件、云事件、运营活动放进时间线 | AI 容易在技术症状里转圈，看不到异常前后发生了什么变化 |
| 告警历史和响应上下文 | 关联 Incident、Alert、通知、认领、升级、战情室讨论和已排除方向 | AI 不了解当前响应阶段，容易重复人已经排除过的路径 |
| Runbook、知识库和历史故障 | 沉淀处理手册、常见错误码、业务说明、历史案例和升级策略 | AI 的建议无法贴近团队环境，只能给通用排障清单 |
| 工具权限 | 支持查询指标、检索日志、打开 Trace、读取事件墙和知识库 | AI 只能基于已有文本推断，结论越容易泛化 |
AI RCA 失败的常见原因
数据分散，AI 只能看到碎片
指标在 Prometheus，日志在 ES、Doris、SLS 或 CLS，Trace 在 SkyWalking、Jaeger、ARMS 或 APM，事件在发布平台、Kubernetes、云控制台和告警系统，服务归属在 CMDB 或文档里。人可以靠经验跳来跳去，AI 如果没有工具和路径，只能看见用户贴给它的碎片。
碎片信息会让 AI 输出“可能是数据库、网络或资源瓶颈”这类宽泛判断。它不是完全错，而是缺少继续收敛的条件。
对象关系缺失，无法区分原因和结果
AI 需要知道当前异常对象是什么：接口、服务、数据库、缓存、消息队列、Pod、主机、网络链路，还是业务系统。它还要知道对象的上游和下游是谁，属于哪个业务，谁依赖它，它依赖谁。
没有对象关系，AI 很难判断一条错误日志是原因、结果，还是无关噪声。比如一个下游超时日志，可能是下游服务故障，也可能是上游请求暴涨导致资源耗尽，还可能只是事故扩散后的结果。
变更事件缺失，根因线索不在日志里
大量事故和发布、配置、扩缩容、Kubernetes 事件、云资源事件、运营活动有关。如果 AI 只能看到指标和日志，看不到异常前后发生了什么变化，它会在技术症状里转圈。
很多根因线索其实不在日志里，而在事件时间线上。发布、配置、节点变更、容器重启、云资源事件和运营动作都可能是调查入口。
历史案例和 runbook 缺失，建议不贴近团队环境
同一个错误码，在不同业务里可能含义不同；同一个数据库告警，在不同系统里处理路径不同。没有历史故障、处理手册、服务说明和业务语义，AI 很难给出贴近团队环境的建议。
Runbook 和知识库的价值，不只是让 AI “知道更多”，而是让它知道这个团队通常怎么判断、怎么止损、怎么升级、哪些动作需要人确认。
工具权限缺失，AI 不能继续调查
根因分析不是静态文本总结，必须查询当前系统。AI 如果不能查询指标、检索日志、打开 Trace、读取事件墙、查看战情室和知识库，就只能基于已有文本推断。权限越少，结论越容易泛化。
AI-Ready 可观测性应该怎么组织
系统拓扑：让 AI 知道沿哪条依赖查下去
AI 要知道服务、接口、组件、实例、集群、机房、网络链路之间的关系。一个支付接口异常时，它要能看到承载服务、下游数据库、缓存、第三方通道、网关和相关机房。
拓扑不是为了画图好看，而是为了让 AI 知道该沿着哪些依赖继续查。没有拓扑，AI 看见的是一个个监控点；有了拓扑，AI 才能把异常放回系统结构里理解。
服务目录：把技术异常转成业务影响和责任路径
服务名、团队、负责人、环境、业务线、等级、值班路径、SLO、权限边界，都属于服务目录上下文。没有服务目录，AI 很难回答两个事故现场最关心的问题：影响哪个业务，谁应该处理。
服务目录也是权限边界的一部分。哪些信息可以读，哪些动作只能建议，哪些动作需要审批，都应该和对象、团队、环境关联起来。
指标、日志、Trace：用统一语义串起证据
指标提供状态，日志提供细节，Trace 提供请求路径。关键是它们要能通过时间、资源、请求上下文串起来。
日志里有 trace_id 但没有 service、env、request_uri 和 error_code，仍然很难做对象级分析；Trace 里有慢 span 但映射不到服务对象，也很难判断影响面。对 AI RCA 来说，指标、日志、Trace 的价值不只在于“有数据”，而在于它们能否使用一致的对象、标签和时间窗口互相引用。
变更和事件：把异常放进时间线
发布、配置、Kubernetes 事件、云事件、运营活动、告警事件都应该进入统一时间线。AI 做 RCA 时，不能只看异常结果，还要看异常前后发生了什么。
统一时间线的目标不是把事件堆在一起，而是支持这样的判断：异常开始前后是否有发布，是否有配置调整，是否有扩缩容，是否有节点或云资源事件，是否有运营活动改变了流量形态。
响应上下文：避免重复排查和错误升级
当前 Incident 关联了哪些 Alert，是否有告警风暴，谁被通知，谁已认领，是否升级，战情室里讨论了什么，这些信息能帮助 AI 判断响应阶段和已排除方向。Flashduty AI SRE 结合 Incident 和 War Room 上下文，正是为了解决这类问题。
响应上下文还能让 AI 输出更贴近现场：不是泛泛建议“请联系负责人”，而是基于服务目录和值班路径给出下一步确认对象；不是重复已经查过的方向，而是把战情室里已排除的假设纳入推理边界。
Runbook 和知识库：补齐长期业务语义
AI 需要长期知识来理解本企业的业务语义、常见故障、处理策略和升级路径。Flashcat FlashAI 的知识库、Flashduty AI SRE 的 Knowledge Packs，都属于这个范畴。
知识库不需要一开始就追求完整。更现实的做法，是先围绕核心链路沉淀高频错误码、历史故障、常见处理路径、服务说明和升级策略，让 AI 在关键场景里先变得有用。
灭火图为什么适合做 AI RCA 的对象模型
Flashcat 灭火图的价值，不只是给人看一张红绿状态图。对 AI 来说，它是一种结构化系统上下文。
灭火图先把系统拆成观测对象。接口、服务、数据库、缓存、消息队列、Pod、主机、网络链路，都可以成为卡片。每张卡片不是一条孤立指标，而是一个具体对象。
灭火图再给每个对象定义健康状态，比如成功率下降、延迟升高、慢查询增多、消费堆积、实例不可用。它还把对象组织成层级结构，例如功能接口、微服务、标准组件、基础设施，并通过下钻规则把日志、Trace、仪表盘、事件和其他卡片挂到对象上。
这正好对应 AI RCA 需要的几类问题：当前分析对象是什么，为什么异常，它在哪个分层，上下游是谁，应该查哪些指标，应该去哪个日志源，用哪些标签查 Trace，应该看哪些变更事件。如果这些都在灭火图里被组织好，AI 面对的就不是碎片数据，而是一个可调查的系统模型。
没有灭火图这类对象模型，AI 可能只能回答“建议检查数据库和依赖服务”。有了对象模型，AI 才可能说清楚“支付接口异常，关联支付服务和订单库卡片同时飘红；日志显示连接池耗尽，Trace 显示耗时集中在数据库调用；事件墙显示 8 分钟前订单服务发布；当前根因候选是新版本引入的慢查询，但需要研发确认 SQL 变更”。
注意这里的措辞：根因候选、需要确认。这是可靠 AI RCA 必须保留的边界。
可靠的 AI RCA 输出应该包含什么
AI RCA 最危险的输出，是一个很自信但没有证据的结论。生产事故里，这类结论会带偏排障方向，甚至导致错误修复。
更合理的输出至少包含四部分。
| 输出部分 | 应该回答的问题 | 示例表达方向 |
|---|---|---|
| 事实 | 哪些指标异常，哪些日志集中出现，哪些 Trace span 变慢，哪些事件发生在异常前 | “下单接口 P99 上升，order-service 相关错误日志增加，数据库调用 span 耗时集中升高” |
| 推理链 | 异常如何从一个对象传导到另一个对象 | “MySQL 慢查询上升导致连接池耗尽，连接池耗尽导致 order-service 请求等待，最终影响下单接口” |
| 置信边界 | 哪些证据支持判断，哪些证据还不足，是否存在其他候选原因 | “当前是根因候选，需要研发确认 SQL 变更；网络抖动证据不足” |
| 下一步动作 | 继续查什么、联系谁、是否止损、是否回滚或验证 | “查看发布前后 SQL 变化，联系服务 owner 确认，先验证回滚或限流方案” |
证据链还有一个作用：让人能复盘 AI。一次 AI RCA 如果判断错了，团队应该能看到它漏掉了哪个上下文、用了哪个错误字段、过度相信了哪条事件、没有查询哪个数据源。只有可审计，AI 才能被持续改进。
人在回路：授权、确认、修复、复盘
AI 可以调查，但生产事故不能把责任交给模型。人在回路至少体现在四个环节。
授权
查询某些敏感日志、执行命令、变更配置、回滚发布、扩容、屏蔽告警，都应该有权限分层。只读调查可以自动化，高风险动作必须由人授权。
确认
AI 输出根因候选后，需要服务 owner、SRE 或相关专家确认。尤其是涉及业务逻辑、数据一致性、用户影响、合规风险时，模型不能替团队拍板。
修复
修复动作往往涉及取舍：回滚会不会影响其他需求，扩容是否有成本和容量风险，切流是否会影响局部用户，屏蔽告警是否会掩盖风险。这些都是工程和业务判断。
复盘
AI 可以整理时间线、证据和初稿，但改进项优先级、负责人、截止日期和验收方式必须由团队确认。否则复盘会变成漂亮文档，而不是系统改进。
落地时怎么建设 AI-Ready 可观测性
1. 选核心业务链路，不要全量铺开
比如交易、支付、登录、核心生产系统。选择最近事故多、业务影响清晰、数据较完整的链路，更容易验证 AI RCA 是否有用。
2. 建立对象模型
用灭火图把接口、服务、组件、基础设施拆成卡片，配置健康状态和层级关系。对象要能对应真实排障语言，而不是只对应指标名。
3. 补齐下钻路径
每类对象都要能下钻到相关指标、日志、Trace、仪表盘、事件和上下游对象。下钻要自动带时间窗口和对象标签，减少手工拼接。
4. 接入事件墙
把发布、配置、Kubernetes、云事件、核心告警和运营活动放进统一时间线，并要求事件带准确时间、对象、负责人和来源。
5. 整理服务目录和知识库
补充服务 owner、值班路径、runbook、历史故障、常见错误码和业务说明。知识不必一次写全，先围绕试点链路补齐高频问题。
6. 把 AI 接入响应流程
Flashcat FlashAI 适合从灭火图、北极星、事件墙和指标/日志/链路上下文切入；Flashduty AI SRE 适合结合 Incident、War Room、知识包和工具调用进入响应现场。两者结合时，要保证观测证据和响应上下文能互相引用。
FAQ
AI RCA 不准，是不是换更强模型就能解决？
不够。更强模型可以提升总结和推理能力，但根因分析首先取决于上下文质量。没有拓扑、服务目录、指标、日志、Trace、事件、runbook 和响应上下文，模型只能基于碎片信息推断，输出自然容易泛化。
AI-Ready 可观测性是不是把所有数据都喂给大模型？
不是。AI-Ready 的重点不是全量喂数据，而是把可观测数据组织成能理解、能调用、能审计的上下文。指标、日志、Trace、事件和服务目录应该通过对象、时间窗口、标签和请求上下文串起来。
为什么变更事件对根因分析这么重要？
因为很多根因线索不在日志里，而在异常前后的时间线上。发布、配置、扩缩容、Kubernetes 事件、云资源事件和运营活动，都可能解释“为什么这个时间点开始异常”。
灭火图在 AI RCA 里解决什么问题？
灭火图把接口、服务、组件和基础设施拆成可观测对象，并定义健康状态、层级关系和下钻路径。它让 AI 面对的是一个可调查的系统模型，而不是一堆没有关系的指标、日志和 Trace。
AI RCA 输出为什么必须保留置信边界？
生产事故里，过度自信但没有证据的结论会带偏排障方向。可靠输出应该区分事实、推理、候选根因和待确认项，明确哪些证据足够，哪些还需要服务 owner、SRE 或相关专家确认。
总结：先建上下文，再谈 AI RCA
AI 根因分析不准，很多时候不是模型不够强，而是上下文没有准备好。数据散、对象关系缺失、变更事件缺失、历史案例缺失、工具权限缺失，都会让 AI 输出停留在猜测层面。
真正可用的 AI RCA，需要系统拓扑、服务目录、指标、日志、Trace、变更、告警历史、响应上下文、runbook 和历史故障共同构成上下文。模型负责基于这些上下文调查、归纳和推理；团队负责定义对象、补齐证据、控制权限、确认根因和推动修复。
下一步可以很具体：下载一份 AI-Ready 可观测性建设清单，选一个核心业务链路，对照检查对象模型、下钻路径、事件墙、知识库、工具权限和响应上下文。先把上下文做扎实，再让 AI 参与调查，效果会比单独追一个“更聪明的模型”可靠得多。
