踩过坑才懂：适合普通人的技术复盘方法

去年9月23号，我在南京新街口的写字楼赶项目上线，临走前改了一行支付回调的配置，直接导致生产环境丢了两百多笔订单。 我当时脸都白了。整个部门连夜回公司抢修，最后赔了不少钱，还挨了通报。从那之后我再也不敢小看复盘这件事。

别上来就列整改清单

那会刚出完事，我第一反应就是打开文档列整改条目：加支付失败报警监控、核对第三方IP白名单、要求测试回归所有配置项。写完交上去，以为完事了。结果部门老大看完，直接给我打回来，说这玩意儿谁不会写？你这是应付老板，不是复盘。 很多人都是这样，一出事就忙着甩锅找责任人，然后列一堆正确的废话，转头就存档吃灰。下次该出问题还是出问题。 技术复盘事故根因分析白板手写记录 复盘的核心从来不是改几个代码，补几个漏洞，是把你脑子里模糊的经验，捋成清晰的路径，下次碰到类似的事，你能直接拿出来用。不是给领导交差的KPI，是你给自己攒的避坑地图。

我现在一直在用的三层刨坑法

我这套方法没什么高大上的名字，就是踩了无数坑磨出来的，分三层，好记好用。 第一层，先还原事实，别带任何主观判断。什么叫还原？就是把整个事件的时间线，每个节点谁做了什么，结果是什么，原原本本摆出来。不能说“我记得开发当时没改配置”，要拿出git记录，拿出聊天记录，拿出运行日志，实锤每个节点的情况。我那次丢单，最后还原出来的时间线很清楚：第三方提前三天发了域名IP变更通知→运维只更新了生产环境的防火墙白名单，忘了同步测试环境→测试在测试环境走通了流程，没发现问题→上线后第三方新IP被生产防火墙拦了，回调全丢。就这么简单，一开始我还怪测试没测出来，后来才发现，根本不是测试的锅，流程漏了一步。 第二层，刨根因，别停留在“人不小心”。很多人复盘到最后，结论就是“开发粗心大意”“测试疏忽”，这等于没说。人都会犯错，你要找的是，为什么系统没拦住这个错？我们那次，根因根本不是谁粗心，是我们的变更流程里，第三方配置变更根本不需要同步开发测试环境，只有运维自己改完就完事，这个流程缺口才是真的根因。 第三层，落具体动作，别喊口号。别说“以后大家要细心”，要说“下次所有第三方变更，必须走变更评审，拉上开发测试运维三个角色，每个环境都要核对变更内容，核对完留记录”。就这么具体，谁都能执行，不会走样。 三层技术复盘方法手账笔记 说实话，这个方法我用了快两年，大大小小的问题，小到一个线上bug，大到整个项目方向走偏，都能套进去用，比那些动辄几十页的复杂框架好用多了。不需要你花几个小时整模板，按三层捋下来，核心问题马上就出来。

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

大多数人都踩过的复盘误区 第一个误区，复盘必须拉一大群人开几个小时会。真没必要。我现在碰到自己负责的小问题，自己花二十分钟写个复盘笔记就行，拉人开会纯粹浪费时间，还容易变成批斗大会，没人愿意说真话。只有那种跨部门的大事故，才需要拉人一起对齐还原，其他时候，自己跟自己复盘反而更坦诚，你敢直面自己犯的错，不用藏着掖着。 第二个误区，复盘必须搞大动作，动不动就重构架构改流程。不对。很多小问题，改一行代码，加一个报警就够了，没必要为了显示你复盘到位，瞎折腾。我之前见过团队出了个偶发的缓存雪崩，本来加个过期时间随机偏移就能解决，结果复盘非要把整个缓存架构全换了，改完出了好几个新问题，耽误了三个月业务进度，得不偿失。复盘是解决问题，不是做给别人看的业绩，能小改就别大动。 第三个误区，复盘是技术负责人的事，跟小开发没关系。这话错得离谱。你复盘出来的经验，全都是你自己的，别人拿不走。你每次踩完坑都刨一遍，三年下来，你碰到问题的敏感度，比那些从来不复盘的人，高不知道多少。很多人工作五六年，看起来资历老，其实碰到新问题还是慌，就是因为从来没把踩过的坑整理成自己的东西，每次都是从头来。 不过话说回来，复盘也不能钻牛角尖。有些问题就是纯偶发，比如第三方云服务商突然宕机，你根本控制不了，你加个降级预案，加个报警就完了，别死磕非要刨出什么惊天大根因，浪费时间。 技术这行，本来就是边走边踩坑。你爬起来的时候，多弯腰捡一块金子，走不了多远，你口袋就满了。别嫌麻烦，真的，我那次南京踩的大坑，换来了现在这套好用的复盘思路，算下来，还是我赚了。对吧？