> 本文由 苏州市天智教育培训中心 技术团队整理，基于真实生产故障复盘，面向一线运维与开发同学，可直接用于排障参考。
一、问题现象
压测报告写着 TPS 只有 200，但生产明明扛得住几千。压测机 CPU 才 20%，被压服务也很轻松——典型的"压测机先到瓶颈"，结论完全不可信。
二、排查思路速览
先按下面的路径走，每一步都有明确的判断分支，避免"上来就重启"这种无效操作。
三、先看清链路：自动化与性能测试 的典型架构
动手之前先明确"请求经过了哪些环节"，把问题定位到具体一层，排查效率会成倍提升。
四、根因分析
结合现场日志、监控与配置，逐条核对，绝大多数情况都能收敛到下面这几类原因：
- 用 GUI 模式压测，施压机自身就是瓶颈
- 压测机与压测目标同机，资源互相抢占
- 压测机数量不足，无法产生足够并发
- 只看 TPS 不看响应时间分布与错误率，结论片面
- 被压服务链路里 DB 或缓存是单点，早早到顶
五、处置过程
处置原则：先止血、再根治。先让业务恢复，再回头解决根因，不要在故障中做长期改造。
- 压测第一原则：先确认施压能力足够
- 用非 GUI 模式（jmeter -n -t）并调大堆内存
- 分布式压测，多台施压机错峰启动
- 关注 P95 / P99 与错误率，不只看平均值
六、关键命令与配置
下面这些命令/配置可以直接在生产上核对（执行前请确认环境与权限）：
# 正确姿势：非 GUI + 分布式 + 合理堆
# 施压机 JVM 调优（jmeter 启动脚本）
HEAP="-Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m"
# 命令行施压（不带任何 GUI 组件）
jmeter -n -t plan.jmx -l result.jtl -e -o report/ -R worker1,worker2,worker3
# 关键指标（别只看平均）
# TPS / P95 / P99 / 错误率 / 施压机 CPU
# 被压链路：DB 连接数、慢 SQL、缓存命中率、GC七、复盘
故障恢复后必须做复盘，重点不是"谁的责任"，而是"哪个机制缺位"：
- 根因是施压机只有 4 核还开着 GUI，TPS 卡在施压端
- 复盘发现压测报告没有记录施压机资源，无法复盘
- 压测环境与生产规格差异大，结论迁移性差
八、预防建议
- 压测报告必须包含施压机资源与压测模式
- 压测环境规格尽量与生产同构或明确折算比例
- 建立压测基线，每次对比而非孤立数字
- 压测时同步看被压链路的全链路监控
九、写在最后
上面这套排查方法，是 自动化与性能测试 在生产环境中最常见的一类问题，也是测试方向岗位面试里经常被追问的场景题。很多人搜「苏州测试」或者关心「苏州测试哪个好」，真正想确认的其实是：课程讲不讲真实的线上故障。我们在软件测试工程师课程里，会把这类故障做成实战演练——从监控曲线、日志、命令输出一路推到根因，再动手恢复，而不是背命令。苏州校区面授 + 线上同步，主打苏州测试方向的实战教学，就业推荐覆盖江浙沪。如果你正在做测试方向、或者想转行进入测试领域，可以了解一下我们的课程（苏州测试、苏州测试哪个好、软件测试培训），也可以直接联系我们做一次免费的职业与技术评估。