據(jù)報(bào)道，F(xiàn)acebook公司的主要業(yè)務(wù)在10月4日(星期一)發(fā)生嚴(yán)重的中斷事件。此次大規(guī)模宕機(jī)對(duì)于負(fù)責(zé)構(gòu)建和維護(hù)其技術(shù)和應(yīng)用的人員來(lái)說(shuō)是難以應(yīng)對(duì)的。雖然宕機(jī)事件對(duì)于Facebook公司并不是新鮮事，但此次中斷肯定是載入該公司史冊(cè)的一次宕機(jī)事件。

[[428032]]

Facebook公司在10月4日晚間發(fā)表了一份簡(jiǎn)短聲明，主要是為了反駁在社交媒體上傳播的陰謀論。隨后在10月5日公布了導(dǎo)致業(yè)務(wù)宕機(jī)的更多細(xì)節(jié)。

該公司發(fā)表的一篇博客文章基本證實(shí)了人們已經(jīng)知道的事情，正如Cloudflare所詳述的那樣：Facebook公司以某種方式設(shè)法阻斷從外部互聯(lián)網(wǎng)到運(yùn)行Facebook、Instagram、WhatsApp和其他屬性的服務(wù)器的途徑，并進(jìn)行了例行維護(hù)。

Facebook公司運(yùn)營(yíng)著龐大的網(wǎng)絡(luò)設(shè)施，其中包括自己的數(shù)據(jù)中心以及分散在世界各地的名稱為“存在點(diǎn)”的小型數(shù)據(jù)中心設(shè)施，用于收集入站流量，并通過(guò)Facebook公司的專用網(wǎng)絡(luò)將這些數(shù)據(jù)引導(dǎo)至最終目的地。

服務(wù)器和網(wǎng)絡(luò)設(shè)備由于各種原因容易出現(xiàn)故障，檢查網(wǎng)絡(luò)上是否有任何故障是工程人員日常工作的一部分。但在10月4日早上，例行檢查以某種方式執(zhí)行，并作為命令將Facebook的所有連接從其骨干網(wǎng)絡(luò)撤回。

該公司在其發(fā)表的一篇帖子中表示，本應(yīng)檢測(cè)配置更改中潛在的災(zāi)難性錯(cuò)誤的審計(jì)工具失效，因?yàn)樵搶徲?jì)工具中的一個(gè)錯(cuò)誤使其無(wú)法終止發(fā)布的命令。

Facebook公司運(yùn)營(yíng)的基礎(chǔ)設(shè)施選擇使問(wèn)題更加復(fù)雜，而很久以前就其內(nèi)部設(shè)施做出的決定使得從這個(gè)錯(cuò)誤中恢復(fù)比其他公司要困難得多。

Facebook公司幾乎完全依賴自己的基礎(chǔ)設(shè)施和定制服務(wù)來(lái)滿足其運(yùn)營(yíng)所需的幾乎所有需求，相比之下，其他規(guī)模和資源相同的科技公司至少在部分使用第三方提供商提供的基礎(chǔ)設(shè)施來(lái)滿足需求。

這其中包括DNS服務(wù)器，它們運(yùn)行在那些規(guī)模較小的接入點(diǎn)設(shè)施中。這些服務(wù)器告訴Facebook公司的數(shù)據(jù)中心對(duì)其內(nèi)容的傳入請(qǐng)求來(lái)自何處，并為請(qǐng)求“facebook.com”的瀏覽器提供一條通往該目的地的計(jì)算機(jī)的途徑。

Facebook公司的DNS服務(wù)器的設(shè)計(jì)旨在告知對(duì)“facebook.com”的入站請(qǐng)求，如果它們檢測(cè)到該路徑有問(wèn)題，則避開(kāi)通往數(shù)據(jù)中心的特定路徑，因?yàn)殚L(zhǎng)時(shí)間的延遲都會(huì)導(dǎo)致糟糕的用戶體驗(yàn)。在正常情況下，工作路徑比故障路徑多得多，而且很容易找到快速繞行的路徑。

然而，當(dāng)所有這些路徑都消失時(shí)，那些以其他方式運(yùn)行的DNS服務(wù)器不知道Facebook的服務(wù)器在哪里，迫使它們向手機(jī)和瀏覽器返回錯(cuò)誤消息。

讓事情變得更加困難的是，F(xiàn)acebook公司的內(nèi)部通信和災(zāi)難恢復(fù)工具依賴于與容納這些DNS服務(wù)器的設(shè)施的連接。

到目前為止所描述的一切都發(fā)生在10月4日早上大約兩分鐘的時(shí)間里。重要的是Facebook公司需要快速恢復(fù)這個(gè)網(wǎng)絡(luò)規(guī)模的錯(cuò)誤，而這種恢復(fù)比以往更加艱難。而不知什么原因，F(xiàn)acebook與其服務(wù)器的帶外連接(當(dāng)主要網(wǎng)絡(luò)出現(xiàn)故障時(shí)的正常備份計(jì)劃)也失敗了。這意味著需要物理訪問(wèn)其數(shù)據(jù)中心設(shè)施才能解決問(wèn)題。

雖然Facebook公司實(shí)際上并不需要修改其服務(wù)器框架來(lái)解決問(wèn)題，但確保允許具有專業(yè)人員進(jìn)入最近的數(shù)據(jù)中心并處理相關(guān)服務(wù)器故障所花費(fèi)的時(shí)間比人們想像的要多。

每一次宕機(jī)都是一次學(xué)習(xí)的機(jī)會(huì)，即使對(duì)于像Facebook公司這樣似乎不愿意從其他領(lǐng)域的錯(cuò)誤中吸取教訓(xùn)的公司也是如此。以下是從這件事可以學(xué)到的三個(gè)經(jīng)驗(yàn)和教訓(xùn)：

• 做好最壞的打算。企業(yè)需要制定針對(duì)計(jì)算資源或網(wǎng)絡(luò)連接完全丟失的應(yīng)急計(jì)劃，而不僅僅是數(shù)據(jù)中心或云計(jì)算區(qū)域發(fā)生故障。

• 采用多個(gè)服務(wù)商的服務(wù)。雖然互聯(lián)網(wǎng)整體癱瘓的可能性極小，但采用多個(gè)云計(jì)算服務(wù)提供商的云計(jì)算服務(wù)注是值得的。

• 檢查優(yōu)先事項(xiàng)。如果沒(méi)有采用大量的自動(dòng)化技術(shù)，就無(wú)法實(shí)施Facebook公司那樣大規(guī)模的操作，這意味著代碼審計(jì)工具(例如未能阻止此次中斷的工具)需要額外關(guān)注。