三个经实战检验的技术复盘方法，帮你把踩坑变核心经验

上周刚跟团队熬了大半天，做完那个折了百万的失败项目复盘。散会的时候三个刚工作一两年的小孩堵着我问，说哥，为啥你带的复盘，结束了我们拿着纸就能改，我们之前自己复盘，要么骂到不欢而散，要么最后落个“下次注意”，啥用没有。 其实不止新人，很多工作五六年的老开发，都没搞明白技术复盘到底要怎么做。说白了，技术复盘不是走流程交报告，是把你踩过的坑，真真正正变成自己的技术资产。

别搞虚的：先把“事故还原”做扎实

很多人复盘的第一步就错了。刚坐下开口就是“那个开发手残改坏了参数”“产品临时改需求坑人”，全是主观吐槽，根本没搞清楚到底发生了什么。 技术复盘的第一步，必须是不带任何评价的纯事实还原。什么叫事实？就是拉一条清清楚楚的时间线：什么时间点，谁做了什么操作，产出了什么交付物，出问题的时候监控数据是什么样，报错日志是什么内容，哪行代码改了什么，全要列出来。 上次我们做大促接口超时故障，一开始全组一口咬定是DBA没给够数据库连接数，吵了快一小时，翻时间线才发现，是我们自己开发前一天晚上改连接池参数，手滑把1024输成了102。就这么简单。 技术复盘项目时间线梳理表 我定过一个死规则：还原阶段只讲“是什么”，不讲“为什么”，更不准骂街。 你上来就骂，谁还敢说自己做错了？藏着掖着，你连真实发生了什么都搞不清楚，后面找的原因全是错的。下次该踩还是踩，复盘不就白做了？ 说白了，还原的核心，就是把“我觉得”变成“我证明”，拿数据和记录说话，不要拿情绪说话。

挖根因别停在人身上，用对5why才有用

大家都听过5why分析法，就是连问五个为什么，挖到问题的根因。但是我敢说，百分之九十的人都用错了。 错在哪？大部分人问一两个就停在了“人”的问题上。比如线上出bug，问：为什么出bug？因为测试没测到。为什么没测到？因为排期紧。排期为什么紧？因为产品临时改需求。到这就停了，最后结论就是“下次产品别乱改需求”“开发上点心”，这有个屁用？ 人都会犯错，你骂一顿开发粗心，他下次赶项目还是会漏，根本解决不了问题。正确的挖法，是一直挖到流程、工具、架构的漏洞才行。 给你举个真实的例子。去年我们有个服务上线，把合作方的接口打挂了，对方赔了我们十万，我们赔了用户小几十万。一开始大家的结论就是“对接的开发不知道对方的限流阈值”，就完了？不对，接着挖： 为什么开发不知道？——因为对接是架构师谈的，架构师没同步给开发。 为什么架构师谈完没同步？——因为公司没有要求对接完必须输出共享文档留档，全靠口口相传。 为什么上线前的checklist没有“第三方接口阈值确认”这一项？——之前根本没人出过这个问题，所以没加。 挖到这才叫根因对吧？后来我们补了三个东西：上线checklist加了第三方参数确认项，所有对外对接必须输出留档共享文档，所有第三方调用都加了本地降级熔断。从那之后，再也没出过一模一样的问题。 技术问题5why根因分析思维导图 记住这个核心点：永远不要把根因归结为“某个人粗心”，要找体系上的漏洞。人都会错，改体系才是一劳永逸的解法。

复盘完必须出可落地的行动项，别留“下次注意”这种废话

复盘完必须出可落地的行动项，别留“下次注意”这种废话 说实话，我最烦复盘结束留一句“大家下次注意点”。这等于没说。 注意什么？怎么注意？谁去做？什么时候做完？要做到什么标准？全说不清楚，最后就是不了了之。过俩月再出一次一模一样的问题，之前的复盘全白做。 技术复盘的最后一步，必须输出可落地、可验证、有明确责任人的行动项。 举个例子，你复盘完发现缓存雪崩的隐患，不能写“优化缓存策略”，这种话太虚了。要写成：“下周三之前，由李XX完成所有核心缓存的过期时间随机打散改造，上线后观测一周，缓存失效波动不超过阈值的10%”。 你看，这才叫能落地的行动项，谁都能看懂，到点就能检查。 不过话说回来，行动项别贪多，一次复盘出三到五条最核心的就行。你一下子列十几二十条，分给大家全做不完，最后全堆在那落灰，还不如不做。 还有，行动项一定要跟进闭环。谁负责的，到点了有没有做完，没做完是什么原因，一定要拉出来说清楚。很多团队复盘做的热热闹闹，最后行动项没人管，放在群里慢慢就沉了，这不就是浪费时间吗？ 技术这行，拼到最后拼的就是谁踩的坑多，还能把坑变成自己的护城河。很多人工作五六年，其实就是一年的经验用五年，踩过的坑转头就忘，下次接着踩，永远涨不了真本事。 找对方法复盘，踩一个坑就能解决一类问题，越攒经验越轻松，这不比天天瞎忙强？对吧。