背景
做了 15 年性能优化，我带过的团队里，压测报告几乎年年都绿，但上线后照样翻车。不是玄学，是结构性问题。三个真实案例（已脱敏）：
案例 A：某电商支付链路，压测环境 8C16G × 4 副本，JMeter 打 5000 TPS 稳态 30 分钟，P99 = 45ms，报告结论"余量充足，可支撑 2 万 TPS"。大促当天实际 1.2 万 TPS 时 P99 飙到 380ms。事后排查：压测用的数据库是独立 RDS，buffer pool 48G 全热；线上主从共库，从库还跑着 3 个报表查询，buffer pool 被报表页挤掉了 60%。压测的"热数据假设"在线上根本不成立。
案例 B：一个 gRPC 微服务，压测用 gRPC-Go 的 round_robin 负载均衡，100 个并发连接均匀打 5 个 pod。线上走的是 K8s Service + iptables 随机转发，连接数 2000+，长连接分布极不均匀——某几个 pod 承接了 40% 流量，GC 频率是压测的 3 倍。负载均衡模型不同，GC 行为完全不同，P99 分布完全不可比。
案例 C：一个 Java 批处理任务，压测时输入数据是"均匀分布的 10 万条"，线上实际数据里 3% 的记录触发了一个 O(n²) 的关联计算，单条耗时 2 秒。压测平均 8ms/条，线上 P99 是 2100ms。数据分布的长尾在压测里被"均匀采样"抹平了。
这三个案例的共同点不是"压测没做好"，而是压测和线上之间有一个结构性的 gap，而这个 gap 在压测报告里是不可见的。
常见分歧（我在不同团队都听到过）
派系一：压测是"验收标准"，达标就该上线。 逻辑是：我们花了 2 周搭压测环境、写了 200 条用例、跑出了 P99 数据，如果这都不能作为上线依据，那这 2 周白花了。这个立场在资源紧张时特别有说服力——"再压一轮要 3 天，业务等不了"。
派系二：压测只能证明"不出大问题"，不能证明"不出小问题"。 逻辑是：压测环境是"理想化"的——硬件独占、数据干净、流量模型简化。它能暴露"容量不够"这种粗粒度问题，但暴露不了"buffer pool 被挤占"、"连接分布不均"、"数据长尾"这类细粒度问题。而真正让 P99 翻车的，恰恰是这些细粒度问题。
派系三：压测根本不该作为上线 gate，应该靠灰度 + 监控兜底。 逻辑是：与其花 2 周做一个"不可信"的压测，不如把 2 周花在灰度策略和监控告警上。1% 灰度 → 5% → 20% → 100%，每一步都有真实流量验证，出了问题秒级回滚。压测报告只是"参考"，不是"准生证"。
三派都有道理，也都有盲区。我见过派系一导致"报告绿了、上线翻车"；也见过派系三导致"灰度 1% 跑了两周没人看监控，等扩到 50% 才发现 P99 已经劣化 3 倍"。
我的倾向与理由
我倾向于一个折中但更务实的框架：压测是"下限测试"，不是"达标测试"。
- "达标"是一个二元判断：P99 < 50ms？是/否。这个判断隐含了一个假设——"压测环境 ≈ 线上环境"。上面三个案例说明这个假设不成立。
- "下限"是一个区间判断：在 X 倍流量下，系统的瓶颈出现在哪里？是 CPU、是 I/O、是锁竞争、是 GC？压测的价值不是给出"P99 = 45ms"这个数，而是给出"在 5000 TPS 下，CPU 72%、buffer pool 命中率 98%、GC 暂停 P99 = 12ms"这组资源画像。上线后监控这组画像，任何一个指标偏离压测基线 20% 以上就告警。
换句话说：压测报告里最值钱的不是 P99 那行数字，而是"在什么资源状态下跑出了这个 P99"。 上线后你要盯的不是"P99 有没有超 50ms"，而是"buffer pool 命中率是不是还是 98%、GC 暂停 P99 是不是还在 12ms 以内、连接分布是不是还均匀"。
这个框架的好处是：
- 它不要求压测环境 100% 模拟线上（做不到，也不该做）；
- 它把"压测达标"从一个二元 gate 变成了一个持续监控基线；
- 它天然和派系三的灰度 + 监控兼容——灰度期间就是在验证"资源画像是否偏离压测基线"。
但我也有一个没想清楚的点：如果压测报告只给"资源画像"不给"P99 达标"，业务方（产品 / 运营）会不会不买账？ 他们要的就是"5000 TPS 下 P99 < 50ms，可以上线"这句话。你怎么把一个"资源画像"翻译成业务方能理解的"能不能上"？
想听大家在什么场景下怎么选
- 你们团队的"压测达标"判据是什么？是 P99 < X ms？还是 CPU < Y%？还是"业务方签字确认"？这个判据是谁定的——SRE、开发、还是业务方？
- 你们有没有"压测绿了、上线翻车"的案例？事后归因是什么？是压测环境的问题，还是上线后流量模型变了，还是"压测根本没覆盖到那个场景"？
- 你们用不用"灰度 + 监控"替代"压测 gate"？如果用了，灰度期间监控哪些指标？有没有"灰度 1% 跑了一周、扩到 50% 才发现问题"的经历？
- 一个更尖锐的问题：如果压测和线上之间永远存在一个不可消除的 gap，那"压测"这个动作本身的价值到底在哪里？是"证明能扛住"还是"找到瓶颈"还是"给业务方一个心理安慰"？
欢迎带数据来聊。我手头有案例 B 里 K8s iptables vs gRPC round_robin 连接分布的对比数据（1000 连接 × 5 pod 的分布直方图），需要的话可以脱敏贴出来。