修复漏洞工作专项总结

修复漏洞工作专项总结

上周三凌晨两点，修复值班同事在监控面板上看到一个异常指标：订单服务的漏洞响应延迟从80毫秒跳到了1.2秒。这不是工作第一次了，过去一个月里，专项总结类似的修复问题反复出现三次，每次都是漏洞重启了事。但这次我们决定不再绕过去。工作

排查从日志开始。专项总结ELK里搜出来的修复堆栈信息指向一个看似无关紧要的定时任务——它每五分钟跑一次，负责同步用户积分。漏洞代码里有一段循环查询，工作没有分页，专项总结用户量涨到四十万之后，修复这个查询开始拖慢整个数据库连接池。漏洞问题本身不复杂，工作但它暴露出来的东西更让人头疼：这个任务当初是谁写的、为什么没有分页、为什么没人发现，答案都是“不知道”。

我们做了三件事。第一，给那段查询加上分页和索引，单次执行时间从4.7秒降到0.3秒。第二，把定时任务从主库切到只读从库，避免它再跟核心业务抢连接。第三，也是我觉得最值得说的——在代码仓库里加了一条CI检查规则：任何循环体内出现数据库查询的代码，直接拒绝合并。这条规则上线两周，拦下了六个类似的隐患。

但修复本身只占这次工作量的三成。剩下七成花在了两件事上：确认影响范围和补测试。影响范围这块，我们翻了近半年的慢查询日志，发现受影响的接口有十一个，其中三个是支付相关的。测试补了十二个用例，覆盖了积分同步的边界条件——比如用户ID为空、积分值为负数、并发更新同一条记录。这些用例跑通之后，我才觉得这个漏洞算是真正关上了。

有个细节值得记一笔。修复过程中，一位同事提出要不要顺便把那个定时任务的执行频率从五分钟改成十分钟。讨论之后我们没改。原因是频率降低意味着积分到账延迟增加，客服那边可能接到更多投诉。修复漏洞的原则是解决根因，不是顺手改需求。这个判断后来被证明是对的——改成十分钟的话，那个慢查询的触发概率确实会降低，但问题依然存在，只是被掩盖了。

从数据上看，修复上线后第一周，订单服务的P99延迟稳定在110毫秒以内，数据库连接池的等待队列长度从平均17降到了2。第二周，我们把这个案例写进了内部的技术复盘文档，重点不是“怎么修的”，而是“为什么拖了这么久才被发现”。监控面板上那个延迟指标其实一直都有，只是没人设告警阈值。现在阈值设了，告警也接了值班手机。

这次修复给我的最大感受是：漏洞从来不是单独存在的。一个没分页的查询背后，是代码审查的缺失、监控的粗放、以及“重启能解决就先不深究”的惯性。修一个漏洞花了两天，但把上面这三样东西补上，花了整整三周。值不值？看下一季度的故障数量就知道了。至少到现在，那个凌晨两点的告警没再响过。