摘要：當(dāng)奧巴馬贏得美國總統(tǒng)大選時，頁面活躍度刷新了記錄。對于每一個成因，都應(yīng)制定相應(yīng)的預(yù)防措施，以減輕大規(guī)模事故。這種故障會通過許多層面進(jìn)入系統(tǒng)服務(wù)中，導(dǎo)致系統(tǒng)故障的發(fā)生。

作者介紹：Ben Maurer是Facebook的網(wǎng)絡(luò)基礎(chǔ)團(tuán)隊(duì)的技術(shù)領(lǐng)先者，主要負(fù)責(zé)整個Facebook面向用戶產(chǎn)品的性能和可靠性。Ben于2010年正式加入Facebook，基礎(chǔ)設(shè)施團(tuán)隊(duì)的成員。在加入Facebook之前，他與Luis von Ahn共同創(chuàng)立的驗(yàn)證碼。最近，本與美國數(shù)字服務(wù)公司合作，以改進(jìn)在聯(lián)邦政府的技術(shù)使用。

數(shù)人云今天為大家?guī)硪黄狟en Maurer分享的“Facebook面對大規(guī)模系統(tǒng)工程故障排查實(shí)踐”，由于內(nèi)容較多，所以數(shù)人云今天只為大家?guī)砩习氩糠郑罄m(xù)內(nèi)容會在明天發(fā)布！

故障是任何大規(guī)模工程系統(tǒng)的一部分。Facebook的文化價值之一就是擁抱失敗。這可以從掛在門洛帕克總部墻上的海報上得到體現(xiàn)：“如果你無所畏懼，你會怎樣？”“天佑勇者。”

為了使Facebook的系統(tǒng)在快速變化的情況下保持可靠，專門為其研究了常見的故障模式，并建立抽象理念來解決這些問題。這些理念確保最佳實(shí)踐應(yīng)用于的整個基礎(chǔ)設(shè)施。通過建立工具來診斷問題，并創(chuàng)建一種復(fù)盤事故的文化來推動并作出改進(jìn)，防止未來發(fā)生故障。

雖然每一個故障都有一個獨(dú)特的故事，但是多數(shù)故障都可以歸結(jié)為少數(shù)的原因。

單個機(jī)器通常會遇到一個孤立的故障，不會影響基礎(chǔ)設(shè)施的其余部分。例如，可能一臺機(jī)器的硬盤驅(qū)動器發(fā)生了故障，或者某臺機(jī)器上的服務(wù)遇到了代碼中的錯誤，內(nèi)存損壞或等。

避免單個機(jī)器故障的關(guān)鍵是自動化，自動化工作最好結(jié)合已知的故障模式（如硬盤驅(qū)動器的S.M.A.R.T.錯誤）與未知問題的搜索（例如，通過交換服務(wù)器異常緩慢的響應(yīng)時間）。當(dāng)自動化發(fā)現(xiàn)一個未知問題，手工調(diào)查可以幫助開發(fā)更好的工具來檢測和修復(fù)問題。

遇到突發(fā)狀況，F(xiàn)acebook會改變?nèi)粘５男袨榱?xí)慣，為基礎(chǔ)設(shè)施帶來挑戰(zhàn)。例如，在重要的全球事件中，獨(dú)特的工作負(fù)載可能會以不尋常的方式來考驗(yàn)其中的基礎(chǔ)設(shè)施。當(dāng)奧巴馬贏得2008美國總統(tǒng)大選時，F(xiàn)acebook頁面活躍度刷新了記錄。如超級杯或者世界杯這樣重大的體育賽事也會引發(fā)其發(fā)帖數(shù)量大大增加。負(fù)載測試，包括“灰度發(fā)布”即有新功能發(fā)布，但是對于使用者不可見，有助于確保新功能能夠處理負(fù)載。

在這些事件中收集的統(tǒng)計數(shù)據(jù)常常為系統(tǒng)的設(shè)計提供一個獨(dú)特的視角。通常情況下，重大事件導(dǎo)致用戶行為的變化（例如，通過圍繞一個特定的對象創(chuàng)建主題活動）。有關(guān)這些更改的數(shù)據(jù)通常指向設(shè)計決策，以便在后續(xù)事件中允許更平滑的操作。

鑒于Facebook鼓勵工程師“快速行動，打破常規(guī)”-如同裝飾辦公室的另一個海報所示，也許有人會認(rèn)為，很多錯誤都是人為造成的。根據(jù)數(shù)據(jù)表明，人為失誤是失敗的一個因素。圖1涵蓋了嚴(yán)重到足以被認(rèn)為違反了SLA（服務(wù)水平協(xié)議）的事件的時間節(jié)點(diǎn)數(shù)據(jù)。由于目標(biāo)是很嚴(yán)格的，所以對網(wǎng)站用戶而言大多數(shù)事件是輕微的，不明顯的。圖1a顯示事件在星期六和星期日發(fā)生的概率大幅減少，然而也不會影響網(wǎng)站流量。圖1b顯示6個月的時間只有兩周沒有事件：包括圣誕節(jié)的一周和員工寫互評的一周。

這兩個數(shù)據(jù)似乎表明，當(dāng)Facebook的員工因?yàn)槊τ谄渌虑椋ㄈ缰苣⒐?jié)假日以及員工考核等）而沒有積極去改變基礎(chǔ)設(shè)施的時候，網(wǎng)站的可靠性反而處于一個比較高的水平。導(dǎo)致我們相信這不是因?yàn)镕acebook員工過于粗心，而是證明了基礎(chǔ)設(shè)施在很大程度上是對非人為的錯誤進(jìn)行自我修復(fù)，如機(jī)器故障。

雖然事故有不同的產(chǎn)生原因，但是通過總結(jié)發(fā)現(xiàn)，有三種常見的原因會使故障擴(kuò)大并成為大規(guī)模的問題。對于每一個成因，都應(yīng)制定相應(yīng)的預(yù)防措施，以減輕大規(guī)模事故。

配置系統(tǒng)往往被設(shè)計為能在全球范圍內(nèi)迅速復(fù)制更改。Rapid配置更改是一個功能強(qiáng)大的工具，可以讓工程師快速管理新產(chǎn)品的推出或調(diào)整設(shè)置。然而，快速配置也意味著當(dāng)配置不當(dāng)時會快速引發(fā)故障。我們采取了一些方法來防止配置更改導(dǎo)致故障。

讓每個人都使用一個通用的配置系統(tǒng)

使用通用配置系統(tǒng)可以確保程序和工具適用于所有類型的配置。在Facebook，我們發(fā)現(xiàn)團(tuán)隊(duì)有時會試圖以一次性的方式來進(jìn)行配置。避免使用這種方式而采用一種統(tǒng)一的方式來進(jìn)行配置，從而使配置系統(tǒng)成為一種提高站點(diǎn)可靠性的衡量方法。

靜態(tài)驗(yàn)證配置更改

許多配置系統(tǒng)允許松散類型的配置，如JSON結(jié)構(gòu)。這些類型的配置很容易使工程師犯一些低級錯誤，例如敲錯字段，如果這個字段是必須使用整數(shù)的字符串。對于這種類型的錯誤最好的辦法就是使用靜態(tài)驗(yàn)證。一個結(jié)構(gòu)化的格式（例如，在Facebook使用的Thrift）可以提供最基本的驗(yàn)證。然而，編寫驗(yàn)證程序來驗(yàn)證更詳細(xì)的要求也是合理的。

運(yùn)行一個Canary

首先將配置部署到服務(wù)的小范圍，可以防止災(zāi)難性的更改。一個Canary可以采取多種形式。最明顯的是A / B測試，如只對百分之一的用戶推出一個新的配置。多個A / B測試可以同時運(yùn)行，并且可以使用數(shù)據(jù)隨時間進(jìn)度來跟蹤度量。

然而，對于可靠性的目的，A / B測試不滿足我們的所有需求。一個更改部署給少數(shù)用戶，但導(dǎo)致了服務(wù)器崩潰或內(nèi)存耗盡的變化，顯然會產(chǎn)生超出測試的有限用戶的影響。A / B測試也費(fèi)時。工程師們常常希望在沒有使用A / B測試的情況下推出一些微小的變化。為此，F(xiàn)acebook基礎(chǔ)設(shè)施自動測試新配置的一小部分服務(wù)器。例如，如果我們希望部署一個新的A / B測試給百分之一的用戶，首先部署測試在僅影響很少量服務(wù)器的那部分用戶，在一個很短的時間內(nèi)監(jiān)測這些服務(wù)器，以確保他們不會崩潰或有其他很明顯的問題。這種機(jī)制提供了一個適用于所有變更的基本的“健全檢查”以確保它們不會造成大面積的故障。

保持良好的配置

Facebook的配置系統(tǒng)的設(shè)計是盡量確保當(dāng)更新帶來故障時保持良好的配置。開發(fā)人員希望創(chuàng)建的配置系統(tǒng)當(dāng)接收到無效的更新配置時會崩潰。喜歡在這些類型的情況下保留舊的配置，并向系統(tǒng)操作員發(fā)出警報，說明該配置無法更新。繼續(xù)運(yùn)行舊有的配置通常優(yōu)于將錯誤返回給用戶。

使它容易恢復(fù)

有時，盡管盡了最大努力，部署的配置依然有問題，快速查找和恢復(fù)是解決這類問題的關(guān)鍵，配置系統(tǒng)是由版本控制，這使得系統(tǒng)很容易恢復(fù)。

開發(fā)者通常默認(rèn)配置管理，服務(wù)發(fā)現(xiàn)，存儲系統(tǒng)等核心業(yè)務(wù)永遠(yuǎn)不會發(fā)生故障。可是，這些核心業(yè)務(wù)的輕微故障都會引起大面積的事故發(fā)生。

核心服務(wù)的緩存數(shù)據(jù)

依賴于這些類型的服務(wù)通常是不必要的，可以通過緩存數(shù)據(jù)的方式，以此保證其中一個系統(tǒng)短暫性中斷，而其它服務(wù)依舊繼續(xù)運(yùn)行。

提供硬化的API使用核心服務(wù)

核心服務(wù)是最好的補(bǔ)充公共庫，遵循最佳實(shí)踐來使用這些核心服務(wù)。例如，庫可以提供良好的api來管理緩存或處理故障。

運(yùn)行的消防演習(xí)

你可能認(rèn)為能夠在核心服務(wù)中斷中生存下來，在嘗試之前，你永遠(yuǎn)不會知道。對于這些類型的中斷，我們不得不開發(fā)系統(tǒng)的消防演習(xí)，從故障注入系統(tǒng)應(yīng)用到單個服務(wù)器中，以此手動觸發(fā)整個數(shù)據(jù)中心的中斷。

一些故障導(dǎo)致服務(wù)的延遲增加到客戶端。這種增加的延遲可能很少（例如，考慮到一個人的配置錯誤，但是依舊服務(wù)的能力導(dǎo)致CPU使用量增加），還有就是，它可能是無限的（一個服務(wù)線程服務(wù)響應(yīng)陷入癱瘓）。而少量的延遲可以很容易地解決由Facebook的基礎(chǔ)設(shè)施、大量的延遲會導(dǎo)致全面故障。幾乎所有的服務(wù)對未完成請求的數(shù)量都有限制，這個限制可能是由于每個請求服務(wù)線程數(shù)量有限，也可能是由于基于故障服務(wù)中的內(nèi)存有限。如果一個服務(wù)面臨大量的延遲，那么調(diào)用它的服務(wù)將耗盡他們的資源。這種故障會通過許多層面進(jìn)入系統(tǒng)服務(wù)中，導(dǎo)致系統(tǒng)故障的發(fā)生。

資源枯竭是一個極具破壞性的故障模式，由于它允許服務(wù)請求的子集用于導(dǎo)致失敗的所有請求失敗。例如，一個服務(wù)調(diào)用只推出 1%的用戶對新的實(shí)驗(yàn)服務(wù)，通常要求這個實(shí)驗(yàn)服務(wù)需要1毫秒，但由于在新的服務(wù)失敗的請求需要1秒，所以1%的用戶使用這項(xiàng)新服務(wù)請求可能會消耗太多的線程，其他99％用戶就不能運(yùn)行此線程。
如今，我們已經(jīng)發(fā)現(xiàn)了一些技術(shù)，可以避免這種類型的積累與較低的誤報率。

控制延遲

在分析以往的事故延遲中，我們發(fā)現(xiàn)許多最糟糕的故障涉及大量隊(duì)列等待處理的請求。有問題的服務(wù)有一個資源限制（如活動線程或內(nèi)存的數(shù)量）和將緩沖請求以保持低于限制使用的請求。由于服務(wù)無法跟上傳入請求的速度，隊(duì)列會變得越來越大，直到它突破了應(yīng)用程序定義的限制。為了解決這種情況，我們希望在不影響正常操作和保證可靠性的情況下，來限制隊(duì)列的大小。我們研究了一個很相似的bufferbloat，在保證可靠性的同時，使用隊(duì)列從而不會造成過度延遲。嘗試了一種codel1（延時）控制算法：

onNewRequest(req, queue):

if(queue.lastEmptyTime() < (now - N seconds)) {

timeout = M ms 

} else {

timeout = N seconds; 

}

queue.enqueue(req, timeout)

在該算法中，如果服務(wù)不能在最后N毫秒內(nèi)清空隊(duì)列，則隊(duì)列中花費(fèi)的時間僅限于M毫秒。如果服務(wù)能夠在最后N毫秒內(nèi)完成清空隊(duì)列，則隊(duì)列中所花費(fèi)的時間僅限于N毫秒。該算法避免站在隊(duì)列（由于lastEmptyTime將在遙遠(yuǎn)的過去,導(dǎo)致anM-ms排隊(duì)超時），一次達(dá)到短時間的排隊(duì)對于可靠性的目的。雖然它似乎有悖常理，請求時間較短，這個過程允許的迅速丟棄服務(wù)，而不是建立在系統(tǒng)無法跟上傳入請求的服務(wù)。短的超時可確保服務(wù)器總是處在工作的狀態(tài)，而不是空閑。

該算法的一個吸引人的特性是，M和N的值往往不需要調(diào)整。解決排隊(duì)問題的其他方法，如在隊(duì)列中設(shè)置項(xiàng)目的數(shù)量或設(shè)置隊(duì)列的超時時間的限制，需要在每個服務(wù)基礎(chǔ)上進(jìn)行調(diào)整。我們已經(jīng)發(fā)現(xiàn)，M和100毫秒的值是5毫秒，它可以很好的用于N中。Facebook的開源碼library5提供的算法是由thrift4框架實(shí)現(xiàn)。

自適應(yīng)后進(jìn)先出（后進(jìn)先出）

大多數(shù)服務(wù)進(jìn)程隊(duì)列FIFO（先進(jìn)先出）。當(dāng)處于高額度處理進(jìn)程中時，先進(jìn)命令明顯已經(jīng)運(yùn)行了很長時間，以至于用戶可能已經(jīng)中止了生成請求的操作。當(dāng)處理先進(jìn)申請命令時，相比之下這種剛剛抵達(dá)的請求命令，首先會消耗少許可能益于用戶的請求命令，服務(wù)進(jìn)程請求程序使用的是應(yīng)后進(jìn)先出的方式。在正常工作條件下，要求按照先進(jìn)先出的順序進(jìn)行處理，但是當(dāng)一個隊(duì)列正要開始成形時，服務(wù)器會切換為LIFO模式，這時，LIFO和CoDel就可以很好的結(jié)合在一起，如圖2所示。CoDel超時設(shè)置時，阻止長的計算機(jī)程序隊(duì)列增長，然后具有適應(yīng)性的先出后進(jìn)命令在計算機(jī)程序隊(duì)列設(shè)置新的請求模式，然后在數(shù)字信號編碼器的作用下，他們兩個能夠發(fā)揮最大化的作用。HHVM3，F(xiàn)acebook的PHP運(yùn)行時，自適應(yīng)后進(jìn)先出法的算法得以實(shí)現(xiàn)。

并發(fā)控制

無論是編碼和自適應(yīng)的后進(jìn)先出法都在服務(wù)器端運(yùn)行。服務(wù)器通常是執(zhí)行延遲的最好的措施——服務(wù)器更傾向于大量的客戶同時能夠擁有更多的客戶信息。然而，有些故障是如此嚴(yán)重，以至于服務(wù)器端控件無法啟動。為此，我們在客戶端實(shí)施一種權(quán)宜之計。每個客戶端會跟蹤每個服務(wù)器所未完成的出站請求數(shù)量。當(dāng)發(fā)送新請求時，如果對該服務(wù)的未執(zhí)行請求的數(shù)目超過可配置的數(shù)字，則該請求將立即標(biāo)記為錯誤。這種機(jī)制可防止單個服務(wù)壟斷其客戶端的資源。

以上內(nèi)容是數(shù)人云今天為大家?guī)淼摹癋acebook面對大規(guī)模系統(tǒng)工程故障排查實(shí)踐”的上半部分，其中主要涵蓋導(dǎo)致故障的原因、以及可以使用一個通用的系統(tǒng)等相關(guān)內(nèi)容，希望可以對大家有所幫助~明天還會為大家?guī)碜罱K的解決方案喲，敬請期待~

作者：Ben Maurer

原文：Fail at Scale Reliability in the face of rapid change

http://queue.acm.org/detail.c...