查漏洞补短板方面存在的问题

上个月，查漏存我所在的洞补短板部门做了一次内部系统压力测试。测试结果不算意外，问题但足够扎心——一个平时看着运行平稳的查漏存客户管理模块，在模拟并发数刚到日常峰值两倍的洞补短板时候，直接卡死。问题页面白屏，查漏存日志刷屏，洞补短板数据库连接池被瞬间打满。问题运维同事一边重启服务，查漏存一边嘟囔：“这个模块去年就说过要重构，洞补短板一直没排上期。问题”

问题就藏在这儿。查漏存我们不是洞补短板不知道漏洞在哪，短板在哪，问题而是“知道”和“补上”之间隔着一道巨大的鸿沟。那道鸿沟的名字，叫“优先级”。日常业务一忙，修复老问题永远得给新需求让路。新功能上线有明确的时间节点，有领导盯着，有考核压着；而查漏补缺这件事，没有截止日期，没有负责人拍胸脯承诺，最后往往就变成“等下次版本一起处理”。下次复下次，下次何其多。

更隐蔽的短板，出现在“不知道”的层面。我们团队每周都开复盘会，但复盘的内容几乎全部围绕“这次事故是怎么发生的”“哪个环节响应慢了”。很少会有人问一句：“我们系统里还有哪些地方可能出问题，但还没出过问题？”这不是矫情。去年有一次数据迁移，因为源库字段定义不规范，导致部分历史订单的金额精度丢失。那个字段在文档里标注的是“decimal(10,2)”，实际生产环境却是“float”。要不是后来对账时发现有几笔账差了几分钱，这个问题可能到现在还躺在数据库里睡大觉。事后我们查了，这个字段是三年前一个实习生定义的，代码评审没人细看，文档也没更新。

这种“隐性漏洞”最可怕。它不像服务器宕机那样有巨响，而是像墙角的裂缝，一开始只有头发丝细，你不去管它，过个雨季，裂缝就能塞进拳头。我们在查漏洞时，习惯性地盯着那些“出过事”的地方，却很少主动去盘查那些“没出事但可能出事”的角落。比如，核心接口有没有做幂等性校验？第三方支付回调有没有处理重复通知？日志文件有没有设置滚动策略，避免磁盘写满？这些都不是新问题，但都是那种“不出事则已，一出事就是大事”的雷。

再往深里说，补短板还有一个绕不开的坎——人的惯性。我们组有个老工程师，技术绝对过硬，但他维护的那套老系统，代码注释几乎为零。他私下跟我说：“不是不想写，是这代码我自己半年前写的，现在看都觉得陌生，写注释得先花半天读懂自己写的东西。”这话听着像玩笑，但其实是真话。查漏洞补短板，很多时候不是技术能力不够，而是对“老账”的畏难情绪。人天生倾向于做那些反馈快、成就感强的事，比如写个新功能、做个炫酷的报表。而梳理旧代码、补测试用例、完善监控告警，这些事干半天也看不见什么明显成果，自然就被搁置了。

最近我们换了个做法，不算高明，但有效。每个迭代周期强制留出20%的时间，专门处理技术债——不接新需求，只干三件事：清垃圾代码、补关键日志、修已知但不紧急的bug。刚开始阻力不小，产品经理觉得这是在“浪费产能”，但跑了两个迭代之后，系统稳定性肉眼可见地提升了。上个月那次压测，虽然还是没能完全扛住，但至少崩溃时间从原来的五分钟缩短到了四十秒。四十秒依然不合格，但起码说明方向是对的。

查漏洞补短板，说到底不是一次专项行动，而是得把它当成日常的呼吸。你不能等胸闷了才想起来要锻炼肺活量，也不能等系统崩了才后悔当初没多看一眼那条告警日志。漏洞永远查不完，短板永远补不尽，但只要这个动作不停下来，它就不会在某个深夜变成一场让你措手不及的火灾。