HA vs DR：兩道不同的防線
高可用（High Availability, HA）和災難復原（Disaster Recovery, DR）是可靠性工程的兩根支柱，但它們解決的是完全不同的問題：
| 面向 | 高可用（HA） | 災難復原（DR） |
|---|---|---|
| 目標 | 預防停機——讓系統在元件故障時持續運作 | 從災難中復原——在大規模故障後恢復服務 |
| 故障範圍 | 單一元件、單一可用區 | 整個區域、資料中心，甚至自然災害 |
| 切換方式 | 自動（failover 在秒級完成） | 可能需要手動介入或自動化腳本觸發 |
| 成本模型 | 冗餘資源持續運行，成本較高 | 依策略而異，從備份到多站點成本差距巨大 |
| 設計時機 | 架構設計的基本要求 | 業務持續運營計畫（BCP）的一部分 |
關鍵觀念：HA 不能取代 DR，DR 也不能取代 HA。一個設計良好的系統同時需要兩者——HA 確保日常運作的穩定性，DR 確保極端情況下的存活能力。
💡 考試小提示：PCA 題目常混用 HA 和 DR 概念來測試理解深度。記住：HA 是「不要倒」，DR 是「倒了怎麼站起來」。
RPO/RTO 分析
架構師在設計 HA/DR 方案之前，必須先與業務方確認兩個關鍵指標：
- RPO（Recovery Point Objective） — 可容忍的最大資料遺失量。RPO = 1 小時代表最多可以丟失最近 1 小時的資料
- RTO（Recovery Time Objective） — 可容忍的最大停機時間。RTO = 15 分鐘代表系統必須在 15 分鐘內恢復服務
RPO/RTO 如何驅動架構決策
| RPO / RTO 目標 | 架構要求 | 成本等級 |
|---|---|---|
| RPO ≈ 0、RTO < 1 分鐘 | 同步複製 + Active-Active 多區域 + Global LB | $$$$$ |
| RPO < 5 分鐘、RTO < 15 分鐘 | 非同步複製 + Warm Standby + 自動 failover | $$$$ |
| RPO < 1 小時、RTO < 4 小時 | 定期快照 + Pilot Light + 自動化部署腳本 | $$$ |
| RPO < 24 小時、RTO < 24 小時 | 每日備份 + Cold Standby + 手動復原流程 | $$ |
核心原則：RPO/RTO 越嚴格，成本越高。架構師的職責不是追求最低的 RPO/RTO，而是找到業務需求與成本之間的最佳平衡點。不同的子系統可以有不同的 RPO/RTO 目標——付款系統需要 RPO ≈ 0，但行銷報表系統可能接受 RPO = 24 小時。
💡 考試小提示：題目給定明確的 RPO/RTO 需求時，先根據數值排除不符合的選項。RPO = 0 一定需要同步複製（如 Spanner），RPO = 幾小時則可用排程快照。
GCP 可用性層級
GCP 基礎設施提供多層次的可用性保障，每一層的成本和複雜度遞增：
| 層級 | 說明 | 可用性目標 | 年度允許停機 |
|---|---|---|---|
| Zonal | 單一可用區部署 | 99.9% | ~8.7 小時 |
| Regional | 跨同區域多可用區 | 99.99% | ~52 分鐘 |
| Multi-Regional | 跨多個區域（如 US、EU） | 99.999% | ~5.3 分鐘 |
| Global | 全球分散式（如 Spanner） | 99.999%+ | < 5 分鐘 |
注意 Zonal 和 Regional 之間的差距是 10 倍（99.9% → 99.99%），而這個差距在年度停機時間上代表從 8.7 小時縮短到 52 分鐘——這就是為什麼生產環境幾乎必須選擇 Regional 以上的部署模式。
HA 設計模式
Active-Active
兩個或多個區域同時處理流量，透過 Global HTTP(S) Load Balancer 分配請求。任一區域故障，流量自動路由到存活區域。
- 優勢：最低 RTO（接近零），資源利用率最高
- 挑戰：資料一致性（需要 Spanner 或 multi-master 架構）、應用必須設計為無狀態或處理衝突解決
- 適用：面向全球使用者的關鍵服務
Active-Passive（Warm Standby）
主區域處理所有流量，備援區域維持一個縮小規模的運行副本。故障時透過 Cloud DNS 切換流量或提升備援區域的資源規模。
- 優勢：成本低於 Active-Active，RTO 通常在分鐘級
- 挑戰：備援區域需要定期驗證是否真正可用
- 適用：區域級服務，接受分鐘級 RTO
Active-Passive（Cold Standby）
主區域處理所有流量，備援區域僅保留基礎設施定義（IaC 模板）和資料備份，不部署實際運行資源。
- 優勢：成本最低的跨區域保護方案
- 挑戰：RTO 較高（需要時間佈建資源和還原資料）
- 適用：非關鍵系統，可接受數小時 RTO
GCP 服務的 HA 配置
不同 GCP 服務的 HA 機制各異，以下是架構師必須掌握的關鍵配置：
| 服務 | HA 配置 | 故障切換 | 跨區域能力 |
|---|---|---|---|
| Compute Engine | MIG（Managed Instance Group）+ Autohealing | 自動重建故障實例，秒級偵測 | Multi-zone MIG 跨可用區分佈 |
| GKE | Regional Cluster（Control plane 跨 3 區）、Pod Disruption Budgets | 自動重新排程 Pod | Multi-cluster with Fleet 跨區域管理 |
| Cloud SQL | HA Configuration（同區域跨區自動 failover） | 自動，約 60 秒完成切換 | Cross-region Read Replicas，可手動提升為主實例 |
| Spanner | Multi-region configurations（如 nam6、eur5） | 自動，透明切換 | 原生全球分佈，同步複製，RPO = 0 |
| Cloud Run | 自動多可用區部署 | 透明，無需配置 | 需搭配 Global LB + 多區域部署 |
💡 考試小提示：Cloud SQL HA 是「同區域跨可用區」，不是跨區域！跨區域需要 Read Replica + 手動提升。需要跨區域自動 failover 且 RPO = 0，答案是 Spanner。
DR 策略層級
四種 DR 策略代表從低成本到高成本、從高 RTO 到低 RTO 的連續光譜：
| 策略 | 描述 | RTO | RPO | 相對成本 |
|---|---|---|---|---|
| Backup & Restore | 定期備份到異地，災難時從備份還原 | 數小時~數天 | 上次備份後的資料全部遺失 | 最低 |
| Pilot Light | 核心系統保持最小化運行（如資料庫複製），其餘資源災難時才佈建 | 數十分鐘~數小時 | 取決於複製延遲 | 低~中 |
| Warm Standby | 備援區域維持完整但縮小規模的運行副本 | 分鐘級 | 接近即時（非同步複製） | 中~高 |
| Multi-site Active-Active | 多區域同時處理流量，無需切換 | 接近零 | 接近零（同步複製） | 最高 |
選擇策略時的決策流程：業務關鍵性 → RPO/RTO 需求 → 預算限制 → 技術可行性。大多數企業會對不同系統採用不同策略——核心交易系統用 Active-Active，內部管理工具用 Backup & Restore。
Backup and DR Service
Google Cloud Backup and DR Service 是全代管的備份解決方案，為 HA/DR 架構提供堅實的資料保護基礎：
- 集中管理 — 在單一控制台管理跨專案、跨區域的備份策略，支援 Compute Engine、Cloud SQL、GKE 和 VMware 工作負載
- 應用一致性備份（Application-consistent Backups） — 支援 Oracle、SQL Server、SAP HANA 等企業應用的一致性備份，確保還原後資料完整可用
- 跨區域複製 — 備份資料自動複製到指定的備援區域，滿足地理隔離的 DR 要求
- 增量備份 — 僅備份變更的區塊，大幅降低備份時間和儲存成本
- 備份保險庫（Backup Vault） — 提供不可變備份（immutable backups），防止勒索軟體或惡意刪除，設定保留期內的備份無法被任何人刪除或修改
💡 考試小提示：題目提到「防止勒索軟體刪除備份」或「不可變備份」，答案指向 Backup and DR Service 的 Backup Vault 功能。
混沌工程：驗證你的 DR 計畫
一份從未測試過的 DR 計畫，和沒有 DR 計畫一樣危險。混沌工程（Chaos Engineering） 是透過主動注入故障來驗證系統韌性的實踐方法。
核心原則
- 建立穩態假設 — 定義系統正常運作的指標（如 p99 延遲 < 200ms、錯誤率 < 0.1%）
- 注入真實世界的故障 — 模擬可用區故障、網路分割、服務相依性中斷、磁碟故障
- 最小化爆炸半徑 — 從小範圍開始（單一 Pod），逐步擴大到可用區級別
- 在生產環境驗證 — 測試環境永遠無法完全模擬生產環境的複雜度
Game Day 實踐
Game Day 是團隊定期進行的 DR 演練：
- 模擬特定故障場景（如 us-central1 區域全面中斷）
- 驗證 failover 流程是否如預期運作
- 測量實際 RTO/RPO 是否符合 SLA 承諾
- 識別文件、流程和自動化的缺口
- 建議頻率：關鍵系統每季度至少一次，全面 DR 演練每年至少一次
在 GKE 環境中，可以使用 Pod Disruption Budgets 搭配故障注入來測試應用對 Pod 中斷的容忍度；在 Compute Engine 環境，可以利用 Maintenance Events 模擬 Live Migration 行為。
實戰情境
情境一：金融服務 99.99% SLA 的 HA 架構
背景：一家數位銀行的核心交易系統需要 99.99% 的可用性 SLA，監管要求交易資料不得遺失（RPO = 0），故障切換時間不得超過 60 秒（RTO < 1 分鐘）。
架構決策：
- 資料層 — 使用 Cloud Spanner multi-region configuration（nam6），同步複製確保 RPO = 0，自動 failover 完全透明
- 應用層 — GKE Regional Cluster 搭配 Pod anti-affinity 分散到所有可用區，設定 Pod Disruption Budget（minAvailable: 80%）確保升級時維持服務能力
- 流量管理 — Global External Application Load Balancer 搭配健康檢查，故障可用區自動排除，無需 DNS 切換
- 監控與警報 — 定義 SLI（成功交易率 > 99.99%、p99 延遲 < 500ms），設定 burn rate alert，在 SLO error budget 即將耗盡時主動告警
- DR 驗證 — 每季度 Game Day 模擬單一可用區故障，每年一次模擬整個區域故障的完整 DR 演練
情境二：電商平台的 DR 規劃（RPO < 1 分鐘）
背景：大型電商平台在促銷季單日 GMV 超過數億元，訂單資料庫在 asia-east1（台灣），需要 DR 方案確保即使整個區域故障也能在 15 分鐘內恢復，且訂單資料遺失不超過 1 分鐘。
架構決策：
- 資料庫 — Cloud SQL HA（主區域）+ Cross-region Read Replica（asia-northeast1）搭配非同步複製（replication lag 通常 < 10 秒），災難時手動提升 Replica 為主實例
- 備份策略 — Backup and DR Service 每 15 分鐘增量備份 + 跨區域複製至 asia-northeast1，Backup Vault 設定 30 天不可變保留
- 應用層 — asia-northeast1 預部署 Warm Standby（最小規模的 Cloud Run 服務 + 資料庫連線配置），Terraform IaC 腳本可在 10 分鐘內擴展至生產規模
- 切換機制 — Cloud DNS 搭配健康檢查，偵測主區域不可達後自動更新 DNS 記錄（TTL 設定 60 秒），搭配 Cloud Run functions 自動觸發 Read Replica 提升流程
- 定期驗證 — 每月模擬 failover 演練，驗證 Replica 提升流程和 DNS 切換的端到端 RTO
重點整理
- HA 是「不要倒」，DR 是「倒了怎麼站起來」 — 兩者缺一不可，共同構成系統的可靠性基礎
- RPO/RTO 驅動一切 — 先確認業務需求再設計架構，不同子系統可以有不同目標，越嚴格成本越高
- 四層可用性：Zonal（99.9%）→ Regional（99.99%）→ Multi-Regional（99.999%）→ Global（99.999%+）
- Cloud SQL HA 是同區域，跨區域需要 Read Replica + 手動提升；跨區域自動 failover + RPO = 0 選 Spanner
- 四種 DR 策略：Backup & Restore → Pilot Light → Warm Standby → Active-Active，依業務關鍵性和預算選擇
- Backup and DR Service 提供集中管理的跨區域備份，Backup Vault 實現不可變備份，防勒索軟體
- 混沌工程和 Game Day 是驗證 DR 計畫的唯一可靠方式——未經測試的 DR 計畫等於沒有計畫
下一步
在下一課中，我們將進入案例研究的實戰演練，解析 PCA 考試中的經典案例題型——包括如何從題目描述中提取架構需求、如何在多個合理方案中選出最佳答案，以及如何運用本課程所學的所有知識點進行系統性分析。