摘要：導讀阿里巴巴千億交易背后，如何盡量避免發布故障在面對實際運維過程中遇到的問題該如何解決近日，在大會上，阿里巴巴運維技術專家少荃，給我們帶來了解決方案和思路。在阿里，這些屏幕包括監控發布單機器故障預警等。

導讀：阿里巴巴千億交易背后，如何盡量避免發布故障？在面對實際運維過程中遇到的問題該如何解決？近日，在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同學比較謹慎可能就會反饋認為確實是有問題，如何去平衡這兩個特點也是比較棘手的。

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

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

算法

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

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

指標使用

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

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

詳情請閱讀原文