PCA 雲端架構師之旅 12 — 災難復原 (DR)

第 11 步處理的是「單 zone、單 region 內某個元件壞掉」這種事——autoscaling、HA、健康檢查都能接得住。但 PCA 還會問你更難看的場景：整個 region 一整天不見、光纖被怪手挖斷、機房泡水。這時候 autoscaling 救不了你，能救你的是事先寫好的 DR 計畫。

DR 講到底就兩個字母組合：RTO 跟 RPO。你能聽懂這兩個詞、能把它們翻成「所以資料庫要怎麼配、bucket 要選哪種 location」，這一篇的核心你就拿到手了。

這是 PCA 雲端架構師之旅 的第 12 步，也是案例題裡幾乎一定會出現的一塊。

---

先把 RTO 和 RPO 分清楚，不然全盤皆錯

這兩個詞長得像、又老是一起出現，考生最容易搞混。講白話：

RTO（Recovery Time Objective）是「災難發生後，多久之內服務要重新跑起來」。RPO（Recovery Point Objective）是「災難那一刻，你最多能接受丟掉多久的資料」。一個量時間、一個量資料，彼此獨立。

case study 不會直接寫「RTO = 1 小時」這麼方便，它會包在情境句裡，等你自己翻譯：

• 「主 region 失效後，服務必須在 1 小時內恢復」→ 這是在講 RTO
• 「最多可以接受遺失 15 分鐘的交易資料」→ 這是在講 RPO
• 「金流系統零資料遺失」→ RPO = 0，而 RPO = 0 幾乎就等於「你得做同步複寫」

第三句是陷阱重災區。看到「零資料遺失」就要反射性地想到同步複寫，而同步複寫是有代價的——後面會講。

我看過不少團隊把 DR 文件寫得漂漂亮亮，RTO、RPO 一欄一欄填好，結果真的出事那天才發現：備份是有，但沒人知道怎麼把服務拉起來。備份是「資料救得回來」，DR 是「服務跑得起來」，這是兩件事。 只有備份、沒有演練過的啟動流程，在考場上會被當成沒做 DR，在現實裡會讓你那天晚上很難熬。

📝 考場提點

遇到 DR 題，第一個動作永遠是：把題目句子翻成 RTO 和 RPO 兩個數字，寫在草稿紙上。「1 小時內恢復」=RTO 1h、「可接受遺失 15 分鐘」=RPO 15m、「零遺失」=RPO 0。翻錯方向（把 RTO 當 RPO）後面整題就歪了。看到「零資料遺失」「金流」「不能停機」這種字眼，先把同步複寫、active-active 圈起來；看到「分析資料」「日誌」「瀏覽紀錄」這種非關鍵字眼，就往便宜的備份方案靠。

---

四種 DR 策略，貴的不一定對

DR 不是「做好做滿」就是對的。它是一條從便宜到貴的光譜，你要做的是把每個系統放到對的位置上，而不是全部塞進最貴的那一格。四種常見策略，以及它們大致能達到的 RTO / RPO（用登雲書店量級當參考，實際數字依設計而定）：

策略	RTO	RPO	成本	何時選
Backup & Restore	小時到天	小時（看備份頻率）	最低	非關鍵系統、預算有限
Pilot Light	數十分鐘	分鐘	中低	DR region 只有核心元件，需要時放大
Warm Standby	分鐘	秒到分鐘	中高	DR region 全副部署但低規模運行
Multi-region Active-Active	接近 0	接近 0	最高	金融、不能停機、全球低延遲

這張表值得背，但更值得理解背後的邏輯：往上一格，RTO/RPO 變短，成本就往上跳。Active-Active 等於把整套系統蓋兩份、兩邊都在線上吃流量，成本接近翻倍。Backup & Restore 平時幾乎不花錢，但出事那天你得從零把環境重建出來，慢是必然的。

現實裡最常見的浪費，是把所有東西都拉到 Active-Active。我看過團隊連「使用者上傳的瀏覽縮圖快取」都做跨 region 同步複寫，帳單出來才發現一大半的錢花在一份丟了也沒人在乎的資料上。DR 設計的功夫，八成在分層——哪些系統值得花大錢、哪些丟幾小時也無所謂。

兩個定義務必記死，考試常直接考字面：

• RTO（Recovery Time Objective）：從災難發生到服務恢復的最長可容忍時間
• RPO（Recovery Point Objective）：災難發生時最多可容忍遺失的資料時間窗

---

GCP 上你會用到哪些工具

策略選好了，落到 GCP 上就是這幾樣東西在撐：

• Cloud Storage 跨 region 複製——dual-region 或 multi-region bucket，物件自動跨地理位置存放。
• Cloud SQL cross-region read replica——非同步複寫，這四個字後面會反覆出現，因為它直接決定你能不能宣稱 RPO = 0（答案是不能）。需要更高一階的話，升級到 Spanner 拿到跨 region 同步複寫。
• Spanner 多 region instance——同步複寫、全球單一邏輯資料庫，寫入經單一 leader region 協調，可做到跨 region 讀寫高可用。
• Cloud DNS failover routing policy——健康檢查掛了就自動把流量導去 DR region 的 LB。
• Persistent Disk snapshot 跨 region——multi-regional snapshot，VM 那一層的救命稻草。

這裡有個 PCA 最愛埋的地雷，務必記牢：Cloud SQL 的 cross-region read replica 是非同步複寫，本質上就有延遲（lag），所以它永遠做不到 RPO = 0。 題目給你「RPO = 0」配「Cloud SQL cross-region read replica」這個組合，幾乎一定是錯的選項。要 RPO = 0，你的牌只有同步複寫——在 GCP 上實務就是 Spanner。

---

走一遍範例 — 登雲書店

登雲書店這種規模，最忌諱「整站一個 DR 等級」。書店裡的訂單金流跟首頁的商品縮圖，重要程度差了十萬八千里，DR 目標當然要分層。把系統拆開來看：

金流與訂單（極關鍵）

• 目標：RTO < 15 分鐘、RPO ≈ 0
• 策略：Multi-region Active-Active 或接近的方案
• 實作：Spanner 配置 nam-eur-asia1（多 region），訂單服務部署在兩個 region，Global LB 自動路由
• 成本取捨：貴，但金流的錢一分都不能丟，這裡省不得

會員資料（關鍵）

• 目標：RTO < 1 小時、RPO < 5 分鐘
• 策略：Warm Standby
• 實作：Cloud SQL PostgreSQL HA 在 asia-east1，另加一個 cross-region read replica 在 asia-northeast1。DR 啟動時 promote replica 成新 primary
• 關鍵檢核：每季演練一次 failover，驗證 RTO 真的達標——別只在文件上寫達標

商品圖片與靜態資源

• 目標：RTO ≈ 0、RPO < 15 分鐘（需啟用 turbo replication）
• 策略：dual-region Cloud Storage bucket
• 實作：bucket location 設為 configurable dual-region（asia-east1 彰化 + asia-northeast1 東京，而非預定義的 asia1，因為 asia1 實際是 asia-northeast1 東京 + asia-northeast2 大阪），並啟用 turbo replication 以取得 15 分鐘 RPO（SLA 保證）；未啟用時預設複寫 RPO 為 12 小時（通常 1 小時內完成），自動雙向複寫

瀏覽紀錄（非關鍵）

• 目標：RTO < 24 小時、RPO < 4 小時
• 策略：Backup & Restore
• 實作：Bigtable 每 4 小時 export 到 GCS multi-region bucket。災難時重建 Bigtable cluster，從最近的 backup 匯入
• 理由：瀏覽紀錄掉幾小時不影響核心業務，不值得砸 active-active 的錢

流量切換機制

• Cloud DNS 設 failover routing policy，health check 連到 asia-east1 的 Global LB
• DR region 的 Global LB 平時關閉，DR 演練時手動啟用或用 Terraform 快速布建——這就是 pilot light 的概念：平時只留最小骨架，需要時才放大

注意這四層怎麼對應到前面那張表：金流是 Active-Active、會員是 Warm Standby、圖片靠 dual-region bucket 的內建複寫、瀏覽紀錄是 Backup & Restore。同一個案例裡四種策略並存，這才是真實架構長的樣子，也是考題想看你會不會分層的地方。

dual-region bucket 掛了一邊會怎樣

PCA 實務題很愛追問這個細節：「商品圖片的 dual-region bucket，如果 asia-east1 掛了，讀寫會怎樣？」

讀的部分會自動切到另一個 region 的副本，使用者大概無感。寫就沒那麼漂亮了——會暫時失敗，要等到 Google 把 bucket 的 metadata primary 切換過去（通常是分鐘級）才恢復。

關鍵在於：dual-region 的複寫是非同步的。 所以 RTO 趨近於 0，因為已經複寫過去的資料在區域故障時還讀得到；但 RPO 沒辦法接近 0，因為區域一掛，那些還沒複寫完的資料就跟著沒了。遺失窗口有多大，取決於你有沒有開 turbo replication：預設最壞是 12 小時（99.9% 的物件 1 小時內完成）；開了 turbo 則是 15 分鐘 SLA。

所以結論很清楚：真要 RPO < 1 分鐘，光靠 dual-region 的預設複寫絕對不夠，得另外上同步機制。這也是為什麼登雲書店的金流走 Spanner、圖片才走 dual-region bucket——兩者對「丟資料」的容忍度根本不在同一個量級。

📝 考場提點

dual-region / multi-region bucket 是考場上最容易被誤用的 DR 工具。記住兩件事：一、它的跨 region 複寫是非同步的，所以能給你很低的 RTO，但給不了 RPO = 0；二、預設複寫的 RPO 是小時級（最壞 12 小時），要壓到 15 分鐘得另外付費開 turbo replication。題目若要求「物件級的 RPO = 0」，dual-region bucket 直接刷掉，別被它「自動複製」的賣相騙了。同理，資料庫題目要 RPO = 0，Cloud SQL 非同步 read replica 也直接刷掉，往 Spanner 想。

---

那些災難演練教會我的事

寫到這裡，有幾個坑是文件上看不出來、要真的跑過一次 DR 才會痛的，順手分享給你。

備份跟它要保護的東西放在一起，等於沒備份。 把備份丟在 asia-east1 的 bucket，結果 asia-east1 整個 region 掛了，備份跟著一起消失——這種事比你想的常見。DR 用的備份一定要放 multi-region 或 dual-region bucket，或至少複製到另一個 region 去。考題很愛用這招測你有沒有真的想清楚「災難範圍」。

沒演練過的 DR，等於沒有 DR。 考試問「你怎麼確認 DR 計畫真的有用？」標準答案是定期演練（game day / DR drill），通常每季或每半年一次。我自己的經驗是，第一次玩真的 game day，幾乎沒有一次是順順跑完的——不是 IAM 權限在 DR region 沒開、就是某個寫死的 endpoint 還指著舊 region、不然就是 promote replica 的 runbook 上一個人離職後就沒人維護過。文件裡寫 RTO 30 分鐘很容易，沒演練過的 30 分鐘，出事那天通常會變成好幾個小時。

「同步複寫」不是免費的零延遲魔法。 Spanner 跨 region 寫入背後是 Paxos 多數派投票，要等多個 region 確認，單筆寫入延遲會從個位數 ms 跳到數十 ms。這對金流可能完全可以接受，但如果你把一個寫入很頻繁、又對延遲敏感的系統硬塞進跨 region Spanner，使用者是會有感的。所以前面才說 RPO = 0 有代價——代價就是這個延遲，你得在應用端先評估扛不扛得住。

---

延伸閱讀

• Google Cloud DR 規劃指南
• Cloud Storage 地理冗餘
• Cloud SQL 跨 region 複寫
• Spanner 多 region 設定

---

下一步：DR 把「整個 region 不見」也補上了，整套架構的可靠性骨架到這就齊了。最後一篇我們收尾，把安全與成本這兩條貫穿全程的主線一次講透。

系列導航

• 系列首頁：PCA 雲端架構師之旅
• 上一篇：PCA 雲端架構師之旅 11 — 可靠性與擴展性
• 下一篇：PCA 雲端架構師之旅 13 — 安全與成本

🎯 換你練習

理論讀完，換自己來。到 架構師設計工作坊 · 步驟 12 填入你的 case study，邊寫邊內化。