容量规划与余量工作流

测算各资源当前利用率，从业务信号外推需求增长，并按已定义的故障模式配置余量。

目标

月度平均值会奉承基础设施：高峰小时消耗容量，营销活动消耗余量，事故消耗周末。从真实峰值与业务信号出发规划，让余量按具名的故障模式定价，供给才能走在需求前面而不是被事故追着跑。

步骤要点

在真实峰值测利用率：采集各资源在实际高峰窗口的利用率而非月均，容量被峰值吃掉、被平均掩盖。
识别约束资源：确定增长下最先饱和的是 CPU、内存、连接池还是外部配额，它决定扩容策略。
从业务信号外推需求：用产品信号（活动日历、用户增长、季节峰值）做预测，而非对上季度的线性外推。
按故障模式定余量：为余量要吸收的具体故障定价——峰值丢节点、流量倍增、切换集中，而不是笼统的 2 倍。
定期加触发器复审：季度复审，另设触发器（新大客户、产品发布、利用率过 60%）即时重置计划。

排错提示

CPU 加了节点饱和依旧，多半约束在连接池或配额，先找最先饱和的资源再花钱；余量数字说不出对应哪种故障就是拍脑袋，N+1、1.8 倍、切换集中各自对应不同的余量；计划一年没更新是没设触发器，利用率先过 60% 就该重跑预测。

适用边界

预测依赖业务输入的准确性，未告知的营销活动会击穿任何余量模型；弹性伸缩可替代部分静态余量，但切换类故障仍需结构性容量。

代码示例

peak utilization (Tue 19:00-20:00, observed):
  api CPU            61%
  api mem            44%
  db connections     71%  pool 400/560   <- BINDING
  cache memory       38%

demand forecast (business signals):
  holiday campaign (Nov 15): +80% traffic, 14 days
  user growth: +9%/qtr
  new enterprise tenant (Q1): +12% steady

headroom sizing (failure-mode justified):
  node loss at peak:  N+1 within 30% of current
  campaign spike:      1.8x peak traffic
  -> provision: db pool 560 -> 900, api nodes 8 -> 13
review: quarterly + triggers (util>60%, launch, tenant)