故障复盘完全指南 — 从 5-Why 到改进项闭环

来源：不爱笑的青年 | 发布日期：2026-06-22

复盘的价值，不在于写出一份漂亮的报告，而在于同样故障不再发生第二次。

一个真实的教训

某微服务 3 月 15 日发生 OOM Kill，Pod 重启 12 次，业务中断 25 分钟。复盘结论是"内存配置不合理"，改进项"将内存限制从 2Gi 调整到 4Gi"，责任人研发组长，截止日期 3 月 22 日。

6 月 18 日，同一个服务，同样的 OOM，同样的中断——内存限制从未被调整过。改进项创建后，无人跟踪落地。

复盘报告写了不等于复盘结束了。改进项落地才是复盘的结束。

复盘的认知误区

5-Why 分析法 — 追问到可落地的改进项

以 OOM 故障为例：

可落地的改进项：

1. 更新监控配置 Checklist，增加 JVM 内存监控项（运维组长，本周五）
2. 所有微服务添加 JVM 内存监控告警（运维，下周五）
3. 代码 Review 检查单增加"缓存 TTL 配置"检查项（研发组长，本周五）

关键： 追问到有人能动手去改的一项具体工作时，5-Why 才算结束。

复盘报告 7 要素

改进项跟踪闭环

改进项落地才是复盘的句号：

复盘检查清单

复盘前逐项打勾：

1. ☐ 故障后 24h 内召开复盘会
2. ☐ 邀请所有相关方（研发+运维+测试+产品）
3. ☐ 5-Why 追问到可落地改进项
4. ☐ 改进项有责任人+截止日+验收标准
5. ☐ 改进项 24h 内公示
6. ☐ 定期跟进机制已建立
7. ☐ 主持人+Leader 共同验收
8. ☐ 验收通过后归档知识库

关联页面