事故过去了，然后呢：vibe 项目的故障复盘实战指南

事故过去了，服务恢复了，群里发了一句“已恢复”，然后呢？对很多一人团队和小团队来说，答案是：然后就没有然后了。下一次同样的事故换个时间再来一次，值班的人还是凭感觉排查，复盘文档如果存在，也只是一句“下次注意”。这篇指南讲的就是事故之后的另一半工作：怎么写一份真正有用的故障复盘（postmortem），让一次事故只交一次学费。

先划清边界。本站此前发过一篇《凌晨 3 点线上挂了，你只有一个人：独立开发者的事故响应 Runbook》，讲的是事故进行时怎么办：分级、止血、回滚、对外沟通。复盘是那篇的下一棒，时间点在恢复之后，目标也不一样：响应追求的是“快”，复盘追求的是“准”——把事故的因果链讲清楚，把改动落到责任人和截止日期上。两篇配合着用，前面管救火，后面管防火；只发一篇，等于只练了半套动作。

本文示例均为虚构：假设你运营一个叫“清单鸟”的小工具，有一天早上用户反馈任务列表打不开。下面所有时间线、数字和人名都是编的，只用来演示写法，方法本身可以直接套用。

第一步：先把时间线钉死，再谈原因

复盘的第一页不应该是原因分析，而应该是时间线。原因可以争论，时间不能含糊。写时间线时坚持三条规则：只写可验证的事实，不写推测；每个节点标明来源（监控告警、部署记录、聊天记录、用户反馈）；用“用户视角”而非“服务器视角”描述影响——“09:12 用户开始反馈列表空白”比“09:12 接口 500 比例上升”更接近事故的真实代价。

以“清单鸟”为例，一份合格的时间线大概是这样：08:47 部署 v2.4.1（改动：任务列表接口加缓存）；09:12 首批用户反馈列表打不开；09:20 值班确认非个例，错误率 38%；09:31 定位到缓存键冲突：新老版本共用同一前缀，旧数据格式被新代码误读；09:40 回滚到 v2.4.0；09:55 错误率回落到基线；10:20 确认恢复并对外发公告。注意，时间线里没有“因为缓存没做好”这种判断，只有“做了什么、观测到什么”。判断留给下一节，混在一起写，复盘会变成各执一词的争论场。

第二步：原因分析要挖到“系统允许它发生”那一层

最常见的复盘毛病，是原因只写到第一层就停了：“缓存键冲突导致故障。”这句话没错，但没用——它没有告诉你下次怎么防止。有效的办法是连续追问“为什么”至少三层：为什么会冲突？因为新老版本共用了缓存键前缀，发布时没有键命名规范。为什么会共用？因为缓存键的命名没有检查清单，评审时只看了业务逻辑。为什么评审没发现？因为发布清单里没有“缓存键变更”这一项，部署流程也不做灰度验证。

挖到第三层，改动项自己就浮出来了：补一条缓存键命名规范、发布清单加一项、关键接口先灰度 10% 再全量。反之，停在第一层的复盘只能产出“下次注意缓存”这种无法执行的建议。还有一条红线：复盘不点名、不甩锅。写“值班同学没发现”没有意义，写“告警阈值设得过高，错误率 38% 才触发”才有改动价值。复盘的读者应该是未来的自己和接手的人，而不是审判席。

第三步：改动项必须有主、有截止日期、有验收标准

复盘文档的后半部分是一张行动表，每一行都要回答四个问题：改什么、谁来做、什么时候做完、怎么算做完。反面例子：“优化缓存策略（负责人：待定，时间：尽快）”——这种句子等于没写。正面例子：“给任务列表接口的缓存键加版本号前缀 v2，负责人阿木，11 月 12 日前上线，验收：灰度期间新老版本共存 24 小时无冲突告警。”

行动项还要分优先级。止血的改动（比如键命名规范和发布清单）应该在一周内落地；结构性的改动（比如给缓存层加自动化冲突检测）可以排到一个月，但必须有明确的排期，而不是“有空再做”。一个实用的做法是：复盘会开完当天，就把行动项直接写进任务管理系统，和正常需求排在一起；留在文档里的行动项，三个月后回头看，十有八九一条都没动。

第四步：复盘会怎么开：一小时，五个议程

复盘会不需要隆重，但需要结构。建议一小时走五个议程：前 10 分钟过时间线，主持人读，参与者只纠正事实错误；接下来 20 分钟讨论原因，目标是达成一致的因果链，而不是找出责任人；然后 15 分钟定行动项，每条当场确认负责人和截止日期；再 10 分钟复盘“响应本身”——值班流程、告警、沟通有没有拖后腿；最后 5 分钟确认文档由谁整理、何时发出。主持人最好不是当事人，当事人讲自己的判断时容易不自觉地辩护。

还有两个细节值得坚持。第一，复盘文档要对内公开，至少团队内所有人能读到；藏起来的复盘等于没写，新人下次还会踩同一个坑。第二，定期回访：每月花 20 分钟扫一遍过去几个月复盘的行动项，看看哪些逾期了。复盘的价值不在文档写得多漂亮，而在行动项有没有真的落地——逾期清单本身，就是下一篇复盘的素材。

小团队的轻量模板：五段就够

一人团队或两三人的小团队不需要大公司的复盘流程，但五段结构值得保留：摘要（发生了什么、影响多大、持续多久）、时间线（事实节点+来源）、原因分析（至少三层为什么）、行动项（改什么、谁、截止日期、验收标准）、经验教训（响应流程上有什么可以改进）。这五段写下来通常一到两页，半小时能写完。模板可以固定下来放在仓库里，每次事故复制一份填空，比每次从头想格式省事得多。

最后说一句不那么讨喜但真实的话：复盘最难的不是方法，而是心态。事故刚过去时，人最容易做的两件事是赶紧翻篇，或者找个人背锅；复盘要求的是反直觉的第三种选择——把伤口摊开、按时间顺序讲清楚、然后改掉让它发生的条件。能做到这一点的团队，事故会越来越少；做不到的，事故只会换个日期重演。你的下一个事故，其实已经在等你写上一篇复盘了。

一份可以直接抄的复盘模板

下面是一份一页纸的复盘骨架，复制到你的仓库里就能用。摘要：事故名称、发生时间、持续时长、影响范围（多少用户、哪些功能）、恢复方式（一句话）。时间线：按时间顺序列出事实节点，每个节点带来源。原因分析：用“为什么”链写三层以上，终点落在系统条件而非个人失误。行动项：表格形式，列分别为改动内容、负责人、截止日期、验收标准、状态。经验教训：响应流程上有什么可以改进（告警、值班、沟通、工具）。附录：相关链接（监控截图、部署记录、群聊记录存档）。

写模板时有一个取舍：字段越少，越容易坚持写下去。很多团队的复盘模板一开始设计得很完整，十几个字段，结果每次事故都嫌麻烦，最后干脆不写。五段结构是一个平衡点：信息够用、写起来不累。等团队大到一定规模，再按需加字段——比如客户影响分级、对外公告链接、法务合规备注——而不是一开始就堆满。

四种常见反模式，写复盘时逐一避开

第一种叫“甩锅会”：复盘会上花一半时间讨论谁的错，最后结论是“某人下次注意”。这种复盘没人愿意参加第二次，而且下一次事故的当事人会本能地隐瞒信息。解法是主持人立规矩：会上只谈系统和流程，不谈个人；任何指向个人的表述，都改写成指向流程的表述。

第二种叫“只写不跟”：文档写得漂亮，行动项一条没落地。解法前面提过：行动项当天进任务系统，每月回访逾期清单。还有一个狠招：下一次复盘会的第一项议程，就是检查上一次复盘的行动项完成情况——完不成的要说明原因，而不是悄悄过期。

第三种叫“当成检讨书”：复盘写成自我批评，越深刻越好，结果没人敢写真实原因。复盘不是检讨书，它的技术文档属性应当大于道德属性；真实原因比漂亮姿态重要得多。如果团队文化还没到能坦然谈失误的程度，复盘文档可以先只在小范围内传阅，等信任建立起来再扩大范围。

第四种叫“小题大做或大事化小”：小事故写十页，大事故一句话带过。复盘的深度应当和事故分级挂钩：影响几分钟、无用户感知的内部抖动，写五段轻量版就够；影响核心功能、持续一小时以上的事故，值得开正式复盘会并完整记录。分级标准可以提前定好，写进值班手册，事故发生时按标准执行，而不是凭当时的心情决定。

复盘与对外沟通的边界：哪些公开、哪些留内

复盘文档通常是内部文件，但事故发生后往往还需要一份对外公告，两者的边界要分清。对外公告讲三件事就够：发生了什么、对用户有什么影响、现在状态如何（已恢复 / 正在修复 / 预计时间）。内部复盘里的原因链、责任讨论和未完成的行动项，不必也不应原样公开——一方面是没必要让用户承担技术细节，另一方面是未验证的推测公开后很难收回。

但有一个例外值得坚持：如果事故涉及用户数据安全或资金损失，公开公告就不能只报“已恢复”，而应当说明影响范围、已采取的补救措施和用户需要做什么（比如改密码、检查账单）。隐瞒这类信息换来的平静是短期的，信任的损失是长期的。复盘文档里应当专门留一节，记录“对外口径由谁定、何时发出”，避免事故现场出现多人各说各话。

从复盘到预防：让同类事故越来越难发生

复盘的终极检验标准，是同类事故的复发间隔有没有拉长。做到这一点需要把复盘的产出沉淀成三样东西：第一，检查清单——发布清单、缓存键规范、回滚步骤，这些清单应当随着每次复盘更新，而不是写一次就 frozen；第二，自动化防护——能用代码拦住的，就不要靠人记住，比如缓存键冲突检测、灰度验证、告警阈值校准；第三，新人入职材料——把历史上最典型的两三个事故复盘放进新人必读，新人第一次值班前就知道团队踩过哪些坑。

这三样东西做起来都不难，难的是坚持。每一次事故都是一次免费的系统体检，复盘就是把体检报告变成处方。处方开出来不吃，体检就白做了。你的团队可以从下一份复盘开始试：只加一条规则——行动项必须在复盘会当天进任务系统。这一条坚持三个月，复盘的价值会自己显现出来。

复盘文化的养成：从第一份复盘开始的三个月计划

复盘写一份容易，养成习惯难。这里给一个三个月的落地计划。第一个月只做一件事：下一次事故发生后 48 小时内写出第一份五段式复盘，不追求完美，写出来就是胜利。同时把模板放进仓库，把行动项当天写进任务系统——这两个动作固定下来，复盘就有了骨架。

第二个月做两件事：第一，把历史上最典型的一次事故补写一份复盘，放进新人必读，让复盘开始产生“预防新人踩坑”的价值；第二，第一次回访上个月的行动项，看看哪些逾期了、为什么逾期。回访的重点不是追责，而是发现行动项定得合不合理——经常逾期的行动项，往往是定得太大、太模糊，需要拆小。

第三个月做一件事：把复盘和发布流程连起来。发布清单里加一项“本次发布有没有相关的历史复盘需要复查”，尤其是改动缓存、权限、支付这类高危区域时，先翻一遍历史复盘再动手。做到这一步，复盘就不再是事故后的补救动作，而是发布前的预防动作。三个月下来，团队会发现一个变化：事故复盘会上讨论的不再是“怎么又出事了”，而是“这次比上次少了哪些问题”——这就是复盘文化开始生根的信号。

写在最后：复盘不是为了过去，而是为了下一次

复盘文档写完、行动项进系统、回访机制跑起来，这套流程的价值会在半年后显现：新入职的人第一次值班前，读两份历史复盘就知道团队的雷区在哪；发布高危改动前，翻一遍相关复盘就能避开已知的坑；事故再发生时，值班的人不用从零开始猜原因，时间线模板和检查清单都在仓库里等着。复盘不是为了给过去一个交代，而是为了让下一次事故处理得更快、影响更小、学到的东西更多。从这个意义上说，复盘写得好不好，要看半年后的团队，而不是看文档本身的篇幅。

补充一点关于复盘文档的保存：复盘写完后建议和当时的监控截图、部署记录、对外公告链接一起归档，存在团队都能找到的地方——仓库里的固定目录、共享文档库都可以，关键是“下次需要时能找得到”。很多团队的复盘不是没写，而是写完散落在个人电脑和群聊记录里，半年后想找翻不出来。归档时按日期和事故名称命名，附上一行摘要，检索成本会低得多。另外，复盘文档的修改要留痕：如果事后发现原因分析有误，用修订记录补充更正，而不是悄悄改掉原文——复盘的可信度来自它的可追溯性，改得无声无息，等于亲手拆掉这份可信度。