无指责复盘报告（postmortem）怎么写？

更新时间：2026-09-19。短答页。复盘不是为了找人背锅，而是让同一类事故不再发生。

一句话回答

按「摘要与影响面 → 时间线 → 根因（触发原因 + 5 Whys）→ 做得好的与不足 → 少量可验收的改进项」写，全程假设「当事人在当时信息和压力下做了合理选择」，问题归因到系统和流程而非个人，行动项必须有 owner、期限并跟踪到关闭。

报告结构

1. 摘要：什么时间、什么现象、影响多久、严重等级，一句话。
2. 影响面（用数据）：受影响用户/请求比例、SLO 损耗、订单/资损，而不是「部分用户受影响」。
3. 时间线：T0 故障开始 → 告警触发 → 人 ack → 定位 → 缓解 → 恢复，每步带时间戳。借此拆分 MTTR：是发现慢、定位慢还是修复慢。
4. 触发原因 vs 根因：触发原因是导火索（某条慢 SQL），根因是让它变成事故的系统缺口（没评审卡点、没慢查询告警、没容量保护）。
5. 5 Whys：连问为什么，直到落到可修复的系统/流程层，不要停在「某人疏忽」。根因通常有多个。
6. 做对了什么：正向强化（监控及时发现、回滚果断），别只写问题。
7. 改进项 action items：3~5 个高价值、SMART、有 owner 和期限。

5 Whys 示例

为什么 5xx 升高？ 连接池耗尽
为什么耗尽？       一条慢 SQL 长期占用连接
为什么有慢 SQL？   新查询没走索引，预发数据小没暴露
为什么没拦住？     发布流程没有 DB 变更卡点
→ 行动：CI 加 SQL EXPLAIN 检查、慢查询/连接池饱和度告警、大表变更评审 checklist

行动项要覆盖三类

• 预防：让故障难发生（灰度、卡点、评审）。
• 检测：让故障更快暴露（补告警、黑盒探测）。
• 缓解：发生后影响更小（降级开关、自动回滚、容灾）。

每条最好能转成一个测试/告警/混沌实验来验证有效，并在下次例会回顾完成率，详见无指责复盘完整方法。

blameless 的关键

• 不把结论写成绩效处罚，否则下次大家隐瞒细节，根因永远问不出来。
• 问「当时为什么觉得那样做是对的」，还原决策上下文，而不是事后诸葛亮。
• 报告对团队公开、沉淀成可检索的复盘库。

坑

• 结论停在「某某误操作」，没有系统层改进，换个人还会犯。
• 行动项写成「加强监控、注意规范」，无法验收也无人负责。
• 只回滚了事，不挖根因，同类问题换形态复发。
• 报告写完归档，从不跟踪行动项关闭。

总结

无指责复盘以「人人在当时处境下都做了合理选择」为前提，用数据写影响面、按检测响应缓解恢复拆带时间戳的时间线，用 5 Whys 把触发原因追问到系统和流程层面的多个根因，同时记录做对的动作；最终产出少量覆盖预防、检测、缓解三类、有 owner 和期限、可通过告警或演练验收的 SMART 改进项并跟踪闭环，报告对内公开且不与绩效挂钩，才能把一次事故转化为组织能力。