AIOps,最初的定義是Algorithm IT Operations,是利用運維算法來實現運維的自動化,最終走向無人化運維。隨着技術成熟,逐步肯定爲Artificial Intelligence for IT Operations——智能運維,將人工智能應用於運維領域,基於已有的運維數據(日誌、監控信息、應用信息等),經過機器學習的方式來進一步解決自動化運維沒法解決的問題。html
早期的運維工做大部分是由運維人員手工完成的,手工運維在互聯網業務快速擴張、人力成本高企的時代,難以維繫。因而,自動化運維應運而生,它主要經過可被自動觸發、預約義規則的腳本,來執行常見、重複性的運維工做,從而減小人力成本,提升運維的效率。總的來講,自動化運維能夠認爲是一種基於行業領域知識和運維場景領域知識的專家系統。隨着整個互聯網業務急劇膨脹,以及服務類型的複雜多樣,「基於人爲指定規則」的專家系統逐漸變得力不從心,自動化運維的不足,日益凸顯,當前美團在業務監控和運維層面也面臨着一樣的困境。git
DevOps的出現,部分解決了上述問題,它強調從價值交付的全局視角,但DevOps更強調橫向融合及打通,AIOps則是DevOps在運維(技術運營)側的高階實現,二者並不衝突。AIOps不依賴於人爲指定規則,主張由機器學習算法自動地從海量運維數據(包括事件自己以及運維人員的人工處理日誌)中不斷地學習,不斷提煉並總結規則。AIOps在自動化運維的基礎上,增長了一個基於機器學習的大腦,指揮監測系統採集大腦決策所需的數據,作出分析、決策,並指揮自動化腳本去執行大腦的決策,從而達到運維繫統的總體目標。綜上看,自動化運維水平是AIOps的重要基石,而AIOps將基於自動化運維,將AI和運維很好地結合起來,這個過程須要三方面的知識:github
美團技術團隊在行業、業務領域知識和運維領域的知識等方面有着長期的積累,已經沉澱出很多工具和產品,實現了自動化運維,同時在AIOps方面也有一些初步的成果。咱們但願經過在AIOps上持續投入、迭代和鑽研,將以前積累的行業、業務和運維領域的知識應用到AIOps中,從而能讓AIOps爲業務研發、產品和運營團隊賦能,提升整個公司的生產效率。算法
AIOps的建設能夠先由無到局部單點探索,在單點探索上獲得初步的成果,再對單點能力進行完善,造成解決某個局部問題的運維AI學件,再由多個具備AI能力的單運維能力點組合成一個智能運維流程。行業通用的演進路線以下:數據庫
所謂學件,亦稱AI運維組件[1](南京大學周志華老師原創),相似程序中的API或公共庫,但API及公共庫不含具體業務數據,只是某種算法,而AI運維組件(或稱學件),則是在相似API的基礎上,兼具對某個運維場景智能化解決的「記憶」能力,將處理這個場景的智能規則保存在了這個組件中,學件(Learnware)= 模型(Model)+規約(Specification)。AIOps具體的能力框架以下圖1所示:數組
AIOps團隊內部人員根據職能可分爲三類團隊,分別爲SRE團隊、開發工程師(穩定性保障方向)團隊和算法工程師團隊,他們在AIOps相關工做中分別扮演不一樣的角色,三者缺一不可。SRE能從業務的技術運營中,提煉出智能化的需求點,在開發實施前可以考慮好需求方案,產品上線後能對產品數據進行持續的運營。開發工程師負責進行平臺相關功能和模塊的開發,以下降用戶的使用門檻,提高用戶的使用效率,根據企業AIOps程度和能力的不一樣,運維自動化平臺開發和運維數據平臺開發的權重不一樣,在工程落地上可以考慮好健壯性、魯棒性、擴展性等,合理拆分任務,保障成果落地。算法工程師則針對來自於SRE的需求進行理解和梳理,對業界方案、相關論文、算法進行調研和嘗試,完成最終算法落地方案的輸出工做,並不斷迭代優化。各團隊之間的關係圖以下圖2所示:微信
當前,咱們在質量保障方面的訴求最迫切,服務運維部先從故障管理領域探索AIOps實踐。在故障管理體系中,從故障開始到結束主要有四大核心能力,即故障發現、告警觸達、故障定位、故障恢復。故障發現包含了指標預測、異常檢測和故障預測等方面,主要目標是能及時、準確地發現故障;告警觸達包含了告警事件的收斂、聚合和抑制,主要目標是降噪聚合,減小干擾;故障定位包含了數據收集、根因分析、關聯分析、智能分析等,主要目標是能及時、精準地定位故障根因;故障恢復部分包含了流量切換、預案、降級等,主要目標是及時恢復故障,減小業務損失,具體關係以下圖3所示:網絡
其中在故障管理智能化的過程當中,故障發現做爲故障管理中最開始的一環,在當前海量指標場景下,自動發現故障和自動異常檢測的需求甚爲迫切,能極大地簡化研發策略配置成本,提升告警的準確率,減小告警風暴和誤告,從而提升研發的效率。除此以外,時序數據異常檢測實際上是基礎能力,在後續告警觸達、故障定位和故障恢復環節中,存在大量指標須要進行異常檢測。因此將故障發現做爲當前重點探索目標,解決當前海量數據場景下人工配置和運營告警策略、告警風暴和準確率不高的核心痛點。整個AIOps體系的探索和演進路線以下圖4所示。每一個環節均有獨立的產品演進,故障發現-Horae(美團服務運維部與交易系統平臺部共建項目)、告警觸達-告警中心、故障定位-雷達、故障恢復-雷達預案。架構
從美團現有的監控體系能夠發現,絕大多數監控數據均爲時序數據(Time Series),時序數據的監控在公司故障發現過程當中扮演着不可忽視的角色。不管是基礎監控CAT[2]、MT-Falcon[3]、Metrics(App端監控),仍是業務監控Digger(外賣業務監控)、Radar(故障發現與定位平臺)等,均基於時序數據進行異常監控,來判斷當前業務是否在正常運行。然而從海量的時序數據指標中能夠發現,指標種類繁多、關係複雜(以下圖5所示)。在指標自己的特色上,有周期性、規律突刺、總體擡升和降低、低峯期等特色,在影響因素上,有節假日、臨時活動、天氣、疫情等因素。原有監控系統的固定閾值類監控策略想要覆蓋上述種種場景,變得愈來愈困難,而且指標數量衆多,在策略配置和優化運營上,人力成本將成倍增加。若在海量指標監控上,能根據指標自動適配合適的策略,不須要人爲參與,將極大的減小SRE和研發同窗在策略配置和運營上的時間成本,也可以讓SRE和研發人員把更多精力用在業務研發上,從而產生更多的業務價值,更好地服務於業務和用戶。框架
在時序數據異常檢測中,對於不一樣類型的時序數據,一般須要設置不一樣的告警規則。好比對於CPU Load曲線,每每波動劇烈,若是設置固定閾值,瞬時的高漲會常常產生誤告,SRE和研發人員須要不斷調整閾值和檢測窗口來減小誤告,當前,經過Radar(美團內部系統)監控系統提供的動態閾值策略,而後參考歷史數據能夠在必定程度上避免這一狀況。若是系統可以提早預判該時序數據類型,給出合理的策略配置建議,就能夠提高告警配置體驗,甚至作到自動化配置。並且在異常檢測中,時序數據分類一般也是智能化的第一步,只有實現智能化分類,才能自動適配相應的策略。
目前,時間序列分類主要有兩種方法,無監督的聚類和基於監督學習的分類。Yading[4]是一種大規模的時序聚類方法,它採用PAA降維和基於密度聚類的方法實現快速聚類,有別於K-Means和K-Shape[5]採用互相關統計方法,它基於互相關的特性提出了一個新穎的計算簇心的方法,且在計算距離時儘可能保留了時間序列的形狀。對KPI進行聚類,也分爲兩種方法,一種是必須提早指定類別數目(如K-Means、K-Shape等)的方法,另外一種是無需指定類別數目(如DBSCAN等),無需指定類別數目的聚類方法,類別劃分的結果受模型參數和樣本影響。至於監督學習的分類方法,經典的算法主要包括Logistics、SVM等。
3.2.1 分類器選擇
根據當前監控系統中時序數據特色,以及業內的實踐,咱們將全部指標抽象成三種類別:週期型、平穩型和無規律波動型[6]。咱們主要經歷了三個階段的探索,單分類器分類、多弱分類器集成決策分類和卷積神經網絡分類。
3.2.2 分類流程
咱們選擇CNN分類器進行時序數據分類,分類過程以下圖6所示,主要步驟以下:
3.3.1 異常檢測方法
基於上述時序數據分類工做,本文可以相對準確地將時序數據分爲週期型、平穩型和無規律波動型三類。在這三種類型中,週期型最爲常見,佔比30%以上,而且包含了大多數業務指標,業務請求量、訂單數等核心指標均爲週期型,因此本文優先選擇週期型指標進行自動異常檢測的探索。對於大量的時序數據,經過規則進行判斷已經不能知足,須要通用的解決方案,能對全部週期型指標進行異常檢測,而非一個指標一套徹底獨立的策略,機器學習方法是首選。
論文Opprentice[8]和騰訊開源的Metis[9]採用監督學習的方式進行異常檢測,其作法以下:首先,進行樣本標註獲得樣本數據集,而後進行特徵提取獲得特徵數據集,使用特徵數據集在指定的學習系統上進行訓練,獲得異常分類模型,最後把模型用於實時檢測。監督學習總體思路[10]以下圖8所示,其中
(x1,y1),(x2,y2),...,(xn,yn)是訓練數據集,學習系統由訓練數據學習一個分類器P(Y∣X)或Y=f(X),分類系統經過學習到的分類器對新的輸入實例xn+1進行分類,預測其輸出的類別yn+1。
3.3.2 異常注入
通常而言,在樣本數據集中,正負樣本比例若是極度不均衡(好比1:5,或者更懸殊),那麼分類器分類時就會傾向於高比例的那一類樣本(假如負樣本佔較大比例,則會表現爲負樣本Recall太高,正樣本Recall低,而總體的Accuracy依然會有比較好的表現),在一個極度不均衡的樣本集中,因爲機器學習會對每一個數據進行學習,那麼多數數據樣本帶有的信息量就比少數樣本信息量大,會對分類器學習過程當中形成干擾,致使分類不許確。
在實際生產環境中,時序數據異常點是很是少見的,99%以上的數據都是正常的。若是使用真實生產環境的數據進行樣本標註,將會致使正負樣本比例嚴重失衡,致使精召率沒法知足要求。爲了解決基於監督學習的異常檢測異常點過少的問題,本文設計一種針對週期型指標的自動異常注入算法,保證異常注入足夠隨機且包含各類異常場景。
時序數據的異常分爲兩種基本類型,異常上漲和異常下跌,以下圖9(圖中數據使用Curve[11]標註),一般異常會持續一段時間,而後逐步恢復,恢復過程或快或慢,影響異常兩側的值,稱之爲漣漪效應(Ripple Effect),相似石頭落入水中,波紋擴散的情形。受到該場景的啓發,異常注入思路及步驟以下:
經過上面的異常注入步驟,能比較好地模擬出週期型指標在生產環境中的各類異常場景,上述過程當中各個步驟的數據都是隨機產生,因此產生的異常案例各不相同,從而能爲咱們生產出足夠多的異常樣本。爲了保證樣本集的高準確性,咱們對於注入異常後的指標數據還會進行標註,以去除部分注入的非異常數據。具體異常數據生成效果如圖10所示,其中藍色線爲原始數據,紅色線爲注入的異常,能夠看出注入異常與線上環境發生故障時類似,注入的異常隨機性較大。
3.3.3 特徵工程
針對週期型指標,經標註產生樣本數據集後,須要設計特徵提取器進行特徵提取,Opprentice中設計的幾種特徵提取器如圖11所示:
上述特徵主要是一些簡單的檢測器,包括如固定閾值、差分、移動平均、SVD分解等。Metis將其分爲三種特徵,一是統計特徵,包括方差、均值、偏度等統計學特徵;二是擬合特徵,包括如移動平均、指數加權移動平均等特徵;三是分類特徵,包含一些自相關性、互相關性等特徵。參考上述說起的特徵提取方法,本文設計了一套特徵工程,區別於上述特徵提取方法,本文對提取的結果用孤立森林進行了一層特徵抽象,使得模型的泛化能力更強,所選擇的特徵及說明以下圖12所示:
3.3.4 模型訓練及實時檢測
參考監督學習在分類問題中的應用思路,對週期型指標自動異常檢測方案具體設計如圖下13所示,主要分爲離線模型訓練和實時檢測兩大部分,模型訓練主要根據樣本數據集訓練生成分類模型,實時檢測利用分類模型進行實時異常檢測。具體過程說明以下:
3.3.5 特殊場景優化
經過上述實踐,本文獲得一套可完整運行的週期型指標異常檢測系統,在該系統應用到生產環境的過程當中,也遇到很多問題,好比低峯期(小數值)波動幅度較大,節假日和週末趨勢和工做日趨勢徹底不一樣,數據存在總體大幅擡升或降低,部分規律波動時間軸上存在偏移,這些狀況都有可能產生誤告。本文也針對這些場景,分別提出對應的優化策略,從而減小週期型指標在這些場景下的誤告,提升異常檢測的精召率。
1)低峯期場景:低峯期主要表現是小數值高波動,低峯期的波動比較廣泛,可是常規檢測時,只獲取當前點先後7min的鄰域內的數據,可能沒法獲取到自己已經出現過屢次的較大波動,致使誤判爲異常。因此對於低峯期,須要擴大比較窗口,容納到更多的正常的較大波動場景,從而減小被誤判。以下圖14所示,紅色是當日數據,灰色是上週同日數據,若是判斷窗口爲w1,w1內藍色點有可能被認爲是異常點,而時間窗口範圍擴大到w2後,大幅波動的藍色點和綠色點都會被捕獲到,出現相似大幅波動時再也不被斷定爲異常,至於低峯期範圍能夠經過歷史數據計算進行識別。
2)節假日場景:節假日前一天以及節假日以後一週的數據,和正常週期的趨勢都會有較大差異,可能會出現誤告。本文經過提早配置須要進行節假日檢測的日期,在設置的日期範圍內,除了進行正常的檢測流程,對於已經檢測出異常的數據點,會再進入到節假日檢測流程,都異常纔會觸發告警。節假日檢測會取最近1h的數據,分別計算其波動比、周同比、日環比等數據,當前時間的這些指標經過「孤立森林」判斷都爲異常,纔會認爲數據是真正異常。除此以外,對於節假日,模型的敏感度會適當調低以適應節假日場景。
3)總體擡升/降低場景:場景特色以下圖15所示,在該場景下,會設置一個擡升/下跌率,好比80%,若是今天最近1h數據80%相對昨日和上週都上漲,則認爲是總體擡升,都下跌則認爲是總體降低。若是出現總體擡升狀況,會下降模型敏感度,而且要求當前日環比、周同比在1h數據中均爲異常點,纔會斷定當前的數據異常。
4)規律波動偏移場景:部分指標存在週期性波動,可是時間上會有所偏移,如圖16所示案例中時序數據因爲波動時間偏移致使誤告。本文設計一種類似序列識別算法,在歷史數據中找出波動類似的序列,若是存在足夠多的類似波動序列,則認爲該波動爲正常波動。類似序列提取過程以下:最近n分鐘的時序做爲基礎序列x,獲取檢測時刻歷史14天鄰域內的數據(如先後30min),在鄰域數據中指定滑動窗口(如3min)滑動,把鄰域數據分爲多個長度爲n的序列集Y,計算基礎序列x與Y中每一個序列的DTW距離,經過「孤立森林」對距離序列進行異常判斷,對於被斷定爲異常值的DTW距離,它所對應的序列將被視爲類似序列。若是類似序列個數超出設定閾值,則認爲當前波動爲規律偏移波動,屬於正常現象。根據上述方法,提取到對應的類似序列如圖16右邊所示,其中紅實線爲基礎序列。
爲了把上述時序數據異常檢測探索的結果進行落地,服務運維部與交易系統平臺部設計和開發了時序數據異常檢測系統Horae。Horae致力於時間序列異常檢測流程的編排與調優,處理對象是時序數據,輸出是檢測流程和檢測結果,核心算法是異常檢測算法、時間序列預測算法以及針對時間序列的特徵提取算法。除此以外,Horae還會針對特殊的場景開發異常檢測算法。Horae核心能力是可根據提供的算法,編排不一樣的檢測流程,對指標進行自動分類,並針對指標所屬類型自動選擇合適的檢測流程,進行流程調優獲得該指標下的最優參數,從而確保能適配指標並獲得更高的精召率,爲各個對時序數據異常檢測有需求的團隊提供高準確率的異常檢測服務。
3.4.1 Horae系統架構設計
Horae系統由四個模塊組成:數據接入、實時檢測、實驗模塊和算法模塊。用戶經過數據接入模塊註冊須要監聽時序數據的消息隊列,Horae系統將監聽註冊的Topic採集時序數據,並根據粒度(例如分鐘、小時或天)更新每一個時間序列,每一個時序點都存儲到時序數據庫中,實時檢測模塊對每一個時序點執行異常檢測,當檢測到異常時,經過消息隊列將異常信息傳輸給用戶。下圖17詳細展現了Horae系統的總體架構圖。
3.4.2 算法註冊和模型編排
算法模型是對算法的抽象,經過惟一字符串標識算法模型,註冊算法時須要指定算法的類型、接口、參數、返回值和處理單個時序點所須要加載的時序數據配置。成功註冊的算法模型根據算法類型的不一樣,會生成用於模型編排的算法組件或對異常檢測模型進行訓練的組件。用於模型編排的算法組件主要包括:預處理算法、時序特徵算法、評估算法、預測算法、分類算法、異常檢測算法等,用於模型訓練的算法分爲兩大類:參數調優和機器學習模型訓練。
註冊後的算法模型一般不會直接用於異常檢測,會對算法模型進行編排後獲得一個流程模型,流程模型能夠用於執行異常檢測或者執行訓練。實驗模塊支持兩種類型的流程模型:執行流程和訓練流程。執行流程是一個異常檢測流程,指定指標和檢測時間段,獲得檢測時間段每一個時序點的異常分值;訓練流程是一個執行訓練的流程模型,主要包括參數調優訓練流程和機器學習模型訓練流程。使用算法進行流程編排以下圖18所示,左側菜單爲算法組件,中間區域可對算法執行流程進行編排調整,右側區域是具體算法的參數設置。
3.4.3 離線訓練和實時檢測
在模型編排階段,可編排執行流程和訓練流程,執行流程主要用在指標實時異常檢測過程,而訓練流程主要用在離線模型訓練和參數調優。執行流程由流程配置和異常分值配置構成,由實驗模塊的流程調度引擎負責執行調度,下圖19展現了執行流程的詳細構成。流程調度引擎在對執行流程調度執行以前,會從流程的最深葉子節點的算法組件開始遞歸計算須要加載的時序數據集,根據流程中算法組件的參數配置,加載前置訓練流程的訓練結果,最後對流程中的算法組件依次調度執行,獲得檢測時間段每一個時序點的異常分值。最終實現後的執行流程編排如圖18所示。
訓練流程由流程配置、訓練算法、樣本加載配置和訓練頻次等信息構成,由實驗模塊的流程調度引擎負責調度執行,下圖20展現了訓練流程的詳細構成。訓練流程主要分爲兩大類,參數調優訓練和機器學習模型訓練。參數調優訓練是指爲須要調優的參數設置參數值迭代範圍或者枚舉值,經過貝葉斯調優算法對參數進行調優,獲得最優參數組合;機器學習模型訓練則經過設計好特徵工程,設置分類器和超參數範圍後調優獲得機器學習模型文件。訓練流程執行訓練的樣本集來源於人工標註的樣本或者基於自動樣本構造功能生成的樣本。訓練流程編排具體過程和執行流程相似,不一樣的是訓練流程可設置定時任務執行,訓練的結果會存儲供後續使用。
異常檢測模型中會包含不少憑藉經驗設定的超參數,不一樣的指標可能須要設置不一樣的參數值,保證更高的精召率。而指標數據會隨着時間發生變化,設置參數須要按期的訓練和更新,在實驗模塊中能夠爲訓練流程設置定時任務,實驗模塊會定時調度訓練流程生成離線訓練任務,訓練任務執行完成能夠看到訓練結果和效果。下圖21示例展現了一個參數調優訓練流程的示例。
3.4.4 模型案例和結果評估
根據在週期型指標上探索的結果,在Horae上編排分類模型訓練流程,訓練和測試所使用的樣本數是28000個,其中用於訓練的比例是75%,用於驗證的比例是25%,具體分類模型訓練結果以下圖22所示,在測試集上的準確率94%,召回率89%。同時編排了與之對應的執行流程,它的檢測流程除了異常分類,還主要包含了空值填充、預檢測、特徵提取、分類判斷、低峯期判斷、偏移波動判斷等邏輯,該執行流程適用範圍是週期型和穩定型指標。除此以外,還提供了流程調優能力,檢測流程中的每一個算法能夠暴露其超參數,對於具體的指標,經過該指標的樣本數據能夠訓練獲得該流程下的一組較優超參數,從而提升該指標的異常檢測的精召率。
該異常檢測流程應用到生產環境的指標後,具體檢測效果相關案例以下圖23所示,對於週期型指標,能及時準確地發現異常,對異常點進行反饋,準確率達到90%以上。除此以外,還對比了形變分析異常檢測,對於生產環境中遇到的三個形變分析沒法發現的4個案例,週期型指標異常檢測流程能發現其中3個,表現優於形變分析。
時序數據異常檢測做爲AIOps中故障發現環節的核心,當前通過探索和實踐,已經在週期型指標異常檢測上取得了必定的成績,並落地到Horae時序異常檢測系統中。在時序數據異常檢測部分,後續會陸續實現平穩型、無規律波動型指標自動異常檢測,增長指標數據預測相關能力,提升檢測性能,從而實現全部類型的海量指標自動異常檢測的目的。
除此以外,在告警觸達方面,咱們當前在進行告警收斂、降噪和抑制相關的規則和算法的探索,致力於提供精簡有效的信息,減小告警風暴及干擾;在故障定位方面,咱們已經基於規則在定位上取得比較不錯的效果,後續還會進行更全面的定位場景覆蓋和關聯性分析、根因分析、知識圖譜相關的探索,經過算法和規則提高故障定位的精召率。因篇幅所限,告警觸達(告警中心)和故障定位(雷達)兩部份內容將會在後續的文章中詳細進行分享,敬請期待。
胡原、錦冬、俊峯,基礎技術部-服務運維部工程師;長偉、永強,到家事業羣-交易系統平臺部工程師。
基礎技術部-服務運維部-運維工具開發組-故障管理開發組主要負責故障發現、故障定位、故障恢復、故障運營、告警中心、風險管理、數據倉庫等工做。目前團隊誠招高級工程師、技術專家。歡迎有興趣的同窗投送簡歷至tech@meituan.com(郵件主題註明:運維工具)
想閱讀更多技術文章,請關注美團技術團隊(meituantech)官方微信公衆號。