故障复盘,写到什么程度才算有用
一、复盘写完,为什么没人再打开
出事那天会议室坐满了人,白板上写得密密麻麻。
三天后复盘文档发进群里,收获十几个赞,然后被下一个项目压下去。半年后再出一次同类故障,有人翻出来一看:当时定的三条改进,一条也没做。
问题不在写得不认真,在于这份文档从一开始就没打算被用第二次。
二、复盘是给下一次故障用的
写复盘最常见的误解,是把它当成对这一次的交代。
真正要看这份东西的人,是半年后遇到同类问题的那位值班同事,还有要做预算决定的那位负责人。
所以判断一份复盘有没有用,标准只有一条:另一个人拿着它,能不能少走一遍同样的弯路。
三、时间线要写到分钟
时间线不是流水账,是这件事怎么一步步走到失控的记录。
至少要写清四个时刻:第一次异常出现、第一个人发现、第一次有效处置、影响结束。
中间那些走错的路也要写。比如先怀疑了网络,查了四十分钟才发现是配置。这段不是自我批评,是下一次省下的四十分钟。
四、影响要说人话
「系统不可用」、「部分用户受影响」,这类写法等于没写。
要有三个数:多少人、多长时间、他们当时做不成什么事。
再补一句业务后果:这期间积压了多少单没处理,或者有多少笔支付失败。技术同事看得懂这些数,老板也看得懂。
五、根因不是一个词,是一串因素
每次复盘都会有人问:根因到底是什么。
如果答案是一个词,比如「配置错误」,那这次复盘基本白做了。配置错误是现象,不是原因。
真正要写的是这一串:这个配置为什么会被改、改的时候为什么没人拦、上线前为什么没测出来、出事后为什么二十分钟才被发现。
四问里通常每一问都有欠缺,这就叫多个促成因素。
六、哪里走了运,这一节最能看出水平
顶级团队的复盘模板里有一节,叫「我们运气好在哪」。
比如那次故障发生在凌晨三点而不是早高峰,比如某个开关恰好是关的,比如某位同事刚好还记得两年前的一次类似情况。
写这一节不是为了庆幸,是为了提醒:下一次运气不会一样好。今天没造成损失的那条路,明天可能就断了。
七、行动项只写两样:谁、什么时候
行动项最常见的失败,是写成一句没有主语的期望。
「加强监控」、「完善流程」、「提高测试覆盖率」,这类句子永远不会有人认领,也永远不会过期。
合格的动作长这样:谁负责,哪天之前完成,做完之后拿什么证明。三样缺一样,就当它不存在。
八、为什么不能写成「加强培训」
培训是最容易写、最难验收的一条。
它的问题是把改进落在了人的记性上。而故障往往不是某个人不知道,是系统允许他在不知道的情况下按下那个按钮。
能改成系统动作的,就不要写成培训。比如把那个按钮加一道确认,比培训十次都可靠。
九、无责,不等于不写名字
无责复盘的意思是:不追究个人责任,鼓励把真实过程说出来。
这不代表文档里不出现人。恰恰相反,时间线里要写清谁在什么时刻做了什么判断,因为那是改进的原材料。
界线在措辞上。「某某操作失误导致故障」是在定罪;「当时按流程执行了这一步,而流程没有覆盖这种情况」是在记录。同一个事实,两种写法,后一种才有人敢写下一份。
十、没参会的人也要看得懂
复盘会一般只有十几个人参加,而受影响的人、以后可能遇到同类问题的人,远不止这些。
所以文档要写给没来的人看:术语第一次出现要给一句白话解释,关键的截图和日志要贴进来,不要只写「见群记录」。
写完可以让一位没参与的同事读一遍,他读完能复述这件事,这份文档就算过关。
十一、会上最容易吵起来的那件事
复盘会上最常见的争执,是要不要把它定性为「重大故障」。
定性直接连着考核和通报,所以各方都会紧张。比较好的做法是开会前就把定性的标准写出来,按影响面和时间对号,不临场讨论。
定性定了,讨论才能回到改进上。否则一场会开两小时,一小时半在争这个词。
十二、行动项要有人盯,而且要在下一次复盘时对账
行动项写完就散,是这类文档最普遍的死法。
简单有效的做法只有两条:每条行动项进和项目任务同一张表,有负责人和截止日;每次新的复盘会开头,先花五分钟对上一次那几条。
没做完的,说明理由,重新定日期,或者当场决定不做。允许不做,但不允许假装它不存在。
十三、小故障要不要也复盘
不是每次宕机才叫故障。一次误发通知、一条跑错的数据、一次半小时没人发现的报表延迟,这些都算。
全做正式复盘太重,团队会敷衍。可行的分档是:影响面大、或者能暴露新风险的,做完整复盘;其余只记三行,发生了什么、为什么、改了什么。
关键是别让小事只留在聊天记录里。同一个原因第三次出现时,它已经不是小事了。
十四、给管理层的一页
要看的三件事,都在文档里,不用另做汇报。
一是最近五次故障的复盘,行动项完成了几个,过期了几个。
二是有没有哪一类故障在重复出现。重复出现说明改进没落地,不是运气不好。
三是上一次复盘的文档,有没有被下一个人真的用上。问一句「你看过哪一份、照着改了什么」,答案最真实。
本文作者:Aryee 发布时间:2026-10-28 09:27
本文出处:ARYEE.cn 固定链接:https://www.aryee.cn/archives/incident-review-that-counts.html
转载或引用请连这一行一起带走;文中的代码与结论按当时环境成立,组件升级后请以官方文档为准。