Google Cloud 架構完善架構的可靠性支柱原則提供相關建議，協助您設計及執行測試，以便在發生故障時進行復原。
這項原則與可靠性的學習 重點領域相關。
原則總覽
為確保系統能從故障中復原，您必須定期執行測試，包括區域容錯移轉、版本回溯，以及從備份還原資料。
這項測試可協助您練習回應對可靠性造成重大風險的事件，例如整個區域發生服務中斷。 這項測試也有助於確認系統在發生中斷時是否能正常運作。
萬一整個區域發生故障，您需要將所有流量容錯移轉至其他區域。在工作負載的正常運作期間，資料修改後必須從主要區域同步至容錯移轉區域。您必須確認複製的資料一律為最新資料，以免使用者發生資料遺失或工作階段中斷的情況。負載平衡系統也必須能夠隨時將流量轉移至容錯移轉區域，且不會中斷服務。為了盡量縮短區域中斷後的停機時間，營運工程師也必須盡可能在短時間內，手動且有效率地將使用者流量從該區域移出。這項作業有時稱為「排空區域」，也就是停止傳入區域的流量，並將所有流量移至其他位置。
建議
設計及執行失敗復原測試時，請參考下列小節的建議。
定義測試目標和範圍
明確定義測試要達成的目標。舉例來說，您的目標可以包括：
- 驗證復原時間目標 (RTO) 和復原點目標 (RPO)。詳情請參閱「DR 規劃的基本概念」。
- 在各種故障情況下，評估系統的復原能力和容錯能力。
- 測試自動容錯移轉機制的成效。
決定測試範圍涵蓋哪些元件、服務或區域。範圍可以包括前端、後端和資料庫等特定應用程式層級，也可以包括 Cloud SQL 執行個體或 GKE 叢集等特定 Google Cloud 資源。範圍也必須指定任何外部依附元件，例如第三方 API 或雲端互連。
準備測試環境
選擇適當的環境，最好是複製生產設定的暫存或沙箱環境。如果在正式環境中進行測試，請務必準備好安全措施，例如自動監控和手動復原程序。
建立備份方案。為重要資料庫和服務建立快照或備份，以免測試期間發生資料遺失。如果自動容錯移轉機制失敗，請確保團隊已準備好進行手動介入。
為避免測試中斷，請確認 IAM 角色、政策和容錯移轉設定正確無誤。確認測試工具和指令碼具備必要權限。
向利害關係人 (包括營運、開發運作和應用程式擁有者) 說明測試時間表、範圍和潛在影響。向利害關係人提供預估時間表，以及測試期間的預期行為。
模擬失敗情境
使用 Chaos Monkey 等工具規劃及執行失敗作業。您可以使用自訂指令碼模擬重要服務的故障情形，例如多區域 GKE 叢集中的主要節點關機，或是 Cloud SQL 執行個體遭到停用。您也可以根據測試範圍，使用防火牆規則或 API 限制，透過指令碼模擬區域網路中斷。逐步擴大故障情境，觀察系統在各種情況下的行為。
在發生中斷時，導入工作負載測試和失敗情境，模擬實際使用情況。測試連鎖故障的影響，例如後端服務無法使用時，前端系統的行為。
如要驗證設定變更，並評估系統抵禦人為錯誤的能力，請測試涉及設定錯誤的情境。舉例來說，使用不正確的 DNS 容錯移轉設定或不正確的 IAM 權限執行測試。
監控系統行為
監控負載平衡器、健康狀態檢查和其他機制如何重新導向流量。使用 Cloud Monitoring 和 Cloud Logging 等 Google Cloud 工具，擷取測試期間的指標和事件。
在失敗模擬期間和之後，觀察延遲時間、錯誤率和輸送量的變化，並監控整體效能影響。找出使用者體驗的任何退化或不一致之處。
確認系統會針對重要事件 (例如服務中斷或容錯移轉) 產生記錄並觸發快訊。您可以使用這項資料，驗證警報和事件回應系統的有效性。
根據 RTO 和 RPO 驗證復原作業
測量系統在發生故障後恢復正常運作所需的時間，然後將這項資料與定義的 RTO 進行比較，並記錄任何差距。
確保資料完整性和可用性符合 RPO。如要測試資料庫一致性，請比較故障前後的資料庫快照或備份。
評估服務還原作業，確認所有服務都已還原至正常運作狀態，且使用者受到的影響降至最低。
記錄及分析結果
記錄每個測試步驟、失敗情境和對應的系統行為。請附上時間戳記、記錄檔和指標，以利進行詳細分析。
強調測試期間觀察到的瓶頸、單點故障或意外行為。為協助您決定修正問題的優先順序，請依嚴重程度和影響程度將問題分類。
建議改善系統架構、容錯移轉機制或監控設定。根據測試結果，更新任何相關的容錯移轉政策和劇本。向利害關係人提交事後檢討報告。報表應總結結果、經驗教訓和後續步驟。詳情請參閱「徹底進行事後檢討」。
反覆測試及修正
為驗證持續的可靠性和韌性，請規劃定期測試 (例如每季一次)。
在不同情境下執行測試，包括基礎架構變更、軟體更新和流量負載增加。
使用 CI/CD 管道將可靠性測試整合到開發生命週期中，自動執行容錯移轉測試。
在事後檢討期間，請根據利害關係人和使用者的意見回饋，改善測試程序和系統復原能力。