Google PCA: 可靠性、災難復原與業務連續性 — 學習指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

總覽

可靠性、災難復原 (DR) 與業務連續性，旨在確保服務在元件、可用區或區域性故障的情況下，仍能持續滿足議定的目標。在 Google Cloud 上，可靠性的建構是透過理解故障域 (可用區級、區域級和全球級)、定義復原目標 (RTO/RPO)、選擇具備韌性的服務架構 (例如 active-active)，並嚴格測試復原計畫來達成的。您的設計必須將服務的關鍵性對應到明確的可用性目標、耐用性保證以及經過驗證的復原路徑，並在可用性、一致性、成本和維運複雜度之間取得平衡。關鍵主題包括：隔離單點故障、盡可能使用託管式複寫、自動化故障轉移決策，以及在類生產環境中持續驗證假設是否成立。

故障域、位置與多區域服務

• 可用區與區域：
  • 可用區是區域內獨立的故障域。可用區級的故障是您在設計時最常需要應對的大規模事件。
  • 區域是由多個具備低延遲連結的可用區所組成。區域級的故障較為罕見，但對於高度關鍵的系統而言，仍必須納入考量。
  • 設計模式：
    • 區域內 (Intra-region)：透過區域級託管執行個體群組 (MIGs)，將無狀態的運算資源部署在至少兩個可用區。
    • 跨區域 (Inter-region)：對於無法容忍區域性服務中斷的關鍵服務，進行狀態複寫與流量故障轉移。
• 多區域與全球性服務：
  • 全球控制平面：VPC 網路、Cloud DNS、全球外部 HTTP(S) 負載平衡以及 Cloud IAM 都是全球範疇的服務，可用於降低區域間的耦合。
  • 資料平面的位置至關重要：
    • Cloud Storage：根據存取模式和 DR 需求，選擇 regional、dual-region 或 multi-region 的儲存桶。
    • BigQuery：資料集位於某個區域或多區域位置；多區域可提高分析介面的可用性，但需考量資料落地和外部 join 的出口流量成本。
    • Spanner：執行個體設定 (regional 或 multi-regional) 定義了複本的拓撲和一致性行為。
• 故障域分析：
  • 將每個元件對應到其影響範圍。例如：
    • 可用區級：單一 VM、可用區級 GKE 節點池、可用區級 SSD PD。
    • 區域級：Cloud SQL HA 的主備執行個體是區域級的；某些維護事件可能會影響整個區域。
    • 全球級：設定錯誤的 IAM 或 Cloud DNS 會影響所有區域。
  • 識別關聯性故障，例如共享的依賴項 (如單一 NAT 閘道、單一 Memorystore 執行個體) 或人為風險 (共享的服務帳戶、單一 Terraform 狀態)。
  • 將配額視為一種故障域；當自動擴展器達到區域配額上限時，功能上等同於服務中斷。

權衡取捨：

• 跨可用區複寫可減少停機時間，但會增加跨可用區的流量和成本。
• 跨區域設計可降低 RTO，但會增加延遲、複雜度和開銷。
• 全球 anycast 負載平衡簡化了故障轉移，但只有在健康狀態檢查夠精確時，才能遮蔽不健康的後端。

目標、依賴性對應與 DR 驗證

• RTO 與 RPO：
  • 復原時間目標 (RTO)：恢復服務的目標時間。此目標驅動了自動化的深度、備援的整備程度以及操作手冊的詳細程度。
  • 復原點目標 (RPO)：可接受的資料遺失時間範圍。此目標驅動了複寫方式和備份頻率的選擇。
• 服務關鍵性與分級：
  • 定義服務層級 (例如，Tier 0：影響安全/財務；Tier 1：影響營收；Tier 2：內部工具)，並設定其目標 SLO、RTO/RPO 及測試頻率。
  • 將開銷和複雜度與服務層級掛鉤；並非每個服務都需要跨區域部署。
• 依賴性對應：
  • 盤點上游和下游的依賴項：身份 (Cloud IAM, SAML IdP)、密鑰 (Secret Manager, KMS)、網路 (DNS, Cloud Interconnect/VPN)、儲存與資料庫、可觀測性、CI/CD 以及第三方 API。
  • 為每個依賴項記錄其所在的區域、可用區和 SLA；為較弱的環節定義補償性控制措施。
• 復原計畫：
  • 為故障轉移/回復、資料還原以及設定提升 (DNS、負載平衡器後端、防火牆) 建立操作手冊和自動化腳本。
  • 預先配置權限和服務帳戶；準備好基礎設施定義，以消除手動關卡的阻礙。
  • 維護可供稽核的緊急存取權限 (break-glass access)。
• 復原測試：
  • 為有狀態的系統 (例如 Cloud SQL HA) 安排定期的故障轉移演練，以驗證主機提升和連線重新協商的過程。
  • 執行演習日 (game days)，模擬可用區或區域性中斷；演練應包含上游供應商以及 IAM/KMS 的故障情境。
  • 使用故障注入來驗證斷路器、超時和重試機制；確認自動擴展和背壓 (backpressure) 機制能如預期般運作。
  • 在測試期間持續衡量 RTO/RPO；當無法達成目標時，調整架構。

具備韌性的運算、資料庫與儲存模式

• 使用區域級 MIGs 與負載平衡達成自我修復的運算：
  • 使用區域級 MIGs 將執行個體分散到不同可用區，並具備自動擴展與自動修復功能。
  • 前端搭配一個全域外部 HTTP(S) 負載平衡器，並設定一個與真實就緒狀態一致的後端服務健康狀態檢查 (例如，/healthz 檢查相依服務)。
  • 允許健康狀態檢查通過防火牆，以避免 VM 不斷地被重新建立：

    gcloud compute firewall-rules create allow-lb-health-checks \
      --network=prod-vpc --action=ALLOW --direction=INGRESS \
      --rules=tcp:80,tcp:443 \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --target-tags=web-backend
    ```

  - 避免本機狀態；將 session 外部化至 Memorystore 或資料庫；在後端使用連線清空 (connection draining) 以在縮減規模期間保留進行中的請求。
  - 常見的故障模式：健康狀態檢查設定不當 (檢查過多或過少)、缺少防火牆規則，以及啟動程序相依於不健康的下游服務。
- Cloud SQL 的韌性：
  - 高可用性：主要執行個體與備用執行個體位於不同可用區，具備同步磁碟複製與自動容錯移轉；選擇一個維護期間並測試容錯移轉。
  - 唯讀複本：新增同區域或跨區域的唯讀複本以分擔讀取負載，並降低區域性事件的 RTO；在災難復原 (DR) 期間將複本提升為主執行個體。
  - 備份與時間點復原 (PITR)：
    - 啟用自動化每日備份與時間點復原 (PITR)，透過二進位/交易日誌達成，並為法規遵循與 RPO 設定足夠的保留期限。
    - 驗證還原至非生產環境的流程，並演練提升程序與應用程式連線字串的更新。
  - 網路：生產環境建議使用私有 IP；確保容錯移轉測試能驗證 DNS/連線池的行為。
  - 維運提示：定期執行一次受控的容錯移轉，以驗證應用程式連線池能乾淨地重新連線。

gcloud sql instances failover prod-sql
```

• Spanner 的設定與韌性：
  • 區域級執行個體使用 Paxos 演算法跨可用區運作，在單一區域內提供低延遲、強一致性的讀寫。
  • 多區域執行個體會跨區域複製資料，具備同步仲裁寫入 (全域強一致性) 與可選的唯讀複本；應選擇靠近寫入來源的區域作為主要區域 (leader region)。
  • 權衡取捨：多區域能改善 RTO/RPO 與讀取可用性，但會增加寫入延遲與成本。適用於需要強一致性的全球分散式、寫入密集型工作負載；否則應考慮使用區域級 Spanner 或帶有複本的 Cloud SQL。
• Cloud Storage 的耐用性與復原模式：
  • 位置策略：區域級 (regional) 用於鄰近運算資源，雙區域 (dual-region) 用於跨兩個區域的 active-active 架構，多區域 (multi-region) 為全球使用者提供廣泛的可用性。
  • 版本控制：啟用物件版本控制以從刪除或毀損中復原；結合生命週期規則來管理成本。
  • 保留政策：套用值區層級的保留政策，並在需要時為法規遵循使用保留鎖；使用事件型保留 (event-based holds) 進行記錄管理。
  • 備份模式：使用跨專案、獨立管理員的值區，以減輕意外刪除和權限提升的風險。對於資料庫，應將邏輯備份匯出到一個獨立專案中的 Cloud Storage。
  • 刪除超過 90 天舊版本的生命週期規則範例：

    {
      "rule": [
        {
          "action": { "type": "Delete" },
          "condition": { "age": 90, "isLive": false }
        }
      ]
    }
    ```

  - 使用以下指令套用：

gsutil lifecycle set lifecycle.json gs://prod-backups
```

• 復原：維護關鍵物件的目錄並測試還原；對於大型資料集，應將還原暫存到臨時值區，以避免名稱衝突並驗證資料完整性。

流量管理、多站點策略與持續性韌性

• 多站點策略：
  • 主動-主動 (Active-active)：同時從多個地區提供流量；需要對稱的資料複製與無衝突的寫入。擁有最佳的 RTO/RPO；但成本與複雜性最高。
  • 主動-被動 (Active-passive)：一個運作中的主要站點與一個就緒的次要站點；資料持續複製，在發生故障時切換流量。在成本與 RTO 之間取得良好平衡。
  • 暖備援 (Warm standby)：一個縮減規模的次要站點，已預先同步資料；在容錯移轉時需要擴展規模；RTO 與成本為中等。
  • 引導燈 (Pilot light)：僅複製最關鍵的資料與基礎設施定義；大部分元件在容錯移轉時才佈建；RTO 較長，穩定狀態成本低。
  • 冷備援 (Cold standby)：僅有定期備份；在故障時重新還原；RTO 最長，成本最低。
• DNS 與流量管理容錯移轉：
  • 偏好使用全球外部 HTTP(S) 負載平衡器，在 Layer 7 進行基於健康狀態的路由。它會對每個後端執行健康狀態檢查，並將流量從不健康的可用區或地區轉移，無需變更 DNS。
  • 僅將低 TTL 的 DNS 記錄用作粗略的容錯移轉控制，或用於在不相連的負載平衡器 VIP 之間切換；需了解 DNS 快取意味著容錯移轉並非即時發生。
  • 對於私有服務，使用內部 HTTP(S) 負載平衡搭配地區性容錯移轉模式，並加上可在需要時以程式化方式更新的私有 DNS。
• 優雅降級模式：
  • 實作功能旗標，以便在壓力下停用非關鍵功能。
  • 使用斷路器、逾時、帶有抖動的重試以及艙壁模式來將故障局部化。
  • 當寫入路徑受損時，提供唯讀模式；將寫入請求排入佇列以便稍後進行調節。
  • 對客戶端進行速率限制並施加反壓，以防止連鎖故障。
• 混沌測試與持續改進：
  • 在網路層（延遲、封包遺失）與應用程式層進行故障注入，以驗證韌性控制措施是否如設計般觸發。
  • 透過演習日 (Game days) 將跨團隊的復原流程操作化；包含呼叫、執行手冊的執行，以及附有具體修正措施的事後檢討。
  • 追蹤錯誤預算與 SLO；根據數據調整容量、重試策略與複製設定。
• 在可用性、一致性、成本與複雜性之間的權衡：
  • 可用性 vs. 一致性：強大的全球一致性（例如，Spanner 多地區架構）可能會增加寫入延遲；最終一致性（例如，非同步複本）可能會改善延遲，但有讀取到過時資料的風險。
  • 成本 vs. RTO/RPO：雙地區儲存與多地區資料庫會增加開銷，但能將資料遺失與停機時間降至最低。
  • 複雜性 vs. 可靠性：每個容錯移轉機制、複製串流與路由規則都必須進行操作與測試；盡可能保持設計簡單以達成目標。

實務問題情境

Acme Tickets 是一家快速成長的線上票務公司，必須確保其購買 API 與活動目錄在地區性中斷期間能夠持續運作，同時維持嚴格的 RTO/RPO（RTO ≤ 5 分鐘，RPO ≤ 1 分鐘）。其技術堆疊包含無狀態微服務、一個關聯式訂單資料庫、一個分析管線以及靜態媒體資產。

1. 定義服務層級、SLO 與復原目標

• 理由：將購買 API 與訂單資料庫分類為 Tier 0（RTO 5 分鐘，RPO 1 分鐘），目錄為 Tier 1（RTO 15 分鐘，RPO 5 分鐘），分析系統為 Tier 2（盡力而為）。這使成本與複雜性與業務衝擊保持一致。

2. 選擇地區部署與多站點策略

• 理由：對於無狀態服務，在 us-central1 與 us-east1 之間部署主動-主動 (active-active) 架構以最小化 RTO；對於訂單資料庫，使用主動-被動 (active-passive) 架構以平衡寫入延遲與成本。

3. 實作地區性 MIG 與全球 HTTP(S) 負載平衡

• 理由：兩個地區性 MIG（每個地區一個），各自散佈於至少兩個可用區。單一的全球任播 (anycast) VIP 透過經過健康狀態檢查的後端服務來路由流量，自動將不健康的地區移出。

4. 將狀態外部化並設定自我修復

• 理由：將會話儲存在 Memorystore 中，並為目錄設定跨地區讀取複本，同時保持服務為無狀態，這樣 MIG 的自動修復與滾動式更新才是安全的。健康狀態檢查指向 /healthz，該端點會驗證關鍵的下游服務。

5. 佈建具備 HA 與跨地區讀取複本的 Cloud SQL for PostgreSQL

• 理由：在主要地區使用 HA 以實現可用區層級的韌性，並啟用具有足夠保留期的 PITR。在次要地區建立一個跨地區讀取複本，並準備一份經過測試的執行手冊，以便在地區性故障時進行提升，從而以最少的寫入損失滿足 RPO ≤ 1 分鐘的要求。

6. 安排例行性的資料庫容錯移轉測試

• 理由：每月執行受控的容錯移轉，以驗證應用程式的重新連線行為與複本提升。這解決了一個常見的故障模式：在真實事件中從未成功提升過複本。

7. 將靜態媒體放置於具備版本控制與保留政策的雙地區 Cloud Storage 儲存桶

• 理由：雙地區可確保物件在兩個地區的可用性；版本控制可防止意外的覆寫/刪除。應用生命週期規則來過期舊版本並控制成本。

8. 使用防火牆與配額保護健康狀態檢查及出口流量

• 理由：為負載平衡器的健康狀態檢查建立明確的防火牆規則，並監控地區性執行個體配額，以防止在容錯移轉期間自動擴展器停滯。

9. 實作 DNS 作為低 TTL 的粗略控制機制

• 理由：雖然全球負載平衡器處理基於健康狀態的路由，但仍維持一個低 TTL 的 A 記錄指向一個備用 VIP，以備緊急手動切換之需，同時需了解 DNS 快取的限制。

10. 自動化 DR 執行手冊並透過演習日進行驗證

• 理由：使用 Cloud Scheduler 觸發綜合流量，並利用 Cloud Monitoring SLO 在每季的演習日中確認行為，同時注入故障（例如，阻斷地區間流量、終止節點）。擷取 RTO/RPO 指標並完善程序。

11. 保護並隔離備份資料

• 理由：將訂單資料庫的每日邏輯備份匯出到一個位於不同專案且設有保留鎖定的 Cloud Storage 儲存桶；定期還原到一個預備環境的執行個體，以驗證其完整性與所需時間。

12. 實作優雅降級

• 理由：如果訂單資料庫效能下降，將目錄切換為唯讀模式，將寫入請求排入佇列以便稍後調節，並捨棄非關鍵功能。這可以防止連鎖故障並維持部分服務運作。

此架構為無狀態服務提供了自動化的地區性容錯移轉，為有狀態元件提供了受控且經過測試的容錯移轉，並提供了經驗證的復原流程，滿足了 Acme Tickets 的業務連續性目標。

← 安全性、合規性與資料保護架構 · 所有領域 · 遷移、現代化與混合雲策略 →

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

瀏覽 Google →