无指责复盘是什么
无指责复盘（Blameless Postmortem）在事故后还原时间线、找系统与流程的失效点，而不是追究某个人的责任。前提是心理安全：人敢说「我当时点了确认」「监控没响我不知道」。结论必须落到可验证的行动项（谁、何时、改什么），否则复盘会变成故事会。测试侧的落点：这次缺陷为什么没被拦住，缺口补到哪。
基本信息
| 原则 | 对事不对人，假设每个人在信息当下做了合理选择 |
|---|---|
| 结构 | 事故摘要、影响、时间线、贡献因素、行动项 |
| 时间线 | 发现问题、响应、缓解、恢复，含时间戳与当时掌握的信息 |
| 贡献因素 | 多重叠加，通常不是单一根因，深挖每道防线为何没拦住 |
| 行动项 | 负责人加期限加验收方式，录入待办持续跟踪 |
| 测试复盘 | 为什么漏检：用例缺、环境差异、回归未覆盖，逐一补测试资产 |
时间线示意
时间线示意
14:02 发布 v2.4.1
14:15 监控告警：订单错误率上升
14:20 值班确认，启动回滚
14:31 服务恢复，影响窗口 29 分钟
贡献因素：灰度批次过大 / 回归未覆盖该配置组合 / 告警延迟典型使用场景
- 线上事故复盘：还原过程找系统缺陷
- 缺陷逃逸分析：为什么回归没拦住这个缺陷
- 行动项跟踪：每季度盘点完成率与效果
- 团队文化建设：新人看到「说真话不吃亏」的实际案例
- 演练复盘：混沌工程与容灾演练的改进输出
要素与常见错误
| 要素 | 常见错误 | 正确做法 |
|---|---|---|
| 时间线 | 写成追责线索 | 记录行为与当时信息 |
| 根因 | 强行归结单一原因 | 列出多重贡献因素 |
| 行动项 | 「加强意识」 | 改成具体的系统或流程改动 |
| 发布 | 邮件一发就结束 | 归档并跟踪到关闭 |
「加强测试」「更细心」不是行动项：不可验证的动作等于没做。行动项要么改系统（自动拦截），要么改流程（评审点与门禁）。
复盘文档应对参与者公开：信息对称才能挖出贡献因素；保密反而让人猜疑，下一次没人再讲真话。
行动项不设负责人与期限就会永远挂着：每个行动项都要能回答「谁在何时用什么方式验证它做完了」。