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

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

一、为什么用 5 Whys¶

很多复盘的问题是：

只写表面现象
只怪某个操作失误
没有流程和系统层结论

5 Whys 的意义是强迫你继续往下问：

为什么会这样？
为什么这个问题没有提前被发现？
为什么现有流程没有拦住？
为什么监控没有报警？

二、一个简单示例¶

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

Text Only

Why 1: 为什么答案质量下降？
→ 新 reranker 版本排序异常

Why 2: 为什么排序异常还能上线？
→ 上线前只做了小样本手测，没有完整离线评测

Why 3: 为什么没有完整离线评测？
→ 团队没有固定评测门禁流程

Why 4: 为什么没有流程？
→ 之前把 reranker 调整当作“低风险配置变更”

Why 5: 为什么会误判为低风险？
→ 缺少对 AI 质量事故的分类和历史复盘沉淀

最终根因就不只是“reranker 出错”，而是：

发布流程缺失
评测门禁缺失
风险分级错误

三、复盘模板¶

Markdown

## 事故标题

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

## 事实时间线

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

## 影响评估

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

## 5 Whys

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

## 根因归类

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

## 修复动作

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

四、常见错误¶

把“某人误操作”当作最终根因
不量化影响
不写行动项 owner 和截止时间
只修技术问题，不修流程问题

五、面试中的价值¶

如果你能讲出一个像样的复盘，面试官会直接判断你：

做过真实项目
不是只会 happy path
有工程 maturity

六、结论¶

复盘不是事故结束后的文书工作，而是系统能力的一部分。
会复盘的人，通常更容易被判断为能扛住真实生产环境。