10-5 Whys 事故复盘模板与案例¶

目标：把复盘从“写一篇事故总结”升级成“持续消灭重复性问题”的机制。

图源：Wikimedia Commons - Ishikawa Fishbone Diagram.svg，CC BY-SA 3.0。鱼骨图不是 5 Whys 的唯一形式，但非常适合配合 5 Whys 做根因分类与展开。

一、为什么要学 5 Whys¶

很多复盘最后都会停在一句没有价值的话上：

• “某同学误操作”
• “某个版本有 bug”
• “当时没注意到”

这样写，下一次问题还会再来。

5 Whys 的意义，在于强迫你继续往下追：

• 为什么这个问题会发生
• 为什么它能进入生产
• 为什么现有流程没有拦住
• 为什么监控没有更早发现
• 为什么团队会把这个风险判断错

真正有用的复盘，最终一定会落到：

• 技术根因
• 流程根因
• 监控根因
• 责任边界和后续动作

二、一个 AI 事故的简化示例¶

问题：RAG 服务上线后，回答质量显著下降。

Why 1：为什么回答质量下降？
因为新的 reranker 版本排序异常。

Why 2：为什么排序异常还能上线？
因为上线前只做了小样本人工验证，没有完整离线评测。

Why 3：为什么没有完整离线评测？
因为团队没有把 reranker 变更纳入固定的评测门禁。

Why 4：为什么没有门禁？
因为大家把 reranker 调整误判成了“低风险配置变更”。

Why 5：为什么会误判？
因为团队缺少 AI 质量事故分类，也没有沉淀过类似复盘案例。

最后的根因就不再只是“reranker 出错”，而会变成：

• 发布门禁缺失
• 风险分级错误
• 质量监控不完整

这才是复盘真正有价值的地方。

三、最小可用复盘模板¶

## 事故标题

- 时间：
- 严重级别：
- 影响范围：
- 发现方式：
- 恢复时间：

## 事实时间线

- 10:05：
- 10:12：
- 10:18：

## 影响评估

- 用户影响：
- 业务影响：
- 指标影响：
- 错误预算消耗：

## 5 Whys

1. 为什么？
2. 为什么？
3. 为什么？
4. 为什么？
5. 为什么？

## 根因归类

- 技术根因：
- 流程根因：
- 监控根因：

## 修复动作

- 立即修复：
- 长期修复：
- 新增监控：
- 新增门禁：
- Owner：
- Deadline：

四、常见错误¶

1. 把“某人误操作”当成最终根因
2. 只写现象，不量化影响
3. 不写 Owner 和截止日期
4. 只修技术问题，不修流程和门禁
5. 只复盘一次事故，不把经验沉淀成检查项

五、面试里这章的价值¶

如果你能把一次像样的复盘讲清楚，面试官通常会直接得到几个结论：

• 你做过真实项目，而不只是在写 Demo
• 你考虑过 happy path 之外的情况
• 你知道 AI 服务除了“挂掉”以外，还有质量事故和行为事故
• 你有工程成熟度，而不只是实现能力

可以直接这样回答：

我做复盘时不会停在表面原因，而是会继续追到流程和监控层。
如果一次事故暴露出评测门禁缺失、灰度指标缺失或监控盲区，
那这些都要进入长期修复项，而不是只修一个代码 bug 就结束。

六、结论¶

复盘不是事故结束后的文书工作，而是系统能力的一部分。

会做复盘的人，通常更容易被判断为能扛住真实生产环境，因为他不仅会修问题，还会阻止同类问题反复出现。

⚠️ 核验说明（2026-03-29）：本页已重新整理 5 Whys 示例、模板与图片说明。若你的团队已有统一 RCA 模板，可在此基础上映射到团队格式。

最后更新日期： 2026-03-29