容量工程

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

容量的第一性原理

什么是容量

容量不只是表面上的资源、 QPS、机器数量

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

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

负载超过能力则体验崩溃；能力固定而负载增长则体验劣化；提升能力或控制负载可改善体验。容量治理的本质是维持这三者的动态平衡。

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

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

容量工程的任务是在约束条件下做最优决策。

这三者覆盖了容量问题的三个核心视角：

视角关注点容量治理中的角色
体验用户/业务系统是否”快、稳、可用”
成本商业/财务资源有代价，不能无限堆砌
风险组织/运营故障率、安全边际要可控

三者的天然冲突构成容量治理的核心挑战：提升体验→成本上升；降低成本→风险上升。因此容量工程本质上是三者的动态平衡与权衡决策。

容量治理的整体架构模型

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

容量治理闭环

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

  1. **容量定义（目标层）**：业务目标与SLO、容量水位定义、成本与风险约束
  2. **容量观测（信号层）**：实时监控、趋势分析、容量预测
  3. **容量分析（决策层）**：瓶颈定位、决策模型、资源画像
  4. **容量处置（执行层）**：扩容与调度、限流与降级、结构性优化

还有一项容量演进能力贯穿全程：基线管理、回归验证、事故复盘。

四层的逻辑链：

容量定义（目标）    ↓  定义要达成的状态（SLO、水位、成本/风险边界）容量观测（信号）    ↓  采集实际状态的原始数据（QPS、RT、资源水位）容量分析（决策）    ↓  将信号转化为判断（瓶颈在哪、风险何时、该不该投入）容量处置（执行）    ↓  执行决策（扩容/限流/降级）    ↺  回到观测——执行后系统状态变化，重新进入观测

核心关系：

还有两条反馈：

这四层不是单向流程，而是目标驱动的采集链 + 执行后的验证反馈 + 多层修正的动态调优。后续章节逐一展开各层能力。

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

SLO 驱动的容量定义

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

容量水位的双重视角

业务水位高  →  该决策了（要扩容还是降级）业务水位低 + 资源水位高  →  预警但不紧急（瓶颈在积累，还没爆发）业务水位低 + 资源水位低  →  安全

业务容量水位

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

资源容量水位

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

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

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

容量观测的核心原则

用户感知优先，而非系统内部指标

信号应从用户视角定义。延迟、错误直接对应SLO边界，而非CPU、内存等内部资源——内部指标是手段，用户指标是目的。

饱和度监控需前置

饱和度监控要在达到硬限制前发出预警，留出缓冲时间。等系统"满了"再告警已经来不及处置。

错误分类细化

区分用户错误（4xx）、系统错误（5xx）、依赖故障（下游超时）。不是所有错误都等价——系统错误才是容量告警信号。

白盒 + 黑盒结合

白盒指标（系统内部状态）+ 黑盒指标（端到端用户体验）联合，才能完整判断瓶颈位置。

容量观测的三类信号

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

平台化容量观测

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

平台的价值在于：

容量分析：从信号到决策

容量分析的本质

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

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

这三个问题构成容量决策的最小完备集：先定位→再定时→再决策。缺失任一维度，决策都不完整。

容量分析的联合视图：

维度回答局限
当前水位现在是否告急等故障发生才知道
趋势分析方向是否正确不知道紧迫程度
预测模型什么时候可能爆发模型可能失效

只看水位→被动响应；只看趋势→知道方向但不知多紧急；只看预测→忽视黑天鹅事件。

决策模型分层

层级特征需要什么分析
自动决策规则驱动实时水位 + 规则匹配
半自动决策人工确认趋势预测 + 阈值比较
人工决策架构调整瓶颈定位 + 根因分析 + 成本评估

错误预算驱动分析优先级

容量分析应围绕错误预算动态调整重点：

容量处置：策略而非手段

容量处置的设计原则

常见处置策略分类

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

容量测试：建立系统基线

容量测试回答"系统能承载多少"，让所有容量决策有数据依据

为什么要基线

没有基线，就无法判断：

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

线上与线下容量测试

容量测试应被纳入 CI/CD，而不是一次性活动。——这次压了，下次代码改了就不知道容量是升是降

容量规划与预测

预测的定位

容量预测解决的是”方向对了没有”，而非”明天具体是多少”。

预测的价值在于提前发现方向性风险，为人工事先干预留出窗口。

核心原则：预测是分析层的输入，为决策提供时间维度的判断依据。

容量规划的矛盾本质

容量规划的核心矛盾是业务需求与资源供给的时间差：

维度业务技术
变化速度分钟级（流量峰值、营销活动）周/月级（采购、部署、调试）

业务可以瞬间爆发，资源就绪周期以周/月计——这个时间差是容量规划存在的根本原因。没有规划，只能永远被动响应。

规划的现实约束

规划必须在现实约束边界内做最优时间窗口决策：

约束类型影响
资金预算周期限制采购时机，过早采购资金占用，过晚采购错失窗口
地域跨地域扩容涉及网络延迟、法律合规、数据主权
灾备冗余边界决定故障时的容量兜底能力
硬件形态物理机 vs 云主机的交付周期差异显著

规划决策框架

容量规划是工程理性与商业理性的平衡：

业务增长预测    ↓资源约束边界（资金/地域/硬件/灾备）    ↓最优扩容时间窗口

核心原则：规划的本质是在约束条件下，找到资源就绪与业务需求之间的最优匹配点。

云时代的容量工程

弹性有边界

弹性解决了"能不能扩"，没解决"该不该扩、扩多少、向哪扩"。

滥用弹性反而增加成本与复杂度。弹性是处置手段之一，不是容量治理的全部。

成本模型转变

维度传统模式云模式
成本性质CAPEX（资本支出）OPEX（运营支出）
决策周期周/月级分钟级

云上容量规划必须把成本作为一等公民，而非事后核算。

架构演进改变容量边界

供应商锁定是容量风险

单云依赖受制于云厂商资源供给能力；多云增加管理复杂度但提升抗风险能力。

容量规划要把云厂商视为合作伙伴与利益博弈方，而非纯基础设施。

组织与治理

容量是业务责任

容量责任必须落在服务 owner 上，平台/SRE 提供工具链和方法论，不承担业务容量决策。

核心原则：容量是业务责任，不是运维责任。

组织设计的两条原则

两者不矛盾：能力集中保证专业性，意识下沉保证执行效率。

容量治理必须嵌入研发流程

容量问题往往发生在团队边界，缺乏强制性的容量评审环节。

必须嵌入的节点：架构评审（容量环节）、大促活动（提前X天）、新服务上线（容量基线）。

组织与系统的对齐

系统架构受制于组织沟通结构（Conway's Law）。

容量治理的组织设计要匹配系统架构：微服务架构需要去中心化的容量意识，集中式架构可以相对集中化容量管理。

容量信息的流通机制

容量信息必须在相关团队间流通，不能停留在运维团队内部。

核心原则：容量事故几乎从来不是”某个服务”的问题，而是组织协作的结果——复盘要从组织视角而非技术视角。

关联内容（自动生成）