实用技术复盘方法，让你踩过的坑都变成进阶垫脚石

前阵子刚帮团队收完一个烂摊子。打磨了三个月的AI训练数据标注工具，上线第三天直接瘫了，核心服务OOM，回滚花了整整七个小时，整个部门通宵到第二天早上。 散会的时候有人嘟囔，说早知道当初复盘上次的缓存问题就好了。我听完没说话。心里门儿清。——之前所谓的复盘，不过是周会上花十分钟走个过场罢了。

先搞清楚，技术复盘不是开批斗会

很多公司对复盘的理解，从根上就错了。出了故障，拉一群人开会，从头到尾就是找责任人，谁写的代码，谁拍板的方案，找到人骂一顿，罚点年终奖，散会。下次该出问题还是出。 说实话，这种会不开也罢。技术复盘的核心，从来不是追责，是拆清楚「当时我们为什么这么选」「哪里出了偏差」「下次怎么避开」。 很多人还分不清项目复盘和技术复盘，项目复盘聊进度聊需求聊成本，技术复盘只抠技术链上的每一个决策，差一点都不行。 技术复盘问题定位逻辑图 举个例子，上次我们出问题是高峰期缓存击穿导致的DB雪崩，很多人复盘到「缓存没设过期保护」就停了，对吧？不对，你得往回挖：当初做方案的时候，为什么没加保护？是不知道有这个东西，还是赶进度主动砍了？当时拍板砍需求的时候，有没有人提出过风险？为什么风险没被重视？ 挖到底你会发现，大多问题都不是某个人犯傻，是当时的信息、资源、优先级共同导致的结果。你的任务是把这个过程挖出来，不是骂某个人蠢。

亲测三年有效的落地技术复盘方法

我这个方法，没什么高大上的名词，就是踩坑踩多了磨出来的，每一步都能落地。 首先，得还原完整技术决策链路，倒着推。从出问题的那个点往回拆，拆到最初的需求评审，每一个环节的决策，参与人是谁，当时的依据是什么，有没有留下文档，全都理出来。你会发现很多问题根本不是最后一步写错代码的事，早在两周前定架构的时候就埋了雷。 接着，拆分「已知错」和「未知坑」，分开处理。已知错是什么？就是你当时做决策的时候，就知道这么做有风险，纯粹是赶进度、缺资源妥协了。比如明明知道要加熔断降级，就是没排期，先上线再说。这种错，直接记进团队的上线准入规则，下次不满足直接不能发版，没的商量。 那未知坑呢？就是你之前从来没遇到过，根本想不到的。比如云服务商某个可用区突发故障，或者第三方SDK偷偷改了接口逻辑没通知你，这种就整理进团队的风险库，所有新项目立项的时候，都要过一遍风险库，提前设防。 技术复盘决策链路拆分示例图 最后一步，必须输出可落地的行动项，绝对不要正确的废话。我见过最多的无效复盘，最后得出的结论是「以后大家要注意容量评估」「以后写代码要多测试」，这说了等于没说对吧？ 合格的行动项，必须说清楚谁来做，做什么，什么时候做完，标准是什么。比如把上面那句废话改成「所有新上线项目，必须出具容量评估报告，由架构组审核，峰值预估必须乘三留冗余，下周三之前把评估模板整理出来」——这才叫能落地的行动项。

绝大多数人都踩过的复盘误区

绝大多数人都踩过的复盘误区 第一个误区，只复盘失败，不复盘成功。太常见了对吧？项目顺利上线，大家一起吃个庆功饭就完了，谁会想着复盘？ 我之前就吃过这个亏，去年做618活动，全程顺顺利利，没出任何问题，我们就没复盘，结果今年同款活动，直接崩了。后来挖才发现，去年运气好，运维上新的时候多打了一倍机器，歪打正着扛住了峰值，我们还以为是自己的架构估算精准，今年按原来的估算配机器，直接不够用。 你说亏不亏？不管成不成，只要是重要项目，都得复盘。成功了要搞清楚，到底是真的能力到位，还是碰运气。 第二个误区，一次复盘要把所有问题都改完，贪多嚼不烂。上次我们复盘一个大故障，前前后后拉出来二十多个待优化点，要是一次性全改，估计所有人一个月不用干别的了，肯定大家都抵触。我们当时挑了三个最核心的问题，一周之内改完上线，剩下的按优先级排进迭代，一个月改完，大家也轻松，也不会抵触。 第三个误区，只有技术人参加复盘。很多技术问题的根，根本不在技术。需求改了三版，架构跟着改了三回，最后没时间做评估，你不把产品拉过来复盘，永远解决不了问题。下次还是改需求改到技术赶进度，还是出问题。 说实话，我现在最烦开三四个小时的冗长复盘会，所有人扯半天闲篇，最后啥结论都出不来，纯纯浪费生命。 不过话说回来，复盘这个事，做和不做，差别真的太大了。我带过的小团队，坚持做了一年正经的技术复盘，相同的坑第二次踩的概率，直接降了七成多，这都是实打实的统计。 之前有个刚工作两年的小朋友，跟我做项目，每次复盘都认认真真理一遍，不到三年就升了高级开发，两年后又升了架构。他自己说，别人踩一次坑转头就忘，他踩一次能把坑的来龙去脉摸得清清楚楚，进步当然比别人快。 那些熬到凌晨的夜，那些回滚时捏的汗，总不能白流对吧。