阿里云预测没有单独的产品入口，它分布在多个产品里，是一组时间序列预测能力。它读取过去一段时间的指标，比如每分钟的请求量、每天的订单数、每小时的CPU使用率，然后给出未来一段时间的预测值。结果通常还带有置信区间，告诉你实际数值可能会在哪个范围内波动。
使用方式大致有两条路。一条是直接用产品自带的功能，例如云服务器弹性伸缩里的预测式伸缩策略。配好之后，计算和扩缩容由系统自动完成。另一条是借助机器学习平台PAI，自己训练和部署模型。这条路适合业务规则特殊、需要自定义特征的场景，但前期投入也更大。
三类常见用法
一、弹性伸缩
这是最直接的用法。系统根据历史负载规律，预测下一时段的访问量，提前把实例加上去。阈值伸缩要等CPU涨上来才动，而预测式伸缩能提前一步。实例启动本身需要几分钟，如果等指标已经飙高再扩容，用户早就感觉到卡顿了。
二、销量与库存规划
零售和电商企业经常用预测结果指导备货。模型可以把节假日、促销活动和季节因素考虑进去，输出分商品、分仓库的需求量，采购部门据此决定补多少、什么时候补。
三、业务指标预警
预测结果还能用来做异常检测。实际指标一旦明显偏离预测区间，就发出告警。比如支付成功率在凌晨突然跌破预测下限，多半是某个支付渠道出了问题，值班同学能更早介入，不用等客服接到投诉才发现。
案例一：电商大促前的服务器扩容
这是一个示例场景，具体数字要以你自己的项目为准。某服装电商每年有几次大促。以前运维人员凭去年的经验手动扩容，结果有两次下单接口超时，还有一次资源闲置了三天以上，成本偏高。
团队分三步处理。第一步，整理过去两年的访问日志，按分钟汇总请求量，并把大促、节假日和营销活动的时间标注出来。第二步，在弹性伸缩里开启预测式策略，预测窗口设为未来一小时，目标CPU利用率控制在60%左右，给突发流量留出缓冲。第三步，大促前一周每天对比预测值和实际值。团队发现首日晚间的预测偏低，于是调高了促销启动时间的权重，重新训练了模型。
大促当天，实例数在晚八点前已经扩充到位，下单接口的超时率降到接近零。活动结束后，系统按负载自动缩容，闲置时间明显变短。对这个团队来说，预测最有用的地方是提前量，单个数字准不准反而没那么关键。
案例二：连锁门店的补货
另一个示例来自一家约200家门店的便利连锁。门店常见的问题有两个：热销饮品断货，或者临期食品积压。采购员每天凭感觉下单，问题一直压不下去。
团队用PAI搭建了销量预测流程，输入数据包括门店每日销量、天气、周边活动和节假日标记。模型按门店和品类分别预测未来七天的销量，并给出上下限。采购系统以预测中位数作为基础订单量，只有实际库存低于下限时才触发紧急补货。
运行三个月后，热销品的缺货天数少了一半左右，临期损耗也有所下降。新开的门店历史数据不够，团队先用同类门店的平均曲线过渡，积累满四周数据后再切换到门店自己的模型。这一点很容易被忽略，新店直接套用成熟门店的模型，结果通常偏差很大。
选型与使用步骤
- 先定目标。写清楚要预测什么指标、预测多长时间、结果用来做什么决策。目标不清楚，后面连模型好不好都没法判断。
- 检查数据。时间序列要求时间戳连续、单位统一。缺失的数据要补齐或说明处理方式，异常峰值要先确认是真实业务还是采集出错。
- 选产品路径。常规伸缩需求优先用内置预测策略，维护成本低。只有业务规则复杂、内置功能覆盖不了时，再考虑在PAI里自建模型。
- 设置基线。拿“上周同一时段”或简单移动平均当参照，确认预测模型确实比它准，再投入使用。
- 定期回测。每周或每次活动结束后，对比预测和实际。偏差连续扩大时就重训，不要等到出事故再看。
常见误区
- 把预测当承诺。预测给出的是概率范围。资源和库存成本较高时，决策要留出余量，不能只按中位数硬卡。
- 数据越多越好。很久以前的数据可能已经不能反映当前的业务模式。业务变过的话，要截断老数据或者降低它的权重。
- 忽略外部因素。促销、天气、竞品动作都会影响结果。只盯着历史曲线，关键时刻很容易失准。
- 不做效果评估。没有对比数据，就分不清预测到底带来了收益，还是只是碰巧没出问题。
小结
阿里云预测比较适合有稳定历史数据、而且预测结果能直接影响决策的场景。从弹性伸缩到库存规划，关键步骤其实是一样的：定目标、理数据、设基线、持续回测。建议先在一个指标、一个环节上试点，跑顺了再逐步扩大范围。
