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。