Facebook 如何避免大規(guī)模線上故障
Fail at Scale 是 Facebook 2015 年在 acm queue 上發(fā)表的一篇文章。主要寫了常見的線上故障和應(yīng)對方法，內(nèi)容還是比較實在的。
"What Would You Do If You Weren't Afraid?" 和 "Fortune Favors the Bold." 是 FB 公司信條，掛墻上那種。
為了能在快速變更的系統(tǒng)中使 FB 的系統(tǒng)穩(wěn)定，工程師們對系統(tǒng)故障進行了一些總結(jié)和抽象，為了能夠建立可靠的系統(tǒng)必須要理解故障。而為了理解故障，工程師們建立了一些工具來診斷問題，并建立了對事故進行復(fù)盤，以避免未來再次發(fā)生的文化。
事故的發(fā)生可以被分為三大類。
為什么會發(fā)生故障
單機故障
通常情況下，單機遇到的孤立故障不會影響到基礎(chǔ)設(shè)施的其他部分。這里的單機故障指的是：一臺機器的硬盤出現(xiàn)了故障，或者某臺機器上的服務(wù)遇到了代碼中的錯誤，如內(nèi)存損壞或死鎖。
避免單個機器故障的關(guān)鍵是自動化。通過總結(jié)已知的故障模式，并與探究未知的故障癥狀相結(jié)合。在發(fā)現(xiàn)未知故障的癥狀(如響應(yīng)緩慢)時，將機器摘除，線下分析，并將其總結(jié)至已知故障中。
工作負載變化
現(xiàn)實世界的重大事件會對 Facebook 網(wǎng)站基礎(chǔ)設(shè)施帶來壓力，比如：
-
奧巴馬當選總統(tǒng)，他的 Facebook 頁面經(jīng)歷了創(chuàng)紀錄的活動水平。
-
重大體育賽事的高潮部分，如超級碗或世界杯，會導(dǎo)致極高的帖子數(shù)量。
-
負載測試，以及新功能發(fā)布時的引流階段會不向用戶展示但引入流量。
這些事件中收集到的統(tǒng)計數(shù)據(jù)會為系統(tǒng)設(shè)計提供獨特的視角。重大事件會導(dǎo)致用戶行為變化，這些變化能為系統(tǒng)后續(xù)的決策提供數(shù)據(jù)依據(jù)。
人為錯誤
圖 1a 顯示了周六和周日發(fā)生的事故是如何大幅減少的，盡管網(wǎng)站的流量在整個一周內(nèi)保持一致。圖 1b 顯示了在六個月的時間里，只有兩個星期沒有發(fā)生事故：圣誕節(jié)的那一周和員工要為對方寫同行評論的那一周。
上圖說明大部分故障都是人為原因，因為事件的統(tǒng)計與人的活動規(guī)律是一致的。
故障的三個原因
故障的原因很多，不過有三種最為常見。這里列出的每一種都給出了預(yù)防措施。
快速部署的配置變更
配置系統(tǒng)往往被設(shè)計為在全球范圍內(nèi)快速復(fù)制變化。快速配置變更是 強大的工具，然而，快速配置變更可能導(dǎo)致部署問題配置時發(fā)生事故。下面是一些防止配置變更故障的手段。
所有人公用同一套配置系統(tǒng)。使用一個共同的配置系統(tǒng)可以確保程序和工具適用于所有類型的配置。
配置變化靜態(tài)檢查。許多配置系統(tǒng)允許松散類型的配置，如 JSON 結(jié)構(gòu)。這些類型的配置使工程師很容易打錯字段的名稱，在需要使用整數(shù)的地方使用字符串，或犯其他簡單的錯誤。這類簡單的錯誤最好用靜態(tài)驗證來捕捉。結(jié)構(gòu)化格式(Facebook 使用 Thrift)可以提供最基本的驗證。然而，編寫程序來對配置進行更詳細的業(yè)務(wù)層面的驗證也是應(yīng)該的。
金絲雀部署。將配置先部署到小范圍，防止變更造成災(zāi)難性后果。金絲雀可以有多種形式。最簡單的是 A/B 測試，如只對 1% 的用戶啟用新的配置。多個 A/B 測試可以同時進行，可以使用一段時間的數(shù)據(jù)來跟蹤指標。
就可靠性而言，A/B 測試并不能滿足所有需求。
-
一個被部署到少數(shù)用戶的變更，如果導(dǎo)致相關(guān)服務(wù)器崩潰或內(nèi)存耗盡，顯然會產(chǎn)生超出測試中有限用戶的影響。
-
A/B 測試也很耗費時間。工程師們經(jīng)常希望在不使用 A/B 測試的情況下推送小的變化。
為了避免配置導(dǎo)致的明顯問題，F(xiàn)acebook 的基礎(chǔ)設(shè)施會自動在一小部分服務(wù)器上測試新版本的配置。
例如，如果我們希望向 1% 的用戶部署一個新的 A/B 測試，會首先向 1% 的用戶部署測試，保證這些用戶的請求落在少量服務(wù)器上，并對這些服務(wù)器進行短時間的監(jiān)控，以確保不會因為配置更新出現(xiàn)非常明顯的崩潰問題。
堅持可以運行的配置。配置系統(tǒng)設(shè)計方案保證在發(fā)生失敗時，保留原有的配置。開發(fā)人員一般傾向于配置發(fā)生問題時系統(tǒng)直接崩潰，不過 Facebook 的基礎(chǔ)設(shè)施開發(fā)人員認為用老的配置，使模塊能運行比向用戶返回錯誤好得多。(注：我只能說這個真的要看場景)
配置有問題時回滾要快速。有時，盡管盡了最大努力，有問題的配置還是上了線。迅速回滾是解決這類問題的關(guān)鍵。配置內(nèi)容在版本管理系統(tǒng)中進行管理，保證能夠回滾。
強依賴核心服務(wù)
開發(fā)人員傾向于認為，核心服務(wù)：如配置管理、服務(wù)發(fā)現(xiàn)或存儲系統(tǒng)，永遠不會失敗。在這種假設(shè)下，這些核心服務(wù)的短暫故障，會變成大規(guī)模故障。
緩存核心服務(wù)的數(shù)據(jù)。可以在服務(wù)本地緩存一部分數(shù)據(jù)，這樣可以降低對緩存服務(wù)的依賴。 提供專門 SDK 來使用核心服務(wù)。 核心服務(wù)最好提供專門的 SDK，這樣保證大家在使用核心服務(wù)時都能遵循相同的最佳實踐。同時在 SDK 中可以考慮好緩存管理和故障處理，使用戶一勞永逸。 進行演練。 只要不進行演練，就沒法知道如果依賴的服務(wù)掛了自己是不是真的會掛，所以通過演練來進行故障注入是必須的。
延遲增加和資源耗盡
有些故障會導(dǎo)致延遲增加，這個影響可以很小(例如，導(dǎo)致 CPU 使用量微微增加)，也可以很大(服務(wù)響應(yīng)的線程死鎖)。
少量的額外延遲可以由 Facebook 的基礎(chǔ)設(shè)施輕松處理，但大量的延遲會導(dǎo)致級聯(lián)故障。幾乎所有的服務(wù)都有一個未處理請求數(shù)量的限制。這個限制可能是因為請求響應(yīng)類服務(wù)的線程數(shù)量有限，也可能是由于基于事件的服務(wù)內(nèi)存有限。如果一個服務(wù)遇到大量的額外延遲，那么調(diào)用它的服務(wù)將耗盡它的資源。這種故障會層層傳播，造成大故障。
資源耗盡是特別具有破壞性的故障模式，它會使請求子集所使用的服務(wù)的故障引起所有請求的故障：
一個服務(wù)調(diào)用一個新的實驗性服務(wù)，該服務(wù)只向 1% 的用戶推出。通常情況下，對這個實驗性服務(wù)的請求需要 1 毫秒，但由于新服務(wù)的失敗，請求需要 1 秒。使用這個新服務(wù)的 1% 的用戶的請求可能會消耗很多線程，以至于其他 99% 的用戶的請求都無法被執(zhí)行。
下面的手段可以避免請求堆積：
-
延遲控制。在分析過去涉及延遲的事件時，工程師發(fā)現(xiàn)大量請求都是堆積在隊列中等待處理。服務(wù)一般會有線程數(shù)或內(nèi)存使用上的限制。由于服務(wù)響應(yīng)速度 < 請求傳入速度，隊列會越來越大，直到達到閾值。想要在不影響正常運行可靠性的前提下限制隊列大小，F(xiàn)B 工程師研究了 bufferbloat 問題，這里的問題和 bufferbloat 問題很類似，都是在擁塞的時候不引起過度延遲。這里實現(xiàn)了 CoDel(controlled delay 縮寫)算法的一個變種：
注：雖然里面寫著 M 和 N，但其實 M 和 N 是定值，N = 100ms，M = 5ms
- onNewRequest(req, queue):
- if queue.lastEmptyTime() < (now - N seconds) {
- timeout = M ms
- } else {
- timeout = N seconds;
- }
- queue.enqueue(req, timeout)
在這個算法中，如果隊列在過去的 100ms 內(nèi)沒有被清空，那么在隊列中花費的時間被限制在 5ms。如果服務(wù)在過去的 100ms 能夠清空隊列，那么在隊列中花費的時間被限制為 100 ms。這種算法可以減少排隊（因為 lastEmptyTime 是在遙遠的過去，導(dǎo)致 5ms 的排隊超時），同時允許短時間的排隊以達到可靠性的目的。雖然讓請求有這么短的超時似乎有悖常理，但這個過程允許請求被快速丟棄，而不是在系統(tǒng)無法跟上傳入請求的速度時堆積起來。較短的超時時間可以確保服務(wù)器接受的工作總是比它實際能處理的多一點，所以它永遠不會閑置。
前面也說了，這里的 M 和 N 基本上不需要按場景調(diào)整。其他解決排隊問題的方法，如對隊列中的項目數(shù)量設(shè)置限制或為隊列設(shè)置超時，需要按場景做 tuning。M 固定 5 毫秒，N 值為 100 毫秒，在大多場景下都能很好地工作。Facebook 的開源 Wangle 庫和 Thrift 使用了這種算法。
-
自適應(yīng) LIFO(后進先出)。大多數(shù)服務(wù)以 FIFO 的順序處理隊列。然而，在大量排隊期間，先入的請求往往已經(jīng)等了很久，用戶可能已經(jīng)放棄了請求相關(guān)的行為。這時候處理先入隊的請求，會將資源耗費在一個不太可能使用戶受益的請求上。FB 的服務(wù)使用自適應(yīng)后進先出的算法來處理請求。在正常的操作條件下，請求是 FIFO 處理模式，但是當隊列開始任務(wù)堆積時，則切換至 LIFO 模式。如圖 2 所示，自適應(yīng) LIFO 和 CoDel 可以很好地配合。CoDel 設(shè)置了較短的超時時間，防止了形成長隊列，而自適應(yīng) LIFO 模式將新的請求放在隊列的前面，最大限度地提高了它們滿足 CoDel 設(shè)置的最后期限的機會。HHVM 實現(xiàn)了這個后進先出算法。
-
并發(fā)控制。CoDel 和自適應(yīng) LIFO 都在服務(wù)器端運行。服務(wù)端是降低延遲的最佳場所--server 為大量的 client 服務(wù)，且有比 client 端更多的信息。 不過有些故障較嚴重， 可能 導(dǎo)致服務(wù)端的控制無法啟動。 為了兜底 FB 還在客戶端實施了一個策略： 每個客戶端都會在每個服務(wù)的基礎(chǔ)上跟蹤未完成的出站請求的數(shù)量。 當新的請求被發(fā)送時，如果對該服務(wù)的未決請求的數(shù)量超過可配置的數(shù)量，該請求將立即被標記為錯誤( 注：應(yīng)該類似熔斷 )。 這種機制可以防止單一服務(wù)壟斷其客戶的所有資源。
幫助診斷故障的工具
盡管有最好的預(yù)防措施，故障還是會發(fā)生。故障期間，使用正確的工具可以迅速找到根本原因，最大限度地減少故障的持續(xù)時間。
使用 Cubism 的高密度儀表板在處理事故時，快速獲取信息很重要。好的儀表盤可以讓工程師快速評估可能出現(xiàn)異常的指標類型，然后利用這些信息來推測根本原因。然而儀表盤會越來越大，直到難以快速瀏覽，這些儀表盤上顯示的圖表有太多線條，無法一目了然，如圖3所示。
為了解決這個問題，我們使用 Cubism 構(gòu)建了我們的頂級儀表盤，這是一個用于創(chuàng)建地平線圖表的框架--該圖表使用顏色對信息進行更密集的編碼，允許對多個類似的數(shù)據(jù)曲線進行輕松比較。例如，我們使用 Cubism 來比較不同數(shù)據(jù)中心的指標。我們圍繞 Cubism 的工具允許簡單的鍵盤導(dǎo)航，工程師可以快速查看多個指標。圖 4 顯示了使用面積圖和水平線圖的不同高度的同一數(shù)據(jù)集。在面積圖版本中，30像素高的版本很難閱讀。同一高度下地平線圖非常容易找到峰值。
最近發(fā)生了什么變更？
由于失敗的首要原因之一是人為錯誤，調(diào)試失敗的最有效方法之一是尋找人類最近的變化。我們在一個叫做 OpsStream 的工具中收集關(guān)于最近的變化的信息，從配置變化到新版本的部署。然而，我們發(fā)現(xiàn)隨著時間的推移，這個數(shù)據(jù)源已經(jīng)變得非常嘈雜。由于數(shù)以千計的工程師在進行改變，在一個事件中往往有太多的改變需要評估。
為了解決這個問題，我們的工具試圖將故障與其相關(guān)的變化聯(lián)系起來。例如，當一個異常被拋出時，除了輸出堆棧跟蹤外，我們還輸出該請求所讀取的任何配置的值最近發(fā)生的變化。通常，產(chǎn)生許多錯誤堆棧的問題的原因就是這些配置值之一。然后，我們可以迅速地對這個問題做出反應(yīng)。例如，讓上線該配置的工程師趕緊回滾配置。
從失敗中學(xué)習(xí)
失敗發(fā)生后，我們的事件審查過程有助于我們從這些事件中學(xué)習(xí)。
事件審查過程的目的不是為了指責。沒有人因為他或她造成的事件被審查而被解雇。審查的目的是為了了解發(fā)生了什么，補救使事件發(fā)生的情況，并建立安全機制以減少未來事件的影響。
審查事件的方法 Facebook 發(fā)明了一種名為 DERP（detection, escalation, remediation, and prevention）的方法，以幫助進行富有成效的事件審查。
-
檢測 detection。如何檢測問題--報警、儀表板、用戶報告？
-
升級 escalation。正確的人是否迅速介入？這些人是否可以通過警報被拉進故障處理流程，而不是人為拉進來？
-
補救 remediation。采取了哪些步驟來解決這個問題？這些步驟是否可以自動化？
-
預(yù)防 prevention。哪些改進可以避免同類型的故障再次發(fā)生？你如何能優(yōu)雅地失敗，或更快地失敗，以減少這次故障的影響？
在這種模式的幫助下，即使不能防止同類型的事件再次發(fā)生，也至少能夠在下一次更快恢復(fù)。
一把梭的時候少出故障
"move fast" 的心態(tài)不一定與可靠性沖突。為了使這些理念兼容，F(xiàn)acebook 的基礎(chǔ)設(shè)施提供了安全閥：
-
配置系統(tǒng)可以防止不良配置的快速部署；
-
核心服務(wù)為客戶提供加固 SDK 以防止故障；
-
核心穩(wěn)定性庫可以防止在延遲發(fā)生的情況下資源耗盡。
為了處理漏網(wǎng)之魚，還建立了易于使用的儀表盤和工具，以幫助找到與故障關(guān)聯(lián)的最近的變更。
最重要的是，在事件發(fā)生后，通過復(fù)盤學(xué)到的經(jīng)驗將使基礎(chǔ)設(shè)施更加可靠。
References
-
CoDel (controlled delay) algorithm; http://queue.acm.org/detail.cfm?id=2209336.
-
Cubism; https://square.github.io/cubism/.
-
HipHop Virtual Machine (HHVM); https://github.com/facebook/hhvm/blob/43c20856239cedf842b2560fd768038f52b501db/hphp/util/job-queue.h#L75.
-
Thrift framework; https://github.com/facebook/fbthrift.
-
Wangle library; https://github.com/facebook/wangle/blob/master/wangle/concurrent/Codel.cpp.
-
https://github.com/facebook/folly/blob/bd600cd4e88f664f285489c76b6ad835d8367cd2/folly/executors/Codel.cpp
