容量规划基础：定义、核心指标与业务意义

容量规划（Capacity Planning）是确保系统在可预见的负载下稳定运行、同时避免资源浪费的系统性工程。它通过量化业务增长与基础设施供给之间的关系，为扩容、限流、降级等运维决策提供数据依据。在混沌工程与版本漂移校准的联合测试中，容量规划是评估变更是否导致性能退化的基准线。

容量规划的定义

容量规划是指在给定服务水平协议（SLA）的前提下，预测系统在未来一段时间内所需的计算、存储、网络等资源，并制定相应的资源供给策略。其核心目标可概括为：

• 保障可用性：确保峰值流量下系统仍能满足响应时间与错误率阈值。
• 优化成本：避免过度预配导致的资源闲置，也防止欠配引发的服务降级。
• 支撑业务增长：将业务指标（如日活、订单量）映射为技术指标，指导扩缩容节奏。

核心指标及其业务意义

容量规划依赖四个核心量化指标：QPS、TPS、RT、资源利用率。下表给出了各指标的定义、度量单位与典型业务映射关系。

指标间的联动关系

四个指标并非孤立存在，它们之间存在典型的联动规律。以下 SVG 图展示了在典型 Web 服务中，QPS 上升如何依次影响 RT 与资源利用率，并最终触发容量阈值。

各指标的详细解读

1. QPS 与 TPS

• QPS 侧重读密集型场景（如商品详情页、搜索结果），通常通过缓存、CDN、读写分离来提升。
• TPS 侧重写密集型场景（如订单创建、支付扣款），对数据一致性要求高，通常受数据库写入能力限制。
• 容量规划要点：分别统计读/写路径的峰值 QPS/TPS，并预留 30%~50% 的缓冲水位。

2. 响应时间 (RT)

• 通常关注 P50（中位数）、P95、P99 分位值，而非平均值。
• P99 RT 超过 500ms 时，用户体验明显下降；超过 2s 会导致大量用户流失。
• 在容量规划中，RT 是判断系统是否接近饱和的早期信号——RT 开始非线性增长时，往往意味着资源即将耗尽。

3. 资源利用率

• CPU：通用计算瓶颈，建议长期水位 ≤ 70%，峰值 ≤ 85%。
• 内存：Java 堆、缓存、连接池等，建议 ≤ 80%，避免 GC 频繁或 OOM。
• 磁盘 I/O：数据库、日志写入场景，IOPS 和延迟是关键。
• 网络带宽：大流量场景（视频、文件上传）需单独规划。

容量规划的业务意义

从 SRE 视角看，容量规划直接服务于以下业务目标：

1. 保障大促/秒杀峰值：提前根据历史峰值 + 业务增长率预估资源，避免系统过载。
2. 成本控制：通过弹性伸缩策略，在低峰期释放资源，降低云支出。
3. 版本变更安全评估：新版本上线前，对比容量基线，判断是否存在性能退化。
4. 容量瓶颈定位：通过资源利用率与 RT 的关联分析，快速定位是 CPU、内存还是 I/O 成为短板。

下表总结了不同业务场景下容量规划的重点关注指标：

容量规划与版本漂移校准的关联

在联合测试框架中，容量规划提供 性能基线，而版本漂移校准检测 配置/代码偏差。两者结合可以回答以下问题：

• 新版本是否因为代码变更导致 QPS 上限下降？
• 配置漂移（如连接池大小、线程数）是否改变了资源利用率与 RT 的关系？
• 容量规划模型是否需要根据新版本的性能特征重新校准？