事故复盘怎么做：不是追责，而是让系统更可靠
摘要
事故复盘的目的不是找一个人背锅，而是理解事故为什么会发生，系统哪些环节没有防住，未来如何降低类似问题再次出现的概率。好的复盘关注事实、时间线、影响范围、根因、修复动作和长期改进。
复盘不是批斗会
很多人害怕复盘，因为复盘常常变成追责。
谁犯了错，谁没检查，谁上线前没发现。这样的讨论短期看起来有交代，长期却会让大家隐藏问题。
真正有价值的复盘，不是否认个人责任，而是把重点放在系统如何让错误发生。
如果一个错误很容易由任何人犯出来，就不能只靠提醒某个人小心。
复盘要让系统更可靠，而不是让人更害怕。
先还原事实时间线
复盘第一步，是建立事实时间线。
什么时候出现异常？谁发现的？影响了哪些用户或流程？采取了哪些动作？什么时候恢复？中间有哪些判断和延迟？
时间线要尽量基于证据，而不是记忆。
日志、监控、提交记录、沟通记录、任务状态，都可以帮助还原。
没有事实时间线，复盘很容易变成情绪讨论。
大家各自记得一部分，最后谁也说不清事故真正如何发生。
区分直接原因和根因
事故通常有直接原因，也有更深的根因。
直接原因可能是某次配置错误、某段代码缺陷、某个接口失败。
根因可能是没有自动检查、权限边界不清、发布流程缺少回滚、监控没有覆盖、需求变更没有同步。
只修直接原因，类似问题可能换个形式再来。
好的复盘会问：为什么这个错误没有被更早发现？为什么系统允许它造成影响？为什么恢复花了这么久？
这些问题比“谁点错了”更有价值。
影响范围要说清楚
事故复盘必须回答影响范围。
影响了多少用户？哪些功能不可用？持续多长时间？是否造成数据错误？是否需要通知用户？是否影响后续任务？
影响范围不是为了让事故显得严重，而是为了决定修复优先级和沟通方式。
小问题可以内部修复，大问题需要公开说明或额外补救。
如果影响范围不清，团队很容易低估或高估事故。
改进动作要可执行
复盘最后必须落到行动。
“以后注意”“加强测试”“提高意识”都太空。
更好的改进动作应该具体：
- 增加发布前自动检查。
- 为关键流程增加失败重试。
- 补充错误日志和告警。
- 为高风险操作增加确认。
- 写清回滚步骤。
- 给某个模块补测试。
每个动作最好有负责人和完成时间。
否则复盘会变成一次认真会议，结束后系统没有变化。
也要记录做得好的地方
复盘不只看失败。
如果某个监控及时发现问题，某个同事快速定位原因，某个流程减少了损失，也应该记录。
这能帮助团队知道哪些机制有效，未来继续保留和加强。
复盘的目标不是制造羞耻，而是学习。
学习包括修正问题，也包括识别有效做法。
结论
事故复盘怎么做？先还原事实时间线，再区分直接原因和根因，说明影响范围，制定可执行改进动作，并记录有效机制。
复盘不是追责，而是让系统下次更不容易以同样方式失败。
一个团队如何面对事故，往往决定它能不能真正变可靠。
