从可观测到 AI RCA：一次值班辅助决策闭环的落地复盘

这是“微服务平台治理”与 “AI RCA” 两条线之间的一篇衔接文章。
如果前面的文章已经逐步解决了服务怎么跑、流量怎么进来、系统怎么被观测，那么这一篇真正要回答的，就是告警真的响起来之后，值班员如何更快拿到第一轮可用判断。

摘要

可观测平台让指标、日志、链路这些运行信号变得越来越完整，但值班员并不会因此自动变轻松。真正辛苦的那一段，往往发生在告警触发之后：人仍然需要跨多个系统去查、去拼、去判断，再把结论同步给其他人。AI RCA 在我们的实践里，不是自动处置系统，也不是聊天机器人，而是一层建立在运行时平台、可观测平台和交付治理之上的值班辅助决策闭环。它的目标不是替代值班员做决定，而是在第一轮排查窗口里，自动拼接观测证据、生成结构化诊断，并把结果回收到 Incident 上下文中。

系列导航

• 微服务治理：从 Git 托管 YAML 到 Nacos
• 容器平台：ACK 微服务容器平台建设
• 网关与流量治理：APISIX 与蓝绿灰度发布
• 可观测平台：指标、日志、链路三层建设
• 交付平台：从 Jenkins 到 GitOps
• AIOps / AI RCA：从可观测到智能故障分析

正文

如果说前面的平台建设，已经逐步解决了这些问题：

• 服务怎么跑
• 服务运行在什么样的平台上
• 外部流量怎么进入系统
• 指标、日志、链路这些运行信号如何被采集和关联

那么接下来的一个非常现实的问题就是：

当凌晨告警真的响起来时，值班员到底能不能更快地把这些信号变成第一轮可用判断？

这也是我们继续往 AI RCA 方向演进的起点。

很多团队在做完可观测平台之后，都会发现一个很相似的现象：
系统里的数据已经越来越全了，指标、日志、链路也都能查，但值班仍然很累。真正辛苦的那一段，并不是“系统里没有数据”，而是告警触发之后，人还要自己跨多个系统去查、去拼、去判断，再把结论同步给其他人。

从这个角度看，AI RCA 想进一步压缩的，并不是“告警触发”这件事，而是“从告警到第一轮联合排查”之间的那段时间。

如果要先用一句话概括它的价值，我会更愿意这样说：

如果说可观测平台解决的是“数据看得见”，那么 AI RCA 解决的就是“值班时怎么更快把这些数据变成第一轮可用判断”。

一、为什么有了可观测，值班还是累

在很多理想化想象里，只要把指标、日志、链路建设完整，值班效率就会自然提升。
但真实情况并没有这么简单。

一个很典型的值班场景是这样的：

告警响起之后，值班员通常还要继续做一串非常熟悉的动作：

• 打开 K8s 或容器平台，看 Pod、事件和重启状态
• 打开 Grafana，看 CPU、内存、RT、错误率曲线
• 打开日志系统，搜某段时间窗口内的报错
• 打开链路系统，查某次异常请求经过了哪些服务
• 再把这些零散信息拼成一个初步判断

如果问题稍微复杂一点，后面还会继续发生：

• 在群里贴截图
• 描述当前假设
• 拉相关同学进群
• 再次解释“我现在看到的是什么”

这个过程中，最大的成本往往不是“某一项技术查询太慢”，而是下面几种隐性成本叠加在一起了：

• 跨系统切换成本
• 上下文重新加载成本
• 证据拼接成本
• 沟通同步成本

也就是说，值班的痛点并不只是“缺数据”，而是这些数据虽然已经存在，却还没有在告警之后被自动收敛成一轮结构化判断。

所以从平台视角看，Missing 的并不是更多监控，而是下面这一步：

在告警触发后的第一轮排查窗口里，谁来自动拼接这些分散信号，并给出一份可供人继续判断的结构化结果？

这就是 AI RCA 在我们这里真正切入的位置。

二、AI RCA 在这里到底解决什么问题

一提到 AI RCA，最容易出现两种误解。

第一种误解，是把它理解成自动处置系统。
好像 AI 既然能分析，那下一步自然就应该直接重启服务、回滚版本、切换流量。

第二种误解，是把它理解成聊天机器人。
好像只要把 LLM 接进值班群，能回答几个问题，就已经叫 AI RCA 了。

这两种理解，在我们的场景里都不准确。

AI RCA 在这里真正要解决的，不是“替代值班员做决定”，而是：

• 在告警触发后自动拉起一轮分析
• 主动去查询相关观测信号
• 把指标、日志、链路等证据拼接起来
• 给出结构化的根因假设、证据引用和建议
• 再把这份结果回收到 Incident 上下文，并投递成补充通知

所以它更像一个“辅助决策闭环”，而不是一个“自动执行引擎”。

如果要把边界说得更明确一点，可以直接这样理解：

不是什么	而是什么
自动处置系统	辅助决策系统
值班替身	缩短第一轮联合排查时间的系统
聊天机器人	围绕 Incident 运行的分析闭环
自由问答	有对象、有状态、有证据引用的诊断流程

这个边界非常重要。

因为生产环境里的自动处置门槛远高于辅助决策。
证据不完整、判断不稳定、组织接受度、审批与审计要求，这些都会决定第一阶段更合理的方向，不是“让 AI 直接动生产”，而是先让 AI 在值班场景中把第一轮判断做得更快、更结构化、更可引用。

所以第一阶段的目标非常克制：

不替代人做决定，只帮助人更快拿到第一轮可用判断。

三、它不是一次 AI 对话，而是一条平台闭环

如果只是把问题表述成“AI 帮忙分析一下告警”，那这件事很容易被理解成一次简单调用：告警来了，丢给 LLM，生成一段回答，结束。

但真实平台设计并不是这样工作的。

在我们的实践里，AI RCA 不是一次临时对话，而是一条有对象、有状态、有生命周期的平台闭环。它至少会经过下面这些核心对象：

• Alert Event
• Incident
• AI Job
• Evidence / Diagnosis
• Notice

从外部读者角度看，你可以把它理解成这样一条简化主链路：

alert event -> incident -> ai job -> evidence/diagnosis -> notice

这条链路的意义，不只是“顺序更完整”，而是它让 AI RCA 不再停留在一个瞬时输出，而变成一个可追踪、可回看、可继续演进的对象闭环。

这里面每个对象都承担着不同职责：

• 告警不是直接喂给 AI，而是先要定义它属于什么问题
• 问题不是一条消息，而要被收敛成 Incident
• 分析不是一次同步调用，而要有 AI Job 承接
• 输出不是一段自由文本，而要沉淀成可引用的 Evidence 和 Diagnosis
• 最后结果不是停在平台里，而要通过补充通知回到值班协作链路

也正因为这样，我们一直不把它理解成“聊天机器人接值班群”。因为真正要做的是平台闭环，而不是会话体验。

四、为什么 AI RCA 能成立，前提其实是前面那些平台能力

如果只看结果，很容易误以为 AI RCA 是在平台上“额外叠了一层 AI”。

但回头看会发现，它并不是凭空长出来的。它之所以能在值班场景里真正落地，前提恰恰是前面这些平台能力已经逐步结构化了。

1. 运行时治理提供了清晰的环境和服务边界

在 Nacos 那篇里，我们已经把配置治理和服务发现治理统一到运行时模型中。
这意味着服务属于哪个环境、如何被发现、运行边界怎么定义，这些信息已经不是散乱的背景知识，而是平台可以理解的结构。

2. 容器平台提供了工作负载状态和运行时承载

在 ACK 那篇里，我们已经让工作负载开始以 Kubernetes 对象的形式存在。
Pod 状态、探针、滚动更新、资源变化、节点调度，这些都让平台第一次可以更稳定地理解“服务现在运行得怎么样”。

3. 入口治理定义了流量如何进入系统

在 APISIX 那篇里，入口流量的规则化、环境切换和运行面边界也已经变得更清楚。
这让平台不仅知道服务在内部怎么跑，也知道请求是如何进入系统的。

4. 可观测平台提供了可关联的信号基础

在上一篇三层可观测里，我们已经把指标、日志、链路组织成了一条可关联的定位链路：

• 指标发现异常
• 链路还原请求路径
• 日志补足实例证据
• trace id / span id 让日志与链路可关联

这一步其实是 AI RCA 最重要的前提之一。因为没有这些结构化信号，AI RCA 就很难从真实系统里拿到足够可用的证据。

5. 交付治理让 deploy change 开始拥有统一状态面

在 Jenkins 到 GitOps 那篇里，我们又开始把 deploy change 收敛成平台对象和统一状态面。
这意味着将来 AI RCA 在做根因分析时，不只是能看观测信号，也更有机会把“最近有没有变更”“哪个 change 最可疑”这类信息纳入上下文。

所以从这个角度看，AI RCA 不是凭空长出来的一层 AI，而是建立在前面运行时、入口、观测和交付这些结构化平台能力之上的上层闭环。

AI RCA 不是多长出来的一层 AI，而是平台能力积累到一定程度后，值班闭环自然往前推进的一步。

五、这件事最重要的三个工程判断

如果要把 AI RCA 这件事真正讲透，最值得写的并不是某个工具怎么接，而是它背后几个关键判断。

1. 辅助决策，而不是自动处置

这是第一阶段最关键的边界。

原因并不复杂：

• 证据覆盖率不可能永远完整
• 诊断置信度不可能永远稳定
• 生产环境里的处置动作风险远高于诊断动作
• 组织对“AI 提供建议”和“AI 直接动生产”的接受度也完全不同

所以第一阶段最合理的目标，不是让 AI 替值班员执行操作，而是让它先把值班员最耗时间的那一段分析动作自动化掉。

2. 平台对象闭环，而不是一次 AI 对话

如果只是做一轮 LLM 调用，系统当然也能“给出一段分析结果”。
但这很难成为真正的平台能力。

因为生产值班场景要的不是“一段回答”，而是：

• 哪个告警触发了分析
• 它属于哪个 Incident
• 这次分析对应哪个 AI Job
• 证据和诊断是否被持久化
• 补充通知有没有被成功投递
• 后续排障和复盘是否还能回看

也就是说，AI RCA 必须围绕对象和状态组织，而不能只围绕会话组织。

3. 控制面和执行面必须分层

AI 分析执行时间本质上不稳定，外部工具调用会失败，LLM 本身也有不确定性。
如果把这些执行逻辑直接塞进 API 服务里，控制面和执行面的故障域就会混在一起。

所以更合理的方式是：

• 控制面负责接住对象、维护状态、协调生命周期
• 执行面负责真正运行分析任务
• 两者通过平台对象和状态机衔接起来

对外看，这只是一个平台能力；
对内看，它其实是一个很明确的控制面/执行面分层系统。

六、一次值班体验到底改善了什么

如果只讲架构和对象，很容易让这篇文章显得过于抽象。
但它真正有说服力的地方，其实还是值班体验本身的变化。

在传统流程里，告警触发之后，值班员通常要自己做这些动作：

• 打开多个系统
• 搜索多个时间窗口
• 拼接多个来源的证据
• 组织成一轮判断
• 再把判断同步给其他人

而在 AI RCA 进入之后，这段流程开始发生变化：

• 告警触发后，平台自动拉起分析任务
• 相关观测信号被自动查询和组织
• 一份带根因假设、证据引用和建议的结构化结果被生成出来
• 结果会补充回 Incident 上下文，并投递到通知链路里

从人的视角看，最大的变化并不是“AI 帮我看到了更多数据”，而是：

原来那段最耗脑力、最耗切换成本的“第一轮证据拼接”，开始被平台接过去了。

值班员不再需要先打开很多系统，才能勉强开始形成判断；平台会先把一份初步判断摆到他面前，他再决定接下来怎么继续验证、怎么拉人、怎么推进。

这并不意味着 AI 已经替代人完成了 RCA。
但它的确让值班闭环往前推进了一步。

七、它明确还不做什么

这一点我反而觉得很重要。

因为很多 AI 文章最大的问题，不是做得不够，而是承诺太多。尤其在生产值班这种高风险场景里，边界意识比能力清单更重要。

所以这件事在第一阶段，我们非常明确地不做这些事：

• 不做自动处置
• 不承诺所有问题都能稳定输出高置信度根因
• 不把 AI 当成值班替身
• 不把自由对话当成 RCA 平台能力本身

第一阶段真正聚焦的，只有一件事：

让告警触发后的第一轮判断更快、更结构化、更可引用。

八、结语：从可观测到 AI RCA，不是多一个 AI，而是把值班闭环往前推了一步

回头看这条演进路径，会发现它其实很自然。

一开始，我们解决的是服务怎么跑、环境怎么治理、入口怎么组织。
接着，我们解决的是指标、日志、链路如何被采集和关联。
而当这些基础能力逐渐稳定之后，值班闭环中最耗人的那一步，就开始自然暴露出来：

• 数据已经有了
• 但第一轮判断仍然主要靠人手工拼接

AI RCA 想解决的，正是这一段。

它不是一个“聊天机器人值班助手”的轻量故事，也不是一个“AI 自动修生产”的激进故事。
在我们的实践里，它更像是一层建立在运行时平台、可观测平台和交付治理之上的辅助决策闭环。

如果说可观测平台让系统问题变得看得见，
那么 AI RCA 让值班员第一次更快地拿到了“第一轮可用判断”。

它不是替代人做决定，而是把值班闭环从“看数据”进一步推进到“基于证据做判断”。

如果要用一句话来总结这次实践，我更愿意这样说：

从可观测到 AI RCA，不是多了一层 AI，而是值班闭环第一次被平台继续往前推了一步。

延伸阅读

• 如果想看更完整的 AI RCA 设计深潜，可以继续读内部系列里的主链路、控制面/执行面、AI Job 租约、告警治理、补充通知和 Skills 装配几篇
• 如果想理解这篇文章的基础前提，建议先读前面的可观测平台、交付平台和入口治理几篇