節(jié)省3500萬的背后，運(yùn)維如何兼顧成本與效率？

一、背景介紹

隨著互聯(lián)網(wǎng)的軟硬件呈現(xiàn)爆發(fā)性的增長，新的架構(gòu)層出不窮，運(yùn)維人員需要做到7*24小時(shí)的職守來保證系統(tǒng)的可靠性和穩(wěn)定性。但這明顯是不可能的。

那么面對(duì)這種空前的壓力，有沒有一種“機(jī)器大腦”能夠減少甚至代替運(yùn)維人員去做一些事情，極大地減少他們的工作量，提高運(yùn)維的效率？又該如何得到這種“機(jī)器大腦”呢？

很多運(yùn)維場景都可以總結(jié)成一些規(guī)則化的東西，可以經(jīng)過提煉總結(jié)生成人工經(jīng)驗(yàn)庫。除了人工經(jīng)驗(yàn)以外，是否可以通過AI算法對(duì)歷史數(shù)據(jù)進(jìn)行分析，得到一些由機(jī)器生成的規(guī)則？

答案當(dāng)然是可以的。如果能將AI算法+人工經(jīng)驗(yàn)應(yīng)用到Ops中，代替一部分的人工決策，這樣將推動(dòng)運(yùn)維從普通的自動(dòng)化階段到智能化階段邁進(jìn)。

從今年開始，很多公司在AIOps領(lǐng)域進(jìn)行了一些嘗試。我們公司的AIOps也經(jīng)歷了從最開始的標(biāo)準(zhǔn)化到后來的精細(xì)化、數(shù)據(jù)化運(yùn)維的前期鋪墊，在2018年，AIOps項(xiàng)目組正式組建，經(jīng)過近一年的發(fā)展，已經(jīng)在很多單點(diǎn)應(yīng)用方面取得比較好的效果，并爭取在今年年底，能夠?qū)崿F(xiàn)一些場景的閉環(huán)。

二、360對(duì)AIOps的思考

大家熟悉的AIOps場景有很多，諸如異常檢測、根因分析、故障自愈、容量預(yù)測等方面。根據(jù)平臺(tái)的實(shí)際場景和業(yè)界AIOps的實(shí)踐經(jīng)驗(yàn)，我們將AIOps劃分為三個(gè)場景：成本、效率和穩(wěn)定性。

針對(duì)成本來說，利用AI算法節(jié)省資源、智能調(diào)度、提高資源利用率的手段來節(jié)省資源；針對(duì)效率方面來說，利用AI算法主動(dòng)發(fā)現(xiàn)問題、分析問題和解決問題，真正節(jié)省人力，提高效率。

那如何開展AIOps呢？我們認(rèn)為AIOps需要開展需要下面三種人員：運(yùn)維人員、運(yùn)維開發(fā)、機(jī)器學(xué)習(xí)工程師。三者缺一不可，否則項(xiàng)目就會(huì)半途而廢。

上面介紹了我們對(duì)AIOps的理解，下面就是純干貨出場了，我們將分兩個(gè)大方向五個(gè)具體項(xiàng)目來介紹AIOps最佳實(shí)踐經(jīng)驗(yàn)。

三、AIOps實(shí)踐方案

數(shù)據(jù)積累

所謂“巧婦難為無米之炊”，在啟動(dòng)AIOps之前，需要準(zhǔn)備很多數(shù)據(jù)，包括機(jī)器維度的基礎(chǔ)數(shù)據(jù)、網(wǎng)絡(luò)數(shù)據(jù)、日志數(shù)據(jù)、甚至進(jìn)程數(shù)據(jù)等。我們有專門的大數(shù)據(jù)工程師歷時(shí)兩年多對(duì)數(shù)據(jù)進(jìn)行收集，為后面的數(shù)據(jù)分析、機(jī)器學(xué)習(xí)模型打下堅(jiān)實(shí)的基礎(chǔ)。

下面是我們前后收集的數(shù)據(jù)總結(jié)：

容量預(yù)估

有了歷史數(shù)據(jù)，我們就可以對(duì)數(shù)據(jù)進(jìn)行一些分析。

首先介紹一種場景——容量預(yù)估。對(duì)重要監(jiān)控項(xiàng)的預(yù)測，能夠使我們及時(shí)了解指標(biāo)的走勢，為后面的決策提供了科學(xué)的依據(jù)。

監(jiān)控項(xiàng)的樣本就是時(shí)間序列，通過分析監(jiān)控項(xiàng)的序列，得到未來一段時(shí)間的預(yù)測值。根據(jù)波動(dòng)劇烈程度，監(jiān)控項(xiàng)可以分為波動(dòng)不太劇烈和劇烈的；根據(jù)周期性，可以分為具有周期性和不具有周期性等等，當(dāng)然還有很多劃分的標(biāo)準(zhǔn)。可見，不同時(shí)間的序列，我們需要使用不同的模型去預(yù)測。

在對(duì)時(shí)間序列進(jìn)行預(yù)測的過程中，我們先后使用了下面幾種模型，從中總結(jié)出了一些經(jīng)驗(yàn)：

很多時(shí)間序列具有周期性，我們還自研了一個(gè)周期性檢測的模型，能夠比較好的判斷一個(gè)序列是否具有周期性。在周期性檢測的基礎(chǔ)上，進(jìn)一步跟進(jìn)序列的周期性特征，來預(yù)測不同的時(shí)間序列。

對(duì)于預(yù)測模型，前人已經(jīng)總結(jié)了很多種，我們在項(xiàng)目中使用了下面一些模型，你可以根據(jù)時(shí)間開銷和準(zhǔn)確度來選擇自己的模型。以上所有的預(yù)測方法將在近期進(jìn)行開源，還希望大家持續(xù)關(guān)注：

在實(shí)際的項(xiàng)目中，我們經(jīng)常會(huì)遇到分類任務(wù)，比如根據(jù)主機(jī)監(jiān)控項(xiàng)的特征，需要用模型判斷出該機(jī)器是否為空閑機(jī)器；再比如，我們會(huì)根據(jù)監(jiān)控項(xiàng)的特征，來判斷該機(jī)器屬于的類型（CPU、磁盤、內(nèi)存密集型）。

機(jī)器學(xué)習(xí)中有很多分類算法，比如SVM、決策樹、分類樹等都可以完成分類任務(wù)。我們只需要做一些預(yù)處理以及特征工程等方面的工作后，就可以使用Python中現(xiàn)成的分類模型，在此就不詳細(xì)介紹。

有了容量預(yù)估和主機(jī)分類的基礎(chǔ)模塊后，我們在成本方面先后做了資源回收、智能調(diào)度系統(tǒng)兩個(gè)項(xiàng)目，并取得了比較好的效果。

資源回收

資源回收，就是及時(shí)發(fā)現(xiàn)比較空閑的機(jī)器，通知業(yè)務(wù)進(jìn)行回收，以達(dá)到提高資源利用率的目的。

我們的資源回收系統(tǒng)分為三塊：容量預(yù)估、主機(jī)分類以及通知模塊。容量預(yù)估模型是對(duì)五個(gè)比較重要的指標(biāo)（CPU使用率、內(nèi)存使用率、網(wǎng)卡流量、磁盤使用率以及狀態(tài)連接數(shù)）進(jìn)行預(yù)測以及定量分析后，生成了五個(gè)特征。接下來使用分類器來對(duì)五個(gè)特征進(jìn)行分類后，得到空閑的機(jī)器列表，最后將空閑機(jī)器通知給相應(yīng)的業(yè)務(wù)負(fù)責(zé)人。

在AIOps中，經(jīng)常用遇到負(fù)樣本不足的問題，一個(gè)原因是異常的場景比較少，另一個(gè)原因是用戶標(biāo)注的成本比較高。

在主機(jī)分類的過程中，我們使用了兩種手段來生成樣本，一種是人工標(biāo)注，一種是用戶標(biāo)注，解決了負(fù)樣本不足的問題。下面這幅圖是我們在Q2季度時(shí)候資源回收取得的效果，目前看還不錯(cuò)：

MySQL智能調(diào)度系統(tǒng)

我們線上的MySQL機(jī)器存在嚴(yán)重的浪費(fèi)問題，例如下面的場景：可以看到只要有一個(gè)指標(biāo)是高負(fù)載的情況，這個(gè)機(jī)器將不可用。細(xì)想一下，如果一臺(tái)機(jī)器內(nèi)存比較高，但是并不代表這臺(tái)機(jī)器不可用，我們可以將CPU使用率較高但內(nèi)存使用率較低的實(shí)例調(diào)度到這臺(tái)機(jī)器上，達(dá)到充分利用資源的目的。

為了將不同類型的機(jī)器和不同類型的實(shí)例進(jìn)行合理搭配，需要將實(shí)例和機(jī)器進(jìn)行分類。在該項(xiàng)目中，實(shí)例分類采用了BP神經(jīng)網(wǎng)絡(luò)，其中輸入是7個(gè)重要的實(shí)例指標(biāo)，輸出是4個(gè)類別（低消耗、計(jì)算型、存儲(chǔ)型、綜合型）。

機(jī)器分類采用決策樹模型，輸入是5個(gè)機(jī)器指標(biāo)，輸出和實(shí)例的輸出類型一樣。樣本全部采用人工標(biāo)注的方式，生成了1000左右的樣本。

有了分類好的機(jī)器和實(shí)例以后，就需要進(jìn)行調(diào)度。在調(diào)度過程中，考慮了多種因素：

• 盡量保證遷移次數(shù)少

• 盡量少的避免切主

• 保證主庫和大容量端口的穩(wěn)定性

• 控制每臺(tái)機(jī)器上主庫的個(gè)數(shù)（不超過5個(gè)）和實(shí)例總個(gè)數(shù)

• 同一端口的實(shí)例不能出現(xiàn)在同一機(jī)器上

• 不調(diào)度黑名單機(jī)器

我們按照上面的原則對(duì)一個(gè)機(jī)房的實(shí)例進(jìn)行測試，端口遷移的次數(shù)為45次，可能將30臺(tái)高負(fù)載機(jī)器中的14臺(tái)變?yōu)榭捎脿顟B(tài)。

成本一直是我們今年努力的一個(gè)大方向。除了上面介紹的兩個(gè)項(xiàng)目，我們還使用了分時(shí)計(jì)算的手段來進(jìn)一步節(jié)省資源。今年的目標(biāo)是能夠?yàn)楣竟?jié)省五千萬的成本，目前已經(jīng)節(jié)省三千五百萬，還沒有達(dá)到目標(biāo)，需要繼續(xù)努力。

上面介紹的是成本方面的工作，下面介紹效率方面的項(xiàng)目。

異常檢測

異常檢測是AIOps最常見的場景，算法也有很多，業(yè)界比較流行的比如普通的統(tǒng)計(jì)學(xué)習(xí)方法——3σ原則，它利用檢測點(diǎn)偏移量來檢測出異常。比如普通的回歸方法，用曲線擬合方法來檢測新的節(jié)點(diǎn)和擬合曲線的偏離程度，甚至有人將CNN和RNN模型應(yīng)用到異常點(diǎn)的檢測。

我們公司使用LVS比較多，為了應(yīng)對(duì)流量突增和突減的情況，需要一個(gè)異常檢測算法。

通過對(duì)LVS流量的時(shí)間序列圖的分析，發(fā)現(xiàn)有的曲線有周期性，有的沒有；有的毛刺比較多，有的比較平穩(wěn)，所以需要有一個(gè)普適檢測算法，能夠處理各種復(fù)雜的場景。

現(xiàn)實(shí)場景中，負(fù)樣本比較少，我們采用了無監(jiān)督模型，除此之外，還借鑒投票機(jī)制來解決單純的方法有時(shí)候具有偏差這樣的問題。

在該項(xiàng)目中，我們采用了五種以上的檢測算法，有統(tǒng)計(jì)學(xué)中同比環(huán)比的情況、曲線擬合算法以及周志華老師的隔離森林模型。通過這些模型來一起對(duì)一個(gè)時(shí)間序列進(jìn)行檢測。如果這些算法中有超過一半的算法認(rèn)為該檢測點(diǎn)為異常點(diǎn)，我們就認(rèn)為這個(gè)點(diǎn)為異常點(diǎn)。

跟蹤了將近半年線上LVS流量數(shù)據(jù)，檢測算法的準(zhǔn)確率高于95%，效果還是不錯(cuò)的。

報(bào)警收斂

為了保證系統(tǒng)的可靠性，運(yùn)維人員經(jīng)常設(shè)置很多監(jiān)控項(xiàng)來及時(shí)了解系統(tǒng)的狀況。如果某個(gè)監(jiān)控項(xiàng)超過設(shè)置的閾值，則系統(tǒng)中某些指標(biāo)出現(xiàn)問題，需要運(yùn)維人員進(jìn)行處理。這樣不經(jīng)過過濾，直接將所有的報(bào)警全部發(fā)出來的方式，很容易增加運(yùn)維人員的壓力，而且隨著報(bào)警數(shù)的增多，也很容易造成他們的疲勞感，并不能達(dá)到好的報(bào)警效果。

我們對(duì)歷史報(bào)警進(jìn)行分析，發(fā)現(xiàn)其中有很多規(guī)律。如果我們利用算法分析出這些報(bào)警項(xiàng)之間的關(guān)系，再加上人工經(jīng)驗(yàn)，將很大程度減少報(bào)警的數(shù)目。

人工經(jīng)驗(yàn)就不用說了，下面介紹一下如何通過算法去分析出報(bào)警項(xiàng)之間的潛在關(guān)系。

我們采用機(jī)器學(xué)習(xí)中關(guān)聯(lián)分析常用的算法Apriori來分析歷史報(bào)警，該模型利用頻繁項(xiàng)集分析出A→B這種關(guān)系。將這種規(guī)則應(yīng)用到報(bào)警中，如果A報(bào)警發(fā)出，則B報(bào)警就不需要發(fā)出，這樣就能夠成倍減少報(bào)警次數(shù)。下圖是我們對(duì)過去30天的報(bào)警數(shù)據(jù)分析，得到20+的關(guān)聯(lián)規(guī)則：

我們線上維護(hù)著一個(gè)規(guī)則庫，這個(gè)規(guī)則庫來源于兩部分：算法分析規(guī)則、人工總結(jié)規(guī)則。在利用這些規(guī)則同時(shí)，我們還結(jié)合了業(yè)務(wù)的評(píng)級(jí)來對(duì)業(yè)務(wù)報(bào)警進(jìn)行一定程度的合并處理。跟蹤了半年的報(bào)警，采用這個(gè)規(guī)則庫能夠減少60%-80%的報(bào)警。

報(bào)警事件的根因分析

上節(jié)介紹了減少報(bào)警的方式，但是現(xiàn)實(shí)中的報(bào)警是不可避免的。在發(fā)生報(bào)警以后，如何快速定位具體問題就成為關(guān)鍵的環(huán)節(jié)。那如何通過模型去定位問題呢？

通過統(tǒng)計(jì)分析，我們線上發(fā)生最多的是這六大類的報(bào)警，這些報(bào)警分別是：

• 主機(jī)存活(host.alive)；

• 磁盤空間使用率(df.bytes.used.percent)；

• 磁盤分區(qū)只讀(sys.disk.rw)；

• CPU使用率(cpu.idle)；

• 內(nèi)存使用率(mem.swapused.percent)；

• 磁盤io操作百分比(disk.io.util)。

在發(fā)生報(bào)警后，運(yùn)維人員需要登陸到機(jī)器或者監(jiān)控系統(tǒng)去看出現(xiàn)問題的時(shí)間段內(nèi)是哪些監(jiān)控項(xiàng)或者進(jìn)程出現(xiàn)問題。這樣繁重且具有很強(qiáng)規(guī)則性的場景特別適合模型去搞定。本節(jié)將介紹一種模型，能夠幫助運(yùn)維人員縮小報(bào)警排查范圍，快速定位到問題。

該項(xiàng)目中要分析兩個(gè)維度數(shù)據(jù)：

• 一個(gè)是事件維度，關(guān)注的是六大類報(bào)警事件；

• 一個(gè)是指標(biāo)維度，關(guān)注機(jī)器維度的監(jiān)控項(xiàng)（大約有200左右個(gè)監(jiān)控項(xiàng)）。

那如何在事件發(fā)生后，找到跟它相關(guān)的指標(biāo)呢？實(shí)現(xiàn)的方法如下：

1）針對(duì)每個(gè)事件，使用在2014年SIGKDD會(huì)議上發(fā)表的論文《Correlating Events with Time Series for Incident Diagnosis》中提到的方法，看哪些指標(biāo)跟這個(gè)事件發(fā)生有關(guān)系。這樣的做目的是對(duì)指標(biāo)進(jìn)行初篩，達(dá)到降維的目的。

2）針對(duì)第一步選出來的指標(biāo)，求出這些指標(biāo)的信息增益比，選擇前k個(gè)（我們?nèi)〉弥凳?）特征作為最后的影響指標(biāo)；

3）最后使用xgboost對(duì)影響指標(biāo)進(jìn)行分類，驗(yàn)證效果。

下圖是我們對(duì)這六大類報(bào)警的分析結(jié)果，取報(bào)警事件最相關(guān)的Top5指標(biāo)，取得比較好的準(zhǔn)確率：

比如下一次發(fā)生“host.alive”報(bào)警，就有很大概率是 'cpu.idle' 、 'net.if.total.bits.sum' 、 'mem.memused.percent' 、 'mem.swapused.percent' 和 'ss.closed' 導(dǎo)致的，這樣就能夠減少排查問題的時(shí)間。

四、經(jīng)驗(yàn)和總結(jié)

通過將近一年的努力，我們已經(jīng)在一些單點(diǎn)的應(yīng)用方面取得比較好的效果。下面是接下來要做的工作前瞻：

• 報(bào)警進(jìn)程級(jí)別的定位；

• 開源組件（容量預(yù)估、異常檢測以及報(bào)警事件的關(guān)聯(lián)分析）；

• 運(yùn)維聊天機(jī)器人。

接下來的工作中，我們將結(jié)合一些具體的場景將上面介紹的一些單點(diǎn)串聯(lián)起來，真正能夠從發(fā)現(xiàn)異常問題、分析問題到最后的解決問題，形成真正意義上的閉環(huán)。

以上就是我此次分享的全部內(nèi)容，感謝大家的參與，謝謝！

直播回放

https://m.qlchat.com/topic/details?topicId=2000002350036659&tracePage=liveCenter