一個潛伏的程式錯誤，讓 Gmail 的例行資料中心維護演變成三小時的全球大當機

2009 年 2 月 24 日，Gmail 對全球使用者中斷服務。Google 針對其 Apps 客戶發布的事件報告指出，中斷時間約為格林威治標準時間上午 9 點至中午 12 點——大約三小時——恢復過程分批進行，因此個別使用者失去存取權的時間長短不一。沒有任何資料遺失。

其運作機制是兩項近期決策交互作用的結果。Google 部署了新軟體，以最佳化使用者資料的存放位置。當天早上，工程師開始在一個歐洲資料中心進行例行維護——這項作業原本設計為使用者無感，因為流量會自動轉移到其他地方。但這次轉移觸發了新在地化程式碼中的潛伏錯誤：目的地超載，而隨著流量被自動再次轉移，超載便從一個資料中心向下游連鎖擴散到另一個資料中心。工程師花了約一小時控制住這波連鎖反應，之後又花了更長時間才重新平衡一切。

Google 處理後續的方式在當時相當罕見地公開：Gmail 網站可靠性經理 Acacio Cruz 同日於官方 Gmail 部落格說明了這波連鎖反應，Google 也為 Apps 客戶發布了正式的事件報告。該公司還承諾為這項服務打造當時尚不存在的東西——公開狀態儀表板——承認雲端供應商在服務中斷期間有責任讓客戶快速取得資訊，而不只是沉默與修復。

2009 年 2 月 24 日，Gmail 無法存取長達三小時，恢復過程依資料中心分批進行；沒有資料遺失

容錯移轉路徑——將流量轉移到第二個資料中心——未曾針對新的資料在地化軟體進行演練，因此潛伏錯誤只在維護期間被觸發。

超載反應放大了故障：當使用者被自動再次轉移時，每個目的地都遭遇相同的超載狀況，並將其向下游擴散。

維護設計假設資料中心之間能順利交接，但新的最佳化程式碼改變了容錯移轉所依據的假設。

溝通落後於事件：Google 自己的事後檢討承認，必須快速確認服務中斷，這直接促成了 Apps 狀態儀表板的誕生。

容錯移轉路徑應與主要路徑接受同等程度的測試：重新安排資料位置的新程式碼，把例行維護變成了連鎖故障。而雲端服務中斷時，需要發布事件報告。

Google 修復了該錯誤並推送變更，發布了事件報告，並在數週後推出 Google Apps 狀態儀表板，將公開的服務中斷溝通制度化。「gfail」事件成為雲端事件報告的早期範本——一份正式、面向客戶的說明，交代原因與補救措施——而當時大多數消費性網路服務根本不提供任何解釋。