因為一條簡單的命令，Facebook宕機6小時，當天股價暴跌6%
最近Facebook發生史上最嚴重的宕機事件，導致其全球網絡宕機6個多小時。
按道理，Facebook這種體量的公司，應該有一套完整的應急預案，不會出現長時間的宕機才對?？墒?，一連串狗血劇情的發生，讓Facebook不得不接受這個事實。
首先是程序員敲錯了一個命令，系統在審計命令的時候，應該不放行。巧的是，審計工具有bug，竟然放行了這條命令。
更要命的是，因為數據中心的安全設計，駐場工程師無法接觸到服務器，只得“溜門撬鎖”，費勁千辛萬苦才修復完成。
修復完一上線又崩了一次，第二次才完全修復完畢，整個過程耗費整整6個小時，堪稱史詩級災難大片。
事件經過
一切都要從日常維護中的一條錯誤命令說起。
在日常維護基礎設施時，工程師需要離線維護部分主干網，例如修理一條光纖線路、增加更多容量或者更新路由器本身的軟件等等。
10月初，出于這一需要，工程師需使用一條命令，以評估網絡狀態，然而卻誤敲成清空路由表的命令。
按道理，審計工具應該攔截這條異常命令，結果因為工具本身的bug，這一條命令被放行。
在Facebook的系統設計中，Facebook所有域名服務器，會在服務器連接不上數據中心對應IP的情況下，停止DNS解析。這一設計的目的是如果IP不可達，那么網絡存在問題，解析出來也沒有太大的意義。這樣一來，用戶的請求仍然可以解析到其他IP上。
但是這一騷操作，直接將Facebook整套自有域名服務器癱瘓掉，即便其他服務器都沒有問題，沒有DNS指路，業務也無法順利進行。
基礎架構翻車、溝通協調不暢以及遠程排除故障困難，是導致Facebook宕機6小時的主要原因。
另外一個原因有點讓人哭笑不得。
數據中心有各式各樣的安全設計，以防止數據盜竊以及其他安全事件的發生。然而因為這些設計上的問題，導致當天駐場工程師，無法第一時間接觸到服務器，不得不強制清除一些“物理”障礙，修復時間一再推遲。
因為修復策略是一臺一臺恢復，導致先上線的少量服務器，無法頂住已經存在的巨大空轉流量，而再次宕機。
最后拔了網線，將集群全部恢復起來，才最終完成修復。
后果
Facebook宕機事故絲毫不亞于前段時間“B站崩潰”事件，在國外引起了軒然大波。網友們紛紛圍觀，甚至調侃。
還有一些品牌借此次事件進行營銷。
宕機事故發生后，Facebook股價暴跌6%，扎克伯格個人財富一日之間蒸發逾60億美元。
事后Facebook工程師們對此次事故進行復盤，估計要被很多低級的錯誤蠢哭，不過話說回來，很多事情就是這樣，事前死活想不到，事后復盤豬一樣。一開始工程師們做架構規劃的時候，可能死活也想不到一些低級的錯誤。
