|
作者簡介 王哲 360 AIOps 高級專家 AIOps 白皮書核心編寫專家 1. 背景先說一下 360 運維體系的背景，主要是兩個平臺加上多組服務(wù)，最下面是基礎(chǔ)運維平臺，包括資源管理和流程工單等管理，基礎(chǔ)運維平臺上是360內(nèi)部的私有云平臺HULK，私有云上面提供虛擬化、數(shù)據(jù)庫、中間件以及部分SaaS服務(wù)。 再往上其實標(biāo)示的是云平臺所支撐的業(yè)務(wù)線，主要分為兩組，一組是360大安全線，另一組是360經(jīng)濟收入線，比如導(dǎo)航搜索商業(yè)化，公司里面比較重要的業(yè)務(wù)有自己的SRE團隊，我所在的團隊是 HULK 私有云平臺，后面基于 AIOps 分享可能都不包含業(yè)務(wù)邏輯，因為有些業(yè)務(wù)層的數(shù)據(jù)不像前面中航信同事和周老師能拿到，如果能拿到對于 AIOps 或許更有價值。 1.1 360運維體系變化360 在2012年開始做標(biāo)準(zhǔn)化，剛才三位老師都提到了，如果 AIOps 實施之前標(biāo)準(zhǔn)化做不好，數(shù)據(jù)降維基本上做不了。 2012年到2016年，精細化和平臺化，各種都收集起來放到私有云平臺上。 2016年、2017年做可視化工作，現(xiàn)在持續(xù)積累可視化能力，同時也把運維大數(shù)據(jù)理念提出來了，我們在收集，通過監(jiān)控系統(tǒng)和業(yè)務(wù)層一些打點能力，我們做運維大數(shù)據(jù)平臺。 到今年（2018）為止，我們單點應(yīng)用和幾個單點應(yīng)用串聯(lián)起來這部分能力突破，后面達到智能閉環(huán)，極大的解放研發(fā)和運維生產(chǎn)力，AI 智能輔助決策。 1.2 360 運維情況概覽360 在資源治理上，整體的規(guī)模百家IDC，十多萬服務(wù)器，核心節(jié)點雙環(huán)路；在技術(shù)沉淀上，比如數(shù)據(jù)有EB級別的安全大數(shù)據(jù)，請求量百億級；在運維架構(gòu)體系上，公司也是解耦分層維護；在服務(wù)上，積累了大量的通用Paas和Saas服務(wù)，后面我們也會發(fā)力在IOT場景下的服務(wù)；在業(yè)務(wù)支撐上，360擁有搜索、花椒視頻，信息流，商城，金融等多種技術(shù)架構(gòu)的業(yè)務(wù)。 2. 360 對 AIOps 的思考運維要關(guān)注的三大場景，效率、成本、穩(wěn)定性，360 怎么通過 AIOps 做三個大方向抉擇呢，我們基于很多因素考慮的。 第一，在效率層，我們談智能運維，整個團隊特別感興趣地方。效率上借助于技術(shù)領(lǐng)先，我們能夠通過一些努力快速解決線上問題。 下圖是運維前輩的圖，我們討論來、討論去，唯快不破，哪些點可以做。我們提出了基于基線異常檢測，在報警收斂做一些能力，做一些磁盤故障預(yù)測，可以的話做一些故障自愈能力，一個磁盤的自動清理，還有CPU報警處理，還有機器在一些合理情況下自動重啟，這是在效率層。 拿馬爸爸開個玩笑，效率做得再好，對團隊成長幫助不大，團隊擴張幫助不大，我們覺得先干掉成本的東西。 比如在十多萬的服務(wù)器規(guī)模下，我們更容易去從成本側(cè)做一些產(chǎn)出來證明智能運維團隊的價值。我會重點提一下預(yù)算、服務(wù)器加速流轉(zhuǎn)，資源回收等能力。在這些之上包含有智能調(diào)度，我們做的比較好的就是把MySQL復(fù)用的端口做智能調(diào)度。 我們給 AIOps 團隊的構(gòu)成下了一些定義，就像看病一樣，有看病的，有出方的，還要有能制藥的。 看病，我們期望團隊有成員懂業(yè)務(wù)，知道哪兒有什么數(shù)據(jù)，能提出需求，最關(guān)鍵就是告訴我期望的結(jié)果，這個叫有產(chǎn)品理念的運維，在 AIOps 周期里承擔(dān)需求方之外，更多做一些把控。 第二個，有大數(shù)據(jù)背景運維開發(fā)，他同樣懂業(yè)務(wù)，會玩數(shù)據(jù)，同時得會編程，重點考察他的交付能力，比如數(shù)據(jù)梳理，在下面的算法上面應(yīng)用，就是接地氣的這部分能力。 最后一部分，我們叫算法專家，我們希望有工程化經(jīng)驗，甚至有能力搭建工程化平臺，把業(yè)務(wù)、數(shù)據(jù)和真正AI融合的這部分能力。 3. 智能運維實踐3.1 實踐背景連接產(chǎn)生價值，我們面對有很多公司的團隊，他們有自己獨有數(shù)據(jù)，他們想做智能運維或者這方向的探索，但是他不知道別的團隊有什么數(shù)據(jù)，或者底層團隊有什么數(shù)據(jù)，公司運維體系協(xié)調(diào)。我們給大家建立連接，讓大家懂?dāng)?shù)據(jù)，能夠獲取更多的數(shù)據(jù)一起來做AIOps 研發(fā)工作。
3.2 資源回收體系大概分這六步: 第一，取到各種各樣監(jiān)控項做數(shù)據(jù)治理。 第二，做容量預(yù)估，這里面智能方法。接下來機器做一個畫像，我們把畫像機器做好分類，需要在分類里人工做驗證，運維經(jīng)驗庫的原理，最后通知合并，通知各個業(yè)務(wù)線去，讓他們能夠信服我們的數(shù)據(jù)，紅色的部分是我待會兒會提到 AI 能力部分。 第一部分，基于業(yè)務(wù)流程的容量預(yù)估，我們獲取到業(yè)務(wù)結(jié)構(gòu)，我們會做兩部分預(yù)估： 1、通過機器維度監(jiān)控項做預(yù)測。 2、把歷史的數(shù)據(jù)做定量的分析。 在預(yù)估這塊，針對不同監(jiān)控項，我們會做一些不同的算法并做比較。 做驗證時候有些經(jīng)驗跟大家分享，使用Python的多線程模型不能改善CPU密集型分析的時間，我們嘗試使用四臺高配虛擬機并行計算跑全量的機器列表，不同的算法有不同的精準(zhǔn)度，有些算法性價比更高，這里面需要考量的是你預(yù)計投入的成本和最終期望達到的目標(biāo)。 定量分析比較通用，有些監(jiān)控項用一些均值的方法，有些使用最大值，拿這些來做機器的畫像即可。 主機分類，我們做完預(yù)估后的主機會引入分類模型，這里嘗試使用過bpann，svm，決策樹等算法，決策樹驗證的準(zhǔn)確度是最高，達到99%。分類后中間有一個流轉(zhuǎn)過程，我們先用決策值算法判斷是否該回收，能夠達到用戶的要求，我們把這些主機記錄到 機器分類DB 里給用戶推薦回收。 推薦后如果達不到用戶的需要，我們就要調(diào)整閥值。我們后面會做一個標(biāo)注的系統(tǒng)，這個標(biāo)注系統(tǒng)業(yè)務(wù)線的運維可以標(biāo)注，云平臺的運維工程師也可以標(biāo)注，以此反推回去給一些訓(xùn)練集，讓這個模型更加完善。
上面就是是剛才提到的全套體系，我們在中間還做了點兒比較有意思的事，原來的系統(tǒng)自動給用戶發(fā)回收郵件都比較生硬，比如：A業(yè)務(wù)下，我們判斷多少臺機器你需要回收，業(yè)務(wù)線同事看多了疲乏了，大概率會忽略。 我們智能運維小組同事玩了一個小技巧。發(fā)件人用幾個特別女性名字，組織一堆語料匹配人性化語氣來做第一次回收的提示，比如：我們今天又做了資產(chǎn)檢查，發(fā)現(xiàn)某塊業(yè)務(wù)的資產(chǎn)利用率偏低。等下一個周期用一個男性的名字，更嚴(yán)厲語氣跟業(yè)務(wù)線表述說公司做經(jīng)營分析，對這塊東西分析完了之后，發(fā)覺你的事業(yè)部下面資源嚴(yán)重的損耗。 我們通過這種方式讓業(yè)務(wù)線同事不會忽略郵件，促使他們很積極解釋這個東西該不該回收。 這是例子，這是業(yè)務(wù)方收到周報，告訴他哪些地方有些浪費，把它省下來大概能省多少錢，這是我們半年總結(jié)的時候一個成果。
3.3 MySQL智能調(diào)度系統(tǒng)這是第二個智能運維落地的場景在數(shù)據(jù)庫團隊，DBA團隊同事想盡辦法在這個領(lǐng)域做了些嘗試。 大部分互聯(lián)網(wǎng)公司，基于歷史因素，線上數(shù)據(jù)庫資源都存在大量浪費，如何把不同資源利用率的MySQL端口合理分配到多個物理機上以最大限度節(jié)省資源是我們的目標(biāo)。 我們有一套比較強大的監(jiān)控系統(tǒng)能取得各種數(shù)據(jù)庫指標(biāo)，最終能夠掌握數(shù)據(jù)庫特征數(shù)據(jù)，這是我們數(shù)據(jù)的積累。 這個圖是私有云系統(tǒng)的一個后臺界面，舉例的是一個MySQL端口，它在CPU，IO很閑情況下，內(nèi)存使用很高，所以只能把它所在的主機判定為很忙，但其實這個實例僅僅大量使用了內(nèi)存。線上針對不同的業(yè)務(wù)，在CPU，IO，內(nèi)存上均有不同的使用情況，我們能看到這里有極大的浪費。 針對這個問題，我們需要去選擇一些監(jiān)控項來輔助分配端口實例，采集的監(jiān)控項比如CPU，實際內(nèi)存，磁盤占有量，IO的讀寫性能，網(wǎng)卡的流量，拿這些來為MySQL端口畫像。 然后我們把整個MySQL數(shù)據(jù)庫端口分為四類，1、寫入和讀取比較低，2、計算型，3、磁盤損耗型，4、綜合型（既耗CPU又耗磁盤）。 在分析過程中，取900多實例做了一個訓(xùn)練集，人肉對上述實例劃分到這四類中。
在樣本處理階段，我們用了比較通用的一個歸一化處理，就是一個偏移度，把它變成零到一之間。 在標(biāo)簽這塊為了匹配神經(jīng)網(wǎng)絡(luò)的效果，講四種標(biāo)簽類型用編碼的方式展現(xiàn)出來。 輸入的神經(jīng)元個數(shù)即我們獲取的監(jiān)控項，這里是7。輸出層是4。算法的同事選取的隱藏層個數(shù)是14。 剛才提到的900多個樣本，按照七比三劃分600多訓(xùn)練集，200多測試集，通過這種迭代我們能夠判斷測試集準(zhǔn)確率達到95%，基本上判斷這個算法是可用的。
通過上述手段，我們把機器和MySQL端口實例分別做了畫像（機器畫像復(fù)用了資源回收的那個系統(tǒng)）。 因為我們獲取實例畫像，怎么把實例更好分布在我們認(rèn)為閑置的機器上，然后回收掉沒有實例的主機，就是我們的目標(biāo)。 我們定了一些基本調(diào)度的需求，比如要求遷移次數(shù)少，遷移影響線上服務(wù)盡量小，確保主庫和大訪問量端口保持穩(wěn)定， 還有控制主庫個數(shù)。我們還會加黑名單，有些未來增長量比較大的MySQL端口冗余。 目前看，現(xiàn)在30臺高配數(shù)據(jù)庫機型，14臺可以節(jié)省出來復(fù)用。
目前這套MySQL資源分配體系很多地方不能自動化，但上面的嘗試是我們在一個月內(nèi)完成的，我覺得還可以，后面也會一直持續(xù)不斷地去做類似的事情。 下面是我們做的一個異常檢測的應(yīng)用。 傳統(tǒng)的檢測方式，一類是我們定義的閥值超過多少報警；還有一類是超過這個數(shù)和達到一個數(shù)字后報警。 比如下圖的360內(nèi)部的監(jiān)控系統(tǒng)，能做成這樣也算比較復(fù)雜了。 閥值有了，監(jiān)控多少次，當(dāng)這個次數(shù)平均或者最大、最小等于時候才報警，而且我們限制報警次數(shù)，報了多少次不報了之類的能力。 而且當(dāng)同類報警出現(xiàn)，滿足某些情況下，我們將其合并，把報警收斂起來，我們認(rèn)為已經(jīng)很極致了。 十多萬臺機器，我們用一套硬件監(jiān)控體系，把所有認(rèn)為可能合并的能力都放在那兒，但是運維工程師還是很苦，有很多重要信息還是被淹沒。
剛才那個的應(yīng)用場景是帶寬流量，主要涉及交換機流量變化，還有LVS突變。 但是有些時候還要關(guān)注業(yè)務(wù)的屬性以及所屬業(yè)務(wù)的重要性，有些業(yè)務(wù)線掛了一段時間也可以不管。 基于這個訴求，我們又把它做了一個檢測等級劃分，即剛才整個外面的算法后面加一個系數(shù)，再根據(jù)敏感程度最終去判斷是否值得報警。 這些調(diào)整后，我們線上驗證準(zhǔn)確度達到80%。還是能節(jié)省大量人力。
剛才那個東西場景是帶寬流量，我們交換機流量變化，還有LVS突變。應(yīng)用過程中根據(jù)業(yè)務(wù)的屬性或者公司重要程度，可能有些業(yè)務(wù)線掛了一段時間也可以不管，我們又把它做了一個檢測等級劃分，剛才整個外面的算法后面加一個系數(shù)，再根據(jù)敏感程度最終去判斷是否值得報警。這個部分，我們線上驗證大將達到80%的情況。比如這種點排除極其特殊的點，我們還是能節(jié)省大量人力。
這是我們做的報警收斂嘗試，其實再一個時間窗口之內(nèi)多個報警一起發(fā)生，我們能不能基于Apriori算法看有多少關(guān)聯(lián)度，先一維再變成二維?；谶@種方式，我們統(tǒng)計出來生成20+關(guān)系規(guī)則，凡是涉及這些關(guān)聯(lián)規(guī)則在系統(tǒng)里做了相關(guān)處理，這部分報警減少60%到80%，有些挺有意思。我們認(rèn)為沒關(guān)聯(lián)，至少整個過程中看到還是有很大的關(guān)聯(lián)性。
這是我們基于主機報警事件的根因分析，報警是一個事件，報警的時候有一堆監(jiān)控項，如果發(fā)現(xiàn)報警監(jiān)控項的相關(guān)性，我們可以做到一些根因分析，這部分能力資深運維能看到。如果沒有經(jīng)驗是否能分析出來相關(guān)性，我們算法來實現(xiàn)。 這是微軟2014年的論文，在發(fā)生特定事件時候，我們前面取一個窗口，后面取一個窗口，中間取一個窗口，如果這三個窗口規(guī)則和模型一致，我們認(rèn)為這個事件各報警沒有關(guān)聯(lián)性。如果不一致的話，說明這個報警對我們監(jiān)控項可能導(dǎo)致報警的因素，我們會找到這些因素用信息增益比判斷其中哪些因素導(dǎo)致報警核心的原因。
這部分還在持續(xù)開發(fā)，我們已經(jīng)獲取了下面這些關(guān)聯(lián)關(guān)系（事件、關(guān)鍵指標(biāo)、準(zhǔn)確率）。99%事件幾率是由哪些關(guān)鍵指標(biāo)體現(xiàn)出來的。有些結(jié)果我們發(fā)現(xiàn)比較有趣，比如磁盤讀寫性能會受這些東西影響，報警時候跟這些東西正相關(guān)的。
4. 經(jīng)驗和總結(jié)這是最后一部分，團隊對 AIOps 的經(jīng)驗和總結(jié)。 第一個，我們的數(shù)據(jù)庫選型，搞 AIOps 時序數(shù)據(jù)很重要，我們嘗試用過很多時序數(shù)據(jù)庫，因為考慮到寫入性能問題，成本問題，最后influxDB，而且我們沒有多寫，就寫一份，允許丟失，丟就丟了。針對事件告警日志還是用MongoDB，可視化展現(xiàn)需求用rrd。如果為了一些場景下提到的關(guān)系展現(xiàn)，我們還是用MySQL。針對實時的熱數(shù)據(jù)、計數(shù)器，比如取TOP多少用Redis 。ES也可以用，主要做檢索引擎，也可以可以做些日志。
第二個經(jīng)驗不是技術(shù)問題，是項目管理問題，PDCA，我們每做一個智能 AIOps 項目要不斷地迭代。 我們做運維項目和AIOps項目很多時候能做到有計劃、能執(zhí)行，但是實現(xiàn)之后，能否持續(xù)檢查和演進處理可能扔掉了。最終導(dǎo)致這件事情越做可能達不到我們趨近完美結(jié)果。 AIOps的項目失敗率很高。如果大家做這個方向的話，自己心里應(yīng)該知道，很多時候奔著一個目標(biāo)去，但是得到結(jié)果很不理想。強烈建議大家一定要在計劃、執(zhí)行、檢查和處理過程中把這個東西一步步改進好，當(dāng)然該舍棄時候要舍棄。
第三個經(jīng)驗，我們按照大數(shù)據(jù)理念，把整個運維大數(shù)據(jù)做了一些分層，構(gòu)成了運維大數(shù)據(jù)平臺，主要分為原始層、明細層、匯聚層、應(yīng)用層。 原始層就是上面這些指標(biāo)和數(shù)據(jù)；明細層，完成數(shù)據(jù)標(biāo)準(zhǔn)化，同時按照業(yè)務(wù)分類完成數(shù)據(jù)分類，這個業(yè)務(wù)分類也很泛泛，運維里面還是我們經(jīng)驗，可以這樣分類就這么分；到了匯聚層，我們在哪一個領(lǐng)域里做AIOps能力，我們按照主體域完成對于數(shù)據(jù)匯聚，形成統(tǒng)一試圖；然后就是將這些匯聚的維度各種組合，解決AIOps要在哪些場景實現(xiàn)哪些能力的問題。 這就是對于運維大數(shù)據(jù)資產(chǎn)的架構(gòu)，這是脫胎于360大數(shù)據(jù)平臺部門的一套體系。
本文根據(jù)作者在GOPS 2018 · 上海站的演講整理發(fā)布 《企業(yè)級 AIOps 實施建議白皮書》v1.0 GOPS 2019 上海站正式發(fā)布 各大行業(yè)名企案例等你來撩~
GOPS 2019 · 深圳站官方視頻新鮮出爐
|
|
|
