阿里巴巴千億交易背后，如何盡量避免發(fā)布故障？面對實際運維過程中遇到的問題該如何解決？近日，阿里巴巴運維技術專家少荃，給我們帶來了解決方案和思路。

近幾年，我們在發(fā)布效率和穩(wěn)定性方面做了不少工作，其中效率簡單的說就是發(fā)布耗時。

一個是發(fā)布的速度，比如一個應用是 1 個小時發(fā)布完成，還是 5 分鐘發(fā)布完成？

另一個是人員介入，開發(fā)在發(fā)布過程中是否需要介入處理各種發(fā)布過程中出現(xiàn)的問題？這兩者都做好了，才能說是發(fā)布效率提升了。

穩(wěn)定性最基礎的是系統(tǒng)的穩(wěn)定性，保障系統(tǒng)的可用，而最關鍵的是要保障通過系統(tǒng)來進行發(fā)布的應用的穩(wěn)定性，不會因為發(fā)布而導致服務不可用等故障出現(xiàn)。

效率這塊我們在集團內(nèi)比較受好評的產(chǎn)品是 SP2P 的文件分發(fā)系統(tǒng)，叫做蜻蜓。

根據(jù)阿里自身的一些特點，我們實現(xiàn)了一套安全高效的 P2P 分發(fā)，同時在 P2P 的協(xié)議上引入了超級節(jié)點，就是 S，提升了 P2P 網(wǎng)絡的啟動速度，目前已經(jīng)開源。

穩(wěn)定性這塊我們?nèi)ツ曜隽艘粋€產(chǎn)品，叫做無人值守發(fā)布，對發(fā)布進行檢測，看看發(fā)布是否會引起問題，來提升發(fā)布的可靠性，今天就和大家一起交流這方面的心得。

線上發(fā)布之痛

我們?yōu)槭裁匆诜€(wěn)定性方面投入大量精力呢？先看一個笑話。

變更故障

這個笑話可能沒那么好笑，但是它真真切切的說明了一個問題：理想和現(xiàn)實的差異，你以為是有四個單身狗陪你，但是實際卻是另外兩對情侶。

這個和我們做生產(chǎn)環(huán)境的發(fā)布是一樣的，我們以為憑借我們出色的邏輯思維能力，已經(jīng)把所有場景都想到了，測試也做的很充分了，但是，發(fā)布上線后，經(jīng)常會遇到實際結果和預期不一致，故障發(fā)生了。

我們針對阿里的故障產(chǎn)生原因做了統(tǒng)計，其中很大一部分都是線上變更引起的，相信在座各位也會遇到或者制造過故障，開發(fā)和運維的同學對故障都是很敬畏的。

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

業(yè)務挑戰(zhàn)：阿里的特殊業(yè)務場景

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

阿里現(xiàn)在的業(yè)務多樣化發(fā)展，新零售、線下支付等一些新的業(yè)務場景，要求我們對故障更加敏感，要能夠更好地避免故障，更快地發(fā)現(xiàn)和處理故障。

還有，如果是線下場景，比如用支付寶坐地鐵，如果出現(xiàn)幾分鐘的服務不可用，那會怎么樣？

如何才能有效的避免故障發(fā)生呢？

那么，如何才能在發(fā)布的時候有效的避免故障發(fā)生呢？

靠“蒙”？大家知道肯定不行。可是細想一下，很多時候確實或多或少在“蒙”。我個人是有過類似感受的。

我們雖然不會隨便到不經(jīng)過測試就進行線上發(fā)布，但是雖然已經(jīng)經(jīng)過了多輪測試，肯定還是沒有辦法覆蓋線上各種復雜多樣的場景的。

而這些沒有辦法覆蓋的場景，就只能靠運氣去"蒙"了，運氣好的，這些場景沒有問題；運氣不好，剛好就其中一個場景出問題，出現(xiàn)故障了。

通常來講，為了盡可能不要去“蒙”，我們會對上線流程加入各種驗證環(huán)節(jié)，來保證發(fā)布盡可能可靠。

例如發(fā)布前，我們會通過各種測試來驗證功能是否 ok，包括單元測試、集成測試等。

發(fā)布過程中，我們會通過一些發(fā)布策略，例如先預發(fā)(預發(fā)布是一種特殊的線上環(huán)境，和線上使用同樣的資源，比如數(shù)據(jù)庫等，但是不會有用戶流量進來)、然后灰度、然后分批滾動發(fā)布等方式，逐步將變更更新到線上。

發(fā)布完成后，又會借助一些故障預警系統(tǒng)，例如像阿里有 GOC 來盡早的發(fā)現(xiàn)故障，進行處理，這些環(huán)節(jié)的這些手段都已經(jīng)有成熟的系統(tǒng)來進行支持，但是發(fā)布的時候，我們常常還是心里沒有底。

"人工智能"的解決方案

還有什么辦法能夠幫助我們盡可能地保障發(fā)布質量呢？大家可能都已經(jīng)在做了：就是"人工"智能的發(fā)布保障。

在發(fā)布過程中，盯著各種屏幕，去看各種數(shù)據(jù)，來人肉的判斷本次發(fā)布有沒有問題。

在阿里，這些屏幕包括監(jiān)控、發(fā)布單、機器、GOC 故障預警等：

• 監(jiān)控，能夠反映出來當前系統(tǒng)的一些狀況，例如機器的負載是否上去了，接口的成功率是否下降了。
• 發(fā)布單，能讓我們了解當前的發(fā)布情況，有多少機器已經(jīng)更新到新版本了，有多少還在跑舊版本，有多少機器啟動又遇到異常了等等。
• 盯著機器，可以看一些日志信息，是否有一些新的異常出現(xiàn)了，異常的量是否很大等等。
• GOC，讓我們在故障發(fā)生的***時間就能結合自己發(fā)布的內(nèi)容判斷是否是本次發(fā)布引起，需要進行處理。

這種方式相比之前讓人放心多了，是因為現(xiàn)在我們看到的是最真實的線上環(huán)境的情況，而不是單單的測試數(shù)據(jù)。

但是這種人肉盯屏的方式也存在著很大的問題，首先是成本太高了，發(fā)布過程中需要有熟練工盯著各種屏幕去看，片刻不離。

其次是人的因素太大了，同樣的發(fā)布情況，不同的人分析出來的結果可能完全是不一樣的，即使是同一個人，因為狀態(tài)或者其他方面的原因，針對同樣的一些數(shù)據(jù)，可能分析出來的結果也不一樣。

另外，人也有局限性，各種數(shù)據(jù)刷新很快，肉眼分析的方式根本都來不及看。

既然這種盯屏的方式被證明是有效的，但是存在一些問題，那么我們就考慮通過系統(tǒng)化來解決這些問題，所以，就有了"無人值守發(fā)布"。

無人值守發(fā)布

無人值守發(fā)布主要是把上述過程自動化、智能化。通過自動化采集這些實時的線上核心數(shù)據(jù)，進行智能化分析，迅速對發(fā)布狀況進行判斷，是否有故障發(fā)生，有的話則立即終止當前發(fā)布。

無人值守發(fā)布的兩大核心能力，一個是故障檢測，一個是異常推薦。故障檢測主要是發(fā)現(xiàn)現(xiàn)在的問題。

異常推薦主要是防范于未然，是指發(fā)布出現(xiàn)了問題，但是不一定會引起故障。

這些異常給開發(fā)的同學透明出來，需要開發(fā)注意，比較常見的是出現(xiàn)了一些異常，這些異常從絕對數(shù)量或者漲幅來看沒有非常明顯，但可能是需要處理的。

什么是無人值守發(fā)布

首先是發(fā)布單詳情頁面中的無人值守信息展示，發(fā)布單詳情頁面是發(fā)布過程中最常會去看的頁面。

所以我們選擇把無人值守檢測出來的一些信息展示到這個頁面，在一個頁面中把可以做的事情都做掉。

當然，并不是說開發(fā)同學一定要自己去刷這個頁面才能夠知道當前發(fā)布是否有異常，當發(fā)布出現(xiàn)異常的情況下，系統(tǒng)會先自動暫停當前的發(fā)布。

然后通過釘釘?shù)纫恍┩ㄖ绞?，告知開發(fā)的同學，你的某個發(fā)布出現(xiàn)了異常，需要你去看下。

這些展示的信息包括了左側的當前發(fā)布是否有異常的概要信息，通過概要信息，可以知道當前發(fā)布有沒有問題。

如果有問題，可以看右側的問題分類，是基礎監(jiān)控指標出問題了，還是業(yè)務指標出問題了，或者是日志出問題了，日志出問題具體是哪個日志有問題了，在這里都可以看到。

如果這里的信息還不夠來判斷是否發(fā)布有問題，那么點擊查看詳情，可以看到更加詳細明確的異常信息，來進行判斷。

無人值守發(fā)布的時候需要應用接入到無人值守發(fā)布系統(tǒng)，當然大部分情況下這是一個自動化的過程，系統(tǒng)會判斷應用是否符合接入標準。

如果符合，會自動接入，但是也有一些情況會導致應用無法自動接入，這種情況下，也會告知用戶當前應用是否接入了，如果未接入，需要做一些配置或者改造來接入。

無人值守發(fā)布詳情

這個是無人值守發(fā)布信息展示的詳情頁面，在這個上面，可以看到更加明細的一些信息，比如異常數(shù)量的發(fā)布前后趨勢對比，業(yè)務監(jiān)控各個指標的變化情況等。

通過這個頁面，開發(fā)的同學基本上有足夠的信息來判斷本次攔截是否有效，是否需要進行回滾等操作。

無人值守接入

這個是應用接入無人值守發(fā)布的一個頁面，主要需要配置業(yè)務監(jiān)控指標、日志路徑等。

無人值守的實戰(zhàn)案例

這是一個典型的案例，其中一些數(shù)據(jù)做了隱藏或者處理。發(fā)布過程中日志中某個異常出現(xiàn)了大幅度增長，我們可以從左側看到異常的數(shù)量。

點擊異常信息還可以看到更加明確的異常堆棧信息，右側可以看到異常數(shù)量出現(xiàn)了明顯增加，下面可以看到這個檢測被用戶判斷為確實有問題，最終執(zhí)行了關閉發(fā)布單進行回滾的操作。

用戶反饋

這些是用戶的一些反饋。應用接入無人值守發(fā)布，對提升發(fā)布的穩(wěn)定性起了立竿見影的效果。

指標

上面這些案例都代表了一部分用戶的感受和反饋，那么整體效果怎么樣，還是要拿數(shù)據(jù)來說話。

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

召回率主要用來反映漏報的情況，準確率主要用來反饋誤報的情況。漏報和誤報的概念比較好理解。

漏報就是本來有 10 個故障，系統(tǒng)報了 9 個，那么漏報了 1 個，召回率是 90%，誤報就是只有 10 個故障，報了 20 個出來，多出來的 10 個就屬于誤報，那么準確率就是 50%。

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

召回率方面，我們已經(jīng)做到了 90%，這個 90% 是指出現(xiàn)了一次故障我們沒有報出來，我們有效攔截了 9 次，這 9 次中可能會引起故障，也可能只是有問題，但是不會造成故障，但是因為及時發(fā)現(xiàn)了，都沒有造成故障。

很難明確說這 9 次里面到底有多少是會造成故障的，所以計算召回率的時候沒有單獨計算故障的召回率，而是把故障和異常一起計算進去了。

關于先重點抓哪個指標，我們也經(jīng)歷過一些波折。一開始的目標是攔截盡可能多的故障，所以比較注重召回率，導致長期一段時間內(nèi)，準確率很低，攔是攔了不少，但是誤報相當多，報 10 次里面可能只有一次是有效的。

如果我們是用戶，可能幾次誤報以后，就對這個產(chǎn)品失去信心了，這個導致我們不敢大面積推廣。

后來調(diào)整策略，優(yōu)先解決準確率的問題，反正沒我們系統(tǒng)之前這些故障也是存在，有了系統(tǒng)，能減少一些就是好的。

所以先不追求召回率，把準確率做上去后，可以大面積進行推廣了，受益面大了，避免的故障也自然多了。當然，后面還是繼續(xù)抓了召回率的。

無人值守發(fā)布實現(xiàn)

前面說了不少，但是都沒有提到系統(tǒng)的具體實現(xiàn)，接下來我們看是怎么去實現(xiàn)無人值守發(fā)布的？

首先看下我們的產(chǎn)品分層和業(yè)務流程。

產(chǎn)品架構和業(yè)務流程

我們的系統(tǒng)大致分了三層：

• 最上面一層是發(fā)布系統(tǒng)層，我們的產(chǎn)品叫海狼，主要是發(fā)布單的提交、執(zhí)行以及無人值守信息的展示和反饋，這一層是可以擴展的，除了發(fā)布系統(tǒng)外，也可以對接其他的一些變更系統(tǒng)。
• 中間是無人值守的核心系統(tǒng)，根據(jù)收集到的分析任務，采集對應的數(shù)據(jù)，進行分析檢測。
• 最下面一層是離線分析層，主要用來做一些算法的訓練、回放驗證等，后面再具體介紹。

大致的業(yè)務過程是，用戶在發(fā)布系統(tǒng)中提交了一個發(fā)布計劃，這個時候會通過 Normandy(諾曼底)這個平臺進行發(fā)布(海狼是諾曼底平臺的一部分，負責發(fā)布的執(zhí)行)。

海狼開始執(zhí)行發(fā)布單后，無人值守系統(tǒng)就會收到發(fā)布單執(zhí)行的事件，然后開始分析，分析的時候會利用離線算出來的一些特征集，然后和當前的指標進行比較檢測。

如果有異常，那么會通過海狼的接口進行暫停發(fā)布單的操作，用戶可以在發(fā)布單頁面看到對應信息，然后進行一些判斷后提交反饋，是有效攔截，還是誤報等。

兩個階段

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

1.0 實現(xiàn)

通過前面的介紹，應該大致了解，無人值守發(fā)布就是分析發(fā)布過程中各種指標數(shù)據(jù)，來判斷發(fā)布是否有異常，那么具體有哪些指標數(shù)據(jù)可以用來分析呢？

大致總結了下，有以下幾類：

• 業(yè)務指標，這個最直接反映當前發(fā)布有沒有問題，如果影響到了業(yè)務，那么基本上就是有問題的。

如果業(yè)務指標能夠覆蓋所有的故障場景，那么理論上只要分析業(yè)務指標就行了，但是現(xiàn)實往往是很多業(yè)務指標的完善都跟不上業(yè)務發(fā)展的，業(yè)務上去了，指標還沒上，這是很現(xiàn)實的事情。

• 基礎指標，例如機器的內(nèi)存使用情況，cpu 使用率，load 情況，磁盤 io 等，這些指標一般在發(fā)布過程中不太會發(fā)生明顯的變化，但是一旦發(fā)生了明顯變化，就可能有問題了。
• 中間件指標，阿里內(nèi)部廣泛使用的 hsf、tair、metaq 等，都有相應的 qps、rt、成功率等指標，如果發(fā)布后成功率突然跌的比較明顯或者 qps 跌 0 等，那么也很有可能是有問題了。
• 日志，阿里比較多的應用是 Java 的，我們會在日志中把一些異常的堆棧信息都打印出來，這些異常信息反映了代碼運行過程中的一個不正常狀態(tài)，所以是一個很寶貴的指標數(shù)據(jù)。

通過分析這些異常的出現(xiàn)情況、漲幅情況、或者是否出現(xiàn)了一些常見的容易引起故障的異常，例如 ClassNotFound 等，我們可以做出足夠有用的判斷。

指標和算法選取

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

***個版本的時候，我們選擇了基礎監(jiān)控和日志這兩方面入手。原因比較簡單，基礎監(jiān)控的覆蓋率夠高，有足夠多的數(shù)據(jù)可以讓我們分析，而日志根據(jù)經(jīng)驗則非常重要。

至于業(yè)務監(jiān)控和中間件指標，由于數(shù)據(jù)方面等一些問題，***個版本我們沒有去考慮。

那怎么對基礎監(jiān)控和日志的指標進行分析呢？我們采用的是使用一些簡單的規(guī)則加上復雜的算法共用的方式。

針對一些情況，例如出現(xiàn)了前面提到的危險異常等，采用規(guī)則的方式，直接進行攔截；針對異常的漲幅變化等，則采用算法來評判這個漲幅是否在合理范圍內(nèi)。

如何實現(xiàn)？確定好了指標和分析思路，我們再看看需要做哪些事情。

首先要做的是數(shù)據(jù)采集，我們面臨的問題是需要采集哪些數(shù)據(jù)，怎么盡快地采集這些數(shù)據(jù)。

其次是對數(shù)據(jù)進行處理，原始的數(shù)據(jù)中會有一些干擾的數(shù)據(jù)，干擾的來源可能是多方面的，可能是數(shù)據(jù)采集系統(tǒng)本身的問題，也可能是與業(yè)務自身的特點有關，需要把這些干擾的數(shù)據(jù)能夠剔除掉。

然后就是針對采集和處理后的這些數(shù)據(jù)，制定什么樣的規(guī)則，使用什么樣的算法，來對它們進行分析，盡可能準確的判斷出發(fā)布后的數(shù)據(jù)是否有問題。

數(shù)據(jù)如何采集？采集之前，先明確檢測的大致思路：發(fā)布前和發(fā)布后的指標進行對比，已發(fā)布和未發(fā)布的機器進行對比。

所以，我們要采集的是時間序列的數(shù)據(jù)，也就是每個時間點某個指標是什么樣的一個數(shù)據(jù)，例如某個時間點，系統(tǒng)的 load 是多少，某個時間點，某類異常出現(xiàn)了多少次等。

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

而從哪些機器上采集指標呢？前面提到，我們檢測思路中有一條是已發(fā)布和未發(fā)布的機器進行對比。

所以我們?yōu)槊總€應用設置了兩組機器，一個是發(fā)布組，一個是參照組，只采集這兩組機器的數(shù)據(jù)，而不是所有機器的數(shù)據(jù)都采集。

至于采集時間，也不用采集所有數(shù)據(jù)，只要采集發(fā)布前后一段時間內(nèi)的數(shù)據(jù)就可以。

采集到數(shù)據(jù)以后，接下來就需要對數(shù)據(jù)進行一些處理，除了前面提到的一些干擾數(shù)據(jù)剔除外，我們還需要進行一些維度的聚合。

因為拿到的是一些單機數(shù)據(jù)，所以需要針對已發(fā)布未發(fā)布等一些維度進行數(shù)據(jù)聚合合并，最終生成了可以分析的數(shù)據(jù)。

數(shù)據(jù)分析方法

數(shù)據(jù)分析的方法，我們采用的是改進型的 funnel 檢測模型，它有這些優(yōu)點：

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

通過上述這些工作，我們大致就把一個檢測系統(tǒng)建立 run 起來了，這***個版本在準確率方面表現(xiàn)不是很好，離線跑的時候能夠有 30%、40%。

但是線上實際跑的時候只有 10% 上下的準確率，所以我們需要去提升準確率，那怎么提升呢？

答案是不斷的分析誤報和漏報數(shù)據(jù)，然后對算法做一些微調(diào)。不停的微調(diào)算法又帶來了一個新的問題。

針對這些誤報的數(shù)據(jù)，可能新的算法不會報出來了，但是之前的那些沒報的數(shù)據(jù)呢，用新的算法會不會又報出來了？之前那些報出來的有效攔截，會不會新的算法中就不報出來了？

于是我們又搭建了之前產(chǎn)品架構中提到的離線回放系統(tǒng)，用來對算法進行回放驗證，從之前的誤報、有效攔截、未攔截等數(shù)據(jù)中抽取部分數(shù)據(jù)。

每次算法調(diào)整后，通過回放系統(tǒng)對這些數(shù)據(jù)重新進行檢測分析，看看準確率和召回率是怎么變化的，誤報的是否還在誤報，有效攔截的是否漏報了等等。

無人值守回放系統(tǒng)

整個無人值守回放系統(tǒng)大致過程如下：

• 錄制模塊會將線上檢測過的發(fā)布單的相關數(shù)據(jù)錄制到回放 db。
• 需要回放的時候，通過回放觸發(fā)接口，觸發(fā)無人值守進行檢測，檢測時候會調(diào)用回放系統(tǒng)提供的指標 mock 接口，從回放 db 獲取數(shù)據(jù)，而不是從實際的數(shù)據(jù)源獲取數(shù)據(jù)。
• 將回放檢測的結果進行保存，產(chǎn)出回放結果報表。

算法的困境

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

首先是需要不斷的去分析檢測數(shù)據(jù)，然后調(diào)整算法，這個過程是相當耗費精力的，并且不一定能夠有相應的回報。

還有很重要的一點是，在實踐過程中，我們發(fā)現(xiàn)一些明顯的誤報信息在重復的誤報。

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

機器學習的大概過程

首先會有一個離線學習的過程，通過一些歷史的發(fā)布單的指標數(shù)據(jù)和攔截數(shù)據(jù)，以及用戶反饋的一些數(shù)據(jù)，計算出來應用發(fā)布時候的一個特征庫。

發(fā)布的時候，會首先采用一些算法來檢測出可疑指標，然后對可疑指標和特征庫進行比較。

如果發(fā)現(xiàn)這個可疑指標落在正常的特征庫里，那么忽略掉，否則，就認為發(fā)布出現(xiàn)了異常，要進行攔截。

攔截完成后，會根據(jù)發(fā)布單最終的結果和用戶的反饋行為將這次攔截是否有效等數(shù)據(jù)保存起來，作為下次離線計算的一個輸入數(shù)據(jù)。

三大要素

機器學習也面臨幾個問題需要去解決，首先是去學習什么樣的數(shù)據(jù)，其次是要通過什么樣的方法去學習產(chǎn)出什么樣的結果，還有一個就是怎么樣把這個學習的結果用到后面的發(fā)布檢測中去。

樣本

我們首先看下樣本問題，就是學什么數(shù)據(jù)。我們有的數(shù)據(jù)大致有這些：發(fā)布單數(shù)據(jù)、發(fā)布過程中的指標數(shù)據(jù)、攔截是否有效的數(shù)據(jù)、用戶反饋的一些數(shù)據(jù)。

這些數(shù)據(jù)看起來很多，每天的發(fā)布單有好幾萬，每個發(fā)布單又有大量的指標數(shù)據(jù)，但是實際上，每個應用的特征都是不一樣的。

所以學習的時候一定是基于應用的維度去學習的，而每個應用的發(fā)布數(shù)據(jù)就很少了，如何從這不多的數(shù)據(jù)去計算應用的發(fā)布特征呢？

計算的思路有兩個：

• 算異常的，這是比較自然的想法，找出異常的特征，下次如果匹配了異常特征，那么就可以判斷發(fā)布有問題。
• 算正常的，而應用維度異常的發(fā)布往往遠少于正常發(fā)布，甚至可能都從來沒有過異常發(fā)布。

所以基于異常的維度去計算，也不大靠譜，相對比較靠譜點的，只能是通過正常的發(fā)布單數(shù)據(jù)去計算出應用發(fā)布的正常發(fā)布特征。

樣本中的一個挑戰(zhàn)是如何來判斷一個發(fā)布真正是有問題的，我們采取的是發(fā)布單行為和用戶反饋相結合的方式，如果發(fā)布單被回滾了，那么就認為是異常的，如果用戶反饋說有異常，那么也認為是異常的。

關鍵和不靠譜是用來描述用戶反饋數(shù)據(jù)的兩個特點的，關鍵是指用戶反饋數(shù)據(jù)非常重要，是最能夠幫助我們?nèi)チ私鈶玫母鱾€指標對異常檢測是否有幫助的。

但是用戶反饋數(shù)據(jù)又具有主觀性，發(fā)布過程中出現(xiàn)了某個異常，A 開發(fā)同學可能會反饋認為沒有問題，而 B 同學比較謹慎可能就會反饋認為確實是有問題，如何去平衡這兩個特點也是比較棘手的。

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

這個反饋數(shù)據(jù)的采集看似很容易，但是據(jù)我所知，在不少公司里，采集這個數(shù)據(jù)阻力都是比較大的。

開發(fā)同學不愿意去填寫反饋這些信息，比較幸運的是，我們通過一系列方式優(yōu)化，盡可能地減少這個反饋對開發(fā)的干擾，把這個反饋給強制開啟來了，采集到的數(shù)據(jù)對我們的幫助確實相當大。

算法

樣本數(shù)據(jù)有了，接下來就要根據(jù)樣本數(shù)據(jù)計算出應用的發(fā)布特征了，我們采用的是簡單的分類方法，最初的想法是分成正常、異常、未分類三大類。

正常比較好理解，異常是指每次出現(xiàn)都會導致故障的，未分類則是一些新增的或者之前出現(xiàn)過沒有變化的一些指標，后面考慮到上面說的異常樣本非常小的問題，就把這三類統(tǒng)一成一類了。

就是只計算應用發(fā)布時候各個指標的一個正常閾值，如果下次發(fā)布的時候，指標的值超過了這個閾值，那么可能就是有問題。

具體學習的過程比較簡單，總結起來一句話就是：找到正常發(fā)布單中指標的***值，作為應用的正常指標閾值。

具體過程是：首先是發(fā)布過程中如果出現(xiàn)了異常指標，那么會去看這次發(fā)布最終是否是有問題的發(fā)布(通過發(fā)布單的行為是否回滾以及用戶的反饋等)。

如果是正常發(fā)布，那么和之前的正常閾值進行比較，如果比之前的正常閾值要小，那么忽略，如果比之前的閾值大，那么就更新正常閾值。

而如果這次發(fā)布是異常發(fā)布，那么理論上應該去判斷這次的指標是否比正常閾值小，如果小，那么要更新正常閾值，但是實際上，這次發(fā)布的問題可能并不一定是這個指標引起的。

而且如果確實是這個指標引起的話，那么之前指標比這個值更大的發(fā)布應該也是異常的，考慮到這兩點，我們現(xiàn)階段采取的是忽略異常發(fā)布單的方式，只針對正常的發(fā)布單進行閾值計算。

指標使用

正常閾值的使用也比較簡單。發(fā)布過程中，如果發(fā)現(xiàn)了異常指標，那么會找到該指標對應的正常閾值做比較，如果小于正常閾值，那么忽略掉；如果超過了正常閾值，那么作為可疑指標。

在一個窗口期內(nèi)進行多輪檢測，窗口期會根據(jù)檢測的結果做一些動態(tài)調(diào)整，如果在窗口期內(nèi)多次被判定為可疑指標，并且達到了一定比例，那么最終會被判定為異常指標，對發(fā)布進行攔截。

整個機器學習的改進過程大致就是這樣，通過這個改進，我們一方面解決了之前遇到的一些問題，提升了召回率和準確率，尤其是準確率方面有了顯著提升。

另外一方面，也釋放了大量精力出來，可以更好的優(yōu)化這個學習的算法。

作者：陸葉平（花名少荃）

簡介：阿里巴巴研發(fā)效能事業(yè)部技術專家。目前從事運維中臺(阿里內(nèi)部叫諾曼底)建設方面的工作，是集團內(nèi)***的應用發(fā)布系統(tǒng)(海狼)負責人。