考慮為關鍵任務系統業務持續性的主要動機，是協助機構在發生故障事件期間和之後，都能維持營運並展現韌性。您可以將系統和資料複製到多個地理區域，並避免單一故障點，盡可能降低影響當地基礎架構的天災風險。其他失敗情境包括嚴重系統故障、網路安全攻擊，甚至是系統設定錯誤。
如要建立有效的業務持續性，就必須最佳化系統，使其能承受故障。系統可靠性會受到多項因素影響，包括但不限於效能、復原能力、正常運作時間可用性、安全性及使用者體驗。如要進一步瞭解如何在Google Cloud上架構及運作可靠的服務，請參閱 Google Cloud Well-Architected Framework 的可靠性支柱，以及可靠性的建構區塊 Google Cloud。
這個架構模式仰賴多個運算環境間的應用程式備援部署。在這個模式中，您會在多個運算環境中部署相同的應用程式，以提高可靠性。業務持續性是指組織在發生中斷事件後，能夠以預先定義的可接受程度，繼續提供重要業務功能或服務。
災難復原 (DR) 被視為業務持續性計畫的一部分，明確著重於 確保支援重要業務功能的 IT 系統在服務中斷後，能盡快恢復正常運作。一般來說，災難復原策略和計畫通常有助於制定更廣泛的業務持續性策略。從技術角度來看，開始制定災難復原策略時，業務影響分析應定義兩個重要指標：復原點目標 (RPO) 和復原時間目標 (RTO)。如要進一步瞭解如何使用 Google Cloud 解決災難復原問題，請參閱「災難復原規劃指南」。
RPO 和 RTO 目標值越小，服務從中斷事件復原的速度就越快，資料遺失量也越少。不過，這表示需要建構備援系統，因此成本較高。如果系統具備近乎即時的資料複製功能，且在發生故障事件後，能以相同規模運作，就會增加複雜度、管理負擔和成本。
選擇災害復原策略 或模式時，應以業務影響分析為依據。舉例來說，金融服務機構停機幾分鐘造成的財務損失，可能遠遠超過導入 DR 系統的成本。不過，其他產業的商家可能可以承受數小時的停機時間，而不會對業務造成重大影響。
在內部部署資料中心執行關鍵任務系統時，DR 的一種做法是在位於不同地區的第二個資料中心維護待命系統。不過，更符合成本效益的做法是將以公用雲端為基礎的運算環境用於容錯移轉。這種做法是業務持續性混合模式的主要推動因素。從成本角度來看，雲端特別有吸引力，因為您可以在未使用的情況下關閉部分 DR 基礎架構。如要降低災難復原解決方案的成本，企業可透過雲端解決方案接受 RPO 和 RTO 值可能增加的情況。
上圖說明如何將雲端做為容錯移轉或災害復原環境，用於地端環境。
這個模式的較不常見 (很少需要) 的子類為「業務持續性多雲端」模式。在該模式中，實際工作環境會使用一個雲端服務供應商，而 DR 環境會使用另一個雲端服務供應商。您可以將工作負載複本部署至多個雲端服務供應商，提高的可用性勝過多地區部署提供的可用性。
評估跨多個雲端的 DR 與使用單一雲端服務供應商的不同區域，需要深入分析多項考量因素，包括：
- 易管理性
- 安全性
- 整體可行性。
- 費用
- 如果持續進行跨雲端通訊，您可能需要支付多個雲端服務供應商的資料轉出費用，這筆費用可能相當高昂。
- 複製資料庫時，可能會產生大量流量。
- TCO 和管理跨雲端網路基礎架構的成本。
如果資料必須留在國內，才能符合法規要求，可以考慮使用位於國內的第二個雲端供應商做為 DR。使用第二個雲端服務供應商的前提是，無法使用內部部署環境建構混合設定。為避免重新設計雲端解決方案架構，理想情況下，第二個雲端服務供應商應在區域內提供您所需的所有功能和服務。
設計須知
- DR 預期：貴商家希望達成的 RPO 和 RTO 目標，應能推動 DR 架構和建構規劃。
- 解決方案架構：採用這種模式時，您需要複製現有內部部署環境的功能，以符合 DR 期望。因此，您需要評估重新託管、重構或重新架構應用程式的可行性和可行性，以便在雲端環境中提供相同 (或更最佳化) 的功能和效能。
- 設計及建構：在雲端環境中部署企業工作負載時，幾乎一律需要先建構登陸區。詳情請參閱 Google Cloud 中的登陸區設計。
災難復原 (DR) 啟動：在設計和規劃災難復原程序時，請務必考慮下列問題：
- 什麼情況會觸發 DR 情況？舉例來說，主要網站中特定函式或系統發生故障時，可能會觸發 DR。
- 如何叫用容錯移轉至 DR 環境？是手動核准程序，還是可以自動化，以達到低 RTO 目標？
- 應如何設計系統故障偵測和通知機制，以配合預期 RTO 叫用容錯移轉？
- 偵測到故障後，流量會如何重新導向至 DR 環境？
透過測試驗證這些問題的答案。
測試：徹底測試及評估容錯移轉至 DR 的情況，確保符合 RPO 和 RTO 預期。這樣一來，您就能更有把握在必要時叫用 DR。每當程序或技術解決方案有任何新變更或更新，請再次進行測試。
團隊技能：除非您的環境是由第三方管理，否則一或多個技術團隊必須具備相關技能和專業知識，才能在雲端環境中建構、運作及排解生產工作負載的問題。
優點
使用 Google Cloud 確保業務持續性有下列優點：
- 由於 Google Cloud 在全球各地有許多區域可供選擇，因此您可使用它將資料備份或複製到同一個大陸內的不同站點。您也可以將資料備份或複製到不同大陸上的站點。
- Google Cloud 可將資料儲存在 Cloud Storage 的雙區域或多區域 bucket 中。資料會以備援的形式儲存在最少兩個不同地理區域。儲存在雙區域和多區域值區的資料會使用預設複製功能，在不同地理區域間複製。
- 提供下列一或多個選項，以減少資本支出和營運費用，建構災難復原機制：
- 已停止的 VM 執行個體只會產生儲存空間費用，而且比正在執行的 VM 執行個體便宜相當多。因此您可以將維護冷待命系統的費用降至最低。
- 採用「用多少付多少」的收費模型，確保您只需要針對實際使用的儲存空間和運算能力進行付費。 Google Cloud
- 彈性功能 (例如自動調度資源) 可讓您視需要自動擴充或縮減 DR 環境。
舉例來說，下圖顯示在內部部署環境 (生產環境) 中執行的應用程式，該應用程式使用Google Cloud 的復原元件，搭配 Compute Engine、Cloud SQL 和 Cloud Load Balancing。在這個情境中，資料庫是使用以 VM 為基礎的資料庫或 Google Cloud 代管資料庫 (例如 Cloud SQL) 預先佈建，以便透過持續複製資料加快復原速度。您可以從預先建立的快照啟動 Compute Engine VM，在正常作業期間降低成本。完成這項設定後，如果發生故障事件，DNS 必須指向 Cloud Load Balancing 外部 IP 位址。
如要讓應用程式在雲端運作，您需要佈建網路和應用程式 VM。視目標 RTO 級別和公司政策而定，您可以手動或自動完成整個程序，包括叫用 DR、在雲端佈建工作負載，以及重新導向流量。
如要加快基礎架構佈建速度並自動執行這項作業，請考慮將基礎架構視為程式碼進行管理。您可以使用 Cloud Build (持續整合服務)，自動將 Terraform 資訊清單套用至環境。詳情請參閱「使用 Terraform、Cloud Build 和 GitOps 管理基礎架構式程式碼」。
最佳做法
使用業務持續性模式時，請考慮下列最佳做法：
- 建立記載基礎架構以及容錯移轉和復原程序的災難復原計畫。
- 根據業務影響分析和已識別的必要 RPO 和 RTO 目標，考慮採取下列動作：
- 如果您只備份資料，請考慮使用轉換模式。否則，網格模式可能是複製現有環境網路架構的好選擇。
- 盡可能減少在不同環境中執行的系統之間的依附元件，尤其是在同步處理通訊時。這些依附元件會降低效能及整體可用性。
避免核心分裂問題。如果您在環境間雙向複製資料，可能會遇到「Split Brain 問題」。如果兩個雙向複製資料的環境失去彼此間的通訊，就會發生「Split Brain 問題」。這種情況可能會導致兩個環境中的系統斷定對方無法使用，並認為自己擁有資料的專屬存取權。這可能會導致資料修改衝突。避免腦裂問題的常見方法有兩種：
- 使用第三個運算環境。系統可透過這個環境在修改資料前檢查群數。
允許在連線復原後，調解產生衝突的資料修改。
使用 SQL 資料庫時，您可以先禁止存取原始主要執行個體，再讓用戶開始使用新的主要執行個體，即可避免腦裂問題。詳情請參閱「Cloud SQL 資料庫災難復原」。
確保持續整合/持續推送軟體更新系統和成果存放區不會變成單點故障。當一個環境無法使用時，您仍然必須要能部署新版本或套用設定變更。
使用待命系統時，請確保所有工作負載在任何環境中都可使用。所有工作負載都應可攜式 (應用程式支援且可行)，這樣系統才能在環境間保持一致。如要採用這種做法，請考慮使用容器和 Kubernetes。使用 Google Kubernetes Engine (GKE)，可簡化建構和作業。
將待命系統的部署作業整合至 CI/CD 管道。這項整合可協助確保環境間採用一致的應用程式版本和設定。
請設定 DNS，並使用合理簡短的存留時間值，確保能夠快速套用 DNS 變更，萬一發生災難時，就能將使用者重新轉送至待命系統。
選取符合架構和解決方案行為的 DNS 政策和轉送政策。此外，您也可以將多個區域負載平衡器與 DNS 轉送政策結合，為不同用途 (包括混合式設定) 建立全域負載平衡架構。
使用多個 DNS 供應商。使用多個 DNS 供應商時，您可以：
- 提高應用程式和服務的可用性和韌性。
當混合式應用程式在地端部署和雲端環境皆具有依附元件，即可透過多供應商 DNS 設定，簡化這類應用程式的部署或遷移作業。
Google Cloud 提供以 octoDNS 為基礎的開放原始碼解決方案，協助您設定及操作多 DNS 供應商的環境。詳情請參閱「使用 Cloud DNS 建立多供應商公用 DNS」。
使用待命系統時，請使用負載平衡器建立自動容錯移轉。請注意，負載平衡器硬體可能會故障。
使用 Cloud Load Balancing，而非硬體負載平衡器，為使用這種架構模式時發生的某些情境提供支援。內部用戶端要求或外部用戶端要求可根據不同指標 (例如以權重為準的流量分配)，重新導向至主要環境或 DR 環境。詳情請參閱「全域外部應用程式負載平衡器的流量管理總覽」。
如果從 Google Cloud 其他環境傳出的資料量很高，請考慮使用 Cloud Interconnect 或 Cross-Cloud Interconnect。Cloud Interconnect 有助於提升連線效能，且如果流量符合特定條件，還可能降低傳出資料的移轉費用。詳情請參閱 Cloud Interconnect 定價。
建議您在 Google Cloud Marketplace 上使用偏好的合作夥伴解決方案，協助進行資料備份、複製和其他符合您需求的作業，包括 RPO 和 RTO 目標。
測試及評估 DR 叫用情境，瞭解與目標 RTO 值相比，應用程式從災難事件中復原的難易度。
加密傳輸中的通訊內容。為保護私密資訊，建議您加密所有傳輸中的通訊內容。如果需要在連線層進行加密，您可以根據選取的混合式連線解決方案，選擇各種選項。這些選項包括 VPN 通道、採用 Cloud Interconnect 的高可用性 VPN，以及 Cloud Interconnect 的 MACsec。