女主宣言
360運維開發(fā)團隊在年初啟動了AIOps項目，經(jīng)過不斷的探索和實踐，成功通過AIOps為公司節(jié)省成本3500萬。
本文分享如何從運維成本和效率兩方面發(fā)力，以達到節(jié)省資源、提高效率的目的。
本文來自360運維開發(fā)團隊-機器學習工程師籍鑫璞在dbaplus社群的第168期線上分享。
前言
今天我們要分享的是近幾年我們在AIOps（智能運維）領(lǐng)域的探索和實踐經(jīng)驗。
下面是本次分享的摘要：
背景介紹
360對AIOps的思考
AIOps的實踐方案
經(jīng)驗和總結(jié)
一、背景介紹
隨著互聯(lián)網(wǎng)的軟硬件呈現(xiàn)爆發(fā)性的增長，新的架構(gòu)層出不窮，運維人員需要做到7*24小時的職守來保證系統(tǒng)的可靠性和穩(wěn)定性。但這明顯是不可能的。
那么面對這種空前的壓力，有沒有一種“機器大腦”能夠減少甚至代替運維人員去做一些事情，極大地減少他們的工作量，提高運維的效率？又該如何得到這種“機器大腦”呢？
很多運維場景都可以總結(jié)成一些規(guī)則化的東西，可以經(jīng)過提煉總結(jié)生成人工經(jīng)驗庫。除了人工經(jīng)驗以外，是否可以通過AI算法對歷史數(shù)據(jù)進行分析，得到一些由機器生成的規(guī)則？
答案當然是可以的。如果能將AI算法+人工經(jīng)驗應(yīng)用到Ops中，代替一部分的人工決策，這樣將推動運維從普通的自動化階段到智能化階段邁進。
從今年開始，很多公司在AIOps領(lǐng)域進行了一些嘗試。我們公司的AIOps也經(jīng)歷了從最開始的標準化到后來的精細化、數(shù)據(jù)化運維的前期鋪墊，在2018年，AIOps項目組正式組建，經(jīng)過近一年的發(fā)展，已經(jīng)在很多單點應(yīng)用方面取得比較好的效果，并爭取在今年年底，能夠?qū)崿F(xiàn)一些場景的閉環(huán)。
二、360對AIOps的思考
大家熟悉的AIOps場景有很多，諸如異常檢測、根因分析、故障自愈、容量預(yù)測等方面。根據(jù)平臺的實際場景和業(yè)界AIOps的實踐經(jīng)驗，我們將AIOps劃分為三個場景：成本、效率和穩(wěn)定性。
針對成本來說，利用AI算法節(jié)省資源、智能調(diào)度、提高資源利用率的手段來節(jié)省資源；針對效率方面來說，利用AI算法主動發(fā)現(xiàn)問題、分析問題和解決問題，真正節(jié)省人力，提高效率。
那如何開展AIOps呢？我們認為AIOps需要開展需要下面三種人員：運維人員、運維開發(fā)、機器學習工程師。三者缺一不可，否則項目就會半途而廢。
上面介紹了我們對AIOps的理解，下面就是純干貨出場了，我們將分兩個大方向五個具體項目來介紹AIOps最佳實踐經(jīng)驗。
三、AIOps實踐方案
1
基礎(chǔ)
數(shù)據(jù)積累
所謂“巧婦難為無米之炊”，在啟動AIOps之前，需要準備很多數(shù)據(jù)，包括機器維度的基礎(chǔ)數(shù)據(jù)、網(wǎng)絡(luò)數(shù)據(jù)、日志數(shù)據(jù)、甚至進程數(shù)據(jù)等。我們有專門的大數(shù)據(jù)工程師歷時兩年多對數(shù)據(jù)進行收集，為后面的數(shù)據(jù)分析、機器學習模型打下堅實的基礎(chǔ)。
下面是我們前后收集的數(shù)據(jù)總結(jié)：
容量預(yù)估
有了歷史數(shù)據(jù)，我們就可以對數(shù)據(jù)進行一些分析。
首先介紹一種場景——容量預(yù)估。對重要監(jiān)控項的預(yù)測，能夠使我們及時了解指標的走勢，為后面的決策提供了科學的依據(jù)。
監(jiān)控項的樣本就是時間序列，通過分析監(jiān)控項的序列，得到未來一段時間的預(yù)測值。根據(jù)波動劇烈程度，監(jiān)控項可以分為波動不太劇烈和劇烈的；根據(jù)周期性，可以分為具有周期性和不具有周期性等等，當然還有很多劃分的標準?？梢?，不同時間的序列，我們需要使用不同的模型去預(yù)測。
在對時間序列進行預(yù)測的過程中，我們先后使用了下面幾種模型，從中總結(jié)出了一些經(jīng)驗：
很多時間序列具有周期性，我們還自研了一個周期性檢測的模型，能夠比較好的判斷一個序列是否具有周期性。在周期性檢測的基礎(chǔ)上，進一步跟進序列的周期性特征，來預(yù)測不同的時間序列。
對于預(yù)測模型，前人已經(jīng)總結(jié)了很多種，我們在項目中使用了下面一些模型，你可以根據(jù)時間開銷和準確度來選擇自己的模型。以上所有的預(yù)測方法將在近期進行開源，還希望大家持續(xù)關(guān)注：
主機分類
在實際的項目中，我們經(jīng)常會遇到分類任務(wù)，比如根據(jù)主機監(jiān)控項的特征，需要用模型判斷出該機器是否為空閑機器；再比如，我們會根據(jù)監(jiān)控項的特征，來判斷該機器屬于的類型（CPU、磁盤、內(nèi)存密集型）。
機器學習中有很多分類算法，比如SVM、決策樹、分類樹等都可以完成分類任務(wù)。我們只需要做一些預(yù)處理以及特征工程等方面的工作后，就可以使用Python中現(xiàn)成的分類模型，在此就不詳細介紹。
2 項目
有了容量預(yù)估和主機分類的基礎(chǔ)模塊后，我們在成本方面先后做了資源回收、智能調(diào)度系統(tǒng)兩個項目，并取得了比較好的效果。
資源回收
資源回收，就是及時發(fā)現(xiàn)比較空閑的機器，通知業(yè)務(wù)進行回收，以達到提高資源利用率的目的。
我們的資源回收系統(tǒng)分為三塊：容量預(yù)估、主機分類以及通知模塊。容量預(yù)估模型是對五個比較重要的指標（CPU使用率、內(nèi)存使用率、網(wǎng)卡流量、磁盤使用率以及狀態(tài)連接數(shù)）進行預(yù)測以及定量分析后，生成了五個特征。接下來使用分類器來對五個特征進行分類后，得到空閑的機器列表，最后將空閑機器通知給相應(yīng)的業(yè)務(wù)負責人。
在AIOps中，經(jīng)常用遇到負樣本不足的問題，一個原因是異常的場景比較少，另一個原因是用戶標注的成本比較高。
在主機分類的過程中，我們使用了兩種手段來生成樣本，一種是人工標注，一種是用戶標注，解決了負樣本不足的問題。下面這幅圖是我們在Q2季度時候資源回收取得的效果，目前看還不錯：
MySQL智能調(diào)度系統(tǒng)
我們線上的MySQL機器存在嚴重的浪費問題，例如下面的場景：可以看到只要有一個指標是高負載的情況，這個機器將不可用。細想一下，如果一臺機器內(nèi)存比較高，但是并不代表這臺機器不可用，我們可以將CPU使用率較高但內(nèi)存使用率較低的實例調(diào)度到這臺機器上，達到充分利用資源的目的。
為了將不同類型的機器和不同類型的實例進行合理搭配，需要將實例和機器進行分類。在該項目中，實例分類采用了BP神經(jīng)網(wǎng)絡(luò)，其中輸入是7個重要的實例指標，輸出是4個類別（低消耗、計算型、存儲型、綜合型）。
機器分類采用決策樹模型，輸入是5個機器指標，輸出和實例的輸出類型一樣。樣本全部采用人工標注的方式，生成了1000左右的樣本。
有了分類好的機器和實例以后，就需要進行調(diào)度。在調(diào)度過程中，考慮了多種因素：
盡量保證遷移次數(shù)少
盡量少的避免切主
保證主庫和大容量端口的穩(wěn)定性
控制每臺機器上主庫的個數(shù)（不超過5個）和實例總個數(shù)
同一端口的實例不能出現(xiàn)在同一機器上
不調(diào)度黑名單機器
我們按照上面的原則對一個機房的實例進行測試，端口遷移的次數(shù)為45次，可能將30臺高負載機器中的14臺變?yōu)榭捎脿顟B(tài)。
成本一直是我們今年努力的一個大方向。除了上面介紹的兩個項目，我們還使用了分時計算的手段來進一步節(jié)省資源。今年的目標是能夠為公司節(jié)省五千萬的成本，目前已經(jīng)節(jié)省三千五百萬，還沒有達到目標，需要繼續(xù)努力。
上面介紹的是成本方面的工作，下面介紹效率方面的項目。
異常檢測
異常檢測是AIOps最常見的場景，算法也有很多，業(yè)界比較流行的比如普通的統(tǒng)計學習方法——3σ原則，它利用檢測點偏移量來檢測出異常。比如普通的回歸方法，用曲線擬合方法來檢測新的節(jié)點和擬合曲線的偏離程度，甚至有人將CNN和RNN模型應(yīng)用到異常點的檢測。
我們公司使用LVS比較多，為了應(yīng)對流量突增和突減的情況，需要一個異常檢測算法。
通過對LVS流量的時間序列圖的分析，發(fā)現(xiàn)有的曲線有周期性，有的沒有；有的毛刺比較多，有的比較平穩(wěn)，所以需要有一個普適檢測算法，能夠處理各種復(fù)雜的場景。
現(xiàn)實場景中，負樣本比較少，我們采用了無監(jiān)督模型，除此之外，還借鑒投票機制來解決單純的方法有時候具有偏差這樣的問題。
在該項目中，我們采用了五種以上的檢測算法，有統(tǒng)計學中同比環(huán)比的情況、曲線擬合算法以及周志華老師的隔離森林模型。通過這些模型來一起對一個時間序列進行檢測。如果這些算法中有超過一半的算法認為該檢測點為異常點，我們就認為這個點為異常點。
跟蹤了將近半年線上LVS流量數(shù)據(jù)，檢測算法的準確率高于95%，效果還是不錯的。
報警收斂
為了保證系統(tǒng)的可靠性，運維人員經(jīng)常設(shè)置很多監(jiān)控項來及時了解系統(tǒng)的狀況。如果某個監(jiān)控項超過設(shè)置的閾值，則系統(tǒng)中某些指標出現(xiàn)問題，需要運維人員進行處理。這樣不經(jīng)過過濾，直接將所有的報警全部發(fā)出來的方式，很容易增加運維人員的壓力，而且隨著報警數(shù)的增多，也很容易造成他們的疲勞感，并不能達到好的報警效果。
我們對歷史報警進行分析，發(fā)現(xiàn)其中有很多規(guī)律。如果我們利用算法分析出這些報警項之間的關(guān)系，再加上人工經(jīng)驗，將很大程度減少報警的數(shù)目。
人工經(jīng)驗就不用說了，下面介紹一下如何通過算法去分析出報警項之間的潛在關(guān)系。
我們采用機器學習中關(guān)聯(lián)分析常用的算法Apriori來分析歷史報警，該模型利用頻繁項集分析出A→B這種關(guān)系。將這種規(guī)則應(yīng)用到報警中，如果A報警發(fā)出，則B報警就不需要發(fā)出，這樣就能夠成倍減少報警次數(shù)。下圖是我們對過去30天的報警數(shù)據(jù)分析，得到20+的關(guān)聯(lián)規(guī)則：
我們線上維護著一個規(guī)則庫，這個規(guī)則庫來源于兩部分：算法分析規(guī)則、人工總結(jié)規(guī)則。在利用這些規(guī)則同時，我們還結(jié)合了業(yè)務(wù)的評級來對業(yè)務(wù)報警進行一定程度的合并處理。跟蹤了半年的報警，采用這個規(guī)則庫能夠減少60%-80%的報警。
報警事件的根因分析
上節(jié)介紹了減少報警的方式，但是現(xiàn)實中的報警是不可避免的。在發(fā)生報警以后，如何快速定位具體問題就成為關(guān)鍵的環(huán)節(jié)。那如何通過模型去定位問題呢？
通過統(tǒng)計分析，我們線上發(fā)生最多的是這六大類的報警，這些報警分別是：
主機存活(host.alive)；
磁盤空間使用率(df.bytes.used.percent)；
磁盤分區(qū)只讀(sys.disk.rw)；
CPU使用率(cpu.idle)；
內(nèi)存使用率(mem.swapused.percent)；
磁盤io操作百分比(disk.io.util)。
在發(fā)生報警后，運維人員需要登陸到機器或者監(jiān)控系統(tǒng)去看出現(xiàn)問題的時間段內(nèi)是哪些監(jiān)控項或者進程出現(xiàn)問題。這樣繁重且具有很強規(guī)則性的場景特別適合模型去搞定。本節(jié)將介紹一種模型，能夠幫助運維人員縮小報警排查范圍，快速定位到問題。
該項目中要分析兩個維度數(shù)據(jù)：
一個是事件維度，關(guān)注的是六大類報警事件；
一個是指標維度，關(guān)注機器維度的監(jiān)控項（大約有200左右個監(jiān)控項）。
那如何在事件發(fā)生后，找到跟它相關(guān)的指標呢？實現(xiàn)的方法如下：
1）針對每個事件，使用在2014年SIGKDD會議上發(fā)表的論文《Correlating Events with Time Series for Incident Diagnosis》中提到的方法，看哪些指標跟這個事件發(fā)生有關(guān)系。這樣的做目的是對指標進行初篩，達到降維的目的。
2）針對第一步選出來的指標，求出這些指標的信息增益比，選擇前k個（我們?nèi)〉弥凳?）特征作為最后的影響指標；
3）最后使用xgboost對影響指標進行分類，驗證效果。
下圖是我們對這六大類報警的分析結(jié)果，取報警事件最相關(guān)的Top5指標，取得比較好的準確率：
比如下一次發(fā)生“host.alive”報警，就有很大概率是 'cpu.idle' 、 'net.if.total.bits.sum' 、 'mem.memused.percent' 、 'mem.swapused.percent' 和 'ss.closed' 導致的，這樣就能夠減少排查問題的時間。
四、經(jīng)驗和總結(jié)
通過將近一年的努力，我們已經(jīng)在一些單點的應(yīng)用方面取得比較好的效果。下面是接下來要做的工作前瞻：
報警進程級別的定位；
開源組件（容量預(yù)估、異常檢測以及報警事件的關(guān)聯(lián)分析）；
運維聊天機器人。
接下來的工作中，我們將結(jié)合一些具體的場景將上面介紹的一些單點串聯(lián)起來，真正能夠從發(fā)現(xiàn)異常問題、分析問題到最后的解決問題，形成真正意義上的閉環(huán)。
以上就是我此次分享的全部內(nèi)容，感謝大家的參與，謝謝！
直播回放
https://m.qlchat.com/topic/details?topicId=2000002350036659&tracePage=liveCenter
HULK一線技術(shù)雜談
由360云平臺團隊打造的技術(shù)分享公眾號，內(nèi)容涉及云計算、數(shù)據(jù)庫、大數(shù)據(jù)、監(jiān)控、泛前端、自動化測試等眾多技術(shù)領(lǐng)域，通過夯實的技術(shù)積累和豐富的一線實戰(zhàn)經(jīng)驗，為你帶來最有料的技術(shù)分享
原文鏈接：https://mp.weixin.qq.com/s/8ZvBhrnEr89CcqIwhG6YNg
重慶分公司
重慶分公司
