上周跟做电商的老同学喝酒，他脸都喝红了。说上次618大促，他们团队提前三周做的性能压测，报告写得漂漂亮亮，说核心交易链路能扛12万QPS，结果当天刚到4万QPS，支付接口直接超时，整个站点瘫了22分钟，算下来损失了小一百万。
查原因查到半夜才发现，压测的时候为了凑好看的数字，他们把所有非核心的埋点上报、商品推荐、用户评价接口全给停了，压测环境的数据库配置比生产高了整整三倍——等于测的是个脱了装备的满血号，真上线了穿一身普通装备出门，三刀就被秒了。
压测达标报告的水分从哪来
我见过太多团队的压测流程，从一开始就走歪了。
提前一周把压测环境收拾得干干净净：所有无关的服务全停，日志级别调到最高，连数据库的慢查询日志都给关了，就怕多出来的IO占了资源。压测时间卡得刚好，刚摸到预设的QPS阈值就立刻停止，根本不跑长时稳定性测试——你要是真连续压两个小时，内存泄漏、连接池耗尽这些问题全得冒出来。
最离谱的是配置差。之前有个做在线教育的团队，压测完说直播推流接口能扛8万并发，结果上线当天2万并发就把边缘节点打满了。回头核对配置，压测用的边缘节点是16核32G的物理机，生产节点是2核4G的虚拟机。
这测出来的数有什么用。
说白了，大家做压测的时候总想着“先把数字做上去交差”，却忘了最核心的判断标准：压测环境的所有配置、所有依赖、所有开关，必须和生产环境完全对齐。你要是偷偷关了限流、关了熔断、把非核心功能全摘了，哪怕测出来能扛100万QPS，真上线了该崩还是崩。
别把压测当成甩锅给开发的工具
还有个特别常见的误区：压测一发现接口响应时间不达标，运维直接把报告甩给后端开发，说你们这接口写得太烂，赶紧优化。
我上次遇到个团队，测用户中心的个人信息接口，压测出来99分位响应时间2.3秒，开发熬了三天做SQL优化、加缓存，结果响应时间还是没降到预期。最后翻压测脚本才发现，脚本里每个请求都带了个参数，要拉取当前用户过去三年的所有订单记录。
真实用户点个人中心的时候，哪会每次都拉全量历史订单啊？真实场景下这个接口的响应时间本来就在200ms以内，是压测脚本的参数完全脱离了真实用户的请求分布，才测出来个离谱的数字。
折腾三天，全是无用功。
压测从来不是为了找个背锅的人。你得把瓶颈定位到具体的环节：是数据库出现慢查询了？还是网关的连接池大小设小了？还是压测脚本本身写得有问题？要是连问题出在哪都没搞清楚就开始甩锅，最后耗的全是团队的时间。
真的，这种事见多了就觉得，很多团队的压测，本质上是为了走个过场证明“我们做过压测了”，根本没想着真的去摸清楚系统的能力边界。
压测完不做预案等于白测
很多人觉得，压测完拿到一个达标数字，这事就算完了。
错。
你测出来系统能扛5万QPS，那你有没有测过，当QPS到4万的时候，系统开始出现响应时间陡增，这个时候你该做什么？是自动扩容弹性实例？还是临时把非核心的推荐、评论功能暂时关掉？还是把数据库的读流量切到只读从库？
之前那个做电商的老同学就是这样，压测的时候明明测到4.5万QPS的时候就已经出现零星的接口超时，但是没人当回事，觉得离预设的12万目标还差得远。结果当天真实流量到4.2万的时候，几个爆品的请求全集中打在一个数据库分片上，直接把分片打挂了。他们连对应的预案都没写，值班的人翻了半天手册，才想起来可以手动切流量，等切完已经过去20多分钟了。
好的压测从来不是为了报个多高的吞吐量数字。是你在压测的过程中，把系统所有可能出问题的节点全摸一遍，提前想好对应的应对动作。比如你测的时候发现，只要把商品详情页的静态资源全切到CDN，整体就能多扛30%的流量，那你在大促前就把这个配置打开，而不是等站点崩了才临时改。
还有，压测的时候得把真实的故障场景加进去。比如某个机房的网络断了，系统能不能自动切流量到备用机房？某个核心依赖的服务挂了，熔断机制能不能正常生效？这些东西，平时不压，真出问题的时候就是手忙脚乱的灾难。
上周跟老同学再吃饭，他们团队现在改了整套压测流程：压测环境完全同步生产的配置，压测脚本的参数全是从生产日志里扒出来的真实用户请求分布，压测完第一时间拉上开发、运维、产品一起过所有的瓶颈点，把对应的应急动作一条条写进值班手册里。
前几天他们做小范围的会员日促销，峰值流量到了之前压测值的80%，整个系统稳得一批，连个紧急告警都没弹。
压测哪有那么玄乎。
无非就是把你未来要面对的真实流量，提前在测试环境走一遍，别等真到了上线那天，才发现自己的系统根本扛不住。