熬到三点写的复盘被打回：真正能用的技术复盘方法根本不是写小作文

上周四晚上十点半，我盯着屏幕上刚写完的五千字复盘文档，鼠标悬在发送键上，突然想起上周leader把我上次写的复盘打回来时说的话："你这是写检讨书还是写小作文？看完我还是不知道下次怎么避免再炸。"

我懵了。

真的懵。

之前我一直觉得，复盘不就是把事故的来龙去脉写清楚，列几条整改措施，走个过场就行？直到那次打回，我翻了过去半年我们组写的十几份复盘，发现百分之八十的内容，看完之后根本记不住，更别说落地了。

你写的复盘，大概率从根上就错了

说真的，我之前踩过的坑能堆成山。

最开始写复盘的时候，我就只会写表面的东西。比如上次大促支付接口崩了，我洋洋洒洒写了三千字，从告警触发的时间，到排查的过程，最后定位到原因是第三方支付平台的网关超时，然后整改措施列了八条：加超时重试、配熔断、做降级、加强监控……写得满满当当，leader看了都夸我认真。

结果呢？

下一个月，还是这个支付接口，又超时了。这次更离谱，直接把我们的订单线程池占满了，连带着用户查询订单的接口都卡得动不了。我又写了份复盘，leader看完直接把文档甩回我脸上："你上次不是说加了熔断吗？怎么还会崩？"

我翻出去年的复盘文档，才发现上次写的整改措施，根本没人跟进。而且就算跟进了，我也根本没写清楚，熔断阈值到底要设多少？超时时间定多长？降级的时候给用户返回什么提示？

后来我才明白，大部分人写的复盘，本质上都是"事故记录"，不是"复盘"。就像你开车刮了蹭了，你只写"今天下午三点在路口刮了别人的车"，却不想为什么刮的？是你没看后视镜？还是路口的视线被挡了？还是你平时开车就不爱打转向灯？下次再遇到同样的情况，你还是会刮。

能落地的复盘，要挖三层而不是只写表面

那次支付接口崩了之后，我拉着组里的几个人，花了一下午重新做复盘。这次我没再写那些虚的东西，就一层一层往下挖。

第一层，最直接的触发原因：第三方支付网关响应超时，我们的系统没有释放挂起的请求，导致线程池被占满。

第二层，流程漏洞：当初我们给这个接口配的超时时间是30s，熔断阈值是100%错误率，而且根本没做降级预案。为什么会定这么离谱的参数？因为当初上线的时候，我们只测了正常场景，根本没测第三方超时的情况。谁拍板的？我。当时我觉得，第三方的可用性那么高，根本不会超时，没必要花时间测。

第三层，认知盲区：我们整个组，都默认第三方接口的可用性是99.99%，从来没把"第三方会超时"当成一个必须处理的场景。甚至连我们的开发规范里，都没写"所有第三方调用必须配超时和熔断"这一条。

就这么挖了三层，最后定的整改措施，具体到离谱：所有第三方调用接口，超时时间统一设为1s，熔断阈值设为50%错误率，超过阈值直接返回"当前支付人数过多，请稍后再试"的提示；把这条规范加到开发checklist里，所有上线前的code review必须检查有没有配超时和熔断；每周拉一次第三方接口的超时率报表，超过0.1%就立刻同步给对方的技术对接人。

这些措施落地之后，接下来的三个月，我们组的线上故障直接少了一半。

真的。

不是吹。

之前我也听过什么5Why分析法，但是用起来总觉得太生硬，像走流程。反而这种挖三层的方法，更符合我们平时排查问题的思路：先找直接炸的原因，再找当初做决策的时候哪里漏了，最后找整个团队的认知里，哪些默认的东西其实是错的。

毕竟很多时候，导致故障的根本原因，根本不是某个人写错了一行代码，而是大家都默认的"潜规则"有问题。比如谁规定运营改优惠券规则不用同步技术？谁规定上线前不用做压测？谁规定监控告警只要发个企业微信就行，不用有人盯着？这些东西，你不挖出来，下次还是会炸。

别把复盘开成批斗会，这几个边界要拎清

我之前参加过别的组的复盘会，那场面，简直是大型甩锅现场。

那次是一个新人写的代码有个空指针，导致整个用户中心崩了。会上所有人都在说"新人怎么不做单元测试"、"code review的时候为什么没查出来"、"怎么连个非空校验都不知道写"。最后定的整改措施是"新人入职要加强培训"、"以后大家写代码要更细心"。

我当时坐在下面，听得直皱眉。

细心？怎么细心？靠熬夜吗？靠人品爆发吗？

后来那个组，下个月就有个老员工写的代码也出了空指针，导致优惠券核销接口崩了。你说老员工也不细心？不可能吧。本质上是他们的开发规范里根本没要求对所有返回值做非空校验，code review的checklist里也没列这一项，就算再细心，也总有漏的时候。

所以复盘的时候，第一个要拎清的边界：对事不对人。不要一上来就问"谁干的"，要问"我们的流程哪里有漏洞"、"我们的规范哪里没覆盖到"。毕竟人都会犯错，但是流程和规范，是可以避免大部分低级错误的。

第二个边界：整改措施必须具体，不能写空话。"加强测试"、"提高安全意识"这种话，写了等于白写。你要写清楚，谁来做，什么时候做完，做完之后怎么验证。比如"小李在本周五之前，把所有第三方调用的超时和熔断参数配好，下周一我来做压测验证"，这才是能用的整改措施。

第三个边界：复盘不是为了追责，是为了下次不踩坑。我见过很多公司，一复盘就开始给人扣绩效，最后大家都不敢说真话，复盘的时候全是套话，根本挖不出真正的原因。那复盘还有什么意义？

上个月我们组做复盘的时候，挖到最后发现，当初给支付接口配30s超时的决策，是我拍板的。要是放在别的组，我可能要被扣绩效了，但是我们leader只是说："那你以后定参数的时候，记得把所有异常场景都测一遍就行。"

就这么简单。

毕竟谁没犯过错？

要是每次犯错都要被追责，那下次谁还敢主动做决策？谁还敢说真话？

我现在越来越觉得，好的技术复盘方法，根本不是什么高大上的理论，就是一群人坐下来，坦诚地把问题挖出来，然后实实在在地把漏洞补上。就这么简单。

上次leader看完我重新写的那份复盘，只改了两个标点，就通过了。他说："这才是复盘该有的样子。"