別再拿無法實現(xiàn)零故障當(dāng)借口擺爛

我們在昨天的文章中，借用IBM的大型機之父Frederick Brooks在《人月神話》一書中闡述的理論，解釋了為什么一個軟件系統(tǒng)無法實現(xiàn)零故障的原因。

但作為一個擁有不（jia）斷（guan）進（jin）?。╦ue）之心的技術(shù)團隊成員，相信還是會想要規(guī)避故障，今天就和大家來聊聊這方面的內(nèi)容。

任何的生產(chǎn)故障，當(dāng)其發(fā)生時都會帶來一定量的傷害和損失。故障雖然不能杜絕，但我們可以通過一系列的手段去及時發(fā)現(xiàn)故障、預(yù)判故障發(fā)生的可能性、在故障發(fā)生時能夠及時合理預(yù)估可能的損失，從而做出正確的動作判斷。我們可以通過如下手段和方法去逐步完善。

• 故障處理制度

這個部分是非常重要的工作規(guī)范，是屬于在前人踩坑經(jīng)驗的基礎(chǔ)上總結(jié)提煉出來的內(nèi)容，是每個技術(shù)管理者需要在技術(shù)團隊內(nèi)不斷強化和要求準(zhǔn)確執(zhí)行的內(nèi)容。

故障處理制度要包含幾個部分：故障等級、處理流程、分析要求、處罰說明。

故障等級：是用來描述故障嚴(yán)重等級定義內(nèi)容，約定了不同的服務(wù)類型及其出現(xiàn)故障后可能產(chǎn)生的影響面及損失大小，整體用“S”（Sensitive 嚴(yán)重級別）或“P”（Priority 優(yōu)先級別）疊加從小到大的數(shù)字來表示。

比如用戶登錄服務(wù)，屬于核心服務(wù)。根據(jù)業(yè)務(wù)規(guī)模情況，如果是停止服務(wù)15分鐘，就可以定義為P1（或S1）級故障。在這個部分還有一個重要的關(guān)鍵內(nèi)容是服務(wù)升級情況，需要根據(jù)服務(wù)等級不同，約定故障在多長時間內(nèi)沒有恢復(fù)。則需要進行升級，以強化技術(shù)團隊整體對故障發(fā)生時的快速響應(yīng)和處理。

處理流程：用來約定技術(shù)團隊整體對故障的處理過程。比如發(fā)現(xiàn)故障后，需要召喚哪些人組成臨時的處理小組，什么場景要通知誰、運維要做什么配合、要對哪些內(nèi)容進行操作處理等等，是對整個故障現(xiàn)場工作處置的細節(jié)描述。

同時，作為一個完整的處置流程，必須要關(guān)注的還有故障處理完成的標(biāo)志。比如針對該故障的所有后續(xù)任務(wù)處置完畢等，也是工作閉環(huán)的重要內(nèi)容。正如之前文章提到的《計劃清單》一書中所描述一樣，詳盡細致的清單，可以在壓力巨大的場景下提供更安全高效的工作處理過程，帶來更好的結(jié)果。

分析要求：每一個故障其實都是團隊的一次技術(shù)訓(xùn)練和教育，通過故障的深入分析還原故障的本質(zhì)原因，找到最核心的解決方法，能夠幫助技術(shù)團隊快速提升。在分析要求中，需要明確列明故障分析報告的構(gòu)成元素、數(shù)據(jù)詳細程度、處理過程細節(jié)要求、處置結(jié)果描述及后續(xù)任務(wù)安排及跟進結(jié)果等內(nèi)容。

處罰說明：這個部分的內(nèi)容根據(jù)技術(shù)團隊的實際情況來定義，可以是針對故障等級，對相關(guān)故障的主要責(zé)任人和次要責(zé)任人進行適度的處罰建議。這里需要關(guān)注的內(nèi)容在于處罰本身不是故障處理的重要內(nèi)容，而前面幾項內(nèi)容才是核心。但作為一個制度，沒有相應(yīng)的責(zé)罰內(nèi)容說明，就會讓這個制度失去威嚴(yán)，會讓大家不重視該制度的落地執(zhí)行。

• 日常CodeReview

CodeReview并不能帶來直接的工作績效，是屬于需要長期堅持且見效很慢的工作。但坦率講，Code Review除了能帶來系統(tǒng)質(zhì)量上的提升，還能帶來工作效率和團隊整體技術(shù)戰(zhàn)斗力的提升。

我在阿里所負責(zé)的一個團隊中，PLA（Product Line Architect，業(yè)務(wù)線架構(gòu)師）有 3、4 位，分別負責(zé)各自的一塊業(yè)務(wù)。PLA 之間 CodeReview 很少，代碼質(zhì)量的意識交流似乎也不多。但團隊的普通開發(fā)同學(xué)在這些 PLA 之間輪流被 CodeReview，代碼質(zhì)量的評比標(biāo)準(zhǔn)差異較大。

這可能會導(dǎo)致 2 種現(xiàn)象：開發(fā)傾向 Review 寬松的同學(xué)，因為寬松 Review 發(fā)現(xiàn)問題（不僅僅是 bug）較少，變動成本不大。不會有改動造成的故障風(fēng)險，不會影響項目進度，但后續(xù)的維護和溝通成本會明顯增加；另一種現(xiàn)象，開發(fā)向不同的 PLA 提出疑義，PLA 之間統(tǒng)一代碼質(zhì)量標(biāo)準(zhǔn)，在團隊內(nèi)達成共識并形成文檔，以作為后續(xù)參考。

所以這個團隊的代碼質(zhì)量主要取決于團隊幾位 PLA，最后在一次故障的復(fù)盤工作中，我們重新提出這個問題，要求PLA們能夠幫助團隊統(tǒng)一代碼質(zhì)量意識和規(guī)范。例如：先由 1-2 位 PLA 對整個團隊開發(fā)做 Review，這個 Review 工作量初期會很大，并且團隊工作效率不高。但后期的 Review 工作量應(yīng)該會明顯減小，代碼質(zhì)量也會明顯提高， 團隊的工作效率也會明顯提升。

可能你會說，這例子能被執(zhí)行是因為大廠有更多的冗余資源足以可以落地推行，中小團隊沒有太多的空閑該如何處理？答案只能從為質(zhì)量埋單的人這里來尋找，只有他痛，他才會推進這些工作得以落地。即便團隊中沒有更多的PLA來落地推進，也可以依靠各個模塊的技術(shù)負責(zé)人，在日常工作過程中立即開展這項工作以使代碼質(zhì)量得到改善。

• 監(jiān)控系統(tǒng)

監(jiān)控系統(tǒng)的作用主要體現(xiàn)在故障發(fā)生前和發(fā)生中，如果一個團隊擁有完善的監(jiān)控系統(tǒng)，在面對故障發(fā)生的前后，會大幅度地縮短故障發(fā)生幾率、降低故障帶來的損失。這種監(jiān)控分成幾個方面：

業(yè)務(wù)層面監(jiān)控：業(yè)務(wù)監(jiān)控主要是針對日常的業(yè)務(wù)指標(biāo)進行持續(xù)的數(shù)據(jù)跟蹤，觀察業(yè)務(wù)數(shù)據(jù)的變化區(qū)間情況，來判斷當(dāng)前的業(yè)務(wù)是否運轉(zhuǎn)正常。

比如針對電商業(yè)務(wù)來說，一天24小時的用戶登錄、訪問商品、下訂單等業(yè)務(wù)動作都會有一個周期性的小幅波動。如果某天某個時段的業(yè)務(wù)數(shù)據(jù)產(chǎn)生異常波動，尤其是數(shù)據(jù)大幅下滑，則有可能是系統(tǒng)在這個業(yè)務(wù)流程處理過程中出現(xiàn)了風(fēng)險，導(dǎo)致業(yè)務(wù)不能正常執(zhí)行。

應(yīng)用層面監(jiān)控：是指對于業(yè)務(wù)系統(tǒng)進行內(nèi)部的服務(wù)健康狀態(tài)的監(jiān)控。諸如：系統(tǒng)存活狀態(tài)、性能響應(yīng)、業(yè)務(wù)異常告警等等。

系統(tǒng)層面監(jiān)控：這個部分一般是指系統(tǒng)的運行環(huán)境層面的監(jiān)控，比如CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)IO、網(wǎng)絡(luò)連接等。針對系統(tǒng)運行環(huán)境內(nèi)部的運行狀態(tài)，如Java的JVM狀態(tài)、GC次數(shù)和狀態(tài)等等，都包含在這個部分之中。也都有相應(yīng)的系統(tǒng)提供對應(yīng)的服務(wù)，技術(shù)團隊可以直接套用成熟的方案以節(jié)約時間。

這里還需要關(guān)注的一個內(nèi)容就是監(jiān)控系統(tǒng)中的告警機制，好的告警機制會規(guī)避掉告警的疲勞，避免因為頻繁的小規(guī)模告警而讓接受方產(chǎn)生思想上的懈怠。如果有一個重大的告警發(fā)生時，往往會出現(xiàn)沒有及時關(guān)注告警情況而延誤故障處置時間。

當(dāng)然，針對這種情況，從告警的角度來講，還可以通過告警升級的手段來加快處理效率。

比如一個告警在第一級處置人員手中沒有及時響應(yīng)，也沒有及時對該告警內(nèi)容進行后續(xù)的處置動作。那么可以在約定的時間內(nèi)對該告警信息進行升級，交由上級處理，并在告警的形式上可以更換一種更加直接的方式處理。如：從短信告警升級為電話告警等等。

還有一種故障預(yù)防的方式越來越被許多技術(shù)團隊采用，用來對系統(tǒng)健壯性和關(guān)鍵業(yè)務(wù)運行時間段中的故障發(fā)生狀態(tài)下進行整體的故障處置演練，強化團隊對故障處理的熟練度，提升處理效率，這就是時下比較流行的“混沌工程（Chaos Engineering）”。

Netflix工程師創(chuàng)建了Chaos Monkey，使用該工具可以在整個系統(tǒng)的隨機位置引發(fā)故障。正如GitHub上的工具維護者所說，“Chaos Monkey會隨機終止在生產(chǎn)環(huán)境中運行的虛擬機實例和容器?！蓖ㄟ^Chaos Monkey，工程師可以快速了解他們正在構(gòu)建的服務(wù)是否健壯，是否可以彈性擴容，是否可以處理計劃外的故障。

2012年，Netflix開源了Chaos Monkey。今天，許多公司（包括谷歌，亞馬遜，IBM，耐克等），都采用某種形式的混沌工程來提高現(xiàn)代架構(gòu)的可靠性。Netflix甚至將其混沌工程工具集擴展到包括整個“Simian Army（中文可以譯為猿軍）”，用它攻擊自己的系統(tǒng)。

混沌工程屬于一門新興的技術(shù)學(xué)科，行業(yè)認知和實踐積累比較少，大多數(shù)IT團隊對它的理解還沒有上升到一個領(lǐng)域概念。阿里電商域在2010年左右開始嘗試故障注入測試的工作，希望解決微服務(wù)架構(gòu)帶來的強弱依賴問題。

混沌工程通過一系列的實驗來發(fā)現(xiàn)系統(tǒng)的弱點，整體過程分成如下幾步：

1.定義并測量系統(tǒng)的“穩(wěn)定狀態(tài)”。

首先精確定義指標(biāo)，表明您的系統(tǒng)按照應(yīng)有的方式運行。Netflix使用客戶點擊視頻流設(shè)備上播放按鈕的速率作為指標(biāo)，稱為“每秒流量”。請注意，這更像是商業(yè)指標(biāo)而非技術(shù)指標(biāo)；事實上，在混沌工程中，業(yè)務(wù)指標(biāo)通常比技術(shù)指標(biāo)更有用，因為它們更適合衡量用戶體驗或運營。

2.創(chuàng)建假設(shè)。

與任何實驗一樣，您需要一個假設(shè)來進行測試。因為你試圖破壞系統(tǒng)正常運行時的穩(wěn)定狀態(tài)，你的假設(shè)將是這樣的：“當(dāng)我們做X時，這個系統(tǒng)的穩(wěn)定狀態(tài)應(yīng)該沒有變化。”為什么用這種方式表達？如果你的期望是你的動作會破壞系統(tǒng)的穩(wěn)定狀態(tài)，那么你會做的第一件事是修復(fù)問題?；煦绻こ虘?yīng)該包括真正的實驗，涉及真正的未知數(shù)。

3.模擬現(xiàn)實世界中可能發(fā)生的事情，目前有如下混沌工程實踐方法：

模擬數(shù)據(jù)中心的故障、強制系統(tǒng)時鐘不同步、在驅(qū)動程序代碼中模擬I/O異常、模擬服務(wù)之間的延遲、隨機引發(fā)函數(shù)拋異常。通常，您希望模擬可能導(dǎo)致系統(tǒng)不可用或?qū)е缕湫阅芙档偷膱鼍?。首先考慮可能出現(xiàn)什么問題，然后進行模擬。一定要優(yōu)先考慮潛在的錯誤。

4.證明或反駁你的假設(shè)。

將穩(wěn)態(tài)指標(biāo)與干擾注入系統(tǒng)后收集的指標(biāo)進行比較。如果您發(fā)現(xiàn)測量結(jié)果存在差異，那么您的混沌工程實驗已經(jīng)成功。您現(xiàn)在可以繼續(xù)加固系統(tǒng)，以便現(xiàn)實世界中的類似事件不會導(dǎo)致大問題?；蛘?，如果您發(fā)現(xiàn)穩(wěn)定狀態(tài)可以保持，那么你對該系統(tǒng)的穩(wěn)定性大可放心。

混沌工程的目的是在將故障扼殺在襁褓之中，也就是在故障造成中斷之前將它們識別出來。通過主動制造故障，測試系統(tǒng)在各種壓力下的行為，識別并修復(fù)故障問題，避免造成嚴(yán)重后果。

關(guān)注我們，防范線上故障