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