移动网络站址运营管理平台的探索(共7044字).doc

《移动网络站址运营管理平台的探索(共7044字).doc》由会员分享，可在线阅读，更多相关《移动网络站址运营管理平台的探索(共7044字).doc（12页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、移动网络站址运营管理平台的探索(共7044字)移动网络站址运营管理平台的探索 0前言为了避免重复建设，国家成立铁塔公司，但是资源共享率的提高与运营成本的上涨成为一对矛盾体，这也是运营商迫切需要解决的问题之一。目前，运营商内部专业化程度较高，着眼于移动网网络管理，依托于各大厂商网管开发综合性网管，方便维护人员使用，例如4G网管，在实际应用中能够提供统一性的故障管控；着眼于资源管理，依托于集团以及各种系统接口，招标第三方开发统一资源管理平台，囊括固网和移动网所有的机房和设备等；着眼于成本管控，依托于集团及省分企信部、财务部，建立统一MSS系统，对财务方面进行过程管控。但是，成本上升与利润增长要求运

2、营商运营必须向精细化转型，而精细化的管控需要系统融合支撑，而目前的高度专业化造成融合起来比较困难。另外，铁塔公司维护的日常督促、月度稽核、费用结算等需要运营商方面配置足够的人员进行配合，运营商与铁塔公司的维护及财务的对接问题和高额的铁塔租赁费成为2个极点，促使精细化提上日程。如何实现网络提质增效的同时做到费用明晰，是需要解决的首要问题，本文就此问题为根本，以实现移动网络站址运营管理的精细化管控为目标，结合一线员工的实际应用需求，对站址运营进行深入探索，并通过开源技术进行初步实现，实际应用效果良好。1移动网络站址现状分析铁塔公司对运营商存量站点的接手和运营商新建站点需求的搜集，标志着运营商建造铁

3、塔时代的终结。运营商以往的一次性投入等价转化为510年的租赁性支出，有利有弊暂且不论，在铁塔共享时代确实是运营商与铁塔公司双赢的局面。移动网络站址的精细化管控则是运营商控制成本和提升质量的切入口之一。通过与运营商后台维护人员与一线员工的访谈、收集调查表以及相关的场景分析，加上对各项系统的实际操控体验，总结出如下亟待解决的问题。a）站址和设备名称变更。往往站址和设备名称需要经历设计、施工、监理、网管、网优、成本管控、一线维护等一系列相关人员经手维护，站址和设备名称的混乱性可想而知。如何规范并有计划地更新，都是必须要面临的问题。b）资源匹配一致性。资源系统的繁重众所周知，以“有用”为前提的资源系统

4、转型尚需时日，如何抛开繁重的资源系统，化繁为简，引入简便快捷的网络拓扑（例如什么站址、什么设备，什么配套），用以支撑精细化管控的资源基础，是一个绕不开的话题。c）成本单站址管控。MSS系统的集中上线解决了财务集中的问题，从采购申请、采购审批、立项、合同到最终的费用支付，均得以完善。但是如何从成本管控人员出发，面对单个站址，解决最实际的房租和电费的缴费问题，目前尚未提上日程。d）成本数据再分析。成本费用进度管控在运营商财务制度里面是重中之重，时序进度是每年都绕不开的话题。但在计算成本求和的基础上如何对成本数据再分析，提取出有价值的东西供成本预估、管控来使用，目前仅仅通过Excel进行汇总筛选。e

5、）告警稽核。不仅需要运营商内部进行指标管控，还需要与铁塔进行接口对接管控。运营商关注BBU、RRU设备层级的告警，而铁塔更专注于站址配套级别的告警，两者的不统一需要稽核比对完成。稽核数据的核心就在于告警同步和站址设备关联明细。f）系统开发维护繁杂。运营商的运营系统，要么是大型软件开发商的定制产品，要么是定制产品的唯一来源拓展，要么是定制产品的接口拓展，无论开发还是维护，起步几十万，动辄上百万，系统“转身”何其困难。2移动网络站址运营探索目前对站址的运营尚未有成型的理论和研究，本文抛砖引玉，针对搜集到的网络站址现状，结合一线员工的直面需求访谈以及相关调查表，从实际应用角度出发，以提质增效和成本管

6、控为目标，探索构建站址运营管理平台，下面以典型问题为突破口进行深入讨论。a）设备北向同步。为了精确描述设备，可以从设备网管的北向接口进行数据同步，每天凌晨进行FTP抓取，将设备网管中的前一天设备信息以设备编码为唯一值同步到数据库设备ODS库中进行备份。设备存量库与设备ODS库最大的区别就是，ODS库只是同步更新，而存量库则作为源库保留所有设备信息，尤其是设备名称及状态的变化，从而做到设备与其名称、状态的实时同步。b）站址信息扩展。以铁塔CRM为例，除记录站址的名称、编码、地址、铁塔信息、机房信息、配套信息、天线信息、挂高信息、共享信息外，还需要获取更多，包含站址名称的变化、设备与站址的对应关系

7、、站址的业主详细信息等。在站址信息表中进行数据库扩展，为站址与名称同步、站址与设备同步、站址与业主同步等多重扩展打下基础。c）变更历史管理。传统系统往往都不注重变更历史，只关注最终状态，而精细化管控必须要包含对历史变更的管理。以站址和设备名称变化为例，稽核过程中需要精确定位过程中的站址和设备的名称以及对应关系，一方面以完善流程制度督促名称统一，一方面需要用站址和设备名称变化历史来追溯过程。相关的费用管控、费用追溯、维护查询等功能，都需要历史变更功能进行辅助。d）成本定位管控。合同签订原则上应以“一站址一合同”进行签订，但也不排除现实中的合并合同。但将合同定位到站址则是一把管理利器，以合同定位为

8、基础，进行房租电费费用的成本定位。从单站站址出发进行的定位，是精细化管控的前提，所以需要做好站址-合同-成本的对应体系。做好基础的精细化管控，才能实现大成本的精确管控。e）成本数据再分析。以单站站址出发进行定位，不仅仅是在现有的基础数据上去核对单站站址的房租电费是否匹配站址、匹配合同、匹配设备等，而且需要关注单站站址的费用产出是否合理、是否能够匹配整体的成本进度，进一步来说，利用数据提取完成类似到期提醒等其他更有意义更倾向于一线的功能，才能够更好地支撑服务前端。f）告警北向同步。告警同步不需要进行更改记录，由于数据量太大，考虑使用周分析（或者每3天，后期调整）进行同步，需要设定告警归并规则，以

9、指标稽核为导向进行告警合并。原则上主要核定同站址配套退网的指标，兼顾设备离线告警，为维护人员定位故障、稽核指标进行支撑。g）开源技术应用。现有系统的接口是必不可少的，毕竟数据本身已经被拉扯得四分五裂，但是可以从一统江湖的角度出发，构架开源式平台，当然，需要构建合理安全体系。将上述接口进行汇总后，辅以安全接口，开放给“边运营边开发”的刚需人员进行维护，以开源技术为突破口，以框架为起步，以创建平台为基础，建立网络站址运营管理平台不失为解决方案之一。3移动网络站址运营平台的设计与初步实现平台着眼于实现网络提质增效、费用清晰的目标，以上述突破口为抓手，分别设计基础数据框架、数据接口、业务逻辑层、数据展

10、示层、移动端展示层等5个层次。3.1基础数据框架包含设备ODS库、数据库以及铁塔信息ODS库，主要提供MVC模式中的数据MODEL。a）设备ODS库为设备网管北向同步的ODS库，目前实现方法是每天由设备网管进行设备信息打包，ODS库表直接从FTP上下载压缩包，解压后进行更新，以缓解设备网管负载和降低数据接口风险。技术为成熟方案，实践证明不存在风险，但是个别情况下会出现解压缩失败的情况，需要设定程序进行执行结果通报。b）铁塔信息ODS库为远程抓取信息或者本地上传信息来的ODS库，目前远程抓取接口在铁塔对接运营商层面实现并不是非常稳定，暂时以下载后的EX⁃CEL进行再次上传进行确认。c

11、）业务数据库则包含人员配置、角色配置、菜单配置、站址基础信息、设备基础信息、合同基础信息、成本缴费信息等基础数据库。需要单独列出的是历史信息数据库，需要将基础信息变更的历史过程按照字段变更进行记录，这样才能方便前端的准确定位和查询。d）告警ODS库主要为故障查询和指标稽核进行告警备份。与设备网管的告警同步可以参照设备ODS库实现方法。告警ODS库从设备网管同步后，关键在于将繁多的设备故障进行合并归档，以设备中断级别告警为主要告警，其余告警进行视图聚合，将同一设备下的告警进行归纳后，在同一站址级别进行统一的展示，方便维护人员使用。同时，归并后的告警方便用户在告警稽核时进行甄别使用。为了更好地描述

12、融合关系，其核心在于将多种基础信息进行有机融合，从而建立完整的站址运营管理平台，用最基础的数据创造最有用的价值。3.2数据接口a）设备北向同步在与设备厂商进行沟通后，通过接口文档直接进行调用和读取。频率设定为每天凌晨进行一次同步，并通过程序记录同步状态。b）铁塔信息的数据接口通过铁塔系统进行EX⁃CEL下载，下载后进行项目匹配，然后导入系统，进行铁塔ODS数据库更新。频率设定为每周一次。3.3业务逻辑层a）系统管理主要解决安全问题（可以在SpringMVC基础上引入SpringSecurity），关注人员配置、菜单配置、角色管理等，后期可以实现用一点登录的性质关联OA等其他系统；通

13、过将人员信息ID对应到角色管理上，再对应到菜单管理以及按钮管理的方法，根据人员的维护权限细化人员系统管理权限，从而确保系统操作安全。b）站址管理则主要从实际应用角度出发，以方便维护人员使用为第1前提，除了站址信息的常规增删改之外，增加对站址的新增进行管理员级别的审核，保证站址信息库的准确。c）设备管理主要以网管设备为基准值，记录对设备信息的变更情况。与站址管理类似的是，管理员层级需要对维护人员的设备变更信息进行审核，保证设备信息库一致性。d）站址设备关联管理通过将站址的ID与设备的编码ID进行关联，从而确保对应关系的唯一性，一个站址可能包含多个设备，但是一个设备在同一时期只能对应一个站址，相对

14、应的一个铁塔订单只能对应一个站址，但是可以对应多个设备，这也就解决了指标稽核中的指标定位问题。另外，这个逻辑关系也有助于维护人员对站址、告警的定位。同样的，关联关系的变化也需要进行管理员级别的审核。e）成本管理中的合同管理主要通过站址ID与合同ID进行定位，一个站址只能对应一个合同，前期维护过程中出现的一个合同对应多个站址的情况予以限期消除，目前已经基本完成。成本管控人员需要对合同的建立进行确认，确保同MSS系统吻合。f）成本管理中的费用主要通过合同ID将多个缴费信息ID进行关联，确保缴费有根据，合同有详单。一个合同对应多个费用信息，包含房租和电费，而一个费用信息在一个时期内只能对应一个合同。

15、g）历史信息管理主要就是通过设计全局拦截器的方法，在逻辑层面实现对基础信息变更时的信息记录，确保记录变化的字段名、字段原值、字段新值等信息，然后以时间（秒）为单位进行归并，从而完成大到记录，小到字段的历史可追溯功能。h）统计分析主要是以视图聚合的形式实现，基础数据的展示除了基础管控，不能实现更高的含义和价值，通过存储过程的方式进行后台计算，将站址信息进行分门别类的汇总，将费用信息进行加权平均计算，最终生成图表展示以及其他相关功能。财务的成本往往只要求账期内进行保障结算即可，而我们还实现了分时间段将账期内的费用按照正常发生的时间段进行平均计算，更有利于单个时间段的费用估算。i）告警分析通过视图进

16、行聚合，将告警ODS库进行归纳，将设定好的规则通过SQL进行实现，然后以视图的形式替代数据表，为表现层提供支撑。设定规则将配套中断级别故障和设备中断级别故障进行置顶，将其他故障进行压缩，确保有效信息的最大化展示。3.4数据展示层在业务逻辑层基础之上，对业务逻辑加以展示，重点在于兼容性、扩展性和良好的界面。重点描述变更历史管理，无论从解决站址、设备的变更问题，还是成本合同的追溯问题，均能有的放矢。a）系统管理中的人员配置主要就是针对人员的部门、密码等信息进行管理，以及对角色的关联；角色管理则主要实现了人员信息与菜单页面以及菜单页面按钮的关联。系统管理就是实现人员关联角色、角色关联菜单页面、页面关

17、联按钮的功能。b）站址管理则关注于费用计价影响的站址信息子项和一线员工使用频率较高的站址配置，包含站址名称、站址的详细地址、站址编码、对应铁塔订单、对应铁塔编码、铁塔类型、铁塔子类型、铁塔共享信息、挂高、天线个数、机房类型、机房子类型、机房共享信息、配套类型、配套共享信息、原产权方、现产权方等。站址的新增需要管理员审核，变更则需要记录到历史信息库中进行备案。站址管理界面对于站址设备关联关系进行展示，关联和取消关联基本和站址的拆迁信息进行同步，而且关联动作需要进行管理员级别审核。c）设备管理关注设备层级的历史变化。设备信息从设备厂家的北向接口中同步以后，设备的历史变化需要历史信息记录，并且需要设

18、备管理员的审核批准，务必确保设备信息准确性，尤其是设备信息中的经度、纬度、工期信息。经纬度是系统定位最准确的依据，工期则可进行多重纬度的统计以及按照工期进行项目交付。设备定位拉取百度和高德的三方MAP接口，可以实现实时的设备定位和导航（苹果手机系统由于隐私设置必须在APP侧才能实现）。d）合同管理则关注于站址相关合同的概要信息，包括合同ID、合同名称、合同对应站址名称、合同起租日期、合同终止日期、合同年费用、合同牵扯电费单价、合同业主名称、合同业主类型、合同业主电话、合同续签类型、合同状态、合同支付方式、合同房租支付周期、合同电费支付周期、合同归属营业部、合同资产归属、合同实体ID等信息，提供

19、包含站址扩展、合同业主维系扩展、合同MSS系统扩展、费用信息扩展等多张信息接口。合同的增加同样需要审批，变更需要记录到历史信息库中。e）成本费用管理则主要依托于合同管理界面实现，类似于站址设备的关联关系，合同费用的关联关系需要依靠合同ID进行关联。房租、电费作为成本管控的基础类型，重点在于进度的把控和实时费用的合理性把控。通过成本费用管理，可有效解决这个问题，关键在于提供费用缴费信息的缴费开始日期、缴费结束日期、缴费含税信息、缴费费用等（电费包含电费的开始读数和结束读数）。f）统计分析功能主要通过后台的逻辑判断计算费用，例如营业部平均支出、站址平均支出、房租和电费的单项平均支出、房租电费的TO

20、P5等图形展示，以支撑费用单项管控。另外，通过对合同的支付周期进行管控，可以在成本费用的基础上再分析，实现房租、电费到期提醒，方便一线员工管控缴费进度，从而保证站址不会由于房租电费到期未支付而造成中断。g）告警分析功能主要针对告警进行表格、图例、指标稽核以及GIS辅助的展示。目前由于告警接口处于洽谈中，暂未实现，后期对此功能进行详细描述。3.5移动端展示层移动端站址层目前采用二维码+网页的轻APP形式试运行，效果良好。主要实现的功能包含站址查询、站址变更和设备查询功能。站址查询能够通过站址名称、站址归属营业部、站址状态等查询到目标站址的详细信息。站址变更则是在站址信息的基础上进行现场巡检拍照并

21、申请变更的功能，后台管理人员可以在网页端进行统一审核。设备查询则能够通过设备编码、名称、状态进行设备查询并定位，导航功能目前只能在安卓系统下实现（在网运行的服保系统目前也暂未支持苹果系统，所以暂未考虑升级）。3.6实现技术关于实现开源技术，众说纷纭，参考目前现有开源技术，建议编程语言采用JAVA（可跨平台、可移植、易扩展）。系统前端采用EasyUI框架，方便调用框架本身的菜单、树、表格、表单等既有插件，且支持移动端简易开发。后端采用JFinal框架，集成MVC程度更高，上手更方便。数据库采用Mysql，服务器端采用Nigix/Tomcat，流程采用Snaker。后续重构建议采用MVVM框架（V

22、UE/Angular等后续潜力较大的框架），集成效果更好，可使用的第三方插件更多，同样支持移动端开发，缺点是上手较慢，后台可进行扩展选取，采用SpringMVC/Jfinal框架，数据库/服务器/流程保持原有阵型。4结束语通过对网络站址运营管理平台的探索、设计和初步实现，基本完成对站址、设备达到颗粒度的精准管理功能，对合同、成本的单站站址精细管控功能，对基础资源进行历史变更管理功能，对成本费用的再分析（TOPN、到期提醒等），对站址设备的移动端进行展示功能等，在实际应用中已经产生数百万元实际应用价值。下一步考虑与铁塔账单的比对功能，从而进一步解放人工提高效率。另外，开源平台受限于时间、人力等因素开发进度稍慢，且告警数据量庞大，告警过滤分析规则需要深入探讨，接口正在同步中，计划下一步开发实现。第 12 页 共 12 页