容量治理全景图

回答“系统增长、峰值、成本和稳定性怎样一起管理，而不是等到大促或事故当天才扩容”

阅读边界: 容量治理不是简单加机器，也不是压测报告归档。它要把业务预测、容量模型、瓶颈识别、弹性策略、峰值预案、成本约束和降级策略接成持续治理。

一句话判断: 如果容量只在上线前或事故后才被讨论，团队掌握的是临时扩容能力，不是容量治理能力。

一、它真正解决什么问题

预测业务量建立容量模型压测瓶颈设置水位弹性与降级复盘成本

二、关键机制

容量模型

把 QPS、并发、数据量、队列积压、存储增长、第三方限额和成本模型放在一起。

水位管理

定义安全水位、预警水位、扩容水位和降级水位，让容量动作有触发条件。

压测与基准

持续保留基准性能和瓶颈曲线，避免每次活动前重新猜系统极限。

弹性策略

区分水平扩容、垂直扩容、预热、排队、缓存、限流和削峰填谷。

容量预案

活动、迁移、发布和突发流量都要有预案、值守和回收计划。

成本归因

容量不是越多越安全，必须追踪业务量、资源量和单位成本之间的关系。

三、水位触发动作表

水位	典型信号	治理动作
安全水位	峰值负载、队列积压、数据库连接、第三方限额都低于预警线。	维持常规监控，定期复核增长趋势和单位成本，不急着扩容。
预警水位	关键资源接近阈值，峰值时延或错误率开始抬头。	启动容量评审，确认瓶颈资源、扩容 lead time、压测可信度和降级预案。
扩容水位	预测增长或活动峰值会触碰瓶颈，当前余量不足以覆盖风险窗口。	执行扩容、预热、缓存、分片、队列或第三方额度申请，并明确回收计划。
降级水位	扩容已经来不及或瓶颈不可横向扩展，用户体验即将明显受损。	启用限流、排队、只读、关闭非核心能力、削峰填谷和业务告知。
事故水位	容量瓶颈已经导致错误率、超时、积压或数据延迟失控。	进入事故指挥，优先止血和保护核心链路，事后回补容量模型和压测基线。

四、压测可信度怎么判断

校准项	低可信表现	高可信要求
流量模型	只压单接口平均 QPS，没有真实用户路径、突刺、读写比例和地域分布。	按关键业务旅程组织流量，覆盖峰值、突刺、长尾请求和热点对象。
数据规模	测试库数据量小、索引新、缓存热度和生产完全不同。	使用接近生产的数据量、分布、冷热比例和历史脏数据形态。
依赖行为	第三方、数据库、消息队列、缓存和下游服务用 mock 简化掉。	明确哪些依赖真实参与，哪些被模拟，并说明模拟误差。
观测指标	只看吞吐和平均延迟，看不到错误、排队、重试、资源瓶颈和用户成功率。	同时看端到端成功率、P95/P99、瓶颈资源、水位变化和业务结果。
复用能力	每次活动前重新压一遍，历史结果不能比较。	保留基准曲线、瓶颈拐点、配置版本和生产差异，形成可复用容量档案。

五、常见误区

六、上线 / 治理检查项

检查项	最低要求
容量基线	关键链路有当前峰值、极限、瓶颈和安全水位记录
增长预测	业务增长、活动峰值、数据增长和第三方限额被纳入模型
压测可信度	压测数据、流量分布、依赖模拟和生产差异被说明
弹性动作	扩容、预热、限流、排队、降级和回收都有负责人和触发条件
成本复盘	活动或扩容后复盘资源利用率、浪费、瓶颈和下一次模型修正

七、容量登记卡与耗尽动作记录

登记字段	要写清楚什么	缺失后的后果
业务旅程	对应用户路径、业务峰值、服务 owner、业务 owner、关键依赖和服务等级	容量按单服务估算，无法解释用户路径为什么仍然慢
容量基线	当前峰值、极限吞吐、P95/P99、瓶颈资源、安全水位和压测日期	每次活动前重新猜极限，历史压测无法比较
增长预测	业务增长、活动峰值、数据量增长、地域 / 租户分布和第三方额度	只按历史均值准备容量，无法覆盖突刺和热点
弹性动作	扩容、预热、缓存、排队、限流、降级、只读和回收动作的触发条件	水位上升后只能人工临场判断，动作慢且不可复盘
成本与回收	预留成本、弹性成本、单位成本、保留理由、回收时间和成本 owner	容量扩上去以后没人回收，稳定性余量和浪费混在一起

耗尽动作记录	最小内容	验收问题
触发信号	触发时间、水位、指标、用户影响、瓶颈资源和是否进入事故响应	这次容量风险是预测发现、告警发现，还是用户先发现？
已执行动作	扩容、限流、降级、排队、缓存预热、第三方额度申请和业务告知记录	哪些动作真的降低了水位，哪些只是增加成本？
未执行动作	未做的扩容、拆分、降级或回收动作，以及未执行原因	是技术不可行、审批太慢、成本不允许，还是预案缺失？
恢复与回收	恢复时间、指标回落、资源回收、降级关闭、告警恢复和成本影响	风险解除后是否把系统带回正常状态，而不是留下临时配置？
模型修正	预测偏差、瓶颈误判、压测差异、下次阈值和新增治理任务	下一次容量评估是否会比这次更准？

八、典型生产场景与最小落地包

场景	最小落地包	验收信号
活动峰值前评估	列出关键旅程、峰值预测、瓶颈资源、第三方限额、预热动作、降级开关和值守负责人	活动前能说清系统极限、当前水位、扩容动作和失败退路
扩容后仍然慢	用端到端指标定位数据库、锁、队列、缓存、网络或外部依赖瓶颈，不只追加计算资源	瓶颈资源明确，扩容动作能带来可观测的吞吐或延迟改善
资源长期闲置	建立业务量、资源量、利用率和单位成本看板；给峰值预留、弹性回收和固定冗余分账	稳定性余量可解释，低利用资源有保留理由或回收计划

九、和现有图谱怎么互链

相关页	连接关系
可靠性治理	容量水位、错误预算和降级策略共同决定系统能否稳定承压
可观测性 / SRE	容量治理依赖指标、趋势、瓶颈和事件时间线
FinOps / 成本工程	容量治理需要把稳定性余量和单位成本放在同一张账里
容灾 / 高可用	容灾切换和故障演练会改变容量需求，必须提前验证
缓存工程	缓存、预热和热点治理常常是容量瓶颈的第一道缓冲层