系统漏洞更新

凌晨三点十七分，系统运维群里弹出一条告警：核心网关响应延迟飙到800毫秒。漏洞我盯着屏幕，更新手里的系统泡面刚拆开。这不是漏洞第一次了，每次版本更新后总得闹点幺蛾子。更新但这次不一样——延迟曲线像心电图一样规律，系统每五分钟一个波峰，漏洞准时得让人发毛。更新

我翻出上周的系统更新日志，三十七个提交记录里藏着一个不起眼的漏洞改动。某个同事把缓存过期时间从300秒改成了297秒。更新理由写在注释里：“避免整点刷新造成资源争抢。系统”逻辑上说得通，漏洞可实际跑起来，更新297秒的过期时间刚好和某个定时任务撞了车。每五分钟，缓存集体失效一次，所有请求直接压到数据库上。数据库扛不住，开始排队，网关跟着堵。一个三秒的改动，炸了整个链路。

这让我想起去年那个更离谱的漏洞。当时我们给用户中心加了个“最近登录设备”功能，代码里用了个第三方库来解析User-Agent。测试环境跑得好好的，上线第二天客服电话被打爆——大量用户被识别成“未知设备”，登录记录全乱套。排查了半天，发现那个库在解析某些国产浏览器时会把版本号后面的空格吃掉，然后整个字符串解析就崩了。更绝的是，这个库在GitHub上最后更新是四年前，issue里早有人提过这个bug，作者回复说“不符合标准格式，不修”。

标准。这个词在技术圈里跟咒语似的。HTTP标准、RFC文档、W3C规范，写得明明白白。可现实世界里，浏览器厂商各有各的脾气，设备厂商各有各的魔改，连运营商都会偷偷往流量里塞东西。你按标准写代码，跑起来才发现到处都是坑。有个前辈跟我说过一句话：写代码要像防贼一样防输入。当时觉得夸张，现在觉得是真理。

回到那个缓存漏洞。修复方案很简单，把297改回300，再加个随机抖动。但我在想另一个问题：为什么这个改动能通过代码评审？因为注释写得太合理了，合理到没人去查297和定时任务的关系。代码评审看逻辑，不看时序。逻辑对，时序错，照样炸。这就像你检查一栋楼的图纸，每根梁都标了承重，但没人算过所有梁同时受力会怎样。

后来我们加了个规矩：任何涉及时间参数的改动，必须画一张时间轴图，标出所有相关任务的执行点。麻烦是麻烦，但总比凌晨三点被叫起来强。我还见过一个团队更狠，他们把所有定时任务的时间参数都改成质数，这样除非周期完全一致，否则永远不会撞车。数学解决工程问题，听着挺酷，实际上就是被逼出来的土办法。

漏洞这东西，修得越多越觉得修不完。不是技术不行，是系统太复杂。一个电商系统，前端、网关、缓存、数据库、消息队列、第三方支付、物流接口，每个环节都有自己的时间刻度。你调一个参数，可能三个月后才会在某个边缘场景里爆发。所以我现在看到“更新”两个字就条件反射地紧张——不是怕改错，是怕改对了却不知道哪里会错。

天快亮了，延迟曲线终于平了。我关掉监控页面，泡面已经坨了。群里有人问要不要回滚，我说不用，改个参数的事。但心里清楚，下一个297秒的坑，说不定已经在某个分支里等着了。