2026 年以来，大模型的能力继续突飞猛进，很多企业都在探索如何用好大模型，Flashcat 也在已有的智能化思路上继续演进。
截止 5 月份，我们基本想明白并验证了可观测性要用好 AI 的几个关键，并为 FlashAI（Flashcat 内置的可观测性 AI Agent）升级了 skill 功能，配备了受控的任务通道。
本文将分享第一个真正震惊到我的智能化故障处理 case。这次典型的真实案例中，新版 FlashAI 从分析异常、建立证据链，到生成修复方案并完成恢复验证，全程“带领”着我完成。
背景
快猫星云有一个云端站点，这个站点为用户提供 Flashcat 的功能试用和预览，该站点有配套的灭火图监控。
某天，本人巡视灭火图，发现两个异常点（飘红）：Kafka 集群与 VictoriaMetrics 集群异常。
本文聚焦其中的 Kafka 异常，介绍 FlashAI 如何基于灭火图信息以及任务通道，逐步定位问题、验证根因，并在人工确认后完成修复。
说明
在本次排查开始前，没有人掌握异常的既定答案；
该站点的自监控灭火图也由 FlashAI 协助创建；
我本人并不熟悉该云端站点的具体部署方式和模块依赖关系；
一、下钻找到故障点，先看清异常现象
进入 Kafka 异常对象后，可以看到以下现象：
- Kafka 集群中的一个消费组，预估消费延迟已经达到数小时，消息出现严重积压，远高于卡片 10 秒的飘红阈值；
- 预估消费延迟曲线呈锯齿状：每隔数小时会突然下降，随后再次逐步攀升。对应标签为
{consumergroup="fc-self-monitor-group", topic="fc-self-monitor"}； - 消息生产曲线虽然存在波动，但没有出现与积压规模相匹配的异常突增；
- 对应
{topic="fc-self-monitor"}的消费曲线却明显异常：消费量会突然大幅升高，随后又快速回落到接近 0 的水平； - 消费延迟开始持续攀升的时间点接近 00:00。
从这些信号看：消费者似乎在周期性尝试消费，但每次都无法持续完成处理。要继续判断，还需要把 Kafka 指标与上下游组件的实际状态联系起来。
二、从异常卡片触发 FlashAI 自动分析
在异常卡片上直接点击 FlashAI，触发自动分析。
注：与从空白对话框开始不同，FlashAI 会自动带入当前异常对象及其关联的指标、日志、链路和灭火图上下文。这样，分析不必建立在单条告警文本上，而能从系统现场开始。
FlashAI 的初步结论建议继续执行若干分析动作。按传统方式，工程师需要登录机器，手动组织查询并逐项取证。在 Flashcat 中，可以继续请 FlashAI 代为执行这些排查任务。
三、交互式深入排查，自动建立故障因果链
FlashAI 生成了排查任务，并自动识别操作的危险级别；需要访问运行环境或执行有风险的动作时，FlashAI 会请用户确认后才能继续。
完成第一轮排查后，FlashAI 找到关键异常和初步方向：fc-stash 向 Doris 写入数据时发生积压。于是，排查范围从 Kafka 消费组延伸到了下游写入链路。它建议继续检查 Doris 日志，以及 fc-stash 与 Doris 之间的连接状态。
注：fc-stash 为 Flashcat 自研的高性能日志处理器，对标 Elasticsearch 的 logstash；Doris 为 Flashcat 底层所使用的日志存储系统；
下一步我没有直接沿用建议，而是按经验提出了一个排查方向：先查看 fc-stash 日志。FlashAI 按照这一方向向 fc-stash 所在的机器下发排查任务取证。
更多证据随之出现：写入 Doris 的日志不符合目标表的 schema 要求。FlashAI 据此形成了一条可继续验证的因果链，并建议检查 Doris 表与分区状态，而不是停留在“写入失败”的表象上。
FlashAI 同时给出修复方向与进一步确认的建议。为避免基于未验证结论直接变更，请 FlashAI 按照它自己的建议补充查看和确认。
四、确认根因：Doris 表缺少时间分区
经过进一步验证，根因被确定为：Doris 表缺少 20260508 时间分区。
由于对应表的时间分区不存在，00:00 后的数据无法写入 Doris，fc-stash 无法正常完成 Kafka 消费。这个根因也解释了前面看到的两类异常曲线：
fc-stash写入 Doris 失败后会采用退避策略，在约两小时后重新尝试消费，因此消费量会周期性突然上升；- 重试仍因写入失败而快速回落，消息持续积压，消费组的预估消费时长于是呈现锯齿状并不断上升。
在根因与证据已经明确后，FlashAI 给出了操作 Doris 存储的修复方案，以及可以执行的修复 SQL。
五、执行修复：FlashAI 代为操作，但由人确认边界
确认修复方向后，请 FlashAI 代为执行，并特别要求考虑回滚方案。
FlashAI 生成执行任务，并在真正执行前再次发起确认。对于可能影响生产环境的操作，FlashAI 不会绕过授权与确认环节。
确认后，FlashAI 执行修复成功，并判断异常将逐步恢复。
六、异常恢复：真正的“哇塞”时刻
等待 1～2 个周期后，异常如预期恢复，灭火图中的 Kafka 卡片由飘红转绿。这是 AI 在可观测性领域第一个真正震惊到我的“哇塞”时刻！
七、还原异常现场：默认配置如何逐层传导为 Kafka 消息积压
故障恢复后，继续追溯 Doris 分区异常的原因。
FlashAI 分析确认，Doris 的配置中设置后端 BE 为 3 副本，但实际环境中，出于成本考虑只保留了 1 个副本。Doris 在创建动态分区时，会校验 BE 节点数量是否满足副本数要求，不满足则分区创建会失败。
在灭火图中查看 Doris 节点状态，可以确认 5 月 6 日确实发生过上线操作。
完整的异常过程如下：
- 5 月 6 日，Flashcat 云端站点升级；部署 Doris 时使用了默认配置，其中副本数默认设置为 3。
- Doris 创建动态时间分区时，会检查 BE 节点数量是否满足副本数要求；若不满足，动态分区创建失败。
- 升级前已生成
20260507分区，因此 5 月 7 日的业务仍然正常。 - 升级后的 5 月 7 日，BE 副本数不满足配置要求，Doris 无法创建
20260508分区。 - 5 月 8 日 00:00 起，Doris 写入异常；上游
fc-stash随之无法正常写入和消费 Kafka 日志，消费组的预估消费时长逐步升高，最终远超飘红阈值。 fc-stash在写入失败后退避重试，约每两小时重新消费一次；因此消费量会短暂攀升后再次回落，预估消费时长曲线也随之呈锯齿状。
结语：让 AI 真正发挥它的“专家”能力，“带领”你完成故障的排查直至修复
这次故障的表象是 Kafka 消费积压，根因却涉及 Doris 分区、BE 副本数和一次历史升级配置。
对于不了解现场的人来说，要跨越 Kafka、fc-stash 与 Doris 建立完整链路，往往需要反复切换系统、组织查询并人工验证。如果是单人来执行排查，执行者不但需要同时具备这些组件的专家知识，还需要知道在哪里以及如何使用相关的数据查询系统，也包括拥有这些系统的查询权限。
这个排障的门槛相当之高，如果不是“老司机”很难一个人完成类似的排障过程。这类历史上的变更导致今天出现故障的 case，更是提高了排障分析的难度。
但是 AI 就是这个“老司机”，AI 所掌握的“专家知识”相信已经超过了绝大部分的人类专家。今天我们要做的事情就是用好 AI 这个“老司机”，给他把故障系统的上下文准备好，给他安装上任务通道这“双手”，做好权限和风险的边界控制，让 AI 能放手发挥自己的能力，“带领”着你完成整个故障处理过程。 而不是把“老司机”关在笼子里，偶尔给个只言片语，问问他的建议。
很多人看到这里一定会有疑问：故障系统的上下文如何建设？AI 有了自己的“双手”能否保证他不做出类似删库跑路的事情？风险如何控制？这些都是我们为 AI 铺路时做了大量考虑和实现的方向，我将在后续的文章中分享。
