摘要：?阿里巴巴千億交易背后，如何盡量避免發(fā)布故障？在面對(duì)實(shí)際運(yùn)維過程中遇到的問題該如何解決？近日，在剛剛結(jié)束的 GOPS·深圳站大會(huì)上，阿里巴巴運(yùn)維技術(shù)專家少荃，給我們帶來了解決方案和思路。

前言

近幾年，我們?cè)诎l(fā)布效率和穩(wěn)定性方面做了不少工作，其中效率簡單的說就是發(fā)布耗時(shí)，一個(gè)是發(fā)布的速度，比如一個(gè)應(yīng)用是1個(gè)小時(shí)發(fā)布完成，還是5分鐘發(fā)布完成？另一個(gè)是人員介入，開發(fā)在發(fā)布過程中是否需要介入處理各種發(fā)布過程中出現(xiàn)的問題？這兩者都做好了，才能說是發(fā)布效率提升了。穩(wěn)定性最基礎(chǔ)的是系統(tǒng)的穩(wěn)定性，保障系統(tǒng)的可用，而最關(guān)鍵的是要保障通過系統(tǒng)來進(jìn)行發(fā)布的應(yīng)用的穩(wěn)定性，不會(huì)因?yàn)榘l(fā)布而導(dǎo)致服務(wù)不可用等故障出現(xiàn)。

效率這塊我們?cè)诩瘓F(tuán)內(nèi)比較受好評(píng)的產(chǎn)品是SP2P的文件分發(fā)系統(tǒng)，叫做蜻蜓，我們根據(jù)阿里自身的一些特點(diǎn)，實(shí)現(xiàn)了一套安全高效的P2P分發(fā)，同時(shí)在P2P的協(xié)議上引入了超級(jí)節(jié)點(diǎn)，就是S，提升了P2P網(wǎng)絡(luò)的啟動(dòng)速度，目前已經(jīng)開源。穩(wěn)定性這塊我們?nèi)ツ曜隽艘粋€(gè)產(chǎn)品，叫做無人值守發(fā)布，對(duì)發(fā)布進(jìn)行檢測，看看發(fā)布是否會(huì)引起問題，來提升發(fā)布的可靠性，今天就和大家一起交流下這方面的心得。

線上發(fā)布之痛

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

變更故障

這個(gè)笑話可能沒那么好笑，但是它真真切切的說明了一個(gè)問題：理想和現(xiàn)實(shí)的差異，你以為是有四個(gè)單身狗陪你，但是實(shí)際卻是另外兩對(duì)情侶。這個(gè)和我們做生產(chǎn)環(huán)境的發(fā)布是一樣的，我們以為憑借我們出色的邏輯思維能力，已經(jīng)把所有場景都想到了，測試也做的很充分了，但是，發(fā)布上線后，經(jīng)常會(huì)遇到實(shí)際結(jié)果和預(yù)期不一致，故障發(fā)生了。我們針對(duì)阿里的故障產(chǎn)生原因做了統(tǒng)計(jì)，其中很大一部分都是線上變更引起的，相信在座各位也會(huì)遇到或者制造過故障，開發(fā)和運(yùn)維的同學(xué)對(duì)故障都是很敬畏的。

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

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

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

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

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

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

靠“蒙”？大家知道肯定不行。可是細(xì)想一下，很多時(shí)候確實(shí)或多或少在“蒙”。我個(gè)人是有過類似感受的。我們雖然不會(huì)隨便到不經(jīng)過測試就進(jìn)行線上發(fā)布，但是雖然已經(jīng)經(jīng)過了多輪測試，肯定還是沒有辦法覆蓋線上各種復(fù)雜多樣的場景的，而這些沒有辦法覆蓋的場景，就只能靠運(yùn)氣去"蒙"了，運(yùn)氣好的，這些場景沒有問題，運(yùn)氣不好，剛好就其中一個(gè)場景出問題，出現(xiàn)故障了。

通常來講，為了盡可能不要去“蒙”，我們會(huì)對(duì)上線流程加入各種驗(yàn)證環(huán)節(jié)，來保證發(fā)布盡可能可靠。例如發(fā)布前，我們會(huì)通過各種測試來驗(yàn)證功能是否ok，包括單元測試、集成測試等，發(fā)布過程中，我們會(huì)通過一些發(fā)布策略，例如先預(yù)發(fā)(預(yù)發(fā)布是一種特殊的線上環(huán)境，和線上使用同樣的資源，比如數(shù)據(jù)庫等，但是不會(huì)有用戶流量進(jìn)來)、然后灰度、然后分批滾動(dòng)發(fā)布等方式，逐步將變更更新到線上，發(fā)布完成后，又會(huì)借助一些故障預(yù)警系統(tǒng)，例如像阿里有GOC來盡早的發(fā)現(xiàn)故障，進(jìn)行處理，這些環(huán)節(jié)的這些手段都已經(jīng)有成熟的系統(tǒng)來進(jìn)行支持，但是發(fā)布的時(shí)候，我們常常還是心里沒有底。

"人工智能"的解決方案

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

在發(fā)布過程中，盯著各種屏幕，去看各種數(shù)據(jù)，來人肉的判斷本次發(fā)布有沒有問題。在阿里，這些屏幕包括：監(jiān)控、發(fā)布單、機(jī)器、GOC故障預(yù)警等。監(jiān)控能夠反映出來當(dāng)前系統(tǒng)的一些狀況，例如機(jī)器的負(fù)載是否上去了，接口的成功率是否下降了，發(fā)布單則能讓我們了解當(dāng)前的發(fā)布情況，有多少機(jī)器已經(jīng)更新到新版本了，有多少還在跑舊版本，有多少機(jī)器啟動(dòng)又遇到異常了等等，盯著機(jī)器則可以看一些日志信息，是否有一些新的異常出現(xiàn)了，異常的量是否很大等等，GOC讓我們?cè)诠收习l(fā)生的第一時(shí)間就能知道，結(jié)合自己發(fā)布的內(nèi)容判斷是否是本次發(fā)布引起，需要進(jìn)行處理。

這種方式相比之前讓人放心多了，是因?yàn)楝F(xiàn)在我們看到的是最真實(shí)的線上環(huán)境的情況，而不是單單的測試數(shù)據(jù)。但是這種人肉盯屏的方式也存在著很大的問題，首先是成本太高了，發(fā)布過程中需要有熟練工盯著各種屏幕去看，片刻不離，其次是人的因素太大了，同樣的發(fā)布情況，不同的人分析出來的結(jié)果可能完全是不一樣的，即使是同一個(gè)人，因?yàn)闋顟B(tài)或者其他方面的原因，針對(duì)同樣的一些數(shù)據(jù)，可能分析出來的結(jié)果也不一樣，另外，人也有局限性，各種數(shù)據(jù)刷新很快，肉眼分析的方式根本都來不及看。

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

無人值守發(fā)布

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

無人值守發(fā)布的兩大核心能力，一個(gè)是故障檢測，一個(gè)是異常推薦。故障檢測主要是發(fā)現(xiàn)現(xiàn)在的問題。異常推薦主要是防范于未然，是指發(fā)布出現(xiàn)了問題，但是不一定會(huì)引起故障，這些異常給開發(fā)的同學(xué)透明出來，需要開發(fā)注意，比較常見的是出現(xiàn)了一些異常，這些異常從絕對(duì)數(shù)量或者漲幅來看沒有非常明顯，但可能是需要處理的。

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

首先是發(fā)布單詳情頁面中的無人值守信息展示，發(fā)布單詳情頁面是發(fā)布過程中最常會(huì)去看的頁面，所以我們選擇把無人值守檢測出來的一些信息展示到這個(gè)頁面，在一個(gè)頁面中把可以做的事情都做掉。當(dāng)然，并不是說開發(fā)同學(xué)一定要自己去刷這個(gè)頁面才能夠知道當(dāng)前發(fā)布是否有異常，當(dāng)發(fā)布出現(xiàn)異常的情況下，系統(tǒng)會(huì)先自動(dòng)暫停當(dāng)前的發(fā)布，然后通過釘釘?shù)纫恍┩ㄖ绞?#xff0c;告知開發(fā)的同學(xué)，你的某個(gè)發(fā)布出現(xiàn)了異常，需要你去看下。

這些展示的信息包括了左側(cè)的當(dāng)前發(fā)布是否有異常的概要信息，通過概要信息，可以知道當(dāng)前發(fā)布有沒有問題，如果有問題，可以看右側(cè)的問題分類，是基礎(chǔ)監(jiān)控指標(biāo)出問題了，還是業(yè)務(wù)指標(biāo)出問題了，或者是日志出問題了，日志出問題具體是哪個(gè)日志有問題了，在這里都可以看到。

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

無人值守發(fā)布的時(shí)候需要應(yīng)用接入到無人值守發(fā)布系統(tǒng)，當(dāng)然大部分情況下這是一個(gè)自動(dòng)化的過程，系統(tǒng)會(huì)判斷應(yīng)用是否符合接入標(biāo)準(zhǔn)，如果符合，會(huì)自動(dòng)接入，但是也有一些情況會(huì)導(dǎo)致應(yīng)用無法自動(dòng)接入，這種情況下，也會(huì)告知用戶當(dāng)前應(yīng)用是否接入了，如果未接入，需要做一些配置或者改造來接入。

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

這個(gè)是無人值守發(fā)布信息展示的詳情頁面，在這個(gè)上面，可以看到更加明細(xì)的一些信息，比如異常數(shù)量的發(fā)布前后趨勢對(duì)比，業(yè)務(wù)監(jiān)控各個(gè)指標(biāo)的變化情況等。通過這個(gè)頁面，開發(fā)的同學(xué)基本上有足夠的信息來判斷本次攔截是否有效，是否需要進(jìn)行回滾等操作。

無人值守接入

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

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

這是一個(gè)典型的案例，其中一些數(shù)據(jù)做了隱藏或者處理。發(fā)布過程中日志中某個(gè)異常出現(xiàn)了大幅度增長，我們可以從左側(cè)看到異常的數(shù)量，點(diǎn)擊異常信息還可以看到更加明確的異常堆棧信息，右側(cè)可以看到異常數(shù)量出現(xiàn)了明顯增加，下面可以看到這個(gè)檢測被用戶判斷為確實(shí)有問題，最終執(zhí)行了關(guān)閉發(fā)布單進(jìn)行回滾的操作。

用戶反饋

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

指標(biāo)

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

業(yè)界對(duì)于異常檢測這塊有兩個(gè)主要的指標(biāo)：一個(gè)是召回率，一個(gè)是準(zhǔn)確率。

召回率主要用來反映漏報(bào)的情況，準(zhǔn)確率主要用來反饋誤報(bào)的情況。漏報(bào)和誤報(bào)的概念比較好理解。漏報(bào)就是本來有10個(gè)故障，系統(tǒng)報(bào)了9個(gè)，那么漏報(bào)了1個(gè)，召回率是90%，誤報(bào)就是只有10個(gè)故障，報(bào)了20個(gè)出來，多出來的10個(gè)就屬于誤報(bào)，那么準(zhǔn)確率就是50%。

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

召回率方面，我們已經(jīng)做到了90%，這個(gè)90%是指出現(xiàn)了一次故障我們沒有報(bào)出來，我們有效攔截了9次，這9次中可能會(huì)引起故障，也可能只是有問題，但是不會(huì)造成故障，但是因?yàn)榧皶r(shí)發(fā)現(xiàn)了，都沒有造成故障，很難明確說這9次里面到底有多少是會(huì)造成故障的，所以計(jì)算召回率的時(shí)候沒有單獨(dú)計(jì)算故障的召回率，而是把故障和異常一起計(jì)算進(jìn)去了。

關(guān)于先重點(diǎn)抓哪個(gè)指標(biāo)，我們也經(jīng)歷過一些波折。一開始的目標(biāo)是攔截盡可能多的故障，所以比較注重召回率，導(dǎo)致長期一段時(shí)間內(nèi)，準(zhǔn)確率很低，攔是攔了不少，但是誤報(bào)相當(dāng)多，報(bào)10次里面可能只有一次是有效的，如果我們是用戶，可能幾次誤報(bào)以后，就對(duì)這個(gè)產(chǎn)品失去信心了，這個(gè)導(dǎo)致我們不敢大面積推廣。后來調(diào)整策略，優(yōu)先解決準(zhǔn)確率的問題，反正沒我們系統(tǒng)之前這些故障也是存在，有了系統(tǒng)，能減少一些就是好的，所以先不追求召回率，把準(zhǔn)確率做上去后，可以大面積進(jìn)行推廣了，受益面大了，避免的故障也自然多了。當(dāng)然，后面還是繼續(xù)抓了召回率的。

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

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

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

產(chǎn)品架構(gòu)和業(yè)務(wù)流程

我們的系統(tǒng)大致分了三層，最上面一層是發(fā)布系統(tǒng)層，我們的產(chǎn)品叫海狼，主要是發(fā)布單的提交、執(zhí)行以及無人值守信息的展示和反饋，這一層是可以擴(kuò)展的，除了發(fā)布系統(tǒng)外，也可以對(duì)接其他的一些變更系統(tǒng)。

中間是無人值守的核心系統(tǒng)，根據(jù)收集到的分析任務(wù)，采集對(duì)應(yīng)的數(shù)據(jù)，進(jìn)行分析檢測。

最下面一層是離線分析層，主要用來做一些算法的訓(xùn)練、回放驗(yàn)證等，后面再具體介紹。

大致的業(yè)務(wù)過程是，用戶在發(fā)布系統(tǒng)中提交了一個(gè)發(fā)布計(jì)劃，這個(gè)時(shí)候會(huì)通過Normandy(諾曼底)這個(gè)平臺(tái)進(jìn)行發(fā)布(海狼是諾曼底平臺(tái)的一部分，負(fù)責(zé)發(fā)布的執(zhí)行)，海狼開始執(zhí)行發(fā)布單后，無人值守系統(tǒng)就會(huì)收到發(fā)布單執(zhí)行的事件，然后開始分析，分析的時(shí)候會(huì)利用離線算出來的一些特征集，然后和當(dāng)前的指標(biāo)進(jìn)行比較檢測，如果有異常，那么會(huì)通過海狼的接口進(jìn)行暫停發(fā)布單的操作，用戶可以在發(fā)布單頁面看到對(duì)應(yīng)信息，然后進(jìn)行一些判斷后提交反饋，是有效攔截，還是誤報(bào)等。

兩個(gè)階段

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

1.0實(shí)現(xiàn)

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

首先是業(yè)務(wù)指標(biāo)，這個(gè)最直接反應(yīng)當(dāng)前發(fā)布有沒有問題，如果影響到了業(yè)務(wù)，那么基本上就是有問題的。如果業(yè)務(wù)指標(biāo)能夠覆蓋所有的故障場景，那么理論上只要分析業(yè)務(wù)指標(biāo)就行了，但是現(xiàn)實(shí)往往是很多業(yè)務(wù)指標(biāo)的完善都跟不上業(yè)務(wù)發(fā)展的，業(yè)務(wù)上去了，指標(biāo)還沒上，這是很現(xiàn)實(shí)的事情。

其次是一些基礎(chǔ)指標(biāo)，例如機(jī)器的內(nèi)存使用情況，cpu使用率，load情況，磁盤io等，這些指標(biāo)一般在發(fā)布過程中不太會(huì)發(fā)生明顯的變化，但是一旦發(fā)生了明顯變化，就可能有問題了。

還有些中間件的指標(biāo)，阿里內(nèi)部廣泛使用的hsf、tair、metaq等，都有相應(yīng)的qps、rt、成功率等指標(biāo)，如果發(fā)布后成功率突然跌的比較明顯或者qps跌0等，那么也很有可能是有問題了。

還有一個(gè)比較關(guān)鍵的是日志，阿里比較多的應(yīng)用是java的，我們會(huì)在日志中把一些異常的堆棧信息都打印出來，這些異常信息反映了代碼運(yùn)行過程中的一個(gè)不正常狀態(tài)，所以是一個(gè)很寶貴的指標(biāo)數(shù)據(jù)。通過分析這些異常的出現(xiàn)情況、漲幅情況、或者是否出現(xiàn)了一些常見的容易引起故障的異常，例如ClassNotFound等，我們可以做出足夠有用的判斷。

指標(biāo)和算法選取

指標(biāo)這么多，我們一開始應(yīng)該從哪入手呢？

第一個(gè)版本的時(shí)候，我們選擇了基礎(chǔ)監(jiān)控和日志這兩方面入手。原因比較簡單，基礎(chǔ)監(jiān)控的覆蓋率夠高，有足夠多的數(shù)據(jù)可以讓我們分析，而日志根據(jù)經(jīng)驗(yàn)則非常重要。至于業(yè)務(wù)監(jiān)控和中間件指標(biāo)，由于數(shù)據(jù)方面等一些問題，第一個(gè)版本我們沒有去考慮。

那怎么對(duì)基礎(chǔ)監(jiān)控和日志的指標(biāo)進(jìn)行分析呢？我們采用的是使用一些簡單的規(guī)則加上復(fù)雜的算法共用的方式，針對(duì)一些情況，例如出現(xiàn)了前面提到的危險(xiǎn)異常等，采用規(guī)則的方式，直接進(jìn)行攔截，針對(duì)異常的漲幅變化等，則采用算法來評(píng)判這個(gè)漲幅是否在合理范圍內(nèi)。

如何實(shí)現(xiàn)

確定好了指標(biāo)和分析思路，我們?cè)倏纯葱枰瞿男┦虑椤Ｊ紫纫龅氖菙?shù)據(jù)采集，我們面臨的問題是需要采集哪些數(shù)據(jù)，怎么盡快地采集這些數(shù)據(jù)。其次是對(duì)數(shù)據(jù)進(jìn)行處理，原始的數(shù)據(jù)中會(huì)有一些干擾的數(shù)據(jù)，干擾的來源可能是多方面的，可能是數(shù)據(jù)采集系統(tǒng)本身的問題，也可能是與業(yè)務(wù)自身的特點(diǎn)有關(guān)，需要把這些干擾的數(shù)據(jù)能夠剔除掉。然后就是針對(duì)采集和處理后的這些數(shù)據(jù)，制定什么樣的規(guī)則，使用什么樣的算法，來對(duì)它們進(jìn)行分析，盡可能準(zhǔn)確的判斷出發(fā)布后的數(shù)據(jù)是否有問題。

數(shù)據(jù)如何采集

首先我們來看看數(shù)據(jù)怎么采集？

采集之前，先明確檢測的大致思路：發(fā)布前和發(fā)布后的指標(biāo)進(jìn)行對(duì)比，已發(fā)布和未發(fā)布的機(jī)器進(jìn)行對(duì)比。所以，我們要采集的是時(shí)間序列的數(shù)據(jù)，也就是每個(gè)時(shí)間點(diǎn)某個(gè)指標(biāo)是什么樣的一個(gè)數(shù)據(jù)，例如某個(gè)時(shí)間點(diǎn)，系統(tǒng)的load是多少，某個(gè)時(shí)間點(diǎn)，某類異常出現(xiàn)了多少次等。

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

而從哪些機(jī)器上采集指標(biāo)呢？前面提到，我們檢測思路中有一條是已發(fā)布和未發(fā)布的機(jī)器進(jìn)行對(duì)比，所以我們?yōu)槊總€(gè)應(yīng)用設(shè)置了兩組機(jī)器，一個(gè)是發(fā)布組，一個(gè)是參照組，只采集這兩組機(jī)器的數(shù)據(jù)，而不是所有機(jī)器的數(shù)據(jù)都采集。至于采集時(shí)間，也不用采集所有數(shù)據(jù)，只要采集發(fā)布前后一段時(shí)間內(nèi)的數(shù)據(jù)就可以。

采集到數(shù)據(jù)以后，接下來就需要對(duì)數(shù)據(jù)進(jìn)行一些處理，除了前面提到的一些干擾數(shù)據(jù)剔除外，我們還需要進(jìn)行一些維度的聚合，因?yàn)槟玫降氖且恍﹩螜C(jī)數(shù)據(jù)，所以需要針對(duì)已發(fā)布未發(fā)布等一些維度進(jìn)行數(shù)據(jù)聚合合并，最終生成了可以分析的數(shù)據(jù)。

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

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

可以滿足針對(duì)不同的指標(biāo)，采用不同的算法的需求，不同的指標(biāo)有各自的特點(diǎn)，使用同一個(gè)算法顯然不大合適；其次它的計(jì)算需要的資源少，同時(shí)檢測的速度又夠快，還支持很多指標(biāo)一起分析。

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

答案是不斷的分析誤報(bào)和漏報(bào)數(shù)據(jù)，然后對(duì)算法做一些微調(diào)。不停的微調(diào)算法又帶來了一個(gè)新的問題，針對(duì)這些誤報(bào)的數(shù)據(jù)，可能新的算法不會(huì)報(bào)出來了，但是之前的那些沒報(bào)的數(shù)據(jù)呢，用新的算法會(huì)不會(huì)又報(bào)出來了？之前那些報(bào)出來的有效攔截，會(huì)不會(huì)新的算法中就不報(bào)出來了？

于是我們又搭建了之前產(chǎn)品架構(gòu)中提到的離線回放系統(tǒng)，用來對(duì)算法進(jìn)行回放驗(yàn)證，從之前的誤報(bào)、有效攔截、未攔截等數(shù)據(jù)中抽取部分?jǐn)?shù)據(jù)，每次算法調(diào)整后，通過回放系統(tǒng)對(duì)這些數(shù)據(jù)重新進(jìn)行檢測分析，看看準(zhǔn)確率和召回率是怎么變化的，誤報(bào)的是否還在誤報(bào)，有效攔截的是否漏報(bào)了等等。

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

整個(gè)無人值守回放系統(tǒng)大致過程如下：錄制模塊會(huì)將線上檢測過的發(fā)布單的相關(guān)數(shù)據(jù)錄制到回放db，然后需要回放的時(shí)候，通過回放觸發(fā)接口，觸發(fā)無人值守進(jìn)行檢測，檢測時(shí)候會(huì)調(diào)用回放系統(tǒng)提供的指標(biāo)mock接口，從回放db獲取數(shù)據(jù)，而不是從實(shí)際的數(shù)據(jù)源獲取數(shù)據(jù)，將回放檢測的結(jié)果進(jìn)行保存，產(chǎn)出回放結(jié)果報(bào)表。

算法的困境

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

首先是需要不斷的去分析檢測數(shù)據(jù)，然后調(diào)整算法，這個(gè)過程是相當(dāng)耗費(fèi)精力的，并且不一定能夠有相應(yīng)的回報(bào)。還有很重要的一點(diǎn)是，在實(shí)踐過程中，我們發(fā)現(xiàn)一些明顯的誤報(bào)信息在重復(fù)的誤報(bào)。

所以我們需要去探索一個(gè)能夠解決這些問題的方案。于是，第二個(gè)版本，我們就采用了基于機(jī)器學(xué)習(xí)的方式在原來的基礎(chǔ)上做了一些改進(jìn)。

機(jī)器學(xué)習(xí)的大概過程

首先會(huì)有一個(gè)離線學(xué)習(xí)的過程，通過一些歷史的發(fā)布單的指標(biāo)數(shù)據(jù)和攔截?cái)?shù)據(jù)，以及用戶反饋的一些數(shù)據(jù)，計(jì)算出來應(yīng)用發(fā)布時(shí)候的一個(gè)特征庫，發(fā)布的時(shí)候，會(huì)首先采用一些算法來檢測出可疑指標(biāo)，然后對(duì)可疑指標(biāo)和特征庫進(jìn)行比較，如果發(fā)現(xiàn)這個(gè)可疑指標(biāo)落在正常的特征庫里，那么忽略掉，否則，就認(rèn)為發(fā)布出現(xiàn)了異常進(jìn)行攔截，攔截完成后，會(huì)根據(jù)發(fā)布單最終的結(jié)果和用戶的反饋行為將這次攔截是否有效等數(shù)據(jù)保存起來，作為下次離線計(jì)算的一個(gè)輸入數(shù)據(jù)。

三大要素

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

樣本

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

這些數(shù)據(jù)看起來很多，每天的發(fā)布單有好幾萬，每個(gè)發(fā)布單又有大量的指標(biāo)數(shù)據(jù)，但是實(shí)際上，每個(gè)應(yīng)用的特征都是不一樣的，所以學(xué)習(xí)的時(shí)候一定是基于應(yīng)用的維度去學(xué)習(xí)的，而每個(gè)應(yīng)用的發(fā)布數(shù)據(jù)就很少了，如何從這不多的數(shù)據(jù)去計(jì)算應(yīng)用的發(fā)布特征呢？

計(jì)算的思路也有兩個(gè)，一個(gè)是算異常的，比較自然的想法，找出異常的特征，下次如果匹配了異常特征，那么就可以判斷發(fā)布有問題，一個(gè)是算正常的，而應(yīng)用維度異常的發(fā)布往往遠(yuǎn)少于正常發(fā)布，甚至可能都從來沒有過異常發(fā)布，所以基于異常的維度去計(jì)算，也不大靠譜，相對(duì)比較靠譜點(diǎn)的，只能是通過正常的發(fā)布單數(shù)據(jù)去計(jì)算出應(yīng)用發(fā)布的正常發(fā)布特征。

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

關(guān)鍵和不靠譜是用來描述用戶反饋數(shù)據(jù)的兩個(gè)特點(diǎn)的，關(guān)鍵是指用戶反饋數(shù)據(jù)非常重要，是最能夠幫助我們?nèi)チ私鈶?yīng)用的各個(gè)指標(biāo)對(duì)異常檢測是否有幫助的，但是用戶反饋數(shù)據(jù)又具有主觀性，發(fā)布過程中出現(xiàn)了某個(gè)異常，A開發(fā)同學(xué)可能會(huì)反饋認(rèn)為沒有問題，而B同學(xué)比較謹(jǐn)慎可能就會(huì)反饋認(rèn)為確實(shí)是有問題，如何去平衡這兩個(gè)特點(diǎn)也是比較棘手的。

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

這個(gè)反饋數(shù)據(jù)的采集看似很容易，但是據(jù)我所知，在不少公司里，采集這個(gè)數(shù)據(jù)阻力都是比較大的，開發(fā)同學(xué)不愿意去填寫反饋這些信息，比較幸運(yùn)的是，我們通過一系列方式優(yōu)化，盡可能地減少這個(gè)反饋對(duì)開發(fā)的干擾，把這個(gè)反饋給強(qiáng)制開啟來了，采集到的數(shù)據(jù)對(duì)我們的幫助確實(shí)相當(dāng)大。

算法

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

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

指標(biāo)使用

正常閾值的使用也比較簡單。發(fā)布過程中，如果發(fā)現(xiàn)了異常指標(biāo)，那么會(huì)找到該指標(biāo)對(duì)應(yīng)的正常閾值做比較，如果小于正常閾值，那么忽略掉，如果超過了正常閾值，那么作為可疑指標(biāo)，在一個(gè)窗口期內(nèi)進(jìn)行多輪檢測，窗口期會(huì)根據(jù)檢測的結(jié)果做一些動(dòng)態(tài)調(diào)整，如果在窗口期內(nèi)多次被判定為可疑指標(biāo)，并且達(dá)到了一定比例，那么最終會(huì)被判定為異常指標(biāo)，對(duì)發(fā)布進(jìn)行攔截。

整個(gè)機(jī)器學(xué)習(xí)的改進(jìn)過程大致就是這樣，通過這個(gè)改進(jìn)，我們一方面解決了之前遇到的一些問題，提升了召回率和準(zhǔn)確率，尤其是準(zhǔn)確率方面有了顯著提升。另外一方面，也釋放了大量精力出來，可以更好的優(yōu)化這個(gè)學(xué)習(xí)的算法。

GOPS 2018 深圳站精彩PPT（持續(xù)更新中）

鏈接: https://pan.baidu.com/s/1zgOGm7CabpO6lIquNVcNkg?

密碼: sp76

另一位阿里技術(shù)專家即將出現(xiàn)在 6月的北京

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

DOIS 大會(huì)為您呈現(xiàn)互聯(lián)網(wǎng)公司與海外企業(yè)的實(shí)踐經(jīng)驗(yàn)與工具技術(shù)，聚焦 DevOps 在金融、通信、零售等行業(yè)的系統(tǒng)性實(shí)踐，不空談！不務(wù)虛！專注 DevOps 落地！

原文發(fā)布時(shí)間為：2018-04-20本文作者：陸葉平（少荃）

原文鏈接

干貨好文，請(qǐng)關(guān)注掃描以下二維碼：

總結(jié)

以上是生活随笔為你收集整理的阿里：千亿交易背后的0故障发布的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。