查漏洞 补短板 抓提升

上周三凌晨两点，查漏运维群里弹出一条告警：订单服务响应时间从80毫秒飙到2.3秒。洞补短板我爬起来查日志，抓提发现是查漏一个新上线的推荐接口在高峰期疯狂调用用户画像服务，而那个服务压根没做缓存。洞补短板这就是抓提典型的漏洞——不是代码写错了，是查漏设计时压根没想过并发场景。

类似的洞补短板事我见过太多。去年有个团队做活动页，抓提测试环境一切正常，查漏上线五分钟就被羊毛党刷爆了。洞补短板后来复盘，抓提发现他们只测了正常用户路径，查漏没测过有人用脚本每秒发200个请求会怎样。洞补短板漏洞这东西，抓提往往不在你盯着看的地方，而在你默认“不会出问题”的环节。

补短板比查漏洞更考验人。查漏洞是找错，补短板是认怂——承认自己某方面就是不行。我见过一个技术很牛的团队，算法优化做到极致，但监控体系稀烂。服务器挂了半小时，还是用户打电话来投诉才知道。他们的短板不在技术深度，在运维意识。后来他们硬性规定：任何服务上线前必须配齐三个基础告警——CPU、内存、错误率。就这么个简单动作，事故响应时间从40分钟压到5分钟。

抓提升这件事，最怕变成喊口号。我待过一家公司，每季度都搞“技术提升月”，请大牛来分享，买在线课程，结果代码质量该烂还是烂。问题出在哪？提升没有落到具体动作上。后来换了个做法：每周五下午抽一小时，全组一起看这周提交的代码，挑三个最烂的片段，当场讨论怎么改。不请外援，不买课程，就盯着自己写的代码。三个月后，代码审查的驳回率降了六成。

提升的关键是找到那个“最小可改进单元”。比如你觉得系统性能不行，别上来就说“我们要重构”。先看慢查询日志，把TOP 10的SQL优化掉，可能就解决了80%的问题。再比如你觉得团队协作效率低，别急着换项目管理工具。先统计一下每天有多少时间花在等别人回复消息上，把这个数字降下来。小切口，深挖井，比铺大摊子管用。

还有个容易踩的坑：把补短板和抓提升混为一谈。短板是“不拖后腿”，提升是“比现在更好”。一个服务响应时间从2秒降到500毫秒，这是补短板。从500毫秒降到200毫秒，这才是提升。顺序不能乱。短板没补上就去追提升，就像地基没打好就盖二楼，风一吹就晃。

我自己的习惯是每个月做一次“技术体检”。拿张纸，左边写“最近出过什么问题”，右边写“哪些环节我心里没底”。左边是漏洞，右边是短板。然后从右边挑一个最没底的，定一个两周内能完成的动作。比如“给核心接口加上熔断降级”，或者“把部署脚本从手动改成自动”。做完划掉，下个月再挑下一个。不贪多，不搞运动式改进，就一个一个啃。

说到底，查漏洞靠的是敬畏心——别觉得自己写的代码不会出错。补短板靠的是诚实——别掩饰自己不懂的东西。抓提升靠的是耐心——别指望一蹴而就。这三件事没有终点，只要系统还在跑，人还在写代码，就得一直做下去。