问问助手

故障复盘,写到什么程度才算有用

2026-10-28 Aryee 0
故障复盘,写到什么程度才算有用

一、复盘写完,为什么没人再打开

出事那天会议室坐满了人,白板上写得密密麻麻。

三天后复盘文档发进群里,收获十几个赞,然后被下一个项目压下去。半年后再出一次同类故障,有人翻出来一看:当时定的三条改进,一条也没做。

问题不在写得不认真,在于这份文档从一开始就没打算被用第二次。

二、复盘是给下一次故障用的

写复盘最常见的误解,是把它当成对这一次的交代。

真正要看这份东西的人,是半年后遇到同类问题的那位值班同事,还有要做预算决定的那位负责人。

所以判断一份复盘有没有用,标准只有一条:另一个人拿着它,能不能少走一遍同样的弯路。

三、时间线要写到分钟

时间线不是流水账,是这件事怎么一步步走到失控的记录。

至少要写清四个时刻:第一次异常出现、第一个人发现、第一次有效处置、影响结束。

中间那些走错的路也要写。比如先怀疑了网络,查了四十分钟才发现是配置。这段不是自我批评,是下一次省下的四十分钟。

四、影响要说人话

「系统不可用」、「部分用户受影响」,这类写法等于没写。

要有三个数:多少人、多长时间、他们当时做不成什么事。

再补一句业务后果:这期间积压了多少单没处理,或者有多少笔支付失败。技术同事看得懂这些数,老板也看得懂。

五、根因不是一个词,是一串因素

每次复盘都会有人问:根因到底是什么。

如果答案是一个词,比如「配置错误」,那这次复盘基本白做了。配置错误是现象,不是原因。

真正要写的是这一串:这个配置为什么会被改、改的时候为什么没人拦、上线前为什么没测出来、出事后为什么二十分钟才被发现。

四问里通常每一问都有欠缺,这就叫多个促成因素。

六、哪里走了运,这一节最能看出水平

顶级团队的复盘模板里有一节,叫「我们运气好在哪」。

比如那次故障发生在凌晨三点而不是早高峰,比如某个开关恰好是关的,比如某位同事刚好还记得两年前的一次类似情况。

写这一节不是为了庆幸,是为了提醒:下一次运气不会一样好。今天没造成损失的那条路,明天可能就断了。

七、行动项只写两样:谁、什么时候

行动项最常见的失败,是写成一句没有主语的期望。

「加强监控」、「完善流程」、「提高测试覆盖率」,这类句子永远不会有人认领,也永远不会过期。

合格的动作长这样:谁负责,哪天之前完成,做完之后拿什么证明。三样缺一样,就当它不存在。

八、为什么不能写成「加强培训」

培训是最容易写、最难验收的一条。

它的问题是把改进落在了人的记性上。而故障往往不是某个人不知道,是系统允许他在不知道的情况下按下那个按钮。

能改成系统动作的,就不要写成培训。比如把那个按钮加一道确认,比培训十次都可靠。

九、无责,不等于不写名字

无责复盘的意思是:不追究个人责任,鼓励把真实过程说出来。

这不代表文档里不出现人。恰恰相反,时间线里要写清谁在什么时刻做了什么判断,因为那是改进的原材料。

界线在措辞上。「某某操作失误导致故障」是在定罪;「当时按流程执行了这一步,而流程没有覆盖这种情况」是在记录。同一个事实,两种写法,后一种才有人敢写下一份。

十、没参会的人也要看得懂

复盘会一般只有十几个人参加,而受影响的人、以后可能遇到同类问题的人,远不止这些。

所以文档要写给没来的人看:术语第一次出现要给一句白话解释,关键的截图和日志要贴进来,不要只写「见群记录」。

写完可以让一位没参与的同事读一遍,他读完能复述这件事,这份文档就算过关。

十一、会上最容易吵起来的那件事

复盘会上最常见的争执,是要不要把它定性为「重大故障」。

定性直接连着考核和通报,所以各方都会紧张。比较好的做法是开会前就把定性的标准写出来,按影响面和时间对号,不临场讨论。

定性定了,讨论才能回到改进上。否则一场会开两小时,一小时半在争这个词。

十二、行动项要有人盯,而且要在下一次复盘时对账

行动项写完就散,是这类文档最普遍的死法。

简单有效的做法只有两条:每条行动项进和项目任务同一张表,有负责人和截止日;每次新的复盘会开头,先花五分钟对上一次那几条。

没做完的,说明理由,重新定日期,或者当场决定不做。允许不做,但不允许假装它不存在。

十三、小故障要不要也复盘

不是每次宕机才叫故障。一次误发通知、一条跑错的数据、一次半小时没人发现的报表延迟,这些都算。

全做正式复盘太重,团队会敷衍。可行的分档是:影响面大、或者能暴露新风险的,做完整复盘;其余只记三行,发生了什么、为什么、改了什么。

关键是别让小事只留在聊天记录里。同一个原因第三次出现时,它已经不是小事了。

十四、给管理层的一页

要看的三件事,都在文档里,不用另做汇报。

一是最近五次故障的复盘,行动项完成了几个,过期了几个。

二是有没有哪一类故障在重复出现。重复出现说明改进没落地,不是运气不好。

三是上一次复盘的文档,有没有被下一个人真的用上。问一句「你看过哪一份、照着改了什么」,答案最真实。

你手上那套系统,卡在哪一步?

留个手机号和方便的时间,我打过来先听你说现状和限制,再给一个能执行的判断:这套系统该继续修、该动哪里,还是重做一版更省。

约一次沟通不接纯 UI 外包,只做系统层面的问题。不方便留号码,也可以直接跟助手说一句话。