臉書全球大當機背後發生的事

10/4 臉書發生了近幾年來規模最大、持續最久的當機事件，臉書旗下的各種服務包含 Facebook、Messenger、Instagram 以及 WhatsApp 全掛，而且持續了五個半小時才陸續恢復，第一時間 Cloudflare 發表了一篇文章從外部視角來看為什麼臉書從網路上消失了，後來從大當機恢復以後臉書也在他們的 Engineering blog 解釋當機發生的原因，讓我們一起來從內部以及外部視角來看看昨天究竟發生了什麼事吧！

外部視角

讓我們先從外部視角切入，當你打開臉書 App 時，App 會嘗試跟臉書的伺服器建立連線，而建立的連線很重要的一步是要把 facebook.com 轉成 IP 位址，這個轉換的過程是利用 DNS (Domain Name System) 這套系統，DNS 是一個分散式的資料庫，把人可以看得懂的網址轉換成實際連線時需要的 IP 位址，在當機期間查詢 Facebook DNS 時回傳的是 SERVFAIL，無法正確解析出伺服器的 IP 位址，因此 App 連不上臉書的伺服器。對 DNS 有興趣的話可以回去聽 Podcast 的 EP20，有深入淺出白話文的講解。

但 DNS 只是症狀，真正的問題是來自 BGP 這個協議，BGP (Border Gateway Protocol) 可以讓網路上不同的子網路互相溝通交換路由資訊，有了路由資訊網路才知道怎麼把資料從 A 點送到 B 點，你可以把 BGP 想像成是網路的郵政服務，有了郵政系統郵差才知道怎麼把信件寄到對的位址。昨天臉書因為內部的問題，停止發送了 BGP advertisement，這等於是跟世界宣佈：「我不知道怎麼處理 facebook.com 的請求」，造成臉書 DNS 伺服器離線，網路連不到 DNS 伺服器自然就沒有辦法找到臉書的 IP 位址，導致了大當機。

內部視角

這一切是怎麼發生的呢？臉書的基礎設施全部都是自己維護的，並沒有使用 AWS 之類的雲端服務，所以他們有自己的資料中心、自己的 DNS 伺服器以及大大小小的網路硬體設施路由器等等，也因此他們需要例行性去維護骨幹網路 (backbone network)，讓骨幹網路離線、更新路由器的軟體以及修復光纖等等。這就是昨天事件發生的起點，在維護的過程中工程師發送了一個 command 意外地切斷了所有骨幹網路的連線，造成了所有的資料中心從網路離線，資料中心之間也無法溝通，本來內部有監控工具專門偵測並且阻止這類型的 command，但是監控工具有 bug 所以並沒有阻止成功。由於臉書的 DNS 伺服器連不到資料中心，它停止發送 BGP advertisement，最後造成 DNS 伺服器離線。

更慘的是，DNS 離線也讓很多內部的工具失效，讓 debug 難上加難，在這種情況下，理論上會使用另外一種 out-of-band 的方式來連到內網，這樣即使在 DNS 失效的情況下還可以持續 debug，但是當下這個系統也出現了問題，所以他們只好派出工程師實際到資料中心 debug 並且重啟整個系統，所以整個修復時間才會拉到這麼長。這也體現了內部疏於練習 out-of-band 系統，讓本來應該在這種情況下發揮效用的工具沒有派上用場

我知道這很複雜，所以讓我再重新總結一下這個當機事件：臉書自己維護基礎設施 → 定期維護骨幹網路 → 意外發送了一個 command 切斷了所有骨幹網路的連線 → 監控並且應該阻止這個 command 的工具有 bug 沒有發揮效用 → DNS 伺服器連不到資料中心 → 不再發送 BGP advertisement → DNS 伺服器離線 → DNS 失效無法把 facebook.com 轉成 IP 位址 → Facebook、Messenger、Instagram 以及 WhatsApp 全掛

而在修復過程中內部工具失效、out-of-band 存取的工具本該派上用場卻壞掉了 → 只好派出工程師到資料中心現場 debug → 導致拖了五個半小時才陸續恢復

不咎責的事後檢討文化

每次這類型的重大事件總是會有一連串的不幸運加上人為疏失，如果監控軟體沒有 bug 是不是就可以第一時間阻止有問題的 command？如果 DNS 伺服器有考慮到這個狀況，是不是可以不要那麼快停止 BGP advertisement？如果平常有練習 out-of-band 是不是可以更快修復？

這類型的重大事件往往是公司內部反省的一個好機會，事後檢討也應該著重在如何改善流程避免類似的事件發生，絕對不是抓戰犯，如果因為一個人就可以影響整間公司把系統搞掛，那這個公司實在是太脆弱了，所以應該改進的是整間公司的流程而不是個人，這也是我之前在 Square 的經驗學到的。