干貨概覽

作為一個合格的碼農，我們每時每刻都在為開發新功能、修復Bug、提升系統性能揮灑汗水。變更發布是產品迭代的必經之路，但是變化總伴隨著風險，互聯網公司轟動一時發生的大故障，往往跟變更有關。一半以上的故障是由變更引入的，毫無疑問，減少變更引入的故障能夠顯著提升服務的穩定性。

減少變更引入故障的基本方法是規范開發流程、提升開發質量、加強QA測試環節，從而避免將有問題的版本發布到線上，防患于未然。但是，由于線上環境與測試環境往往存在差異，一些變更在測試環境中工作正常，但是在線上環境會暴露出故障。這些變更成為了薛定諤的貓，只有在上線后才能揭曉是否存在故障。

因此，在發布過程中對服務健康情況進行跟蹤檢查、及早發現變更引入的故障成為發布過程不可或缺的環節，這樣才能避免系統卷入重大故障的血案中。本文將介紹百度是如何對變更發布進行分級、檢查來控制變更故障影響范圍的。

分級發布，讓故障影響范圍可控

在百度，我們采用分級發布機制來發布變更到線上環境。分級發布將變更發布過程拆分成多個階段，每個階段只將變更應用到部分機器上，并在相鄰的兩個階段之間對服務的健康情況進行檢查。如果發現服務的健康度顯著下降，則可以中止甚至回滾變更。在這個過程當中，大部分故障都能夠在最后一個階段之前被發現，因此故障通常只影響已經應用了變更的部分機器，從而有效地控制了故障的影響范圍。

分級發布拆分的階段越多，越能夠在變更全面應用之前發現問題。但是，階段的數量也并非越多越好，因為每個階段都需要花費一定的時間來應用變更和檢查健康度，階段的數量大必然導致發布的時間變長，從而降低發布的效率。圖1給出了百度內部分級發布的最佳實踐方案。

方案包含5個階段，依次為沙盒環境、單機房少量機器、單機房全量機器、其他所有機房少量機器、以及其他所有機房全量機器。這種劃分方法平衡了故障風險和變更發布效率，在每個階段制定了對應的故障止損預案，在實踐中取得了很好的效果。 

將變更發布過程拆分成多個階段是基礎，相鄰的兩個階段之間服務健康度檢查是核心。如果在各階段發布后未進行服務健康度檢查或者檢查方法無效，即使將變更發布劃分成了多個階段，故障最終將擴展到所有機器。

因此，分級發布檢查是否有效直接決定了故障引發的損失量。下面將重點介紹如何進行分級發布檢查。

更快、更準發現變更潛在隱患

1. 人工檢查，變更發布效率無法保證

人工檢查是最容易想到的檢查方法，當一個階段變更發布結束后，運維工程師會去監控平臺對核心指標的波動情況進行逐一檢查。如發現有波動異常的指標，則認為本次變更存在問題，中止甚至回滾變更。

在百度，運維工程師會檢查CPU等系統指標以及請求量等業務指標，需要檢查的核心指標個數一般在300個以上。為了保證變更發布效率，一次變更發布除去機器重啟的時間，留給人工檢查的時間通常只有10分鐘左右。根據上述的分級發布流程，一共存在4個檢查點，這就意味著要保證變更發布效率，運維工程師需要在0.5（10*60/4/300）秒內完成一個指標的檢查。

我們知道，在對指標檢查的時候，不單要看當前的波動，還要參考指標在歷史上的波動情況，0.5秒完成一個指標的檢查人工是無法做到的。

2. 基于人工規則檢查，閾值選擇、更新是難題

每次變更發布后人工檢查核心指標耗時耗力，能否將人工檢查的經驗轉化成規則，變更發布時基于規則進行自動檢查？這就是基于人工規則自動檢查。首先，人工根據指標的波動情況，給指標設定不同的閾值。當服務變更發布后，會自動啟動服務健康狀態檢查腳本，腳本會將當時的指標采集值與人工設置的閾值進行比較，若存在指標采集值未落入人工配置的閾值范圍內，則判斷本次變更可能引入了故障，中止變更并通知運維同學進行處理。

如圖2所示的兩個指標，人工給請求量指標設置的閾值上界為2.2k、下界為1.5k；對于請求失敗數指標，用戶只關心指標上漲，因此給指標設置了20的上界。變更發布后，請求量指標在1.5k ~ 2.2k之間波動，判斷該指標正常；請求錯誤數超過了人工配置的上界20，判斷該指標異常，需要中止變更。

基于人工規則檢查將檢查過程自動化，大幅提升了變更發布效率的同時也節省了人力成本。但是人工規則檢查面臨兩大難題：閾值選擇、閾值更新。

首先，應該設置什么樣的閾值是一個很難回答的問題，圖3（a）為某服務的錯誤日志數指標，人工根據經驗將閾值上界設為15，在一次變更發布后錯誤數發生了明顯的上漲，但未達到人工設置的閾值，因此基于人工規則無法發現這次變更引入的故障，導致故障擴散到所有機房，影響了服務的穩定性。

另外，人工配置閾值也并非一勞永逸，當指標水位發生變化后，需要對閾值進行更新。如圖（b）是某服務的請求量指標，歷史請求量經常維持在1.3k，人工將閾值設置在1.2 ~ 1.4k。隨著業務的發展，服務的請求量有了突增達到了1.6k，需要人工對閾值進行調整。

3.  智能檢查，安心躺著做變更

鑒于人工規則檢查存在閾值選擇、更新困難的問題，迫切需要有更智能的檢查方法。我們對一些引入故障的變更進行分析發現，大部分的故障會導致指標突變，運維工程師往往對發生突變的指標格外關注。同時，我們也發現，在變更場景下，指標突變不一定代表變更引入了故障。

比如，當在流量上漲期間進行變更發布時，流量相關的指標必然會發生突增。再比如，在變更發布過程中伴隨著進程重啟，像內存、文件句柄等指標可能會因為資源釋放而發生突降。因此，智能檢查算法由兩部分組成：度量指標是否發生突變、對突變是否合理進行判斷。若指標在變更發布前后發生了無法解釋的突變，則認為指標異常。

指標突變是否合理可以從以下兩個角度進行解釋：突變是否由時間因素、重啟導致。由于時間因素的影響會同時施加在應用變更的機器（實驗組）和未應用變更的機器（對照組），可以根據對照組來排除時間因素的影響；進程重啟對指標的影響可以通過歷史變更來建模。當對照組與歷史變更均無法解釋指標突變時，則認為指標異常，需要中止變更。智能檢查無需人工配置參數，可以自動、智能地識別異常突變的指標。

圖4給出了一個具體的例子，每一行代表一個指標，對于每個指標都展示了在某次變更發布前后的波動情況、對照組在對應時間的波動情況以及指標在歷史一次正常的變更發布前后的波動情況。

對于指標①，指標在本次變更發布后出現了上漲，但是對照組也出現了類似程度的上漲，因此判斷上漲是由時間因素導致，指標變化正常；對于指標②，變更發布后指標出現突降，歷史正常變更發布后指標都會發生突降，因此判斷突降是由進程重啟導致的，指標變化正常；對于指標③，變更發布后發生了突增，而對照組跟歷史變更發布后均未發生明顯變化，即指標突變無法被對照組、歷史變更解釋，指標異常，需要中止甚至回滾變更。

總結

以上就是我們使變更發布更加安全高效的方法，智能檢查算法是減少故障損失的核心。算法基于歷史變更和對照組進行，不需要人工配置參數，具有普適性。希望能夠對大家有所幫助，如有任何想法和疑問，歡迎一起交流。