基於機器學習的智慧運維
當代社會的生產生活，許多方面都依賴於大型、複雜的軟硬體系統， 包括網際網路、高效能運算、電信、金融、電力網路、物聯網、 醫療網路和裝置、航空航天、軍用裝置及網路等。這些系統的使用者都期待有好的體驗。 因而，這些複雜系統的部署、執行和維護都需要專業的運維人員，以應對各種突發事件，確保系統安全、可靠地執行。由於各類突發事件會產生海量資料，因此，智慧運維從本質上可以認為是一個大資料分析的具體場景。
圖1展示了智慧運維涉及的範圍。它是人工智慧、行業領域知識、運維場景領域知識三者相結合的交叉領域，離不開三者的緊密合作。
圖1 智慧運維涉及的範圍
智慧運維的歷史
手工運維：早期的運維工作大部分是由運維人員手工完成的，那時，運維人員又被稱為系統管理員或網管。他們負責的工作包括監控產品執行狀態和效能指標、產品上線、變更服務等。因此，單個運維人員的工作量，運維人員的數量都是隨著產品的個數或者產品服務的使用者規模呈線性增長的。此時的運維工作消耗大量的人力資源，但大部分運維工作都是低效的重複。這種手工運維的方式必然無法滿足網際網路產品日新月異的需求和突飛猛進的規模。
自動化運維：運維人員逐漸發現，一些常見的重複性的運維工作可以通過自動化的指令碼來實現：一部分自動化指令碼用以監控分散式系統，產生大量的日誌;另外一部分被用於在人工的監督下進行自動化處理。這些指令碼能夠被重複呼叫和自動觸發，並在一定程度上防止人工的誤操作，從而極大地減少人力成本，提高運維的效率。這就誕生了自動化運維。自動化運維可以認為是一種基於行業領域知識和運維場景領域知識的專家系統。
運維開發一體化：傳統的運維體系將運維人員從產品開發人員中抽離出來，成立單獨的運維部門。這種模式使得不同公司能夠分享自動化運維的工具和想法，互相借鑑，從而極大地推動了運維的發展。然而，這種人為分割的最大問題是產生了兩個對立的團隊——產品開發人員和運維人員。他們的使命從一開始就截然不同：產品開發人員的目標是儘快地實現系統的新功能並進行部署，從而讓使用者儘快地使用到新版本和新功能。運維人員則希望儘可能少地產生異常和故障。但是經過統計發現，大部分的異常或故障都是由於配置變更或軟體升級導致的。因此，運維人員本能地排斥產品開發團隊部署配置變更或軟體升級。他們之間的目標衝突降低了系統整體的效率。此外，由於運維人員不瞭解產品的實現細節，因此他們在發現問題後不能很好地定位故障的根本原因。為了解決這一矛盾，DevOps 應運而生。DevOps 最核心的概念是開發運維一體化，即不再硬性地區分開發人員和運維人員。開發人員自己在程式碼中設定監控點，產生監控資料。系統部署和執行過程中發生的異常由開發人員進行定位和分析。這種組織方式的優勢非常明顯：能夠產生更加有效的監控資料，方便後期運維;同時，運維人員也是開發人員，出現問題之後能夠快速地找出根因。谷歌的站點可靠性工程(Site Reliability Engineering, SRE)就是 DevOps 的一種特例。
智慧運維 ( ofollow,noindex" href="http://www.aiops.com/">AIOps ， Artificial Intelligence for IT Operations)： 自動化運維在手動運維基礎上大大提高了運維的效率，DevOps 有效地提升了研發和運維的配合效率。但是，隨著整個網際網路系統資料規模的急劇膨脹，以及服務型別的複雜多樣，“基於人為指定規則”的專家系統逐漸變得力不從心。因為，自動化運維的瓶頸在於人腦：必須由一個長期在一個行業從事運維的專家手動地將重複出現的、有跡可循的現象總結出來，形成規則，才能完成自動化運維。然而，越來越多的場景表明，簡單的、基於人為制定規則的方法並不能夠解決大規模運維的問題。
與自動化運維依賴人工生成規則不同，智慧運維強調由機器學習演算法自動地從海量運維資料(包括事件本身以及運維人員的人工處理日誌)中不斷地學習，不斷地提煉並總結規則。換句話說， 智慧運維在自動化運維的基礎上增加了一個基於機器學習的大腦，指揮著監測系統採集大腦決策所需的資料，做出分析、決策並指揮自動化指令碼去執行大腦的決策，從而達到運維繫統的整體目標(見圖2)。Gartner Report 預測 AIOps 的全球部署率將從2017年的10%增加到2020年的50%。
圖2 智慧運維與自動化運維的最大區別是有一個基於機器學習的大腦
智慧運維現狀
關鍵場景與技術
圖 3顯示了智慧運維包含的關鍵場景和技術 ，涉及大型分散式系統監控、分析、決策等。
圖3 智慧運維的關鍵場景和技術
在針對歷史事件的智慧運維技術中，瓶頸分析是指發現制約網際網路服務效能的硬體或軟體瓶頸。熱點分析指的是找到對於某項指標(如處理服務請求規模、出錯日誌)顯著大於處於類似屬性空間內其他設施的叢集、網路裝置、伺服器等設施。KPI 曲線聚類是指對形狀類似的曲線進行聚類。KPI 曲線關聯挖掘針對兩條曲線的變化趨勢進行關聯關係挖掘。KPI 曲線與報警之間的關聯關係挖掘是針對一條KPI曲線的變化趨勢與某種異常之間的關聯關係進行挖掘。異常事件關聯挖掘是指對異常事件之間進行關聯關係挖掘。全鏈路模組呼叫鏈分析能夠分析出軟體模組之間的呼叫關係。故障傳播關係圖構建融合了上述後四種技術，推斷出異常事件之間的故障傳播關係，並作為故障根因分析的基礎，解決微服務時代 KPI 異常之間的故障傳播關係不斷變化而無法通過先驗知識靜態設定的問題。通過以上技術，智慧運維繫統能夠準確地復現並診斷歷史事件。
針對當前事件，KPI 異常檢測是指通過分析 KPI 曲線，發現網際網路服務的軟硬體中的異常行為，如訪問延遲增大、網路裝置故障、訪問使用者急劇減少等。異常定位在KPI被檢測出異常之後被觸發，在多維屬性空間中快速定位導致異常的屬性組合。快速止損是指對以往常見故障引發的異常報警建立“指紋”系統，用於快速比對新發生故障時的指紋，從而判斷故障型別以便快速止損。異常報警聚合指的是根據異常報警的空間和時間特徵，對它們進行聚類，並把聚類結果傳送給運維人員，從而減少運維人員處理異常報警的工作負擔。故障根因分析是指根據故障傳播圖快速找到當前應用服務 KPI 異常的根本觸發原因。故障根因分析系統找出異常事件可能的根因以及故障傳播鏈後，運維專家可以對根因分析的結果進行確定和標記，從而幫助機器學習方法更好地學習領域知識。這一系統最終達到的效果是當故障發生時，系統自動準確地推薦出故障根因，指導運維人員去修復或者系統自動採取修復措施。
關鍵技術示例
KPI 瓶頸分析
為了保證向千萬級甚至上億級使用者提供可靠、高效的服務，網際網路服務的運維人員通常會使用一些關鍵效能指標來監測這些應用的服務效能。比如，一個應用服務在單位時間內被訪問的次數(Page Views, PV)，單位時間交易量，應用效能和可靠性等。KPI 瓶頸分析的目標是在 KPI 不理想時分析系統的瓶頸。一般監控資料中的關鍵指標有很多屬性，這些屬性可能影響到關鍵指標，如圖4所示。
圖4 KPI 及影響因素
當資料規模較小時，運維人員通過手動過濾和選擇，便能夠發現影響關鍵效能指標的屬性組合。但是，當某個關鍵指標有十幾個屬性，每個屬性有幾百億條資料時，如何確定它們的屬性是怎樣影響關鍵效能指標的，是一個非常有挑戰性的問題。顯然，採用人工的方式去總結其中的規律是不可行的。因此，需要藉助於機器學習演算法來自動地挖掘資料背後的現象，定位系統的瓶頸。
針對這一問題，學術界已經提出了層次聚類、決策樹、聚類樹(CLTree)等方法。FOCUS [1]通過對資料預處理，把 KPI 分為“達標”和“不達標”兩類，從而把KPI瓶頸分析問題轉化為在多維屬性空間中的有監督二分類問題。由於瓶頸分析問題要求結果具備可解釋性，因此 FOCUS 採用了結果解釋性較好的決策樹演算法。該演算法較為通用，可以針對符合圖4所示的各類資料進行瓶頸分析。
KPI 異常檢測
KPI 異常檢測是網際網路服務智慧運維的一個底層核心技術。大多數上述智慧運維的關鍵技術都依賴於 KPI 異常檢測的結果。
當 KPI 呈現出異常(如突增、突降、抖動)時，往往意味著與其相關的應用發生了一些潛在的故障，比如網路故障、伺服器故障、配置錯誤、缺陷版本上線、網路過載、伺服器過載、外部攻擊等。圖 5 展示了某搜尋引擎一週內的PV資料，其中紅圈標註的為異常。
圖5 KPI 異常示例：某搜尋引擎 PV 曲線的異常
因此，為了提供高效、可靠的服務，必須實時監測 KPI，以便及時發現異常。同時，那些持續時間相對較短的 KPI 抖動也必須被準確檢測出來，以避免未來的經濟損失。
目前，學術界和工業界已經提出了一系列KPI異常檢測演算法。這些演算法可以概括地分成基於視窗的異常檢測演算法，例如奇異譜變換(singular spectrum transform);基於近似性的異常檢測演算法;基於預測的異常檢測演算法，例如 Holt-Winters方法、時序分解方法、線性迴歸方法、支援向量迴歸等;基於隱式馬爾科夫模型的異常檢測演算法;基於分段的異常檢測演算法;基於機器學習(整合學習)的異常檢測演算法[2]等類別。
故障預測
現在，主動的異常管理已成為一種提高服務穩定性的有效方法。故障預測是主動異常管理的關鍵技術。故障預測是指在網際網路服務執行時，使用多種模型或方法分析服務當前的狀態，並基於歷史經驗判斷近期是否會發生故障。
圖 6 顯示了故障預測的定義。在當前時刻，根據一段時間內的測量資料，預測未來某一時間區間是否會發生故障。之所以預測未來某一時間區間的故障，是因為運維人員需要一段時間來應對即將發生的故障，例如切換流量、替換裝置等。
圖6 故障預測定義
目前，學術界和工業界已經提出了大量的故障預測方法。大致可分為幾個類別：
• 故障蹤跡。其核心思想是從以往故障的發生特徵上推斷即將發生的故障。發生特徵可以是故障的發生頻率，也可以是故障的型別。
• 徵兆監測。通過一些故障對系統的“副作用”來捕獲它們，例如，異常的記憶體利用率、CPU 使用率、磁碟 I/O、系統中異常的功能呼叫等。
• 錯誤記錄。錯誤事件日誌往往是離散的分類資料，例如事件 ID、元件 ID、錯誤型別等。
智慧運維所用到的機器學習演算法
在智慧運維文獻中較為常見的演算法包括邏輯迴歸、關聯關係挖掘、聚類、決策樹、隨機森林、支援向量機、蒙特卡洛樹搜尋、隱式馬爾科夫、多示例學習、遷移學習、卷積神經網路等。在處理運維工單和人機介面時，自然語言處理和對話機器人也被廣泛應用。
智慧運維繫統在演進的過程中，不斷採用越來越先進的機器學習演算法。
基於網際網路的視訊流媒體(如 QQ 視訊、優酷、愛奇藝、Netflix 等)已經逐漸滲透到人們的日常生活中。在網路領域頂級會議中也湧現了很多學術界和工業界合作的智慧運維案例，如卡內基梅隆大學的系列工作：SIGCOMM’11論文[3]利用不同資料分析及統計分析方法，靈活使用視覺化(visualization)、相關分析(correlation)、資訊熵增益(information gain)等工具，將雜亂無章的資料轉化為直觀清晰的資訊，從而分析出海量資料背後的視訊體驗不佳的規律和瓶頸;SIGCOMM’12論文[4]為視訊傳輸設計了一個“大腦”，根據視訊客戶和網路狀況的全域性資訊，動態地優化視訊傳輸;SIGCOMM’13論文[5]通過決策樹模型建立視訊流媒體使用者參與度的預測模型，指導關鍵效能指標的優化策略，最終有效地改善了視訊流媒體使用者的體驗質量;NSDI’17論文[6]將視訊質量的實時優化問題轉化為實時多臂老虎機(multi-armed bandits)問題(一種基礎的強化學習方法)，並使用上限置信區間演算法(upper confidence bound)有效解決了這一問題。這一系列論文，見證了智慧運維不斷演進之路。
智慧運維未來展望
多個行業領域都表現出對智慧運維的強烈需求。但是，他們主要在各自行業內尋找解決方案。同時，受限於所處行業運維團隊的開發能力，他們往往對所處行業內的運維團隊提出相對較低的需求——這些需求一般停留在自動化運維的階段。如果各行業領域能夠在深入瞭解智慧運維框架中關鍵技術的基礎上， 制定合適的智慧運維目標，並投入適當的資源，一定能夠有效地推動智慧運維在各自行業的發展。同時，在智慧運維通用技術的基礎上，各行業領域的科研工作者也可以在解決所處行業智慧運維的一些特殊問題的同時，拓寬自身的科研領域。
在基於機器學習的智慧運維框架下，機器將成為運維人員的高效可靠助手。但是，人的作用仍處於主導地位。在智慧運維的框架下，運維工程師逐漸轉型為大資料工程師，負責搭建大資料基礎架構，開發和整合資料採集程式和自動化執行指令碼，並高效實現機器學習演算法。 同時，在面對所處行業的智慧運維需求時，智慧運維工程師可以在整個智慧運維框架下跨行業地尋找關鍵技術，從而能夠更好地滿足本行業的智慧運維需求，達到事半功倍的效果。這種從普通工程師到大資料工程師(智慧運維工程師)的職業技能轉型對運維工程師是非常具有吸引力的。
智慧運維的基石是機器學習和人工智慧。 相比人工智慧在其他領域的應用，智慧運維幾乎完美地擁有一個有前景的人工智慧垂直應用領域必備的要素： 實際應用場景、大量資料、大量標註。智慧運維幾乎所有的關鍵技術都離不開機器學習演算法;工業界不斷產生海量運維日誌;由於運維人員自身就是領域專家，其日常的工作就會產生大量的標註資料。海量的資料和標註降低了研究機器學習演算法的門檻，有益於演算法研究快速取得進展。因此，智慧運維可以說是機器學習領域一個尚未開採的“金礦”， 非常值得機器學習領域科研人員的關注和投入。
作為人工智慧的一個垂直方向，智慧運維的理論也將取得長足的進步。除了網際網路以外，智慧運維在高效能運算、電信、金融、電力網路、物聯網、 醫療網路和裝置、航空航天、軍用裝置及網路都有很好的應用。
參考文獻
[1]Liu D, Zhao Y, Sui K, et al. FOCUS: Shedding Light on the High Search Response Time in the Wild[C]//Proceedings of the 35th Annual IEEE International Conference on Computer Communications. IEEE Press, 2016:1-9.
[2] Liu D, Zhao Y, Xu H, et al.Opprentice: Towards Practical and Automatic Anomaly Detection Through Machine Learning[C]//Proceedings of the 2015 Internet Measurement Conference.New York: ACM Press, 2015:211-224.
[3] Dobrian F, Sekar V, Awan A, et al. Understanding the impact of video quality on user engagement[C]//ACM SIGCOMM Computer Communication Review. ACM, 2011, 41(4): 362-373.
MLA
[4] Liu X, Dobrian F, Milner H, et al. A case for a coordinated internet video control plane[C]//Proceedings of the ACM SIGCOMM 2012 conference on Applications, technologies, architectures, and protocols for computer communication. ACM, 2012: 359-370.
[5] Balachandran A, Sekar V, Akella A, et al. Developing a predictive model of quality of experience for internet video[C]//ACM SIGCOMM Computer Communication Review. ACM, 2013, 43(4): 339-350.
MLA
[6] Jiang J, Sun S, Sekar V, et al. Pytheas: Enabling Data-Driven Quality of Experience Optimization Using Group-Based Exploration-Exploitation[C]//NSDI. 2017: 393-406.
作者：AIOPstack
連結：https://www.jianshu.com/p/347b3459fef0