面向集中監(jiān)控的智能化轉(zhuǎn)型探索

劉淦誠 張 笑 孫子琪

中國聯(lián)合網(wǎng)絡(luò)通信集團(tuán)有限公司江蘇省分公司

0 引言

近年來，為進(jìn)一步提高在新時(shí)期的核心競(jìng)爭(zhēng)力，各大運(yùn)營商都在逐步建立和完善以客戶為中心的集中化網(wǎng)絡(luò)運(yùn)行維護(hù)體系。而在這種體系中，監(jiān)控團(tuán)隊(duì)作為網(wǎng)絡(luò)運(yùn)維管理的眼睛、耳朵和嘴巴，其素質(zhì)能力的高低直接影響到運(yùn)維工作的質(zhì)量。

經(jīng)過多年的建設(shè)，中國聯(lián)通已建成OSS2.0系統(tǒng)。作為集中化運(yùn)營支撐系統(tǒng)，OSS2.0有力推動(dòng)了全國運(yùn)維工作的集約化改革。江蘇聯(lián)通在全國OSS2.0上線過程中進(jìn)行了大量的探索工作，尤其是在集中監(jiān)控的智能化轉(zhuǎn)型方面，在效能提升上實(shí)現(xiàn)了突破。

1 告警智能關(guān)聯(lián)

OSS2.0智能監(jiān)控系統(tǒng)通過一套平臺(tái)將各專業(yè)、各廠家數(shù)百套網(wǎng)管的告警統(tǒng)一整合，同時(shí)完成告警的標(biāo)準(zhǔn)化輸出，通過與工單系統(tǒng)對(duì)接，實(shí)現(xiàn)告警、故障的集中調(diào)度和管理。

統(tǒng)一平臺(tái)接入告警大大減少了監(jiān)控終端的數(shù)量，但帶來的直接問題就是單個(gè)終端告警的大量增加，值班員面對(duì)故障的判斷時(shí)間也同步增長，尤其是面對(duì)傳輸光纜中斷引起的多專業(yè)、多系統(tǒng)故障，瞬間涌出的告警很容易增加監(jiān)控員的壓力，產(chǎn)生人為原因的失誤或疏忽。因此，需要面向監(jiān)控人員增加智能支撐手段以提升工作效率。

1.1 關(guān)聯(lián)思路

監(jiān)控人員面臨的壓力大部分來自集中監(jiān)控后大量增加的告警量，同一個(gè)故障可能產(chǎn)生不同專業(yè)的告警，如果能夠?qū)⑼还收系乃懈婢M(jìn)行關(guān)聯(lián)整合，監(jiān)控員的問題也就迎刃而解了。因此本次研究主要面向同一故障的告警關(guān)聯(lián)、自動(dòng)定位和工單的自動(dòng)派發(fā)，提升故障產(chǎn)生初期的處理效率。

以最復(fù)雜的情況為例，某地市某條光纜故障，該光纜上承載了傳輸?shù)腟DH和IPRAN系統(tǒng)兩條光路（A-B，D-E），接入網(wǎng)的OLT至下聯(lián)分光器光路，數(shù)據(jù)網(wǎng)的裸纖業(yè)務(wù)。傳輸光路中斷引起支鏈（B/C/E）中斷，繼而引發(fā)支鏈上承載的2G/3G基站退服。

故障發(fā)生時(shí)各專業(yè)、各系統(tǒng)大量上報(bào)告警，系統(tǒng)能夠在告警發(fā)生后將上述影響系統(tǒng)產(chǎn)生的相關(guān)告警關(guān)聯(lián)，并生成工單。工單詳細(xì)描述現(xiàn)象：某時(shí)某光纜中斷，影響傳輸A-B、D-E中斷，無線B、C、E基站退服，數(shù)據(jù)網(wǎng)交換機(jī)X-X中斷，并派發(fā)至線路工程師處。

1.2 實(shí)施方案

多條告警建立關(guān)聯(lián)關(guān)系，首先是找到這些告警間的關(guān)聯(lián)點(diǎn)。關(guān)聯(lián)點(diǎn)根據(jù)告警網(wǎng)元的維度不同而相異，如同一網(wǎng)元的告警關(guān)聯(lián)點(diǎn)就是網(wǎng)元本身，同一廠家不同網(wǎng)元告警的關(guān)聯(lián)點(diǎn)就是廠家，同一專業(yè)不同系統(tǒng)間的關(guān)聯(lián)點(diǎn)就是專業(yè)，不同專業(yè)間的關(guān)聯(lián)點(diǎn)為資源系統(tǒng)內(nèi)的空間資源等等，本次研究根據(jù)以上關(guān)聯(lián)點(diǎn)建立了一套關(guān)聯(lián)體系，完成了不同故障的關(guān)聯(lián)關(guān)系。

其次，需要整合關(guān)聯(lián)關(guān)系，梳理關(guān)聯(lián)流程，建立關(guān)聯(lián)規(guī)則。關(guān)聯(lián)流程作為整個(gè)智能支撐手段中的核心模塊，需要實(shí)現(xiàn)與人工關(guān)聯(lián)相似的邏輯關(guān)系，因此可以以人工判斷過程為依據(jù)進(jìn)行逆向推理。在上例中，值班工程師的判斷流程如圖1所示。

圖1 值班工程師的判斷流程圖

在這個(gè)流程中，值班員針對(duì)無線、傳輸、接入網(wǎng)、數(shù)據(jù)網(wǎng)先進(jìn)行專業(yè)內(nèi)的告警關(guān)聯(lián)：無線依據(jù)發(fā)生告警的基站名稱，傳輸、接入網(wǎng)和數(shù)據(jù)網(wǎng)依據(jù)網(wǎng)管上的拓?fù)鋱D。專業(yè)內(nèi)關(guān)聯(lián)結(jié)束后，值班員通過查詢無線側(cè)的電路資料得出退服的基站均承載在發(fā)生中斷的傳輸網(wǎng)元上，實(shí)現(xiàn)了專業(yè)間的關(guān)聯(lián)。當(dāng)各專業(yè)工單都派發(fā)完畢后，維護(hù)界面通過查詢光纜纖芯資料，得出此3個(gè)工單為同一故障引起。

人工判斷定位流程繁瑣，大量信息容易遺漏引起誤判。本例中值班員用于關(guān)聯(lián)的關(guān)聯(lián)點(diǎn)，機(jī)房名稱、拓?fù)潢P(guān)系、電路路由均已錄入資源系統(tǒng)，因此，智能關(guān)聯(lián)即“萬事俱備，只欠規(guī)則”了。依照人工流程將智能規(guī)則分層實(shí)現(xiàn)，如圖2所示。

圖2 智能規(guī)則分層

（1）專業(yè)內(nèi)關(guān)聯(lián)

無線網(wǎng)：存在級(jí)聯(lián)關(guān)系的網(wǎng)元告警，如BSC-BTS、RNCNODEB、同一機(jī)房的基站等。

傳輸網(wǎng)：存在拓?fù)潢P(guān)系的網(wǎng)元告警；同一條光纜承載的拓?fù)涓婢?；存在因果關(guān)系的告警，如設(shè)備板卡類故障引起的光纜故障。

接入網(wǎng)：存在級(jí)聯(lián)關(guān)系的網(wǎng)元OLT-ONU。

動(dòng)環(huán)網(wǎng)：存在因果關(guān)系的告警，如停電-溫高等。

主要依靠電路路由和光纜纖芯資料。動(dòng)環(huán)網(wǎng)與其他專業(yè)間依據(jù)所在局房進(jìn)行關(guān)聯(lián)。

最后，整個(gè)智能支撐手段的最終實(shí)現(xiàn)環(huán)節(jié)，將已完成告警關(guān)聯(lián)的智能告警進(jìn)行工單派發(fā)：根據(jù)關(guān)聯(lián)的告警生成工單標(biāo)題，依據(jù)系統(tǒng)內(nèi)置的維護(hù)值班表，按照規(guī)定的派單時(shí)限要求完成派單動(dòng)作。

1.3 階段成果

智能關(guān)聯(lián)規(guī)則實(shí)現(xiàn)了全專業(yè)告警采集和跨專業(yè)告警關(guān)聯(lián)，對(duì)提高監(jiān)控效率發(fā)揮了重要的作用。一鍵派單功能使派發(fā)一張工單的時(shí)間由4分鐘下降為30秒，截至2021年4月自動(dòng)工單比例達(dá)到98.3%。

智能關(guān)聯(lián)支撐實(shí)施后，故障受理時(shí)長平均縮短了63%，公眾寬帶用戶障礙歷時(shí)改善了36%，大客戶專業(yè)故障歷時(shí)縮短了30%，標(biāo)準(zhǔn)告警工單壓縮比為1155：1，人均監(jiān)控基線從2085站提升到13559站，效率提升6倍，人員精簡比例達(dá)到70%以上。

2 基于機(jī)器學(xué)習(xí)的調(diào)度規(guī)則自優(yōu)化

目前很多故障在末梢到達(dá)現(xiàn)場(chǎng)前已恢復(fù)，導(dǎo)致末梢的人力、物力存在資源浪費(fèi)；再加上人工部署簡單，規(guī)則類似“一刀切”，無法根據(jù)不同故障自我適應(yīng)、自我調(diào)整，部署故障規(guī)則機(jī)器學(xué)習(xí)能實(shí)現(xiàn)根據(jù)歷史的故障恢復(fù)情況完成派單規(guī)則自行優(yōu)化，提升末梢故障單的質(zhì)量。

2.1 規(guī)則調(diào)度現(xiàn)狀

規(guī)則調(diào)度的現(xiàn)狀：（1）自行恢復(fù)故障比例組成不同。取2021年2月份告警及工單數(shù)據(jù)：日均740張工單派發(fā)至末梢一線人員，其中187張工單在20分鐘以內(nèi)恢復(fù)，272張工單3小時(shí)內(nèi)恢復(fù)，281張工單處理超過3小時(shí)。（2）故障派單規(guī)則配置不夠合理，無法精細(xì)設(shè)置單個(gè)故障的派單動(dòng)作，故障工單派單規(guī)則位于智能監(jiān)控系統(tǒng)的規(guī)則管理?xiàng)l目中。派單規(guī)則僅分為兩塊區(qū)域：一是告警過濾區(qū)——將需派單的告警通過條件設(shè)置過濾出來；二是派單參數(shù)區(qū)——設(shè)置需派單告警的派單時(shí)間段、時(shí)延以及動(dòng)作。

2.2 實(shí)施對(duì)策

智能監(jiān)控系統(tǒng)的派單規(guī)則首先通過告警過濾條件將需要派單的告警過濾出來，然后經(jīng)過設(shè)置好的派單時(shí)延后完成派單動(dòng)作。由于全網(wǎng)需派單的告警在數(shù)十萬級(jí)，不可能針對(duì)每一個(gè)告警設(shè)置對(duì)應(yīng)的派單時(shí)延，經(jīng)反復(fù)研究和對(duì)比后確認(rèn)了對(duì)策的應(yīng)用場(chǎng)景如下。

本工程采用理正巖土工程計(jì)算軟件，根據(jù)《建筑基坑支護(hù)技術(shù)規(guī)程》（JGJ120—2012）建議分析方法，對(duì)土釘內(nèi)部及外部穩(wěn)定性進(jìn)行計(jì)算分析。采用土釘墻做支護(hù)結(jié)構(gòu)，共設(shè)置7道土釘，地面超載按照15kPa考慮，計(jì)算模型如圖1。

（1）自學(xué)習(xí)規(guī)則應(yīng)用的范圍：所有需派單告警的派單時(shí)延。

（2）實(shí)現(xiàn)方式：通過分析歷史告警記錄表，分析出每一個(gè)告警對(duì)象的歷史恢復(fù)時(shí)間，確認(rèn)好相應(yīng)的數(shù)學(xué)模型，明確延時(shí)邏輯并在執(zhí)行派單動(dòng)作前將延時(shí)插入。如圖3所示。

圖3 自學(xué)習(xí)架構(gòu)

計(jì)算邏輯如下：

假設(shè)：T=最終派單時(shí)延。

T1=派單規(guī)則中定義的派單時(shí)延。

T2=當(dāng)前網(wǎng)元、當(dāng)前告警標(biāo)題對(duì)應(yīng)告警的恢復(fù)時(shí)長的歷史基線值。

T3=最大調(diào)整時(shí)長（可以在配置文件中進(jìn)行配置）。

算法：

如此可以實(shí)現(xiàn)所有告警的歷史恢復(fù)情況記錄，并在下次發(fā)生的時(shí)候參考?xì)v史恢復(fù)時(shí)間，并進(jìn)行相應(yīng)的動(dòng)作：如果歷史基線值在設(shè)置的派單規(guī)則時(shí)延后的指定閾值內(nèi)，則進(jìn)行相應(yīng)時(shí)延；如果歷史基線值較長，則不額外時(shí)延。

支撐數(shù)據(jù)來源于智能監(jiān)控系統(tǒng)告警表內(nèi)的告警對(duì)象，告警的清除時(shí)長。接著是確認(rèn)大數(shù)據(jù)的計(jì)算邏輯和規(guī)則參數(shù)，主要的調(diào)整是歷史基線值的取值和最大調(diào)整時(shí)長，最終確認(rèn)最大調(diào)整時(shí)長暫定為5分鐘，小于5分鐘的占比為44%，可同時(shí)兼顧故障及時(shí)性和降低問題單數(shù)量。在鞏固檢查的同時(shí)，增加一些預(yù)防措施，部署知識(shí)庫、數(shù)據(jù)流的運(yùn)行監(jiān)測(cè)程序，部署長時(shí)間沒有案例入庫的預(yù)警機(jī)制。

2.3 階段成果

通過SQL查詢繼續(xù)學(xué)習(xí)知識(shí)庫以及運(yùn)行結(jié)果庫，導(dǎo)出工單數(shù)據(jù)，進(jìn)行數(shù)據(jù)分析，實(shí)現(xiàn)了驗(yàn)證數(shù)據(jù)獲取。數(shù)據(jù)顯示，截至2021年5月31日，系統(tǒng)從日均220萬條告警中收集出177萬余個(gè)告警對(duì)象的故障知識(shí)庫，且仍在不斷豐富完善中。規(guī)則日均生效541次，減少工單97張，減少代維無效出勤70次，故障工單比由活動(dòng)前的1.55降低至1.3，提升了末梢的工作效率。

3 應(yīng)用互聯(lián)網(wǎng)化軟件實(shí)現(xiàn)調(diào)度智能化

在集中監(jiān)控的日常調(diào)度中，故障通報(bào)大量依賴人工在各類故障調(diào)度群內(nèi)通知，因人工紕漏在所難免，存在通知不及時(shí)、漏通知、無跟蹤、不升級(jí)等問題；尤其是在集中監(jiān)控以后，多崗位合并不可避免地增加了監(jiān)控人員工作量，在故障高發(fā)時(shí)工作人員出現(xiàn)手忙腳亂、無暇通知的情況，調(diào)度效能亟待改善。

3.1 故障調(diào)度痛點(diǎn)

2020年3-9月月均各類故障量超過2萬條，全部依賴值班人員人工報(bào)送、跟蹤。故障受理及時(shí)率在95%以下，故障響應(yīng)不及時(shí)，影響了故障處理時(shí)長。一線代維故障及時(shí)受理率均在94%以下，平均受理時(shí)長在40分鐘左右。故障受理需要有效提醒機(jī)制，督促故障受理、處理。

3.2 實(shí)施方案

在全面分析OSS2.0系統(tǒng)架構(gòu)的基礎(chǔ)上，首先確定解決方案的系統(tǒng)架構(gòu)，如圖4所示。

圖4 智能調(diào)度架構(gòu)

主要涉及三個(gè)部分：

（1）信息源：要進(jìn)行自動(dòng)通報(bào)的故障數(shù)據(jù)來源。信息源取集團(tuán)OSS2.0智能監(jiān)控系統(tǒng)的告警及短信分發(fā)模塊。

（2）信息處理平臺(tái)：方案中核心的組件將獲取到的調(diào)度信息處理，并在信息發(fā)布平臺(tái)中呈現(xiàn)。

信息處理平臺(tái)前端采用AdminLTE2+Bootstrap3框架。目前Bootstrap是最流行的前端框架，比較成熟，在大量的項(xiàng)目中有充分的使用和測(cè)試，AdminLTE的加入更補(bǔ)充了后臺(tái)模板和組件的豐富性。兩者結(jié)合可以很好互補(bǔ)，完成信息處理和推送功能。

系統(tǒng)后臺(tái)使用JAVA語言開發(fā)，因此采用了經(jīng)典的SpringMVC+Spring+Hibernate的開發(fā)方式，并使用了Redis緩存組件臨時(shí)存儲(chǔ)消息隊(duì)列，提高性能。

（3）信息發(fā)布平臺(tái)：故障通報(bào)最終呈現(xiàn)的平臺(tái)

主流即時(shí)通信方式QQ和微信因?yàn)闊o對(duì)外開放接口，開發(fā)難度極大，無法滿足要求；傳統(tǒng)通信方式無論是短信還是電話，都有其局限性，且管控較為困難，也被放棄；而釘釘平臺(tái)，優(yōu)點(diǎn)明顯，且缺點(diǎn)容易克服，因此信息發(fā)布平臺(tái)選定為釘釘。

智能監(jiān)控將調(diào)度信息通過WebSerivce接口推送至江蘇省端的智能調(diào)度機(jī)器人，智能調(diào)度機(jī)器人通過群發(fā)服務(wù)，根據(jù)發(fā)布規(guī)則調(diào)用API接口后推送至對(duì)應(yīng)釘釘群，如圖5所示。

圖5 智能調(diào)度接口

3.3 階段成果

截至2021年5月7日，智能故障信息調(diào)度機(jī)器人已在全省部署完畢并正式生效，累計(jì)部署63個(gè)故障調(diào)度群，共計(jì)103條調(diào)度規(guī)則，每日通報(bào)故障538條，為值班人員節(jié)省工作量約5分鐘/條，累計(jì)節(jié)省工作時(shí)長2690分鐘/日，可節(jié)省每天2人的工作量，監(jiān)控效率提升33%，全年節(jié)約人力成本17.5萬元。全省故障受理率為98.4%，受理時(shí)長為17.2分鐘，提升整體故障處理效率約7%，帶來間接經(jīng)濟(jì)收益為28萬元。

4 結(jié)束語

目前智能化轉(zhuǎn)型正在各行各業(yè)普遍開展，江蘇聯(lián)通通過探索故障告警的自動(dòng)化關(guān)聯(lián)提升了故障發(fā)現(xiàn)效率；引入機(jī)器學(xué)習(xí)實(shí)現(xiàn)了故障調(diào)度規(guī)則的自動(dòng)優(yōu)化，避免了規(guī)則“一刀切“現(xiàn)象，降低了無效冗余調(diào)度；對(duì)接釘釘機(jī)器人Webhook接口，完成了調(diào)度的精準(zhǔn)性提升。該技術(shù)的應(yīng)用，大幅提高了人員的工作效能，實(shí)際效果喜人，只要能在網(wǎng)絡(luò)AI上繼續(xù)探索，相信“網(wǎng)絡(luò)高度自治”終將實(shí)現(xiàn)。