AIOps須要翻越的「三座大山」

最近AIOps火熱的就像8月裏的盛夏，運維圈子裏的每個人都在討論着AIOps，彷彿不聊點AIOps的東西，就透着那麼out。原來作運維產品的一衆廠商也像打了雞血似的，紛紛推出花樣繁多的AIOps產品，彷彿AIOps是什麼傳說中的靈丹妙藥，一試就靈、包治百病同樣。

Gartner更是推波助瀾，頗爲大膽的預測到2022年，將有超過40%的企業會採用AIOps平臺技術。睿象科技從18年初開始投入研發力量作AIOps平臺，轉眼間一年時間過去了，期間遇到了各類不曾預期的挑戰，想起來實在是五味雜陳，溢於言表。

不過總算天道酬勤，到如今爲止，咱們已經成功實施四個商業案例了。淌過這麼多坑，對AIOps算是有了些更深刻的體會，過節這幾天閒暇無事，就和諸位聊聊，也算給你們提個醒吧。

AIOps平臺一應俱全，包含異常檢測，異常定位，根因分析，容量規劃，故障預測，模式識別，告警壓縮等等各類「豪華大招」。貌似感受有了AIOps平臺，運維工程師不再用苦逼哄哄了，然而理想豐滿，現實卻骨感，要實現咱們的理想，甚至說只是部分實現，都是一個極具挑戰的系統工程，我的感受至少要翻越「三座大山」。

第一座大山：數據採集

衆所周知，要實現好智能運維，全方位，實時，多維度，全量地對運維數據採集採集，是全部工做的第一步，可是這第一步可很差走。

一個典型的AIOps企業級用戶，大多數狀況都有比較完整的運維體系，並且經年累月，積累並實施了不少成熟的運維工具，從傳統網管，基礎架構監控，網絡監控，流量監控，工單系統，日誌監控，到最流行的APM，從國外的大廠IBM BMC的 Tivoli，OpenView，再到國內的OneAPM，摩卡，天旦，還有開源的Zabbix, Catti ，ELK 等，應有盡有。要在不少軟件都已經沒有，要將相應的數據導入到AIOps平臺中，相應的工做量可想而知。

更要命的是，不少軟件，特別是老舊一點的運維產品，是沒有公開的數據接口的，某些工具，即便經過各類方法把數據取出來，發現其數據也是不許確，或者是非實時的。

咱們在碰到這類問題的時候，就會先幫着企業梳理已有的數據採集工具，能接的所有接上，創建相應的數據模型，若是沒有相應的數據維度，則建議企業購買相應的數據採集工具來補足能力。

第二座大山：數據中臺

數據中臺概念最先是由阿里提出來的，是指以服務爲導向，對海量數據進行採集、計算、存儲、加工的一系列技術集合；這個概念一般有優先應用於與公司經營決策運行的業務數據，可是隨着AIOps的概念的出現，接入海量多種類的IT 數據，所帶來的數據存儲，計算，加工問題，一般會困擾到運維團隊。

在國外，如Gartner的定義中，就沒有數據中臺的概念，但國外在談到這塊的時候，會用Data lakes 來進行進行陳述，這個IT數據湖對數據處理的要求，有着本身的特色，主要有着如下的挑戰：

海量存儲和可擴展性的挑戰

通常中小金融機構的IT數據中心，在AIOps平臺建設的初期，接入的數據量天天就可能達到就在1TB以上，而隨着客戶對平臺價值的理解， 客戶將會更多類型的數據，特別是接入例如Wire Data, Tracing Data後，數據量必將會有爆炸性的增加，達到接近50TB天天，甚至突破100TB天天。

數據類型多樣挑戰

從IT監控運維的角度來講，AIOps 接入的數據包括，時序指標數據，日誌數據，網絡抓包數據，事務鏈數據，IT事件數據等等，從底層技術維度來看這些數據，能夠把這些數據理解爲，時序數據，半結構化數據，DAG圖數據，結構化數據，很明顯，要對這些這麼多樣化數據進行存儲和分析，只用一種數據存儲引擎是不夠的，選擇合適的數據存儲引擎，如何將多個數據引擎進行有機結合，是一個考驗。

多樣化的分析需求挑戰

AIOps監控運維，分析場景衆多，維度複雜，在業務監控這塊，部分還有很強的關聯關係，還要結合一些傳統的機器學習算法進行分析，致使了平臺起碼要支持如下的分析能力：

• 流計算處理能力：用於對數據進行實時內存計算，在事件窗口內，實現相似於關聯，復瑣事件處理等計算
• 多維半結構化數據實時過濾匯聚能力：用於對日誌這種半結構化，維度不固定，有大量的數據須要被提取，須要進行實時分析匯聚
• 時序指標數據處理能力：針對KPI的時序特性，實現高效存儲實時匯聚
• 經典機器能力：支持如線性迴歸，SVM，決策樹等，Kmean 等算法
• 深度學習能力：LSTM , RNN ，CNN 等深度算法，相關算法須要從大量標註過的歷史數據進行訓練學習，相關的算法，要能訪問到遠比實時，近線數據數據量大的多的歷史數據，進行相應的訓練。

數據治理挑戰

能夠想象，咱們往這個數據湖裏頭，灌了那麼多不一樣類型的，不一樣結構的數據後，若是沒有合適的治理，這數據湖將確定會變成一個泥潭，因此須要如下的治理能力。

• 元數據管理：在商業智能上，這一塊相對已經有了很多的實踐，可是在IT數據中，業界探索纔剛剛開始，咱們看到，Elastic公司剛剛開源了一個小項目，叫Elastic Common Schema，用意就是針對IT數據，定義一套通用的Schema，便於關聯，以及後繼的分析。可是這個東西目前仍是比較稚嫩，或者說，在咱們不少的場景下。
• 數據生命週期管理：數據量龐大，須要將過時的數據，遷移合適的歷史數據存儲上。不少狀況下，還須要將部分的歷史數據，以粗粒度的形式進行匯聚後，丟棄細粒度原文。有的還須要進行永久保存，例如一些合規要求的交易日誌，所以，必然須要有相應的歷史數據管理方案
• 數據流向管理：數據在平臺內部， 必然要作相關的流轉，關聯，處理，須要對相應的數據流向流動，進行管控，保證數據加工的準確性。
• …

能夠看到，這個數據中臺的能力，是整個AIOps平臺的核心，架構，實現的難度很是大， 很是考驗架構師的功力。

第三座大山：就是算法

算法的挑戰主要來自如下幾個方面，分別是人，指望，適用場景，工程化。

人

這裏的人，不單只是算法研究員，而是完整的從產品，算法，研發，運維，測試的有機合做，造成完整的團隊，才能從運維場景出發，爲算法找到這個相應的落腳點，並經過產品設計，研發編碼，運維及測試的配合，才能很好的進行落地。

指望

客戶對相應的場景的合理預期，是算法落地的關鍵。不管是廣義的AI，仍是AIOps裏頭的智能算法，都距離大衆的指望值有較大的距離，而如今媒體還處於對於AI算法的炒做期階段，因此這裏就會引起出較大落差。在項目初始階段，須要進行充分，反覆的溝通，讓雙方都能理解到，在目前的階段，算法的實踐仍是屬於前沿探索行爲，在特定的場景下，有必定的效果，並且在落地的過程當中，必定有各類的問題，須要一塊兒去探索。

適用場景

離開用戶適用場景，去談AIOps算法，就是耍流程。在剛開始，進行算法研究的時候，咱們的算法研究員是獨立對算法進行研究的，結果發現，經過新研究的算法，從技術上來講，目標是達到了，可是從業務上來講，這個結果，對於運維人員來講，自己就是顯而易見的，就是說在這個場景中，用算法算出的的結果，毫無心義。所以，咱們在往後的算法探索，第一步就是與運維人員及客戶，把相應的運維場景進行明確。

而在項目真正項目實踐過程當中，咱們在於客戶互動的狀況下，咱們發現，其實在不少時候，客戶所想要的智能化，並不必定須要用到多複雜的算法，例如， 咱們用了多個很常見算法，甚至不是機器學習的算法， 在客戶海量的告警數據下， 對進行了壓縮，減小了告警風暴，給客戶帶來了很是實際的價值。 所以，根據場景找到合適的算法，並進行落地，是算法落地的關鍵一步。

工程化

咱們發現了，不少的算法及模型，在進行實驗的時候很不錯，可是要進行生產，將算法遷移到生產環境中，就會發現有很多的問題，最廣泛的是，計算量巨大，致使計算沒有辦法作到實時，又或者因爲沒有考慮到一些制約因素，沒有選用對合適的數據讀取方法，致使運行緩慢，甚至程序崩潰。

從客觀上來講，不少的算法研究員編碼及工程化能力不太強，這基本上是一個廣泛現場，畢竟術業有專攻；另外以一方面，這也是工程化和產品化的一部分，須要，算法研究員與架構師一塊兒，將算法的實現進行重構， 並進行產品化，工程化。

總結

路慢慢其修遠兮，吾將上下而求索。在追求運維智能化的道路上，註定不會平坦，以上就是咱們團隊在作AIOps產品時通過的「三座大山」，但願能對你們有所幫助，若是你們想要更多的瞭解有關AIOps的知識，歡迎訪問www.AIOps.com。