大促前三小时，压测报告显示TPS 3800，P99平滑得像镜面。你自信地睡去。六小时后，系统在真实流量涌入的第五分钟崩盘。监控屏上那条笔直的红色离线线，是你见过最沉默的控诉。

如果你见过这条线，说明你正在被一种无菌压测欺骗。

01 单一负载的谎言

绝大多数团队跑压测，路径惊人一致：开一个工具（ab、JMeter、wrk），配线程组，跑15分钟，看TPS、平均延时，导出报告，存档，上线。

这套流程最大的问题，不是错——而是过于仁慈。

真实生产环境的崩溃，极少发生在平滑递增的流量里。它总在你最安心的时候来：依赖服务抖了一下，重试风暴打穿连接池；宿主机邻居跑满内存带宽，你的CPU偷取周期（%steal）飙到40%；磁盘延迟从2ms变成200ms，而你压测时压根没测过慢磁盘。

传统压测是在无菌实验室测免疫力。混沌测试是把人扔进早高峰地铁，还塞一瓶病毒。

02 压测必须盯的五个“死神指标”

很多人跑完压测只看两个数：TPS和平均响应时间。这两个指标只能告诉你“系统没死”，不能告诉你“离死还有多远”。

以下五个指标，是压测时必须同步监控的“死神凝视值”：

1. CPU %steal（偷取时间）：虚拟化环境下宿主机抢走的时间。超过5%，说明邻居在跟你抢资源。

2. 内存swap用量：si/so一旦持续大于0，性能已崩，压测数据作废。

3. TCP重传率：超过1%，网络层已现瓶颈。

4. 连接队列溢出（ListenDrops）：系统来不及accept，新连接被丢弃——这是雪崩前夜。

5. P99响应时间：比平均响应时间重要100倍。P99曲线出现拐点，意味着部分用户已经开始卡死。

没有资源监控的压测，是盲人摸象。

03 从压测到混沌：给系统加点“反派剧本”

2022年，一个电商客户用JMeter压Redis集群，三小时指标全绿。上线第三天，一次非核心业务的网络抖动，连接池瞬间打满，商品页雪崩。

问题出在哪？压测脚本从未模拟过“Redis超时”。

这就是传统压测的致命盲区：只测正常流，不测异常流；只测目标系统，不测依赖系统。

混沌测试的核心思想是：压测的同时，主动往系统里扔手榴弹，看它还能不能站住。

工具与一句话实践

• ChaosBlade（阿里开源）
  https://chaosblade.io/
  支持CPU、内存、网络、磁盘、JVM故障注入。一条命令让指定端口增加50ms延迟。

• tc（Linux内置）
  模拟网络延迟、丢包、乱序。
  tc qdisc add dev eth0 root netem delay 50ms

• stress
  制造CPU竞争、内存压力。
  stress --cpu 1 --timeout 60

一个小实验：压测时用tc给8080端口加50ms延迟，你会看到P99从50ms飙到800ms——这50ms的延迟，是传统压测永远测不出来的“真实世界”。

04 从报告到资产：算清楚“单核QPS”

压测的终点不是报告，而是容量模型。

很多团队压完只会说：“系统能扛2000 QPS。”——这句话毫无意义。2000 QPS是在多少核、多少内存、什么磁盘类型下测的？换个配置，数字就废了。

真正可复用的容量资产，是归一化指标：

• 单核QPS = 总QPS ÷ CPU核心数（压测时观察CPU是否打满）

• 内存驻留因子 = 每万QPS消耗的内存GB数

• 连接数放大系数 = 一个业务请求会放大成多少个下游请求

有了这些，你才能回答那个灵魂拷问：“从2000 QPS到20000 QPS，我需要加多少台机器？”

容量规划不是算命，是小学乘法。

05 信任不是测出来的，是摔出来的

一位做了十五年压测的老专家说过一句话：

“最稳的系统，不是测出来的。是每年大促崩一次，崩完加监控、加熔断、加降级，五年下来，想崩都难。”

这不是鼓吹不测就上线，而是想告诉你：压测的价值不在于证明系统今天不崩，而在于逼你提前面对那些“早晚会崩”的角落。

所以，下次跑压测时，别只在晴天测。挑个下雨天——网络打点延迟，磁盘塞点日志，CPU抢点时间。

如果它垮了，恭喜你。你在线下发现了线上一定会踩的坑。

这个坑值多少钱，你自己算。