多场所集中纳管：运营商组网日志审计怎么管？

运营商把一百家店的组网交付了，但日审能力没有跟着交付。

光猫装了、线路通了、WiFi能上了，Portal认证和日志留存这两项，不在运营商组网方案的交付清单里。176号令施行之后，这个缺口不再是“行业惯例”，而是合规风险——检查发现某家店没有Portal流程、日志查不到人，能力缺失会沿着组网设备回溯到运营商侧。

智慧光迅支持云Portal和云日审以插件形态对接光猫，不换设备、不动布线。但一百家店不是装一百次插件就结束了，真正的问题是怎么加、怎么管——插件实例怎么批量开通、认证策略怎么统一下发、日志状态怎么集中巡检、出了问题先找设备侧还是插件侧。

这里要说准EaaS云管在运营商组网场景里的角色：它纳管的是云Portal与云日审这两个插件实例，而不是接管光猫。

设备归原有界面，插件归 EaaS管

运营商组网里，光猫、ONU、AP 这些接入设备的配置与维护，继续在运营商原有的管理界面完成——那是运营商既有的网管资产和装维流程，EaaS 不介入，也不需要介入。EaaS 纳管的是叠加在光猫上的插件层：云 Portal 实例（认证策略、页面模板、认证记录）与云日审实例（日志策略、留存周期、审计报表）。

批量交付：插件实例的开通流水线

模板库：按业态（酒店、网吧、民宿、公寓）预置认证页与日志策略模板，新店开通从配置工作变成选择题。

随开通下发：插件实例在宽带开通流程里批量创建，装维上门一次，宽带与合规能力一起到位——设备不动，是这条流水线成本低的关键。

灰度发布：认证策略或留存策略变更先推试点店，观察一至两天再铺开到其余门店，连锁场景一次错误策略下发就是几十家店同时受影响。

运维面：插件状态巡检与合规报表

认证失败率异常、日志断流、插件实例离线，EaaS 主动告警到运营商运维侧，多数问题远程处置；设备级故障则仍在运营商原有网管里走既有工单流程。

合规侧，日志在云端汇聚后支持按账号、按门店、按时段导出报表，迎检材料由运营商侧统一产出。

对运营商的价值：合规能力可运营

插件层集中纳管的意义，是把合规从一次性的「装完就走」变成可运营的持续服务：开通可批量、状态可巡检、报表可统一导出。设备侧零改造、零接管，运营商的网管体系和装维流程原样保留——这正是插件形态能在运营商体系里铺开的前提。

FAQ

Q1：EaaS 云管在运营商组网场景纳管什么？

A1：云 Portal 与云日审的插件实例——认证策略、插件状态、日志与审计报表；光猫、ONU、AP 等接入设备仍在运营商原有管理界面，EaaS 不接管设备管理。

Q2：门店设备出故障了找谁？

A2：光猫等接入设备走运营商原有运维渠道；插件层问题（认证异常、日志断流）由 EaaS 侧告警并远程处置，两条线分开，先分清归属再派单。

Q3：自建网络场景下 EaaS 纳管的对象有什么不同？

A3：自建网络走智慧光迅「通密一体」方案，EaaS 纳管的是梦想网关等自有设备与插件，设备本身在纳管范围内——这与运营商场景「设备不动、只纳管插件层」的边界不同。