Facebook公司在10月4日晚間發表了一份簡短聲明，主要是為了反駁在社交媒體上傳播的陰謀論。隨后在10月5日公布了導致業務宕機的更多細節。
該公司發表的一篇博客文章基本證實了人們已經知道的事情，正如Cloudflare所詳述的那樣：Facebook公司以某種方式設法阻斷從外部互聯網到運行Facebook、Instagram、WhatsApp和其他屬性的服務器的途徑，并進行了例行維護。
Facebook公司運營著龐大的網絡設施，其中包括自己的數據中心以及分散在世界各地的名稱為“存在點”的小型數據中心設施，用于收集入站流量，并通過Facebook公司的專用網絡將這些數據引導至最終目的地。
服務器和網絡設備由于各種原因容易出現故障，檢查網絡上是否有任何故障是工程人員日常工作的一部分。但在10月4日早上，例行檢查以某種方式執行，并作為命令將Facebook的所有連接從其骨干網絡撤回。
該公司在其發表的一篇帖子中表示，本應檢測配置更改中潛在的災難性錯誤的審計工具失效，因為該審計工具中的一個錯誤使其無法終止發布的命令。
Facebook公司運營的基礎設施選擇使問題更加復雜，而很久以前就其內部設施做出的決定使得從這個錯誤中恢復比其他公司要困難得多。
Facebook公司幾乎完全依賴自己的基礎設施和定制服務來滿足其運營所需的幾乎所有需求，相比之下，其他規模和資源相同的科技公司至少在部分使用第三方提供商提供的基礎設施來滿足需求。
這其中包括DNS服務器，它們運行在那些規模較小的接入點設施中。這些服務器告訴Facebook公司的數據中心對其內容的傳入請求來自何處，并為請求“facebook.com”的瀏覽器提供一條通往該目的地的計算機的途徑。
Facebook公司的DNS服務器的設計旨在告知對“facebook.com”的入站請求，如果它們檢測到該路徑有問題，則避開通往數據中心的特定路徑，因為長時間的延遲都會導致糟糕的用戶體驗。在正常情況下，工作路徑比故障路徑多得多，而且很容易找到快速繞行的路徑。
然而，當所有這些路徑都消失時，那些以其他方式運行的DNS服務器不知道Facebook的服務器在哪里，迫使它們向手機和瀏覽器返回錯誤消息。
讓事情變得更加困難的是，Facebook公司的內部通信和災難恢復工具依賴于與容納這些DNS服務器的設施的連接。
到目前為止所描述的一切都發生在10月4日早上大約兩分鐘的時間里。重要的是Facebook公司需要快速恢復這個網絡規模的錯誤，而這種恢復比以往更加艱難。而不知什么原因，Facebook與其服務器的帶外連接(當主要網絡出現故障時的正常備份計劃)也失敗了。這意味著需要物理訪問其數據中心設施才能解決問題。
雖然Facebook公司實際上并不需要修改其服務器框架來解決問題，但確保允許具有專業人員進入最近的數據中心并處理相關服務器故障所花費的時間比人們想像的要多。
每一次宕機都是一次學習的機會，即使對于像Facebook公司這樣似乎不愿意從其他領域的錯誤中吸取教訓的公司也是如此。以下是從這件事可以學到的三個經驗和教訓：
•做好最壞的打算。企業需要制定針對計算資源或網絡連接完全丟失的應急計劃，而不僅僅是數據中心或云計算區域發生故障。
•采用多個服務商的服務。雖然互聯網整體癱瘓的可能性極小，但采用多個云計算服務提供商的云計算服務是值得的。
•檢查優先事項。如果沒有采用大量的自動化技術，就無法實施Facebook公司那樣大規模的操作，這意味著代碼審計工具(例如未能阻止此次中斷的工具)需要額外關注。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號