王肇剛（梓弋）阿里云高級技術(shù)專家
摘要：業(yè)務(wù)通過產(chǎn)品技術(shù)發(fā)揮價值的一個必要條件就是可以在線上穩(wěn)定持續(xù)的運行，這一直是運維人員的終極目標。相信大家在使用天貓、淘寶、支付寶時幾乎沒有遇到過無法使用的情況，阿里是如何做到的呢？AIOps又是什么？本文主要關(guān)注線上業(yè)務(wù)的研發(fā)和運維流程，由阿里云高級技術(shù)專家向大家介紹如何將機器學(xué)習(xí)算法引入運維中的監(jiān)控和故障分析領(lǐng)域，探索智能運維解決方案。
本文將圍繞一下幾個方面進行介紹：
一．阿里巴巴故障治理業(yè)務(wù)流程及挑戰(zhàn)
二．智能運維實戰(zhàn)
三．AIOps智能運維解決方案
本文主要關(guān)注線上業(yè)務(wù)的研發(fā)和運維流程，如今有很多工具可以幫助大家研發(fā)協(xié)同和部署，但業(yè)務(wù)通過產(chǎn)品技術(shù)發(fā)揮價值的一個必要條件就是可以在線上穩(wěn)定持續(xù)的運行。如果業(yè)務(wù)運行出現(xiàn)故障，業(yè)務(wù)價值將無法得到保障和發(fā)揮。相信大家在使用天貓、淘寶、支付寶時幾乎沒有遇到過無法使用的情況，這有兩個原因：一是阿里的系統(tǒng)穩(wěn)定性非常好，二是一些局部故障在用戶感知之前已經(jīng)由內(nèi)部的監(jiān)控系統(tǒng)發(fā)現(xiàn)并解決了。大家一定熟知DevOps一詞，而本文標題中的AIOps則是DevOps未來發(fā)展的一個趨勢。AIOps將機器學(xué)習(xí)算法引入了運維中的監(jiān)控和故障分析領(lǐng)域，探索更有效穩(wěn)定的線上運行效果。
一．阿里巴巴故障治理業(yè)務(wù)流程及挑戰(zhàn)
1. 面臨的挑戰(zhàn)
首先雙十一極具震撼力的數(shù)字給阿里帶了了巨大的穩(wěn)定性挑戰(zhàn)。
但更大的挑戰(zhàn)來自于日常阿里業(yè)務(wù)的多樣和復(fù)雜。首先，阿里業(yè)務(wù)數(shù)量巨大，包括2萬多名技術(shù)工程師，50+ BU，40000+ 應(yīng)用程序。其次，業(yè)務(wù)形態(tài)差異較大。隨著阿里經(jīng)濟體的壯大，出現(xiàn)了許多與傳統(tǒng)電商、金融、云計算等不一樣的業(yè)務(wù)形態(tài)，例如優(yōu)酷是文娛，釘釘是社交，還有阿里體育、阿里健康等更多新的業(yè)務(wù)。業(yè)務(wù)形態(tài)的差異會導(dǎo)致用戶行為的多樣性。并且阿里國際化業(yè)務(wù)例如LAZADA、速賣通AE等，也為監(jiān)控系統(tǒng)帶來了許多挑戰(zhàn)。最后，業(yè)務(wù)關(guān)聯(lián)復(fù)雜。程序之間需要互相調(diào)用，阿里的幾萬個程序間的調(diào)用已經(jīng)構(gòu)成了非常復(fù)雜的網(wǎng)絡(luò)，這種牽一發(fā)而動全局的情況會給穩(wěn)定性帶來極大的挑戰(zhàn)。并且實際情況可能更為復(fù)雜，因為除了內(nèi)部關(guān)聯(lián)，還有外部關(guān)聯(lián)。例如用戶可能習(xí)慣使用淘寶的搜索框?qū)ふ蚁胍徺I的商品，若某日搜索功能出現(xiàn)故障，那么便會直接導(dǎo)致淘寶交易量降低。這是因為大部分用戶是通過搜索功能進入交易頁，出現(xiàn)故障會導(dǎo)致用戶找不到其他措施進行交易。應(yīng)用程序之間的鏈路復(fù)雜和用戶行為對業(yè)務(wù)的影響都會導(dǎo)致業(yè)務(wù)關(guān)聯(lián)復(fù)雜。
因此，阿里需要一個對線上故障進行統(tǒng)一治理的機制。首先，業(yè)務(wù)故障需要統(tǒng)一的發(fā)現(xiàn)，然后跨BU故障協(xié)同處理，故障的影響面和根因需要統(tǒng)一收口和推送，最后當(dāng)確定故障后，第一選擇是使用統(tǒng)一的機制快速恢復(fù)，只有無法快速恢復(fù)的故障才會去分析原因。那么如何在這種復(fù)雜的業(yè)務(wù)流程下實現(xiàn)統(tǒng)一故障處理機制呢？
2. 故障治理業(yè)務(wù)流程
阿里巴巴全局故障治理流程如下所示：
發(fā)現(xiàn)故障后，需要對故障進行定級、通告、輔助定位、處理決策、快速恢復(fù)、復(fù)盤，以及為了防止下次故障進行的演練。阿里的工程師和更多的內(nèi)部成員共同協(xié)作，通過一個龐大而完備的平臺保證該故障處理流程。盡管如此，仍然存在一些人力難以企及的業(yè)務(wù)痛點。例如，傳統(tǒng)的監(jiān)控系統(tǒng)誤報漏報較多。因為業(yè)務(wù)飛速的變化，監(jiān)控系統(tǒng)的報警閾值也會飛速變化導(dǎo)致監(jiān)控維護成本較大。發(fā)現(xiàn)故障后需要梳理雜亂的信息才能定位故障。除此之外，還有故障等級定義差異較大、實時決策觸發(fā)切換難以實現(xiàn)等諸多問題。為了解決這些業(yè)務(wù)痛點，阿里引入了智能運維AIOps的概念，即將機器學(xué)習(xí)和一些工程框架引入故障管理流程中。
該故障治理流程的首要目標是實現(xiàn)故障的精準報警。由下圖可見，改進的效果十分明顯，故障發(fā)現(xiàn)的準確率從40%提升至80%，故障通告耗時從5分鐘減少為小于1分鐘，按照該效率一周可以節(jié)約29人時，極大的提升了企業(yè)的效率。根因推薦從依賴人的經(jīng)驗改進至系統(tǒng)自動推薦可疑事件，這為大型故障中的指揮調(diào)度提供了較好的支持。那么該如何真正實現(xiàn)智能運維呢？
二．智能運維實戰(zhàn)
1. 時間序列異常檢測
阿里中有成千甚至上萬個核心業(yè)務(wù)指標，例如淘寶的成交量、菜鳥裹裹的包裹量等。如何定義何時出現(xiàn)問題，這其實是一個艱難的行為。因此希望可以將業(yè)務(wù)上的一個問題通過監(jiān)控轉(zhuǎn)化為一個技術(shù)問題。這里需要澄清的一點是，大家經(jīng)常需要監(jiān)控的一些指標，例如集群的CPU利用率、網(wǎng)絡(luò)流量或者應(yīng)用程序的response time等，都是系統(tǒng)和應(yīng)用層面的監(jiān)控，不是業(yè)務(wù)層監(jiān)控。有時系統(tǒng)應(yīng)用出現(xiàn)問題時業(yè)務(wù)有可能并不受其影響，例如高可用集群的異地容災(zāi)切換保證中，局部集群掛掉可能用戶使用并不會出現(xiàn)問題，但另一角度看，可能系統(tǒng)任何問題都沒有出現(xiàn)但是業(yè)務(wù)受到影響，例如運營商的骨干網(wǎng)出現(xiàn)問題，這種情況下仍然需要采取措施來防止流量下降。因此監(jiān)控的目標需要直達業(yè)務(wù)結(jié)果，業(yè)務(wù)量下跌即為出現(xiàn)故障，雖然故障可能不是由于系統(tǒng)本身引起，但仍需要發(fā)現(xiàn)并定位該故障。如此將一個對業(yè)務(wù)的監(jiān)控通過以下流程進行轉(zhuǎn)換，首先對故障進行等級定義，對時間序列的業(yè)務(wù)指標監(jiān)控，定位異常點，做出故障通告。
但在實現(xiàn)以上流程中，出現(xiàn)了兩大難點。一是無法確定基線。如果判定下跌一定的數(shù)值為出現(xiàn)故障，那么下跌的數(shù)值該是和什么相比較呢？尤其是高靈敏度的監(jiān)控基線確定更加艱難。因為業(yè)務(wù)影響因素眾多，受到人的影響尤為明顯。如下圖中所示，圖中每個周期為一天，每天不完全相同，有不同的毛刺和尖刺，由于一些業(yè)務(wù)變化和營銷因素的影響，曲線并不是完全的上揚和下跌，而是有一定的起伏，此時簡單的一條橫線或者分段的靜態(tài)閾值已經(jīng)無法應(yīng)對業(yè)務(wù)局部的趨勢變化。同比和環(huán)比也同樣無法應(yīng)對業(yè)務(wù)整體的起伏趨勢。
難點二為假設(shè)設(shè)定了某個基線，如何判定異常。業(yè)務(wù)異常的判定尺度眾多，包括曲線本身波動程度、曲線宏觀業(yè)務(wù)量、時間點、業(yè)務(wù)特性等。當(dāng)然也可以不考慮這些因素，那么一天的100條報警中可能65-70條都為誤報。
接下來就借助機器學(xué)習(xí)來解決該問題。這里可以有兩種途徑供選擇，各有優(yōu)劣。途徑一是通過端到端分類，不計算基線直接判斷異常；途徑二通過回歸擬合基線判斷異常。阿里采用的是途徑二，對業(yè)務(wù)更可控，擬合出的基線對能否準確的判定異常至關(guān)重要。途徑二可以通過基于時間序列分解或者機器學(xué)習(xí)/深度學(xué)習(xí)實現(xiàn)。阿里業(yè)務(wù)中，通過基于時間序列分解來進行擬合回歸，機器學(xué)習(xí)/深度學(xué)習(xí)來解決判斷異常。
整體算法框架如下圖所示。首先對數(shù)據(jù)進行預(yù)處理，包括差值補缺和平滑去噪。然后基于優(yōu)化后的時間序列分解Seanonal Trend LOESS方法進行基線擬合，滑動平均使曲線平滑。然后結(jié)合時間序列分析、機器學(xué)習(xí)以及特征工程中的各種方法，判斷一個時間片段是否需要報警。開始設(shè)計時并未確定該算法應(yīng)采取哪些方法，而是被阿里巴巴各行業(yè)的業(yè)務(wù)、形態(tài)各異的數(shù)據(jù)以及判斷標準訓(xùn)練出來的。它的優(yōu)勢在于對各行業(yè)的數(shù)據(jù)有較高的適配性，對非技術(shù)性的曲線波動有較強的抗干擾能力。此外，該算法會輸出擬合的基線，并且內(nèi)部系統(tǒng)中可以通過該基線提前100分鐘預(yù)測趨勢，當(dāng)然距離越近的預(yù)測越準確，預(yù)測時會將歷史波動和局部變化趨勢都考慮在內(nèi)，每個瞬間都會判斷這個時刻是否需要報警。出現(xiàn)報警后，可以回溯到該報警的開始時間和結(jié)束時間，由此達到整體的報警功能。
該算法達到的效果十分明顯，故障發(fā)現(xiàn)準確率由40%提升至80%，故障發(fā)現(xiàn)召回率從30%提升至80%，每周因誤報而花費的流程操作時間下降了29小時。
2. 智能根因推薦
發(fā)現(xiàn)故障后若無法快速切換恢復(fù)正常運行則需要深入分析原因。但是在智能根因推薦中也存在眾多難點。首先，故障分析定位的范圍及邊界難以確定。例如，是否需要定位到bug存在于哪段代碼，發(fā)布的哪個版本，但這個定位范圍并不是這里需要的。這里的邊界是阿里自定義后的邊界。確定邊界后，需要通過日志、監(jiān)控、報警信息及一些集群圖表來收集故障定位信息。然后進行定位判斷和邏輯決策，判斷哪些是出現(xiàn)該問題最可疑的部分并且提出解決策略。在IT行業(yè)的技術(shù)棧架構(gòu)下，阿里的應(yīng)用程序及業(yè)務(wù)是依靠下圖所示的技術(shù)基礎(chǔ)設(shè)施分層搭建出的。
這個框架從一個業(yè)務(wù)故障出發(fā)，從中找出可能導(dǎo)致該故障的應(yīng)用、中間件或數(shù)據(jù)庫。那么bug具體在哪段代碼中并不是這個框架關(guān)注的重點。但是這已經(jīng)可以幫助大家解決兩個問題，一是快速了解該問題的影響面，二是快速鎖定問題范圍。這對業(yè)務(wù)非常復(fù)雜的一些大型企業(yè)來說有非常重要的優(yōu)勢和價值。在實現(xiàn)這個框架時，主要按照以下流程。首先，通過時間序列異常檢測發(fā)現(xiàn)業(yè)務(wù)異常。然后查詢拓撲鏈路，獲取可疑應(yīng)用及相關(guān)上下游應(yīng)用。接著查詢運維數(shù)據(jù)倉庫，獲取可疑事件。最后根據(jù)故障定位算法，給出可疑程度排序。
了解故障智能分析流程后，其中仍有一些基礎(chǔ)的細節(jié)仍需要詳細介紹，例如運維數(shù)據(jù)倉庫，數(shù)據(jù)倉庫是指為了解決某一領(lǐng)域的專業(yè)問題將一些在線數(shù)據(jù)作匯聚和整理。但為了故障定位而設(shè)置數(shù)據(jù)倉庫，并不只是簡單的將可能影響線上業(yè)務(wù)穩(wěn)定性的所有數(shù)據(jù)匯聚。這里的數(shù)據(jù)倉庫是希望實現(xiàn)自動檢索與故障相關(guān)的事件。因此，運維數(shù)據(jù)倉庫不僅需要匯聚這些數(shù)據(jù)，也需要耦合對這些數(shù)據(jù)的組織關(guān)系，即metadata元數(shù)據(jù)，運維中特指CMDB（Configuration Management Database）。相信大家會使用文字的形式記錄每次的故障報告，但這些文字不可編程也不可檢索，那么運維數(shù)據(jù)倉庫便可以幫助大家實現(xiàn)技術(shù)化的、結(jié)構(gòu)化的故障快照。
接下來通過一個案例展示其效果。下圖中，第一個子圖是阿里巴巴全局業(yè)務(wù)狀態(tài)監(jiān)控。空白處表示無異常，出現(xiàn)異常時跳出紅色柱狀。此時便自動開展上述故障智能分析，推薦相關(guān)可疑事件，并且展示相關(guān)的應(yīng)用鏈路追蹤。對某些受眾來說，比起故障原因更關(guān)心這個故障的影響面，這也會實時展現(xiàn)，包括影響的應(yīng)用及其功能點列表。
三．AIOps智能運維解決方案
1. 核心功能
上述內(nèi)容給大家介紹了在故障發(fā)現(xiàn)和原因分析中引入機器學(xué)習(xí)算法和一些工程框架，這也就是AIOps理念實際落地的產(chǎn)品。阿里希望可以借助阿里云平臺孵化AIOps智能運維解決方案，將這個企業(yè)產(chǎn)品賦能給客戶，進而共同提升企業(yè)穩(wěn)定性。AIOps智能運維解決方案的核心功能有三個。一是異常檢測。下圖為客戶實際測試得出的一個例子，通過預(yù)測來判斷曲線本應(yīng)趨勢如何，學(xué)習(xí)歷史殘差，避免過于靈敏造成誤報，即存在某些毛刺是視為無異常情況的。一旦發(fā)現(xiàn)明顯的趨勢偏離，便可以立刻識別和報警，并且在持續(xù)偏離的情況下識別異常區(qū)間抑制重復(fù)報警。
第二個核心功能是基線預(yù)測?？梢酝ㄟ^回歸擬合預(yù)測距當(dāng)前時間100分鐘內(nèi)的趨勢，這對處理業(yè)務(wù)有極大的幫助。如上文所說，該算法通過學(xué)習(xí)和訓(xùn)練各行業(yè)的數(shù)據(jù)得出，因此即使數(shù)據(jù)有較多的毛刺和抖動，歷史趨勢完全不同，該框架都能較好的適應(yīng)，均方誤差較小。直觀來說，擬合出的紅線一定是大家理想的檢測業(yè)務(wù)下跌的基準，因此為它命名為智能基線。
當(dāng)出現(xiàn)故障時，還有另一核心功能為多維分析。數(shù)據(jù)是由分布式系統(tǒng)的日志流式計算匯集，因此數(shù)據(jù)中會存在某些字段可以進行維度拆解。例如淘寶流量來自于全國各省市各地區(qū)，來自于安卓用戶和IOS用戶，來自于電信或聯(lián)通。那么流量出現(xiàn)故障時會自動判斷這次的流量下跌主要來自哪個省市或應(yīng)用商，例如是否來自江蘇省的移動用戶中的安卓用戶。這可以幫助運維人員快速的鎖定故障對象。
2. 典型場景
在各行業(yè)中采集了一些典型場景如下所示：
圖一中為爬蟲現(xiàn)象，若機器學(xué)習(xí)到的結(jié)果通常顯示為該現(xiàn)象，那么就認為這不是業(yè)務(wù)異常。圖二所示現(xiàn)象是否應(yīng)視為異常如今在阿里內(nèi)部仍沒有定論，對此可以設(shè)置一些靈敏度選擇，根據(jù)不同情況設(shè)置為不同結(jié)果。圖三所示的周期性探測中，大多數(shù)業(yè)務(wù)都以天或者星期為周期，但該業(yè)務(wù)更多的與月初月末相關(guān)，例如信用卡還款、話費流量充值等，因此這種業(yè)務(wù)是日周期、周周期和月周期的疊加。上文中的算法具備自動探測周期的能力。圖四是最經(jīng)典的探測到交易量的驟然下跌。由此可見，該算法模型可以適配各行業(yè)的業(yè)務(wù)數(shù)據(jù)。對于底層的系統(tǒng)級數(shù)據(jù)也有相對應(yīng)的特定算法。
綜上，阿里的AIOps智能運維解決方案有以下三大特點：故障探測、智能調(diào)參、自動進化。故障探測中，精準全面報警，鮮有誤報漏報，沒有人工配置成本，所有流程自動化學(xué)習(xí)。即使業(yè)務(wù)發(fā)生了巨大的變化，例如阿里的釘釘在這一年中的發(fā)展非常迅速，在三個月前業(yè)務(wù)量可能處于一個量級，三個月后就上升到另一個量級，該算法也會在極短的時間內(nèi)自動適應(yīng)，不需要人工修改調(diào)整閾值。智能調(diào)參是指根據(jù)趨勢預(yù)測的變化自動調(diào)節(jié)參數(shù)。自動學(xué)習(xí)是指，當(dāng)大家對是否報警持有爭議時，可以采取不同靈敏度報警方案，并且將報警結(jié)果反饋回算法，那么該算法會不斷學(xué)習(xí)報警的尺度，優(yōu)化報警模型，進而提升故障報警的覆蓋面和準確性。
本文由云棲志愿小組郭雪整理，編輯百見
