系统跑得慢，查漏不一定是洞问短板代码写得烂。上个月帮一家做仓储管理的着力制约公司排查问题，他们的解决出库单打印接口响应时间从200毫秒飙到4秒。运维第一反应是瓶颈加服务器，数据库连接池从50调到200，查漏结果更卡了。洞问短板后来抓了一次火焰图，着力制约发现罪魁祸首是解决一个循环里反复查同一张配置表，每次都要走一次网络IO。瓶颈改成本地缓存后，查漏响应时间掉回180毫秒。洞问短板瓶颈往往藏在最不起眼的着力制约调用链里，不是解决靠堆资源能解决的。

查漏洞这件事，瓶颈很多人习惯从代码规范入手，查空指针、查SQL注入、查日志脱敏。这些当然要做，但真正拖垮系统的，通常是那些“看起来没问题”的设计。比如一个订单状态机，代码里写死了七八个状态流转条件，每加一个业务场景就要改一次if-else。半年后没人敢动那段逻辑，因为谁也不知道改了会不会影响其他分支。这种短板不是靠加注释能补上的，得重新画状态图，把流转规则抽成配置或独立服务。

我见过一个更典型的例子。某电商平台的购物车服务，平时QPS不到一千，大促前压测直接崩了。查下来是Redis的big key问题——每个用户的购物车存成一个Hash，热门用户的Hash里塞了几千个商品ID。单次HGETALL要拉几十KB数据，网络带宽先扛不住。团队一开始想换Redis集群，后来改成按商品分片存储，每个key只存一个商品条目，问题才根治。短板不在Redis本身，在数据建模的粒度上。

找瓶颈得动手，不能光靠开会。我习惯用三种手段：链路追踪看耗时分布，日志采样找异常模式，还有最笨但最有效的——把生产流量复制一份到预发环境，用真实请求打一遍。有一次发现某个内部服务的超时设置是30秒，上游调用方只等5秒，结果每次超时都触发重试，重试又堆积，把线程池占满。这种漏洞在代码审查里根本看不出来，只有跑起来才会暴露。

还有一类短板是组织层面的。开发、运维、测试各管一段，没人对全链路负责。一个接口挂了，开发说网络问题，运维说代码没释放连接，测试说压测环境配置不对。最后查出来是负载均衡的健康检查间隔太长，故障节点没及时摘掉。这种问题靠技术手段解决不了，得有人把整条链路串起来看。我们后来搞了个“故障演练日”，每月抽一天随机注入延迟或异常，逼着大家从全局视角找短板。

解决瓶颈制约，最怕的是“头痛医头”。数据库慢就加索引，接口慢就加缓存，消息积压就加消费者。这些手段短期有效，但如果不搞清楚根因，很快又会冒出新的瓶颈。我见过一个团队，每两周就要扩容一次Kafka，后来发现是消费者里有个同步调用外部HTTP接口的逻辑，外部接口一抖动，消费线程全堵住。把同步改异步后，三个月没再扩过容。

查漏洞、问短板，说到底是一种持续对抗系统熵增的习惯。没有一劳永逸的方案，只有不断逼近真实瓶颈的观察和实验。别迷信监控大盘上的平均值，去看P99，去看长尾请求的堆栈，去问一线运维最近什么告警最烦人。瓶颈往往就在那些被忽略的角落里，等着你动手把它揪出来。