在饱和之前规划容量,而不是之后
按月增长是可以预测的——只要你在测。AI 容量规划把流量趋势转化为在用户感到卡顿前几周就落定的采购决策。
每一家快速成长的 FTTH ISP 都认得那个瞬间。上季度还是舒服上扬曲线的流量图,开始在天花板附近变平。等客户投诉来的时候,饱和已经存在三周了。升级的采购周期是六周。数学是无情的。
容量规划就是早买
当运营商说他们想要「AI 容量规划」时,他们真正想要的是把一个缓慢的技术信号——骨干接口利用率悄悄爬到 70% 以上——转换成一个快速的业务信号——「Q3 第 6 周之前采购 10 Gbps 上行」。真正难的不是流量预测,那已经研究得很透了。真正难的是在用户注意到之前,闭合预测到采购的环路。
一个简单可辩护的模型
你不需要深度神经网络来预测采购关心时间尺度上的带宽。一个季节性分解模型(STL 或 Prophet 风格)加上一条每周峰值规则,在 4–12 周视窗上出奇地有效。这个模型产生我们关心的三个数字:链路达到 80% 峰值利用的日期、达到 95% 的日期、以及预期的每周增长斜率。
- 至少用每条链路或 PON 端口 90 天的一分钟计数器做训练。
- 分解:趋势、周季节性、日季节性、残差。
- 按周预测峰值(预测分布的第 95 百分位)。
- 把预测峰值映射到已知阈值(80%、90%、95%),给出饱和日期。
- 每周重训。模型漂移比谁都想得快。
有意思的地方:基于队列的预测
预测更棘手的地方是增长非自然发生时——比如销售第 4 周要上一栋 2000 用户的楼。这种增长不会出现在历史流量里。它出现在 CRM 里。只看 NMS 的容量规划会漏掉悬崖。连接了 CRM 和订单簿的容量规划则能提前几周看见。
会自我回本的整合
给容量规划器能加的最好特性,就是从销售管线来的数据源:每周按地理划分的计划开通量。我们见过预测精度只靠打开这一个信号,就从 ±35% 变成 ±9%。
晚到的代价
值得量化替代方案。「等投诉」模式在三个方向上收费:流失(用户在 2–3 个月内离开一条饱和链路)、口碑(负 NPS 扩散)、紧急采购溢价(为一个原本可以有 notice 折扣的端口付点亮溢价)。我们把饱和的持有成本建模为每受影响用户每月约 4–9 美元,再加 3–5% 的流失附加。
90+ 天
骨干扩容的典型采购交付周期
$4–9
饱和状态下每受影响用户每月持有成本
+3–5%
饱和群体中的流失上浮
好的样子
- 1一个看板,显示每条 uplink、PON 端口和骨干段及其预测饱和日期。
- 2每周自动送达 CTO 和财务的摘要——未来 60–90 天要花钱的地方。
- 3与 CRM/订单簿直接整合,让计划开通量在上线前就影响曲线。
- 4对越过阈值的端口自动生成采购工单,并附上游厂商的预报价选项。