如何判斷系統的穩定性
雲智慧 AIOps 社群是由雲智慧發起，針對運維業務場景，提供演算法、算力、資料集整體的服務體系及智慧運維業務場景的解決方案交流社群。該社群致力於傳播 AIOps 技術，旨在與各行業客戶、使用者、研究者和開發者們共同解決智慧運維行業技術難題，推動 AIOps 技術在企業中落地，建設健康共贏的AIOps 開發者生態。
引言
近年來，隨著IT系統監控能力的日益成熟，IT系統執行時問題的根因分析領域吸引了很多研究者的目光。本文透過調研大量運維領域根因分析的相關文獻，並結合運維的實際需要，將根因分析問題進行了拆解，並對各子問題的解決方案進行了總結和分析。
一、IT系統及其穩定性的概念及抽象
IT系統，即IT基礎設施。其定義千差萬別，但一般認為是包括運營整個組織所必需的一系列物理裝置和應用軟體的集合，也包括由管理層預算所決定的組織範圍內的人和技術能力的服務集合。業界經常提到的資訊科技硬體、軟體、服務方面的投資，其實就是IT基礎設施。對於企業來說，這些設施能夠為客戶服務、與供應商建立聯絡和內部管理提供基礎。IT基礎設施的支出往往佔到大型企業資訊科技支出的25%-30%。IT系統運維的任務要儘可能保證服務執行環境的穩定性——即在有限的IT基礎設施所提供的資源條件內，保證服務得以平穩執行。如圖1所示，透過監控系統執行狀態（狀態監控），運維人員需要分析其中的故障點（故障檢測），並透過回溯排查問題的源頭（根因分析），進而對系統進行管理（控制策略及控制訊號生成），以使系統執行恢復正常或保持平穩。
根因分析作為 IT 執行的重要組成部分，旨在找出哪些事件真正觸發了 IT 系統中的現象或症狀。與臨床診斷類似，操作人員透過綜合分析指標資料和系統日誌，判斷系統的主要問題在哪裡，從而實現故障定位。
在很多企業當中，出於對控制成本，維持服務穩定等方面的考慮，根因分析技術是有巨大需求的。良好而成熟的根因分析技術可以幫助系統的運維人員快速定位到系統問題，從而加快問題的修復速度，以儘量小的代價解決IT系統在執行過程中遇到的問題，增加系統的平穩執行時間，減少企業損失。
在上圖中，根因分析作為問題發現模組和問題解決模組之間的樞紐環節，起到非常重要的作用。一方面，當今的IT系統十分複雜，系統動輒上千節點，且節點之間的結構和功能高度耦合，單點的問題也往往有相當大的影響範圍，使得運維人員往往無法直接確定系統的故障點。另一方面，為了化解系統故障帶來的影響，運維人員修復系統需要以根因分析的結果作為依據來對症下藥，使得系統得以在儘可能短的時間內恢復正常。
傳統運維需要透過人工方式進行。運維人員在該階段排查故障根因往往需要經歷艱辛的過程，需要透過檢視系統日誌、監控指標，瞭解系統狀態，才能推斷系統故障的原因所在。而隨著自動化運維的發展，系統的自動監控和資訊收集日趨完善，運維人員對系統的監控越來越直觀，且實時化程度大大提高。在面對小型IT系統時，自動化運維極大地加強了運維人員對系統的掌控能力，得以減少運維人員在縮小問題根因範圍方面所投入的工作量。但與此同時，隨著DevOps和雲技術的發展，IT系統的規模變得越來越大，一個獨立系統擁有上千節點已不算罕見。另外，服務的微服務化也使得IT系統的結構變化越來越迅速，系統結構對於大型系統的根因分析，由於監控資料量龐大，僅僅依靠運維人員來進行根因分析便顯得捉襟見肘。
由於人工排障仍然具有諸多不足，自動化的根因分析能力便成了大家關注的熱點。自動化的根因分析，是利用演算法對給定的故障問題進行自動化分析，輸出推薦結果來輔助運維人員排查系統問題的過程。實現自動化的根因分析，可以減輕運維人員的工作負擔，減少系統問題的平均修復時間，提高系統的平均可用時長。另外，對於C端的企業來說，它更是減少客戶投訴，減少運維成本，進而提高經濟效益的重要手段。
二、根因分析思路與方法總結
根因分析（root cause analysis）一詞本不是運維的發明。在IT領域裡，根因分析起初是指分析導致程式執行異常的問題點，即我們平時所說的“找bug”。後來，隨著運維與開發變得越發密不可分，開發口中的根因分析一詞也逐漸拓展到了運維行業，演變成我們現在理解的IT運維中的根因分析。
顧名思義，根因分析是一個從問題現象探究到問題本質的過程。根據IT運維本身的特點，根因分析問題可以進一步分成兩部分。首先，我們需要從宏觀層面上確定問題發生的位置，給出相關的位置資訊和大致的問題範圍；這個過程我們稱之為根因範圍壓縮。其次，我們要根據根因範圍壓縮的結果對單點進一步進行排查，具體定位到節點上的問題事件，為運維人員解決問題提供相關的邏輯證據；這個過程我們稱之為根因事件查詢。
在下面的篇幅中，我們分別介紹目前已有的針對根因範圍壓縮和根因事件查詢的思路和方法，並對各方法的優缺點進行簡單的分析。
1、根因範圍壓縮方法
根因範圍壓縮的主要目的是從IT系統龐大的監控資料當中篩查出問題的主要故障點。因此，該過程中所用的方法主要以資料驅動為主，運維邏輯為輔，透過資料的統計特徵和運維經驗的結合來篩選出問題源頭的範圍。由於資料驅動的模型和方法不可避免地會受到資料質量的影響，因此該過程也需要對結果的可信程度進行估計。
基於分類器的模型，例如決策樹、支援向量機（二分類模型）、神經網路（二分類或多分類）等模型，將系統狀態轉換為特徵，透過對系統的特徵和特徵之間的隱含邏輯進行學習，從而對系統所處的狀態和對應的根因範圍進行判斷。
透過統計學習或機器學習的手段，分類器模型都可以很方便地進行對系統約束關係的自動抽取，從而推斷出不同情況下的根因範圍，因此該類模型具有較好的適用範圍：只要能對系統的特徵進行提取和對資料進行標註，往往可以使用該類模型進行根因範圍壓縮。但隨之而來的是，基於分類器的方法普遍具有結果可解釋性比較差的問題，且系統知識隱含在模型結構中；對於根因分析問題，我們很難驗證模型所學到的“運維知識”是否真實存在。另一方面，目前我們還未發現有較為有效的特徵提取和篩選的通用方法。對於不同的運維資料，需要關注哪些特徵來解決根因範圍壓縮的問題，也需要經過一定時間的積累。因此，此類方法對系統監控資料的數量和質量是有一定的要求的。
此外，還有一類較為常見的模型例如馬爾可夫模型，隨機Petri網等，透過對系統結構的模擬，利用內建在模型中的運維經驗對根因範圍進行估計。此類模型的特點是，以資料為導向，透過圖模型搭建系統的大致框架，而後透過機器學習的手段確定模型中轉移關係的機率分佈，從而自動生成運維知識的機率模型。在此類模型中有現階段比較流行的根因分析思路，即在節點或指標的關聯拓撲上，利用統計學習進行系統建模，而後將運維經驗設計為演算法邏輯進行根因範圍壓縮。例如，一些方法利用故障的分佈特徵對根因位置進行識別，其前提假設為，如果大量異常業務經過某節點，則該節點成為根因的可能性會更大。該系列方法將系統模型與運維經驗結合起來，可以起到較好的根因範圍壓縮效果。
總的來說，資料驅動的方法在縮小根因範圍方面確實可以起到一定的作用，但其在大部分場景下依然無法對後續分析提供足夠的幫助，對問題細節的展現並不充分。在更深層次上，因為“因果性”與“相關性”兩個概念之間差異難以彌合，演算法所抽取的相關性與系統故障傳播的因果關係較難進行良好的對應。運維經驗在演算法中的融合可以適當地拉近根因分析中“因果性”和“相關性”的距離，但仍不足以使運維人員獲取足夠的資訊進行問題的修復。因此，只有根因範圍壓縮的能力，我們仍然需要部分的人工問題排查，很難實現IT系統控制閉環的自動化。
2、根因事件查詢方法
目前對根因事件查詢問題的解決方法較為少見，學術界對此問題的討論並不充分。貝爾實驗室早在1999年提出了一個基於事件推理的根因分析框架。該框架提出了基於事件關係圖的根因推理方法，並且考慮了不完全資訊下的根因推理問題以及時序資訊的引入對事件關係圖建模能力的影響。該方法對現今的智慧運維根因分析有很好的指導和借鑑意義，但可惜的是，後來對該方向的深入研究大部分轉到了Petri Net上，漸漸地脫離了現在的運維場景——從分析運維資源佔用情況的角度講，這樣的方法仍然可以解決一部分簡單系統的運維問題，但隨著運維繫統規模越來越大，服務的數量越來越多，資源的佔用情況越來越複雜，基於Petri Net的分析慢慢的開始變得無力。
可以預見，直接以資源佔用的細節開始進行運維故障的分析會給分析引擎帶來極大的負擔。另一個有趣的想法來自一篇於2012年發表在IEEE/ACM ToN上的論文。這篇論文中提到的G-RCA系統是根因分析的一種很好的思路——透過分析系統事件之間的關係來構建事件的因果圖，而後利用不同的推理方法來進行根因事件分析。其中介紹的知識抽取方法，對於解決和刻畫運維領域的根因分析問題也相當有借鑑意義。另外，其他一些基於SAT理論，誘導邏輯程式（機率模型或確定模型）等的根因推理的框架或模型，也在部分研究中提到過，但因推理的複雜度過高（尤其是一些非on-the-fly的方法）或與運維場景的需求相去甚遠，並未有在IT運維場景落地的前景。
開源福利
雲智慧已開源資料視覺化編排平臺 FlyFish 。透過配置資料模型為使用者提供上百種視覺化圖形元件，零編碼即可實現符合自己業務需求的炫酷視覺化大屏。 同時，飛魚也提供了靈活的拓展能力，支援元件開發、自定義函式與全域性事件等配置， 面向複雜需求場景能夠保證高效開發與交付。
點選下方地址連結，歡迎大家給 FlyFish 點贊送 Star。
GitHub 地址： https：//github。com/CloudWise-OpenSource/FlyFish
Gitee 地址：https：//gitee。com/CloudWise/fly-fish