#分享 從 GCP 事故看大規模服務崩潰復原的困難之處
Hello 各位好，繼 openAI 大當機之後今天繼續來分享大廠的事故 xD
網路上做故障覆盤的文章和影片其實已經蠻多了
因此今天想藉這次事故來跟大家分享大規模服務崩潰之後要復原的諸多難點
首先我們先從調查報告的簡易 timeline 來看
10:51 | 事故發生
10:53 | 檢測到問題
11:01 | 確認問題原因
11:31 | 開始恢復工作
18:18 | 服務全部復原完成
從這個 timeline 我們可以注意到，Google 團隊其實 2 分鐘就發現問題並且 8 分鐘就確認問題發生的原因在 30 分鐘就修正完畢開始恢復工作，但是卻一路到了 18:18 服務才完全回來
不禁讓人好奇明明那麼快就修好了，為什麼服務回來要花那麼多的時間呢?
其中有幾個常見的困難點，這篇文章提出其中兩個來說明
(1) 沒辦法按正常上版流程更新服務
一般來說，大規模的服務在上版的時候會用 rolling update 的方式進行更新，一次更新一小部分慢慢把全部的服務都更新完，但是當遇到整個服務完全崩潰的情況如果按照本來的方式來進行hotfix 的上版的話會遇到的問題是，剛修正完畢的那一小部分服務馬上就會因為扛不住原先整個 Cluster 的流量又再次被打掛。
(2) Cache 失效
如果很不幸的這次崩潰導致 Cache 丟失的話，那要恢復整個 Cluster 的服務又會更困難了。
縱使今天把整個 Cluster 的服務拉起來了，但因為 Cache 丟失的關係大量的請求又直接湧向 Database 導致 DB 又被打掛了
那對於上面這兩種情況應該要如何處理呢?
對於第一種情況來說，一種常見的策略是進行服務熔斷或是降級，終止部分服務的流量或是只先允許少部分的流量通過，驗證目前的服務有順利恢復再逐漸把剩下的服務給拉起來並逐漸放寬流量的速率限制來讓服務回復穩定的狀態。
可能會有人好奇，既然一次恢復一小部分可能會導致扛不住本來的流量那為什麼不一口氣全部拉起來就好了呢?
因為這個掛掉的服務本身也會依賴其他的服務，如果我們一口氣把整個集群拉起來的話也很容易導致依賴的其他服務被我們打掛，比如突然大量的 DB connections, Log , API Requests也很可能把其他服務瞬間打掛來不及進行 scale 造成二次事故。
對於第二種情況來說，最有效的方式就是要進行 Cache 的預熱 (Cache Warming)
來避免服務一起來就有大量的請求往 DB 轟炸過去
乍看之下好像會覺得 咦 好像也沒有很困難嘛 就中斷一下流量 然後 Cache warming 一下就好了
但實務上其實還有很多需要考量到的細節，比如當你進行服務的熔斷與降級的時候你可能就會遇到使用者體驗不好的問題，服務掛了使用者通常會抱怨一下然後乖乖等服務回來但服務可以用但用起來卻很爛很多功能不能用使用者可能會不爽很久直到服務全部正常 xD
以及熔斷和降級的閾值其實也是需要經驗和測試去做拿捏，如果過早就熔斷和降級不只影響使用者體驗也會延後你整個服務完整復原的時間但如果設的太高則可能讓服務又再次被打到掛掉
至於 Cache Warming 當然也沒有想像中那麼簡單，要拿哪些資料來預熱? 預熱會耗費多少計算資源? 會花多久時間? 這些都很仰賴平常的災難復原的演練
以後有機會再來分享更多意外事故(希望不要哪天分享到自己的
如果上面內容有錯誤或不夠清楚的再麻煩大佬提點了
也歡迎留言分享討論平常工作上遇到事故的時候都是怎麼處理的!
Ref: ---
目前持續都有提供 履歷健檢 & 職涯諮詢的免費服務 ! 歡迎私訊
