AIOps在攜程的探索與實踐-知識星球

攜程的應用數量眾多、架構複雜，規模效應和時間維度上的積累會導致運維資料（日誌、監控資料、應用資訊等）體量異常龐大，傳統基於經驗規則的方式已經不能很好地勝任某些特定的運維場景。特別是在大資料時代背景下，這種挑戰尤為嚴峻。

本文將分享攜程在AIOps方面的一些探索和典型的實踐場景，希望透過分享，讓大家對AIOps以及目前行業發展水平有個宏觀的認識，也給對AIOps感興趣的小夥伴一些借鑒和啟發。

運維面臨的挑戰

運維資料的體量隨著運維規模的快速增長呈現出爆髮式地增長。除了對持續交付、持續整合、資源排程、監控能力等提出很高的要求外，面對海量的運維資料，其查詢和獲取成本也變得非常高。

另外，運維資料的價值和資料成本之間如何平衡、如何取捨，以及如何挖掘有價值的資訊，也給運維提出了一定的挑戰。

AIOps的理解、定位和現狀

結合自身實踐以及透過對行業整體水平的分析，介紹下對AIOps的理解、定位和現狀，以及發展AIOps面臨的一些挑戰。

運維技術的發展趨勢

和運維行業中普遍的經歷一樣，攜程的運維方式主要經歷了：人肉運維的指令碼運維時代，針對特定運維場景的工具化運維時代，打通端到端應用交付的自動化運維時代，到現在正在進行中的智慧化運維時代。

AIOps屬於跨領域結合的技術，正式被提出是在2016年，隨後有多家網際網路公司參與實踐，2018年被業內稱為AIOps的元年。

運維人員構成轉變

行業中對人員的構成上也按照職能的側重點不同，劃分為運維工程師、運維開發工程師和運維AI工程師，大家專業領域不同，分工的側重也不同。

從個人理解看，這種劃分大多數情況下只是一種邏輯劃分，例如一個人可以身兼多種角色，而這種複合型的人才是目前非常緊缺的。

AIOps現狀及實踐內容

從行業分享的最佳實踐內容看，AIOps主要圍繞質量、效率和成本這三個方面展開，實踐包括異常檢測到診斷自愈，以及容量到成本的最佳化。

從行業整體實踐水平來看，目前的AIOps還處於初級階段，實踐的內容主要還是針對單個應用的場景展開。

發展AIOps的挑戰

因為是跨領域結合的技術，所以發展的難度也主要是兩個領域的知識都需要有比較深刻的理解和認識。資料質量和演演算法積累是一方面挑戰，複合型人才的稀缺是另一方面。

AIOps在攜程的探索與實踐場景介紹

單場景實踐方面羅列了幾個相對成熟的解決方案。

首先是應用監控指標的智慧異常檢測。傳統基於規則方式的告警泛化能力差，經常會導致告警漏告或者誤告，智慧告警是透過機器學習的方式替代傳統基於固定閾值的告警方式。

當檢測到應用指標異常之後，我們透過智慧應用診斷系統，診斷系統是基於專家經驗和相關性檢測等演演算法實現的故障分析診斷系統，可以快速定位故障根源，從而達到快速止損。

另一實踐場景是線上資源和離線作業之間的混合部署，基於對線上應用的資源和離線作業的畫像，分時動態地將離線作業排程到線上資源上執行，從而達到提升線上資源利用率的目的，同時也提高了離線作業的執行效率。

最後一個要介紹的是智慧彈性擴縮容，透過對線上資源構建容量模型，定期生成容量報告，根據容量報告自動執行擴容和縮容。

從AIOps整體架構設計和規劃方面，主要分為四個邏輯層實現。自頂向下分別包括：運維KPI層、運維場景解決方案層、平臺自動化層、以及底層基礎架構和資料監控層。

底層服務為上次的實現提供能力和平臺支撐，未來重點主要會放在平臺能力的建設和最佳化、以及更多智慧化運維場景的挖掘方面。

具體的實踐運維場景以監控時序的異常檢測和應用的智慧診斷為例展開介紹：

監控時序的異常檢測

資料體量很小的時候，基於規則的告警方式尚可勝任，當資料體量不斷增長之後，規則的泛化能力就會變弱。做監控時序的智慧異常檢測主要是為了提高告警的質量，減少誤報和漏告數量、提高告警的及時性、降低閾值管理的複雜度。

監控時序指標

首先總結下常見的監控時序指標，攜程是國內最大的線上旅遊網際網路公司，和大部分網際網路公司一樣，監控指標根據功能的不同主要分為以下幾類：

訂單指標，也是最核心的監控指標，從監控曲線看有非常強的週期性；
應用指標和業務指標，大部分是開發基於框架中介軟體做的一些業務埋點。這些指標正常情況下都會表現的很平穩，當有突髮狀況或異常時，指標會劇烈抖動；
基礎監控指標，涉及底層各種型別的監控，包括伺服器CPU、記憶體、磁碟IO、網路IO等指標，以及DB、Redis、代理、網路等相關監控指標。

異常檢測流程

前面提到了常見幾種監控時序型別，其中最能夠及時反映應用健康程度的就是應用的監控指標（錯誤數、請求量以及相應時間等），也是應用運維最關心的指標。

異常檢測實踐的主要內容也是在圍繞業務指標跟應用指標展開的，因為攜程的應用數量眾多，這部分指標的數量也是非常龐大，非常具有挑戰性。這裡我們主要介紹從資料流向的角度來介紹下時序指標的異常檢測。

資料源配置：對於一個通用的異常檢測平臺而言，待檢測的時序資料源可能存在不同的物理介質上，也可能是不同的系統中，為了避免對業務系統的侵入性，異常檢測的邏輯一般都是旁路來實現。首先需要將這些不同系統、不同儲存介質中的時序進行採集（資料源可以是DB、HBase、訊息、API、以及特定的監控系統等），在異常檢測平臺中儲存一段副本資料，留作構建資料倉庫使用。
資料集過濾：實踐中我們並不會對所有的資料集都配置智慧檢測演演算法，是因為在很多真實的場景中，有些指標很難用被異常檢測的演演算法檢測，主要的原因是資料質量不高，有演演算法經歷的道友應該都清楚，資料質量的好壞決定了演演算法效果的上限。我們會事先配置了一個資料集過濾模組，過濾掉一些資料質量不高的資料集。實現的原理主要是基於資料集的一階和二階統計量、偏度、峰度、資訊熵等指標，將滿足一定統計特性的資料集篩選到後續流程處理。
異常檢測演演算法集：針對預篩選環節過濾得到的資料集，我們準備了常見的異常檢測演演算法集，這些演演算法大都是通用的機器學習演演算法根據實際情況和需要做了一定的二次定製，更詳細的介紹我們會在接下來的內容中展開。
告警狀態機：這個模組的功能主要是將時序異常轉變為一個有效的告警。從事過監控告警的道友應該有類似的共識，異常資料從統計角度看只是離群較遠的分佈，能不能當做一個業務告警處理呢？大部分時候是需要業務同事來給出規則，將一個無語意的時序異常轉變成一個業務告警。例如將連續三次或五次的時序異常轉變成一個業務告警，連續多少次之後恢復告警，同時告警狀態機會維護每個告警的生命週期，避免重覆的告警通知等。
告警質量評價：告警質量的評估可以說是最具挑戰性的工作了。一方面，我們檢測的指標基本都是無標註的資料集，產生的告警準確與否必須有人來判斷；另一方面，因為應用數量眾多，每天的告警量也非常的龐大，靠人力逐個去判斷幾乎是不可能實現的。如果不做告警質量的評價，就無法形成閉環，演演算法效果也無法得到後續的最佳化與提升。目前的評價一方面是靠專家經驗抽樣判斷，一方面是郵件將告警推送給監控負責人，透過一定的獎勵機制調動使用者來反饋告警結果。

異常檢測演演算法介紹

習慣上，按照待檢測的資料集有無標簽標註可以分為監督式學習、無監督學習以及半監督學習；按照演演算法模型有無引數將演演算法分為有參模型和無參模型。

具體演演算法基本都是大家耳熟能詳的，其中大部分演演算法在實際使用的時候都做過一些二次開發和引數最佳化，例如某些場景下我們需要將有的演演算法改寫成遞迴方式實現，用來適配流方式的處理。

上面只是羅列了部分演演算法，具體的實現演演算法要遠多於這幾種。但就這些異常檢測演演算法的思想進行分類的話，無外乎兩大類：

一類是監督式的異常檢測，這類演演算法的資料集因為已經打上了標簽的，分成了訓練資料集和測試資料集，利用訓練資料集和對應的標簽訓練出模型，然後利用學習到的模型再對測試資料集進行檢測；

另外一類演演算法可以歸結為基於分佈和統計特性的異常檢測，這型別的演演算法針對的是無標註資料集的檢測，一個很簡單的道理，我們要判斷某個指標正常與否，一定需要和某個基準進行比對，這個基準可以是固定閾值，也可以是動態閾值。基於分佈和統計特性的異常檢測使用的基本都是動態化的閾值。

在大部分的實踐場景中，監控指標都是沒有標簽標註的，這裡我們重點介紹下基於分佈和統計特性的異常檢測原理。

我們提到的絕大部分監控指標，經過統計分析後都是能夠近似滿足正態分佈或者超高斯分佈。利用統計特性做異常檢測主要是看分佈情況，時間軸上的監控序列投影到縱軸上，就可以得到相應的機率密度分佈函式，樣子如下圖所示。

可以看到水平方向很高的點，對應的機率密度非常小，而大部分監控資料的分佈都比較集中。直觀的看，連續多次小機率事件發生就可以認為是異常事件。

我們藉助工業上常用的3Sigma（標準差）準則作為是否是異常點的檢驗標準，對標準的正態分佈而言，3Sigma準則可以包括整個樣本集99.7%的分佈，也就是說有千分之三的樣本會被判定為異常。

對於超高斯分佈，也就是形狀上比標準正態分佈更尖的分佈，可能不用3Sigma，2Sigma甚至1Sigma就可以滿足檢測需求。除了使用標準差外，四分位差也是經常被用作異常檢測的動態閾值。

下麵是從我們生產系統裡擷取的一張圖，是某個應用的某項監控指標，豎著的虛線標識的時間點代表該指標有監控告警。可以看到正常情況下這個指標是比較小，按照以往固定閾值的告警方式很難發現這類故障，因為固定閾值動輒就是成百上千的設定閾值，像這種Case，很容易漏掉告警，但是透過分佈和統計特性來檢測就很容易發現異常。

前面介紹了基於分佈和統計特性的異常檢測規則，原理上就是基於N Sigma準則方式實現的動態閾值，其中動態閾值是根據預測基線和N倍標準差計算得到的。接下來這個演演算法主要是跟大家分享下，我們是如何基於時頻變換得到預測基線。

時頻變換對很多人來講可能是個比較陌生的概念，用到的技術叫做傅裡葉變換。大家可能或多或少都有一點印象，高等數學有一章級數，曾經提到過傅裡葉級數。系統講解傅氏變換的技術是在訊號處理這門課程裡邊介紹的。

理解傅氏變換的物理意義是很有挑戰性，這裡簡單介紹下如何應用和實現，具體實現需要對監控序列加窗，然後做離散傅裡葉變換。下麵也給出了具體的計算公式，但由於直接計算相當的複雜，實現上都是透過做快速傅裡葉變換實現下的，簡稱FFT。很多程式語言都有現成的函式庫實現。

透過前面介紹的時頻轉換技術，將監控時序變換到頻率域之後再對頻譜做相應的過濾，去除掉頻率較高的成分，然後在時間域重構時序，就可以得到一條相對平穩的基線了。

這裡的前提假設就是我們的監控指標正常情況下都是平穩的，漸變的。從我們生產系統裡邊截取了一段基於頻域濾波的監控結果，黃色的曲線是原始的監控指標，綠色的曲線是透過頻域濾波之後的基線，可以看到是一條非常平滑和穩定的曲線。從圖中可以看到，使用這個技術可以有效的剔除掉異常監控點，確保基線平穩。

基於時頻變換的技術，除了前面講到的可以過濾掉時序中的高頻成分生成比較平穩基線時序外，還可以自動發現時序是有包含週期性特徵。

以這幅圖為例為例，這是從生產系統裡邊擷取的一段真實的監控指標。直觀的看，確實是存在明顯的週期性，現在我們要做的事情是讓程式自動的來識別這個指標的週期。

首先對這個時序做一個自相關，如圖中第2幅所示，然後去掉自相關序列中頻率過低和過高的成分，再去掉均值，如圖中第3幅所示，這時候結果看上去有點接近正弦波的形狀。最後再對上面的結果做一次時頻變換就可以得到對應序列的頻率譜，如最後一幅圖所示。

頻率譜左右對稱，單位一般取赫茲，頻譜上有明顯的譜線就說明對應的時間序列存在比較強的週期性，透過一定的數學公式轉換，就可以計算出相應的週期大小。

異常檢測實踐的經驗總結

針對前面介紹的關於異常指標檢測實踐內容，我們簡單總結下實踐的成果和積累的一些經驗，以及識別到的一些問題。

透過智慧化告警的實踐，應用告警的準確率、召回率相比之前基於規則和固定閾值方式的告警得到了很大的提升。

現在攜程預設的應用告警方式已經全替換成了智慧告警。大部分實踐場景中，這些時序資料都是沒有標註的，都是需要結合基於分佈和統計特性的異常檢測方式。

另外並不是所有的時序都是要採用智慧化的方式被檢測，這裡涉及到算力和成本的投入，如果基於規則的方式可以滿足某些場景下的告警檢測，那麼做智慧化檢測的意義就不是很大，做成這件事主要還是為瞭解決“痛點”。

另外就是不同時序的特徵可能有所不同，而不同的演演算法適用場景也有所差異，所以針對不同特徵的資料集就需要配置不同的檢測演演算法。

再提一下檢測結果的質量評估問題，對於沒有標簽標註的資料集來說，一直是一個難點和挑戰，只有這個環節打通，異常檢測才算是真正的閉環了。也只有不斷地收集和利用反饋結果，這件事才能越來越智慧。

應用告警的智慧診斷

我們先來看一個例子，下麵是一張大量應用告警時的應用大盤截圖，標紅的每個方格表示當前有告警的應用。實際應用之間的呼叫錯綜複雜，究竟是哪個應用或什麼操作導致了此次故障，需要能快速排查出故障原因，這樣就可以為網站快速恢復和止損。

作為堅定的唯物主義因果論者，我們相信萬事皆有因果。藉助專家經驗，我們把所有可能會影響到某個應用異常的因素羅列出來，每個子項稱為一個因子分析器，其中包括了應用釋出、配置變更、呼叫鏈異常、代理故障、資料庫釋出、DNS故障、負載均衡器故障、網路變更等等。

每當發生應用告警的時候，就會自動觸發因子分析器分析。引子分析器主要是做運維事件及告警等和應用告警的關聯分析，分析結果用百分制打分給出。

主要的演演算法有兩個：一種是基於皮爾遜相關係數計算得到的相關係數；另外一種是基於貝葉斯公式計算得到的後驗機率。這兩種技術計算的結果，其絕對值都是在0和1之間，相當於對結果做了歸因化的處理，然後對這個結果再乘以100就可以直接計算出因子分析器輸出的關聯分數。

應用的相關性打分、聚合

因子分析器種類特別多，這裡我們以應用告警指標和釋出事件之間的關聯分析為例，說明下相關性打分的原理。

上面黃色的曲線代表了某個告警應用的監控指標，記做序列A；下麵的紅色的曲線代表了釋出事件在時間維度上的量化結果，記做序列B。此時我們就得到了A和B兩個時間序列，然後計算下皮爾遜相關係數即可計算得出關聯分析結果。

同樣的思路我們還可以運用到多個告警應用之間的關聯性分析。圖中上線兩條曲線分別代表了兩個告警應用的監控指標序列，對這兩個監控時序直接計算皮爾遜相關係數，即可求得兩個告警之間的關聯程度。

另外，我們還會透過框架中間記錄的埋點資料分析兩個應用之間是否存在呼叫關係，再結合之前計算得到的相關係數，以此來完成將多個應用告警事件進行聚合和收斂。

後驗機率打分

利用後驗機率打分，需要積累相當長時間的歷史運維事件和關聯應用告警的資料，記錄並收集在運維知識庫。這裡我們主要對貝葉斯公式的使用做下說明，使用貝葉斯公式的目的主要是希望從似然機率計算得出後驗機率。

似然機率是可以透過對知識庫的訓練和學習得出的某個運維事件發生的時候，各應用告警發生的機率；後驗機率剛好是反過來的，是在應用告警的時候，某個運維事件發生的機率大小，而這些運維事件大部分情況下就是對應應用告警的根源。

上面我們介紹了多種故障關聯的方法和實現。實際效果如何呢？這幅圖是從我們生產系統裡邊截的一張故障時候快速定位根源的快拍。

某天某時突然有很多應用告警同時告警，在我們故障診斷系統中一鍵分析就得出了圖中的結果，定位的結果非常明顯地指向了中間某個應用，而這個應用當時關聯到正在做釋出。

故障診斷總結

和前面應用告警的智慧檢測實踐一樣，我們總結下故障智慧診斷的實踐成果、經驗和識別到的一些問題。

目前大部分故障發生時，我們已經可以快速的定位出故障根源，大大縮短了恢復故障的時間。因子分析器的設計、專家經驗知識庫的構建、關聯打分、呼叫鏈挖掘等都是非常關鍵的技術點。

要提到的一點是，診斷質量的結果評估和告警質量的結果評估類似，也是一個技術難點。未來的計劃是隨著反饋資料的不斷積累以及知識庫的完善，相信這個問題會逐步得到更好地解決。

AIOps未來展望

透過攜程在AIOps方面的實踐和探索，最後簡單總結下我們在AIOps方面的一些思考和展望。

AI是“他山之石”：AIOps是一個跨領域結合的技術，AI只是解決運維問題的一種思路和工具，實踐的出發點和落腳點還是Ops。另外，較高的自動化程度是AIOps實踐的前提。

實踐一定要結合自身場景：我們一直是主張場景優先的原則，實踐AIOps，首先一定要明確自身運維過程中的場景和痛點，不能跟風；警惕拿來主義，AIOps目前沒有明確和統一的實踐規範，實踐前最好要搞清楚機制和原理，必要的時候做一些二次開發。

緊跟行業動態：大型網際網路企業有相當的財力和人力做這件事情，而且一般也很樂意分享相關的實踐經驗。緊隨行業的一些最佳實踐，結合自身場景分析討論落地的可行性，可以避免大方向上走彎路。

學術界跟工業界各貢獻一半力量：這是清華裴丹教授在各種AIOps會議上分享的時候一直呼籲的，學術界貢獻演演算法，工業界貢獻資料和場景，最終實現AIOps的美好願景。

AIOps總體來說是一個比較新和初期的技術，預測5到10年後，運維必將是另外一番景象。相信透過構建敏銳的“眼”、智慧的“腦”以及自動化的“手”，“無人值守的運維”的美好願景終將能實現。

AIOps在攜程的探索與實踐

相關推薦

熱門標籤

熱門文章

分享創造快樂