ONU 固件批量升级与版本管理：把三千台光猫的软件版本管住
核心要点：ONU 固件版本失控，是 PON 网络里最容易被忽略的一类故障源——同一张 PON 上跑着三四种固件，故障随机出现、现场无法复现、回滚也找不到依据。这篇文章给的是一套能执行的做法：先把版本基线定下来，再按 20%／50%／100% 三批灰度推进，最后把版本、位置、时间和执行人写进同一张台账。它解决的不是"怎么点升级"，而是"三千台设备怎么管得住"。
一、版本失控的现场症状，比硬件故障更难查
典型的报障长这样：某个小区三栋楼，同一批 ONU，二楼说 IPTV 换台要等五秒，五楼说电话只能听不能说，另一栋什么都没问题。运维上去重启，好两天，又复发。换一台新 ONU 就好了，于是被判定为"个别设备不良"——实际上换掉的那台换的是型号和固件，问题被掩盖了，不是被解决了。
PON 的麻烦在于层数太多。光功率正常、注册正常、拨号正常，看起来一切正常，问题可能停在 OMCI 建模、组播加入方式、VoIP 编解码协商这些看不见的层面。而这些层面的行为，恰恰由固件决定。
真正的卡点是：后台通常只看得到在线状态、光功率和最后一次上下线时间，看不到固件版本。没有版本视图，排查就只能靠猜；靠猜出来的结论写不进验收报告，也没法跟客户解释。
版本漂移很少是一次性造成的，它来自三个日常动作：补货批次不同、坏件换新时顺手刷了供应商给的最新包、施工队为了先通业务把手上任何能注册的固件都刷进去。三个月后，一张 PON 上就出现三种行为不一致的设备，而没有一个人记得是哪一次动作造成的。
二、第一步不是升级，是先有版本基线
很多项目一上手就"把设备升到最新版"，这是最容易出事的做法。升级的前提是知道目标版本是什么、为什么是它。建议把版本分成三档，并且写下来：
- 稳定版：全网主力版本，除安全修复外不动。占全网 90% 以上。
- 灰度版：正在验证的版本，只允许在指定楼栋或指定批次内出现。
- 应急版：只用于修复某个已知问题的版本，问题关闭后即退出。
然后是版本矩阵：以 ONU 型号和芯片为行，以版本号为列，格子里写状态（稳定／灰度／禁用）和适用业务。这张表不用做得漂亮，但它必须存在，而且要能让一线工程师查到"我这台该装哪个版本"。
两条纪律：同一分光器下不混跑超过两个版本，否则故障定位会失去参照；新版本进网一律先过灰度，不论供应商怎么承诺。
三、升级前必须核对的五件事
- 型号与芯片：外壳一样不等于同一颗芯片。用 OMCI 上报的 equipment ID 与 vendor ID 确认，升级包对不上的设备一律排除，不要抱着"试试看"的心态。
- 光功率余量：弱光设备在升级过程中更容易中断，也更容易停在半完成状态。收光低于 -27 dBm 的先处理链路，再谈升级。
- 供电：升级过程掉电是最常见的变砖原因。机房确认 UPS 续航，楼道取电确认没有人为断电计划。
- 业务窗口：避开晚高峰 20:00–23:00，避开酒店入住与退房时段。凌晨 2:00–5:00 是唯一普遍可用的窗口。
- 回滚包：确认 ONU 支持双镜像（A/B bank），确认回滚包与回滚步骤已经落在文档里。没有回滚包的批次不许开工。
四、批量升级的三条路径，各有边界
路径选错，比不升级更麻烦。三条路都能用，但不能混在同一批次里用，否则失败原因永远分不清。
| 路径 | 覆盖面 | 前提条件 | 适合场景 |
|---|---|---|---|
| TR-069 / ACS 远程管理 | 跨 OLT、跨区域 | ONU 支持 TR-069 且已纳管 | 多局点统一版本、需要按策略下发 |
| OLT 侧 OMCI 下发 | 单台 OLT 下全部 ONU | 同厂商、OMCI 建模一致 | 大批量、同一局点、追求最短耗时 |
| 本地 Web / U 盘 | 单台至数十台 | 人到现场 | 救砖、补装、疑难单台 |
实践中常见组合是：OMCI 负责主体批量，ACS 负责跨局点补齐与后续版本巡查，本地手段只用于收尾。三种方式的执行记录要分开写，混在一起就失去了追溯价值。
五、灰度节奏：20% → 50% → 100%
一次性全网升级，等于把全部客户当成测试样本。建议固定三段式，每段都有明确的放行条件和回滚触发条件：
| 批次 | 比例 | 观察窗口 | 放行条件 |
|---|---|---|---|
| 第一批 | 20% | 24 小时 | 每台 OLT 至少覆盖 5% 端口，四个指标无劣化 |
| 第二批 | 50% | 24–48 小时 | 同上，且无集中投诉 |
| 第三批 | 100% | 72 小时 | 全量完成后出一次版本分布统计 |
四个观察指标：注册成功率、光功率分布（是否整体下移）、单位时间掉线次数、业务投诉量。任何一个出现明显劣化就停批，先查升级包与设备型号的匹配关系，不要先怀疑硬件。
失败率超过 2% 就立即停止，这是硬阈值。停批不是失败，硬推下去才是。
另外一条纪律：灰度窗口内不要同时调整限速模板、VLAN 规划或认证方式。一次只动一个变量，出现劣化才分得清是固件还是配置。多数团队都在这件事上吃过一次亏，之后才学会收敛改动范围。
六、升级失败的处理顺序
现场最容易犯的错是"失败就再试一次"，连试三遍之后日志被冲掉，什么线索都没了。固定顺序如下：
- 单台失败：重试一次。仍失败则回滚到上一版本，记录序列号与现象，不当场深挖。
- 变砖（无法注册、OMCI 无响应）：直接安排现场换机，不要占用远程窗口反复尝试。
- 批量失败：立即停批，按顺序检查三件事——升级包是否对应这个型号、这批设备的光功率是否普遍偏低、OLT 侧 OMCI 会话是否已达上限。
- 记录失败快照：设备序列号、当时收发光、失败步骤、错误码。这四个字段比任何口头描述都有用。
七、把版本写进台账：一张表管住三千台
版本管理最后一定会落到一张表上。字段不用多，但要能回答三个问题：这台设备在哪、现在什么版本、谁在什么时候动过它。
- ONU 序列号（GPON SN）
- 位置：楼栋－单元－房号，与按户认证使用的 circuit-id 绑定，位置不需要二次录入
- 型号、芯片、当前版本、上一版本
- 上次升级时间、执行人、结果（成功／失败／回滚）
关键设计：每次升级只允许改三列——版本、时间、结果。要改的字段越多，台账越不会被真的维护，最后变成一份过期文档。每月做一次版本分布统计，输出三个清单：版本占比、异常版本设备、待升级设备。
维护人要比表结构更早确定。比较可靠的做法是把台账挂进施工验收：不填台账不算完工，而不是等运维事后补录。事后补录的台账，一个月内就会失真。
八、上线验收八项
- 版本矩阵已发布，全网在跑版本不超过两个。
- 每台 OLT 都有对应型号的回滚包与回滚步骤记录。
- 灰度批次记录完整：比例、时间、放行结论、停批原因（如有）。
- 弱光设备（收光低于 -27 dBm）在升级前已清理完毕。
- 升级窗口与业务方书面确认，酒店类项目同步前台与客房部。
- 所有失败设备有序列号、现象与处置记录。
- 台账可按楼栋导出，能直接交给现场工程师使用。
- 月度版本分布报表已成文，作为下季度采购与备件依据。
结语
固件升级本身不难，难的是它跨越了采购、施工、运维和客服四个环节，任何一个环节缺记录，整件事就会退化成"出问题再重启"。把版本当资产管，而不是当操作管——先有基线，再有灰度，最后有台账。做到这三点，三千台 ONU 也不过是一张表的事。
联系我们
如果你的项目正在做 ONU 选型、批量部署或存量网络版本梳理，欢迎把现网情况发给我们，我们可以一起看版本矩阵怎么定。
- 邮箱：zhenghui.xu@sczhgx.com
- WhatsApp：+86 17612849559
- 官方商城：shop.sczhgx.com
