适用场景

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

配置步骤（基线与触发线落地）

# 1) 采集六项基线（示例：单机）
vmstat 1 5
free -m
sar -d 1 3
df -h | grep -v tmpfs
ss -s

# 2) 关键指标公式
# CPU 水位 = (1 - idle) 取 5 分钟均值
# 内存水位 = (used - cache) / total
# 磁盘水位 = used / total（注意 inode）
df -i | grep -v tmpfs

# 3) 带宽与包量
# 交换机侧看端口利用率与峰值，服务器侧看 ethtool -S 丢包

# 4) 队列长度
# 数据库：等待事件；MQ：堆积数；Web：队列或连接池等待

关键参数与建议

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

容易踩的坑

  • 只看 CPU 不看内存与 IO，扩容后瓶颈转移
  • 平均值掩盖峰值，大促当晚被打满
  • 忽略 inode 水位，磁盘没满但无法创建文件
  • 未考虑连接数与队列，应用侧先崩
  • 采集口径各部门不一致，汇报数据互相矛盾
  • 台账不更新，扩容历史查不到

验证与巡检

# 月度复核清单
# 1) 六项指标 P95 与峰值
# 2) 与上月对比增长率
# 3) 达到触发线的资源清单
# 4) 扩容计划与预算
  • 巡检：月度报告、触发线告警生效、台账与实物一致、扩容记录可追溯

小结

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

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