從2020年8月19日20:55到03:30開始，多個G suite和GCP產品發生無法使用以及
延遲嚴重等錯誤。這些問題大部分是創建、上傳、複製以及傳送資料。
事件持續了6小時35分鐘。
影響的詳細說明
從2020年8月19日20:55到03:30開始 Google服務出現以下問題:
● Gmail: Gmail對於一些使用者發生無法使用的問題，還有Gmail也出現傳送延遲問題。大約0.73%的用戶(包括使用者和G suite)在問題期間遇到了3個或更多錯誤。G suite的客戶佔Gmail受影響用戶27%。某些用戶在向郵件添加附件時遇到錯誤。到03:30時減輕了對Gmail的影響，並且此事件導致的所有傳送延遲的郵件都已傳送完成。
● Drive: 一些Google Drive用戶遇到錯誤並導致延遲增加。在停電時，過去24小時內活動的Google Drive用戶(包括消費者和G Suite)中約有1.5％遇到了3個或更多錯誤。
● Docs and Editors: 一些Google Docs用戶在創建圖片時遇到了問題(例如:上傳圖片或使用複製圖片)。
● New Google Sites: 有些用戶不能創建新的Sites、新增新的頁面以及新增圖片。創建網站的錯誤率幾乎趨近100％並且於3:00趨緩下來。
● Chat: Google Chat用戶中有2％遇到傳送訊息的錯誤，嘗試將郵件轉發到Gmail的Chat用戶中有16％遇到錯誤。
● Meet: 在此事件發生直播中斷的問題。由於對Youtube的影響，錄音也發生延遲問題。影響從21:00到01:15，01:40到02:10。
● Keep: 有些用戶回傳關於伺服器錯誤代碼500以及涉及媒體營運延誤的錯誤。
● Voice: 帶有附件的SMS訊息傳送失敗。某些語音郵件，通話錄音和SMS的傳送被延遲。在03:20趨緩了對語音的影響。所有語音郵件和錄音都已經發送，最大延遲為5.5小時。
● Jamboard: ：某些用戶在嘗試上傳圖片或複製包含圖片的檔案時遇到錯誤。
● Admin Console: 在G Suite Admin Console中上傳CSV文件時，某些用戶遇到錯誤。在中斷時，這些操作的錯誤率介於15％到40％之間。
● App Engine: 使用Blobstore API的App Engine Standard發現了了更高的錯誤率。在大多數地區，錯誤率都低於5％，但在us-west1和us-central1中最高達到47％。使用Images API的App Engine Standard的錯誤率高達66％。由靜態文件或Blobstore objects提供服務的連線HTTP requests出現了更高的錯誤，最高為1％。包含靜態文件的App部署失敗，並顯示一條消息: e “The following errors occurred whilecopying files to App Engine: Filehttps://storage.googleapis.com/…. failed with: Failed to save static file.”。直到3:25減緩了對於App的影響。
● Cloud Logging: 寫入Google Cloud Logging的日誌消息（包括由Google生成的日誌，例如App Engine請求日誌，活動日誌和審核日誌）最多延遲了4小時43分鐘。在中斷時，API成功呼叫、寫入和讀取日誌，但返回的結果不完整。
● Cloud Storage: 對位於US多區域的Google Cloud Storage buckets的API呼
叫的錯誤率高達1％。
根本原因
許多Google服務使用通用的內部分佈式系統來儲存不可變的非結構化數據，也稱為二進制大數據或Blob。這個Blob存儲系統包含一個與Google內部客戶端服務連接的前端，一個處理metadata操作的中間層以及Blob本身的後端儲存。當客戶端向前端發出請求時，metadata操作將轉發到與存儲服務進行通信的服務。
來自另一個Google服務的流量增加開始使metadata服務超載。導致任務變得不良，並要求增加延遲。此等待時間促使這些操作過多重試，從而導致資源耗盡。自動化系統嘗試啟動新的metadata任務。但是，這些任務中的許多任務立即被接收到的通信量淹沒，開始分配任務的資源不足而導致資源枯竭。用於取消和重試失敗請求的策略加劇了此問題，從而導致流量倍增。
與其他產品相比，Google Cloud Storage的影響較小。雖然Google Cloud Storage建立在相同的Blob存儲系統上，但GCS的metadata大多與受影響的Google內部服務隔離。正在針對 US多區域進行GCS元數據隔離的遷移，而所有其他遷移都已完成。最後，減少了對GCS客戶的影響，並且這種影響僅限於US的多地區。
補救與預防
Google工程師在20:58收到有關這問題的自動警報，並開始對此問題進行調查。受影響最嚴重的Google Cloud服務的工程師在事件開始時間的一小時內就開始並進行調查和緩解措施。
Google Blob存儲服務的工程師進行限速配置的更改，從而緩解了大多數的內部錯誤，儘管資源耗盡而繼續造成影響。在00:00和04:00間，事件響應者通過為metadata服務分配緊急容量並禁用正在重新啟動伺服器的運行狀況來緩解事件。錯誤率和等待時間逐漸降低，最後一次資源耗盡錯誤發生在04:03。
為了防止問題重複發生並減少類似事件的影響，Google正在採取以下措施:
● 增加對blob服務的計算資源分配，直到根本原因得到完全修復為止
● 調查並改進在metadata服務啟動期間執行的運行狀況檢查，以避免在為資源配置之前過早停止
● 評估並改進metadata操作失敗時使用的back off和retry策略
● 修復一個問題，在該問題中，錯誤可能導致跨複製資源的取消請求氾濫
● 改進Blob儲存系統使用的自動擴展服務中的警報，以在啟動任務和分配資源時可以更早地發現問題
● 為對Blob儲存服務的請求實施更全面的限速控制
● 添加工具以更有效地調整Blob操作
● 提高關鍵任務之間轉移生產資源的速度，效率和自動化程度
● 在Bolb儲存服務改善內部playbook文件的限速控制
Google已經承諾於快速，持續改進我們的技術以及防止服務中斷。