Google 迴應全球宕機：磁碟滿了

12 月 14 日，Google 服務遭遇全球大面積宕機，旗下 Gmail 郵箱，Google 日曆（Google Calendar）、影片網站 YouTube 等服務都受到影響，但大部分搜尋引擎業務仍然完好。據英國《衛報》當天報道，Google 服務的大面積癱瘓大約從格林尼治標準時間（GMT）12 月 14 日上午 11 時 50 分開始，影響了公司旗下絕大多數的服務。而 Google 的公司自動系統直到服務中斷了 30 分鐘仍在彙報任何服務都沒有出現問題，包括消費者服務和麵向開發者的雲服務。12 時 25 分， Google 才終於發現問題。

目前，Google Cloud 在推特上回應：宕機是由於磁碟滿了。

但真是由於磁碟滿了導致的嗎？從技術上嘗試做一個分析。全線崩潰？確切的說，搜尋服務是一直可用的，另外已經登陸服務的使用者，也是正常的，退出服務或者重新登陸，就會報錯了。谷歌這次bigbang，是全球範圍的，幾乎影響了Gmail、辦公套件、日曆、智慧家居等所有服務，包括被瘋狂diss的油管。

據google公開的內容，儲存空間不夠→處理使用者身份驗證和鑑權服務的儲存空間不夠，進而導致登陸報錯。

根據Google放出的故障報告(https://status.cloud.google.com/incident/zall/20013)，崩潰發生於2020-12-14 04:07，結束於2020-12-14 06:23（太平洋時間）。

影響範圍包括google全球所有云服務的賬號登入和身份驗證，導致的結果是gmail, calendar, google meet, google docs, google drive全都不能用，團滅時長為50分鐘。

故障的主要原因其實不是網傳的硬碟容量不夠了啥的，而是google的自動配額系統(automated quota management system)把google的驗證管理系統的配額容量減少了。所謂的quota management system，主要是用來管理分配各項服務佔用的儲存容量的，如果一項服務，實際的佔用的容量超過了指定的配額，系統就會發出警告並採取相應的措施。

而這回正是因為quota management system突然減少了google身份驗證系統的配額，導致身份驗證系統的服務受到影響，返回了大量的報錯資訊。而身份驗證系統又是google裡至關重要的一環，用過google服務的都知道，google的一套服務體系基本是一個賬號通用，而訪問一些資源的時候經常要你重新登入驗證，因此身份驗證是google整套使用者服務裡至關重要的“單點”，所有的服務都要經過它，一旦它掛了，後果是十分嚴重的。這也是為什麼我們通常說，在系統設計上要避免“單點故障”。

回答裡趁機黑容錯備份的朋友們可以洗洗睡了，這次的故障明明正是因為google在容錯上沒有做好，尤其是對這種和整套系統息息相關的服務，沒有充分地考慮到各種可能的出錯情況，容錯系統沒有設計好。追根究底，可能有兩個原因：

quota management system設計存在bug，像身份驗證系統這種不可能停下來的系統，優先順序應當非常高，突然縮減它的quota，而沒有給予身份驗證系統upcall申請增加quota的許可權，這種設計是不合理的。身份驗證系統本身的容錯機制不完善，尤其是這種極端情況，沒有經過充分測試。很可能，在設計的時候，開發者沒有考慮到達到quota時候，系統應該如何應對。就像我們平時寫程式，讀寫某個檔案，可能也不會考慮說，要是這個檔案特別特別的大，或者檔案系統快要滿了，再寫就要報"no disk space"的錯誤了，應該怎麼處理。通常的測試在這些conner case上很難覆蓋到，尤其是這種，如果要測試，必須先讓系統容量達到quota，才能測出超過quota時的容錯機制是否完善。可能程式設計師偷偷懶就放過了，沒想到真有撞上的一天= =

像Google這樣的大公司，絕對是有一套較為先進的容錯機制的，依然無法避免這樣的事情，說明在分佈系統容錯這個主題上，還有許多亟待解決完善的問題。

比較黑色幽默的一點是，因為google內部用的也是google的這一套系統，也就是所謂的dogfooding，“吃自家的狗糧”。這就導致出事的時候，google內部的員工自己也登不上賬號，導致修復崩潰系統的時候，交流不暢，增加了修復系統的用時。

"

谷歌最近不是第一次宕機了，我自己的記憶中有過Gmail跟YouTube上不去的事情。

這次的原因在Goole Cloud的推特賬號上說清楚了，因為quota（配額）的問題，導致驗證系統出現了宕機。

推特里說的quota issue也就是一個分配資源的問題。這裡的quota一般指的就是虛擬機器的資源，如果分配的少了，可能就會導致響應太慢，就好像這次的崩潰。如果分配的多了，浪費錢。正常來說，一個成熟的系統必然是有自己的一套自動調整quota的規則，可以根據需求自動調整quota的大小。

但是擴大虛擬機器的數量（也就是增大quota）肯定是需要很多時間的。谷歌雲不清楚，像是微軟的Azure會在15分鐘內保證可以設定好一個新的虛擬機器。也就是說，真的等到流量激增才調整quota是完全來不及的。所以這個自動調整的規則必然是根據歷史來設定的。比如半夜0點拉高quota（很多定時服務會在0點啟動）。

既然是根據歷史來設定，難免會有玩脫的時候。就是今年穀歌玩脫的次數有點多，雖然其他幾次不見得是quota的鍋。

"

尾聲

前不久，google推出的k8s宣佈去docker ，是不是遇到這問題，會有變故產生？