及时复盘总结查找漏洞不足

项目上线第三天，复盘服务器崩了。总结凌晨两点，查找我被电话叫醒，漏洞打开电脑一看——数据库连接池爆满，不足日志里全是复盘超时异常。排查到四点，总结发现是查找一个不起眼的定时任务没加锁，并发时把连接全占了。漏洞改完配置，不足重启服务，复盘天已经亮了。总结

这件事让我彻底明白一个道理：不回头看，查找你永远不知道自己在哪儿摔的漏洞跤。复盘不是不足走形式，是拿手术刀剖开自己。那个定时任务其实代码量不到五十行，写的时候觉得“这么简单，能出什么问题”。偏偏就是它，把整个系统拖垮了。

复盘要趁热。事情过去一周再回头，细节早就模糊了。我习惯在问题解决后的两小时内，打开一个空白文档，把时间线拉出来。几点几分发现了什么现象，做了哪些操作，哪些操作有效，哪些是白费力气。这个过程很枯燥，但写着写着，漏洞就自己浮出来了。那次事故的复盘文档里，我记了整整三页，最后归纳出两条：一是所有并发操作必须加锁，二是连接池监控要提前告警。后来这两条写进了团队规范，再没犯过同样的错。

查找漏洞需要一种“找茬”的心态。别急着给自己找理由，什么“当时太忙”“需求太急”，这些都不是借口。我见过一个同事，每次复盘都写成功劳簿，通篇在讲自己多辛苦、加班到几点，问题一笔带过。结果呢？同一个坑他踩了三次。复盘不是自我安慰，是自我审判。你得盯着自己的失误看，看到脸红，看到坐不住，才算到位。

不足分两种：一种是技术上的，一种是流程上的。技术上的好办，查文档、补知识、改代码。流程上的更隐蔽，也更致命。比如那次事故，表面是定时任务的问题，根子上是上线前没有做压力测试。我们当时觉得“小改动，不用测”，这种侥幸心理才是最大的漏洞。后来我强制要求，任何涉及并发和数据库的改动，必须跑一轮基准测试。流程上的补丁，比代码补丁管用得多。

复盘的结果要落地。光写文档没用，得转化成可执行的动作。我的做法是：每次复盘至少产出三条改进项，每条都指定负责人和完成时间。改进项不能太虚，比如“提高代码质量”这种等于没说。要具体到“给所有定时任务添加分布式锁”“在监控面板增加连接池使用率曲线”。然后下周同一时间，检查这些改进项是否完成。没完成的，继续追。

有人觉得复盘浪费时间，有那功夫不如多写两行代码。我不同意。写代码是往前跑，复盘是回头看路。你跑得再快，方向错了，或者鞋里进了石子，迟早要摔。花半小时复盘，可能省下未来三天的排查时间。这笔账，怎么算都划算。

最后说个细节。我现在的复盘文档里，专门有一栏叫“如果重来一次”。每次填这一栏，都能发现一些当时没意识到的选择。比如那次事故，如果重来一次，我会在写定时任务之前，先问自己三个问题：会不会并发？失败了怎么办？怎么知道它失败了？这三个问题，后来成了我写任何异步任务的固定检查项。

漏洞不会自己消失，不足也不会自动补齐。你得主动去找，去挖，去补。复盘就是那把铲子。别怕挖出自己的难堪，挖得越深，地基越稳。

很赞哦!（3）