在 GPON 网络上自动化根因分析
当一台 ONU 掉线,答案通常在光功率、OLT 端口和邻居里。这里讲 AI 如何在几秒内回溯——以及如何评估任何 RCA 引擎。
一位用户在 21:14 掉线。21:15 客户已经打进电话。21:17 一线坐席把症状录入工单。21:23 一个 NOC 工程师在五个工具间来回,想搞清是真实故障、欠费停机还是短暂闪断。21:40 一辆车被派了出去。60% 的情况下,那辆车根本不必去。
这就是人工根因分析每天的代价。不是技术员的错。数据存在,工作流不存在。GPON 运营商在 2026 年能做出的杠杆最高的一次改变,就是把这个环路端到端地自动化。下面讲这个环路该长什么样,以及如何评估任何声称能做的 RCA 引擎。
GPON 故障的物理
在无源光网络里,可行动的信号集中在少数几个测量上。知道这一点是自动化 RCA 的基石——因为 AI 必须知道该看什么。
- ONT 与 OLT PON 端口的光 Rx/Tx 功率(dBm)。
- OLT 端口状态(up/down、最近一次 flap、错误计数)。
- PON 树上的邻居——同一分光链路上的兄弟 ONT。
- 认证与会话状态(TR-069 inform、RADIUS、DHCP)。
- 近期配置变更(上一次 ACS 推送、固件升级)。
- 现场历史相关性——这台 ONT 过去 30 天有没有过投诉?
- 可用时的气象信号——影响外线光缆的冷/热事件。
五秒钟的回溯
一个自动化 RCA 引擎会同时看所有这些。它不是跑一段顺序脚本;它是从症状开始反向遍历一张有向图。「ONU 离线」变成「认证缺失」。它变成「有没有 LOS?」。再变成「Rx 功率是多少?和上一次已知良好比怎么样?」。再变成「同一分光器上的兄弟节点是不是也掉了?」每条分支带权贡献一份证据。
Netxol 的 RCA Engine 如何推理(典型端到端 1.8 秒)
- 拉取该 ONT、其 OLT 端口、其兄弟节点、其过去 30 天投诉、其配置历史的最近已知遥测。
- 遍历假设图:功率损失、光纤断、OLT 端口 flap、分光器损耗、ONU 硬件故障、认证问题、欠费停机。
- 对每条分支根据证据打分。
- 概率汇总。置信度是真实的百分数,不是「高」这样的标签。
- 把最上层的假设映射到补救动作:重启、重认证、下发 profile、派工。
- 估算搞错的代价(比如一次多余的上门)。
- 如果置信度高于策略阈值且动作可回滚,执行并验证。
- 否则连同完整证据交给 NOC。
「置信度」应该是什么意思
早期 RCA 工具一个常见的失败模式,就是那个没有意义的置信度数字——一条规则上手工调出来的权重。现代 RCA 引擎应该给你一个能过贝叶斯健全性检查的概率:50% 就是当前证据下真正的抛硬币;95% 意味着对低代价动作,不经人工复核就执行是合理的。
校准测试
抽 100 条标为「92% 置信」的 RCA 输出。复核下来大约 92 条应当正确。如果只有 70 条正确,模型就是过度自信,你还不该允许它自动动作。
拓扑的作用
我们在现场看到的多余上门,一半原本可以靠一条上下文避免:「这是同一 PON 端口上 30 分钟内第三台 flap 的 ONT。」单一 ONT 的报告看起来是客户问题;三个兄弟一起掉看起来就是光纤断。只有把拓扑放到与遥测同一个查询平面时,这个模式才会浮现。
这就是 Netxol 为什么把由 LLDP/CDP 推导出的实时拓扑图作为平台的一等公民对象。每一条告警都携带其在图中的位置。每一条 RCA 假设都能就地询问「这台设备下游还有谁?」而不必离开引擎。
评估 RCA 引擎——该问的问题
- 1融合了哪些模态?(遥测/拓扑/历史/账单/气象)
- 2「置信度」是否校准?要一份校准曲线看看。
- 3能否行动,而不只是建议?在何种策略下允许行动?
- 4是否能自我解释?对任何结论你都应能读到证据轨迹。
- 5如何处理未知故障模式?能否优雅升级而不是瞎猜?
- 6数据面是否多厂商?不支持多厂商的 GPON 是博物馆藏品。
实测结果
当这个环路端到端跑起来,我们在多家运营商部署中看到的数字是一致的。MTTR 下降 40–60%。上门下降 30–50%。与已诊断故障相关的客户投诉下降更多,因为许多故障还没被客户察觉就被处理了。
−47%
平均修复时长
−38%
入呼故障投诉
−42%
本可避免的上门