原文作者：啟明。
國際慣例，我們先介紹一下AIOps的概念：AIOps，即 Artificial Intelligence for IT Operations，智能運維，将人工智能應用于運維領域，基于已有的運維資料（日志、監控資訊、應用資訊等），通過機器學習的方式來進一步解決自動化運維沒辦法解決的問題。
Gartner預測，目前的IT應用程式會發生劇變，而且管理整個IT生态系統的方式也會改變。這些變化的關鍵是Gartner所稱的AIOps平台。
我們今天要讨論的，就是AIOps的需求挑戰，以及我們通過怎麼樣的方式去應對這種挑戰。
AIOps需求及挑戰
（一）新技術、新挑戰，呼喚高度智能的電信網絡
近年來，以5G為代表的新技術在電信網絡中得到了快速的應用。新技術的應用，給我們帶來了很多的收益，比如大連接配接、低延遲時間、高速率等等。5G的發展，讓這些資料都至少有一個數量級的提升。
但是，資料量級的提升，伴随着的，是運維難度的增加，進而給運維帶來了如下挑戰：
1. 網絡複雜性：
資料量級的增大，讓網絡變得更加複雜：新技術得到了快速應用，舊技術卻沒有同步退出，導緻我們每引入一項新技術，都需要在原來的複雜度上做一個加法。而在某些場景式，甚至要去做乘法。
比如，在無線領域，2G/3G/4G/5G，“四代同堂”；在核心網，PS/CS/MS物聯網等等十域并存......如此高的網絡複雜度勢必會給運維帶來相當大的挑戰。
2. 2B新需求
運維的第二個挑戰是To B的新場景，也就是企業應用。5G的應用推動了智能制造，網絡也逐漸融入到了企業的生産制造流程當中。在這種情況下，對網絡可靠性的要求必然會提高，畢竟網絡一旦出問題，生産流程就可能會受影響，甚至會中斷，這樣造成的損失将會非常大。3.
3. 成本壓力
成本壓力主要是由前面兩個挑戰傳導而來。前兩個挑戰導緻我們要麼面臨一個比較複雜的網絡，要麼就是有更高的要求。如果我們以傳統的運維方式去應對的話，必然會導緻成本的急劇上升。當然，成本的提高，還有一個因素就是能耗。畢竟，5G的能耗要遠高于4G的能耗。
針對上述這些挑戰，我們要如何去應對呢？AI技術是關鍵。
（二）AI是提升電信網絡自動化和智能化的關鍵技術
在運維成本方面，有統計顯示，90%的運維都需要人工去參與，而70%的成本就是人力成本。在這種情況下，一個很自然的想法就是能不能使用AI的技術來降低人的成本，來提高運維效率。
比如剛才提到5G能耗問題，我們能否通過人工智能的技術來去降低能耗呢？從過往的實踐經驗來看，上述問題的答案是肯定的。
接下來，我們通過三個例子來說明。
1. 基站節能
第一個例子是基站節能。基站的能耗是非常高的。在布網初期，基站使用者較少，有時候基站常常是空開。針對這種情況，營運商的解決方案是對話務量做出一些預測。如果我們能精準預測話務量的話，那麼，在話務量小的時候，我們就可以把一定量的載波關掉，進而達到節能的目的。據統計，在預測話務量的過程中，通過LSTM神經網絡來做預測，可以實作節能10%以上。
2. 核心網KPI異常檢測
第二個例子，是異常檢測。在營運商的核心網部署KPI異常檢測服務。原有的異常檢測服務，是使用固定門檻值進行告警通知。而AI技術，則更加智能、及時、準确地識别異常。
3. 故障識别及根因定位
通常網絡上一旦發生故障，就會觸發大量的告警，而系統同時又以高經緯次元進行運維派單。如果多個網員上報多個告警，那麼就會出現這種重複派單。也就是說發生了一個故障，多網員上報告警，最後可能導緻在多個域（無線域和傳輸域等）都去派單。
（三）開發AI應用仍然面臨挑戰：開發門檻高、周期長
從上面三個例子我們可以看出，AI相對來說，還是非常靠譜的。但是既然AI如此靠譜，為什麼沒有得到全面快速的應用呢？因為AI的開發還面臨着不小的挑戰，簡單概括就是六個字：門檻高，周期長。
上圖是Gartner的一份研究報告。它從四個次元分析了AI應用的主要障礙。其中最主要的3點：
- 人員技能
- 了解增益與用途
- 資料範圍與品質
這就回到我們說的六個字：門檻高，周期長。
1. 門檻高
此處說的“門檻高”，第一點是指缺乏AI算法開發人員。一般的運維團隊不會配置專門的AI算法開發人員，這樣必然導緻AI技能的缺失。
但這不是最關鍵的，因為AI人員通過教育訓練、培養、招聘等手段，都可以解決。
最關鍵的，也就是我們說的第二點，算法與業務結合難。如果要想把一個應用做好，最好的是從業務出發，根據業務的實際情況選擇合适的算法，這樣才能把應用做好。但在實際操作過程中，首先，我們需要有一個業務專家對運維要有深刻的了解；其次，還需要有一個精通AI的算法專家。在這之後，需要他們有充足的時間和意願坐下來深入的交流。在這裡，時間和意願都會成為阻礙。
第三點是資料。資料包含兩個問題：工程問題和标注問題。即，開發一個AI應用實際上是相當大的工程量，因為首先需要接入海量的多模态的資料去完成模型的訓練和推理，最後還要去完成結果的展示，包括去對接一些現有的系統。是以除了前面需要的運維專家和算法專家，還需要很多工程開發人員。
2. 周期長
開發門檻高，就決定了開發周期長，畢竟有這麼高的門檻，如果不能很好的解決的話，那麼周期必然會特别長。開發周期長會導緻：
第一，了解增益和用途。怎麼了解呢？也就是說，如果我們長時間拿不到結果，那麼企業決策人員就可能對AI能産生的效果會表示懷疑；
第二，時間越長，大家對項目的期望就會越高。假設同樣是做一個東西取得了同樣的效果，比如說故障修複時長降低5%，兩年做出來的和一個月做出來的，得到的評價可能就完全不一樣。
針對AIOps落地過程中遇到的挑戰，華為推出的AIOps服務！現在我們一起來看看AIOps服務具體是什麼，以及它是如何解決我們前面面臨的挑戰的。
華為AIOps服務
上圖是AIOps服務的整體架構。AIOps從下到上分成了四層：
第一層：資料的采集和治理。資料采集治理，聽上去容易，做起來難，為什麼呢？因為要面對的資料類型多，接口和資料類型也不統一。光去适配這些資料，都有可能累的焦頭爛額。相對來說，華為AIOps服務首先支援通用的接口，然後對一些常見的裝置都已經預置完成，最後能達到自動對接，資料自動治理的一個水準。
第二層：AI原子能力。華為AIOps共有二十多個原子能力，覆寫檢測、預測、識别、診斷四大場景。原子能力不僅僅是AI算法的一個實作。每一個原子能力都經過實際局點資料的檢驗，針對具體的營運場景做過優化。同時，每一個原子能力也都融入了華為以前的運維經驗，某些原子能力甚至能做到不訓練可以直接使用。
第三層：編排能力。包括流程的編排和大屏的編排，還有RPA的編排。原子能力是AIOps智能運維的基礎元件，流程編排操作簡單靈活，隻需從元件庫中拖拽資料及AI運維能力進行組合，即可完成指令場景端到端的圖形化編排，真正支撐合作夥伴拉低開發門檻，高效率的建構AI應用編排架構。
第四層：行業AI app。針對最典型的場景開箱即用。通過豐富的2D和3D可視化元件，如提供了超過30個圖表控件，覆寫折線、拓撲、清單、柱形等樣式，并提供多個地圖控件、互動控件及媒體控件搭建。運維效果大屏時隻需從元件庫裡拖拽出各類控件，按需組合自由布局、靈活配置應用的各種報表，輔助監控和分析，例如DIY微服務健康監控大廳，使其能夠可視化，展示接口平均成功率、接口平均時延、接口失敗率、接口調用次數等。同時提供KPI告警清單，為營運人員提供故障預警參考依據，拖拽所需控件号，對控件的樣式，資料及互動進行個性化定制，使其滿足展示要求。後端資料還可使用app組合流程裡定義的各類中間資料。配置完成後即可一鍵預覽和釋出運維效果，大屏展示接口，平均成功率，接口平均時延，接口失敗率，接口調用次數等，快速實作DIY可視化大屏。
（一）RPA助力AIOps對接現有運維系統
除了展示位，推理結果必須能夠幫助進行故障的恢複。現階段一般是對接現有的系統，比如工單系統（需要工單郵箱的人要去處理）、自動回複和問題單。如果通過人工去對接，費時費力并且容易出錯。是以機器人流程自動化，也就是RPA服務，水到渠成。RPA服務可以完成資料的對接、搬運及工單的發放等等，減少人力投入，降低出錯成本。
（二）10+開箱即用的App，支援快速部署
針對一些最典型的場景，華為雲AIOps把編排能力都已經提前準備好，也即，有十多種開箱即用的App，如園區網絡、DC網絡、IT應用、營運商網絡等等場景全覆寫；靈活部署，支援公有雲、HCS部署、On Premise部署、及雲地協同等；開放生态，支援合作夥伴開發行業App，并将AI應用釋出到AI市場，合作共赢，共建網絡AI生态。
下面我們以“KPI異常檢測”App來示範一下如何使用一個開箱即用的App。
第一步：導入網元清單；
第二步：配置性能、告警資料源；
第三步：資料源關聯到App；
第四步：啟動App；
第五步：檢視大屏，分析故障。
AIOps使能園區網絡智能運維
那麼AIOps是如何解決園區中實際運維的呢？
（一）園區網絡建維模式
上圖為園區網絡的兩種建維模式：
2B和2C共用大網的OMC：目前的主流模式。企業去租用營運商的無線裝置及其他的一些裝置。這種模式的問題在于，終端由企業維護，網絡由營運商維護，那麼出現問題的時候很難厘清責任；另外一個問題是，營運商側的運維能力群組織構築大網2C的O域，難以支撐企業内網高SLA，強化客戶訴求。
2B和2C分開OMC（EMS）：企業采購5G CPE、無線、核心網等全部裝置進行維護，具備端到端的視圖。從工信部發文、VDF、奧迪園區及企業SLA保障來看，企業租用營運商頻譜或專用頻譜自建5G網絡會逐漸成為主流。
（二）業務場景和痛點分析：園區客戶需要簡單易用、多域融合的網絡運維
1. 典型網絡現狀
上圖是一個園區比較常見的一個視訊檢測的業務。我們可以看到，即便是一個最常見的業務，也大概十來個網元都會參與到其中，從5G的無線到傳輸到邊緣計算，甚至是核心網，都會去參與其中。
2. 園區應用
AIOps：企業運維新力量！
上圖列出了園區裡面常見的一些應用，包括邊緣的AI檢測、智能物流、室内定位等。所有的這些業務其實都和上一張圖類似，即任何一個簡單的業務都要涉及到多個域的參與。
那麼園區與營運商運維的差異是什麼呢？主要有以下三點：
使用者：缺乏專業的通信知識，網絡運維能力弱；
網絡：組網相對簡單，但涉及多域、無線、傳接、數通、IT等；
SLA：生産系統網絡端到端SLA合同要求高，7X24小時，99.99%。
是以，客戶如果是園區運維的話，有如下痛點：
技能：5G 2B引入使得網絡更加複雜，企業工程師缺乏相關技能，運維困難；
工具：缺乏有效的運維工具，複雜網絡問題定位需要跨域專家現場會診，成本高，耗時長。
總結來說，園區網絡跨域裝置需要實作資料融合，支撐端到端分析及呈現，最終實作企業ICT基礎設施的統一運維。而園區網絡涉及網絡裝置多，邊界模糊，需要有統一的跨域定界定位能力，加速生産網絡問題定位。
（三）傳統人工、工具化運維不能滿足園區網絡新需求，急需智能化轉型
根據上圖的資料，我們可以看到：
被動式運維：75%的問題都是由使用者發現而非主動檢測，如果由使用者發現，那麼使用者很可能就會投訴；
自動化程度低：企業成本中70%的營運成本屬于人力成本，成本激增；
故障解決困難：90%故障的恢複時間是用來做問題定位的，真正的問題修複時間占比非常小。
這樣看來，無論是從效率還是效果這兩方面去考慮，都有一個訴求就是引入人工智能去解決問題，使能網絡運維的預測、分析、決策的自動化閉環。
（四）跨域故障定位算法流程
上圖是跨域故障定位的算法流程。整個流程如下：
輸入：
- 告警：裝置上報的告警；
- Topo：組網Topo結構；
- 故障傳播圖：告警間的影響關系。
流程介紹：
- 降噪：過濾原始告警中的閃斷、震斷等數量多又無效告警；
- 聚合：對告警進行劃分，将Topo不相關的告警分開，可能相關（屬于同一故障）的告警聚合到一起，得到多個告警組；
- 識别定位：結合Topo、故障傳播圖，對每個告警組進行分析，識别出每個告警組中有幾個故障，每個故障的根因網元和根因告警；
- 診斷：對于每個故障告警診斷出故障的類型，例如：電源中斷。
輸出：
- 故障的根因
- 故障設計的告警
- 故障類型
- 故障恢複建議
（五）AIOps架構實作算法流程
以上講解了整個的算法流程，接下來，我們看看如果使用華為AIOps架構去實作算法流程。
1、快速配置資料源，編排流程
配置資料源：将無線、傳輸、核心網等多個域的告警接入，接入網絡拓撲資料；
流程編排：通用已有的原子能力，快速進行流程編排。
經過上述過程，可以完成“事件通知”功能，并将結果儲存到記錄集（即，資料庫），用于大屏展示。效果圖如下：
打開其中一條告警，可以看到如下資訊：
AIOps部署建議
根據前述的實踐，我們可以總結以下内容：
1、標明成熟場景，循序漸進部署AIOps
經過長期實踐，我們對AIOps部署失敗的主要原因做了如下總結：
資料上不來：資料分散在各個獨立系統之上，缺乏綜合采集管理手段。資料缺失，資料品質低下是造成AIOps效果欠佳的主要原因；
指令下不去：缺乏自動化運維工具，不能進行主動檢測，恢複操作；
模型不智能：不能有效的積累日常運維中的标注資訊，不能實作模型自學習。
是以，在部署失敗的基礎上，我們可以得出，如果要成功部署AIOps，我們需要：
從具備條件的成熟場景出發，循序漸進推進AIOps部署；
- 資料上的來，全面收集各種運維資料，提高資料品質；
- 指令下得去，AIOps後端對接現在自動運維工具，增強診斷手段和自動恢複能力；
- 有效積累标注資料，讓AIOps模型能不斷收到回報，具備自學習能力。
2、選擇成熟的AIOps服務
針對不同類型的企業，AIOps服務的選擇也是不盡相同，具體見下表：
華為AlOps服務降低網絡AI應用開發門檻，加速網絡AI應用落地。沉澱了10+開箱即用的智能APP，覆寫營運商網絡、園區網絡、資料中心網絡和IT應用等應用領域。預內建豐富的AI原子能力，覆寫故障預測、檢測、診斷、識别等環節。支援使用者零編碼開發AI應用，提升運維效率。