BlogOctober 30, 2023
2023 年 10月 27 日 Zeabur 台北區域服務故障報告
Yuanlin LinThis article also available in English.
故障簡介
2023 年 10 月 27 日，Zeabur 發生了一次服務中斷故障事件。故障影響到位於台北區域的 tpe1 叢集 ，導致服務中斷 1 小時左右。故障的起因是一名實習生操作失誤導致刪除了我司位於 Google Cloud Platform 台北機房的 Kubernetes 叢集。
Zeabur 的運維團隊在接收到監控服務報警後迅速採取行動，在兩小時內復原了企業方案及開發者方案使用者的服務。此次故障影響範圍較為廣泛，主要受影響的使用者包括：
- 部署在 tpe1（台北）區域的免費方案、開發者方案、企業方案使用者的容器化服務
- 部署在 tpe1（台北）區域的免費方案、開發者方案、企業方案使用者的 Serverless 服務
如果您部署的服務恰好在受影響的區域內，那麼在 2023 年 10 月 27 日的這段時間內，您可能會無法訪問您在 Zeabur 部署的相關服務。
我們對此次事件的失誤和造成的影響深感歉意。
事件時間線
公司實習生在刪除原有廢棄的測試叢集時，由於缺乏操作經驗，以及內部權限管理的疏失，並且未將危險操作行為上報給主管人員，錯誤地將生產環境的 Google Kubernetes Engine 叢集刪除，導致叢集進入不可用狀態， tpe1（台北）區域的服務全部中斷。
- UTC 2:40 - tpe1 叢集被刪除，服務全部離線。
- UTC 2:41 - 服務健康監控系統檢測到服務中斷，向專案監控小組發送緊急報警。
- UTC 2:45 - 故障原因確認，運維人員立即進行排查，發現叢集無法訪問。進一步排查發現叢集被刪除，並且過程不可逆，團隊開始緊急應變措施。
- UTC 2:50 - 專案技術負責人及運維人員在嘗試和 Google Cloud Platform 溝通後嘗試直接修復叢集失敗，嘗試通過 Google Kubernetes Engine 備份復原的方式復原叢集，但是經排查該叢集並未啟用備份服務。
- UTC 3:00 - 經過團隊排查，發現被刪除的叢集不影響使用 Google Cloud Platform 中 Compute Engine 的 Persistent Disk，因此確定使用者服務資料並未遺失。
- UTC 3:10 - 開始將故障服務遷移至 tpe0（台北）區域，團隊開始透過自動化腳本將使用者的資料重新綁定至位於台北區域的備援叢集。
- UTC 3:30 - 叢集主要功能復原，使用者服務重新上線，企業方案客戶服務復原，開發團隊開始處理使用者回報的工單。
- UTC 3:48 - 團隊發表故障公告，並建議可以臨時遷移無狀態服務至 hkg1（香港）區域或 sfo1（北美）區域作為臨時解決方案。
- UTC 3:56 - 團隊發表服務復原宣告，向使用者給出解決方案以及工單提交流程。
- UTC 6:10 - 團隊發表服務復原公告，所有故障期間發布的開發者方案客戶工單處理完畢，制定使用者服務復原申請的工單提交流程，持續為使用者復原服務。
原因分析
- 員工安全意識缺乏，在危險操作前沒有及時上報給主管開發人員覆核，也沒有重複確認操作的目標資源。
- 團隊內部權限管理不夠細粒度，導致員工擁有生產環境叢集的管理權限，沒有進行針對性的權限控制。
- 災備方案不夠完善，Kubernetes 資源沒有定期自動備份，導致故障發生後無法快速透過備份進行復原。
- 缺乏相關緊急情況的應急處理流程，導致反應時間較長。
應急處理
故障發現
監控系統快速檢測到多個服務出現 502 錯誤，並且在短時間內出現大量報警，經排查所有項目均來自於 `TPE1` 叢集。隨後在開發組內部確認，團隊在 1 分鐘內有刪除開發叢集的操作，但是由於沒有及時上報給主管開發人員覆核，同時帳戶策略一直在使用高權限帳戶，導致誤刪除了生產叢集。
故障復原
在最短的時間內，開發團隊開始緊急處理，團隊工程師詢問了 Google Cloud Platform 客服，確認刪除操作一旦執行不可復原。並且因為 Google Kubernetes Engine 備份功能未啟用，無法透過此方式復原叢集。
經過團隊排查，叢集的持久化儲存硬碟並未因為叢集的刪除動作而被銷毀，因此決定手動透過綁定原有硬碟的方式在備援叢集建立新的有狀態服務，無狀態服務則採用重新構建的方式。
基礎設施運維工程師，在台北備援叢集 tpe0 增加計算節點，建立新的部署以容納來自故障叢集的使用者服務。叢集準備就緒後，團隊開始透過自動化腳本透過原有的持久化硬碟復原使用者服務。得益於 Zeabur 原有系統的健壯性，透過一些簡單的遷移腳本，開發團隊得以快速將服務遷移到備援叢集。實驗性手動遷移工作的可行性驗證後，優先復原企業方案使用者的服務。
故障使用者的叢集遷移完成，企業方案使用者服務復原。開發團隊開始處理使用者工單。開發者方案使用者和免費方案使用者服務開始透過完善的自動化流程逐步復原。
後續應急方案更新：使用者可以臨時遷移無狀態服務至 香港 `HKG1` 叢集或 美國 `SFO1` 叢集作為解決方案。有狀態服務則遷移至臨時叢集，有效保護使用者資料的完整性。
驗證
經驗證，業務系統在備援叢集上能夠正確啟動和對外提供服務，服務中斷事件得以解決。
處理
在應急事件結束後，團隊第一時間關閉了所有開發人員的 IAM 權限帳戶進行了最小化控管，同時對於所有的基礎設施進行了安全檢測，發現了一些潛在的安全隱患並制定改進計畫。
在所有叢集復原正常狀態後，運維工程師對所有叢集開啟了備份服務，並且對於所有的叢集進行了全量備份。開啟定時備份服務，對於使用者資料進行定時增量備份。
團隊對於事件進行了總結和分析，並且對於事件中的失誤進行了反思和改進，同時對於基礎設施的高可用性和安全性進行了重新評估和設計。
使用者服務保障
對於偶發的使用者服務仍然持續出現錯誤的情況，團隊制定了服務復原工作的回報流程，保證服務復原工單的快速應答和高可用：
- 參考社群 > 尋求幫助在 Zeabur 官方的 Discord 伺服器上提交工單
- 由 Zeabur 官方團隊進行工單處理，對於使用者的復原請求，我們將在 10 分鐘完成服務復原工作。
後續改進措施
管理流程
強化員工和實習生的安全和規範化操作培訓，修改生產環境前需要上級主管工程師覆核。審批通過後，由主管工程師進行操作。如果條件允許，將確保復原機制可用。
權限管理
1. 在此次事件後，團隊內部針對 IAM 權限管理進行了完整的重新設計，確保所有開發人員只獲得最小化的操作權限。
2. 對於破壞性的操作（尤其是不可復原的破壞性操作），確保開發人員必須在手動 assume（假設）資源操作角色後，才能獲得對應的權限，多一次重複確認的動作來確保這類疏失不再發生。
3. 監控系統和管理團隊也能在當敏感操作對應的角色被 assume 時收到監控報警，即時避免錯誤的操作。
資源鎖定
在關鍵系統資源上設定保護性鎖定，避免錯誤的修改和刪除。危險操作需要系統管理員認證和 MFA 多因素裝置輔助認證。
強化災備
基於此次經驗，我們重新設計了 Zeabur 對於單區域性故障的災備策略和應變措施。透過備份 Kubernetes 資源、使用者服務的容器 Image，我們可以確保在最糟的情況下仍能在 15 分鐘內復原服務。
同時，團隊也決定提升使用者服務的持久化資料的備份等級，為企業方案和開發者方案客戶部署的服務的持久化資料進行跨區備份，確保即使上游供應商發生故障，也能保障 Zeabur 使用者的資料安全。
報警最佳化
完善監控報警系統，對於基礎設施操作接入報警系統，及時發現異常操作。我們將來自上游系統（如 AWS CloudTrail、 Google Cloud Audit Logs）的操作記錄接入到 Zeabur 內部的管理系統中，使用 Clickhouse 及 Grafana 設定對應的報警規則，確保危險操作在可能發生時能夠被即時確認。
總結
Zeabur 一直致力於打造高可用的服務部署體驗，但這次意外事件表明，我們顯然沒有達到預期。透過這次事件，我們注意到在基礎設施安全管理和高可用架構設計上還有很多不足，會認真總結和改進以預防類似事件再次發生。在此對所有在本次服務故障事件期間無法訪問 Zeabur 服務的使用者深表歉意。我們已經開始改進和反思，確保類似情況不會再次發生。