本文經《郵電設計技術》授權發(fā)布
如需要轉載，請聯(lián)系《郵電設計技術》獲取授權
郵電設計技術公眾號：ydsjjs，歡迎關注！
摘要：重點探討了人工智能在通信網(wǎng)絡故障溯源方面的應用研究和相關案例。首先介紹了目前網(wǎng)絡運維的現(xiàn)狀和國內外研究進展，結合通信網(wǎng)絡運維中的實際業(yè)務和問題總結了多個應用場景，并針對所有場景提出了故障溯源整體解決方案。最后重點分析了中國聯(lián)通IPRAN網(wǎng)絡告警根因案例。該案例的實踐效果說明了人工智能應用到網(wǎng)絡運維中可以幫助運維人員快速定位根告警和故障源，提高運維效率。
概述
全球運營商相繼發(fā)布網(wǎng)絡演進和轉型戰(zhàn)略，希望能夠通過引入 SDN/NFV、云計算、區(qū)塊鏈、5G 等新技術，減少對專有硬件的依賴，實現(xiàn)新業(yè)務的快速部署，滿足用戶多樣化的需求，提升核心競爭力。但在轉型過程中通信運營商面臨著多種挑戰(zhàn)，一方面是聯(lián)網(wǎng)設備數(shù)量快速增長以及設備之間溝通產生的數(shù)據(jù)洪流，另一方面是隨著電信網(wǎng)絡設備日趨虛擬化、自動化和智能化，網(wǎng)絡復雜度指數(shù)型增長。這些挑戰(zhàn)無疑使網(wǎng)絡運維變得日益繁雜和困難，運維人員一方面必須面對各種高度集成設備產生的大量實時信息，另一方面需要處理海量的告警數(shù)據(jù)，并且為了不降低用戶感知，需要快速解決問題?，F(xiàn)有的系統(tǒng)已經無法在異常狀況發(fā)生時為運維人員提供足夠的支持，導致許多問題不能被及時發(fā)現(xiàn)而不斷傳播升級，直至影響所有業(yè)務。如果發(fā)生異常告警時需要花費大量時間去尋找問題根源及解決辦法，那么即使是細微的問題也會迅速地升級擴大。
人工智能（AI）的發(fā)展可追溯到 1956 年達特茅斯會議（Dartmouth Conference）［1］。人工智能可以定義為機器能夠實現(xiàn)的智能，是與人類和其他動物表現(xiàn)出的人類智能和自然智能相對的概念。也可引用“人工智能之父”Marvin Minsky對人工智能的理解來定義它—“人工智能就是讓機器來完成那些如果由人來做則需要智能的事情的科學”。網(wǎng)絡人工智能（Network AI）［2］是將人工智能技術應用在網(wǎng)絡中，使用機器替代或優(yōu)化目前依靠人工進行的工作，使運營商能夠更加便捷地提供更加優(yōu)質的網(wǎng)絡服務。
本文以人工智能技術為基礎，結合現(xiàn)有網(wǎng)絡運維技術，提出故障溯源整體解決方案。希望通過對告警信息進行合適的過濾、篩選、匹配、分類等流程確認告警信息，并根據(jù)各個告警之間的關系來進行告警溯源，屏蔽不重要或衍生的告警，實現(xiàn)對網(wǎng)絡故障的快速診斷。同時配合相應的通信業(yè)務模型和網(wǎng)絡拓撲結構實現(xiàn)故障的精準定位。最后通過實踐中的具體案例分析，給出人工智能應用于網(wǎng)絡故障溯源的結論和展望。
國內外研究現(xiàn)狀
著名的 IT研究與顧問咨詢公司 Gartner在 2016年提出 AIOps（Artificial Intelligence for IT Operations）的概念［3］，即通過人工智能的方式來支撐現(xiàn)在日益復雜的運維工作。AIOps 可以在深度集成 DevOps 工具鏈的基礎上獲取系統(tǒng)數(shù)據(jù)，然后通過機器學習算法進行數(shù)據(jù)分析，更深度地解析數(shù)據(jù)中所蘊藏的運維信息。Gartner的報告指出預計到2020年，50%的企業(yè)將會在他們的業(yè)務和 IT 運維方面采用 AIOps，遠超現(xiàn)在的10%。同時，國內外各大公司如AT&T、Microsoft、Facebook、百度、阿里巴巴等都在他們的運維系統(tǒng)中實驗或部署了機器學習算法，助力某些運維任務智能化。
華為諾亞方舟實驗室開發(fā)了智能故障診斷系統(tǒng)，利用網(wǎng)絡故障的歷史記錄數(shù)據(jù)自動構建通信領域知識圖譜［4］，并在知識圖譜上進行概率推理，以自動問答的形式幫助工程師找出故障的根本原因。微軟分別在會議NSDI’09和SIGCOMM’16發(fā)表了2篇基于機器學習的故障檢測系統(tǒng)的論文［5-6］。其中，2009 年發(fā)表的論文中提到針對家庭網(wǎng)絡配置問題診斷的NetPrints系統(tǒng)。該系統(tǒng)通過學習明確針對應用的正確配置，在用戶的某個應用發(fā)生錯誤時，可以通過檢測用戶的配置來為用戶選擇一個最小代價的調整策略恢復應用工作。同時，由于系統(tǒng)的特殊設計，一些系統(tǒng)原本無法解決的問題可以通過用戶的協(xié)作更新到診斷系統(tǒng)中，實現(xiàn)了用戶間的知識共享，提高系統(tǒng)的可用性。
2016年微軟發(fā)表的論文中提到針對微軟數(shù)據(jù)中心的錯誤定位問題的 NetPoirot 系統(tǒng)。該系統(tǒng)僅通過觀察主機側的 TCP數(shù)據(jù)就可以定位故障的發(fā)生位置，并且對于未訓練過的錯誤也具有很高的故障位置識別率。但是，該系統(tǒng)只能診斷發(fā)生在主機、網(wǎng)絡或服務器中的錯誤，無法精確地定位到設備也很難精確定位具體錯誤。針對移動設備的視頻傳輸問題，加泰羅尼亞理工大學的研究者在 2015 年的 CoNEXT 上提出了解決方案［7］。該方案通過收集和處理服務中部分位置的設備數(shù)據(jù)，可實現(xiàn)視頻流QoE的預測和故障定位。
故障溯源相關應用場景研究
結合電信網(wǎng)絡的實際業(yè)務場景，剖析運維過程中的實際問題，更有益于將最新的AI技術運用到電信網(wǎng)絡的運維和故障溯源中去，從而提升運維人員的運維效率和運維體驗。目前典型的業(yè)務場景有以下幾個。
3.1 場景1：瞬斷告警
瞬斷告警定義為告警的發(fā)生時間和清除時間很短，小于一定的閾值。這類告警因為生命周期比較短，對運維人員沒有太大的價值，而且會導致告警量激增，從而掩蓋真正需要關注的告警，增加運維人員識別難度。
3.2 場景2：頻發(fā)告警
如果一定時間內發(fā)生的相同告警/事件達到一定的數(shù)目，可以認為這些告警/事件之間存在一定的相關性。通過設置告警/事件頻次分析規(guī)則，當某一段時間內發(fā)生的設定告警/事件的數(shù)目超過了預先設置的閾值，則認為這些告警/事件之間存在相關性。如同一網(wǎng)元同一單板的單板溫度過高或過低告警X分鐘出現(xiàn)Y次，合并生成一條新告警，說明單板溫度異常。
3.3 場景3：同網(wǎng)元內故障影響分析
指同一網(wǎng)元內某物理對象（單板、拓撲）上產生告警會導致該網(wǎng)元上其他物理對象和邏輯對象產生關聯(lián)告警。
對于LTE設備，基站內單板之間以及單板和小區(qū)（邏輯對象）存在關聯(lián)特性，因此單板故障往往會導致小區(qū)也存在異常。如圖1所示，4槽BPN出現(xiàn)“光模塊不可用告警”時，會導致51號RRU產生“RRU 斷鏈告警”，而承載在該RRU上的小區(qū)也會上報“LTE小區(qū)退服告警”，即“光模塊不可用告警”為根告警。
▲ 圖1 某同網(wǎng)元內故障示意圖
3.4 場景4：同專業(yè)網(wǎng)上下層業(yè)務故障影響分析
該場景體現(xiàn)為因為某一個故障導致大面積告警的現(xiàn)象，需要快速地獲取故障原因。如圖2所示，服務層告警會導致客戶層告警的發(fā)生，如光纖出現(xiàn)斷點，光纖所在端口會報LOS告警，導致上層的 TMS、隧道、偽線、業(yè)務都上報告警，此時光纖所在端口的LOS告警就是根告警。
▲ 圖2 某同專業(yè)網(wǎng)上下層業(yè)務故障示意圖
3.5 場景5：跨專業(yè)網(wǎng)告警分析
傳輸包括光傳輸和微波傳輸，光傳輸節(jié)點會下掛很多微波節(jié)點，當一個鏈路中斷會影響這條鏈路上的1個或多個站點，光傳輸節(jié)點斷開導致所有下游的微波 BTS站點都會退服，中間微波某一跳斷也會導致下游所有BTS退服（見圖3）。
▲ 圖3 某跨專業(yè)網(wǎng)故障示意圖
3.6 場景6：綜合故障診斷
故障的表現(xiàn)具有多樣性，可能表現(xiàn)為告警、KPI異?；騿渭儤I(yè)務不通，很多情況下告警并不能反映所有的故障點，所以也無法僅通過告警分析來定位故障。
比如網(wǎng)絡升級后，某LTE業(yè)務不通，如圖4所示的流程，根據(jù)經驗，查看監(jiān)控數(shù)據(jù)，進行各種診斷動作和配置檢查，從而定位故障點，告警只是分析的一部分。
▲ 圖4 某綜合故障分析過程流程圖
通信網(wǎng)絡故障溯源整體解決方案研究
第3章所述業(yè)務場景要解決的問題就是如何智能地識別故障并做有效分析，故障分析模型是基于關聯(lián)規(guī)則，而關聯(lián)規(guī)則通常使用關聯(lián)分析算法得到。
關聯(lián)規(guī)則算法是從一個數(shù)據(jù)集中發(fā)現(xiàn)項與項之間的隱藏關系。只有從多個不同的維度分析告警數(shù)據(jù)，才能識別出它們之間的關聯(lián)關系，如告警發(fā)生的模式或規(guī)律。
基于人工智能的故障診斷和溯源就是在結合大數(shù)據(jù)關聯(lián)規(guī)則分析及人工智能技術的基礎上，根據(jù)系統(tǒng)中的網(wǎng)絡、業(yè)務上下游關系，綜合所有監(jiān)控數(shù)據(jù)（包括告警、性能）、操作日志以及故障解決歷史記錄，輸出故障特征與故障原因之間的一系列規(guī)則。本方案旨在采用人工智能和大數(shù)據(jù)挖掘技術，研究開發(fā)智能故障診斷系統(tǒng)（見圖 5）。在實際網(wǎng)絡運維中，根據(jù)故障特征自動匹配診斷規(guī)則進行診斷，自動得出故障點及相關處理建議。
▲ 圖5 智能故障診斷系統(tǒng)示意圖
本文所提出的智能故障診斷系統(tǒng)要先基于AI學習生成診斷規(guī)則庫，然后根據(jù)規(guī)則進行故障分析。
4.1 基于AI學習生成診斷規(guī)則庫
4.1.1 診斷信息獲取
診斷信息越豐富，診斷效果越好，所以系統(tǒng)應具有自動獲取整個周期（當前、歷史）的網(wǎng)絡狀態(tài)信息的功能。即在現(xiàn)網(wǎng)運行中，除了記錄操作日志、告警、KPI、故障處理建議這種日常監(jiān)控數(shù)據(jù)外，對于網(wǎng)絡拓撲、業(yè)務配置、業(yè)務狀態(tài)這些只記錄當前狀態(tài)的數(shù)據(jù)，也要定時采樣，作為學習的素材。
4.1.2 建立自學習能力
提取故障特征，比如PWE3-CES的包丟失表示2G業(yè)務不通，分析其附近的KPI、操作日志、丟包情況、業(yè)務配置，業(yè)務狀態(tài)等信息，獲取故障特征。此處可使用數(shù)據(jù)降維，分類算法。
根據(jù)故障產生與消失這段時間的操作日志、故障文字記錄、其他告警的產生消失情況等相關數(shù)據(jù)，分析原因。此處可使用關聯(lián)算法、深度學習算法。
分析足夠多的案例，得到所有可能的原因，并計算原因概率。此處可使用概率論的相關算法。
4.2 診斷規(guī)則的運行
現(xiàn)網(wǎng)監(jiān)控：實時監(jiān)控告警，并且對流量、丟包情況定時采樣，并記錄操作日志。
匹配故障特征，進行故障診斷：對現(xiàn)網(wǎng)監(jiān)控數(shù)據(jù)實時進行匹配，一旦匹配成功，立即開始診斷。將故障的原因按概率從大到小排序，逐個診斷，當確認某個原因存在時，就可以定位故障并給出處理建議。
故障修復確認，反向修正診斷規(guī)則庫：故障在自動恢復或派單修復后，反饋派單中原因是否有效，修正診斷規(guī)則庫的原因概率。
相比傳統(tǒng)的故障溯源方案，本方案結合運維中的多種數(shù)據(jù)源，包括并不限于告警、性能、拓撲資源、日志以及偵測命令，這使本方案溯源結果更加精確，并且更具有可參考性。
中國聯(lián)通IPRAN告警智能化分析識別
5.1 案例背景和目的
IPRAN網(wǎng)絡主要用于承載3G/4G移動業(yè)務以及大客戶專線業(yè)務，主要采用IP/MPLS動態(tài)協(xié)議技術。IP RAN網(wǎng)絡協(xié)議以及網(wǎng)絡的邏輯連接的復雜性，使IP RAN網(wǎng)管系統(tǒng)每天接收到大量的設備告警消息，其中很多告警信息都是由根源告警信息引起。
目前處理告警數(shù)據(jù)的相關規(guī)則多依賴于專家經驗，通過規(guī)則過濾掉不關鍵的告警信息。這種方法的缺點是過濾能力有限且有些規(guī)則無法被發(fā)現(xiàn)。
因此需要將人工智能技術應用于IPRAN網(wǎng)絡告警根因溯源中，形成更高效的告警處理方法。
5.2 方案和效果分析
故障是產生告警的根本原因，當網(wǎng)絡發(fā)生故障時，將產生大量告警，挖掘告警之間的關聯(lián)規(guī)則對故障定位有著重要意義?？傮w方案思路如圖6所示。
▲ 圖6 告警根因溯源技術方案流程圖
該方案流程總體可分為以下4個步驟。
a）數(shù)據(jù)預處理階段，包括數(shù)據(jù)導入和清洗、用戶端側告警匹配、頻發(fā)告警識別。輸入數(shù)據(jù)為現(xiàn)網(wǎng)提取的歷史告警數(shù)據(jù)、網(wǎng)絡拓撲數(shù)據(jù)和業(yè)務數(shù)據(jù)3種，經過清洗和整合轉變?yōu)榭商幚淼臄?shù)據(jù)格式。用戶端側告警匹配是根據(jù)以往運維經驗去除不關心/無價值的告警。頻發(fā)告警的具體描述見第3章中的場景2定義，該類告警的處理方式為對同一端口上連續(xù)10s內的相同告警進行壓縮，僅留下頻發(fā)告警的第1條告警，其他均標識為可過濾告警。
b）關聯(lián)規(guī)則挖掘階段，該部分核心算法為 Prefix-Span時間序列模式挖掘算法［8］。與Apriori、序列模式、時空模式等挖掘算法相比，該算法更適合本案例。但傳統(tǒng)的 PrefixSpan 算法挖掘出來的規(guī)則不帶有約束條件，導致專家也無法判斷關聯(lián)規(guī)則的正確性，如規(guī)則A［光模塊不可用告警→ RRU 斷鏈告警］。為解決該問題，改進了 PrefixSpan算法，這使其挖掘過程存在約束條件。此時規(guī)則A改進為［光模塊不可用告警→ RRU斷鏈告警，同網(wǎng)元］，提升了算法規(guī)則挖掘的精確度。
c）關聯(lián)規(guī)則確認與入庫，其中包括已確認關聯(lián)規(guī)則庫和黑名單。通過多位專家確認上一步中挖掘出來的告警關聯(lián)規(guī)則，將正確的規(guī)則存入已確認關聯(lián)規(guī)則庫中，以支撐下一步的告警識別工作。錯誤和不合理的規(guī)則自動導入黑名單，防止下次挖掘出同類規(guī)則。
d）根告警識別階段，即給每個告警分別打上根告警、衍生告警、普通告警3種標簽。根據(jù)8類不同約束條件對當前告警進行識別處理，約束條件分別為同一端口、同一網(wǎng)元、對應業(yè)務網(wǎng)元、同一業(yè)務ID關聯(lián)、直連對端網(wǎng)元、直連對端端口、同環(huán)網(wǎng)元、對應業(yè)務ID關聯(lián)。
由于廠商和地域的差異性，目前還無法建立統(tǒng)一適用的關聯(lián)規(guī)則數(shù)據(jù)庫。現(xiàn)已建立了A設備商IPRAN的告警關聯(lián)規(guī)則知識庫，共計198條規(guī)則。通過已建立的知識庫，在多個城市進行了試點，表1為相關告警分析的結果。
從表1中可以看到B市和D市處理效果較差，冗余告警（用戶側、頻發(fā)、衍生）過濾百分比為81%左右，C市和A市結果較好，最高可達98%。產生該結果的原因有2方面：一是由于告警總數(shù)不同，其中無關聯(lián)的普通告警數(shù)量也不同；二是地域的差異性，B市和D市的傳輸網(wǎng)絡設備更多，無法根據(jù)人工規(guī)則去除無關告警。
表1 多個試點城市的歷史網(wǎng)絡告警分析處理結果
為了更直觀查看告警之間存在的拓撲及業(yè)務關聯(lián)關系，系統(tǒng)可根據(jù)分析結果自動呈現(xiàn)告警關聯(lián)分析拓撲圖，通過不同顏色標記網(wǎng)元以區(qū)分根告警和衍生告警，并可通過查看歷史告警、網(wǎng)元、端口等信息，輔助支撐運維人員更準確地定位故障、精準派單。
總結和展望
通過案例分析可以看出將人工智能技術引用到網(wǎng)絡運維的故障溯源場景中是可行且有效的，基于運維數(shù)據(jù)智能化地識別告警之間的關聯(lián)規(guī)則，解決了人工經驗積累不足的問題，提升了運維效率。但現(xiàn)階段仍存在一些問題，由于目前采用的是單一的數(shù)據(jù)挖掘算法，需要人工判斷關聯(lián)規(guī)則和結果是否正確，準確率和實時性仍無法保障，并未做到真正的智能。
為解決單一人工智能方法的不足，未來可采用多種診斷技術協(xié)同的新模式，即多智能體技術?；诙喾N具備不同功能的軟件系統(tǒng)，將復雜的網(wǎng)絡告警分解成單一、獨立的成分和因素，各個系統(tǒng)協(xié)同合作，能整合包括網(wǎng)絡狀態(tài)信息、硬件信息、工單信息等更多的數(shù)據(jù)，實現(xiàn)自主學習、自主訓練，不斷提升系統(tǒng)性能，全面關聯(lián)網(wǎng)絡告警，準確定位網(wǎng)絡故障。
▎參考文獻：
［1］ 尼克 . 人工智能的緣起［J］. 中國計算機學會通訊，2016（3）：38-44.
［2］ SDN/NFV 產業(yè)聯(lián)盟 . 網(wǎng)絡人工智能應用白皮書 v1.0［S］. 北京：SDN/NFV產業(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］. 中國科學技術大學學報，2018（1）：57-64.
［9］ 孫學波，石飛達. 基于Hadoop的Apriori算法研究與優(yōu)化［J］. 計算機工程與設計，2018（1）：126-133.
［10］ 朱林. 基于MapReduce模型可擴展的序列模式挖掘的研究［J］. 科技通報，2018（1）：212-217.技通報，2018（1）：212-217.
▎
