AI時代，我們離AIOps還有多遠？

AI 時代，AIOps 熱炒，這篇算是蹭個熱點：）。回到本行，我們運維應該關心的是什麼：

AIOps 到底是什麼？

AI 和 Ops 究竟是什麼關係？

AIOps 到底會帶來哪些改變（顛覆 or 提升）？

按照 Gartner 的定義，AIOps 是 Algorithmic IT Operations，但是在人工智慧時代，可能很多的人會把 AI 理解成 Artificial Intelligence，不去糾結定義，我覺得本質上，想要表達的意思是一樣的，就是讓運維具備機器學習和演算法的能力。

如果直觀的理解 AI 和 Ops 的關係，類比到人，AI 相當於人的大腦，我們手腳和軀幹是執行系統，大腦負責決策判斷，手腳軀幹負責完成大腦下發的動作指令。我們可以稍微停頓再思考一個場景，無人駕駛是怎麼樣的？

不難得到答案，AI 更多的是根據路況做決策判斷，然後將這些指令下發給汽車自身的駕駛系統（如左轉、右轉、倒車、油門、剎車等）。在一定條件下（如完善的交通規則、良好的公民素質等），基於海量的數據和優秀的演算法，機器學習做出的判斷會比人更加高效和準確（至少機器不會因為疲憊而造成反應遲鈍等等）。

解釋到這裡，以此類推，就不難理解 AI 和 Ops 的關係了。

「基於專家經驗」到「基於機器學習」的轉變

前面提到，AI 發揮的作用是，動態變化場景的複雜條件下，能夠做出高效準確的決策判斷。回到運維上來，我們現在常看到的監控告警、根因分析、日誌異常檢測、報警聚合、容量預測、故障預測等等，這些都是要基於海量的線上運行時數據，做出分析判斷的，所以在這一塊，我們會看到大量的跟 AI 結合的 AIOps 的解決方案，特別是智能監控。

而對於一些靜態化的配置（CMDB、應用配置管理等），或者按照標準的流程規範，按部就班就可以完成的事情，比如持續集成、發布和部署等等，這些其實就沒有必要硬跟 AI 本身扯上什麼關係了，但是不是也完全沒有任何關係呢？也不一定，後面會看到。

下面以智能監控方面的例子來說明一下，我理解的一整套的 AIOps 應該是什麼樣子。

參考說明：以下涉及機器學習演算法部分和部分截圖參考了前 APPDynamics 首席數據科學家、現銷售易技術 VP 趙宇辰老師近一年在 QCon 和 AS 上的主題分享內容，也有幸跟宇辰老師做過幾次面對面的交流，啟發很大。

本文涉及機器學習演算法部分只做簡單描述，詳細內容大家可以參考宇辰老師的演講內容，再就是需要花時間深入學習和研究了。

在 http://www.infoq.com/cn/，搜索趙宇辰即可

發現問題—機器學習演算法在異常檢測中的應用

從「基於專家（人）經驗」演化成「基於機器學習」的判斷和分析模式，舉個監控告警規則設定的例子：

通常處理一個問題，抽象出來就是以下三個環節，我們就從這三個環節一步步分析我們要做的具體的事情：

a、傳統模式下基於人的經驗，是基於固定閾值的設定，比如 CPU 高於 80% 就告警，Load 超過 Core 的 2 倍就告警等等，而這個 80% 和 2 倍，就是基於人的經驗設定的，說的高端一些是專家經驗。而這種經驗的適配性其實是很差的，不同的應用和場景的閾值可能又不一樣，大量個性化的配置就出現了，當達到一定規模時，人工基本是不可維護的。

b、發現了這種適配性不好，可以採用動態閾值判斷，比如 3-sigma，或者分段 3-sigma，這個時候演算法可以根據正態分布的概率，自動的調整告警閾值。但是，這樣的演算法容易忽略周期性和趨勢，比如大促時的各項監控值一定是非常高的，而春節等假期又是非常低的，這時的監控點的分布極有可能是在正態分布之外的，如下圖的個別節點就很難識別是否異常。

c、繼續改進，到這個階段，就可以引入一些機器學習演算法了，比如基於指數平滑的二次平滑、三次平滑演算法，基於分解的傅里葉分解、小波分解演算法等，基於深度學習的前饋神經網路、循環神經網路 RNN 演算法等，還有其它演算法等等，這個時候，演算法就需要通過大量的線上歷史數據進行訓練，以便得出相對準確的告警策略。

d、如此多的演算法，到底應該選擇那個？這個時候又引入了一類機器學習演算法，自動模型選取的分類演算法。多個演算法同時進行訓練，針對不同的場景，每一種演算法的效果會不同，這時根據與歷史結果的對比，調整每個演算法的權重，最終得出一個共同決策結果。如下圖所示：

在 c 和 d 階段，已經可以引入機器學習的演算法，並會通過大量歷史數據的訓練，讓演算法能夠相對準確的進行異常檢測，自動生成告警策略。

分析問題—RCA 根因分析

第一個階段是發現問題，這個階段是針對單個異常信息的，比如單個的 meric 異常、單個應用進程異常、單個應用日誌信息的異常等。但是實際情況下，通常一個部件發生異常，有可能會導致周邊依賴的部件會同時異常，而且會同時導致 N 個的指標異常和告警。

比如，DB 一條慢 SQL 超時，DB 會告警、依賴 DB 的應用因為連接阻塞也會告警，RT 告警、QPS 異常告警、Load 告警，JVM 告警等等多個指標異常，而且有可能一整個集群都在告警，收告警的人也很多，DBA、PE、開發、SA 等等，再複雜一點，同一時間點，可能還有線上變更操作，如應用在做發布、DB 在執行 DDL、DML 等等。

這個時候，在一個分散式系統里，我們發現了問題，但是問題根因在哪裡，就變得十分重要了，這個確認不了，就沒法進行止損和故障消除。而且這個定位過程一般是非常非常痛苦的，越漫長越痛苦，但凡處理過故障的同學都會有深刻的切身體會。之前我們通常只是說要做告警收斂，簡單和常見場景下靠人的經驗是容易判斷的，但是複雜情況下，還是得藉助機器學習相關的演算法，且系統越龐大、越複雜，靠人和專家會越來越無力。

這個時候就需要一套根因分析 RCA 框架來幫我們做這方面的分析工作，宇辰老師給出的建議是 Monitor Everything，然後根據相關性和決策樹方面的演算法進行根因分析，這塊從分享內容看，在業界也是有比較成熟的分析演算法。下面給出我的理解，直接看下圖：

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！