我们在 FTTH ISP 内部反复发现的 10 个运营问题

过去 24 个月我们走进了用户规模从 8000 到 22 万的运营商后台。头条问题各不相同。深层问题几乎一模一样。这是一份经过现场验证的清单——以及我们对每一条反复在做的事。

1. 两套 NMS,每个 OLT 厂商一套

一旦一家运营商收购另一家,就会冒出两套 NMS。每一套都是自己那部分设备的「真理来源」。工程师同时开着两个标签页。错误发生在拼接处。合并到一套厂商无关的 NMS,单是许可 9–12 个月内自我回本,错误减少上 3–4 个月内回本。

2. CRM 不知道网络在做什么

客服在电话里应付一个投诉的用户,他们从网络得到的唯一信号是「在线/离线」。如果用户的 WAN 上着但 CPE 上 WiFi 配错了,坐席无从知晓。补上这个信号缺口,是对大多数运营商开放的最大一步。

3. 开通拖得比该有的时间长,只因缺一个 API

在十家手工开通的店里,九家里恰好有一个工具(通常是 OLT 控制器)没有可用的 API。所以一个人来跑 CLI 脚本。其他都自动了。那一段 CLI 脚本的代价,是几天延迟和长尾式的拼写错误。

4. 拓扑分散在三张不同的表格里

现场有一张 Google Sheet。工程有 Visio。NMS 有自己自动发现的图。三家没一家对得上。没有权威拓扑,RCA 就无法工作——而权威拓扑意味着由 LLDP/CDP 从在线网络中导出,只在接缝处人工补充。

5. 固件太旧——或太新

没有一致的政策。要么 CPE 跑着 4 年前带已知 CVE 的固件,要么上个月被强推到最新 Beta,其中 2% 现在每 12 小时挂一次。修法是一套带健康门禁、内嵌于 ACS 的分阶段发布策略。

6. 告警噪声底太高

一台典型 NMS 每月冒 4000–20,000 条告警。一个典型 NOC 读 50 条。其余被丢在地上,统计意义上把真的那几条也埋了。基于拓扑与历史相关的 AI 抑制,能把可见量削去 80–95%,而不丢失可行动的那几条。

7. OLT running-config 没有备份——任何地方都没有

我们走进过一些运维中心,网络上最贵的单台设备除了「工程师的笔记本」外没有 running-config 备份。周六晚上那台 OLT 挂了,恢复时长是几天,不是几小时。到 git 风格版本控制的每日自动备份是基本要求。

8. RADIUS 是那个秘密的单点故障

我们最近做过基准的运营商,RADIUS 每分钟不可用大约损失 400 个会话和一波入呼。RADIUS 跑在一台 VM、一个负载均衡器背后,没有集群故障切换。让人痛苦的是,这是我们看到最常见的配置。

9. 报表要三天才能出

一份月度高管报表本不该占分析师三天。但它就是这样,因为数据活在四个工具里,分析师本人就是整合。用模板化叙事的 AI 辅助报表生成把这变成一小时——分析师把省下的时间花在只有人类能做的事上。

10. 「知识」活在两个人的脑袋里

每家 ISP 里至少有一个工程师,清楚知道哪个 OLT 端口的 SFP 有毛病、哪个用户星期五晚上一定要打电话。那些知识没有写下来。工程师换工作时,六个月的运营质量跟着走。把部落知识编纂进平台——作为策略、作为 profile、作为监控——是大多数运营商拖延、也最后悔拖延的事。

延伸阅读