容量压测基础：目标、关键指标与压测类型
容量压测是保障系统在真实流量冲击下稳定运行的核心手段。在 Runbook 联动场景中，压测结果直接驱动巡检阈值调整、扩缩容策略触发和故障预案执行。本节从目标、关键指标和压测类型三个维度建立容量压测的知识基线。
2.1 容量压测的核心目标
容量压测不是简单的“发请求看报错”，而是围绕以下四个目标展开的工程活动：
| 目标维度 | 说明 | Runbook 联动价值 |
|---|---|---|
| 容量摸底 | 确定系统在指定硬件/软件配置下的最大承载能力 | 为巡检脚本提供基线阈值（如 CPU 80% 触发告警） |
| 瓶颈定位 | 发现 CPU、内存、IO、网络、连接池等资源短板 | 驱动巡检脚本增加专项检查项（如连接池水位） |
| 弹性验证 | 验证自动扩缩容、限流降级、熔断等策略是否按预期生效 | 校验 Runbook 中弹性动作的触发条件和执行效果 |
| 容量规划 | 根据业务增长预测，输出资源扩容建议和压测报告 | 更新巡检脚本的告警阈值和容量水位标记 |
SRE 经验：容量压测的最终产出不是“最大 QPS 数字”，而是一组可被 Runbook 消费的容量基线数据，包括安全水位、告警水位、熔断水位和对应的关键指标阈值。
2.2 关键指标：QPS / RT / TP99 / 错误率
容量压测的四大核心指标构成了系统健康度的“四象限”。任何单一指标都不能完整描述系统状态，必须组合分析。
| 指标 | 全称 | 定义 | 典型阈值参考 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒处理的请求数，代表系统吞吐能力 | 根据业务场景设定，如核心链路 5000 QPS |
| RT | Response Time | 请求从发出到收到完整响应的耗时（单位 ms） | P99 RT < 200ms（在线业务） |
| TP99 | Top Percentile 99 | 99% 的请求耗时在此值以下，反映长尾延迟 | TP99 < 500ms（容忍上限） |
| 错误率 | Error Rate | 失败请求数 / 总请求数 × 100% | < 0.1%（核心服务） |
指标联动关系：当 QPS 持续上升时，RT 和 TP99 会先缓慢增长，到达拐点后急剧恶化；错误率通常在 RT 超过超时阈值后开始攀升。Runbook 巡检脚本应同时监控这四个指标，避免单一指标误判。
2.3 压测类型：负载 / 压力 / 稳定性
根据压测目的和施压模式，容量压测分为三种基本类型。Runbook 编排时需要根据场景选择或组合使用。
- 负载测试（Load Testing）：模拟正常业务流量，验证系统在预期负载下的表现。目标：确认系统能否承载日常峰值流量。Runbook 场景：日常巡检、发布前回归验证。
- 压力测试（Stress Testing）：持续增加负载直至系统崩溃或达到瓶颈，找到系统的极限承载点。目标：确定最大容量和失效模式。Runbook 场景：容量规划、弹性策略验证。
- 稳定性测试（Stability / Soak Testing）：在中等负载下长时间运行（数小时至数天），观察系统是否存在内存泄漏、连接泄漏、GC 异常等慢性问题。目标：验证系统长期运行的可靠性。Runbook 场景：大促前长稳演练、版本长期运行验证。
2.4 压测类型的选择矩阵
在实际 Runbook 编排中，需要根据压测目标和系统状态选择合适的压测类型。下表总结了三种类型的核心差异和适用场景：
| 对比维度 | 负载测试 | 压力测试 | 稳定性测试 |
|---|---|---|---|
| 施压模式 | 阶梯递增至目标负载 | 持续递增直至系统崩溃 | 固定中等负载长时间运行 |
| 持续时间 | 10~30 分钟 | 30~60 分钟 | 4~24 小时 |
| 主要关注点 | 响应时间、错误率 | 最大 QPS、瓶颈点 | 内存趋势、GC 行为、连接泄漏 |
| Runbook 触发场景 | 发布前回归、日常巡检 | 容量规划、弹性策略验证 | 大促前长稳演练、版本长期验证 |
| 失败标准 | RT/错误率超过阈值 | 系统不可用或指标急剧恶化 | 资源占用持续增长不收敛 |
常见误区：不要用负载测试的结果来推断系统的极限容量。负载测试只验证“预期负载”下的表现，而压力测试才能暴露系统的真实上限。Runbook 编排时，建议先执行压力测试确定极限值，再根据安全系数设定负载测试的目标值。
2.5 指标采集与 Runbook 集成要点
容量压测的指标数据需要被 Runbook 巡检脚本消费，因此采集和上报方式必须标准化：
- QPS 采集：从负载均衡器（如 Nginx、ALB）或网关层获取，使用 Prometheus Counter 类型指标。
- RT / TP99 采集：从应用侧埋点（如 OpenTelemetry、SkyWalking）或中间件（如 Redis、MySQL）慢日志获取。
- 错误率采集：区分业务错误（如 4xx）和系统错误（如 5xx、超时、连接拒绝），分别上报。
- 资源指标关联：将 QPS 与 CPU、内存、IO 等系统指标做时间对齐，便于定位瓶颈。
# 示例：PromQL 查询压测期间的 TP99 延迟（假设指标名为 http_request_duration_seconds）
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{job="api-server"}[5m])) by (le)
)
Runbook 集成建议：在压测脚本中增加指标断言步骤，压测结束后自动比对指标是否在基线范围内。如果 TP99 超过告警阈值，Runbook 应自动触发巡检脚本的阈值调整流程，并通知 SRE 确认。