容量规划的核心不是“还剩多少”，而是“还能撑多久”

很多团队判断是否扩容，依赖监控面板上的即时水位：CPU 高了就加机器，磁盘满了就扩存储。这种方式在业务平稳时问题不大，一旦业务进入增长期，往往会陷入被动——采购、上架、系统部署、压测验收都需要时间，而资源瓶颈不会等流程走完才出现。

更稳妥的做法，是把容量规划从“事后响应”前移为“事前预判”：以业务增速为输入，推算未来半年到一年内资源耗尽的时间点，再倒推出必须启动扩容的节点。本文给出的是一套可落地的分析框架，不涉及具体产品或报价，重点在方法与步骤。

第一步：建立可信的容量基线

预判的前提是数据可靠。建议先固定一套采集口径，避免每次复盘都换指标。

• 资源侧：CPU 使用率（区分平均与峰值）、内存使用率、磁盘容量与 IOPS、内网与公网带宽、连接数、句柄数等。
• 业务侧：日活、订单量、接口调用量、消息量、单次请求数据体积等可直接对应资源消耗的指标。
• 时间维度：至少保留近 6～12 个月的按天数据，并标注大促、活动、版本发布等异常点。

关键是要区分日常水位与峰值水位。峰值决定系统能否扛住，日常水位决定长期成本，两者在容量模型里承担不同角色，不能混为一谈。

第二步：判断业务增速属于哪种形态

“按固定百分比增长”只在少数场景成立。先给业务增速归类，再选预测方法，误差会小很多。

• 线性增长：用户与流量平稳上升，适合用近期日增量的中位数外推。
• 阶梯式增长：由新业务上线、新渠道接入、大客户签约驱动，资源需求会在某个时间点跳变，需要结合业务排期表而非历史曲线。
• 季节性波动：有明显的周内与年内周期，应基于同比而非环比判断趋势，避免把淡季低点当成长期基线。
• 突发性热点：难以预测但影响巨大，通常靠弹性资源与限流降级兜底，不纳入长期容量基线，但要单独评估其上限。

第三步：把业务指标翻译成资源指标

容量规划最容易出错的地方，是拿业务增长率直接乘机器数量。正确的做法是先找到单位业务量对应的资源消耗，再叠加增长。

• 计算资源：以高峰时段的请求量或任务量对应 CPU 消耗，注意区分计算密集与 IO 密集型服务。
• 内存资源：关注常驻内存随连接数、缓存规模的变化，留意内存泄漏带来的缓慢爬升。
• 存储资源：按“日增数据量 × 保留周期”估算，同时考虑副本、备份、日志与索引膨胀。
• 网络资源：带宽需求与响应体大小、调用链路长度强相关，跨可用区或跨地域调用要额外计入。

如果某个服务的历史数据不足，可以用压测结果作为补充输入，但要注明压测环境与生产环境的差异，避免直接照搬。

第四步：推算扩容时间窗口

当基线与增速都明确后，可以用一个简单流程倒推出动作节点：

1. 确定各类资源当前的实际可用余量（总容量减去安全水位后的部分）。
2. 按业务增速换算成资源消耗速度，得到“预计可用天数”。
3. 从可用天数中扣除交付周期：需求评审、预算审批、采购到货、机房上架、系统初始化、数据同步、压测与灰度上线。
4. 剩余时间即为最晚启动时间。若该时间已经临近或为负，说明需要立即处理，或先用弹性资源、优化手段过渡。

实践中建议对半年与一年分别做一次推演：半年期的预测用于指导具体扩容动作，一年期的预测用于预算沟通与架构改造决策。两者口径应保持一致，只在假设条件上有所不同。

第五步：把一次性预测变成常态机制

预测会失准，机制比单次结论更重要。

• 月度复盘：比对预测值与实际值，记录偏差原因，逐步修正增长假设。
• 季度滚动：每季度重做一次半年与一年的推演，让扩容节点始终滚动可见。
• 设置分级预警：把资源水位分为观察、关注、行动三档，明确每档对应的责任人与动作。
• 预留缓冲：在架构层面保留一定的冗余与弹性能力，为预测误差留出空间。
• 同步业务排期：把容量评估纳入新业务上线流程，避免出现“业务先上、资源后补”。

常见误区

• 只看平均值：平均值掩盖峰值，峰值才决定是否过载。
• 用机器数代替资源量：不同规格、不同负载类型的机器不可直接换算。
• 忽略交付周期：预测出耗尽时间却来不及交付，等于没有预测。
• 过度依赖单一增长曲线：业务形态变化时，历史趋势会迅速失效。
• 只扩不优：在扩容决策前，应先确认是否存在可优化的资源浪费与低效调用。

落地检查清单

• 是否建立了统一口径的资源与业务指标基线？
• 是否区分了日常水位与峰值水位？
• 是否明确了业务增速的形态与假设条件？
• 是否完成了业务指标到资源指标的换算？
• 是否推算出半年与一年的扩容节点，并倒推出最晚启动时间？
• 是否把容量评估接入了业务上线流程与定期复盘机制？

容量规划的价值，不在于把未来算得分毫不差，而在于让团队在资源耗尽之前就拥有选择权：是提前扩容、是优化架构，还是调整业务节奏。基于业务增速预判半年到一年的扩容节点，正是把这种选择权握在手里的开始。