Google ACE: 可靠性、備份與災難復原 — 學習指南

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

屬於 Google Associate Cloud Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

在 Google Cloud 上實現可靠性、備份與災難復原，需要在故障網域、資料保護機制、流量管理與營運整備等方面進行刻意的設計。本節將說明如何在可用區與區域之間架構服務、如何保護與還原具狀態的資料，以及如何透過嚴謹的 Runbook 與持續的彈性測試來驗證復原目標。本節也將概述災難復原 (DR) 策略的權衡取捨與容量規劃，以確保平台能在定義的復原時間目標 (RTO) 與復原點目標 (RPO) 內完成復原。

故障網域與區域級設計

可用區、區域與多區域服務
- 可用區 (Zone) 是最小的獨立故障網域。單一可用區的故障不應中斷區域級服務。
- 區域 (Region) 由多個具備低延遲連結的獨立可用區組成。區域級設計能承受可用區故障，但不一定能承受整個區域的事件。
- 多區域服務會在多個區域之間進行複製，能抵禦區域性損失，但成本較高，且可能會有較高的寫入延遲。
- 設計原則：在您所關注的最小故障網域中，避免單點故障。如果您的 RTO/RPO 要求能承受可用區故障，請至少部署到兩個可用區。若要具備區域級的存活能力，請將主動式元件部署到多個區域，或使用多區域服務。
Managed instance groups (MIG) 與自我修復
- 優先使用區域級 MIG，將執行個體分散到單一區域內的多個可用區。這可以在不需額外工具的情況下，減輕可用區中斷的影響。
- 負載平衡器的健康狀態檢查會將不健康的 VM 從流量中移除。MIG 的自動修復功能會取代不健康或無回應的 VM。兩者應並用。
- 使用應用程式層級的 HTTP(S) 健康狀態檢查，來驗證整備端點 (readiness endpoints) 及其依賴項目。TCP 檢查僅能驗證通訊埠的可連線性。
- 自動修復的常見設定錯誤：若只使用負載平衡器的健康狀態檢查，雖然能阻止流量流向有問題的執行個體，但不會重新建立它。應設定 MIG 自身的健康狀態檢查來執行替換，並設定初始延遲，以避免在開機過程中過早重啟。

範例：

建立一個應用程式健康狀態檢查，設定 10 秒的檢查間隔與 3 次的不健康閾值，使其在大約 30 秒後觸發自我修復： gcloud compute health-checks create http hc-app
–check-interval=10s –timeout=5s
–unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz
將此健康狀態檢查附加到一個區域級 MIG 以啟用自動修復： gcloud compute instance-groups managed update my-rmig
–region=us-central1 –health-check=hc-app –initial-delay=60
多區域考量
- Global external HTTP(S) Load Balancing 支援位於多個區域的後端，並能根據健康狀態檢查自動進行容錯移轉。
- 跨區域的狀態同步是關鍵的權衡點。主動-主動 (Active-active) 模式的吞吐量高，但必須妥善設計一致性與衝突解決機制。主動-被動 (Active-passive) 模式較為簡單，但容錯移轉速度較慢，且可能有較大的 RPO。

韌性維運與持續改進

RTO、RPO、復原計畫與維運手冊
- RTO 定義服務必須多快恢復；RPO 定義可接受的資料遺失量。這些指標應從業務衝擊分析中推導出來。
- 將每個系統元件對應到滿足 RTO/RPO 的特定機制：用 HA 對應可用區故障、用跨區域複寫對應區域性故障、用備份對應資料損毀、用儲存空間級別/複寫對應耐久性。
- 維護維運手冊：包含精確的步驟、指令、憑證存取方式、健康狀態驗證檢查以及決策樹。將其儲存在有版本控制且存取受控的儲存庫中，並定期演練。
- 復原驗證：安排演練以衡量實際的 RTO/RPO、驗證資料完整性，並收集改善措施。測試小範圍還原（資料表、磁碟）和完整的站點復原。
DR 策略與其取捨
- Active-active：所有區域都提供流量服務；若資料同步設計得當，可達到最小的 RTO 和低的 RPO。複雜度和成本較高；需要衝突解決機制和全球負載平衡。
- Active-passive：主要區域為作用中；次要區域為暖備援狀態並接收複寫的資料。成本中等；RTO 為數分鐘到數十分鐘；RPO 不為零，取決於複寫機制。
- Pilot-light：在次要區域運行最少量的關鍵服務（資料庫複寫、最小的應用程式足跡）。RTO 為數小時；具成本效益；在故障轉移期間需要謹慎的協調來擴展運算資源。
- Cold-standby：基礎設施以程式碼定義但未佈建。RTO 為數天；成本最低；存在因組態漂移、配額和容量稀缺而產生意外的風險。
混沌測試與故障模擬
- 定期模擬執行個體崩潰、程序卡死、健康檢查失敗、磁碟滿載以及相依服務中斷等情況。使用工具或腳本來終止執行個體、阻擋對後端的出口流量，或在代理層注入延遲。
- 透過刻意讓健康檢查端點失敗，來驗證 MIG 的自動修復和 LB 的移除機制。確認替換行為和復原時間軸。
- 練習區域性撤離：排空一個區域中的後端服務，觀察全球負載平衡器的故障轉移，並驗證次要區域中有狀態的相依服務。
- 持續改進：在測試期間記錄平均偵測時間 (mean time to detect)、故障轉移時間和資料遺失量等指標。優先修復能減少 RTO/RPO 和移除手動步驟的問題。

實務問題情境

Brightlane Retail 在 us-central1 營運一個電子商務平台，對可用性有嚴格要求，且訂單資料的 RPO 為四小時。管理層要求能夠在可用區中斷時無停機時間地存活，並在區域中斷時對客戶的影響降到最低。

方法：

實作一個具備 HTTP 自動修復功能的區域性 MIG，以及一個全球 HTTP(S) 負載平衡器
- 理由：區域性 MIG 將執行個體分散到多個可用區，而應用程式層級的 HTTP 健康檢查能在連續三次（每次 10 秒）檢查失敗後啟用自我修復。全球負載平衡器會自動移除不健康的 VM，並將流量轉移到健康的可用區。
- 指令：

undefined

啟用 Cloud SQL HA，並搭配跨區域讀取複本和 PITR
- 理由：區域性 HA 提供具備自動故障轉移的可用區存活能力。在 us-east1 的讀取複本提供區域性 DR，其 RPO 不為零但有界限。啟用 PITR（對 MySQL 來說是啟用 binary logging）可以透過還原到某個時間點來解決邏輯性損毀問題。
- 指令：

undefined

使用雙區域 Cloud Storage 和生命週期政策保護物件資產
- 理由：產品圖片和靜態資產儲存在雙區域值區中，以實現區域性韌性。生命週期轉換會將較舊的成品移至 Coldline 以優化成本，而版本控制加上保留政策可防止關鍵資產被意外刪除。
- 步驟：啟用物件版本控制 (Object Versioning)，為關鍵值區設定 30 天的保留政策，並對非關鍵的建置成品套用生命週期規則，使其在 90 天後轉換到 Coldline，並在一年後刪除。
為有狀態的服務排程 PD 快照並建立機器映像檔
- 理由：VM 磁碟的增量快照提供快速的崩潰一致性還原選項。機器映像檔擷取開機和設定資訊，以在區域故障轉移期間加速應用程式伺服器的重新部署。快照排程可確保一致、由政策驅動的備份。
- 指令：

undefined

定義 RTO/RPO 並將 DR 維運手冊和 IaC 程式碼化
- 理由：為 web/API 設定 15 分鐘的服務層級 RTO，為訂單設定四小時的 RPO。維運手冊詳細說明流量故障轉移程序、Cloud SQL 讀取複本的提升、DNS 應變計畫以及驗證步驟。基礎設施即程式碼 (Infrastructure as code，如 Terraform/Deployment Manager) 可確保確定性的重建並減少人為錯誤。
在次要區域佈建容量和配額
- 理由：為關鍵的 VM 形狀建立預留，預先佈建備用的負載平衡器後端、SSL 憑證、NAT 容量，並在 us-east1 驗證 Compute、SQL、轉送規則和 KMS 的配額。這可以防止在故障轉移期間發生容量不足的問題。
透過混沌演練驗證復原能力並記錄改善項目
- 理由：每季的可用區故障演練可驗證 MIG 和 LB 的行為；每半年的區域性撤離演練會提升 us-east1 中的讀取複本、將全球 LB 指向 us-east1 的後端，並衡量 RTO/RPO。演練的發現將推動改善，例如減少手動步驟或增加複本容量。

透過遵循這些步驟，Brightlane Retail 實現了具備自動自我修復能力的可用區高可用性，以及具備已定義且經過測試的維運手冊的區域性 DR 態勢，確保訂單資料滿足四小時的 RPO，且應用程式服務能在目標 RTO 範圍內復原。

← 安全性、合規性與資料保護 · 所有領域 · 成本管理、效能與容量最佳化 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →