移動網(wǎng)絡(luò)站址運(yùn)營管理平臺的探索與實現(xiàn)

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

0 前言

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

1 移動網(wǎng)絡(luò)站址現(xiàn)狀分析

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

通過與運(yùn)營商后臺維護(hù)人員與一線員工的訪談、收集調(diào)查表以及相關(guān)的場景分析，加上對各項系統(tǒng)的實際操控體驗，總結(jié)出如下亟待解決的問題。

a）站址和設(shè)備名稱變更。往往站址和設(shè)備名稱需要經(jīng)歷設(shè)計、施工、監(jiān)理、網(wǎng)管、網(wǎng)優(yōu)、成本管控、一線維護(hù)等一系列相關(guān)人員經(jīng)手維護(hù)，站址和設(shè)備名稱的混亂性可想而知。如何規(guī)范并有計劃地更新，都是必須要面臨的問題。

b）資源匹配一致性。資源系統(tǒng)的繁重眾所周知，以“有用”為前提的資源系統(tǒng)轉(zhuǎn)型尚需時日，如何拋開繁重的資源系統(tǒng)，化繁為簡，引入簡便快捷的網(wǎng)絡(luò)拓?fù)洌ɡ缡裁凑局?、什么設(shè)備，什么配套），用以支撐精細(xì)化管控的資源基礎(chǔ)，是一個繞不開的話題。

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

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

e）告警稽核。不僅需要運(yùn)營商內(nèi)部進(jìn)行指標(biāo)管控，還需要與鐵塔進(jìn)行接口對接管控。運(yùn)營商關(guān)注BBU、RRU設(shè)備層級的告警，而鐵塔更專注于站址配套級別的告警，兩者的不統(tǒng)一需要稽核比對完成。稽核數(shù)據(jù)的核心就在于告警同步和站址設(shè)備關(guān)聯(lián)明細(xì)。

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

2 移動網(wǎng)絡(luò)站址運(yùn)營探索

目前對站址的運(yùn)營尚未有成型的理論和研究，本文拋磚引玉，針對搜集到的網(wǎng)絡(luò)站址現(xiàn)狀，結(jié)合一線員工的直面需求訪談以及相關(guān)調(diào)查表，從實際應(yīng)用角度出發(fā)，以提質(zhì)增效和成本管控為目標(biāo)，探索構(gòu)建站址運(yùn)營管理平臺，下面以典型問題為突破口進(jìn)行深入討論。

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

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

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

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

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

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

g）開源技術(shù)應(yīng)用?，F(xiàn)有系統(tǒng)的接口是必不可少的，畢竟數(shù)據(jù)本身已經(jīng)被拉扯得四分五裂，但是可以從一統(tǒng)江湖的角度出發(fā)，構(gòu)架開源式平臺，當(dāng)然，需要構(gòu)建合理安全體系。將上述接口進(jìn)行匯總后，輔以安全接口，開放給“邊運(yùn)營邊開發(fā)”的剛需人員進(jìn)行維護(hù)，以開源技術(shù)為突破口，以框架為起步，以創(chuàng)建平臺為基礎(chǔ)，建立網(wǎng)絡(luò)站址運(yùn)營管理平臺不失為解決方案之一。

3 移動網(wǎng)絡(luò)站址運(yùn)營平臺的設(shè)計與初步實現(xiàn)

平臺著眼于實現(xiàn)網(wǎng)絡(luò)提質(zhì)增效、費(fèi)用清晰的目標(biāo)，以上述突破口為抓手，分別設(shè)計基礎(chǔ)數(shù)據(jù)框架、數(shù)據(jù)接口、業(yè)務(wù)邏輯層、數(shù)據(jù)展示層、移動端展示層等5個層次。

3.1 基礎(chǔ)數(shù)據(jù)框架

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

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

b）鐵塔信息ODS庫為遠(yuǎn)程抓取信息或者本地上傳信息來的ODS庫，目前遠(yuǎn)程抓取接口在鐵塔對接運(yùn)營商層面實現(xiàn)并不是非常穩(wěn)定，暫時以下載后的EX?CEL進(jìn)行再次上傳進(jìn)行確認(rèn)。

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

d）告警ODS庫主要為故障查詢和指標(biāo)稽核進(jìn)行告警備份。與設(shè)備網(wǎng)管的告警同步可以參照設(shè)備ODS庫實現(xiàn)方法。告警ODS庫從設(shè)備網(wǎng)管同步后，關(guān)鍵在于將繁多的設(shè)備故障進(jìn)行合并歸檔，以設(shè)備中斷級別告警為主要告警，其余告警進(jìn)行視圖聚合，將同一設(shè)備下的告警進(jìn)行歸納后，在同一站址級別進(jìn)行統(tǒng)一的展示，方便維護(hù)人員使用。同時，歸并后的告警方便用戶在告警稽核時進(jìn)行甄別使用。

為了更好地描述融合關(guān)系，下面通過圖1對關(guān)聯(lián)關(guān)系進(jìn)行闡述，其核心在于將多種基礎(chǔ)信息進(jìn)行有機(jī)融合，從而建立完整的站址運(yùn)營管理平臺，用最基礎(chǔ)的數(shù)據(jù)創(chuàng)造最有用的價值。

3.2 數(shù)據(jù)接口

a）設(shè)備北向同步在與設(shè)備廠商進(jìn)行溝通后，通過接口文檔直接進(jìn)行調(diào)用和讀取。頻率設(shè)定為每天凌晨進(jìn)行一次同步，并通過程序記錄同步狀態(tài)。

b）鐵塔信息的數(shù)據(jù)接口通過鐵塔系統(tǒng)進(jìn)行EX?CEL下載，下載后進(jìn)行項目匹配，然后導(dǎo)入系統(tǒng)，進(jìn)行鐵塔ODS數(shù)據(jù)庫更新。頻率設(shè)定為每周一次。

3.3 業(yè)務(wù)邏輯層

a）系統(tǒng)管理主要解決安全問題（可以在Spring MVC基礎(chǔ)上引入Spring Security），關(guān)注人員配置、菜單配置、角色管理等，后期可以實現(xiàn)用一點登錄的性質(zhì)關(guān)聯(lián)OA等其他系統(tǒng)；通過將人員信息ID對應(yīng)到角色管理上，再對應(yīng)到菜單管理以及按鈕管理的方法，根據(jù)人員的維護(hù)權(quán)限細(xì)化人員系統(tǒng)管理權(quán)限，從而確保系統(tǒng)操作安全。

圖1 系統(tǒng)E-R簡圖

b）站址管理則主要從實際應(yīng)用角度出發(fā)，以方便維護(hù)人員使用為第1前提，除了站址信息的常規(guī)增刪改之外，增加對站址的新增進(jìn)行管理員級別的審核，保證站址信息庫的準(zhǔn)確。

c）設(shè)備管理主要以網(wǎng)管設(shè)備為基準(zhǔn)值，記錄對設(shè)備信息的變更情況。與站址管理類似的是，管理員層級需要對維護(hù)人員的設(shè)備變更信息進(jìn)行審核，保證設(shè)備信息庫一致性。

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

e）成本管理中的合同管理主要通過站址ID與合同ID進(jìn)行定位，一個站址只能對應(yīng)一個合同，前期維護(hù)過程中出現(xiàn)的一個合同對應(yīng)多個站址的情況予以限期消除，目前已經(jīng)基本完成。成本管控人員需要對合同的建立進(jìn)行確認(rèn)，確保同MSS系統(tǒng)吻合。

f）成本管理中的費(fèi)用主要通過合同ID將多個繳費(fèi)信息ID進(jìn)行關(guān)聯(lián)，確保繳費(fèi)有根據(jù)，合同有詳單。一個合同對應(yīng)多個費(fèi)用信息，包含房租和電費(fèi)，而一個費(fèi)用信息在一個時期內(nèi)只能對應(yīng)一個合同。

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

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

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

3.4 數(shù)據(jù)展示層

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

a）系統(tǒng)管理中的人員配置主要就是針對人員的部門、密碼等信息進(jìn)行管理，以及對角色的關(guān)聯(lián)；角色管理則主要實現(xiàn)了人員信息與菜單頁面以及菜單頁面按鈕的關(guān)聯(lián)。系統(tǒng)管理就是實現(xiàn)人員關(guān)聯(lián)角色、角色關(guān)聯(lián)菜單頁面、頁面關(guān)聯(lián)按鈕的功能。

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

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

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

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

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

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

3.5 移動端展示層

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

3.6 實現(xiàn)技術(shù)

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

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

4 結(jié)束語

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