云上压力测试全流程实战：从脚本编写到瓶颈分析，摸清系统上限
去年双11前，一个客户信心满满地跟我说：“我们系统肯定扛得住，平时流量翻三倍都没问题。”
我问他：“做过压测吗？”
“做过，用JMeter跑了几百个并发，一切正常。”
大促当天，流量确实只涨了三倍。但系统在第5分钟崩了。不是代码问题，也不是数据库问题。是日志写得太疯狂，磁盘IO打满了。他们在测试环境跑压测时，日志级别是WARN；生产环境是INFO，每秒写几千条日志，磁盘扛不住了。
这是压测最经典的翻车现场：你测的，和生产跑的，不是同一个东西。
今天聊聊云上压力测试全流程。不是那种“压测很重要”的入门课，而是帮你理清楚：从定目标到写脚本，从执行到分析瓶颈，怎么测才能测出真实上限。
01 定目标：先问自己三个问题
很多人上来就开压，问目标是什么？“看看系统能扛多少。”这不是目标，是好奇心。
压测前必须回答三个问题：
第一，测什么业务场景？ 核心链路是下单、登录、还是刷商品？非核心链路要不要测？大促当天的用户行为路径是什么样的？先画出来，别漏了关键环节。
第二，目标值是多少？ 目标QPS、目标响应时间（P99）、目标错误率。没有目标，压测就是瞎跑。可以基于历史峰值数据设定，比如去年双11最高5000 QPS，今年目标8000。
第三，接受什么样的失败？ 是允许少量超时还是零容忍？是能接受降级还是必须全链路正常？把这些底线划清楚。
那家电商的目标是“扛住3倍流量”，但没有细化。日常峰值500 QPS，目标1500。但下单、加购、搜索的QPS分布不一样，他们没分开测，混在一起跑，结果失真。
02 准备环境：测试环境要像生产
硬件配置要一致。测试环境4核8G，生产8核16G，压出来没意义。至少保持和生产同比例。
数据量级要接近。生产订单表1亿行，测试环境只有1万行，SQL执行计划可能完全不同。生产走索引扫描，测试走全表扫描——压测结果完全反的。
日志级别要对齐。前面那家客户的翻车点就在这里。测试WARN，生产INFO，磁盘IO差了几倍。
依赖服务要真实。如果依赖第三方支付，用Mock还是真实接口？用Mock要确认Mock的耗时和行为和生产一致。用真实接口要提前沟通，别把对方压崩了。
那家客户后来重建了压测环境：从生产复制脱敏数据，配置和生产1:1，日志级别同步。再压出来的结果和线上表现就基本一致了。
03 写脚本：场景要真实，参数要随机
压测脚本写得不真实，结果就是“假通过”。
场景编排要贴近用户行为。真实用户不是一直在点，有思考时间、有操作间隔。脚本里要加Think Time，比如每次请求间隔100-500ms随机。
参数要随机化。固定参数会导致缓存命中率虚高，或者热点数据不均。用CSV文件准备一批真实参数（用户ID、商品ID），让每个虚拟用户用不同的值。
断言要完整。不仅检查HTTP状态码200，还要校验返回体里的业务状态码。接口返回200但内部错误码是5001，你的压测工具可能算作成功，但实际上业务是失败的。
那家电商的脚本只测了下单接口，没测登录、没测加购。大促当天，登录接口先崩了，用户进不来，下单接口根本用不上。
04 执行：渐进加压，边跑边看
压测不是一上来就怼满，要按梯度加压。
阶梯式加压：从低并发开始，比如100 VU，跑3分钟稳定；加到500 VU，跑3分钟；加到1000 VU，以此类推。观察每个梯度的TPS、响应时间、错误率。
寻找拐点：当TPS不再随并发增加而增长，反而开始下降时，说明系统到了瓶颈。此时的TPS就是系统上限。
脉冲式测试：模拟突发流量，瞬间加到峰值，观察系统能否扛住尖峰。
持续稳定性测试：在目标水位跑30分钟以上，观察是否有内存泄漏、连接池耗尽。
那家客户只做了阶梯加压，没做脉冲测试。大促当天的流量是脉冲式的——前5秒直接冲顶，不是慢慢涨上来的。
05 分析瓶颈：看指标，找证据
压测跑完了，数据拿到了，然后呢？
看哪个指标先异常。是TPS上不去了？响应时间飙了？错误率升高了？还是系统资源满了？先定位异常类型，再找根因。
分层排查：
常见瓶颈：
TPS上不去，CPU不高 → 可能是锁竞争、线程池太小、外部依赖慢
CPU跑满 → 可能是代码效率问题、死循环、大量计算
磁盘IO高 → 看日志级别、是否在写大量临时文件
那家电商的瓶颈最终定位在磁盘IO。监控发现，加压到目标水位时，磁盘写延迟从1ms飙到200ms。进一步排查，日志每秒写入量是测试环境的30倍，因为生产日志级别不一样。
06 优化与回归：改完再测，闭环验证
找到瓶颈后，优化，然后重新压测验证。
验证优化效果：优化前后同场景对比，TPS是否提升？响应时间是否下降？
回归核心场景：防止优化A问题导致B场景性能回退。
更新基线：优化后的性能数据成为新的基准，下次压测以此为参考。
那家电商把日志级别从INFO调回WARN（业务日志另做采样），再压一遍，TPS从800升到了2200，磁盘IO恢复正常。
写在最后
压力测试不是跑个脚本出个报告就完事了。它是容量规划的核心依据，是上线前的最后一道防线。
那家电商的运维负责人后来总结了一句话：“压测不是证明系统有多强，是发现系统有多弱。发现的弱点多，改完就强了。”
你的压测，是在证明“我能行”，还是在发现“哪里不行”？
