阿里：千億交易背後的0故障釋出

導讀：阿里巴巴千億交易背後，如何儘量避免釋出故障？在面對實際運維過程中遇到的問題該如何解決？近日，在剛剛結束的 GOPS·深圳站大會上，阿里巴巴運維技術專家少荃，給我們帶來了解決方案和思路。

作者：陸葉平（花名少荃），阿里巴巴研發效能事業部技術專家。目前從事運維中臺(阿里內部叫諾曼底)建設方面的工作，是集團內最大的應用釋出系統(海狼)負責人。

前言

近幾年，我們在釋出效率和穩定性方面做了不少工作，其中效率簡單的說就是釋出耗時，一個是釋出的速度，比如一個應用是1個小時釋出完成，還是5分鐘釋出完成？另一個是人員介入，開發在釋出過程中是否需要介入處理各種釋出過程中出現的問題？這兩者都做好了，才能說是釋出效率提升了。穩定性最基礎的是系統的穩定性，保障系統的可用，而最關鍵的是要保障通過系統來進行釋出的應用的穩定性，不會因為釋出而導致服務不可用等故障出現。

 

效率這塊我們在集團內比較受好評的產品是SP2P的檔案分發系統，叫做蜻蜓，我們根據阿里自身的一些特點，實現了一套安全高效的P2P分發，同時在P2P的協議上引入了超級節點，就是S，提升了P2P網路的啟動速度，目前已經開源。穩定性這塊我們去年做了一個產品，叫做無人值守釋出，對釋出進行檢測，看看釋出是否會引起問題，來提升釋出的可靠性，今天就和大家一起交流下這方面的心得。

線上釋出之痛

我們為什麼要在穩定性方面投入大量精力呢？先讓我們來看一個笑話。

變更故障

這個笑話可能沒那麼好笑，但是它真真切切的說明了一個問題：理想和現實的差異，你以為是有四個單身狗陪你，但是實際卻是另外兩對情侶。這個和我們做生產環境的釋出是一樣的，我們以為憑藉我們出色的邏輯思維能力，已經把所有場景都想到了，測試也做的很充分了，但是，釋出上線後，經常會遇到實際結果和預期不一致，故障發生了。我們針對阿里的故障產生原因做了統計，其中很大一部分都是線上變更引起的，相信在座各位也會遇到或者製造過故障，開發和運維的同學對故障都是很敬畏的。

故障大家都遇到過，但是故障的影響差異會比較大。有些故障可能是故障發現後處理了一會就恢復了，有些故障則可能會導致嚴重的後果。所以我們需要儘量避免變更帶來的故障。

業務挑戰：阿里的特殊業務場景

回到阿里，我們都知道，去年雙11的成交額已經達到了1682億，想象下，這麼大的交易額下，如果出現了故障，那會怎麼樣？

阿里現在的業務多樣化發展，新零售、線下支付等一些新的業務場景，要求我們對故障更加敏感，要能夠更好地避免故障，更快地發現和處理故障。想一下，如果是線下場景，比如用支付寶坐地鐵，如果出現幾分鐘的服務不可用，那會怎麼樣？

如何才能有效的避免故障發生呢？

那麼，如何才能在釋出的時候有效的避免故障發生呢？

靠“蒙”？大家知道肯定不行。可是細想一下，很多時候確實或多或少在“蒙”。我個人是有過類似感受的。我們雖然不會隨便到不經過測試就進行線上釋出，但是雖然已經經過了多輪測試，肯定還是沒有辦法覆蓋線上各種複雜多樣的場景的，而這些沒有辦法覆蓋的場景，就只能靠運氣去"蒙"了，運氣好的，這些場景沒有問題，運氣不好，剛好就其中一個場景出問題，出現故障了。

通常來講，為了儘可能不要去“蒙”，我們會對上線流程加入各種驗證環節，來保證釋出儘可能可靠。例如釋出前，我們會通過各種測試來驗證功能是否ok，包括單元測試、整合測試等，釋出過程中，我們會通過一些釋出策略，例如先預發(預釋出是一種特殊的線上環境，和線上使用同樣的資源，比如資料庫等，但是不會有使用者流量進來)、然後灰度、然後分批滾動釋出等方式，逐步將變更更新到線上，釋出完成後，又會藉助一些故障預警系統，例如像阿里有GOC來儘早的發現故障，進行處理，這些環節的這些手段都已經有成熟的系統來進行支援，但是釋出的時候，我們常常還是心裡沒有底。

"人工智慧"的解決方案

那麼，還有什麼辦法能夠幫助我們儘可能地保障釋出質量呢？大家可能都已經在做了：就是"人工"智慧的釋出保障。

在釋出過程中，盯著各種螢幕，去看各種資料，來人肉的判斷本次釋出有沒有問題。在阿里，這些螢幕包括：監控、釋出單、機器、GOC故障預警等。監控能夠反映出來當前系統的一些狀況，例如機器的負載是否上去了，介面的成功率是否下降了，釋出單則能讓我們瞭解當前的釋出情況，有多少機器已經更新到新版本了，有多少還在跑舊版本，有多少機器啟動又遇到異常了等等，盯著機器則可以看一些日誌資訊，是否有一些新的異常出現了，異常的量是否很大等等，GOC讓我們在故障發生的第一時間就能知道，結合自己釋出的內容判斷是否是本次釋出引起，需要進行處理。

這種方式相比之前讓人放心多了，是因為現在我們看到的是最真實的線上環境的情況，而不是單單的測試資料。但是這種人肉盯屏的方式也存在著很大的問題，首先是成本太高了，釋出過程中需要有熟練工盯著各種螢幕去看，片刻不離，其次是人的因素太大了，同樣的釋出情況，不同的人分析出來的結果可能完全是不一樣的，即使是同一個人，因為狀態或者其他方面的原因，針對同樣的一些資料，可能分析出來的結果也不一樣，另外，人也有侷限性，各種資料重新整理很快，肉眼分析的方式根本都來不及看。

既然這種盯屏的方式被證明是有效的，但是存在一些問題，那麼我們就考慮通過系統化來解決這些問題，所以，就有了"無人值守釋出"。

無人值守釋出

無人值守釋出主要是把上述過程自動化、智慧化。通過自動化採集這些實時的線上核心資料，進行智慧化分析，迅速對釋出狀況進行判斷，是否有故障發生，有的話則立即終止當前釋出。

無人值守釋出的兩大核心能力，一個是故障檢測，一個是異常推薦。故障檢測主要是發現現在的問題。異常推薦主要是防範於未然，是指釋出出現了問題，但是不一定會引起故障，這些異常給開發的同學透明出來，需要開發注意，比較常見的是出現了一些異常，這些異常從絕對數量或者漲幅來看沒有非常明顯，但可能是需要處理的。

 

什麼是無人值守釋出

首先是釋出單詳情頁面中的無人值守資訊展示，釋出單詳情頁面是釋出過程中最常會去看的頁面，所以我們選擇把無人值守檢測出來的一些資訊展示到這個頁面，在一個頁面中把可以做的事情都做掉。當然，並不是說開發同學一定要自己去刷這個頁面才能夠知道當前釋出是否有異常，當釋出出現異常的情況下，系統會先自動暫停當前的釋出，然後通過釘釘等一些通知方式，告知開發的同學，你的某個釋出出現了異常，需要你去看下。

 

這些展示的資訊包括了左側的當前釋出是否有異常的概要資訊，通過概要資訊，可以知道當前釋出有沒有問題，如果有問題，可以看右側的問題分類，是基礎監控指標出問題了，還是業務指標出問題了，或者是日誌出問題了，日誌出問題具體是哪個日誌有問題了，在這裡都可以看到。

 

如果這裡的資訊還不夠來判斷是否釋出有問題，那麼點選檢視詳情，可以看到更加詳細明確的異常資訊，來進行判斷。

 

無人值守釋出的時候需要應用接入到無人值守釋出系統，當然大部分情況下這是一個自動化的過程，系統會判斷應用是否符合接入標準，如果符合，會自動接入，但是也有一些情況會導致應用無法自動接入，這種情況下，也會告知使用者當前應用是否接入了，如果未接入，需要做一些配置或者改造來接入。

 

無人值守釋出詳情

這個是無人值守釋出資訊展示的詳情頁面，在這個上面，可以看到更加明細的一些資訊，比如異常數量的釋出前後趨勢對比，業務監控各個指標的變化情況等。通過這個頁面，開發的同學基本上有足夠的資訊來判斷本次攔截是否有效，是否需要進行回滾等操作。

 

無人值守接入

這個是應用接入無人值守釋出的一個頁面，主要需要配置業務監控指標、日誌路徑等。

無人值守的實戰案例

這是一個典型的案例，其中一些資料做了隱藏或者處理。釋出過程中日誌中某個異常出現了大幅度增長，我們可以從左側看到異常的數量，點選異常資訊還可以看到更加明確的異常堆疊資訊，右側可以看到異常數量出現了明顯增加，下面可以看到這個檢測被使用者判斷為確實有問題，最終執行了關閉釋出單進行回滾的操作。

使用者反饋

這些是使用者的一些反饋。應用接入無人值守釋出，對提升釋出的穩定性起了立竿見影的效果。

指標

 

上面這些案例都代表了一部分使用者的感受和反饋，那麼整體效果怎麼樣，還是要拿資料來說話。

業界對於異常檢測這塊有兩個主要的指標：一個是召回率，一個是準確率。

召回率主要用來反映漏報的情況，準確率主要用來反饋誤報的情況。漏報和誤報的概念比較好理解。漏報就是本來有10個故障，系統報了9個，那麼漏報了1個，召回率是90%，誤報就是隻有10個故障，報了20個出來，多出來的10個就屬於誤報，那麼準確率就是50%。

目前準確率方面，我們已經做到了60%左右，也就是說差不多每報2次，就有一次確實是有問題的，這種體驗應該算還不錯。

召回率方面，我們已經做到了90%，這個90%是指出現了一次故障我們沒有報出來，我們有效攔截了9次，這9次中可能會引起故障，也可能只是有問題，但是不會造成故障，但是因為及時發現了，都沒有造成故障，很難明確說這9次裡面到底有多少是會造成故障的，所以計算召回率的時候沒有單獨計算故障的召回率，而是把故障和異常一起計算進去了。

關於先重點抓哪個指標，我們也經歷過一些波折。一開始的目標是攔截儘可能多的故障，所以比較注重召回率，導致長期一段時間內，準確率很低，攔是攔了不少，但是誤報相當多，報10次裡面可能只有一次是有效的，如果我們是使用者，可能幾次誤報以後，就對這個產品失去信心了，這個導致我們不敢大面積推廣。後來調整策略，優先解決準確率的問題，反正沒我們系統之前這些故障也是存在，有了系統，能減少一些就是好的，所以先不追求召回率，把準確率做上去後，可以大面積進行推廣了，受益面大了，避免的故障也自然多了。當然，後面還是繼續抓了召回率的。

無人值守釋出實現

前面說了不少，但是都沒有提到系統的具體實現，接下來我們看是怎麼去實現無人值守釋出的？

首先看下我們的產品分層和業務流程。

產品架構和業務流程

我們的系統大致分了三層，最上面一層是釋出系統層，我們的產品叫海狼，主要是釋出單的提交、執行以及無人值守資訊的展示和反饋，這一層是可以擴充套件的，除了釋出系統外，也可以對接其他的一些變更系統。

中間是無人值守的核心繫統，根據收集到的分析任務，採集對應的資料，進行分析檢測。

最下面一層是離線分析層，主要用來做一些演算法的訓練、回放驗證等，後面再具體介紹。

大致的業務過程是，使用者在釋出系統中提交了一個釋出計劃，這個時候會通過Normandy(諾曼底)這個平臺進行釋出(海狼是諾曼底平臺的一部分，負責釋出的執行)，海狼開始執行釋出單後，無人值守系統就會收到釋出單執行的事件，然後開始分析，分析的時候會利用離線算出來的一些特徵集，然後和當前的指標進行比較檢測，如果有異常，那麼會通過海狼的介面進行暫停釋出單的操作，使用者可以在釋出單頁面看到對應資訊，然後進行一些判斷後提交反饋，是有效攔截，還是誤報等。

兩個階段

上述是一個大致的過程，具體實現方面，我們經過了兩個大的版本迭代，下面針對兩個版本分別介紹下。

1.0實現

通過前面的介紹，應該大致瞭解，無人值守釋出就是分析釋出過程中各種指標資料，來判斷髮布是否有異常，那麼具體有哪些指標資料可以用來分析呢？大致總結了下，有以下幾類：

首先是業務指標，這個最直接反應當前釋出有沒有問題，如果影響到了業務，那麼基本上就是有問題的。如果業務指標能夠覆蓋所有的故障場景，那麼理論上只要分析業務指標就行了，但是現實往往是很多業務指標的完善都跟不上業務發展的，業務上去了，指標還沒上，這是很現實的事情。

其次是一些基礎指標，例如機器的記憶體使用情況，cpu使用率，load情況，磁碟io等，這些指標一般在釋出過程中不太會發生明顯的變化，但是一旦發生了明顯變化，就可能有問題了。

還有些中介軟體的指標，阿里內部廣泛使用的hsf、tair、metaq等，都有相應的qps、rt、成功率等指標，如果釋出後成功率突然跌的比較明顯或者qps跌0等，那麼也很有可能是有問題了。

還有一個比較關鍵的是日誌，阿里比較多的應用是java的，我們會在日誌中把一些異常的堆疊資訊都列印出來，這些異常資訊反映了程式碼執行過程中的一個不正常狀態，所以是一個很寶貴的指標資料。通過分析這些異常的出現情況、漲幅情況、或者是否出現了一些常見的容易引起故障的異常，例如ClassNotFound等，我們可以做出足夠有用的判斷。

指標和演算法選取

指標這麼多，我們一開始應該從哪入手呢？

第一個版本的時候，我們選擇了基礎監控和日誌這兩方面入手。原因比較簡單，基礎監控的覆蓋率夠高，有足夠多的資料可以讓我們分析，而日誌根據經驗則非常重要。至於業務監控和中介軟體指標，由於資料方面等一些問題，第一個版本我們沒有去考慮。

那怎麼對基礎監控和日誌的指標進行分析呢？我們採用的是使用一些簡單的規則加上覆雜的演算法共用的方式，針對一些情況，例如出現了前面提到的危險異常等，採用規則的方式，直接進行攔截，針對異常的漲幅變化等，則採用演算法來評判這個漲幅是否在合理範圍內。

如何實現

確定好了指標和分析思路，我們再看看需要做哪些事情。首先要做的是資料採集，我們面臨的問題是需要採集哪些資料，怎麼儘快地採集這些資料。其次是對資料進行處理，原始的資料中會有一些干擾的資料，干擾的來源可能是多方面的，可能是資料採集系統本身的問題，也可能是與業務自身的特點有關，需要把這些干擾的資料能夠剔除掉。然後就是針對採集和處理後的這些資料，制定什麼樣的規則，使用什麼樣的演算法，來對它們進行分析，儘可能準確的判斷出釋出後的資料是否有問題。

資料如何採集

首先我們來看看資料怎麼採集？

採集之前，先明確檢測的大致思路：釋出前和釋出後的指標進行對比，已釋出和未釋出的機器進行對比。所以，我們要採集的是時間序列的資料，也就是每個時間點某個指標是什麼樣的一個資料，例如某個時間點，系統的load是多少，某個時間點，某類異常出現了多少次等。

具體要採集哪些指標，上面已經明確了，只要把這些指標再做一個分析，把最重要最能反映故障情況的一些指標挑選出來，採集過來就行。

而從哪些機器上採集指標呢？前面提到，我們檢測思路中有一條是已釋出和未釋出的機器進行對比，所以我們為每個應用設定了兩組機器，一個是釋出組，一個是參照組，只採集這兩組機器的資料，而不是所有機器的資料都採集。至於採集時間，也不用採集所有資料，只要採集釋出前後一段時間內的資料就可以。

採集到資料以後，接下來就需要對資料進行一些處理，除了前面提到的一些干擾資料剔除外，我們還需要進行一些維度的聚合，因為拿到的是一些單機資料，所以需要針對已釋出未釋出等一些維度進行資料聚合合併，最終生成了可以分析的資料。

資料分析方法

資料分析的方法，我們採用的是改進型的funnel檢測模型，它有這些優點：

可以滿足針對不同的指標，採用不同的演算法的需求，不同的指標有各自的特點，使用同一個演算法顯然不大合適；其次它的計算需要的資源少，同時檢測的速度又夠快，還支援很多指標一起分析。

通過上述這些工作，我們大致就把一個檢測系統建立run起來了，這第一個版本在準確率方面表現不是很好，離線跑的時候能夠有30%、40%，但是線上實際跑的時候只有10%上下的準確率，所以我們需要去提升準確率，那怎麼提升呢？

答案是不斷的分析誤報和漏報資料，然後對演算法做一些微調。不停的微調演算法又帶來了一個新的問題，針對這些誤報的資料，可能新的演算法不會報出來了，但是之前的那些沒報的資料呢，用新的演算法會不會又報出來了？之前那些報出來的有效攔截，會不會新的演算法中就不報出來了？

於是我們又搭建了之前產品架構中提到的離線回放系統，用來對演算法進行回放驗證，從之前的誤報、有效攔截、未攔截等資料中抽取部分資料，每次演算法調整後，通過回放系統對這些資料重新進行檢測分析，看看準確率和召回率是怎麼變化的，誤報的是否還在誤報，有效攔截的是否漏報了等等。

無人值守回放系統

整個無人值守回放系統大致過程如下：錄製模組會將線上檢測過的釋出單的相關資料錄製到回放db，然後需要回放的時候，通過回放觸發介面，觸發無人值守進行檢測，檢測時候會呼叫回放系統提供的指標mock介面，從回放db獲取資料，而不是從實際的資料來源獲取資料，將回放檢測的結果進行儲存，產出回放結果報表。

演算法的困境

通過無人值守回放系統，我們建立了可靠的演算法驗證機制，通過不斷的微調演算法來提升召回率和準確率。但是，還是遇到了一些問題。

首先是需要不斷的去分析檢測資料，然後調整演算法，這個過程是相當耗費精力的，並且不一定能夠有相應的回報。還有很重要的一點是，在實踐過程中，我們發現一些明顯的誤報資訊在重複的誤報。

所以我們需要去探索一個能夠解決這些問題的方案。於是，第二個版本，我們就採用了基於機器學習的方式在原來的基礎上做了一些改進。

機器學習的大概過程

首先會有一個離線學習的過程，通過一些歷史的釋出單的指標資料和攔截資料，以及使用者反饋的一些資料，計算出來應用釋出時候的一個特徵庫，釋出的時候，會首先採用一些演算法來檢測出可疑指標，然後對可疑指標和特徵庫進行比較，如果發現這個可疑指標落在正常的特徵庫裡，那麼忽略掉，否則，就認為釋出出現了異常進行攔截，攔截完成後，會根據釋出單最終的結果和使用者的反饋行為將這次攔截是否有效等資料儲存起來，作為下次離線計算的一個輸入資料。

三大要素

機器學習也面臨幾個問題需要去解決，首先是去學習什麼樣的資料，其次是要通過什麼樣的方法去學習產出什麼樣的結果，還有一個就是怎麼樣把這個學習的結果用到後面的釋出檢測中去。

樣本

我們首先看下樣本問題，就是學什麼資料。我們有的資料大致有這些：釋出單資料、釋出過程中的指標資料、攔截是否有效的資料、使用者反饋的一些資料。

這些資料看起來很多，每天的釋出單有好幾萬，每個釋出單又有大量的指標資料，但是實際上，每個應用的特徵都是不一樣的，所以學習的時候一定是基於應用的維度去學習的，而每個應用的釋出資料就很少了，如何從這不多的資料去計算應用的釋出特徵呢？

計算的思路也有兩個，一個是算異常的，比較自然的想法，找出異常的特徵，下次如果匹配了異常特徵，那麼就可以判斷髮布有問題，一個是算正常的，而應用維度異常的釋出往往遠少於正常釋出，甚至可能都從來沒有過異常釋出，所以基於異常的維度去計算，也不大靠譜，相對比較靠譜點的，只能是通過正常的釋出單資料去計算出應用釋出的正常釋出特徵。

樣本中的一個挑戰是如何來判斷一個釋出真正是有問題的，我們採取的是釋出單行為和使用者反饋相結合的方式，如果釋出單被回滾了，那麼就認為是異常的，如果使用者反饋說有異常，那麼也認為是異常的。

關鍵和不靠譜是用來描述使用者反饋資料的兩個特點的，關鍵是指使用者反饋資料非常重要，是最能夠幫助我們去了解應用的各個指標對異常檢測是否有幫助的，但是使用者反饋資料又具有主觀性，釋出過程中出現了某個異常，A開發同學可能會反饋認為沒有問題，而B同學比較謹慎可能就會反饋認為確實是有問題，如何去平衡這兩個特點也是比較棘手的。

這個就是剛才提到的使用者反饋資料，通過這個反饋資料，我們可以明確的知道某個指標雖然異常了，但是對這個應用來說，可能是完全沒有用的，根本不需要作為檢測的依據，那麼下次檢測的時候就可以忽略掉該指標。

這個反饋資料的採集看似很容易，但是據我所知，在不少公司裡，採集這個資料阻力都是比較大的，開發同學不願意去填寫反饋這些資訊，比較幸運的是，我們通過一系列方式優化，儘可能地減少這個反饋對開發的干擾，把這個反饋給強制開啟來了，採集到的資料對我們的幫助確實相當大。

演算法

樣本資料有了，接下來就要根據樣本資料計算出應用的釋出特徵了，我們採用的是簡單的分類的方法，最初的想法是分成正常、異常、未分類三大類，正常比較好理解，異常是指每次出現都會導致故障的，未分類則是一些新增的或者之前出現過沒有變化的一些指標，後面考慮到上面說的異常樣本非常小的問題，就把這三類統一成一類了，就是隻計算應用釋出時候各個指標的一個正常閾值，如果下次釋出的時候，指標的值超過了這個閾值，那麼可能就是有問題。

具體學習的過程比較簡單，總結起來一句話就是：找到正常釋出單中指標的最大值，作為應用的正常指標閾值。具體過程是：首先是釋出過程中如果出現了異常指標，那麼會去看這次釋出最終是否是有問題的釋出(通過釋出單的行為是否回滾以及使用者的反饋等)，如果是正常釋出，那麼和之前的正常閾值進行比較，如果比之前的正常閾值要小，那麼忽略，如果比之前的閾值大，那麼就更新正常閾值，而如果這次釋出是異常釋出，那麼理論上應該去判斷這次的指標是否比正常閾值小，如果小，那麼要更新正常閾值，但是實際上，這次釋出的問題可能並不一定是這個指標引起的，而且如果確實是這個指標引起的話，那麼之前指標比這個值更大的釋出應該也是異常的，考慮到這兩點，我們現階段採取的是忽略異常釋出單的方式，只針對正常的釋出單進行閾值計算。

指標使用

正常閾值的使用也比較簡單。釋出過程中，如果發現了異常指標，那麼會找到該指標對應的正常閾值做比較，如果小於正常閾值，那麼忽略掉，如果超過了正常閾值，那麼作為可疑指標，在一個視窗期內進行多輪檢測，視窗期會根據檢測的結果做一些動態調整，如果在視窗期內多次被判定為可疑指標，並且達到了一定比例，那麼最終會被判定為異常指標，對釋出進行攔截。

整個機器學習的改進過程大致就是這樣，通過這個改進，我們一方面解決了之前遇到的一些問題，提升了召回率和準確率，尤其是準確率方面有了顯著提升。另外一方面，也釋放了大量精力出來，可以更好的優化這個學習的演算法。

GOPS 2018 深圳站精彩PPT（持續更新中）
連結: https://pan.baidu.com/s/1zgOGm7CabpO6lIquNVcNkg 
密碼: sp76

另一位阿里技術專家即將出現在 6月的北京

6.29-30 DevOps 國際峰會將在北京與您見面

DOIS 大會為您呈現網際網路公司與海外企業的實踐經驗與工具技術，聚焦 DevOps 在金融、通訊、零售等行業的系統性實踐，不空談！不務虛！專注 DevOps 落地！

掃描二維碼進入大會官網

DevOps 國際峰會（DevOps International Summit，縮寫：DOIS）是國內唯一的國際性 DevOps 技術峰會，由 OSCAR 聯盟指導、DevOps 時代社群與高效運維社群聯合主辦，共邀全球80餘名頂級專家暢談 DevOps 體系與方法、過程與實踐、工具與技術。

點選閱讀原文，參與報名⬇️