适用场景

容量规划最容易犯的错是「等报警再扩容」。正确做法是用最小成本算清三个数：当前单机能扛多少、业务每周涨多少、扩容需要提前多久。三个数齐了，扩容就是例行动作。

配置步骤（扩容触发线与台账）

# 触发线（按资源分级）
核心业务：CPU/内存/连接数 > 60% 预警、> 75% 申请扩容、> 85% 强制扩容
一般业务：> 70% 预警、> 85% 申请
内部系统：> 80% 预警

# 容量台账字段
系统 | 资源类型 | 当前规格 | 当前水位 | 单机能力 | 增长速率 | 下次扩容时间 | 提前期 | 负责人

# 扩容提前期（示例）
云主机：30 分钟    | 物理机采购：2-4 周
带宽扩容：1-3 天   | 数据库只读实例：半天

# 例行动作
- 每月 1 号更新水位与预测
- 达到 75% 自动创建扩容工单（自动化工单）

关键参数与建议

  • 单机能力：用压测标定（QPS、并发、时延拐点），不要用经验值
  • 增长模型：按周环比推月，大促与新业务上线显式纳入
  • 瓶颈顺序：CPU → 内存 → IO → 网络 → 连接数/队列，逐项验证
  • 扩容触发线：核心 60% 预警、75% 申请、85% 强制；非核心可放宽
  • 提前期：采购+上架+部署+数据同步的总时长要写进台账
  • 成本替代：索引优化、缓存、异步化往往比扩容便宜，优先评估
  • 压测纪律：压测环境与生产配置一致，压测数据隔离
  • 复盘：每次大促后更新单机能力与增长模型参数

容易踩的坑

  • 台账只在项目开始时建，之后从不更新
  • 触发线定得比业务要求低，天天扩容浪费钱
  • 触发线定得高，报警时已经没时间扩容
  • 提前期没算，云上能扩内网却不能扩
  • 扩容工单没有自动创建，靠人记
  • 台账与实际不一致，盘点时发现差好几台

验证与巡检

# 台账与触发检查
1) 台账更新时间是否在 1 个月内？
2) 达到触发线的资源是否有扩容工单？
3) 扩容提前期是否与供应商确认过？
4) 台账数量与监控实例数是否一致？
  • 巡检：台账月度更新、触发线自动工单、数量与监控一致、提前期已确认

小结

容量模型验收：业务量翻倍时能立刻回答「哪些资源要扩、扩到多少、多久到位、花多少钱」，四项都有数字。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。