TL;DR

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

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

Facebook 博客

原文：More details about the October 4 outage

在昨天的故障之后，我們的平臺已經開始照常運行，我認為值得分享更多的細節，說明發生了什么，為什么，以及最重要的是，我們如何從中學習。

這次中斷是由管理我們全球骨干網絡容量的系統引發的。骨干網是 Facebook 建立的網絡，將我們所有的計算設施連接在一起，它由數萬英里的光纖電纜組成，橫跨全球，連接我們所有的數據中心。

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

當你打開我們的一個應用程序并加載你的信息時，該應用程序對數據的請求從你的設備到最近的設施，然后直接通過我們的骨干網絡與更大的數據中心進行通信。這就是你的應用程序所需要的信息被檢索和處理的地方，并通過網絡發送回你的手機。

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

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

這一變化導致我們的數據中心和互聯網之間的服務器連接完全斷開。而這種連接的完全喪失造成了第二個問題，使事情變得更糟。

我們的小型設施執行的工作之一是響應 DNS 查詢。DNS 是互聯網的地址簿，使我們在瀏覽器中輸入的簡單網絡名稱能夠被翻譯成特定的服務器IP地址。這些翻譯查詢由我們的權威名稱服務器回答，這些服務器（dns 服務器）本身也擁有一個對應的 IP 地址，而這些地址又通過另一個稱為邊界網關協議（BGP）的協議向互聯網的其他部分公布。

為了確保可靠的運行，如果我們的 DNS 服務器自己不能與我們的數據中心對話，就會禁用這些 BGP 廣播，因為這是網絡連接不健康的表現。在最近的故障中，整個骨干網被從運行中移除，（剛剛提到的策略）使這些地方（dns 服務器）宣布自己不健康，并撤回這些 BGP 廣播。最終的結果是，我們的DNS服務器變得遙不可及（不可路由），盡管它們仍在運行。這使得互聯網的其他部分無法找到我們的服務器。

所有這些都發生得非常快。當我們的工程師努力弄清楚發生了什么以及為什么發生時，他們面臨著兩個巨大的障礙：

• 首先，由于他們的網絡癱瘓，不可能通過我們的正常手段訪問我們的數據中心；
• 其次，DNS的完全喪失破壞了我們通常用來調查和解決這種故障的許多內部工具。

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

一旦我們的骨干網絡連接在我們的數據中心區域內恢復，一切都會隨之恢復。但問題還沒有結束：我們知道，一下子恢復我們的服務可能會因為流量的激增而導致新一輪的崩潰。各個數據中心都報告說電力使用量下降了幾十兆瓦，而突然扭轉這種電力消耗的下降可能會使從電力系統處于危險之中。

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

每一次這樣的失敗都是一個學習和改進的機會，我們可以從這一次學到很多東西。在每個問題之后，無論大小，我們都會做一個廣泛的審查過程，以了解我們如何使我們的系統更有彈性。這個過程已經在進行了。

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

Cloudflare 博客

原文：Understanding How Facebook Disappeared from the Internet

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

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

社交媒體迅速爆發，報道了我們的工程師也迅速確認的情況。事實上，Facebook及其附屬服務 WhatsApp 和 Instagram 都已癱瘓。他們的 DNS 服務器停止解析，他們的基礎設施IP也無法訪問。這就像有人一下子從他們的數據中心 "拔掉了電纜"，并將他們與互聯網斷開。

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

這怎么可能呢？

Facebook的更新

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

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

現在來看看我們從外部看到的情況。

認識 BGP

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

互聯網實際上是一個網絡的網絡，它是由BGP捆綁在一起的。BGP允許一個網絡（例如Facebook）向構成互聯網的其他網絡廣播其存在。當我們寫到 Facebook 沒有廣播它的存在時，ISP 和其他網絡就找不到 Facebook 的網絡，因此它就不可用。

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

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

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

在 15:58 UTC，我們注意到，Facebook 已經停止宣布他們的 DNS 前綴的路由。這意味著，至少，Facebook 的 DNS 服務器是不可用的。正因為如此，Cloudflare的1.1.1.1 DNS解析器無法再響應查詢 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，Facebook 和相關服務實際上是不可用的。

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>我們跟蹤我們在全球網絡中看到的所有BGP更新和公告。在我們的規模下，我們收集的數據讓我們看到了互聯網是如何連接的，以及流量要從哪里流向地球上的各個地方。

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

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

如果我們把這個觀點按照路由的 announcements 和撤銷 withdrawals 來劃分，我們就能更好地了解發生了什么。路由被 withdrawals，Facebook 的 DNS 服務器下線。

隨著這些 withdrawals，Facebook及其網站實際上已經與互聯網斷開了聯系。

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發生這種情況是因為DNS，像互聯網上的許多其他系統一樣，也有其路由機制。當有人在瀏覽器中鍵入https://facebook.com URL時，負責將域名翻譯成實際IP地址進行連接的DNS解析器，首先檢查它的緩存中是否有東西并使用它。如果沒有，它就試圖從域名服務器中獲取答案，通常由擁有該域名的實體托管。

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

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

但這還不是全部。現在，人類行為和應用邏輯開始發揮作用，導致另一個指數效應。一場額外的 DNS 流量的海嘯隨之而來。

發生這種情況的原因是

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

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

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

影響到其他服務

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

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

互聯網

今天的事件溫和地提醒我們，互聯網是一個非常復雜和相互依賴的系統，由數百萬個系統和協議共同工作。信任、標準化和實體間的合作是使其為全球近50億活躍用戶工作的核心。

更新

在21:00 UTC左右，我們看到來自Facebook網絡的BGP活動再次出現，并在21:17 UTC達到頂峰。

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

毫無疑問，Facebook、WhatsApp和Instagram的服務將需要進一步的時間才能上線，但截至UTC時間21:28，Facebook似乎已經重新連接到全球互聯網，DNS也重新工作。