Castrel AI 如何让多人并行排查同一个故障
复杂故障发生后，排查很快会分成多条线。数据库写入中断时，有人要确认实例为什么无法启动，有人检查磁盘和副本状态，服务负责人需要评估影响，可观测性团队还要追查为什么没有提前预警。这些问题彼此相关，却不适合排成一条等待队列。
过去，团队往往在群聊、工单和临时文档中口头分工。并行工作虽然开始了，故障背景、最新进展和调查证据却散落在不同地方。负责人需要逐个询问，后加入的成员还要重新拼接时间线。更麻烦的是，一条调查修正了关键事实，其他成员未必及时知道，后续判断仍可能建立在旧信息上。
Castrel AI 将故障详情变成多人协作排查的共同入口。一个故障可以承载多项调查任务，成员从共享上下文出发并行工作；活动流和评论保留协作过程，发现与产出物持续回到故障详情。团队还可以围绕整个故障继续询问，让 Castrel AI 创建新的调查任务，并在排查结束后生成故障报告。
一个故障，同时推进四项调查
以下用一个 PostgreSQL 排查场景说明这套工作方式。CloudNativePG 集群中的 postgres-cluster-1 因数据卷空间耗尽进入 CrashLoopBackOff，数据库写入随之中断。故障由人工健康巡检发现，当前记录没有关联警报；如果故障已经关联警报，相关信号也会成为任务共享的故障上下文。
故障被发现时，团队需要同时确认直接原因、存储状态、业务影响和监控缺口。在 Castrel AI 中，这些问题可以拆成不同任务，并通过不同方式发起：
| 调查任务 | 发起方式 | 需要回答的问题 | 返回故障的结果 |
|---|---|---|---|
| 排查生产 PG 主库磁盘满 | Castrel AI 自动发起 | 实例为何无法启动，如何恢复数据库写入 | 直接原因、处置过程和恢复结论 |
| 检查磁盘状态 | 成员手动发起 | 数据卷是否完成扩容，实例与复制状态是否正常 | 存储状态、角色变化和待验证项 |
| 中断服务与影响评估 | 成员手动发起 | 写入中断影响了哪些服务，业务是否恢复 | 影响范围和恢复状态 |
| PostgreSQL 磁盘满告警缺失排查 | 在故障助手中通过 Agent 发起 | 为什么没有提前预警，哪些采集或规则缺失 | 监控缺口、证据和整改建议 |
任务可以同时运行，也可以在排查过程中随新问题继续增加。每项任务保留自己的发起方式、执行状态和完整调查过程，同时共享故障描述、影响应用，以及已经关联的警报和发现。团队无需为每条调查重复整理背景，也不必等待一项总任务依次流转。
新事实通过活动流进入每一条调查
并行排查真正困难的部分是同步事实。这个 PostgreSQL 场景的初始描述将 postgres-cluster-1 判断为主库，并认为它是唯一没有扩容的数据卷。后续调查结合 CloudNativePG 实例角色和云盘状态修正了两点：实际 primary 是 postgres-cluster-2，而三个数据卷最终都已扩容到 500 GiB。
这类修正会改变下一步该检查什么。Castrel AI 将任务创建、完成或中断、添加发现、评论和标记根因报告等事件记录在故障活动流中。存储和角色变化确认后，成员可以在评论中说明新的主从关系，提醒复制调查调整检查对象。其他成员看到的是更新后的排查依据，不需要等待负责人再次转述。
故障详情也支持评论和回复。成员可以补充人工确认、提出待验证问题，或解释一项操作对其他调查的影响。讨论与故障保存在一起，交接时既能看到结论，也能知道结论是在什么条件下形成的。
从故障提问，可以直接发起新的调查
故障详情右侧的 Castrel AI 助手使用当前故障作为上下文。负责人可以询问已经确认了哪些原因、哪些问题仍在阻塞恢复，或主库切换后还存在哪些风险。更重要的是，询问可以继续转成调查任务。
在这个场景中，成员直接让 Castrel AI 创建一项新任务，调查为什么没有提前告警，以及缺少哪些采集或告警规则。Castrel AI 随即创建新的调查，检查生产 Prometheus 的指标和规则，并将结论写回故障的「发现」。
调查确认，kubelet_volume_stats_* 没有可用序列，cnpg_* 指标也缺失；现有 156 条告警规则中没有磁盘容量或 PVC 用量规则。这说明漏报同时发生在采集和规则两层。负责人无需离开故障详情重新创建任务、复制背景，再把调查结果手动搬回来。
任务结果回到故障，最后形成根因报告
多项调查会产生各自的发现和产出物。Castrel AI 在故障详情提供统一的任务入口，并汇总当前现状、「发现」和「产出物」。负责人可以先在故障层面查看结论和核心证据，需要核对执行细节时再进入对应任务。这减少了在多个任务页面之间寻找结论的工作。
汇总视图也让团队区分三种状态：已经确认的事实、已经修正的早期判断，以及尚未闭环的问题。这个场景已经确认磁盘耗尽触发实例拒绝启动，三个数据卷完成扩容，数据库写入恢复；初始主库角色判断得到修正。至于磁盘为什么写满，现有监控仍无法回答，需要后续通过 df、du 或补齐采集继续验证。
排查接近结束时，团队可以让 Castrel AI 汇总故障上下文、活动记录、任务产出和发现，生成故障调查报告。报告包含结论、时间线、事实修正、影响范围、整改建议和待跟进项，还可以被标记为故障的根因报告，作为后续复盘与交接的共同记录。
服务恢复后，团队不必把剩余问题留在某个成员的聊天记录里。「为什么写满」仍然作为待验证项保留在根因报告中，下一位接手者可以沿着同一份证据继续调查。下一次出现相似故障时，这份记录也提供了可复用的任务拆分方式、判断依据和监控整改方向。