容量工程

在 体验、成本、风险 三者约束下，建立一种可演进、可治理、可自动化的系统容量能力。

一、容量的第一性原理

1.1 什么是容量

容量不是资源，不是 QPS，也不是机器数量。

容量 = 在既定用户体验目标与成本约束下，系统能够长期、稳定承载的业务负载上限。

容量由三类变量共同决定：

容量问题的本质，是这三者之间的 动态平衡问题。

1.2 容量工程要解决的核心矛盾

维度目标冲突点
业务更高峰值成本不可控
技术更稳定系统资源利用率下降
组织更少事故过度保守

容量工程的任务不是“无限扩容”，而是 在约束条件下做最优决策。

二、容量治理的整体架构模型

容量治理不是单点能力，而是一个 长期运行的系统工程闭环。

2.1 容量治理闭环

容量治理可以抽象为四个层次：

  1. **容量定义（目标层）**
  2. **容量观测（信号层）**
  3. **容量分析（决策层）**
  4. **容量处置（执行层）**

这四层形成一个持续演进的治理闭环。

2.2 容量治理能力树

容量治理能力├─ 容量定义能力│  ├─ 业务目标与 SLO│  ├─ 容量水位定义│  └─ 成本与风险约束├─ 容量观测能力│  ├─ 实时监控│  ├─ 趋势分析│  └─ 容量预测├─ 容量分析能力│  ├─ 瓶颈定位│  ├─ 决策模型│  └─ 资源画像├─ 容量处置能力│  ├─ 扩容与调度│  ├─ 限流与降级│  └─ 结构性优化└─ 容量演进能力   ├─ 基线管理   ├─ 回归验证   └─ 事故复盘

三、容量定义：目标与水位模型

3.1 容量水位的双重视角

业务容量水位

业务容量水位 = 当前业务负载 / 业务可承载上限

资源容量水位

资源容量水位 = 当前资源消耗 / 可用资源总量

业务水位是目标，资源水位是信号。

3.2 SLO 驱动的容量定义

容量必须由体验目标反向约束：

四、容量观测：信号体系与平台化

4.1 容量观测的三类信号

信号类型作用示例
实时信号事故预警当前 QPS、RT
趋势信号风险识别周期性增长
预测信号决策支持峰值预估

4.2 平台化容量观测

容量观测应通过平台能力沉淀：

平台的价值在于：减少个体经验依赖。

五、容量分析：从信号到决策

5.1 容量分析的本质

容量分析不是“算还能撑多久”，而是回答三个问题：

  1. 瓶颈在哪里
  2. 风险什么时候发生
  3. 现在该不该投入成本

5.2 决策模型分层

层级特征示例
自动决策规则驱动HPA、限流
半自动决策人工确认预测扩容
人工决策架构调整拆分、重构

数学模型（如 ARIMA）的角色是 决策支持，而非决策本身。

六、容量处置：策略而非手段

6.1 容量处置的设计原则

6.2 常见处置策略分类

类型目标示例
扩容提升上限弹性扩容
调度提高利用率混部
限流保护核心丢弃非关键请求
降级保住主功能功能裁剪

七、容量测试：建立系统基线

7.1 为什么要基线

没有基线，就无法判断：

基线是容量工程的“参照系”。

7.2 线上与线下容量测试

容量测试应被纳入 CI/CD，而不是一次性活动。

八、容量规划与预测

8.1 预测的定位

预测不是为了“算准未来”，而是：

尽早发现方向性风险

时间序列模型适合趋势判断，不适合孤立决策。

8.2 容量规划的现实约束

容量规划始终是 工程理性与商业理性的平衡。

九、云时代的容量工程

9.1 弹性不是万能药

前进方向：

十、组织与治理

10.1 组织设计原则

容量事故几乎从来不是“某个服务”的问题，而是 组织协作的结果。

十一、小规模系统的容量策略

容量工程不是规模专属，而是一种 工程思维方式。

关联内容（自动生成）