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
本文作者：雲雷
本文爲雲棲社區原創內容，未經允許不得轉載。