容量规划核心是建立业务行为与资源消耗的真实映射关系：先用arima做基线预测，再叠加主播开播数等业务因子修正；需实测拟合资源消耗经验公式，识别线性/s型/阶梯增长拐点并差异化扩容；通过偏差归因与模型重训构建动态反馈闭环。

容量规划的底层算法模型和业务增长预测，核心在于把“人怎么用系统”转化成“机器怎么算资源”。不是堆指标，而是建关系——业务行为与资源消耗之间的真实映射关系。

时间序列模型是预测的起点，但不能只靠它

ARIMA、指数平滑等传统时间序列方法适合有稳定周期规律的场景，比如电商日常访问、支付系统日结流量。它们能拟合历史趋势，但对突发性增长（如新功能上线、营销活动引爆）响应滞后。实际中建议：先用ARIMA做基线预测，再叠加业务驱动因子做修正。例如，某直播平台在预测QPS时，会把“主播开播数×平均观众停留时长×互动频次”作为外生变量输入模型，而不是单纯看过去7天的QPS曲线。

• 单靠历史数据预测，容易低估结构性增长
• 加入业务动作（上线、促销、渠道投放）作为解释变量，提升预测置信度
• 模型输出需带区间估计（如80%概率落在X±15%），而非单一数值

资源消耗建模比流量预测更关键

很多团队卡在“预测了QPS，却配不出服务器”，问题出在没建立资源消耗模型。比如一个API调用，它消耗多少CPU、内存、数据库连接、网络带宽，取决于请求体大小、SQL复杂度、缓存命中率等十几个变量。真实做法是：对核心链路做分层压测，采集不同负载下的资源消耗曲线，再拟合出经验公式。例如：

• 数据库写入QPS每增加1000，磁盘IOPS上升约2400，CPU使用率上升3.2%
• 缓存未命中率每升高1%，后端服务P99延迟跳升17ms
• 消息队列积压每增加10万条，消费者内存占用增长约1.8GB

这些系数必须来自本系统实测，不能套用文档或别家经验。

业务增长不是线性外推，要识别拐点类型

用户量或订单量的增长曲线，本质反映业务阶段。初期常为线性（地推拉新），中期转向S型（市场渗透），成熟期可能呈阶梯式（依赖大客户签约或政策驱动）。不同形态对应不同容量策略：

• 线性增长：按月增速预留2–3倍冗余，重点保障水平扩展能力（如无状态服务、分库分表路由可配）
• S型增长：关注拐点前3个月，提前扩容基础设施，避免临界点性能坍塌
• 阶梯增长：把每个阶梯视为独立容量事件，单独做预案（如签约某车企后，预估新增10万车联网设备上报）

动态反馈闭环让模型持续有效

上线后的监控数据必须反哺预测模型。不是“预测→部署→不管”，而是“预测→部署→采集误差→归因分析→更新模型参数”。例如，某风控服务上线后发现CPU实际消耗比预测高40%，追查发现是新规则引擎引入了更多正则匹配，于是将“规则复杂度得分”加入资源消耗模型。这种闭环迭代，比初始模型精度更重要。

• 每周对比预测值与实际资源使用率偏差 >15% 的模块
• 对偏差大的场景做根因分析，更新特征或系数
• 每季度重训一次核心预测模型，保留至少3个版本用于A/B对比