移動網絡站址運營管理平臺的探索與實現

周 博，付 珂（中國電信股份有限公司鄭州分公司，河南鄭州450000）

0 前言

為了避免重復建設，國家成立鐵塔公司，但是資源共享率的提高與運營成本的上漲成為一對矛盾體，這也是運營商迫切需要解決的問題之一。目前，運營商內部專業化程度較高，著眼于移動網網絡管理，依托于各大廠商網管開發綜合性網管，方便維護人員使用，例如4G網管，在實際應用中能夠提供統一性的故障管控；著眼于資源管理，依托于集團以及各種系統接口，招標第三方開發統一資源管理平臺，囊括固網和移動網所有的機房和設備等；著眼于成本管控，依托于集團及省分企信部、財務部，建立統一MSS系統，對財務方面進行過程管控。但是，成本上升與利潤增長要求運營商運營必須向精細化轉型，而精細化的管控需要系統融合支撐，而目前的高度專業化造成融合起來比較困難。另外，鐵塔公司維護的日常督促、月度稽核、費用結算等需要運營商方面配置足夠的人員進行配合，運營商與鐵塔公司的維護及財務的對接問題和高額的鐵塔租賃費成為2個極點，促使精細化提上日程。如何實現網絡提質增效的同時做到費用明晰，是需要解決的首要問題，本文就此問題為根本，以實現移動網絡站址運營管理的精細化管控為目標，結合一線員工的實際應用需求，對站址運營進行深入探索，并通過開源技術進行初步實現，實際應用效果良好。

1 移動網絡站址現狀分析

鐵塔公司對運營商存量站點的接手和運營商新建站點需求的搜集，標志著運營商建造鐵塔時代的終結。運營商以往的一次性投入等價轉化為5～10年的租賃性支出，有利有弊暫且不論，在鐵塔共享時代確實是運營商與鐵塔公司雙贏的局面。移動網絡站址的精細化管控則是運營商控制成本和提升質量的切入口之一。

通過與運營商后臺維護人員與一線員工的訪談、收集調查表以及相關的場景分析，加上對各項系統的實際操控體驗，總結出如下亟待解決的問題。

a）站址和設備名稱變更。往往站址和設備名稱需要經歷設計、施工、監理、網管、網優、成本管控、一線維護等一系列相關人員經手維護，站址和設備名稱的混亂性可想而知。如何規范并有計劃地更新，都是必須要面臨的問題。

b）資源匹配一致性。資源系統的繁重眾所周知，以“有用”為前提的資源系統轉型尚需時日，如何拋開繁重的資源系統，化繁為簡，引入簡便快捷的網絡拓撲（例如什么站址、什么設備，什么配套），用以支撐精細化管控的資源基礎，是一個繞不開的話題。

c）成本單站址管控。MSS系統的集中上線解決了財務集中的問題，從采購申請、采購審批、立項、合同到最終的費用支付，均得以完善。但是如何從成本管控人員出發，面對單個站址，解決最實際的房租和電費的繳費問題，目前尚未提上日程。

d）成本數據再分析。成本費用進度管控在運營商財務制度里面是重中之重，時序進度是每年都繞不開的話題。但在計算成本求和的基礎上如何對成本數據再分析，提取出有價值的東西供成本預估、管控來使用，目前僅僅通過Excel進行匯總篩選。

e）告警稽核。不僅需要運營商內部進行指標管控，還需要與鐵塔進行接口對接管控。運營商關注BBU、RRU設備層級的告警，而鐵塔更專注于站址配套級別的告警，兩者的不統一需要稽核比對完成。稽核數據的核心就在于告警同步和站址設備關聯明細。

f）系統開發維護繁雜。運營商的運營系統，要么是大型軟件開發商的定制產品，要么是定制產品的唯一來源拓展，要么是定制產品的接口拓展，無論開發還是維護，起步幾十萬，動輒上百萬，系統“轉身”何其困難。

2 移動網絡站址運營探索

目前對站址的運營尚未有成型的理論和研究，本文拋磚引玉，針對搜集到的網絡站址現狀，結合一線員工的直面需求訪談以及相關調查表，從實際應用角度出發，以提質增效和成本管控為目標，探索構建站址運營管理平臺，下面以典型問題為突破口進行深入討論。

a）設備北向同步。為了精確描述設備，可以從設備網管的北向接口進行數據同步，每天凌晨進行FTP抓取，將設備網管中的前一天設備信息以設備編碼為唯一值同步到數據庫設備ODS庫中進行備份。設備存量庫與設備ODS庫最大的區別就是，ODS庫只是同步更新，而存量庫則作為源庫保留所有設備信息，尤其是設備名稱及狀態的變化，從而做到設備與其名稱、狀態的實時同步。

b）站址信息擴展。以鐵塔CRM為例，除記錄站址的名稱、編碼、地址、鐵塔信息、機房信息、配套信息、天線信息、掛高信息、共享信息外，還需要獲取更多，包含站址名稱的變化、設備與站址的對應關系、站址的業主詳細信息等。在站址信息表中進行數據庫擴展，為站址與名稱同步、站址與設備同步、站址與業主同步等多重擴展打下基礎。

c）變更歷史管理。傳統系統往往都不注重變更歷史，只關注最終狀態，而精細化管控必須要包含對歷史變更的管理。以站址和設備名稱變化為例，稽核過程中需要精確定位過程中的站址和設備的名稱以及對應關系，一方面以完善流程制度督促名稱統一，一方面需要用站址和設備名稱變化歷史來追溯過程。相關的費用管控、費用追溯、維護查詢等功能，都需要歷史變更功能進行輔助。

d）成本定位管控。合同簽訂原則上應以“一站址一合同”進行簽訂，但也不排除現實中的合并合同。但將合同定位到站址則是一把管理利器，以合同定位為基礎，進行房租電費費用的成本定位。從單站站址出發進行的定位，是精細化管控的前提，所以需要做好站址-合同-成本的對應體系。做好基礎的精細化管控，才能實現大成本的精確管控。

e）成本數據再分析。以單站站址出發進行定位，不僅僅是在現有的基礎數據上去核對單站站址的房租電費是否匹配站址、匹配合同、匹配設備等，而且需要關注單站站址的費用產出是否合理、是否能夠匹配整體的成本進度，進一步來說，利用數據提取完成類似到期提醒等其他更有意義更傾向于一線的功能，才能夠更好地支撐服務前端。

f）告警北向同步。告警同步不需要進行更改記錄，由于數據量太大，考慮使用周分析（或者每3天，后期調整）進行同步，需要設定告警歸并規則，以指標稽核為導向進行告警合并。原則上主要核定同站址配套退網的指標，兼顧設備離線告警，為維護人員定位故障、稽核指標進行支撐。

g）開源技術應用。現有系統的接口是必不可少的，畢竟數據本身已經被拉扯得四分五裂，但是可以從一統江湖的角度出發，構架開源式平臺，當然，需要構建合理安全體系。將上述接口進行匯總后，輔以安全接口，開放給“邊運營邊開發”的剛需人員進行維護，以開源技術為突破口，以框架為起步，以創建平臺為基礎，建立網絡站址運營管理平臺不失為解決方案之一。

3 移動網絡站址運營平臺的設計與初步實現

平臺著眼于實現網絡提質增效、費用清晰的目標，以上述突破口為抓手，分別設計基礎數據框架、數據接口、業務邏輯層、數據展示層、移動端展示層等5個層次。

3.1 基礎數據框架

包含設備ODS庫、數據庫以及鐵塔信息ODS庫，主要提供MVC模式中的數據MODEL。

a）設備ODS庫為設備網管北向同步的ODS庫，目前實現方法是每天由設備網管進行設備信息打包，ODS庫表直接從FTP上下載壓縮包，解壓后進行更新，以緩解設備網管負載和降低數據接口風險。技術為成熟方案，實踐證明不存在風險，但是個別情況下會出現解壓縮失敗的情況，需要設定程序進行執行結果通報。

b）鐵塔信息ODS庫為遠程抓取信息或者本地上傳信息來的ODS庫，目前遠程抓取接口在鐵塔對接運營商層面實現并不是非常穩定，暫時以下載后的EX?CEL進行再次上傳進行確認。

c）業務數據庫則包含人員配置、角色配置、菜單配置、站址基礎信息、設備基礎信息、合同基礎信息、成本繳費信息等基礎數據庫。需要單獨列出的是歷史信息數據庫，需要將基礎信息變更的歷史過程按照字段變更進行記錄，這樣才能方便前端的準確定位和查詢。

d）告警ODS庫主要為故障查詢和指標稽核進行告警備份。與設備網管的告警同步可以參照設備ODS庫實現方法。告警ODS庫從設備網管同步后，關鍵在于將繁多的設備故障進行合并歸檔，以設備中斷級別告警為主要告警，其余告警進行視圖聚合，將同一設備下的告警進行歸納后，在同一站址級別進行統一的展示，方便維護人員使用。同時，歸并后的告警方便用戶在告警稽核時進行甄別使用。

為了更好地描述融合關系，下面通過圖1對關聯關系進行闡述，其核心在于將多種基礎信息進行有機融合，從而建立完整的站址運營管理平臺，用最基礎的數據創造最有用的價值。

3.2 數據接口

a）設備北向同步在與設備廠商進行溝通后，通過接口文檔直接進行調用和讀取。頻率設定為每天凌晨進行一次同步，并通過程序記錄同步狀態。

b）鐵塔信息的數據接口通過鐵塔系統進行EX?CEL下載，下載后進行項目匹配，然后導入系統，進行鐵塔ODS數據庫更新。頻率設定為每周一次。

3.3 業務邏輯層

a）系統管理主要解決安全問題（可以在Spring MVC基礎上引入Spring Security），關注人員配置、菜單配置、角色管理等，后期可以實現用一點登錄的性質關聯OA等其他系統；通過將人員信息ID對應到角色管理上，再對應到菜單管理以及按鈕管理的方法，根據人員的維護權限細化人員系統管理權限，從而確保系統操作安全。

圖1 系統E-R簡圖

b）站址管理則主要從實際應用角度出發，以方便維護人員使用為第1前提，除了站址信息的常規增刪改之外，增加對站址的新增進行管理員級別的審核，保證站址信息庫的準確。

c）設備管理主要以網管設備為基準值，記錄對設備信息的變更情況。與站址管理類似的是，管理員層級需要對維護人員的設備變更信息進行審核，保證設備信息庫一致性。

d）站址設備關聯管理通過將站址的ID與設備的編碼ID進行關聯，從而確保對應關系的唯一性，一個站址可能包含多個設備，但是一個設備在同一時期只能對應一個站址，相對應的一個鐵塔訂單只能對應一個站址，但是可以對應多個設備，這也就解決了指標稽核中的指標定位問題。另外，這個邏輯關系也有助于維護人員對站址、告警的定位。同樣的，關聯關系的變化也需要進行管理員級別的審核。

e）成本管理中的合同管理主要通過站址ID與合同ID進行定位，一個站址只能對應一個合同，前期維護過程中出現的一個合同對應多個站址的情況予以限期消除，目前已經基本完成。成本管控人員需要對合同的建立進行確認，確保同MSS系統吻合。

f）成本管理中的費用主要通過合同ID將多個繳費信息ID進行關聯，確保繳費有根據，合同有詳單。一個合同對應多個費用信息，包含房租和電費，而一個費用信息在一個時期內只能對應一個合同。

g）歷史信息管理主要就是通過設計全局攔截器的方法，在邏輯層面實現對基礎信息變更時的信息記錄，確保記錄變化的字段名、字段原值、字段新值等信息，然后以時間（秒）為單位進行歸并，從而完成大到記錄，小到字段的歷史可追溯功能。

h）統計分析主要是以視圖聚合的形式實現，基礎數據的展示除了基礎管控，不能實現更高的含義和價值，通過存儲過程的方式進行后臺計算，將站址信息進行分門別類的匯總，將費用信息進行加權平均計算，最終生成圖表展示以及其他相關功能。財務的成本往往只要求賬期內進行保障結算即可，而我們還實現了分時間段將賬期內的費用按照正常發生的時間段進行平均計算，更有利于單個時間段的費用估算。

i）告警分析通過視圖進行聚合，將告警ODS庫進行歸納，將設定好的規則通過SQL進行實現，然后以視圖的形式替代數據表，為表現層提供支撐。設定規則將配套中斷級別故障和設備中斷級別故障進行置頂，將其他故障進行壓縮，確保有效信息的最大化展示。

3.4 數據展示層

在業務邏輯層基礎之上，對業務邏輯加以展示，重點在于兼容性、擴展性和良好的界面。重點描述變更歷史管理，無論從解決站址、設備的變更問題，還是成本合同的追溯問題，均能有的放矢。

a）系統管理中的人員配置主要就是針對人員的部門、密碼等信息進行管理，以及對角色的關聯；角色管理則主要實現了人員信息與菜單頁面以及菜單頁面按鈕的關聯。系統管理就是實現人員關聯角色、角色關聯菜單頁面、頁面關聯按鈕的功能。

b）站址管理則關注于費用計價影響的站址信息子項和一線員工使用頻率較高的站址配置，包含站址名稱、站址的詳細地址、站址編碼、對應鐵塔訂單、對應鐵塔編碼、鐵塔類型、鐵塔子類型、鐵塔共享信息、掛高、天線個數、機房類型、機房子類型、機房共享信息、配套類型、配套共享信息、原產權方、現產權方等。站址的新增需要管理員審核，變更則需要記錄到歷史信息庫中進行備案。站址管理界面對于站址設備關聯關系進行展示，關聯和取消關聯基本和站址的拆遷信息進行同步，而且關聯動作需要進行管理員級別審核。

c）設備管理關注設備層級的歷史變化。設備信息從設備廠家的北向接口中同步以后，設備的歷史變化需要歷史信息記錄，并且需要設備管理員的審核批準，務必確保設備信息準確性，尤其是設備信息中的經度、緯度、工期信息。經緯度是系統定位最準確的依據，工期則可進行多重緯度的統計以及按照工期進行項目交付。設備定位拉取百度和高德的三方MAP接口，可以實現實時的設備定位和導航（蘋果手機系統由于隱私設置必須在APP側才能實現）。

d）合同管理則關注于站址相關合同的概要信息，包括合同ID、合同名稱、合同對應站址名稱、合同起租日期、合同終止日期、合同年費用、合同牽扯電費單價、合同業主名稱、合同業主類型、合同業主電話、合同續簽類型、合同狀態、合同支付方式、合同房租支付周期、合同電費支付周期、合同歸屬營業部、合同資產歸屬、合同實體ID等信息，提供包含站址擴展、合同業主維系擴展、合同MSS系統擴展、費用信息擴展等多張信息接口。合同的增加同樣需要審批，變更需要記錄到歷史信息庫中。

e）成本費用管理則主要依托于合同管理界面實現，類似于站址設備的關聯關系，合同費用的關聯關系需要依靠合同ID進行關聯。房租、電費作為成本管控的基礎類型，重點在于進度的把控和實時費用的合理性把控。通過成本費用管理，可有效解決這個問題，關鍵在于提供費用繳費信息的繳費開始日期、繳費結束日期、繳費含稅信息、繳費費用等（電費包含電費的開始讀數和結束讀數）。

f）統計分析功能主要通過后臺的邏輯判斷計算費用，例如營業部平均支出、站址平均支出、房租和電費的單項平均支出、房租電費的TOP5等圖形展示，以支撐費用單項管控。另外，通過對合同的支付周期進行管控，可以在成本費用的基礎上再分析，實現房租、電費到期提醒，方便一線員工管控繳費進度，從而保證站址不會由于房租電費到期未支付而造成中斷。

g）告警分析功能主要針對告警進行表格、圖例、指標稽核以及GIS輔助的展示。目前由于告警接口處于洽談中，暫未實現，后期對此功能進行詳細描述。

3.5 移動端展示層

移動端站址層目前采用二維碼+網頁的輕APP形式試運行，效果良好。主要實現的功能包含站址查詢、站址變更和設備查詢功能。站址查詢能夠通過站址名稱、站址歸屬營業部、站址狀態等查詢到目標站址的詳細信息。站址變更則是在站址信息的基礎上進行現場巡檢拍照并申請變更的功能，后臺管理人員可以在網頁端進行統一審核。設備查詢則能夠通過設備編碼、名稱、狀態進行設備查詢并定位，導航功能目前只能在安卓系統下實現（在網運行的服保系統目前也暫未支持蘋果系統，所以暫未考慮升級）。

3.6 實現技術

關于實現開源技術，眾說紛紜，參考目前現有開源技術，建議編程語言采用JAVA（可跨平臺、可移植、易擴展）。系統前端采用EasyUI框架，方便調用框架本身的菜單、樹、表格、表單等既有插件，且支持移動端簡易開發。后端采用JFinal框架，集成MVC程度更高，上手更方便。數據庫采用Mysql，服務器端采用Nigix/Tomcat，流程采用 Snaker。

后續重構建議采用MVVM框架（VUE/Angular等后續潛力較大的框架），集成效果更好，可使用的第三方插件更多，同樣支持移動端開發，缺點是上手較慢，后臺可進行擴展選取，采用SpringMVC/Jfinal框架，數據庫/服務器/流程保持原有陣型。

4 結束語

通過對網絡站址運營管理平臺的探索、設計和初步實現，基本完成對站址、設備達到顆粒度的精準管理功能，對合同、成本的單站站址精細管控功能，對基礎資源進行歷史變更管理功能，對成本費用的再分析（TOPN、到期提醒等），對站址設備的移動端進行展示功能等，在實際應用中已經產生數百萬元實際應用價值。下一步考慮與鐵塔賬單的比對功能，從而進一步解放人工提高效率。另外，開源平臺受限于時間、人力等因素開發進度稍慢，且告警數據量龐大，告警過濾分析規則需要深入探討，接口正在同步中，計劃下一步開發實現。