网格时代广电网络运维工作的思考和建议

1、前言

目前广电网络的运维工作总体以处理用户故障核心开展的。用户发现使用业务出现问题，于是打电话至呼叫中心进行故障申告，呼叫中心进行初步判别和分拣后，将用户故障工单分发给在第一线进行维护工作的客户维护部工作人员进行上门服务。客户维护部负责机房(含二级站机房)之外的光缆、电缆系统的保障和维护，在用户家中如果发现故障在本环节无法处理，则要求将此用户工单责转至上游部门由上游部门跟进处理(为避免推诿扯皮原则上是无条件责转工单)。

目前直接与客户维护部对接的上游部门是机房维护部及运营支撑研发中心的终端部，而与机房维护部进一步对接的最终部门是总工办。接到由客户维护部责转的工单后，机房维护部和终端部在自身资源和能力允许的范围内排除故障(如发现并非机房原因造成用户故障的则要求对责转人员进行追责)。如故障仍无法排除，机房维护部向总工办提交扩容或变更技术设计的申请，终端部向研发部门提出支持需求。最终环节的两个部门接到申请后提出解决方案由机房维护部及终端部进一步实施直到将故障解决后，由机房维护部及终端部填写工单，此故障完成最终闭环。实际上自有线电视运行之日起，运维工作的流程和核心思路都没有变过，那就是用户发现问题，电话申告故障由呼叫中心生成故障工单，以工单形式约束和推进运维工作的进展。

2、分析

在只有单向电视业务的时代，因为技术条件限制只能被动的向客户提供维护服务，这个核心思路只能是唯一的选择，但在当今这个强调用户体验的互联网时代，坐等用户提意见的运维思路很明显已经在严重掣肘广电网络一网三化战略的推进。

(1)技术层面的问题

目前公司双向接入网采用CMTS和EPON+EOC方式实现。

CMTS接入方式主要面临两个问题：一个是下行(正向分发)和上行(反向汇集)端口都在二级站机房内，单端口承载用户较多，扩容和调整相对复杂;另一个则是同轴电缆系统天生的缺陷-噪声，噪声是无法根除的，只能尽可能限制噪声能够影响到的范围。由于资源有限，绝大部分机房内部都是若干个小区共享一组上下行端口(1个下行百兆端口至少覆盖8-12个小区光节点，1个上行端口至少覆盖2-6个小区上行回传)，这又造成了两个严重的问题：一是端口带宽跟不上小区用户增长的带宽需求，新用户刚开通广电宽带体验可能就不太好，随着营销活动持续开展反倒越来越不理想。去年750训练营逐小区发展业务造成单个小区用户数量急剧增加就是这种情况的极端体现;二是一旦有哪个小区产生了不可控的噪声干扰，会影响到共享这一上行端口的所有小区用户(单个端口承载的用户数量不平衡)，少则影响几百户，多则上千同时出现故障，而且噪声干扰的不仅是宽带业务，互动业务同时也会受到影响。

EPON+EOC接入方式相比CMTS方式，因为光纤延伸至小区或者楼栋及单元，单ONU理论上可以实现千兆级别的带宽覆盖相对数量较少的用户(几十到上百户)从而保证了高带宽业务的实现，同时因为ONU和EOC局端放置在小区，不但方便扩容和调整，还可以将同轴线路的噪声影响范围严格的限制在单局端覆盖的范围内，更适合作为光纤到户前的过渡方案。目前EPON+EOC接入方式最大的瓶颈在于传统落后的多用户共用1个业务VLAN规划造成无法实现真正的QoS以及因用户端产生的广播风暴造成大面积用户故障的问题，与同轴电缆系统噪声类似的是，用户端广播风暴同样是无法根除的(CMTS通过路由方式转发所以没有广播风暴问题)，但可以通过QINQ技术实现1用户1业务VLAN规划方式从而将用户广播风暴造成的影响限制在单个用户范围，同时通过两层VLAN的叠加可以实现有效的QoS和精准的用户定位。而如果不能在根本上改变落后的VLAN规划方式，广播风暴问题即便实现了光纤到户一样解决不了。

(2)制度层面

为了将维护界面划清楚，之前的客户维护部负责机房(含二级站机房)之外的光、电缆线路及设备维护，机房维护部负责机房内部的所有设备维护，总工办负责整个网络的规划及优化设计。三个维护环节通过故障工单流转的方式衔接和制约。这种看似清晰的运维界面，实际上存在着严重的缺陷。

1)通过故障工单来衔接三个运维环节的确能够有效约束每个环节不作为的可能，但问题在于所有的工单对于用户来说都是已经发生的故障，而之后对用户进行的维护工作全部都是事后维护，这在单向电视业务时代是不得已而为之，但在如今这个以用户体验为核心的互联网时代是无法想象的。实际上以目前的现有的技术手段依靠各种网络系统采集到的信息进行最大限度的前向维护是可行的，但到目前为止，除了营维合一的网格运营中心因为直接接受经营业绩考核而有内在驱动力去做这个工作，其他环节依然只受工单和约束和驱动，缺乏足够的内驱力(如果没有工单，完全可以不做)。

2)所有二级站之外的线路和设备，本质上都是二级站内设备的延伸，也是最终为业务落地服务的，但三个维护环节界面的划分却更有利于内部的绩效考核，因此三个环节内部的技术信息是不其他环节公开而且也不关心其他环节的技术信息，这种运维界面分割造成了严重的信息不对称。举例来说：对于CMTS接入方式，当有客户申告网络速度较慢故障时，到客户家进行维护的服务人员事前并不知道这个用户所在的CMTS具体的端口信息，诸如用户报维时是否并发超限，是否存在噪声等等。当这个服务人员在用户家中解决不了的时候，他有两个选择，一个是责转至上游环节，另一个则是通过非技术手段使此用户的工单就此终结。由于信息不对称造成一线的服务人员对于判断故障成因存在客观困难，而责转工单给其他环节一旦不符合要求则会被其他环节进行反考核扣分，因此作为一线人员做出后一个选择的可能性陡然增加。这又进一步造成了另一个角度的信息不对称-上游环节对于客户实际问题的性质、范围、数量的误判，可能各种数据报表上明明显示有可能会产生大量的故障，但实际上却并没有接到责转的工单或者某个类型的故障占比非常低，于是就存在是否需要进一步跟进的问题。

3)即便是最终产生了工单流转，从客户报维到一线人员到客户家中，然后测试并通过各种手段来做故障界面分析最终责转至上游环节，那么上游环节一样要进行一遍重复的工作，因为根据现在的工单责转流程，工单责转方判断故障非本环节原因且成功责转后此工单在本环节即告结束，没有任何责任和义务去配合上游环节的工作。而上游环节经过测试和甄别发现此故障是因并发超限等原因造成的，则需要向再上一级环节提出优化申请，待优化方案发到本环节后再依照执行。但实际上绝大部分的此类故障绝大部分并不是多么复杂的技术难题，只需要对二级站内部端口与小区设备联接关系做微调就可以实现优化，本来可能只需要三个小时就能完成闭环的工作，实际上可能用掉三天。如此之低的效率，让网格运营中心怎样去完成经营指标呢?

4)在技术层面中的提到CMTS噪声和EPON+EOC的环路问题，处理起来基本都会涉及到前面的3个环节，动用大量的人力和物质资源，又无法快速解决问题，不能快速解决问题的同时，又无法有效避免下一次同类故障的发生。

但实际上是有变通余地的-只需要机房有人能够做出快速响应，至少可以让客户问题暂时解决或者缓解。对于CMTS噪声，可以临时将不是噪声源的小区光节点临时调整到别的上行端口就快速可以规避因一个用户造成上千用户被影响的问题。对于EPON+EOC未实现基于QINQ的1用户1VLAN规划之前产生的广播风暴问题，同样可以将不是广播风暴来源的ONU、EOC局端上的业务VLAN临时修改成其他VLAN最大限度减少被影响的客户范围、数量。

3、建议

目前通过营维合一实现网格化运营，已经彻底改变了之前客户维护部一切工作围绕工单进行的传统运行模式，但上游环节依然按照之前后向维护的工作思路进行，这种头脑和身体不协调的情况必然会影响到网格运营中心的业绩，所以必须对现有运维体制进行调整，所有技术资源都下沉至网格以打破之前以故障工单驱动的后向运维模式。而且网格运营中心即将向智能家居智能城市等新业务进军，目前为止没有配套的直属的技术队伍有效支撑，依然以故障工单责转这种后向维护方式来要求其他技术部分来提供技术支持显然无法有效保证预期效益实现。所以在技术层面，网格运营中心必须尽快建立直接隶属、直接接受网格运营中心业绩考核的技术队伍，以经营业绩而不是故障工单为内驱力来驱动整体运维工作的开展，尽可能在网格内部进行前向维护及快速处理突发故障实现故障在网格中心最大程度的闭环。

基于所有技术资源都下沉至网格这个思路，网格运营中心的技术队伍需要以下资源：

1)足够的信息对称，只要目前涉及到会影响到客户体验的技术监控系统及报表，不止具体负责部门有权查看，网格运营中心也要查看。对于非网格中心负责但涉及到用户体验的技术项目、方案、操作、割接，网格中心必须有知情权和调阅权。

2)二级站外的光、电缆系统本质上是二级站内设备的延伸，网格中心要想实现快速处理、大部分故障在网格中心形成闭环，就必须要有二级站设备管理权及其配套网管系统的使用权。

3)只要网格中心内部能够完成的规划或者优化方案(包括需要快速跟进的光、电缆网络的设计和施工)必须由网格中心自行完成，不再以逐环节提交申请的方式推进，而且以先处理故障，再进行分析和备案的思路进行，把能够提前的工作全都提前。

4)在技术上接受上游环节的指导和监督，在业绩上监督和考核上游环节的支持力度及效果。

5)尽快推进EPON+EOC方式VLAN规划方式的改进。

由于网格运营中心的技术队伍直接接受经营业绩考核，其内在的驱动力是远高于之前基于工单流转考核的驱动力的，相比之前后向维护的运维工作方式，可算是整个广电网络运维工作的脱胎换骨、浴火重生。所以建立网格中心自己的技术队伍并下沉一切为客户服务的技术资源是当务之急、必由之路，早一天建成，早一天见效。