DevOps是什么？

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

DevOps的挑戰

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

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

怎么解決研發過程中時間碎片化的問題？我們原來做了很多重復性的工作，這些工作可以總結和沉淀下來，通過工具幫我們去沉淀。我們原來需要調查問題的時候，才登錄集群要抓日志；現在做一個采集日志的工具，把所有日志的實時采集到云端，當需要看日志的時候，我立馬就可以在服務端看到所有的日志信息。原來需要到機器上搜索日志，現在在云端做倒排索引，直接就可以搜索到整個集群的日志。原來我可能要用excel做一些數據分析的工作，去分析我的運營效果怎么樣。現在在服務端實現一套實時分析的計算引擎，再加上可視化功能，幫助做各種各樣的報表。原來調查問題的時候要登錄集群上，用vim打開集群上的日志，看文件上下文是什么樣子的?，F在在云端做一個上下文關聯的功能，直接在云端就可以看到所有集群上的日志和上下文信息。原來調查問題可能依賴于人的經驗。現在通過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

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的AI赋能DevOps：数据驱动的全栈工程师实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。