上周陪朋友去他在徐庄软件园的公司开618前的压测启动会。
一屋子人坐得整整齐齐，运维的哥们把JMeter报告往投影上一投，声音洪亮：”我们系统现在能稳定扛1万QPS，绝对没问题。”
产品当场就皱了眉。说去年大促，QPS才刚到8000，用户点提交订单的按钮要转三秒才出结果，一半的人直接退出去了，你这1万QPS的数是怎么压出来的？
运维也懵了。说我就按平时的压测脚本跑的啊。
你压的到底是啥
这就是绝大多数团队压测的通病。盯着QPS、平均响应时间两个数死磕，从来没认真看过指标背后的东西。
平均响应时间200ms，看着挺好看。但你把报告往细了翻，99分位延迟早就飙到了2000ms。什么意思？100个发请求的用户里，最慢的那个要等两秒才能拿到结果。用户感知到的“卡”，从来不是平均出来的数字，就是那几个慢到离谱的请求攒出来的。
还有更离谱的。上次我见个团队，压测的时候把所有测试数据造得一模一样，商品ID全是连续的，库存数全是100，连数据库的缓存命中率都能稳定在100%。这种环境下压到5万QPS都不飘，结果上线第一天，生产环境的订单表已经存了半年的历史数据，同样的脚本跑上去，QPS刚到1万，数据库CPU就直接打满了。
白忙活一周。
压测不是为了凑个好看的数字
很多团队做压测，从一开始方向就错了。
不是为了测系统到底能扛多少流量，是为了给老板交差——我们测过了，系统能扛X万QPS，大促稳了。
至于压测的流量是不是和真实用户行为匹配？没人管。大促当天的流量本来就不是均匀分布的：有30%的人在反复刷商品详情页，25%的人在点提交订单，15%的人在查物流，还有10%的人在后台改商品价格。你要是把所有压测流量全往首页打，就算压到10万QPS，核心的下单链路该崩还是崩。
更有甚者，为了让压测数据好看，偷偷把日志级别全改成最高的ERROR，慢查询日志直接关掉，甚至把核心接口的超时时间从3秒改成10秒。压测的时候响应时间确实降了30%，上线才发现，线上出了问题连日志都查不到，整个团队熬了三个通宵排障。
你说这图啥？
真的。压测跑出来的数字再好看，最后抵不过用户真实的一次点击卡顿。
真正有用的压测要拉上所有人
别再觉得压测是运维一个部门的事了。
产品得全程在。大促的时候哪个链路是核心，哪个功能出了问题会直接影响营收，得给个明确的优先级。别等压测完了才发现，你花了一半资源压的是个没人用的活动页，核心的支付接口连压都没压到。
开发得跟着蹲在压测现场。哪条接口慢了，是代码里写了循环查数据库的烂逻辑，还是缓存没做预热，当场就能定位。别等压测报告甩到开发群里，过了三天才有人回一句“我最近忙，下周再改”——那压测还有什么意义？
测试得兜底。压测过程中出的异常，是真的系统扛不住流量，还是测试数据造得有问题，得有人快速分辨。上次我朋友团队压测的时候，发现支付接口延迟突然飙到5秒，开发过来查了半小时，才发现是测试同学把测试的支付沙箱地址配成了生产环境的真实地址，白紧张半天。
对了，还有个最基础的常识，压测流量一定要做标识隔离。别直接把测试请求打到生产库，记得配影子表，别像去年那个团队似的，压测的时候把几百条测试订单写到了用户的真实订单列表里，被用户投诉到12315，赔了小一万的优惠券。
说白了。
你压测的时候偷的懒，最后都会变成大促当天凌晨三点，你在徐庄软件园楼下便利店买的那杯难喝的冰美式。