AIOps：企業運維新力量！
摘要：企業運維需求及挑戰，來看看華為AIOps如何解決！
本文分享自華為雲社區《【雲駐共創】AIOps？企業運維新力量！》，原文作者：啟明。
國際慣例，我們先介紹一下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. 園區應用
上圖列出了園區裡面常見的一些應用，包括邊緣的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應用，提升運維效率。
