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