AI賦能DevOps：數據驅動的全棧工程師實踐

DevOps是什麼？

對於傳統的軟件研發而言，開發，測試，運維，運營，有不一樣的崗位進行分工協做，以保證質量和專業度，同一件事情，依賴不一樣崗位的排期、溝通、協調，效率不免會有打折。而對於互聯網業務來講，快速的迭代，對人力的需求很是強烈，不大可能有足夠的人力支撐這麼多崗位。同時跨部門的溝通，強烈影響了項目的進度，所以一些快速發展的團隊，開始推行DevOps，本身作測試，保證代碼質量，本身上線運維，監控告警。亞馬遜很早就開始推行"you build it, you run it"的文化。因爲本身對本身的作事情很清楚，所以效率也會很高。這就是DevOps。

DevOps的挑戰

DevOps責任多，事情多且雜。一天的時間怎麼分配？我做爲研發，確定是但願一天90%可以專心的寫代碼。但實際上只有20%的時間來寫代碼，其餘的時間作什麼？幫用戶調查問題，處理工單。作線上的運維等等。用戶提了一個工單，你要立馬放下手中的工做去幫用戶調查問題。結果就發現時間被碎片化了，一天中很難有大塊的時間去專門作研發。

經過數據驅動和智能自動化應對DevOps的挑戰

怎麼解決研發過程當中時間碎片化的問題？咱們原來作了不少重複性的工做，這些工做能夠總結和沉澱下來，經過工具幫咱們去沉澱。咱們原來須要調查問題的時候，才登陸集羣要抓日誌；如今作一個採集日誌的工具，把全部日誌的實時採集到雲端，當須要看日誌的時候，我立馬就能夠在服務端看到全部的日誌信息。原來須要到機器上搜索日誌，如今在雲端作倒排索引，直接就能夠搜索到整個集羣的日誌。原來我可能要用excel作一些數據分析的工做，去分析個人運營效果怎麼樣。如今在服務端實現一套實時分析的計算引擎，再加上可視化功能，幫助作各類各樣的報表。原來調查問題的時候要登陸集羣上，用vim打開集羣上的日誌，看文件上下文是什麼樣子的。如今在雲端作一個上下文關聯的功能，直接在雲端就能夠看到全部集羣上的日誌和上下文信息。原來調查問題可能依賴於人的經驗。如今經過AI幫咱們作自動化的事情。

因此總結下來咱們但願經過數據中臺幫咱們實現數據驅動的運維，來代替原來的人工驅動。藉助於AI幫咱們實現自動化、智能化。經過這種數據驅動加上智能自動化的運維幫咱們節省被碎片化的時間。

數據中臺的挑戰

若是咱們要作這樣一個數據中臺會面臨哪些挑戰呢？首先就是數據太少，若是咱們抓取的數據太少的話，那麼咱們的信息量就會太少，在分鐘級別的監控裏面可能不少信息就被平均掉了，咱們只有抓秒級監控才能夠看到咱們所關心的數據。第二個是實時性的挑戰，咱們作線上故障恢復的時候，都但願是說能夠儘快定位問題的答案，儘快去恢復，這就是一個實時性的需求。若是咱們找到答案太慢，可能已經錯過了一個最佳的自救的時間。第三，系統愈來愈複雜，咱們的需求是愈來愈多的，咱們每加一個需求要加一個模塊，那麼維護整個一套系統實際上是一個很是大的挑戰。最後是數據太多的問題，數據太少是問題，太多也是問題。太少的話信息量不足，太多的話不少重要的信息被淹沒。關於數據規模的問題和數據速度的問題能夠經過數據中臺來解決，數據中臺幫咱們經過算力來換取一個數據的速度和規模；而數據太多信息爆炸的問題，咱們用AI算法來換取對數據深刻的洞察力。

數據中臺的基礎能力

數據中臺具有的能力，第一個就是數據採集，數據採集幫咱們從各個數據孤島中，從各類環境中，把各類各樣的格式的日誌統一採集，而後以統一的格式被存儲起來。原來數據可能在手機上，可能在網頁上等等各類各樣的環境，格式也不同。統一採集以後， 咱們就有統一的格式，之後分析就很是方便了。數據採集幫咱們作的髒活累活，實際上是幫咱們節省了不少的時間。數據採集以後，中臺要有二次加工的能力。爲何要二次加工？由於咱們採集過來的數據可能包含着髒數據，垃圾數據，咱們要過濾掉，作一些轉換和富華。加強數據質量，數據質量加強之後，分析的時候才能夠駕輕就熟。接下來就是一個查詢分析的能力，中臺提供的進行交互式的查詢分析，能夠在秒級別分析上億日誌。經過這種查詢分析能力你能夠盡情的探索你數據裏面包含了什麼價值。查詢分析依賴於人的經驗探索數據，那麼咱們還能夠藉助AI自動探索數據，這就是AI的預測能力和異常檢測能力以及根因分析的能力。經過數據中臺將AI，幫助咱們去獲取對數據源的可觀察性，進而經過數據可觀察性，實現對運維繫統的可觀察性。

基於數據中臺的問題調查路徑

咱們前面介紹了數據中臺的，接下來我會以一系列的實踐去分享咱們怎麼樣利用這樣一個數據中臺幫咱們解決咱們DevOps所遇到的各類各樣的問題。

咱們說到數據驅動的運維，首先咱們會面臨大規模的數據，如何去找有效的信息，這就是一個發現的過程。原來咱們經過grep搜索的關鍵字，經過awk作一些簡單的計算；藉助中臺，咱們能夠經過交互式查詢去不停探索答案，也能夠經過異常檢測幫助咱們智能的檢測數據裏面到底有什麼異常的信息。
當咱們發現一些有效信息之後，接下來怎麼辦？咱們要從這些線索出發，而後去找更多的線索，去找關聯關係，去找因果關係，這個就是上下文鑽取，以及聚類。那麼經過這種鑽取咱們能夠找到一系列的更加關聯的信息，咱們最終找到了信息足夠多以後，咱們要肯定最終的一個答案，這個就是根因分析，幫咱們肯定故障的根本緣由是什麼。

數據驅動和AI驅動的DevOps實踐

1：搜索和上下文

咱們作數據分析最簡單的形式是什麼？咱們上網的時候，用的最多的工具是什麼？是搜索引擎，搜索能夠幫咱們盡情探索數據中的價值。原來咱們到機器上搜索日誌，數據在文件中是是有序的存儲的。而在採集的過程當中，爲了性能的考慮，會以亂序的形式存儲下來，固然咱們搜索完以後，可能咱們看到的是亂序的日誌。如何從這些亂序的日誌中找它的上下文信息呢？咱們爲每一條日誌指定一個編碼。當咱們搜索到一條日誌以後，去看它的編碼值，再去計算它的下一條編碼是什麼，根據編號搜索下一條日誌。經過這種方式去找，搜索，去定位下上文

咱們看一個搜索和上下文的樣例。咱們把全部集羣的日誌都被統一的採集到一塊兒，而後去搜索整個集羣日誌，這個時候若是咱們對某一臺機器感興趣的話，咱們能夠把機器的hostname加入到搜索條件裏面去。這個時候若是咱們對某一些關鍵字不感興趣的話，咱們能夠過濾掉。這個時候咱們定位到9條日誌，咱們對這9條日誌感興趣。咱們能夠去看上下文的信息。在上下文裏面，能夠以上下文嚴格有序的一種形式去看這條日誌先後發生的一些事情，經過這種方式找它的一個因果關係。

2：全局視野和局部視野

搜索針對的對象是什麼？是日誌；日誌是什麼？是一種事件類型的數據，裏面包含的信息有事件的發生的時間、對象、操做，還有各類屬性，關於事件的描述是很是詳細的。除了這種事件日誌，還有一種指標日誌。指標日誌有時間，有一個彙總的數值，例如用一個數值表示這一分鐘有多少個瀏覽量。這兩種數據有什麼區別？事件日誌描述的是一個很是詳細的信息，因此它的體量和規模是很是大的。它表明的是咱們從局部去觀察問題的一種視角。而指標數據是一種彙總的信息，全部它的體量很是小。可是它表明的是一種全局視角，歸納整個事件的信息。例如，咱們一分鐘有1萬次的訪問，咱們用這種事件日誌來表示可能就真的是1萬條數據。用這種指標日誌可能就是1萬這一個數字，這就是二者之間的差異。這兩種日誌之中是否是割裂的？不是，咱們能夠經過計算把事件日誌轉化爲指標日誌，一個是表明大視野，一個表明小視野。咱們能夠充分利用計算在這兩種視野之間切換去調查問題。

舉個例子，咱們面對一個事件日誌，可能對某一些維度感興趣，比方說時間維度，那麼在時間維度中統計趨勢指標；或者對IP維度感興趣，能夠統計出IP分佈，他們這個時候咱們就把一個事件日誌轉化成了指標日誌，從局部視野跳到所有視野看待問題。
當咱們看到某一個數值比較特殊，咱們對它進行下鑽，增長維度，進行更多的統計。比方說咱們按照不一樣的IP統計出它的趨勢。假如統計出來的各個維度之間，咱們對某一些維度感興趣的話，咱們把它單獨拎出來，跳回咱們原來的事件日誌當中，幫咱們搜索對應的事件。這樣的話咱們就造成了一個調查問題的閉環，咱們從事件日誌出發去統計它全局的信息，再回到原來的事件，這是一個閉環。

3：聚類解決數據爆炸

事件日誌的體量是很是大的，如今對於咱們的業務來講，天天的數據量都在上漲，每分鐘能達到上億條的日誌，日誌這麼多，重要的信息被淹沒了怎麼辦？即便咱們只關心錯誤的日誌，可是錯誤的信息可能都有上千條，何時看完？咱們一般對於這不少大量日誌的這種場景，首先想的是排除法，比方說咱們先把一些不關心的日誌排除掉，逐步排除掉一些關鍵字，逐步的縮小數據的體量，慢慢靠近咱們關心的信息。對於數值類來講，咱們怎麼樣排除？咱們可能統計數值的百分位，去統計它的25分位在哪裏，75分位在哪裏？99分位在哪裏？假如說說咱們對99分位感興趣，只須要過濾出來99分位以上的數據，經過這種方式減小數值類型數據的體量。

可是這種排除法不必定能夠幫助咱們找到全部咱們所關心的問題，由於咱們如今的業務實在是太複雜了，維度太多了。有一個真實的案例，就是有一次咱們一個新版本發佈，有一個邊界的條件沒有測試到，上線以後也沒發現，直到用戶跑過來問，爲何我以前能夠用，如今不能用？如今開始報錯了？我到這個時候才發現發現，真的是從升級那一刻開始出現一種新類型的日誌，原來都沒有這種日誌。顯然用排除法是沒有辦法幫我解決升級後的這種異常檢測，怎麼辦呢？那咱們引入了智能聚類。即便每分鐘產生上億條日誌，可能裏面不到100種類新的事件，只是說每一種類新的事件重複發生了不少次，因此形成總體數據的膨脹。

經過這種分析數據之間的關聯性，把數據裏面的干擾信息過濾掉，提取出裏面一些公共的特徵，這個就是聚類。在這個例子中咱們有1300萬條數據，人眼去看這1300萬條可能一天一晚上也看不到。可是咱們能夠經過聚類，最後只有35條聚類的結果，這個時候咱們去看35種類型的事件，其實一眼就能夠看到，那麼在機器上到底發生了什麼事情。好比說，我能夠一眼看到這是有這樣一個timeout關鍵字，是否是要特殊的關注它？

咱們怎麼樣利用智能聚會幫助咱們解決升級後故障發現的問題。咱們能夠經過對比升級後你的聚類結果和升級前了聚類結果，查看有沒有什麼差異，若是一個新的事件在升級以後出現了，而以前是沒有的，這是特殊關注的。經過這種方式咱們去作告警，及時發現問題，及時的處理，避免影響到用戶。

4：Metric數據異常檢測

經過智能聚類實現對文本類的數據異常類檢測。那麼對於咱們剛纔說的Metric指標數據，怎麼樣尋求異常檢測？最簡單的指標什麼？是一條平穩的直線，圍繞這樣一條直線，可能有一個很輕微的在正常範圍以內的波動，對於這種數值咱們設一個固定的閾值，能夠很好的把一些大的抖動捕獲出來。可是這是一種很是簡單的場景，在現實的業務中其實沒有這麼簡單的，現實的數據必定是有各類各樣的波動。
最多見波動是什麼？是週期性。通常咱們工做日它的流量比較高，到了週末流量又跌下去了，那就是一個週期新的波動，因此對於波動性的信息咱們怎麼樣作異常的檢測？我能夠經過同比、環比，拿當前時間點的數據和上一個週期同一個時間點的數據進行對比，看看有沒有發生比較大的誤差，這就是同環比算法。

還有一種狀況就是趨勢性，對於互聯網業務來講，增加是一種常態，沒有增加的業務是沒有前途的。在增加的趨勢中，可能還有周期性的波動，以及擾動。咱們所關心的那種異常的點可能被掩藏在這樣一個增加的趨勢中，對於人眼來講，其實一眼就能夠看出來哪個點是異常點。可是對於算法來講檢測出來這樣一個異常點是一個很大的挑戰。咱們的解決方案是經過機器學習，經過學習歷史上的數據它的一個趨勢性信息，週期性信息，而後去預測將來的點是什麼樣子的。那麼把預測的點和真實出現的這個數據進行一個對比，那麼當這樣一個差值發生比較大的誤差的時候，就認爲這是一個異常的點。經過這種方式去檢測趨勢性數據裏面的一個異常點。

無論是週期性信息仍是趨勢性的信息，它其實都是一種很規律的一種波動。那麼還有一種數據波動稱爲斷層。比方說原來咱們一個機器，它的CPU很低。忽然有一天你把流量切到機器上，它的CPU立馬暴漲到另一個水平，可是它的波動又沒有什麼變化，這就是斷層。對於斷層的數據，其實統計的時候是很是難的，由於在這樣一個點裏面它的導數是沒有的。那麼咱們能夠用專門的斷層檢測算法去檢測出來。
最後一個就是變點，變點是什麼？就是在某一個點，它的波動形態、統計特徵發生了變化。原來多是一條平穩的直線，可是在某一個時間點假如說發生了異常，你的流量抖動開始發生了很是大的一個抖動，這就是一個變點。經過變點算法，統計全部數據裏面的波動信息，而後對比不一樣點上的波動信息進行檢測這種變點。這就是咱們針對Metric指標數據，利用機器學習、統計算法進行異常檢測的方法。

5：異常根因分析

當咱們檢測到異常以後，下一步要作什麼事情？要找這個異常它發生的緣由是什麼？而且及時的去修復它。假如咱們網站流量下跌了7%，下跌是什麼緣由引發的？一般人工是怎麼檢測這個問題的？咱們可能按照咱們的經驗逐步去排查，比方說咱們先到服務端看一下，有沒有錯過日誌；服務端沒有，再看網絡上有沒有抖動。OK，那網絡端沒有抖動，接下來怎麼辦，再去看用戶的統計上有沒有異常的一些抖動，結果發現，用戶的統計上有抖動的話怎麼辦？咱們再去下鑽，去看什麼類型的用戶發生了抖動。比方說不一樣的城市有沒有抖動，不一樣的接入點有沒有抖動？不一樣的客戶端有沒有抖動？結果發如今客戶端這樣一個維度，有數據是抖動的。那麼咱們再深刻的下鑽去找哪種類型的客戶端發生了問題。經過這種逐層的下鑽，逐層去找，最終定位到版本因素形成了流量下跌。

這是咱們人工調查問題的一個方法，這一套流程走下來實際上是很是耗費時間的。咱們怎麼樣藉助算法幫助咱們作這種異常檢測呢？這就是關聯規則算法，你們都據說過啤酒和尿布這個故事：在一大堆物品當中，啤酒和尿布同時出現的頻率很是高，因此咱們認爲它兩個之間是有關聯關係的，而後進行關聯推薦。咱們能夠把這種關聯推薦給映射到根因分析算法。比方說我拿了一個訪問日誌，訪問日誌裏面有不少的錯誤信息，而後咱們再把網絡日誌拿過來。結果發如今網絡日誌裏面某個交換機常常會和這個錯誤日誌同時出現，是否是能夠認爲這個交換機上出現了錯誤？

如何找兩個關聯的項目，就是咱們經過頻繁集算法。咱們把一份錯誤的日誌拿出來，找這個日誌裏面它高頻出現的一些數據集合。比方說咱們在這樣一個錯誤日誌裏面定位到IP等於1002這樣一個用戶，他出現的頻率是68%，那麼是否是認爲這樣一個用戶他就是形成咱們錯誤的一個緣由？不必定。爲何？由於這個用戶可能在錯誤的日誌中出現的頻率比較高，可是在正確的日誌中出現的頻率也是很是高的，因此你不能簡單認爲他就是一個錯誤的緣由。那怎麼辦呢？要經過差別集合算法進行統計，咱們把一份完整的數據，按照是否有錯誤，分紅正負兩份樣本，而後比較兩個樣本里面的頻繁集有什麼差異，若是某一個集合它在一個錯誤的集合中出現的頻率比較高，而在正確的集合裏面出現的頻率比較低，就能夠認爲這個集合是形成錯誤的根本緣由。

若是咱們再引入到時序維度，針對咱們剛纔說的網站瀏覽量下跌的問題，咱們怎麼樣作這種根因分析呢？咱們首先面對一個彙總的流量下跌的曲線，而後能夠把咱們所關心的維度都引入進來，例如地區維度，運營商維度，客戶端維度所有引入進來，把各類維度自由組合各類各樣的集合，那麼咱們算出來每個集合它的一個流量曲線，計算算每個集合它下跌的一個趨勢，和總體流量下跌趨勢之間的關聯度，而且打分，按照分數的高低尋找根因集合。經過這種打分找出來一個集合，它對整個流量下跌的貢獻是最大的。比方說咱們最終統計出來上海這個地區全部的運營商流量下跌都很是的嚴重，打分很是高，那咱們認爲上海這個集合就是根因。

6：DevOps成本控制

對於咱們DevOps而言，咱們不只要關心咱們所作的成果，還要關心咱們的成本，由於拿堆資源作出來的成果不表明一我的的能力，用最少的資源作最大的事情才能夠表明一我的的能力。咱們一般作採購機器，而後等待機器到貨、上架，最終部署這個軟件，交付。這是一個原來傳統的上線機器的流程。這個流程是很長的，通常過幾個月才能拿到機器。如今有云服務，一鍵能夠建立機器，當你須要的時候能夠立馬拿到資源，這樣一個流程實在太方便了。可是就是方便背後其實也有一些其餘的困擾。比方說我一次測試的時候買了一臺機器，用完以後忘了釋放，結果這機器在那裏跑着一直產生費用，或者我在儲存裏面放了一大堆的數據，測試徹底以後忘記了刪除，過了好久，誰都不知道這個數據是幹嗎的，誰也不敢刪，誰都不知道這個數據刪掉之後會不會影響其餘的業務。可是這些資源一直產生的費用。直到財務人員發現你的消費比較高的時候，通常都會來踢你的屁股，說你部門成本怎麼這麼高？你要優化一下了。這個時候其實就已是很被動了，爲何？由於這個時候咱們去統計全部的資源，統計誰在用這些資源，這個流程是很是長的。咱們能夠經過主動的成本控制，去統計咱們的資源使用量，實時去統計資源使用量，實時去優化。

咱們看一個成本控制的樣例。咱們把實時的把帳單數據導入數據中臺，而後能夠統計出來，我這個月到底花費了多少錢，預測這個月大概花多少錢，以及每個雲產品花錢的數量。還能夠去看，過去三個月的趨勢是怎麼樣的，以及每個產品的趨勢。或者根據咱們過去的趨勢信息預測我將來三個月大概要花多少錢，利用這個數字及時的去申請預算。

同時咱們還能夠在咱們帳單數據裏面，根據統計信息看一下有沒有一些異常的帳單。比方說我在近三個月的消費曲線中，發現10月1號這一天帳單發生了暴漲。我要抓出來究竟是哪個雲產品產生了這麼多消費？因而深刻下鑽到日誌裏面去分析，用剛纔提到的根因分析的算法去找哪個產品對一個消費的上漲貢獻歸最大，因此咱們發現SLS這樣一個產品，它的異常打分是最高的。那麼咱們就認爲，這個產品出現的消費異常，及時的發出告警便可。

Summary

咱們作一個總結，咱們介紹了調查問題的一系列案例，經過這些樣例展現咱們如何藉助於數據中臺，幫助咱們作數據驅動，以及藉助AI作一些智能化、自動化的運維。經過這種數據驅動和智能、自動化的運維，總體提高咱們的效率，減小咱們被碎片化的時間。

阿里雲雙11領億元補貼，拼手氣抽iPhone 11 Pro、衛衣等好禮，點此參與：http://t.cn/Ai1hLLJT

---

本文做者：雲雷

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。