TL;DR

Facebook 的路由配置出錯導(dǎo)致服務(wù)器下線，讓工程師不得不物理進入安全系數(shù)很高的服務(wù)器進行修復(fù)。

下面兩篇博客分別從內(nèi)部和外部視角對其進行了分析

Facebook 博客

原文：More details about the October 4 outage

在昨天的故障之后，我們的平臺已經(jīng)開始照常運行，我認為值得分享更多的細節(jié)，說明發(fā)生了什么，為什么，以及最重要的是，我們?nèi)绾螐闹袑W(xué)習(xí)。

這次中斷是由管理我們?nèi)蚬歉删W(wǎng)絡(luò)容量的系統(tǒng)引發(fā)的。骨干網(wǎng)是 Facebook 建立的網(wǎng)絡(luò)，將我們所有的計算設(shè)施連接在一起，它由數(shù)萬英里的光纖電纜組成，橫跨全球，連接我們所有的數(shù)據(jù)中心。

這些數(shù)據(jù)中心有不同的形式。有些是巨大的建筑物，容納了數(shù)以百萬計的機器，用于存儲數(shù)據(jù)和運行沉重的計算負載，以保持我們的平臺運行，其他的是較小的設(shè)施，將我們的骨干網(wǎng)絡(luò)連接到更廣泛的互聯(lián)網(wǎng)和使用我們平臺的人。

當(dāng)你打開我們的一個應(yīng)用程序并加載你的信息時，該應(yīng)用程序?qū)?shù)據(jù)的請求從你的設(shè)備到最近的設(shè)施，然后直接通過我們的骨干網(wǎng)絡(luò)與更大的數(shù)據(jù)中心進行通信。這就是你的應(yīng)用程序所需要的信息被檢索和處理的地方，并通過網(wǎng)絡(luò)發(fā)送回你的手機。

所有這些計算設(shè)施之間的數(shù)據(jù)流量是由路由器管理的，它負責(zé)計算所有傳入和傳出數(shù)據(jù)的發(fā)送位置。在維護這一基礎(chǔ)設(shè)施的大量日常工作中，我們的工程師經(jīng)常需要將骨干網(wǎng)的一部分脫機維護：也許是修復(fù)一條光纖線路，增加更多的容量，或者更新路由器本身的軟件。

這就是昨天故障的根源。在這些例行維護工作中，有一條命令被發(fā)出，目的是評估全球骨干網(wǎng)容量的可用性，這無意中關(guān)閉了我們骨干網(wǎng)的所有連接，并切斷了 Facebook 全球數(shù)據(jù)中心的連接。我們的系統(tǒng)被設(shè)計為審計這樣的命令，以防止這樣的錯誤，但該審計工具的一個錯誤使其無法正確地停止該命令。

這一變化導(dǎo)致我們的數(shù)據(jù)中心和互聯(lián)網(wǎng)之間的服務(wù)器連接完全斷開。而這種連接的完全喪失造成了第二個問題，使事情變得更糟。

我們的小型設(shè)施執(zhí)行的工作之一是響應(yīng) DNS 查詢。DNS 是互聯(lián)網(wǎng)的地址簿，使我們在瀏覽器中輸入的簡單網(wǎng)絡(luò)名稱能夠被翻譯成特定的服務(wù)器IP地址。這些翻譯查詢由我們的權(quán)威名稱服務(wù)器回答，這些服務(wù)器（dns 服務(wù)器）本身也擁有一個對應(yīng)的 IP 地址，而這些地址又通過另一個稱為邊界網(wǎng)關(guān)協(xié)議（BGP）的協(xié)議向互聯(lián)網(wǎng)的其他部分公布。

為了確?？煽康倪\行，如果我們的 DNS 服務(wù)器自己不能與我們的數(shù)據(jù)中心對話，就會禁用這些 BGP 廣播，因為這是網(wǎng)絡(luò)連接不健康的表現(xiàn)。在最近的故障中，整個骨干網(wǎng)被從運行中移除，（剛剛提到的策略）使這些地方（dns 服務(wù)器）宣布自己不健康，并撤回這些 BGP 廣播。最終的結(jié)果是，我們的DNS服務(wù)器變得遙不可及（不可路由），盡管它們?nèi)栽谶\行。這使得互聯(lián)網(wǎng)的其他部分無法找到我們的服務(wù)器。

所有這些都發(fā)生得非?？臁．?dāng)我們的工程師努力弄清楚發(fā)生了什么以及為什么發(fā)生時，他們面臨著兩個巨大的障礙：

• 首先，由于他們的網(wǎng)絡(luò)癱瘓，不可能通過我們的正常手段訪問我們的數(shù)據(jù)中心；
• 其次，DNS的完全喪失破壞了我們通常用來調(diào)查和解決這種故障的許多內(nèi)部工具。

我們的主要網(wǎng)絡(luò)和帶外管理網(wǎng)絡(luò)訪問被切斷，所以我們只能派工程師到數(shù)據(jù)中心現(xiàn)場，讓他們調(diào)試問題并重新啟動系統(tǒng)。但這需要時間，因為這些設(shè)施的設(shè)計考慮到了高水平的物理和系統(tǒng)安全。它們很難進入，而且一旦你進入，硬件和路由器的設(shè)計是很難修改的，即使你有物理訪問權(quán)。因此，我們需要額外的時間來激活所需的安全訪問協(xié)議，讓人們到現(xiàn)場并能夠在服務(wù)器上工作。只有這樣，我們才能確認問題，并使我們的主干網(wǎng)重新上線。

一旦我們的骨干網(wǎng)絡(luò)連接在我們的數(shù)據(jù)中心區(qū)域內(nèi)恢復(fù)，一切都會隨之恢復(fù)。但問題還沒有結(jié)束：我們知道，一下子恢復(fù)我們的服務(wù)可能會因為流量的激增而導(dǎo)致新一輪的崩潰。各個數(shù)據(jù)中心都報告說電力使用量下降了幾十兆瓦，而突然扭轉(zhuǎn)這種電力消耗的下降可能會使從電力系統(tǒng)處于危險之中。

幸運的是，由于我們已經(jīng)進行了很長時間的 "風(fēng)暴 "演習(xí)，我們對這一事件有充分的準(zhǔn)備。在風(fēng)暴演習(xí)中，我們通過關(guān)閉一個服務(wù)、數(shù)據(jù)中心或整個地區(qū)來模擬一個重大的系統(tǒng)故障，對所有涉及的基礎(chǔ)設(shè)施和軟件進行壓力測試。從這些演習(xí)中獲得的經(jīng)驗給了我們信心和經(jīng)驗，使事情重新上線并仔細管理不斷增加的負載。最后，我們的服務(wù)很快就恢復(fù)了，沒有再出現(xiàn)任何系統(tǒng)性的故障。雖然我們以前從未進行過模擬我們的全球骨干網(wǎng)被切斷的風(fēng)暴，但我們肯定會尋找方法來模擬這樣的事件，并繼續(xù)前進。

每一次這樣的失敗都是一個學(xué)習(xí)和改進的機會，我們可以從這一次學(xué)到很多東西。在每個問題之后，無論大小，我們都會做一個廣泛的審查過程，以了解我們?nèi)绾问刮覀兊南到y(tǒng)更有彈性。這個過程已經(jīng)在進行了。

我們已經(jīng)做了大量的工作來加固我們的系統(tǒng)（安全措施），以防止未經(jīng)授權(quán)的訪問，有趣的是，當(dāng)我們試圖從不是由惡意活動，而是由我們自己造成的錯誤引起的故障中恢復(fù)時，這種加固卻減緩我們的速度。我相信這樣的權(quán)衡是值得的：大大提高了日常的安全性，但是卻在這樣一個罕見的事件中恢復(fù)得很慢。從現(xiàn)在開始，我們的工作是加強我們的測試、演習(xí)和整體復(fù)原力，以確保像這樣的事件盡可能少發(fā)生。

Cloudflare 博客

原文：Understanding How Facebook Disappeared from the Internet

"Facebook不可能癱瘓，對嗎？"，我們想了一會兒。

今天（2021/10/05） 15:51 UTC，我們提了一個題為 "Facebook DNS查詢返回SERVFAIL "的內(nèi)部事件，因為我們擔(dān)心我們的DNS解析器1.1.1.1有問題。 但當(dāng)我們準(zhǔn)備在我們的公共狀態(tài)頁面上發(fā)布時，我們意識到發(fā)生了其他更嚴重的事情。

社交媒體迅速爆發(fā)，報道了我們的工程師也迅速確認的情況。事實上，F(xiàn)acebook及其附屬服務(wù) WhatsApp 和 Instagram 都已癱瘓。他們的 DNS 服務(wù)器停止解析，他們的基礎(chǔ)設(shè)施IP也無法訪問。這就像有人一下子從他們的數(shù)據(jù)中心 "拔掉了電纜"，并將他們與互聯(lián)網(wǎng)斷開。

這本身并不是一個DNS問題，但DNS故障是我們看到的Facebook較大的故障的第一個癥狀。

這怎么可能呢？

Facebook的更新

Facebook 現(xiàn)在發(fā)表了一篇博文，介紹了內(nèi)部發(fā)生的一些細節(jié)。在外部，我們看到了這篇文章中概述的 BGP 和 DNS 問題，但問題實際上始于一個影響整個內(nèi)部骨干網(wǎng)的配置變化。這導(dǎo)致了 Facebook 和其他設(shè)施的消失，而 Facebook 內(nèi)部的員工也很難再獲得服務(wù)（主要是 dns 的原因）。

臉書又發(fā)表了一篇博文（上文的翻譯），對發(fā)生的事情做了更詳細的說明。你可以閱讀那篇關(guān)于內(nèi)部情況的文章，以及這篇關(guān)于外部情況的文章。

現(xiàn)在來看看我們從外部看到的情況。

認識 BGP

BGP 是邊界網(wǎng)關(guān)協(xié)議的縮寫。它是一種在互聯(lián)網(wǎng)上的自治系統(tǒng)（AS）之間交換路由信息的機制。使互聯(lián)網(wǎng)運轉(zhuǎn)的大型路由器擁有龐大的、不斷更新的可能路由列表，這些路由可以用來將每個網(wǎng)絡(luò)數(shù)據(jù)包送到它們的最終目的地。沒有BGP，互聯(lián)網(wǎng)路由器就不知道該怎么做，互聯(lián)網(wǎng)也就無法運行。

互聯(lián)網(wǎng)實際上是一個網(wǎng)絡(luò)的網(wǎng)絡(luò)，它是由BGP捆綁在一起的。BGP允許一個網(wǎng)絡(luò)（例如Facebook）向構(gòu)成互聯(lián)網(wǎng)的其他網(wǎng)絡(luò)廣播其存在。當(dāng)我們寫到 Facebook 沒有廣播它的存在時，ISP 和其他網(wǎng)絡(luò)就找不到 Facebook 的網(wǎng)絡(luò)，因此它就不可用。

各個網(wǎng)絡(luò)都有一個ASN：一個自治系統(tǒng)號碼。一個自治系統(tǒng)（AS）是一個具有統(tǒng)一的內(nèi)部路由策略的單獨網(wǎng)絡(luò)。一個AS可以發(fā)起前綴（說他們控制著一組 IP 地址），以及過境前綴（說他們知道如何到達特定的 IP 地址組）。

Cloudflare 的 ASN 是AS13335。每個 ASN 都需要使用 BGP 向互聯(lián)網(wǎng)宣布其前綴路由；否則，沒有人會知道如何連接以及在哪里找到我們。

在這個簡化圖中，你可以看到互聯(lián)網(wǎng)上的六個自治系統(tǒng)，以及一個數(shù)據(jù)包從起點到終點可能使用的兩條路線。AS1→AS2→AS3 是最快的，AS1→AS6→AS5→AS4→AS3 是最慢的，但如果第一條失敗，也可以使用。

在 15:58 UTC，我們注意到，F(xiàn)acebook 已經(jīng)停止宣布他們的 DNS 前綴的路由。這意味著，至少，F(xiàn)acebook 的 DNS 服務(wù)器是不可用的。正因為如此，Cloudflare的1.1.1.1 DNS解析器無法再響應(yīng)查詢 facebook.com 的IP地址。

route-views>show ip bgp 185.89.218.0/23% Network not in tableroute-views>route-views>show ip bgp 129.134.30.0/23% Network not in tableroute-views>同時，其他的 Facebook IP 地址仍在路由中，但沒有任何作用，因為沒有DNS，F(xiàn)acebook 和相關(guān)服務(wù)實際上是不可用的。

route-views>show ip bgp 129.134.30.0 BGP routing table entry for 129.134.0.0/17, version 1025798334Paths: (24 available, best #14, table default) Not advertised to any peer Refresh Epoch 2 3303 6453 32934 217.192.89.50 from 217.192.89.50 (138.187.128.158) Origin IGP, localpref 100, valid, external Community: 3303:1004 3303:1006 3303:3075 6453:3000 6453:3400 6453:3402 path 7FE1408ED9C8 RPKI State not found rx pathid: 0, tx pathid: 0 Refresh Epoch 1route-views>我們跟蹤我們在全球網(wǎng)絡(luò)中看到的所有BGP更新和公告。在我們的規(guī)模下，我們收集的數(shù)據(jù)讓我們看到了互聯(lián)網(wǎng)是如何連接的，以及流量要從哪里流向地球上的各個地方。

BGP UPDATE 消息通知路由器你對前綴廣播所做的任何改變。在檢查我們的時間序列數(shù)據(jù)庫時，我們可以清楚地看到從 Facebook 收到的更新數(shù)量。通常情況下，這個圖表是相當(dāng)安靜的：Facebook 不會每分鐘對其網(wǎng)絡(luò)進行大量的更改。

但在UTC時間15:40左右，我們看到 Facebook 的路由變化達到了一個高峰。這就是麻煩開始的時候。

如果我們把這個觀點按照路由的 announcements 和撤銷 withdrawals 來劃分，我們就能更好地了解發(fā)生了什么。路由被 withdrawals，F(xiàn)acebook 的 DNS 服務(wù)器下線。

隨著這些 withdrawals，F(xiàn)acebook及其網(wǎng)站實際上已經(jīng)與互聯(lián)網(wǎng)斷開了聯(lián)系。

DNS 受到影響

作為這一事件的直接后果，世界各地的DNS解析器停止了對其域名的解析。

? ~ dig @1.1.1.1 facebook.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322;facebook.com. IN A? ~ dig @1.1.1.1 whatsapp.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322;whatsapp.com. IN A? ~ dig @8.8.8.8 facebook.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322;facebook.com. IN A? ~ dig @8.8.8.8 whatsapp.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322;whatsapp.com. IN A發(fā)生這種情況是因為DNS，像互聯(lián)網(wǎng)上的許多其他系統(tǒng)一樣，也有其路由機制。當(dāng)有人在瀏覽器中鍵入https://facebook.com URL時，負責(zé)將域名翻譯成實際IP地址進行連接的DNS解析器，首先檢查它的緩存中是否有東西并使用它。如果沒有，它就試圖從域名服務(wù)器中獲取答案，通常由擁有該域名的實體托管。

如果域名服務(wù)器無法到達，或者由于其他原因而無法響應(yīng)，那么就會返回一個SERVFAIL，瀏覽器就會向用戶發(fā)出一個錯誤。

由于Facebook停止通過BGP宣布他們的DNS前綴路由，我們和其他人的DNS解析器沒有辦法連接到他們的名字服務(wù)器。因此，1.1.1.1、8.8.8.8和其他主要的公共DNS解析器開始發(fā)出（和緩存）SERVFAIL響應(yīng)。

但這還不是全部。現(xiàn)在，人類行為和應(yīng)用邏輯開始發(fā)揮作用，導(dǎo)致另一個指數(shù)效應(yīng)。一場額外的 DNS 流量的海嘯隨之而來。

發(fā)生這種情況的原因是

• 應(yīng)用程序不接受一個錯誤的答案，并開始重試。
• 用戶也不接受一個錯誤的答案，并開始重新加載頁面，或殺死和重新啟動他們的應(yīng)用程序。

因此，現(xiàn)在，由于 Facebook 和他們的網(wǎng)站是如此之大，我們的DNS解析器在全球范圍內(nèi)處理比平時多30倍的查詢，并可能對其他平臺造成延遲和超時問題。

我們絕大部分的DNS請求都能在10毫秒內(nèi)得到解決。同時，p95和p99百分位數(shù)的最小部分的響應(yīng)時間增加了，可能是由于 TTL 過期不得不請求不存在的 Facebook 的 dns 服務(wù)器而導(dǎo)致的超時。10秒的DNS超時限制在工程師中是眾所周知的。

影響到其他服務(wù)

人們尋找替代方案，想知道更多或討論發(fā)生了什么。當(dāng) Facebook 變得無法訪問時，我們開始看到對 Twitter、Signal 和其他消息和社交媒體平臺的 DNS 查詢增加。

我們還可以從 Facebook 受影響的 ASN 32934 的 WARP 流量中看到這種不可達性的另一個副作用。這張圖顯示了每個國家從15:45 UTC到16:45 UTC的流量與三小時前相比的變化。在世界各地，進出 Facebook 網(wǎng)絡(luò)的 WARP 流量完全消失了。

互聯(lián)網(wǎng)

今天的事件溫和地提醒我們，互聯(lián)網(wǎng)是一個非常復(fù)雜和相互依賴的系統(tǒng)，由數(shù)百萬個系統(tǒng)和協(xié)議共同工作。信任、標(biāo)準(zhǔn)化和實體間的合作是使其為全球近50億活躍用戶工作的核心。

更新

在21:00 UTC左右，我們看到來自Facebook網(wǎng)絡(luò)的BGP活動再次出現(xiàn)，并在21:17 UTC達到頂峰。

該圖表顯示了 "facebook.com "在Cloudflare 的 DNS解析器1.1.1.1上的可用性。它在15:50 UTC左右停止可用，并在21:20 UTC恢復(fù)。

毫無疑問，F(xiàn)acebook、WhatsApp和Instagram的服務(wù)將需要進一步的時間才能上線，但截至UTC時間21:28，F(xiàn)acebook似乎已經(jīng)重新連接到全球互聯(lián)網(wǎng)，DNS也重新工作。