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年後，運維必將是另外一番景象。相信通過構建敏銳的“眼”、智慧的“腦”以及自動化的“手”，“無人值守的運維”的美好願景終將能實現。
