事故响应与复盘：五分钟止损、一天说明、七天复盘

事故里的第一分钟决定后面的一小时。

一、八十二分钟里他做了什么

一次错误的迁移脚本，把一张表的字段类型改了。凌晨一点，写入开始失败。

贺川先查日志，再连数据库，再试图手工改回去。他试了三次，每次都被外键挡住。第八十二分钟，他从备份恢复到一个临时库，比对后重建了那张表。

事后他写复盘，只写了一句话：「迁移脚本没测。」三个月后，同一个位置又出了一次类似的问题。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

事故里最贵的是顺序错。 先恢复服务，再找原因；他反过来了，所以花了八十二分钟。

顺序要靠清单固定。 靠记忆的人在压力下会退回到「先看看哪里错了」，这正是最慢的一条路。

没有复盘的复盘，等于没有。 一句「没测」不是根因，是一句自我批评；它不会改变下一次的行为。

二、五分钟内三选一

止损只有三个动作，必须在五分钟内选一个。

先选动作，再找原因。 原因可以事后查，用户等不了；五分钟内没做决定，就等于选择了「让故障继续」。

不确定时选可逆的那个。 回滚与关开关都能撤回，切换备用会留下状态不一致；先选能退回来的。

回滚优先级最高。 只要怀疑是新版本引起的，先回滚；12 分钟的确定性，胜过 40 分钟的热修赌博。

开关比回滚更快。 2 分钟关掉一个功能，能把影响面从「全站」缩到「一个入口」。

切换备用要谨慎。 只读模式会让写入排队，恢复后要补；切之前先确认队列能撑住。

写下你选了什么。 事故记录里第一行写动作与时间，复盘时才知道当时的判断依据。

三、止损、说明、复盘

三段各有明确时限，不要互相侵占。

止损阶段不看根因。 看根因会把你拖进分析，而用户还在等；这个阶段只回答「怎么先停下」。

止损后立刻记时间。 发现、动作、恢复三个时间点当场写；过一小时再回忆，误差会有十分钟。

说明阶段要写给用户。 内部时间线可以粗糙，对外公告必须包含恢复时间、影响范围与是否需要用户操作。

复盘阶段要写系统，不写人。 「迁移脚本没测」应改成「迁移脚本没有在预发库跑过一次回滚」；前者是责备，后者是可执行的控制。

行动项不超过三条。 十条行动项等于没有行动项；挑最靠近根因的三条，30 天内做完。

收尾要看验证结果。 加了一条检查还不够，要在下一次发布里确认它真的拦住了问题。

四、复算与复盘模板

先算清楚时间花在哪，再决定改什么。

4 次事故、累计 138 分钟 → 平均 34.5 分钟/次
构成：回滚 8 分钟 + 关开关 6 分钟 + 数据库恢复 82 分钟 + 依赖故障 42 分钟
自因 = 8 + 6 + 82 = 96 分钟；依赖 = 42 分钟；合计 138 分钟
82 ÷ 96 = 85.4% 的自因停机来自那一次数据库恢复
把它压到 30 分钟：138 − 52 = 86 分钟 → 可用性 99.93%
目标 MTTR ≤ 30 分钟；当前 34.5 分钟，差距主要在恢复演练

一次事故决定整体水平。 82 分钟占了自因停机的 85.4%；修好这一处，比优化另外三次更有价值。

长尾事故要单独归类。 数据类故障少但长，回滚类故障多但短；两类要分开定目标，不能用一个 MTTR 平均掉。

恢复时间是练出来的。 备份有，但没演练过，恢复就会在真事故里第一次跑；把演练写进季度计划。

MTTR 要按事故类型分开算。 回滚类事故的 MTTR 是 8 分钟，数据类事故是 82 分钟；混在一起会掩盖真正的短板。

复盘模板五段。 时间线（精确到分钟）、影响（账户数与订单数）、根因（系统层面）、处置（做了什么、耗时多少）、行动（三条、带负责人与截止日）。

复盘要公开给用户一个版本。 不必写内部细节，但要说清发生了什么、影响多久、改了什么；这比任何道歉都有效。

时间线要写「当时以为」。 记录判断依据，才能发现是信息不足还是判断错误；只写结果，下次还会犯同样的错。

五、行动清单与复算验收

把三选一写在纸上，比记在脑子里可靠。

• 为回滚、关开关、切备用各写一句触发条件。
• 测一次回滚，记录真实耗时。
• 规定止损 5 分钟、恢复 30 分钟、说明 24 小时、复盘 7 天。
• 建一份五段式复盘模板，放在触手可及的位置。
• 每次事故记录影响账户数与订单数，不写「部分用户」。
• 复盘行动项不超过 3 条，各带截止日。
• 每季度演练一次数据库恢复，目标 30 分钟内。
• 30 天后回看行动项是否完成并验证。

验收标准：事故发生时，你能在五分钟内选出一个止损动作并在 30 分钟内恢复；事后能拿出五段式复盘与三条行动项，做不到说明你的响应还靠临场反应。

使用边界与实操验收

本文处理的是一人产品的事故响应与复盘，不涉及安全事件与法律通知。

安全事件不归本文。 数据泄露、账号被盗与监管通知另有一套流程，处置顺序也不同。

根因分析不必追到最深。 追到「可以直接改的那一层」就够；再往下会变成哲学讨论。

别把复盘写成检讨。 检讨针对人，复盘针对系统；前者让人隐瞒，后者让人说真话。

行动项要能验证。 「加强测试」无法验证；「迁移脚本必须在预发库跑一次回滚」可以。

事故记录要留原文。 公告、聊天记录与日志时间戳都保留；一个月后记忆会美化过程。

小事故也要记。 五分钟恢复的事故同样写三行；不记，就看不到趋势。

不要同时做两件事。 止损与沟通可以并行，止损与根因分析不能；一个人更要注意顺序。

关键参考与核验范围

核验日期：2026-10-25。以下链接用于核对事故响应与复盘的一般做法，本文未逐条引用其内容。

• Google SRE：管理事故 ：用于核对事故中的角色、沟通与止损顺序。
• Google SRE：事后复盘 ：用于核对无责复盘的结构与文化前提。

引用口径。 本文只借用「先止损、再说明、后复盘」这一一般顺序；4 次、138 分钟、82 分钟与 30 分钟全部是教学假设，与上述材料无关。

核验范围。 核验的是「三选一能否在五分钟内做出」，不是比对某家事故管理平台的功能。

如何自行复核。 取最近一次事故，从发现到第一个止损动作之间隔了几分钟；超过五分钟，就把三选一打印出来贴在桌前。

系列导航

• 上一篇：发布后的 24 小时：观察窗口、回滚判据与冻结期
• 下一篇：运维验收：十项控制、四张表与月度巡检
• 回到目录：一个人的运维：可用性、告警、事故与值班
• 相关阅读：事故响应：被盗、被封、被停机、域名劫持的 72 小时