一、压测基础：系统稳定性概念、压测目标与原则、压测在研发流程中的位置
1.1 系统稳定性，到底是个啥？
先问大家一个问题：什么样的系统算「稳定」？
很多人第一反应是「不出错」。嗯，这话没错，但太笼统了。我个人的理解是——系统稳定性，是系统在持续运行中，面对各种突发流量、硬件抖动、网络波动时，依然能提供正确服务的能力。
说白了，就是「扛得住、不崩盘、恢复快」。
我在项目中遇到过这么一件事：一个电商平台，平时跑得稳稳当当，双十一零点一到，流量瞬间暴涨 10 倍。结果呢？数据库连接池被打满，接口响应从 20ms 飙升到 5s，最后整个系统雪崩。你说它平时稳定吗？稳定。但面对高并发，它就不稳定了。
所以，稳定性不是「现在没问题」，而是「极端情况下也没问题」。
核心三要素：
- 可用性：服务能正常访问，不宕机
- 可靠性：数据不丢、逻辑不错、结果正确
- 弹性：遇到压力能自动伸缩，扛得住波动
1.2 压测的目标：你到底想测什么？
很多团队做压测，上来就怼 QPS（每秒查询数）。测出来 5000，就觉得自己很牛。但我想说——压测不是刷分，是找短板。
我习惯把压测目标分成三层：
| 层次 | 目标 | 典型问题 |
|---|---|---|
| 第一层 | 摸清系统容量上限 | 最大 QPS 是多少？并发用户数上限？ |
| 第二层 | 发现性能瓶颈 | CPU 打满？数据库慢查询？内存泄漏？ |
| 第三层 | 验证稳定性与容错 | 长时间运行会不会 OOM？节点挂了能恢复吗？ |
你想想看，如果只测第一层，你只知道「能扛多少」，但不知道「哪里会先扛不住」。我曾经帮一个团队做压测，他们 QPS 能到 8000，但一跑 30 分钟，内存就涨到 90%。这就是典型的「容量够，稳定性差」。
我的建议：每次压测前，先问自己三个问题——
- 这次压测要验证什么假设？
- 预期结果是什么？
- 如果结果不符合预期，下一步怎么排查？
想清楚再动手，别上来就开压。
1.3 压测原则：别踩这些坑
做压测这么多年，我总结了几条铁律。嗯，都是血泪换来的。
原则一：压测环境要「像」生产
很多人图省事，在开发环境压。结果呢？开发库数据量只有 100 条，生产库 1 亿条。压出来的结果，完全没参考价值。
我建议：数据量、硬件配置、网络拓扑，尽量和生产保持一致。实在不行，至少数据量要按比例缩放。
原则二：压测要「有节奏」
别一上来就 1000 并发。我习惯的做法是：先 10 并发跑一轮，看看基线；然后 50、100、200 逐步加压。每轮跑 5-10 分钟，观察各项指标。
为什么会这样？因为系统崩溃往往不是瞬间的，而是渐进式的。你慢慢加压，才能看到「拐点」在哪。
原则三：压测不是「一次性」的事
有些团队，上线前压一次，然后就再也不管了。这不对。系统在变，流量在变，代码在变。我建议：每次大版本发布前，至少做一次回归压测。
避坑指南：我曾经见过一个团队，压测时发现接口没问题，但上线后还是崩了。为什么？因为他们压测时只测了单个接口，没测混合场景。真实用户是「又下单、又搜索、又登录」的。所以，压测场景要尽量模拟真实用户行为。
1.4 压测在研发流程中的位置
这个问题，很多公司都没想清楚。压测到底该放在哪个阶段？
我个人的经验是：压测应该贯穿整个研发流程，而不是只在最后「验收」一下。
来看一个典型的流程：
| 阶段 | 压测做什么 | 谁负责 |
|---|---|---|
| 需求评审 | 评估新功能对系统性能的影响 | 架构师 + 测试 |
| 开发阶段 | 单接口压测，验证代码性能 | 开发自测 |
| 集成测试 | 混合场景压测，找瓶颈 | 测试工程师 |
| 预发环境 | 全链路压测，模拟真实流量 | 测试 + 运维 |
| 上线后 | 灰度压测，验证线上稳定性 | 运维 + SRE |
你看，压测不是「最后一关」，而是「每一关」。
我记得有一次，一个团队在开发阶段就做了单接口压测，发现一个查询接口响应时间超过 2 秒。开发一查，原来是 SQL 没加索引。如果等到集成测试才发现，改起来就麻烦了。这就是「左移」的价值——越早发现问题，修复成本越低。
总结一句话：
压测不是「上线前的仪式」，而是「研发流程中的体检」。每次迭代都做一次体检，系统才能一直健康。
1.5 本章小结
好，这一章我们聊了三个核心问题：
- 系统稳定性：可用性 + 可靠性 + 弹性，缺一不可
- 压测目标：摸清容量、发现瓶颈、验证稳定性
- 压测原则：环境像生产、节奏要渐进、持续做回归
- 流程位置：从需求到上线，压测贯穿始终
下一章，我会带大家搭建第一个压测环境，手把手写一个压测脚本。到时候咱们直接上手干，别光看不练。
嗯，今天就到这儿。有问题欢迎交流。