故障复盘模板

故障复盘模板：把一次事故变成六份可执行的改进

事故复盘的目的不是追责，而是让同样的故障不再发生第二次。很多团队把复盘会开成了“批斗会”，或者更常见的情况是——复盘文档写完之后躺在 Wiki 里再也没人看。一份好的复盘，靠的不是华丽的格式，而是结构化的记录加上真正被落实的改进项。下面这套模板结合了 Google SRE 的实践，可以直接拿去用。

复盘结构：六个固定板块

1. 事故摘要。用三到五句话说清楚：发生了什么、什么时候发生、影响了谁、持续了多久。摘要要让一个没参与的人也能快速看懂。

2. 时间线。按时间顺序记录关键事件，精确到分钟，使用 UTC 时间避免时区歧义。时间线要“记录事实，不做评价”，比如写“12:03 收到告警”，而不是“12:03 我们才开始慌”。

3. 根因分析。用“5 个为什么”逐层追问，直到找到系统层面可以改变的东西。根因往往是多个因素叠加：比如“数据库连接池耗尽”背后可能是“监控阈值设得太晚”+“连接没有设置超时”+“发布前没有压测”。

4. 影响范围与损失。量化影响：多少用户受影响、多少笔订单失败、营收损失估算、SLA 违约时长。数字越具体，改进项越有说服力。

5. 临时修复与长期修复。先写“怎么让它先跑起来”（回滚、重启、扩容），再写“怎么让它以后不犯”（代码修复、架构调整、流程改进）。两类都要写，很多团队只写了长期修复，却忘了记录当时的止血手段，下次遇到同类问题还要重新摸索。

6. 责任人与截止时间。每个改进项必须有明确的负责人和截止时间，并在下次复盘时逐条确认状态。

一条最重要的原则：不做个人归咎

复盘的语言要用“系统视角”：不说“某某某操作失误”，而是问“为什么系统允许这种误操作发生”。这不仅是文化问题，更是效率问题——一旦开始追责，参与者就会倾向于隐瞒细节，下一次复盘的数据质量就会下降。Google SRE 把这条原则叫 blameless postmortem，是能持续产出改进的基石。

一个填写示例（简化）

复盘会议怎么开才高效

• 控制在 45-60 分钟，不要在会上当场写文档，会前先把时间线拉好
• 主持人负责控场，把“是谁的错”的讨论拉回“系统哪里需要改”
• 结论必须落到改进项清单，没有改进项的复盘等于白开

复盘文档建议沉淀到团队都能访问的地方（如 Wiki 或仓库），并给每个改进项建一条可跟踪的待办。建议顺手统计两个数字：MTTR（平均恢复时间）和“改进项按时完成率”，它们比“这个月没出事”更能反映复盘的长期价值。

事故分级与复盘门槛

不是所有故障都值得写完整复盘，但也不能只复盘“大事故”。建议给事故定级：

分级的意义在于让有限的复盘精力花在刀刃上，同时保证 P0/P1 有硬性的“截止时间”。复盘本身也是一种演练——平时多做低成本的 P2 复盘，真到 P0 的时候团队才有默契。

复盘产出要不要纳入考核？ 建议把“改进项是否按期完成”纳入跟进机制，而不是用“这个月没出事”当指标。出事频率下降，靠的是改进项真的被执行。

参考：Google SRE 关于事故复盘文化的章节 https://sre.google/sre-book/postmortem-culture/
参考：Atlassian 事故复盘指南 https://www.atlassian.com/incident-management/postmortems