作者 | 馬超? ? ? ?責編 | 張紅月

出品 | CSDN

弱小從來不是生存的障礙，傲慢才是。10月4日 FaceBook 發生了一次史詩級中斷事故，故障期間 FaceBook 所有旗下APP全面對外服務中斷，而且故障的時間長達7個小時之久。根據 Facebook 最新的聲明來看，故障的原因是由于工程師錯誤地發出了一條指令，切斷了 Facebook 的數據中心“在全球范圍內的所有網絡連接”。

恰恰是這條簡單的指令，造成的影響卻是史詩級別的，本次宕機事故非常徹底，甚至Facebook自己的內網也完全報廢，無法訪問。筆者看到事件解決過程中不少運維方面的大牛都直接把故障的原因定位到了DNS和BGP方面。

從Cloudflare的博客中也能看到，問題的原因也確實出在了BGP指令方面，不過我們要問的是為什么這樣一條小小的指令會造成如此之大的影響。

route-views>show?ip?bgp?185.89.218.0/23 %?Network?not?in?table route-views>

上一次Facebook的全面中斷事件還要追溯到7年的2014年6月當時Facebook在APP更新版本時出現了一些問題，隨后就有一些用戶開始無法登陸Facebook，不過Facebook方面很快就找到了問題所在并進行了修復，并在半小時之內就讓服務100%恢復了正常。

這次史詩級故障也不是脆弱的BGP協議第一次出現問題，就在2020年1月23日，所有后綴為.net的域名也出現無法解析的情況，經DNS頂級根服務運營商ISC調查，發現.net域名缺失了關鍵的A記錄和AAAA記錄，所有.net后綴的互聯網地址從ISC的F根服務器全部消失了，接下來美國宇航局（NASA）運營的E根服務器也遇到了類似的問題。

那次故障中ISC定位問題的時間也很快，在5分鐘內就迅速將問題定位在他們與Cloudflare合作運營的節點上，后來Cloudflare很快查明原因是由于他們剛剛發布的變更代碼所造成的問題。但最終問題的解決也花了近兩個小時的時間，因為撤回導致該問題的BGP通告，出乎意料的長。

通過對比我們可以看到，本次Facebook的故障無論是從影響程度，還是故障時間上講都堪稱是負面教材的典型，而歷史一再告訴我們，只要能從歷史經驗中總結一點教訓就能避免悲劇的發生，因此復盤這次史詩級的故障，對于我們來說肯定也會是大有裨益。

什么是BGP協議

BGP邊界網關協議是EGP外部網關協議的一種， 顧名思義BGP處理外部網絡區域的之間路由信息的協議，其主要功能是與其他網絡自治區的BGP協議系統交換網絡路由信息。我們看到EGP相對的IGP內部網關協議，擁有眾多儲如RIP、OSPF、IS-IS、IGRP、EIGRP的協議族實現不同。EGP家族當中幾乎只有BGP這一根獨苗是可用的,BGP幾乎是唯一一個能夠處理獨立路由域間的多路連接的協議。

我們舉個例子來說明一下這個BGP協議，比如互聯網上有7個獨立的網絡自治區域AS (Autonomous System)，他們分別是AS1-AS7,這7個AS之間相互的物理連接情況用橙色線段表示如下：

那么如果AS1區域內的設備想要與AS7區域內的設備產生連接，那么具體的路由路徑應該選擇AS1-AS4-AS5-AS6-AS7的藍色路徑，還是選擇AS1-AS2-AS35-AS6-AS7的紅色路徑就是BGP協議要解決的核心問題，其實BGP之類的路由協議從宏觀層面來看都有點像旅游規劃，也就是可以把問題轉化為從AS1到AS7的道路中哪條道路最快。BGP協議通過一系列的報文，Internet發布其前綴路由信息，并維護一個有限狀態機，并以此來完成路由策略的收斂，但如果發布了錯誤的通告信息，那么就沒有人能夠知道如何連接這個錯誤區域了。當然本文不是要介紹BGP協議，這里各位讀者對于BGP的有關概念性有所認識就可以了。

事件處理故障復盤

正如Facebook公告所說，事故的一開始，Facebook已經停他們DNS前綴路由的BGP通告也就是說Facebook的DNS無法訪問，也就是說一條錯誤的指令讓Facebook整體下線了。

route-views>show ip bgp 129.134.30.0/23 % Network not in table route-views>

在故障期間通過dig、nslookup等命令解析Facebook的DNS域名全部返回SERVFAIL，而且正如我們上文介紹，如果發布了錯誤的BGP通告，那么沒有人能夠再從互聯網上找到你，這和人工破壞了Facebook數據中心的連向互聯網的光纖線路，從結果上看沒有任何本質區別。

根據CloudFlare的博客顯示，Facebook的故障差點把整個互聯網搞崩，因為Facebook用戶太多了，用戶在無法正常登陸APP時會瘋狂的發起重試，而且由于Facebook域名解析緩存已經在各級DNS服務器上全部失效了，這就給根DNS也就是1.1.1.1造成了巨大的壓力。據說這使1.1.1.1的DNS解析查詢的速度比平時高出30倍，所幸1.1.1.1頂住了壓力，Facebook故障期間絕大多數的DNS解析請求的返回速度都穩定在10毫秒左右，否則一旦根DNS也崩潰那么后果將不堪設想。

最終在7個小時之后，Facebook終端重新向互聯網通告了他們的路由，至此服務才最終恢復。

通過本次事件我們能學到了什么

以Facebook那些大牛人物的實力，從發現故障到定位故障原因的時間不會超過1分鐘，甚至很有可能在剛剛指行完那條錯誤的BGP通告命令之后就發現問題了，但是故障依舊持續了長達7個小時。再結合Facebook內網全部中斷的細節，那么我們可以推出隱藏在這背后的重要結論，那就是相關的錯誤命令把Facebook的VPN通道也全部影響了，我們知道Facebook目前在疫情的影響下，美國區的員工還處在遠程辦公的狀態，也就是說在錯誤指令生效之后，遠程運維工程師自身的VPN以及逃生通道也全部失效了，而數據中心現場值班的人員可能只會加電、重啟等簡單操作，甚至不排除現場人員連登陸到核心網絡設備的權限都沒有，一切都得指望遠程運維的人員到現場解決了。

假設自己不出現低級失誤，才是最大的低級錯誤：從上述分析中我們可以看出，Facebook的網絡工程師對于自身的能力太過自信了，以至于他們可能就沒有認真分析過回退方案的可行性，而故障發生之后才發現網絡設備已經無法通過遠程方式登陸了，回退方案執行的前提已經崩潰。因此在發布任何版本之前都要根據其造成的最大負面影響制訂預案，假定自身不會出現低級失誤的想法是絕對錯誤的。

逃生通道是最后生命線，必須嚴格保持獨立：從故障的時間上看，遠程登陸的逃生通道也一定是受到了影響，從這里我們能吸取到的教訓就是一定要在平時做好逃生通道的可用性驗證，并且要盡量保證逃生通道的獨立性，不能把逃生和日常運營的通道混為一談。

作者：馬超，CSDN博客專家，阿里云MVP、華為云MVP，華為2020年技術社區開發者之星。

往期推薦

“5G+AI”到底有啥用？

云原生時代，底層性能如何調優？

Redis很厲害，使用規范來啦

985大學的高材生只會寫代碼片段，丟人嗎？

點分享

點收藏

點點贊

點在看

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的一行指令造成 60 亿美元蒸发，更让 Facebook 遭遇史诗级故障！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。