劉裕良-基于 AI 與數據驅動的通信網絡智能運維實踐.pdf

《劉裕良-基于 AI 與數據驅動的通信網絡智能運維實踐.pdf》由會員分享，可在線閱讀，更多相關《劉裕良-基于 AI 與數據驅動的通信網絡智能運維實踐.pdf（34頁珍藏版）》請在三個皮匠報告上搜索。

1、敏捷感知，精準決策：基于 AI 與數據驅動的通信網絡智能運維實踐劉裕良 研究員中國科學院自動化研究所博士，現為華為諾亞方舟實驗室研究員。2016年開始參與ICT智能運維相關工作，主要從事小樣本學習、數據異常檢測、根因推薦、智能診斷、時空聚類、關聯挖掘、預訓練模型、Zero-Touch Operation等方向研究。在研究工作中提出的V-Sharpness、iRCRR、根因基、MSGR、AdaSTE等算法和框架，已成功應用到AUTIN等相關產品。具有豐富的AI算法設計、優化、落地經驗，同時熟悉無線、傳輸、核心網的基本運維機制，理解運維語言和運維痛點。通信網絡發展趨勢及運維挑戰通信網絡未來運維模式

2、華為智能運維實踐總結與展望通信網絡發展趨勢及運維挑戰通信網絡發展趨勢網絡運維面臨的挑戰網絡運維轉型趨勢根據行業預測，未來的運維的發展趨勢，將逐漸從面向網絡與設備的被動式管理轉型成為面向客戶的預測、預防式管理，通過高度自動化的服務為客戶提供自助服務的模式。而通過面向客戶的并且提供預測 預防管理的智能運維模式，雖然網絡環境逐漸趨向復雜與多元，但網絡故障的處理時長、運維人員與人為引入故障的數量都將得到較大控制，傳統的網絡環境復雜度與維護成本、人數等運維的工作量之間的矛盾將得到極大緩解。引入 AI 是電信行業趨勢所向Tractica 電信行業 AI 收入預測全球知名市場研究公司 Tractica/Ov

3、um 對 30 個領域近 300 個真實的 AI 使用場景進行的研究表明，電信領域在 AI 技術方面尤為積極，并且是目前最大的 AI 細分市場。根據 Tractica/Ovum 預測，到 2025 年，全球電信業對人工智能軟件、硬件和服務的投資將達到 367 億美元。其中，電信業 AI 軟件市場將以 48.8%的年復合增長率從 2016 年的3.157 億美元增至 2025年的 113 億美元。預計至 2025 年，電信運營商主要將 AI 用于網絡運營監控和管理，這方面的支出將占到電信業 AI 支出的61%通信網絡未來運維模式新需求和挑戰對未來運維模式的期望人工智能在電信網絡運維中的作用電信網

4、絡未來運維模式：人機協同運維體系迭代發展過程中人、數據、機器的角色與關系隨著人工智能的技術不斷成熟并在運維中扮演越來越重要的角色，推動運維管理由傳統“人+流程”的運維模式轉向人機協同的運維模式，人機協同的運維模式是讓機器把機器學習、深度學習等人工智能算法應用于運維工具和業務系統所采集的大型數據集，并嘗試模擬人類行為（如感知、分析、決策、執行等）協助運維的模式。人機協同模式讓運維管理具備算法和機器學習能力，通過持續學習將運維人員從紛繁復雜的告警中解放出來、使運維變得智能化。在新的運維模式下，新技術可以賦能運營團隊，以人的獨特經驗和判斷力注入數據底座，點石成金，將數據升華為知識，并以此推動機器的學

5、習能力，形成機器自決策、自執行的閉環，打開電信網絡的未來新模式的大門。新一代電信網絡運維模式人機協同運維模式的演進方法華為智能運維實踐華為智能運維核心能力：場景化專業能力借助于豐富的項目經驗與過硬的技術能力，華為已經建立了強大的在MBB/FBB/NFV&5G 下的場景化專業能力。華為智能運維核心能力：AI 算法與數據服務能力統一 AI 算法能力，賦能場景數據賦能故障預測與管理案例介紹1：無線網絡故障管理自動化1.人工總結故障樹，耗時耗力，場景覆蓋度僅40%，2.單棵故障樹準確率70%；3.MV場景無專家經驗積累，覆蓋難度大。競爭力突破業務痛點1.標注工作量大，2人月/項目；2.場景僅覆蓋MBB

6、；3.推理過程不可視，無參數暴露，客戶無法參與1.圖主題挖掘技術突破，標注工作量2人月 5人天；2.構建通用傳播圖，場景拓展到承載網（PTN/OTN）；3.推理過程可視智能識別（AABD Pro）人工識別-機器挖掘+無感標注智能診斷（RCF）人工總結-自主系統+場景覆蓋度故障管理業務流數據采集故障識別修復&閉環故障診斷網絡拓撲&資源數據實時告警歷史告警訓練態推理態ProAI能力支撐故障修復傳播關系挖掘時空聚類根因網元識別故障傳播圖故障根因推斷修復方案推薦智能識別智能診斷業務痛點競爭力突破基于RCF根因基模型構建淺層根因決策能力，無線接入場景覆蓋率從40%提升到80%，準確率90%，支持MV。單

7、層定位多層定位問題抽象N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7N1N3N2N4N6N5N7TT1=N1,N2,N3,N4,N5,N5,N6rcNe1=N2TT1=N1,N2,N3,N4,N5,N5rcNe1=N2TT2=N6rcNe2=N61!#!$故障定界：精準確定故障影響范圍，減少工單數量，避免重復派單；故障定位：準確上報根網元，提高運維效率，避免無效上站N1N3N2N4N6N5N7業務問題：“告警太多（百萬/天）了，我們一線運維工程師根本看不過來！”傳統方法：告

8、警壓縮，對告警進行分級處理，從而減少告警數量；這種方法需要大量人工經驗，而且無法解決“群障”，因此對工單數量減少有限。問題抽象：在無人工經驗的條件下確定異質圖的時空邊界關鍵發現：1、異質序列之間具有物理關聯性，聯合建?？梢蕴岣呔?2、在一較小鄰域內發生同時發生兩個故障的概率較小。以印尼XX為例：網元【10W+】，產生告警【200W+/天】，實際故障約【2W/天】業務問題：“我應該先處理上哪個站？帶什么工具去？”傳統方法：代維人員靠經驗決定工單處理的先后順序，重復上占率高；問題抽象：在樣本極少且有錯標的情況下，異質圖的推理問題關鍵發現：1、故障的時空一致性；2、故障的傳播性以印尼XX為例：工單

9、【2W/天】，其中10%需要上站，重復/錯誤上站20%-30%；每一單的成本【80美金】TT1=N1,N2,N3,N4,N5,N5,N6TT1=N1,N2,N3,N4,N5,N5TT2=N6!#$%!#$%!&%!&%技術挑戰與解決方案解決方案：建立了故障流模型（FSM），以事件驅動的方式處理“群障”，并提出了拓撲融合方案MTF解決了空間邊界的問題；提出基于異質序列變分協的等待時長預測方案VSDA以解決時間邊界的問題；在少人工經驗的條件下確定異質圖的時空邊界MSGR:解決TE黏連問題VSDA:解決時間邊界問題MTF:解決空間邊界問題空間邊界時間邊界解決方案：從可解釋和小樣本兩條路徑進行了探索：

10、1、可解釋：因果推理、屬性圖關系挖掘、神經時序點過程挖掘2、小樣本：小樣本圖節點分類方法；小樣本根因分類；在樣本極少且有錯標的情況下，異質圖的推理根因網元識別根因告警識別根因推斷&修復建議123MetaGCN:解決有標注時的根因網元推斷1AdaSTE:降低假陽性ICT-大模型:拓撲完整時的推斷關系挖掘INTLA:拓撲不全的推斷關系挖掘!=(%#:%!&!#()/(%#:%!&!1)2RCF:解決樣本分部不均時的故障根因推斷3單層定位多層定位案例介紹2：5G核心網故障管理自動化故障管理業務流 網絡產品多：5GC云化網絡涉及VNF、CloudOS層（VM、FS、E9000）、網絡層（交換機、TOR

11、）、存儲（磁陣、硬盤）等多種產品，產品之間可采用近10種組網方式，每種產品又涉及幾十個組件設備（如右圖所示）運維經驗少：5GC建網時間短，客戶積累的運維經驗少，跨層故障發生時不知如何應對 定界時間長：5GC故障現象涉及的設備和數據多，需要人工結合拓撲進行關聯分析定界，時間花費長，是當前客戶運維Top痛點業務指標倒換隔離根因推薦智能關聯智能定界CHR日志運行日志設備告警網絡拓撲KPI檢測CHR檢測日志檢測時空匯聚(通用)模糊匹配數據采集多維關聯與定界業務恢復異常檢測定位閉環深層診斷問題抽象異常檢測：對多種不同類型數據進行實時快速檢測故障定界：準確推薦根因設備，支撐后續隔離倒換，快速恢復業務多維關

12、聯：將多種數據業務準確關聯，生成一個故障事件UDMAMFPCFAUSFAFUPFSMF業務層垂直層SMF-VM1SMF-VM2SMF-VM3PCF-VM3PCF-VM2PCF-VM1性能時序運行日志CHR日志CHRError code小區終端號段Sip statusRelease NET-TORST-TORM-TORDisk0Host0Disk1Host2Host1M-HostvDisk0vDisk1Disk2vDisk2VM2VM1VM0異常設備正常設備Host1 Host2Host3Host4現有解決方案異常檢測：對不同類型數據采取不同檢測方法，準確率90%+故障定界：在關聯基礎上結合歷史

13、故障先驗和拓撲連接，計算子圖中各節點異常得分，實現根因節點推薦，準確率75%；同時探索基于因果傳播鏈的根因推理多維關聯：文本&節點向量疊加網絡拓撲，基于異常相似度進行關聯匹配，關聯準確率85%特征1特征2特征3特征4專家規則iI層虛擬機重啟場景：特征1：分區負載監控告警特征2：服務中和服務通信故障特征3：分區過載監控特征4：節點故障Network EmbeddingAMF SMF UDM業務全阻AMF SMF到單類型網元全阻AMF SMF到單個網元連接斷I層虛機故障I層主機端口異常等關聯規則關聯規則Word EmbeddingAMF2VM3VM4VM5S0S1S2Host1Router1故障子

14、圖（有向無環）主機端口故障某主機故障的因果傳播關系主機狀態異常虛機故障虛機鏈接中斷網元資源單元故障稀疏矩陣檢測CHR日志運行日志模板生成與匹配性能時序動態閾值監控故障場景熱門方向：基礎模型https:/arxiv.org/pdf/2108.07258.pdf在2021年8月份，百余位科學家聯合發文，提出了大規模預訓練模型面臨的基于和挑戰，文中建議將預訓練大模型統一稱作Foundation Models，即AI基礎模型/大模型。文中指出AI基礎模型最典型的特征是“涌現”和“同質化”。Emergence means that the behavior of a system is implicit

15、ly induced rather than explicitly constructed;it is both the source of scientific excitement and anxiety about unanticipated consequences.Homogenization indicates the consolidation of methodologies for building machine learning systems across a wide range of applications;it provides strong leverage

16、towards many tasks but also creates single points of failure.Foundation models have led to an unprecedented level of homogenization:Almost all state-ofthe-art NLP models are now adapted from one of a few foundation models,such as BERT,RoBERTa,BART,T5,etc.ICT運維基礎模型識和數據雙輪驅動的電信網絡維護人工智能框架。經綸運維大模型是一個“編碼-

17、解碼”框架下的序列數據模型，通過在正常數據上進行自監督預測學習的方式進行訓練；其中的自然語言預訓練模型用于生成通信原理的表征并與現網數據融合，可以獨立訓練，直接支撐語言序列的下游任務；借鑒預訓練的思想，我們可以在“編碼-解碼”框架下完成預訓練，而只使用編碼器部分的網絡作為預訓練模型，為不同的下游任務（機器數據序列的預測、檢測、分析等）提供融合表征作為輸入。隨著2/3/4/5G全融合，虛擬網元數量激增，控制面全集中，轉發面全分布，虛擬化網絡功能上/下線自動化程度上升，網絡故障定位需要跟蹤的調用環節同步上升、故障定位難度劇增。我們提出一種通信網絡運維領域的機器學習大模型框架，不僅將網絡運維所需要處

18、理的多種形式的數據統一在一個學習范式中，而且將網絡運維中的各種任務以下游任務的形式也統一到該學習框架中。該框架也是融合知數據準備構建經綸運維大模型所需的數據分為兩類：文檔類數據以技術類文檔為主，包括Hedex產品文檔、3GPP協議文檔、技術會議文檔、技術博客、技術書籍等。用于構建通信領域的預訓練語言模型，支持在設備數據建模過程中融合通信原理，同時支撐文本類下游任務的應用文檔類數據設備數據序號來源說明樣例1產品文檔設備描述產品Hedex文檔2協議文檔基礎技術文檔3GPP標準、RFC（請求意見稿）3技術博客技術類帖3MS4技術會議、期刊標準來源文檔ICASAP、ICC、Globecom5技術書籍標

19、準工具書CCNA、HCIA、TCP/IP詳解等序號數據類型數據形式描述1Perf時間序列設備各類指標的打點計數2Alarm事件序列設備在運行過程中產生的告警信息3Debuglog結構化文本設備產生的高度日志4MML半結構化文本相關命令的輸入輸出5CHRToken序列CCNA、HCIA、TCP/IP詳解等設備數據各類設備產生的數據，如Perf、Alarm、Debuglog、MML、CHR等。用于對經綸運維大模型的“編碼-解碼”框架進行訓練及下游任務的驗證已收集處理產品文檔：無線、數通、云核、傳送、接入、IT等6個產品線 共計4,714,7494,714,749個網頁頁面，47G47G大?。ㄖ杏⑽?/p>

20、）解析成通用結構語料，共計17G17G（中英文）已收集處理協議文檔：共計38,67138,671個協議文檔，28G28G大?。ㄓ⑽模┏槿『蟮倪壿嬑臋n數量為1,548,0001,548,000個，共計6.2G6.2G（英文）ICT基礎模型：日志關聯場景 在海量非結構化日志中，根據語義的異常找到關鍵日志*，并且找到上下文關聯的相關日志是日志分析的核心問題。通常的，工程師能夠顯式的根據問題描述找到關鍵的異常日志，但是上下文相關聯的日志查找費時費力，我們期望通過領域知識模型助力日志推薦功能，實現精準的日志關聯推薦。!#$%&!#$%&PrecisionRecallF1baseline0.7450.69

21、80.707Googlebert+non-finetune0.6740.4680.548XXXX+non-finetune0.8780.6250.715Googlebert+finetune0.8430.6330.718XXXX+finetune0.8000.7010.732 我們在IT服務器日志分析場景收集了80w條日志數據，涉及42個故障場景。專家標注了少量的故障相關的日志（42個故障），并且指明現象日志（Query）?；赑airwise的構建方法我們擴充了數據集。壓縮前日志()*+,()*+,-.+,/-.+,/非相關日志對252020012343139313901/0沙掽蟆詫蟆悪&摸

22、)BiLSTMLog 1Log 2Log 1Log 21/0ClassifierCLS/MEAN基于Siamese Network的日志關聯推薦模型XX框架日志關聯推薦數據集構建背景數據方法 基于模板對日志進行壓縮，保留關鍵語義信息，屏蔽語義無關的參數信息?；诮浘]大模型對語義信息生成詞向量，構建如下圖所示的分類模型。實驗結果2022-04-09T09:55:11.279722+08:00 euler nova-api DEBUG pid:3156690 GreenThread-437 tid:70369507448976 session.py:548 _http_log_response-R

23、ESP:200 Content-Length:17665 Content-Type:application/json Date:Sat,09 Apr 2022 01:55:11 GMT Server:Apache Vary:X-Auth-Token X-Frame-Options:DENY X-Subject-Token:SHA256aa84e15fecfec1cc43a577250f7303ce240e1fb383e512e682adcfd3ab853c75 connection:close x-openstack-request-id:req-034f041a-2c0c-4356-b707

24、-76e8a4b43cca _http_log_response/usr/lib/python3.7/site-packages/keystoneauth1/session.py:548 RESP:Content-Length:Content-Type:application/json Date:Server:Apache Vary:X-Auth-Token X-Frame-Options:DENY X-Subject-Token:connection:close x-openstack-request-id:_http_log_response:日志模板精簡ICT基礎模型：信令分析場景當前信

25、令模型沒有考慮信元的語義信息，導致不同信元之間的語義關聯沒有顯式建模，因此信元級別的任務效果仍不理想?；诖?，我們在信元表示上引入語義信息，同時借助專業文檔訓練的預訓練語言模型進一步提升語義的表達能力。當前使用的token信息：#消息:50547#信元:599446實際的語義信息：#消息：sip.CSeq.method,SUBSCRIBE,#信元：sip.P-Access-Network-Info.access-type:3GPP-NR-TDD,sip.contact.uri|e164.msisdn|e164.country_code:86，.h1hi-1x1,1xi-1,1Informati

26、on Element-Level AttentionTOKEN POSITION ENCODING.firstmessage.Information Element-Level AttentionlastmessageMESSAGE POSITION ENCODINGMessage-Level Attentionx1,nxi-1,n.xi,1.Decoder Attentioncurrentmessagexi,j-1Softmaxxi,jPOOLINGPOOLINGTOKEN EMBEDDINGSEMANTIC EMBEDDINGBERT CLS Information Element Exp

27、lanationCLS Information Element ExplanationBERT CLS Information Element ExplanationBERT CLS Information Element ExplanationBERT CLS Information Element ExplanationBERT CLS Information Element ExplanationBERT SHAREBasic ModelSense Unit實驗方案實驗數據實驗結果模型/指標TOP1 PRECISIONMAPNDCGBaseline23.0829.4869.28+Goog

28、le Bert26.9231.8972.25+運維大模型42.3134.474.47ICT基礎模型：MO場景FinetuneFinetune樣本數：25774；正樣本：12887；負樣本：12887；其中10%用來測試；90%用來訓練；Finetune過程中，測試集最高準確率98.175%；Domain覆蓋：無線、傳輸、動環、RNG-2G、RNG-3G、RNG-4G、MW、POWER、RAN；Vendor：高新興、艾默生、烽火、大唐、華為、愛立信、阿爾卡特朗訊、鐵塔、中興力維、中興、諾基亞、ZTE、ERICSSON、CISCO、NEC、HUAWEI；ValidationAABDPRO挖掘得到的

29、傳播關系：304條；挖掘過程中不使用方向先驗(r002)；專家標注Y：56 -挖掘正確，方向正確F：53 -關聯正確，推斷方向錯誤（相反）N：195 -關聯錯誤，告警間無關系Domain：傳輸網、動環、無線接入網；Vendor：華為、XX；生成驗證數據 驗證數據生成后會與Finetune數據去重，保證驗證用的數據是模型“沒見過”的；因為不同廠家對同一種Domain描述有差異，所以分成Domain對齊和未對齊兩種場景。FinetunedModelUnfinetunedModelCurrent Method（bow）Y_F89.908%(98/109)85.321%(93/109)48.624%Y

30、_F_reverse87.156%(95/109)82.569%(90/109)48.624%Y_F_vendor_domain_aligned96.970%(64/66)96.970%(64/66)48.624%驗證數據一：Y_F 取Y和F類型的數據；數據大?。?09條驗證數據二：Y_F_reverse 取Y和F類型的數據 對所有數據反向，即把alarm1-alarm2;變成alarm2-alarm1;數據大?。?09條驗證數據三：Y_F_vendor_domain_aligned 取Y和F類型的數據；將”傳輸網”修改為“傳輸”；“無線接入網”修改為“無線”；與finetune對齊；數據大小

31、：66條總結與展望CT網絡與IT網絡的差異電信網絡IT數據中心CTIT網絡體系3G,4G,5G,TCP/IP設備類型BSC,RNC,MME,HSS,eNB,S-GW,服務器，路由器/交換機連接方式線纜，無線線纜設備分布室內+室外（分散式）室內機房（集中式）應用分布用戶與設備強耦合應用與設備弱耦合/解耦商業模式運行商：購買設備，少量自營業務=設備廠商負責運維，運行商開權限、提訴求設備、業務都歸IT公司所有=主人與保姆同體CT網絡運維 VS IT網絡運維CTIT數據收集鏈條長，限制多，挑戰大，成本高（室外設備：天氣，人為破壞，）代價較小數據預處理標準化低=依賴領域/廠商知識標準化高=易實現數據標定

32、設備關聯，數據關聯=工作量大工作量較小AI基礎技術不存在本質差別（異常檢測、深度學習、在線學習、強化學習，預訓練）用戶訴求訴求高實時性要求不高、對運維效果感知較弱驗證測試上線周期長，實測成本高易上線測試，試錯成本低可復制性差強展望隨著5G網絡商用進展的不斷推進，以及AI與電信網絡運維的深度融合，華為的人機協同智能運維解決方案使運維從“人拉肩扛”走向“自動化和智能化”。通過技能轉型使運維人員向數據分析師、網絡策略師和應用編排師轉型，把專家經驗總結的規則、AI 模型封裝成運維流程資產及運維認知資產注入智能運維平臺；智能運維平臺能夠基于這些資產實現智能運維，通過這種人機協同的運維模式，華為智能運維解決方案能夠打破運維資源隨設備線性增長的定律，利用自動化減少人為失誤，提升運維效率；基于 AI 技術實現網絡及業務故障的預測預防，提升運維質量，從而保障超可靠的四代共生的電信網絡。面向未來，華為將持續利用在產品、技術和專業服務領域的優勢和經驗，將更多的“主動、預測、預防”帶進現實，與行業一起攜手打造更健康、更具活力的電信運維生態。華為愿與運營商攜手合作，在電信網絡運維領域不斷探索，持續創新，開放華為全球運維經驗及生態，助力運營商構筑智能化運維能力，實現降低成本、提高網絡質量、使能運維轉型。Thanks開放運維聯盟高效運維社區DevOps 時代榮譽出品