在 体验、成本、风险 三者约束下，建立一种可演进、可治理、可自动化的系统容量能力。
容量不只是表面上的资源、 QPS、机器数量
容量 = 在既定用户体验目标与成本约束下，系统能够长期、稳定承载的业务负载上限。
容量由三类变量共同决定：
负载超过能力则体验崩溃；能力固定而负载增长则体验劣化；提升能力或控制负载可改善体验。容量治理的本质是维持这三者的动态平衡。
| 维度 | 目标 | 冲突点 |
|---|---|---|
| 业务 | 更高峰值 | 成本不可控 |
| 技术 | 更稳定系统 | 资源利用率下降 |
| 组织 | 更少事故 | 过度保守 |
容量工程的任务是在约束条件下做最优决策。
这三者覆盖了容量问题的三个核心视角：
| 视角 | 关注点 | 容量治理中的角色 |
|---|---|---|
| 体验 | 用户/业务 | 系统是否”快、稳、可用” |
| 成本 | 商业/财务 | 资源有代价，不能无限堆砌 |
| 风险 | 组织/运营 | 故障率、安全边际要可控 |
三者的天然冲突构成容量治理的核心挑战：提升体验→成本上升；降低成本→风险上升。因此容量工程本质上是三者的动态平衡与权衡决策。
容量治理不是单点能力，而是一个 长期运行的系统工程闭环。
容量治理可以抽象为四个层次：
还有一项容量演进能力贯穿全程：基线管理、回归验证、事故复盘。
四层的逻辑链：
容量定义（目标）
↓ 定义要达成的状态（SLO、水位、成本/风险边界）
容量观测（信号）
↓ 采集实际状态的原始数据（QPS、RT、资源水位）
容量分析（决策）
↓ 将信号转化为判断（瓶颈在哪、风险何时、该不该投入）
容量处置（执行）
↓ 执行决策（扩容/限流/降级）
↺ 回到观测——执行后系统状态变化，重新进入观测
核心关系：
还有两条反馈：
这四层不是单向流程，而是目标驱动的采集链 + 执行后的验证反馈 + 多层修正的动态调优。后续章节逐一展开各层能力。
容量必须由体验目标反向约束：
业务水位高 → 该决策了（要扩容还是降级）
业务水位低 + 资源水位高 → 预警但不紧急（瓶颈在积累，还没爆发）
业务水位低 + 资源水位低 → 安全
业务容量水位 = 当前业务负载 / 业务可承载上限
资源容量水位 = 当前资源消耗 / 可用资源总量
业务水位是目标，资源水位是信号。
用户感知优先，而非系统内部指标
信号应从用户视角定义。延迟、错误直接对应SLO边界，而非CPU、内存等内部资源——内部指标是手段，用户指标是目的。
饱和度监控需前置
饱和度监控要在达到硬限制前发出预警，留出缓冲时间。等系统"满了"再告警已经来不及处置。
错误分类细化
区分用户错误（4xx）、系统错误（5xx）、依赖故障（下游超时）。不是所有错误都等价——系统错误才是容量告警信号。
白盒 + 黑盒结合
白盒指标（系统内部状态）+ 黑盒指标（端到端用户体验）联合，才能完整判断瓶颈位置。
| 信号类型 | 作用 | 示例 |
|---|---|---|
| 实时信号 | 事故预警 | 当前 QPS、RT |
| 趋势信号 | 风险识别 | 周期性增长 |
| 预测信号 | 决策支持 | 峰值预估 |
容量观测应通过平台能力沉淀：
平台的价值在于：
容量分析不是”算还能撑多久”，而是回答三个问题：
这三个问题构成容量决策的最小完备集：先定位→再定时→再决策。缺失任一维度，决策都不完整。
容量分析的联合视图：
| 维度 | 回答 | 局限 |
|---|---|---|
| 当前水位 | 现在是否告急 | 等故障发生才知道 |
| 趋势分析 | 方向是否正确 | 不知道紧迫程度 |
| 预测模型 | 什么时候可能爆发 | 模型可能失效 |
只看水位→被动响应；只看趋势→知道方向但不知多紧急；只看预测→忽视黑天鹅事件。
| 层级 | 特征 | 需要什么分析 |
|---|---|---|
| 自动决策 | 规则驱动 | 实时水位 + 规则匹配 |
| 半自动决策 | 人工确认 | 趋势预测 + 阈值比较 |
| 人工决策 | 架构调整 | 瓶颈定位 + 根因分析 + 成本评估 |
容量分析应围绕错误预算动态调整重点：
| 类型 | 目标 | 示例 |
|---|---|---|
| 扩容 | 提升上限 | 弹性扩容 |
| 调度 | 提高利用率 | 混部 |
| 限流 | 保护核心 | 丢弃非关键请求 |
| 降级 | 保住主功能 | 功能裁剪 |
容量测试回答"系统能承载多少"，让所有容量决策有数据依据
没有基线，就无法判断：
基线是容量工程的“参照系”。
容量测试应被纳入 CI/CD，而不是一次性活动。——这次压了，下次代码改了就不知道容量是升是降
容量预测解决的是”方向对了没有”，而非”明天具体是多少”。
预测的价值在于提前发现方向性风险，为人工事先干预留出窗口。
核心原则：预测是分析层的输入，为决策提供时间维度的判断依据。
容量规划的核心矛盾是业务需求与资源供给的时间差：
| 维度 | 业务 | 技术 |
|---|---|---|
| 变化速度 | 分钟级（流量峰值、营销活动） | 周/月级（采购、部署、调试） |
业务可以瞬间爆发，资源就绪周期以周/月计——这个时间差是容量规划存在的根本原因。没有规划，只能永远被动响应。
规划必须在现实约束边界内做最优时间窗口决策：
| 约束类型 | 影响 |
|---|---|
| 资金 | 预算周期限制采购时机，过早采购资金占用，过晚采购错失窗口 |
| 地域 | 跨地域扩容涉及网络延迟、法律合规、数据主权 |
| 灾备 | 冗余边界决定故障时的容量兜底能力 |
| 硬件形态 | 物理机 vs 云主机的交付周期差异显著 |
容量规划是工程理性与商业理性的平衡：
业务增长预测
↓
资源约束边界（资金/地域/硬件/灾备）
↓
最优扩容时间窗口
核心原则：规划的本质是在约束条件下，找到资源就绪与业务需求之间的最优匹配点。
弹性解决了"能不能扩"，没解决"该不该扩、扩多少、向哪扩"。
滥用弹性反而增加成本与复杂度。弹性是处置手段之一，不是容量治理的全部。
| 维度 | 传统模式 | 云模式 |
|---|---|---|
| 成本性质 | CAPEX（资本支出） | OPEX（运营支出） |
| 决策周期 | 周/月级 | 分钟级 |
云上容量规划必须把成本作为一等公民，而非事后核算。
单云依赖受制于云厂商资源供给能力；多云增加管理复杂度但提升抗风险能力。
容量规划要把云厂商视为合作伙伴与利益博弈方，而非纯基础设施。
容量责任必须落在服务 owner 上，平台/SRE 提供工具链和方法论，不承担业务容量决策。
核心原则：容量是业务责任，不是运维责任。
两者不矛盾：能力集中保证专业性，意识下沉保证执行效率。
容量问题往往发生在团队边界，缺乏强制性的容量评审环节。
必须嵌入的节点：架构评审（容量环节）、大促活动（提前X天）、新服务上线（容量基线）。
系统架构受制于组织沟通结构（Conway's Law）。
容量治理的组织设计要匹配系统架构：微服务架构需要去中心化的容量意识，集中式架构可以相对集中化容量管理。
容量信息必须在相关团队间流通，不能停留在运维团队内部。
核心原则：容量事故几乎从来不是”某个服务”的问题，而是组织协作的结果——复盘要从组织视角而非技术视角。