1. 容量规划基础：定义、目标与核心原则
1.1 容量规划的定义
容量规划（Capacity Planning）是指在给定服务水平目标（SLO）和成本约束下，预测、评估并持续调整IT 资源供给，使其恰好满足业务负载需求的过程。它不是一次性的“估算”，而是一个持续反馈、动态调整的闭环管理活动。
核心公式： 容量规划 = 需求预测 × 资源建模 × 成本优化 × 弹性策略
1.2 容量规划的核心目标
容量规划需要同时平衡三个相互制约的维度，通常被称为“容量三角”：
| 目标维度 | 关键指标 | 说明 |
|---|---|---|
| 性能与可用性 | P99 延迟、错误率、SLO 达标率 | 资源不足导致性能劣化、服务降级甚至中断 |
| 成本效率 | 资源利用率、单位请求成本、闲置率 | 过度预配造成浪费，云支出失控 |
| 弹性与敏捷性 | 扩容时间、缩容时间、突发应对能力 | 无法快速响应流量突增或业务变化 |
SRE 视角： 容量规划不是“买多少机器”，而是“在给定 SLO 下，用最少的资源跑最多的业务”。云原生时代，这一目标被进一步放大——资源可以秒级伸缩，但错误的规划会导致成本爆炸。
1.3 容量规划的核心原则
遵循以下四项原则，可以构建可落地、可持续的容量规划体系：
- 以业务驱动，而非以资源驱动
容量规划必须从业务指标（QPS、DAU、订单量、视频上传数）出发，反向推导基础设施需求。避免“先买机器再想用途”的粗放模式。 - 数据驱动，量化决策
所有规划必须基于历史监控数据、业务增长曲线、季节性规律，使用统计模型（如时间序列预测、线性回归）进行量化，而非凭经验“拍脑袋”。 - 预留缓冲，但控制浪费
为应对突发流量和故障转移，必须保留一定的冗余容量（Headroom）。云原生环境下，建议通过弹性伸缩动态调整缓冲，而非静态预留大量空闲资源。 - 持续迭代，闭环反馈
容量规划不是“做完一次就结束”。每次规划后，需要跟踪实际使用率与预测值的偏差，将偏差反馈回模型，持续优化预测精度。
1.4 为什么在云原生时代容量规划至关重要
云原生架构（容器、微服务、Kubernetes、Serverless）在带来弹性和敏捷性的同时，也引入了新的容量规划挑战，使得规划工作比传统时代更加关键：
| 传统架构 | 云原生架构 | 容量规划新挑战 |
|---|---|---|
| 物理机/VM 固定规格 | 容器/Pod 动态调度 | 资源碎片化、调度密度难以预测 |
| 扩容周期以天/周计 | 扩容周期以秒/分钟计 | 弹性策略不当导致“抖动”或成本飙升 |
| 单体应用，流量路径固定 | 微服务网状调用，链路复杂 | 瓶颈点漂移，容量模型需要覆盖全链路 |
| 资源成本相对固定 | 按量付费、竞价实例、预留实例混合 | 成本模型复杂，优化空间大但风险也大 |
| 容量规划由运维主导 | 开发+运维+财务（FinOps）协同 | 需要跨团队协作，规划结果直接影响业务成本 |
常见误区： 认为云原生“无限弹性”就不需要容量规划。实际上，弹性只解决“扩容速度”问题，不解决“该扩多少、何时扩、成本是否可控”的问题。没有规划的弹性，轻则浪费 30%-50% 的云支出，重则在流量高峰时因资源池枯竭导致全面故障。
1.5 容量规划在云原生环境中的核心流程
下图展示了云原生环境下容量规划的闭环流程，从业务指标采集到资源供给调整，形成持续反馈：
1.6 容量规划在 SRE 体系中的定位
在 Google SRE 经典模型中，容量规划是运维成熟度的关键衡量维度。它与以下 SRE 实践紧密关联：
- SLO 与错误预算： 容量不足直接导致 SLO 违约，消耗错误预算。容量规划是保护错误预算的第一道防线。
- 负载测试与压测： 容量规划需要压测数据来验证资源映射模型的准确性。
- 故障域隔离： 容量规划决定了每个故障域（可用区、集群、节点池）的资源水位，直接影响故障半径。
- Backstage 资源目录： 容量规划的结果需要被纳入 Backstage 的资源目录，作为服务所有者、运维团队和财务团队的统一数据源。
实践建议： 在 Backstage 中为每个服务定义
capacity.spec 字段，包含预期 QPS、资源配额、弹性策略和成本上限。将容量规划从“离线文档”转变为“在线可观测的配置”，实现规划即代码（Planning as Code）。