结论先行：容量预测的价值不在于算出精确的峰值数字，而在于把"什么时候该扩容"从拍脑袋变成有据可依。可行做法是用可观测平台已沉淀的历史指标做趋势外推，叠加业务日历（促销、开盘、月末结算、季度跑批）做人工修正，提前数周给出扩容建议，并为关键接口设定容量水位红线。模型给出的是方向，业务日历给出的是确定性，两者缺一不可。
为什么固定阈值的容量告警总在出事之后才响
多数团队的容量管理停留在"资源告警"层面：CPU 超过某个比例、连接池占用超过某个数值就触发告警。这类告警有三个天然缺陷。
- 它是滞后指标。等到 CPU 打满，业务侧的响应时间早已经开始劣化，扩容动作落在用户投诉之后。
- 它不区分业务节奏。工作日与节假日、月初与月末、开盘与收盘的流量模型差别很大，用同一个阈值，闲时过于敏感、忙时又容易漏报。
- 它无法回答"还够用多久"。告警只能说明"现在已经紧张"，而采购与扩容需要的是"三周后会紧张"。
容量预测要解决的是第三点：把剩余可用时间算出来，给采购、扩容、压测留出窗口。
容量预测需要哪些数据底座
趋势外推并不神秘，前提是数据齐。下表列出四类必备输入与采集要点。
| 数据类型 | 在预测中的作用 | 采集要点 |
|---|---|---|
| 接口吞吐量与耗时分布 | 判断单服务的承载余量 | 至少保留一个完整业务周期（含月末、季末） |
| 资源水位（CPU／内存／连接池／线程池） | 把业务量换算成资源消耗 | 按实例采集，不要只看集群均值 |
| 中间件与数据库指标 | 定位真正的瓶颈环节 | 消息堆积、慢语句数、锁等待时长要单独成指标 |
| 业务量指标（订单数、活跃用户、交易笔数） | 建立业务量与资源量的换算关系 | 与技术指标对齐时间粒度 |
其中第二点最容易被忽略。集群均值会把少数几个高负载实例掩盖掉，而故障往往从单个实例开始。
四步建立可用的容量预测
- 定基线周期。先观察一个完整业务周期，把周期性波动（日间高峰、周末、月末结算、季度跑批）识别出来。只学三五天就下结论，会把低频但关键的峰值当成噪声。
- 建换算关系。用历史数据拟合"业务量 → 资源消耗"的斜率。有了这条斜率，就能把业务部门的增长预期（比如下季度订单量增长三成）直接换算成资源需求。
- 设水位红线。给每类资源设定两级水位：关注线（开始准备）与行动线（必须扩容）。红线应低于设备实际极限，留出突发缓冲。
- 定期复核。业务架构一变，斜率就失效。建议每季度复核一次换算关系与水位设置，跟随业务变化调整。
业务日历：预测模型补不上的那一环
纯数据驱动的模型有一个结构性盲区：它只能外推"过去发生过的规律"，无法预知"未来要发生的事"。一次营销活动、一个新网点开业、一次系统迁移，都不在历史数据里。
补法很朴素——维护一张业务日历，把已知的确定性事件提前登记：活动时间与预期流量倍数、新业务上线计划、批量作业排期、监管报送节点。预测模型给出趋势，业务日历给出阶跃，两者叠加才是可用的预测结果。
常见误区
- 只预测总量，不做分项。整站流量平稳不代表某个接口平稳，真正压垮系统的往往是局部热点。
- 把预测当成承诺。预测输出的是区间与概率，不是确定值。对外沟通时应给出区间，并说明前置假设。
- 预测做完就结束。没有配套的扩容流程与压测验证，预测结果只会躺在报告里。建议把预测结论直接接到扩容工单与压测计划上。
奇摩在服务金融与制造客户时，通常把容量预测与季度性能复核绑定在一起，让预测—扩容—验证形成固定节奏，而不是临时抱佛脚。
如果您正在规划相关建设，欢迎预约咨询，奇摩技术团队可基于现网数据做一轮评估，再决定是否推进。