摘要：當(dāng)奧巴馬贏得美國(guó)總統(tǒng)大選時(shí)，頁(yè)面活躍度刷新了記錄。對(duì)于每一個(gè)成因，都應(yīng)制定相應(yīng)的預(yù)防措施，以減輕大規(guī)模事故。這種故障會(huì)通過(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é)整個(gè)Facebook面向用戶產(chǎn)品的性能和可靠性。Ben于2010年正式加入Facebook，基礎(chǔ)設(shè)施團(tuán)隊(duì)的成員。在加入Facebook之前，他與Luis von Ahn共同創(chuàng)立的驗(yàn)證碼。最近，本與美國(guó)數(shù)字服務(wù)公司合作，以改進(jìn)在聯(lián)邦政府的技術(shù)使用。

數(shù)人云今天為大家?guī)?lái)一篇Ben Maurer分享的“Facebook面對(duì)大規(guī)模系統(tǒng)工程故障排查實(shí)踐”，由于內(nèi)容較多，所以數(shù)人云今天只為大家?guī)?lái)上半部分，后續(xù)內(nèi)容會(huì)在明天發(fā)布！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

運(yùn)行一個(gè)Canary

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

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

保持良好的配置

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

使它容易恢復(fù)

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

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

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

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

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

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

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

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

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

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

控制延遲

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

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

該算法的一個(gè)吸引人的特性是，M和N的值往往不需要調(diào)整。解決排隊(duì)問題的其他方法，如在隊(duì)列中設(shè)置項(xiàng)目的數(shù)量或設(shè)置隊(duì)列的超時(shí)時(shí)間的限制，需要在每個(gè)服務(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)程中時(shí)，先進(jìn)命令明顯已經(jīng)運(yùn)行了很長(zhǎng)時(shí)間，以至于用戶可能已經(jīng)中止了生成請(qǐng)求的操作。當(dāng)處理先進(jìn)申請(qǐng)命令時(shí)，相比之下這種剛剛抵達(dá)的請(qǐng)求命令，首先會(huì)消耗少許可能益于用戶的請(qǐng)求命令，服務(wù)進(jìn)程請(qǐng)求程序使用的是應(yīng)后進(jìn)先出的方式。在正常工作條件下，要求按照先進(jìn)先出的順序進(jìn)行處理，但是當(dāng)一個(gè)隊(duì)列正要開始成形時(shí)，服務(wù)器會(huì)切換為L(zhǎng)IFO模式，這時(shí)，LIFO和CoDel就可以很好的結(jié)合在一起，如圖2所示。CoDel超時(shí)設(shè)置時(shí)，阻止長(zhǎng)的計(jì)算機(jī)程序隊(duì)列增長(zhǎng)，然后具有適應(yīng)性的先出后進(jìn)命令在計(jì)算機(jī)程序隊(duì)列設(shè)置新的請(qǐng)求模式，然后在數(shù)字信號(hào)編碼器的作用下，他們兩個(gè)能夠發(fā)揮最大化的作用。HHVM3，F(xiàn)acebook的PHP運(yùn)行時(shí)，自適應(yīng)后進(jìn)先出法的算法得以實(shí)現(xiàn)。

并發(fā)控制

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

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

作者：Ben Maurer

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

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