上次线上故障烧了30万，我靠这套技术复盘方法把锅变成了墙

去年9月23号，我在南京河西的写字楼里盯大促，刚点完外卖，运维的电话炸了。支付通道掉了。三个小时，整整三个小时，用户付不了钱，运营在旁边跺脚，产品把鼠标捏碎了一个。事后算帐，加上给用户发的补偿，直接烧了三十万。

那天复盘开到凌晨两点，一开始全是甩锅：开发说运维改了配置，运维说测试没测出来，测试说产品改需求改的太急。谁都没错，又谁都有错，散会的时候没人记得住到底要改什么。这不就是大多数团队技术复盘的常态吗？

别把技术复盘开成甩锅批斗会

很多团队对技术复盘的理解从根上就错了。出了问题，第一反应是「这锅是谁的」，不是「这问题出在哪」。我见过不少团队，开完复盘会，责任人背了个警告扣了奖金，转头该出问题还是出问题。

为什么？因为问题从来不是某个人“不小心”造成的。你让一个刚毕业两年的新人盯配置，没加自动化校验，没做双人审核，出了错你怪他不小心？这叫找替罪羊，不叫复盘。

说实话，做技术五年，我出过的错能绕办公室三圈。错不可怕，可怕的是错完了，下次还在同一个地方摔。

我刚工作那会，领导也要求我们写那种几十页的复盘报告，要背景要影响要根因要改进，一套模板下来，半天就没了，真正有用的信息埋在十几页官话里，谁都懒得看。不过话说回来，真的要把复盘做好，需要那么复杂吗？反正我后来再也不写那种鬼东西了。

我用了四年的切口式技术复盘方法

什么叫切口式？就是不一开始就铺开整个流程找问题，先找那个最反常的「切口」。上次支付故障，反常点是什么？测试环境跑了三天全没问题，一上线就炸。这就是切口，就盯着这个点挖，别扯别的。

第一步，锁死出事那一刻的所有状态，半分钟都别改。很多人一出问题，第一反应是赶紧先把服务拉起来，拉起来之后顺手就改了配置调了参数，转头要复盘了，死活复现不出来。这种蠢事我刚工作的时候也干过。

后来长记性了，不管多急，先把当时的所有状态打包存好：代码版本、配置参数、流量曲线、错误日志，全存下来，哪怕你先切备用集群顶着，原环境别动。留着原环境，才好挖根。

第二步，顺着切口挖，挖到根就停。别东拉西扯扯到十年前的架构问题。还是说那次支付故障，我们盯着「测试环境没问题线上有问题」这个切口挖，最后挖出来什么？测试环境用的是内网的商户号，不用走真实的银行卡鉴权，线上我们新上了一个鉴权参数，开发改代码的时候少写了一个下划线，测试环境没触发这个逻辑，就漏了。

就这么点破事，一开始甩锅甩了一个小时，要是一开始就盯着反常点挖，半小时就能出来。

类比一下，这就像你家里跳闸了，你别上来就把所有插座全拔了，先想刚才开了什么电器，顺着那个闸往下找，一找一个准。那些上来就把整个系统全捋一遍的，不是闲得慌就是根本不会复盘。

第三步，挖完根因，一定要落一件可执行的小事。别写什么「加强测试流程」「提升工程师素养」这种正确的废话。我们那次挖出来是参数写错了没校验，直接花一天写了个小工具，上线前自动比对配置参数和代码里的字段，不对就卡着不让发版。就这么一件小事，之后再也没出过同类的错。

这些坑我踩过，你别再碰

这套方法好用，但也不是万能的，有几个边界一定要记清楚。

第一个，别为了凑根因瞎归因。我见过有的复盘，明明是多个问题凑到一起才出的事，非要找一个「根本原因」，最后把一个小问题放大成整个架构的问题，折腾三个月重构，结果原来的问题没解决，新问题出来一堆。其实很多线上故障，就是多个小概率事件撞在一起了，你只要把每个小概率事件的防控加上就好，没必要非要揪出来一个所谓的根因。

第二个，别放过「隐性问题」。什么叫隐性问题？就是这次没出事，但是已经露苗头了。我上次帮朋友复盘他们的数据库问题，出问题之前半个月，慢查询数量就涨了三倍，监控报警没人理，最后把整个库拖垮了。复盘的时候别只说这次出事的点，要往回翻，看看之前有什么信号被漏掉了，把这个信号加上报警，比什么都管用。

第三个，别把复盘报告锁进共享盘就完事。说实话，我见过太多团队，复盘开完，报告上传，就再也没人提了。过了半年，同一个坑再摔一次，所有人都拍脑袋说「哦我们之前好像出过这个问题？」你说冤不冤？

我现在的习惯是，每个复盘完改的东西，都写到我们团队的wiki首页，每个新人进来第一件事就是看这些坑，每个月站会抽五分钟过一遍最近踩的坑，花不了多少时间，印象深的多。

做技术这么久，我越来越觉得，会不会写高大上的架构不重要，会不会把踩过的坑变成自己的墙，才是拉开差距的地方。谁没出过错啊？出了错，躲，甩锅，忘，那你永远只能停在原地。把错掰碎了，看清楚坑在哪，填上，下次就不会再掉进去了。

就这么简单。