酒店与公寓全光网交付联调：六个子系统的上线顺序与验收清单
核心要点：酒店与公寓的全光网交付，翻车点很少在设备，而在顺序。光缆与分光、客房 ONU 与 Wi-Fi、IPTV 组播、语音、客控门锁、安防监控这六个子系统，若等全部装完再一起联调，问题会互相掩盖，定位成本成倍上升。下面给一条能照着走的顺序：先立移交标准，再排依赖，然后分四阶段推进，每阶段都有出口条件，最后附联调清单、压测项与移交包。
一、为什么"全部装完再一起调"一定会翻车
常见排期是四段串行：布线、安装、开通、联调，联调压在最后三五天。这个排法把所有不确定性都推到时间最紧的时候。
一栋 150 间客房的楼，末端设备接近一千台。哪怕只有 5% 未就绪，也是四五十台，压在开业前三天处理，等于每小时要闭环一两个问题。
更麻烦的是故障掩盖。组播没打通时，客控丢包会被当成"网络不稳"；语音有回声，现场先查交换机，实际是网关增益；门锁离线，第一反应是电池，真正原因可能是 ONU 的 PoE 口协商。六个系统同时出问题，每次定位都要在六条链路之间反复排除。
所以联调不该是最后一道工序，而应拆成分段动作，每段只让一两个变量进来。
二、先定义"能开业"，再谈顺序
没有验收标准就排不出顺序，因为没人知道某一步算不算做完。开工前应与业主、总包、各子系统供应商写下三条判据：
- 单房可用：任取一间房，上网、电视、电话、客控、门锁、能耗六项在一次进房内全部完成。
- 跨房可用：一百间房同时换台不卡；前台一键全开灯光，指令全部落地；监控全在线且上行不拥塞。
- 异常可定位：随机关掉一台 ONU 的光纤，运维不看图纸也能说出这是哪层哪间、挂在哪个分光口。
第三条最容易被忽略，却决定交付后三年的运维成本。
三、六个子系统的依赖关系
排顺序的本质是排依赖。这张表可以直接当排期讨论的底稿：
| 子系统 | 依赖什么 | 被谁依赖 | 不能提前做的原因 |
|---|---|---|---|
| 光缆、分光器与光层 | 井道、桥架、机房位置 | 全部子系统 | 光功率不达标时，上层调试结论都不可信 |
| 客房 ONU 与 Wi-Fi | 光层 + 客房供电 + VLAN 规划 | IPTV、语音、客控、门锁 | ONU 未稳定在线，无法区分配置与链路问题 |
| IPTV 组播 | ONU 在线 + 组播源与频点表 | 无 | 频道表未定稿就调，等于反复重配 |
| 语音 | ONU 在线 + 号码与拨号方案 | 无（涉及断电逃生） | 号码未开通只能测通断，测不出回声与并发 |
| 客控、门锁与能耗 | ONU 在线 + 地址与端口规划 | 无 | 地址未收敛时，冲突会伪装成设备故障 |
| 安防监控与门禁 | 光层 + 上行带宽预算 | 无（占用上行） | 先上线会吃掉上行余量，掩盖其他业务表现 |
这张表要记住的只有一条：光层是所有结论的地基。光功率差 3 dB，后面每个子系统都会不稳定，且毫无规律。
四、四个阶段与出口条件
把依赖压成四阶段，每阶段必须有出口条件，不满足就不推进——这是最该写进合同的一条：
| 阶段 | 主要工作 | 出口条件 | 工期占比 |
|---|---|---|---|
| 一 · 光层与注册 | 主干分光、光功率测试、ONU 批量注册、VLAN 与地址规划落纸 | 收光全部在预算内、台账与房号对应、无未注册设备 | 约 40% |
| 二 · 单房打通 | 选光预算最紧的一间做样板房，六项业务逐项跑通 | 六项全过且连续稳定 24 小时 | 约 20% |
| 三 · 分层复制 | 按楼层或分区复制，一层一验 | 抽检合格、异常房号清零、地址池占用正常 | 约 30% |
| 四 · 压测与移交 | 组播、监控、客控同时压测，交付移交包，陪跑 | 压测全过、移交包齐备、业主签字 | 约 10% |
占比只是经验参考，真正要守的是"不满足出口不推进"。现场最常见的妥协是阶段一差几间房没注册就开业务，这几间房会在阶段三变成最难查的疑难。
五、阶段一：光层不干净，后面全是玄学
这一阶段的产出不是"能上网"，而是三份别人看得懂的资料：
- 双端光功率记录。OLT 发光与 ONU 收光逐台记录，写明测试仪型号与时间。只记收光不够——同一读数可能来自发光偏高加损耗偏大，两者对扩容的含义完全相反。
- 房号映射表。房号、分光器编号与端口、ONU 序列号、管理地址四列可互相反查。
- VLAN 与地址规划表。各业务占哪个 VLAN、客控与门锁是否独立网段、DHCP 由谁发，都要在阶段一冻结；之后改一次就是整层重配。
三条红线：收光低于预算余量、存在反复上下线的 ONU、分光口与房号对不上。任一未达标就不该进入阶段二。
六、阶段二：用最远的一间房做样板
样板房选哪间，决定后面返工多少。常见错误是选楼层中间、离弱电井最近、装修最完整那间——它一定最好，也一定掩盖最坏情况。
正确选法是选光预算最紧的那间：离机房最远、分光级数最多、线缆最长。用最好的房间做样板，等于把风险留到阶段三逐层暴露。
六件事按固定顺序过：上网（VLAN、地址、限速档位、实测速率）；电视（开机时间、换台时延、频道数与频点表一致）；电话（内线互拨、外线呼入呼出、断电后能否拨出）；客控（各场景，以及断网后本地是否仍可操作）；门锁（发卡、开锁、记录上传）；能耗（数据是否按时上报）。
最后一项常被跳过，因为它不影响客人体验，却决定后期能否做能耗分析。
七、阶段三：分层复制，把异常留在小范围
样板房通过后不要直接全楼上，按楼层或防火分区复制，一层一验，任何配置错误最多影响一层。每层验收只需三件事：抽检若干房做六项快速核对；查该层有无 ONU 反复上下线；确认没有新增地址冲突。
阶段三的隐性问题是地址池耗尽与租期过短。客控、门锁、监控、盒子都会自行续租，租期太短会在整点集中续租，表现为每天固定时段设备集体掉线几分钟。
八、阶段四：六个系统同时开起来
跨业务压测最容易被砍，因为它不产生新功能，只暴露问题。但它对应开业当天的真实场景：客人开电视、前台批量开灯、监控全开、有人在打电话。
| 压测项 | 方法 | 通过标准 |
|---|---|---|
| 组播并发换台 | 尽可能多的房间同时切到不同频道，反复多轮 | 无花屏长黑，上联与 ONU 无丢包堆积 |
| 客控指令风暴 | 前台一键全开、全关，连续多次 | 指令全部落地，无离线，服务端无队列积压 |
| 监控上行叠加 | 全部摄像机同时上传，叠加组播与客控流量 | 关键业务不降级，监控无丢帧告警 |
| 语音并发 | 按设计并发路数集中呼叫 | 无单通、无回声、无掉话 |
| 断电逃生 | 切断该层供电，观察语音与门锁降级 | 语音按设计可拨出，门锁可机械开启 |
| 单点失效 | 拔掉一条上联或一路分光 | 按设计降级而非全断，告警可定位 |
客控指令风暴尤其值得一测：单条指令只占几百字节，一百多间房同时下发也就几十 KB，压力在服务端队列与设备并发上。很多项目"一键全开"卡住，是控制器把指令串行处理了。
九、五种最常见的翻车现场
- ONU 注册风暴：整栋同时上电，几百台同分钟注册，OLT 控制面被打满。按楼层分批上电，或开注册限速。
- 地址冲突：客控、门锁、监控由不同供应商施工，各按习惯分配网段，交付时才发现重叠。
- 组播风暴：IGMP snooping 未启用或未开代理，组播全端口泛洪，吃满客房下行。
- 语音回声与单通：多半不是网络问题，而是网关增益、回声抑制与话机型号不匹配。
- 门锁离线：常见于 PoE 余量不足、电池锁休眠过深丢心跳、服务器与 ONU 时区不一致。
十、移交包：五份东西加一段陪跑
交付的终点不是验收通过，而是业主的人能自己接住。移交包固定五份：拓扑图与标签对照表；账号与权限清单（交付时统一改默认密码）；房号—ONU 序列号—分光口映射表（可导出）；验收记录（含光功率原始数据、压测结果）；故障处理手册（六类现象的判断顺序与责任人）。再配七天陪跑，让第一次真实高峰留在原班人马还在时。
结语
全光网本身不复杂，复杂的是六个子系统在同一栋楼里同时上线。顺序排对，问题数量不会减少，但每个问题都会在只有一两个变量时出现，定位成本能降一个量级。真正决定项目赚不赚钱的，往往不是设备采购价，而是交付期返工了几次、开业后又跑了多少趟现场。
如果项目卡在"设备都装完了就是调不通"，通常不是设备问题，而是阶段一的光层或台账没做干净。可以从双端光功率记录和房号映射表这两件事倒查一遍。
联系我们
- 邮箱：zhenghui.xu@sczhgx.com
- WhatsApp：+86 17612849559
- 官方商城：shop.sczhgx.com
