[[427699]]

最近Facebook發(fā)生史上最嚴重的宕機事件，導致其全球網絡宕機6個多小時。

按道理，F(xiàn)acebook這種體量的公司，應該有一套完整的應急預案，不會出現(xiàn)長時間的宕機才對?？墒?，一連串狗血劇情的發(fā)生，讓Facebook不得不接受這個事實。

首先是程序員敲錯了一個命令，系統(tǒng)在審計命令的時候，應該不放行。巧的是，審計工具有bug，竟然放行了這條命令。

更要命的是，因為數據中心的安全設計，駐場工程師無法接觸到服務器，只得“溜門撬鎖”，費勁千辛萬苦才修復完成。

修復完一上線又崩了一次，第二次才完全修復完畢，整個過程耗費整整6個小時，堪稱史詩級災難大片。

事件經過

一切都要從日常維護中的一條錯誤命令說起。

在日常維護基礎設施時，工程師需要離線維護部分主干網，例如修理一條光纖線路、增加更多容量或者更新路由器本身的軟件等等。

10月初，出于這一需要，工程師需使用一條命令，以評估網絡狀態(tài)，然而卻誤敲成清空路由表的命令。

按道理，審計工具應該攔截這條異常命令，結果因為工具本身的bug，這一條命令被放行。

在Facebook的系統(tǒng)設計中，F(xiàn)acebook所有域名服務器，會在服務器連接不上數據中心對應IP的情況下，停止DNS解析。這一設計的目的是如果IP不可達，那么網絡存在問題，解析出來也沒有太大的意義。這樣一來，用戶的請求仍然可以解析到其他IP上。

但是這一騷操作，直接將Facebook整套自有域名服務器癱瘓掉，即便其他服務器都沒有問題，沒有DNS指路，業(yè)務也無法順利進行。

基礎架構翻車、溝通協(xié)調不暢以及遠程排除故障困難，是導致Facebook宕機6小時的主要原因。

另外一個原因有點讓人哭笑不得。

數據中心有各式各樣的安全設計，以防止數據盜竊以及其他安全事件的發(fā)生。然而因為這些設計上的問題，導致當天駐場工程師，無法第一時間接觸到服務器，不得不強制清除一些“物理”障礙，修復時間一再推遲。

因為修復策略是一臺一臺恢復，導致先上線的少量服務器，無法頂住已經存在的巨大空轉流量，而再次宕機。

最后拔了網線，將集群全部恢復起來，才最終完成修復。

后果

Facebook宕機事故絲毫不亞于前段時間“B站崩潰”事件，在國外引起了軒然大波。網友們紛紛圍觀，甚至調侃。

[[427701]]

還有一些品牌借此次事件進行營銷。

宕機事故發(fā)生后，F(xiàn)acebook股價暴跌6%，扎克伯格個人財富一日之間蒸發(fā)逾60億美元。

事后Facebook工程師們對此次事故進行復盤，估計要被很多低級的錯誤蠢哭，不過話說回來，很多事情就是這樣，事前死活想不到，事后復盤豬一樣。一開始工程師們做架構規(guī)劃的時候，可能死活也想不到一些低級的錯誤。