故障复盘是什么
复盘（Postmortem）的目标不是追责，而是把一次故障转成系统改进。做法是用时间线、根因与证据作为输入，通过『5 个为什么』一路追到流程与机制层，输出可验收的行动项（负责人、期限、验收标准）。判断复盘好坏的标准很简单：产出的行动项是否在下一次同类故障前真的生效了。
基本信息
| 输入 | 时间线、直接原因与根本原因、证据、处置记录 |
|---|---|
| 方法 | 5 Whys、变更分析、监控覆盖度审查 |
| 输出 | 行动项清单，每项含负责人、截止时间、验收方式 |
| 节奏 | 重大故障 3 个工作日内出初稿，行动项进入常规跟踪 |
典型使用场景
- 重大故障后统一认知：让相关方对时间线与根因达成一致，避免各说各话
- 行动项闭环：把『加强培训』这类无效结论替换成可验证的系统改造
- 监控盲区发现：如果故障是靠用户投诉发现而非告警，说明覆盖度有问题
- 变更流程改进：多数故障可追溯到某次变更，复盘时检查变更评审与灰度环节
5 Whys 示例
5 Whys 示例
问：网站 502 了 → 答：后端不可达
问：为何不可达 → 答：健康检查全部超时
问：为何健康检查超时 → 答：健康检查源 IP 被安全组拦截
问：为何被拦 → 答：安全组由 IaC 模板下发，模板缺少该规则
问：为何模板缺规则 → 答：模板更新无测试环境验证，直接上生产
→ 行动项：① 模板变更进 CI 校验 ② 生产安全组变更二次确认 ③ 健康检查失败纳入拨测复盘质量对照
| 要素 | 合格做法 | 无效做法 |
|---|---|---|
| 根因 | 区分直接原因与根本原因，两者都写 | 只写『人为操作失误』 |
| 行动项 | 具体到人、期限与验收标准 | 『加强培训』『注意检查』 |
| 数据 | 引用监控与日志的原始数字 | 凭印象描述影响范围 |
| 范围 | 定位到具体变更或机制缺陷 | 笼统归为『网络抖动』 |
没有行动项的跟踪表，复盘等于写作文：把行动项录进常规任务系统并设置提醒，下一季度回顾完成率。
复盘会一旦变成批斗会，后续故障一线会倾向隐瞒与拖延，损失远大于一次故障本身。就事论事、对系统不对人，是复盘能持续开展的前提。