适用场景

容量规划的核心是提前量。等业务报警才扩容，等于把可用性交给运气。正确做法是把每类资源的基线、增长速率、扩容触发线写清楚，按月复核，扩容变成例行工作。

配置步骤（扩容方案与窗口管理）

# 1) 扩容类型
# 纵向：加 CPU / 内存（需重启，窗口长）
# 横向：加节点（需应用支持无状态）
# 分流：读写分离 / 缓存 / CDN（成本低）

# 2) 扩容窗口：数据库从库先扩，验证后再切主
# 3) 扩容前必做
#   - 备份 + 快照
#   - 版本与配置一致性核对
#   - 回退步骤写好

# 4) 扩容后验证
#   - 基线复测
#   - 数据一致性校验
#   - 监控告警收敛确认

关键参数与建议

  • 资源分级：核心业务、一般业务、内部系统分级定不同水位标准
  • 基线口径：CPU/内存/磁盘/带宽/连接数/队列长度六项，统一采集口径
  • 增长预测：按周环比推月，业务有大促或上线计划要显式纳入
  • 触发线：核心业务 60% 预警、75% 扩容申请、85% 强制扩容
  • 扩容提前期：从申请到可用要算清采购、上架、系统安装、数据同步时间
  • 容量台账：每个系统的规格、当前水位、下次扩容时间窗口都要有记录
  • 成本平衡：扩容不是唯一解，索引优化、缓存、异步化往往更便宜

容易踩的坑

  • 扩容没做备份，回退时无从下手
  • 只扩了应用没扩数据库，瓶颈仍在
  • 新节点配置与老节点不一致，行为差异引发故障
  • 扩容窗口安排在业务高峰，影响用户
  • 扩容后未复测，不知道是否真的解决
  • 忘记更新台账与监控阈值，下次判断继续出错

验证与巡检

# 扩容前后对比
# 记录：TPS、P95 响应、CPU/内存水位、连接数

# 一致性校验
# 行数与关键汇总对比，与迁移校验同一套脚本
  • 巡检：扩容有单据、前后数据齐全、台账已更新、回退方案已归档

小结

容量规划检验：业务翻倍时，能立刻说清哪些资源要扩、扩到什么规格、需要多久到位。答不上来就是没做规划。

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