本文經(jīng)《郵電設(shè)計技術(shù)》授權(quán)發(fā)布

如需要轉(zhuǎn)載，請聯(lián)系《郵電設(shè)計技術(shù)》獲取授權(quán)

郵電設(shè)計技術(shù)公眾號：ydsjjs，歡迎關(guān)注！

摘要：重點探討了人工智能在通信網(wǎng)絡(luò)故障溯源方面的應(yīng)用研究和相關(guān)案例。首先介紹了目前網(wǎng)絡(luò)運維的現(xiàn)狀和國內(nèi)外研究進展，結(jié)合通信網(wǎng)絡(luò)運維中的實際業(yè)務(wù)和問題總結(jié)了多個應(yīng)用場景，并針對所有場景提出了故障溯源整體解決方案。最后重點分析了中國聯(lián)通IPRAN網(wǎng)絡(luò)告警根因案例。該案例的實踐效果說明了人工智能應(yīng)用到網(wǎng)絡(luò)運維中可以幫助運維人員快速定位根告警和故障源，提高運維效率。

概述

全球運營商相繼發(fā)布網(wǎng)絡(luò)演進和轉(zhuǎn)型戰(zhàn)略，希望能夠通過引入 SDN/NFV、云計算、區(qū)塊鏈、5G 等新技術(shù)，減少對專有硬件的依賴，實現(xiàn)新業(yè)務(wù)的快速部署，滿足用戶多樣化的需求，提升核心競爭力。但在轉(zhuǎn)型過程中通信運營商面臨著多種挑戰(zhàn)，一方面是聯(lián)網(wǎng)設(shè)備數(shù)量快速增長以及設(shè)備之間溝通產(chǎn)生的數(shù)據(jù)洪流，另一方面是隨著電信網(wǎng)絡(luò)設(shè)備日趨虛擬化、自動化和智能化，網(wǎng)絡(luò)復(fù)雜度指數(shù)型增長。這些挑戰(zhàn)無疑使網(wǎng)絡(luò)運維變得日益繁雜和困難，運維人員一方面必須面對各種高度集成設(shè)備產(chǎn)生的大量實時信息，另一方面需要處理海量的告警數(shù)據(jù)，并且為了不降低用戶感知，需要快速解決問題。現(xiàn)有的系統(tǒng)已經(jīng)無法在異常狀況發(fā)生時為運維人員提供足夠的支持，導(dǎo)致許多問題不能被及時發(fā)現(xiàn)而不斷傳播升級，直至影響所有業(yè)務(wù)。如果發(fā)生異常告警時需要花費大量時間去尋找問題根源及解決辦法，那么即使是細微的問題也會迅速地升級擴大。

人工智能（AI）的發(fā)展可追溯到 1956 年達特茅斯會議（Dartmouth Conference）［1］。人工智能可以定義為機器能夠?qū)崿F(xiàn)的智能，是與人類和其他動物表現(xiàn)出的人類智能和自然智能相對的概念。也可引用“人工智能之父”Marvin Minsky對人工智能的理解來定義它—“人工智能就是讓機器來完成那些如果由人來做則需要智能的事情的科學(xué)”。網(wǎng)絡(luò)人工智能（Network AI）［2］是將人工智能技術(shù)應(yīng)用在網(wǎng)絡(luò)中，使用機器替代或優(yōu)化目前依靠人工進行的工作，使運營商能夠更加便捷地提供更加優(yōu)質(zhì)的網(wǎng)絡(luò)服務(wù)。

本文以人工智能技術(shù)為基礎(chǔ)，結(jié)合現(xiàn)有網(wǎng)絡(luò)運維技術(shù)，提出故障溯源整體解決方案。希望通過對告警信息進行合適的過濾、篩選、匹配、分類等流程確認告警信息，并根據(jù)各個告警之間的關(guān)系來進行告警溯源，屏蔽不重要或衍生的告警，實現(xiàn)對網(wǎng)絡(luò)故障的快速診斷。同時配合相應(yīng)的通信業(yè)務(wù)模型和網(wǎng)絡(luò)拓撲結(jié)構(gòu)實現(xiàn)故障的精準(zhǔn)定位。最后通過實踐中的具體案例分析，給出人工智能應(yīng)用于網(wǎng)絡(luò)故障溯源的結(jié)論和展望。

國內(nèi)外研究現(xiàn)狀

著名的 IT研究與顧問咨詢公司 Gartner在 2016年提出 AIOps（Artificial Intelligence for IT Operations）的概念［3］，即通過人工智能的方式來支撐現(xiàn)在日益復(fù)雜的運維工作。AIOps 可以在深度集成 DevOps 工具鏈的基礎(chǔ)上獲取系統(tǒng)數(shù)據(jù)，然后通過機器學(xué)習(xí)算法進行數(shù)據(jù)分析，更深度地解析數(shù)據(jù)中所蘊藏的運維信息。Gartner的報告指出預(yù)計到2020年，50%的企業(yè)將會在他們的業(yè)務(wù)和 IT 運維方面采用 AIOps，遠超現(xiàn)在的10%。同時，國內(nèi)外各大公司如AT&T、Microsoft、Facebook、百度、阿里巴巴等都在他們的運維系統(tǒng)中實驗或部署了機器學(xué)習(xí)算法，助力某些運維任務(wù)智能化。

華為諾亞方舟實驗室開發(fā)了智能故障診斷系統(tǒng)，利用網(wǎng)絡(luò)故障的歷史記錄數(shù)據(jù)自動構(gòu)建通信領(lǐng)域知識圖譜［4］，并在知識圖譜上進行概率推理，以自動問答的形式幫助工程師找出故障的根本原因。微軟分別在會議NSDI’09和SIGCOMM’16發(fā)表了2篇基于機器學(xué)習(xí)的故障檢測系統(tǒng)的論文［5-6］。其中，2009 年發(fā)表的論文中提到針對家庭網(wǎng)絡(luò)配置問題診斷的NetPrints系統(tǒng)。該系統(tǒng)通過學(xué)習(xí)明確針對應(yīng)用的正確配置，在用戶的某個應(yīng)用發(fā)生錯誤時，可以通過檢測用戶的配置來為用戶選擇一個最小代價的調(diào)整策略恢復(fù)應(yīng)用工作。同時，由于系統(tǒng)的特殊設(shè)計，一些系統(tǒng)原本無法解決的問題可以通過用戶的協(xié)作更新到診斷系統(tǒng)中，實現(xiàn)了用戶間的知識共享，提高系統(tǒng)的可用性。

2016年微軟發(fā)表的論文中提到針對微軟數(shù)據(jù)中心的錯誤定位問題的 NetPoirot 系統(tǒng)。該系統(tǒng)僅通過觀察主機側(cè)的 TCP數(shù)據(jù)就可以定位故障的發(fā)生位置，并且對于未訓(xùn)練過的錯誤也具有很高的故障位置識別率。但是，該系統(tǒng)只能診斷發(fā)生在主機、網(wǎng)絡(luò)或服務(wù)器中的錯誤，無法精確地定位到設(shè)備也很難精確定位具體錯誤。針對移動設(shè)備的視頻傳輸問題，加泰羅尼亞理工大學(xué)的研究者在 2015 年的 CoNEXT 上提出了解決方案［7］。該方案通過收集和處理服務(wù)中部分位置的設(shè)備數(shù)據(jù)，可實現(xiàn)視頻流QoE的預(yù)測和故障定位。

故障溯源相關(guān)應(yīng)用場景研究

結(jié)合電信網(wǎng)絡(luò)的實際業(yè)務(wù)場景，剖析運維過程中的實際問題，更有益于將最新的AI技術(shù)運用到電信網(wǎng)絡(luò)的運維和故障溯源中去，從而提升運維人員的運維效率和運維體驗。目前典型的業(yè)務(wù)場景有以下幾個。

3.1 場景1：瞬斷告警

瞬斷告警定義為告警的發(fā)生時間和清除時間很短，小于一定的閾值。這類告警因為生命周期比較短，對運維人員沒有太大的價值，而且會導(dǎo)致告警量激增，從而掩蓋真正需要關(guān)注的告警，增加運維人員識別難度。

3.2 場景2：頻發(fā)告警

如果一定時間內(nèi)發(fā)生的相同告警/事件達到一定的數(shù)目，可以認為這些告警/事件之間存在一定的相關(guān)性。通過設(shè)置告警/事件頻次分析規(guī)則，當(dāng)某一段時間內(nèi)發(fā)生的設(shè)定告警/事件的數(shù)目超過了預(yù)先設(shè)置的閾值，則認為這些告警/事件之間存在相關(guān)性。如同一網(wǎng)元同一單板的單板溫度過高或過低告警X分鐘出現(xiàn)Y次，合并生成一條新告警，說明單板溫度異常。

3.3 場景3：同網(wǎng)元內(nèi)故障影響分析

指同一網(wǎng)元內(nèi)某物理對象（單板、拓撲）上產(chǎn)生告警會導(dǎo)致該網(wǎng)元上其他物理對象和邏輯對象產(chǎn)生關(guān)聯(lián)告警。

對于LTE設(shè)備，基站內(nèi)單板之間以及單板和小區(qū)（邏輯對象）存在關(guān)聯(lián)特性，因此單板故障往往會導(dǎo)致小區(qū)也存在異常。如圖1所示，4槽BPN出現(xiàn)“光模塊不可用告警”時，會導(dǎo)致51號RRU產(chǎn)生“RRU 斷鏈告警”，而承載在該RRU上的小區(qū)也會上報“LTE小區(qū)退服告警”，即“光模塊不可用告警”為根告警。

▲ 圖1 某同網(wǎng)元內(nèi)故障示意圖

3.4 場景4：同專業(yè)網(wǎng)上下層業(yè)務(wù)故障影響分析

該場景體現(xiàn)為因為某一個故障導(dǎo)致大面積告警的現(xiàn)象，需要快速地獲取故障原因。如圖2所示，服務(wù)層告警會導(dǎo)致客戶層告警的發(fā)生，如光纖出現(xiàn)斷點，光纖所在端口會報LOS告警，導(dǎo)致上層的 TMS、隧道、偽線、業(yè)務(wù)都上報告警，此時光纖所在端口的LOS告警就是根告警。

▲ 圖2 某同專業(yè)網(wǎng)上下層業(yè)務(wù)故障示意圖

3.5 場景5：跨專業(yè)網(wǎng)告警分析

傳輸包括光傳輸和微波傳輸，光傳輸節(jié)點會下掛很多微波節(jié)點，當(dāng)一個鏈路中斷會影響這條鏈路上的1個或多個站點，光傳輸節(jié)點斷開導(dǎo)致所有下游的微波 BTS站點都會退服，中間微波某一跳斷也會導(dǎo)致下游所有BTS退服（見圖3）。

▲ 圖3 某跨專業(yè)網(wǎng)故障示意圖

3.6 場景6：綜合故障診斷

故障的表現(xiàn)具有多樣性，可能表現(xiàn)為告警、KPI異常或單純業(yè)務(wù)不通，很多情況下告警并不能反映所有的故障點，所以也無法僅通過告警分析來定位故障。

比如網(wǎng)絡(luò)升級后，某LTE業(yè)務(wù)不通，如圖4所示的流程，根據(jù)經(jīng)驗，查看監(jiān)控數(shù)據(jù)，進行各種診斷動作和配置檢查，從而定位故障點，告警只是分析的一部分。

▲ 圖4 某綜合故障分析過程流程圖

通信網(wǎng)絡(luò)故障溯源整體解決方案研究

第3章所述業(yè)務(wù)場景要解決的問題就是如何智能地識別故障并做有效分析，故障分析模型是基于關(guān)聯(lián)規(guī)則，而關(guān)聯(lián)規(guī)則通常使用關(guān)聯(lián)分析算法得到。

關(guān)聯(lián)規(guī)則算法是從一個數(shù)據(jù)集中發(fā)現(xiàn)項與項之間的隱藏關(guān)系。只有從多個不同的維度分析告警數(shù)據(jù)，才能識別出它們之間的關(guān)聯(lián)關(guān)系，如告警發(fā)生的模式或規(guī)律。

基于人工智能的故障診斷和溯源就是在結(jié)合大數(shù)據(jù)關(guān)聯(lián)規(guī)則分析及人工智能技術(shù)的基礎(chǔ)上，根據(jù)系統(tǒng)中的網(wǎng)絡(luò)、業(yè)務(wù)上下游關(guān)系，綜合所有監(jiān)控數(shù)據(jù)（包括告警、性能）、操作日志以及故障解決歷史記錄，輸出故障特征與故障原因之間的一系列規(guī)則。本方案旨在采用人工智能和大數(shù)據(jù)挖掘技術(shù)，研究開發(fā)智能故障診斷系統(tǒng)（見圖 5）。在實際網(wǎng)絡(luò)運維中，根據(jù)故障特征自動匹配診斷規(guī)則進行診斷，自動得出故障點及相關(guān)處理建議。

▲ 圖5 智能故障診斷系統(tǒng)示意圖

本文所提出的智能故障診斷系統(tǒng)要先基于AI學(xué)習(xí)生成診斷規(guī)則庫，然后根據(jù)規(guī)則進行故障分析。

4.1 基于AI學(xué)習(xí)生成診斷規(guī)則庫

4.1.1 診斷信息獲取

診斷信息越豐富，診斷效果越好，所以系統(tǒng)應(yīng)具有自動獲取整個周期（當(dāng)前、歷史）的網(wǎng)絡(luò)狀態(tài)信息的功能。即在現(xiàn)網(wǎng)運行中，除了記錄操作日志、告警、KPI、故障處理建議這種日常監(jiān)控數(shù)據(jù)外，對于網(wǎng)絡(luò)拓撲、業(yè)務(wù)配置、業(yè)務(wù)狀態(tài)這些只記錄當(dāng)前狀態(tài)的數(shù)據(jù)，也要定時采樣，作為學(xué)習(xí)的素材。

4.1.2 建立自學(xué)習(xí)能力

提取故障特征，比如PWE3-CES的包丟失表示2G業(yè)務(wù)不通，分析其附近的KPI、操作日志、丟包情況、業(yè)務(wù)配置，業(yè)務(wù)狀態(tài)等信息，獲取故障特征。此處可使用數(shù)據(jù)降維，分類算法。

根據(jù)故障產(chǎn)生與消失這段時間的操作日志、故障文字記錄、其他告警的產(chǎn)生消失情況等相關(guān)數(shù)據(jù)，分析原因。此處可使用關(guān)聯(lián)算法、深度學(xué)習(xí)算法。

分析足夠多的案例，得到所有可能的原因，并計算原因概率。此處可使用概率論的相關(guān)算法。

4.2 診斷規(guī)則的運行

現(xiàn)網(wǎng)監(jiān)控：實時監(jiān)控告警，并且對流量、丟包情況定時采樣，并記錄操作日志。

匹配故障特征，進行故障診斷：對現(xiàn)網(wǎng)監(jiān)控數(shù)據(jù)實時進行匹配，一旦匹配成功，立即開始診斷。將故障的原因按概率從大到小排序，逐個診斷，當(dāng)確認某個原因存在時，就可以定位故障并給出處理建議。

故障修復(fù)確認，反向修正診斷規(guī)則庫：故障在自動恢復(fù)或派單修復(fù)后，反饋派單中原因是否有效，修正診斷規(guī)則庫的原因概率。

相比傳統(tǒng)的故障溯源方案，本方案結(jié)合運維中的多種數(shù)據(jù)源，包括并不限于告警、性能、拓撲資源、日志以及偵測命令，這使本方案溯源結(jié)果更加精確，并且更具有可參考性。

中國聯(lián)通IPRAN告警智能化分析識別

5.1 案例背景和目的

IPRAN網(wǎng)絡(luò)主要用于承載3G/4G移動業(yè)務(wù)以及大客戶專線業(yè)務(wù)，主要采用IP/MPLS動態(tài)協(xié)議技術(shù)。IP RAN網(wǎng)絡(luò)協(xié)議以及網(wǎng)絡(luò)的邏輯連接的復(fù)雜性，使IP RAN網(wǎng)管系統(tǒng)每天接收到大量的設(shè)備告警消息，其中很多告警信息都是由根源告警信息引起。

目前處理告警數(shù)據(jù)的相關(guān)規(guī)則多依賴于專家經(jīng)驗，通過規(guī)則過濾掉不關(guān)鍵的告警信息。這種方法的缺點是過濾能力有限且有些規(guī)則無法被發(fā)現(xiàn)。

因此需要將人工智能技術(shù)應(yīng)用于IPRAN網(wǎng)絡(luò)告警根因溯源中，形成更高效的告警處理方法。

5.2 方案和效果分析

故障是產(chǎn)生告警的根本原因，當(dāng)網(wǎng)絡(luò)發(fā)生故障時，將產(chǎn)生大量告警，挖掘告警之間的關(guān)聯(lián)規(guī)則對故障定位有著重要意義。總體方案思路如圖6所示。

▲ 圖6 告警根因溯源技術(shù)方案流程圖

該方案流程總體可分為以下4個步驟。

a）數(shù)據(jù)預(yù)處理階段，包括數(shù)據(jù)導(dǎo)入和清洗、用戶端側(cè)告警匹配、頻發(fā)告警識別。輸入數(shù)據(jù)為現(xiàn)網(wǎng)提取的歷史告警數(shù)據(jù)、網(wǎng)絡(luò)拓撲數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)3種，經(jīng)過清洗和整合轉(zhuǎn)變?yōu)榭商幚淼臄?shù)據(jù)格式。用戶端側(cè)告警匹配是根據(jù)以往運維經(jīng)驗去除不關(guān)心/無價值的告警。頻發(fā)告警的具體描述見第3章中的場景2定義，該類告警的處理方式為對同一端口上連續(xù)10s內(nèi)的相同告警進行壓縮，僅留下頻發(fā)告警的第1條告警，其他均標(biāo)識為可過濾告警。

b）關(guān)聯(lián)規(guī)則挖掘階段，該部分核心算法為 Prefix-Span時間序列模式挖掘算法［8］。與Apriori、序列模式、時空模式等挖掘算法相比，該算法更適合本案例。但傳統(tǒng)的 PrefixSpan 算法挖掘出來的規(guī)則不帶有約束條件，導(dǎo)致專家也無法判斷關(guān)聯(lián)規(guī)則的正確性，如規(guī)則A［光模塊不可用告警→ RRU 斷鏈告警］。為解決該問題，改進了 PrefixSpan算法，這使其挖掘過程存在約束條件。此時規(guī)則A改進為［光模塊不可用告警→ RRU斷鏈告警，同網(wǎng)元］，提升了算法規(guī)則挖掘的精確度。

c）關(guān)聯(lián)規(guī)則確認與入庫，其中包括已確認關(guān)聯(lián)規(guī)則庫和黑名單。通過多位專家確認上一步中挖掘出來的告警關(guān)聯(lián)規(guī)則，將正確的規(guī)則存入已確認關(guān)聯(lián)規(guī)則庫中，以支撐下一步的告警識別工作。錯誤和不合理的規(guī)則自動導(dǎo)入黑名單，防止下次挖掘出同類規(guī)則。

d）根告警識別階段，即給每個告警分別打上根告警、衍生告警、普通告警3種標(biāo)簽。根據(jù)8類不同約束條件對當(dāng)前告警進行識別處理，約束條件分別為同一端口、同一網(wǎng)元、對應(yīng)業(yè)務(wù)網(wǎng)元、同一業(yè)務(wù)ID關(guān)聯(lián)、直連對端網(wǎng)元、直連對端端口、同環(huán)網(wǎng)元、對應(yīng)業(yè)務(wù)ID關(guān)聯(lián)。

由于廠商和地域的差異性，目前還無法建立統(tǒng)一適用的關(guān)聯(lián)規(guī)則數(shù)據(jù)庫。現(xiàn)已建立了A設(shè)備商IPRAN的告警關(guān)聯(lián)規(guī)則知識庫，共計198條規(guī)則。通過已建立的知識庫，在多個城市進行了試點，表1為相關(guān)告警分析的結(jié)果。

從表1中可以看到B市和D市處理效果較差，冗余告警（用戶側(cè)、頻發(fā)、衍生）過濾百分比為81%左右，C市和A市結(jié)果較好，最高可達98%。產(chǎn)生該結(jié)果的原因有2方面：一是由于告警總數(shù)不同，其中無關(guān)聯(lián)的普通告警數(shù)量也不同；二是地域的差異性，B市和D市的傳輸網(wǎng)絡(luò)設(shè)備更多，無法根據(jù)人工規(guī)則去除無關(guān)告警。

表1 多個試點城市的歷史網(wǎng)絡(luò)告警分析處理結(jié)果

為了更直觀查看告警之間存在的拓撲及業(yè)務(wù)關(guān)聯(lián)關(guān)系，系統(tǒng)可根據(jù)分析結(jié)果自動呈現(xiàn)告警關(guān)聯(lián)分析拓撲圖，通過不同顏色標(biāo)記網(wǎng)元以區(qū)分根告警和衍生告警，并可通過查看歷史告警、網(wǎng)元、端口等信息，輔助支撐運維人員更準(zhǔn)確地定位故障、精準(zhǔn)派單。

總結(jié)和展望

通過案例分析可以看出將人工智能技術(shù)引用到網(wǎng)絡(luò)運維的故障溯源場景中是可行且有效的，基于運維數(shù)據(jù)智能化地識別告警之間的關(guān)聯(lián)規(guī)則，解決了人工經(jīng)驗積累不足的問題，提升了運維效率。但現(xiàn)階段仍存在一些問題，由于目前采用的是單一的數(shù)據(jù)挖掘算法，需要人工判斷關(guān)聯(lián)規(guī)則和結(jié)果是否正確，準(zhǔn)確率和實時性仍無法保障，并未做到真正的智能。

為解決單一人工智能方法的不足，未來可采用多種診斷技術(shù)協(xié)同的新模式，即多智能體技術(shù)?；诙喾N具備不同功能的軟件系統(tǒng)，將復(fù)雜的網(wǎng)絡(luò)告警分解成單一、獨立的成分和因素，各個系統(tǒng)協(xié)同合作，能整合包括網(wǎng)絡(luò)狀態(tài)信息、硬件信息、工單信息等更多的數(shù)據(jù)，實現(xiàn)自主學(xué)習(xí)、自主訓(xùn)練，不斷提升系統(tǒng)性能，全面關(guān)聯(lián)網(wǎng)絡(luò)告警，準(zhǔn)確定位網(wǎng)絡(luò)故障。

［1］ 尼克 . 人工智能的緣起［J］. 中國計算機學(xué)會通訊，2016（3）：38-44.

［2］ SDN/NFV 產(chǎn)業(yè)聯(lián)盟 . 網(wǎng)絡(luò)人工智能應(yīng)用白皮書 v1.0［S］. 北京：SDN/NFV產(chǎn)業(yè)聯(lián)盟，2018（5）.

［3］ Gartner. Market Guide for AIOps Platforms［EB/OL］［. 2018-09-24］.https：//www. gartner. com / doc / 3772124 / market-guide -aiops -plat?forms.

［4］ JINGJING S，LIN Y，A-XING Z，et al. Machine-Learning Variables at Different Scales vs. Knowledge-based Variables for Mapping Multiple Soil Properties［J］. Soil Science Society of America Journal，2018，82（3）：645-.656

［5］ AGGARWAL B，BHAGWAN R，PADMANABHAN V，et al. Net?Prints：Diagnosing Home Network Misconfigurations Using Shared Knowledge［C］// Usenix Symposium on Networked Systems Design & Implementation. USENIX Association，2009.

［6］ ARZANI B，CIRACI S，LOO B T，et al. Taking the Blame Game out of Data Centers Operations with NetPoirot［C］// Conference on ACM Sigcomm Conference. ACM，2016.

［7］ DIMOPOULOS G，LEONTIADIS I，BARLET-ROS P，et al. Identifying the root cause of video streaming issues on mobile devices［C］//CoNEXT '15 Proceedings of the 11th ACM Conference on Emerging Networking Experiments and Technologies. ACM，2015.

［8］ 朱一波，鮑培明，吉根林 . 一種用戶頻繁移動模式并行挖掘算法

［J］. 中國科學(xué)技術(shù)大學(xué)學(xué)報，2018（1）：57-64.

［9］ 孫學(xué)波，石飛達. 基于Hadoop的Apriori算法研究與優(yōu)化［J］. 計算機工程與設(shè)計，2018（1）：126-133.

［10］ 朱林. 基于MapReduce模型可擴展的序列模式挖掘的研究［J］. 科技通報，2018（1）：212-217.技通報，2018（1）：212-217.