這份文件屬於Google Cloud Well-Architected Framework：金融服務 (FS) 觀點，概略說明在 Google Cloud設計、部署及操作可靠 FS 工作負載的原則和建議。這份文件探討如何將進階可靠性做法和觀測能力整合至架構藍圖。本文中的建議符合 Well-Architected Framework 的可靠性支柱。
對金融機構而言，可靠且具備韌性的基礎架構不僅是業務需求，也是法規要求。為確保Google Cloud 中的 FS 工作負載穩定可靠，您必須瞭解並降低潛在故障點、部署備援資源，並規劃復原作業。營運韌性是可靠性的結果。也就是承受、適應及從中斷情況中復原的能力。營運韌性可協助金融服務機構遵守嚴格的法規要求。並避免對客戶造成無法承受的傷害。
Google Cloud 中可靠性的重要建構模塊是區域、可用區和雲端資源的各種位置範圍：可用區、區域、多區域、全球。您可以透過下列方式提高可用性：使用代管服務、分配資源、實作高可用性模式，以及自動化程序。
法規要求
金融服務機構必須遵守監管機構嚴格的可靠性規定，例如美國聯邦準備系統、歐盟歐洲銀行監理機關和英國審慎監理局。全球監管機構都強調營運韌性，這對金融穩定和消費者保護至關重要。營運韌性是指抵禦中斷、有效復原及維持關鍵服務的能力。這需要採取協調一致的方法，管理技術風險和對第三方的依賴。
大多數管轄區的法規要求都有以下共同主題：
- 網路安全和技術韌性：強化網路威脅防禦能力，確保 IT 系統韌性。
- 第三方風險管理：管理將服務外包給資訊和通訊技術 (ICT) 供應商的相關風險。
- 營運持續性和事件應變：制定完善計畫，確保在服務中斷期間維持重要營運，並有效復原。
- 維護金融穩定：確保整體金融體系健全穩定。
本文件中的可靠性建議對應至下列核心原則：
優先採用多可用區和多區域部署
對於重要的金融服務應用程式，建議您使用多區域拓撲，分散在至少兩個區域，以及每個區域內的三個可用區。這種做法對於防範可用區和區域性服務中斷相當重要。法規通常會規定這種做法，因為如果某個可用區或區域發生故障，大多數管轄區都會認為第二個可用區發生嚴重中斷是可能發生的後果。這是因為當某個位置發生故障時，另一個位置可能會收到異常大量的額外流量。
建議您參考下列做法，提升對可用區和區域服務中斷的復原能力：
- 建議優先選用位置範圍較廣的資源。請盡可能使用區域性資源，而非可用區資源，並使用多區域或全域資源，而非區域性資源。這種做法有助於避免使用備份還原作業。
- 在每個區域中，請使用三個可用區，而非兩個。為處理容錯移轉，請將容量超額佈建至預估值的三分之一以上。
- 實作主動-主動部署，盡量減少手動復原步驟，例如：
- Spanner 等分散式資料庫提供內建備援機制，並可跨區域同步處理。
- Cloud SQL 的高可用性功能提供接近主動-主動的拓撲，並在各可用區中提供唯讀副本。區域之間的復原點目標 (RPO) 接近 0。
- 使用 Cloud DNS 將使用者流量分配到不同區域，並在各區域部署區域性負載平衡器。您也可以根據需求和重要性，考慮使用全域負載平衡器。詳情請參閱「多區域部署項目全域負載平衡的優點和風險」。
- 如要儲存資料，請使用 Spanner 和 Cloud Storage 等多區域服務。
消除單點故障
將資源分散到不同位置，並使用備援資源，避免任何單點故障 (SPOF) 影響整個應用程式堆疊。
請參考下列建議，避免單點故障：
- 避免只部署單一應用程式伺服器或資料庫。
- 使用代管執行個體群組 (MIG)，確保自動重新建立失敗的 VM。
- 實作負載平衡，將流量平均分配到可用資源。
- 為 Cloud SQL 等資料庫採用高可用性設定。
- 使用區域性永久磁碟和同步複製功能，提高資料可用性。
詳情請參閱「在 Google Cloud中為工作負載設計可靠的基礎架構」。
瞭解及管理匯總可用性
請注意，系統的整體或匯總可用性會受到系統各層或元件的可用性影響。應用程式堆疊中的層級數量與堆疊的匯總可用性成反比。請參考下列建議，管理匯總可用性：
使用公式 tier1_availability × tier2_availability × tierN_availability 計算多層級堆疊的匯總可用性。
下圖顯示由四項服務組成的多層級系統，其匯總可用性的計算方式：
在上圖中，每個層級的服務都提供 99.9% 的可用性，但系統的匯總可用性較低，為 99.6% (0.999 × 0.999 × 0.999 × 0.999)。一般來說，多層級堆疊的匯總可用性低於提供最低可用性的層級。
在可行的情況下，請選擇平行處理，而非鏈結。如果服務平行化，端對端可用性會高於個別服務的可用性。
下圖顯示使用鏈結和平行處理方法部署的兩項服務 A 和 B：
在上述範例中，兩項服務的服務水準協議均為 99%，因此匯總可用性會因實作方法而異：
- 鏈結服務的匯總可用性僅為 98% (.99 × .99)。
- 平行化服務的匯總可用性較高，達到 99.99%，因為每項服務都獨立運作，個別服務不會受到其他服務的可用性影響。匯總平行服務的公式為 1 − (1 − A) × (1 − B)。
選擇 Google Cloud 服務時，請考量其正常運作時間服務水準協議 (SLA)，確保應用程式堆疊的整體正常運作時間符合要求。
設計架構時，請權衡可用性、作業複雜度、延遲時間和成本。提高可用性通常會增加成本，但有助於滿足法規要求。
舉例來說，99.9% 的可用性 (三個九) 代表 24 小時內可能會有 86 秒的停機時間。相較之下，99% (兩個 9) 代表在相同期間內有 864 秒的停機時間，比三個 9 的可用性多出 10 倍。
如果是重要的金融服務，架構選項可能會受到限制。不過，請務必找出可用性需求，並準確計算可用性。進行這類評估，有助於您評估設計決策對架構和預算的影響。
實施完善的災難復原策略
針對不同的災難情境 (包括可用區和區域性中斷) 制定明確的計畫。明確的災難復原 (DR) 策略可讓您從中斷中復原，並在影響最小的情況下恢復正常營運。
災難復原和高可用性 (HA) 是不同的概念。一般來說，在雲端部署中，DR 適用於多區域部署，HA 則適用於區域部署。這些部署原型支援不同的複製機制。
- HA：許多代管服務預設會在單一區域內的可用區之間同步複製資料。這類服務支援零或接近零的復原時間目標 (RTO) 和復原點目標 (RPO)。這項支援可讓您建立主動-主動部署拓撲，不會有任何單一故障點。
- 災難復原：如果工作負載部署在兩個以上的區域，且您未使用多區域或全域服務，則必須定義複製策略。複製策略通常是非同步。請仔細評估這類複製作業對重要應用程式的 RTO 和 RPO 有何影響。找出容錯移轉所需的手動或半自動作業。
如果是金融機構，選擇容錯移轉區域時，可能會受到資料主權和資料落地相關法規的限制。如果您需要在兩個區域之間建立主動-主動拓撲，建議您選擇代管的多區域服務，例如 Spanner 和 Cloud Storage，尤其是在資料複製至關重要時。
請參考下列建議：
- 使用代管的多區域儲存服務來儲存資料。
- 建立永久磁碟中資料的快照，並將快照儲存在多區域位置。
- 使用區域或可用區資源時，請設定將資料複製到其他區域。
- 定期測試災難復原計畫，驗證計畫是否有效。
- 請留意 RTO 和 RPO，以及兩者與您所在管轄區金融法規規定的影響容忍度之間的關聯。
詳情請參閱「為雲端基礎架構服務中斷建立災難復原架構」。
使用代管服務
請盡可能使用代管服務，充分運用備份、高可用性和擴充性等內建功能。使用代管服務時，請參考下列建議：
- 使用 Google Cloud中的代管服務。提供服務水準協議支援的高可用性。此外，這些服務也提供內建備份機制和復原功能。
- 如需資料管理，請考慮使用 Cloud SQL、Cloud Storage 和 Spanner 等服務。
- 如需運算和應用程式託管服務，請考慮使用 Compute Engine 代管執行個體群組 (MIG) 和 Google Kubernetes Engine (GKE) 叢集。區域性 MIG 和 GKE 區域叢集可抵禦可用區中斷。
- 如要提高對區域服務中斷的復原能力，請使用代管多區域服務。
- 針對具有獨特特性的服務，判斷是否需要退場計畫，並定義所需計畫。FCA、PRA 和 EBA 等金融監管機構要求，如果與雲端服務供應商的關係結束，企業必須制定資料擷取和營運持續性的策略和應變計畫。公司必須在簽訂雲端合約前評估退出的可行性，且必須保有更換供應商的能力，同時不中斷營運。
- 確認您選擇的服務支援將資料匯出為 CSV、Parquet 和 Avro 等開放格式。確認服務是否採用開放式技術，例如 GKE 支援開放容器計畫 (OCI) 格式，或 Managed Service for Apache Airflow。
自動佈建基礎架構和復原程序
自動化有助於盡可能減少人為錯誤，並減少應對事件所需的時間和資源。使用自動化功能有助於確保更快從故障中復原，並獲得更一致的結果。請參考下列建議，自動佈建及復原資源：
- 使用 Terraform 等基礎架構即程式碼 (IaC) 工具，盡可能減少人為錯誤。
- 自動執行容錯移轉程序，減少手動介入。自動化回應也有助於降低故障的影響。例如，您可以使用 Eventarc 或 Workflows，自動觸發補救措施，因應稽核記錄中觀察到的問題。
- 使用自動調度資源功能，在容錯移轉期間增加雲端資源容量。
- 採用平台工程，在服務部署期間，自動在雲端拓撲中套用政策和防護措施，以符合法規要求。