Well-Architected Framework：金融服务 (FS) 视角中的本文档概述了在 中设计、部署和运营可靠 FS 工作负载的原则和建议。Google Cloud Google Cloud本文档探讨了如何将高级可靠性实践和可观测性集成到架构蓝图中。本文档中的建议与 可靠性支柱 的 Well-Architected Framework 保持一致。
对于金融机构而言，可靠且弹性的基础架构既是业务需求，也是监管要求。为了确保 Google Cloud 中的 FS 工作负载可靠，您必须了解并缓解潜在的故障 点、以冗余方式部署资源，并制定恢复计划。运营弹性是可靠性的结果。它是指吸收、适应和从中断中恢复的能力。运营弹性有助于 FS 组织满足严格的监管要求。它还有助于避免 无法容忍的损害 对客户。
可靠性的关键 构建块 包括 Google Cloud 区域、可用区以及云资源的各种位置范围：可用区级、区域级、多区域级、全球级。您可以通过使用托管式服务、分配资源、实现高可用性模式和自动化流程来提高可用性。
法规要求
FS 组织在监管 机构（例如美国 联邦储备系统 、欧盟 欧洲银行业管理局 和英国 审慎监管局 ）的严格可靠性要求下运营。在全球范围内，监管机构强调运营弹性，这对于金融稳定和消费者保护至关重要。运营弹性是指承受中断、有效恢复和维护关键服务的能力。这需要采取统一的方法来管理技术风险和对第三方的依赖。
大多数司法管辖区的监管要求都有以下共同主题：
- 网络安全和技术弹性：加强针对网络威胁的防御，并确保 IT 系统的弹性。
- 第三方风险管理：管理与将服务外包给信息和通信 技术 (ICT) 提供商相关的风险。
- 业务连续性和突发事件响应：制定稳健的计划，以 在中断期间维持关键运营并有效恢复。
- 保护金融稳定：确保更广泛的金融体系的稳健性和稳定性 。
本文档中的可靠性建议与以下核心原则相对应：
优先考虑多可用区和多区域部署
对于关键金融服务应用，我们建议您使用多区域拓扑，该拓扑分布在至少两个区域以及每个区域内的三个可用区中。这种方法对于应对可用区和区域服务中断至关重要。法规通常会规定这种方法，因为如果一个可用区或区域发生故障，大多数司法管辖区都会认为第二个可用区会受到严重中断的影响。其理由是，当一个位置发生故障时，另一个位置可能会收到异常高的额外流量。
请考虑以下建议，以构建针对可用区和区域服务中断的弹性：
- 首选位置范围更广的资源。尽可能使用区域级资源而不是可用区级资源，并使用多区域或全球级资源而不是区域级资源。这种方法有助于避免需要使用备份来恢复运营。
- 在每个区域中，利用三个可用区而不是两个。为了处理故障切换，将容量超额预配为估计容量的三分之一以上。
- 通过实现主动-主动部署（如以下示例）来最大限度地减少手动恢复步骤：
- Spanner 等分布式数据库提供跨区域的内置冗余和同步。
- Cloud SQL 的 高可用性功能 提供近乎主动-主动的拓扑，其中包含跨可用区的只读 副本。它提供区域间接近于 0 的恢复点目标 (RPO)。
- 使用 Cloud DNS 在区域之间分配用户流量，并 在每个区域中部署 区域级负载均衡器。全球负载均衡器是您可以根据需求和重要性考虑的另一个选项。如需了解更多 信息，请参阅 多区域部署的全球负载均衡的优势和风险。
- 如需存储数据，请使用 Spanner 和 Cloud Storage 等多区域服务。
消除单点故障
将资源分布在不同的位置，并使用冗余资源，以防止任何单点故障 (SPOF) 影响整个应用堆栈。
请考虑以下建议，以避免 SPOF：
- 避免仅部署单个应用服务器或数据库。
- 使用 托管式实例组 (MIG)确保自动重新创建失败的虚拟机。
- 通过实现 负载均衡，在可用资源之间均匀分配流量。
- 为 Cloud SQL等数据库使用高可用性配置。
- 通过使用 具有同步复制功能的区域级永久性磁盘 来提高数据可用性。
如需了解详情，请参阅 在 中为工作负载设计可靠的基础架构 Google Cloud。
了解和管理总体可用性
请注意，系统的总体可用性或 总体可用性受系统每个层级或组件的可用性的影响。应用堆栈中的层级数与堆栈的总体可用性具有反向关系。请考虑以下有关管理总体可用性的建议：
使用 公式 层级 1 可用性 × 层级 2 可用性 × 层级 N 可用性计算多层级堆栈的总体可用性。
下图展示了由四项服务组成的多层级系统的总体可用性计算：
在上图中，每个层级中的服务都提供 99.9% 的可用性，但系统的总体可用性较低，为 99.6% (0.999 × 0.999 × 0.999 × 0.999)。一般来说，多层级堆栈的总体可用性低于提供最低可用性的层级的可用性。
在可行的情况下，选择 并行化而不是 链接。对于并行化服务，端到端可用性高于每个单独服务的可用性。
下图展示了使用链接和并行化方法部署的两项服务 A 和 B：
在前面的示例中，这两项服务的 SLA 均为 99%，因此，根据实现方法，总体可用性如下：
- 链接服务 的总体可用性仅为 98% (.99 × .99)。
- 并行化服务 的总体可用性更高，为 99.99%，因为每项服务都是独立运行的，并且单独服务不受其他服务的可用性的影响。并行化服务的总体可用性公式为 1 − (1 − A) × (1 − B)。
选择 Google Cloud 具有正常运行时间 SLA 的服务，这些服务有助于满足 应用堆栈所需的总体正常运行时间级别。
在设计架构时，请考虑可用性、运营复杂性、延迟时间和费用之间的权衡取舍。提高可用性的 9 的数量通常会增加费用，但这样做有助于满足监管要求。
例如，99.9% 的可用性（三个 9）意味着 24 小时内可能会停机 86 秒。相比之下，99%（两个 9）意味着在同一时间段内停机 864 秒，这比三个 9 的可用性停机时间多 10 倍。
对于关键金融服务，架构选项可能有限。但是，确定可用性要求并准确计算可用性至关重要。执行此类评估有助于您评估设计决策对架构和预算的影响。
实现稳健的灾难恢复策略
为不同的灾难场景（包括可用区和区域服务中断）创建明确定义的计划。明确定义的灾难恢复 (DR) 策略可让您从中断中恢复，并以最小的影响恢复正常运营。
灾难恢复和高可用性 (HA) 是不同的概念。对于云部署，一般来说，灾难恢复适用于多区域部署，而高可用性适用于区域级部署。这些 部署原型 支持不同的复制机制。
- HA：许多托管式服务默认提供单个区域内可用区之间的同步复制。此类服务支持零或接近于零的恢复时间目标 (RTO) 和恢复点目标 (RPO)。 借助此支持，您可以创建没有任何 SPOF 的主动-主动部署拓扑。
- 灾难恢复：对于跨两个或多个区域部署的工作负载，如果 您不使用多区域或全球级服务，则必须定义 复制策略。复制策略通常是异步的。 仔细评估此类复制对关键应用的 RTO 和 RPO 的影响。确定故障切换所需的手动或半自动操作。
对于金融机构，您选择的故障切换区域可能会受到有关数据主权和数据驻留的法规的限制。如果您需要在两个区域之间实现主动-主动拓扑，我们建议您选择托管式多区域服务（如 Spanner 和 Cloud Storage），尤其是在数据复制至关重要的情况下。
请考虑以下建议：
- 使用托管式多区域存储服务存储数据。
- 截取永久性磁盘中的数据快照，并将快照存储在 多区域位置。
- 使用区域级或可用区级资源时，设置向其他区域的数据复制。
- 通过定期测试计划来验证灾难恢复计划是否有效。
- 了解 RTO 和 RPO 及其与您所在司法管辖区的金融法规规定的影响容忍度的相关性。
如需了解详情，请参阅 针对云基础架构服务中断设计灾难恢复架构。
利用托管式服务
尽可能使用托管式服务，以利用备份、高可用性和可伸缩性的内置功能。请考虑以下有关使用托管式服务的建议：
- 在 Google Cloud中使用托管式服务。它们提供由 SLA 支持的高可用性。它们还提供内置备份机制和弹性功能。
- 对于数据管理，请考虑 Cloud SQL、 Cloud Storage、 和 Spanner等服务，
- 对于计算和应用托管，请考虑 Compute Engine 托管式实例组 (MIG) 和 Google Kubernetes Engine (GKE) 集群。 区域 MIG 和 GKE 区域级集群能够灵活应对可用区服务中断。
- 如需提高应对区域服务中断的弹性，请使用托管式多区域服务。
- 确定具有独特特征的服务是否需要 退出计划，并定义所需的计划。FCA、PRA 和 EBA 等金融监管机构要求公司制定策略和应急计划，以便在与云服务提供商的关系终止时检索数据并保持运营连续性。公司必须在签订云合约之前评估退出可行性，并且必须保持在不中断运营的情况下更换提供商的能力。
- 验证您选择的服务是否支持将数据导出为 CSV、Parquet 和 Avro 等开放格式。验证服务是否 基于开放技术，例如 GKE 对 开放容器倡议 (OCI) 格式 的 支持，或者基于 Apache Airflow 构建的 Managed Service for Apache Airflow。
自动执行基础架构预配和恢复流程
Automation 有助于最大限度地减少人为错误，并有助于减少响应突发事件所需的时间和资源。使用自动化有助于确保更快地从故障中恢复并获得更一致的结果。请考虑以下建议，以自动执行资源预配和恢复方式：
- 使用 Terraform 等基础架构即代码 (IaC) 工具最大限度地减少人为错误。
- 通过自动执行故障切换流程来减少手动干预。自动响应还有助于减少故障的影响。例如，您 可以使用 Eventarc 或 Workflows 自动触发补救措施，以响应通过审核日志观察到的问题。
- 通过使用自动扩缩，在故障切换期间增加云资源的容量。
- 通过采用 平台工程，在服务部署期间自动为云拓扑应用法规要求的政策和防护措施 。