好用不折腾的技术复盘方法，帮你踩过的坑都变成垫脚石
别搞虚的，技术复盘先搞对目标
很多团队从第一步就错了。上来第一句话就是「说吧，这次是谁的问题」。直接把复盘开成了批斗会，所有人都缩着，生怕祸水引到自己身上，还怎么挖真问题？
我前年在创业公司带队做支付系统，刚上线第一个大促就崩了十分钟，大半夜全公司人拉到公司复盘。一开始CTO拍桌子就要查责任人，扯了快一个小时，没人敢说话，净是「我当时没注意」「这块我没参与」这种废话。
后来还是那个做架构的老杨拍了桌子：别扯谁错，先说说我们预设的熔断机制为啥没起作用。
技术复盘会现场讨论手写记录
不到四十分钟，根因就出来了。压测的时候只测了常规峰值流量，没人想到大促会有用户重复点击支付，触发了重试风暴，我们的熔断阈值是按常规流量设的，根本扛不住。
技术复盘的核心目标，从来都不是追责，是三件事：找到真问题、避免再踩坑、沉淀可复用的经验。目标错了，再标准的流程都是白搭。
我用过最顺手的五步技术复盘方法
说实话，我试过不下十几种复盘方法论，什么OKR复盘，什么系统化复盘，最后留下来天天用的，就是这五步，没花活，好用。
第一步，先还原事实，别掺主观判断。
啥叫事实？就是所有人都能验证的东西。别说「小张粗心漏改了配置」，这是观点。要说「上线前的配置表中，Redis集群超时参数写的是100ms，符合常规场景要求，但文档未标注主从切换场景需要调整为500ms」，这才是事实。所有复盘的起点错了，后面全歪。
第二步，对着结果差找问题。
预期结果是什么？实际结果是什么？差在了哪里？把所有卡点列出来，一个个过。比如预期是一万QPS不超时，实际三千就全崩了，那差的七千QPS到底卡在哪一环？是数据库？缓存？还是网络？别模糊带过。
第三步，挖根因，别停在表面。
大家都听过五个为什么，但是很多人用成了五个逼问。其实就是一层层往下剥，别停在「人错了」这一层。比如：
为什么缓存没生效？因为缓存键生成规则错了。
为什么规则错了？因为需求改了参数，代码没更。
为什么代码没更？因为代码评审没人注意到参数变更。
为什么没人注意到？因为评审清单里没加依赖参数变更检查项。
你看，挖到底，根因不是某个人粗心，是流程缺了一块。改流程就行了，骂一顿人，下次还是错。
技术复盘五why根因分析对照表
第四步，出具体的改进行动。
别写那种「加强测试管理，提升人员能力」这种正确的废话。所有行动必须可落地、可验证，有负责人、有截止时间。比如说「下周三之前，把参数变更检查项加到代码评审checklist里」「下周五之前，补完重试风暴场景的压测用例」，就够了，清清楚楚。
第五步，沉淀到公共知识库，别锁在领导硬盘里。
把复盘的整个过程，根因，改进行动，最后的落地结果，整理成几句话的文档，放到全公司所有人都能搜到的地方。下次有人做同类型的项目，一搜就能看到之前踩过的坑，直接避开，这才是复盘最大的价值。不然你复盘的成果只有参会的几个人知道，哪天这几个人走了，坑就得重新踩一遍。
几个反常识的坑，踩过才知道有多痛
几个反常识的坑，踩过才知道有多痛
第一个坑，复盘别拉无关的领导。
我刚当技术经理的时候吃过这个大亏。一次小模块出了线上问题，怕大老板说我不重视，特意请了大老板来参加复盘。结果呢，本来十分钟说清的事，大家全说官话，一个个自我检讨，挖出来的改方案都是错的。三个月后，同一个坑又踩了一次，我当时那个懊恼啊，抽了自己半包烟。
真的，技术复盘只要拉所有相关的参与人就行，领导要是好奇，你把复盘文档发他就行了，没必要请过来镇场。一镇场，真话就没了。
第二个坑，别放过没造成后果的小问题。
很多人说，这次就是个误告警，没影响用户，也没损失，复什么盘？不对，绝大多数大事故，都是一堆没人管的小问题堆出来的。之前某公有云的大范围宕机，追根溯源就是三年前一个没人当回事的小配置变更，一直没复盘，最后滚成了大灾难。只要是偏离预期的问题，不管大小，抽十分钟过一遍，没坏处。
第三个坑，别追求高大上的方法论。
现在很多知识付费课，把复盘吹得玄乎，什么体系化认知，什么深度复盘，要做几十页分析，要对齐战略啥的。说白了，技术复盘就是解决问题，能让你下次不踩同一个坑，就是好方法。整那些虚头巴脑的，除了浪费时间，啥用没有。对吧？
前几天看到行业报告说，国内互联网公司里，超过六成的技术事故，都是重复踩之前踩过的坑。说白了，就是复盘没做好，要么变成批斗会，要么变成形式主义，没拿到真东西。 你踩过一次坑，花一两个小时把它理清楚，变成团队所有人都能用的经验，比你读十本技术畅销书都有用。 真的。