Well-Architected Framework：金融服务 (FS) 视角

Last reviewed 2025-07-28 UTC

Google Cloud Well-Architected Framework 中的本文档介绍了相关原则和建议，可帮助您在 Google Cloud 中设计、构建和管理金融服务 (FS) 应用，以满足您的运营、安全、可靠性、费用和性能目标。

本文档的目标受众群体包括在 Google Cloud中设计、构建、部署和维护 FS 工作负载的决策者、架构师、管理员、开发者和运维人员。可从本指南中受益的金融服务组织包括银行、支付基础设施参与者、保险提供商和资本市场运营商。

金融服务组织有特定的注意事项，尤其是在架构和恢复能力方面。这些考虑因素主要受法规、风险和性能要求的影响。本文档基于我们在全球范围内众多金融服务客户中观察到的设计考虑因素，提供了一些高级别指导。无论您的工作负载是完全在云中运行，还是正在向混合云或多云部署过渡，本文档中的指导都有助于您在 Google Cloud 上设计工作负载，以满足您的监管要求和不同的风险视角。这些指南可能无法解决每个组织的独特挑战。它提供了一个基础，可满足金融服务组织 (FS) 的许多主要监管要求。

设计云工作负载时面临的主要挑战之一是将云部署与本地环境保持一致，尤其是在您希望采用一致的安全、可靠性和弹性方法时。云服务为您提供了从根本上重新思考架构的机会，从而减少管理开销、优化成本、增强安全性并提高可靠性和弹性。

以下页面介绍了 Well-Architected Framework 的每个核心中特定于 FS 工作负载的原则和建议：

贡献者

作者：

其他贡献者：

金融服务视角：卓越运营

Google Cloud Well-Architected Framework：金融服务 (FS) 视角中的本文档概述了在 Google Cloud中构建、部署和运营稳健的 FS 工作负载的原则和建议。这些建议可帮助您设置可观测性、自动化和可伸缩性等基本元素。本文档中的建议与 Well-Architected Framework 的卓越运营核心相一致。

对于 Google Cloud 中的金融服务 (FS) 工作负载，卓越的运营至关重要，因为此类工作负载受到严格监管且非常敏感。卓越运营可确保云解决方案能够适应不断变化的需求，并满足您在价值、性能、安全性和可靠性方面的要求。这些方面的失误可能会导致严重的财务损失、监管处罚和声誉损害。

卓越运营可为 FS 工作负载带来以下优势：

  • 维护信任和声誉：金融机构非常依赖客户的信任。运营中断或安全违规行为会严重削弱这种信任，并导致客户流失。卓越的运营有助于最大限度地降低这些风险。

  • 满足严格的监管合规性要求：金融服务受众多复杂法规的约束，例如：

    完善的运营流程、监控和突发事件管理对于证明符合法规要求和避免处罚至关重要。

  • 确保业务连续性和弹性：金融市场和服务通常持续运营。因此，高可用性和有效的灾难恢复至关重要。卓越运营原则可指导弹性系统的设计和实现。可靠性支柱可在此方面提供更多指导。

  • 保护敏感数据：金融机构会处理大量高度敏感的客户数据和财务数据。为了防止数据泄露并维护隐私，必须采取严格的运营控制措施、安全监控措施和快速的突发事件响应措施。安全性支柱可在此方面提供更多指导。

  • 针对关键应用优化性能：许多金融应用（例如交易平台和实时分析）需要高性能和低延迟。为了满足这些性能要求，您需要高度优化的计算、网络和存储设计。性能优化支柱可在此方面提供更多指导。

  • 有效管理费用：除了安全性和可靠性之外，金融机构还非常关注成本效益。卓越运营包括优化资源利用率和管理云支出的实践。“费用优化”支柱可在此方面提供更多指导。

本文档中的卓越运营建议与以下核心原则相对应：

定义 SLA 以及相应的 SLO 和 SLI

在许多金融服务组织中，应用的可用性通常根据恢复时间目标 (RTO) 和恢复点目标 (RPO) 指标进行分类。对于面向外部客户的业务关键型应用，可能还需要定义服务等级协议 (SLA)。

SLA 需要一个指标框架，该框架从用户满意度的角度代表系统的行为。 站点可靠性工程 (SRE) 实践提供了一种实现所需系统可靠性水平的方法。创建指标框架需要定义和监控关键的数值指标，以便从用户的角度了解系统健康状况。例如，延迟时间和错误率等指标可量化衡量服务的性能。 这些指标称为服务等级指标 (SLI)。制定有效的 SLI 至关重要，因为它们可提供客观评估可靠性所需的原始数据。

如需定义有意义的 SLA、SLI 和 SLO，请考虑以下建议：

  • 为每项关键服务开发并定义 SLI。设置用于定义可接受性能水平的目标值。
  • 制定并定义与 SLI 对应的服务等级目标 (SLO)。例如，SLO 可以规定 99.9% 的请求的延迟时间必须小于 200 毫秒。
  • 确定如果服务未达到 SLO，必须采取哪些内部补救措施。例如，为了提高平台的弹性，您可能需要将开发资源集中用于修复问题。
  • 验证每项服务的 SLA 要求，并将 SLA 视为与服务用户的正式合同。

服务等级示例

下表提供了支付平台的 SLI、SLO 和 SLA 示例：

业务指标 SLI SLO 服务等级协议 (SLA)
付款交易成功

一种定量指标，用于衡量成功处理并确认的所有已发起付款交易的百分比。

示例：（成功交易次数 ÷ 有效交易总次数）× 100，在滚动 5 分钟窗口内进行衡量。

一个内部目标值，用于在特定时间段内保持较高的成功付款交易百分比。

示例：在滚动 30 天的时间窗口内，将付款交易成功率保持在 99.98%，不包括无效请求和计划维护。

对付款交易处理的成功率和速度的合同保证。

示例：服务提供商保证，客户发起的 99.0% 的付款交易将在 1 秒内成功处理并确认。
付款处理延迟时间

从客户发起付款交易到最终确认付款交易的平均处理时间。

示例：交易确认的平均响应时间（以毫秒为单位），在 5 分钟的滚动窗口内进行衡量。

支付交易处理速度的内部目标值。

示例：确保在滚动 30 天的时间窗口内，99.5% 的付款交易在 400 毫秒内处理完毕。

一项合同承诺，即在指定的时间范围内解决严重的付款处理问题。

示例：对于严重的付款处理问题（定义为影响超过 1% 交易的服务中断），服务提供商承诺在问题报告或检测到后的两小时内解决。
平台可用性

核心支付处理 API 和用户界面可供客户正常运行和访问的时间百分比。

示例：（总运行时间 - 停机时间）/ 总运行时间 × 100，按分钟计算。

核心支付平台的正常运行时间内部目标。

示例：实现每个日历月 99.995% 的平台可用性，不包括计划内维护窗口。

就支付平台的最低正常运行时间向客户做出的正式的、具有法律约束力的承诺，包括未达到该最低正常运行时间的后果。

示例：平台在每个日历月内将保持至少 99.9% 的可用性，但计划维护窗口除外。如果可用性低于最低水平，客户将获得服务补偿，每下降 0.1% 即可抵扣每月服务费的 5%。

使用 SLI 数据监控系统是否在定义的 SLO 范围内，并确保达到 SLA。通过使用一组明确定义的 SLI，工程师和开发者可以监控以下级别的 FS 应用：

  • 直接在部署应用的 GKE 或 Cloud Run 等服务中。
  • 通过使用基础架构组件（例如负载均衡器）提供的日志。

OpenTelemetry 提供了一个开源标准和一组技术，用于捕获所有类型的遥测数据，包括指标、跟踪记录和日志。 Google Cloud Managed Service for Prometheus 提供全托管式、高度可伸缩的后端，用于大规模处理 Prometheus 的指标和操作。

如需详细了解 SLI、SLO 和错误预算，请参阅 SRE 手册。

如需开发有效的提醒和监控信息中心及机制，请将 Google Cloud Observability 工具与 Google Cloud 监控搭配使用。如需了解安全专用监控和检测功能，请参阅安全支柱。

定义和测试突发事件管理流程

定义明确且定期测试的突发事件管理流程可直接提升 Google Cloud中 FS 工作负载的价值、性能、安全性和可靠性。这些流程有助于金融机构满足严格的监管要求、保护敏感数据、维持业务连续性并赢得客户信任。

定期测试事件管理流程可带来以下好处：

  • 在高峰负载下保持性能：通过定期进行性能和负载测试，金融机构可以确保其基于云的应用和基础设施能够应对交易量高峰、市场波动和其他高需求场景，而不会出现性能下降。此功能对于保持顺畅的用户体验和满足金融市场的需求至关重要。
  • 找出潜在的瓶颈和限制：压力测试可将系统推向极限，使金融机构能够在潜在的瓶颈和性能限制影响关键运营之前发现它们。这种主动式方法可帮助金融机构调整其基础设施和应用，以实现最佳性能和可伸缩性。
  • 验证可靠性和弹性：定期测试（包括混沌工程或模拟故障）有助于验证金融系统的可靠性和弹性。此测试可确保系统能够从故障中顺利恢复并保持高可用性，这对于业务连续性至关重要。
  • 执行有效的容量规划：性能测试可提供有关不同负载条件下的资源利用率的宝贵数据，这对于准确的容量规划至关重要。金融机构可以利用这些数据主动预测未来的容量需求，并避免因资源限制而导致性能问题。
  • 成功部署新功能和代码变更：将自动化测试集成到 CI/CD 流水线中，有助于确保变更和新部署在发布到生产环境之前经过全面验证。这种方法可显著降低可能导致运营中断的错误和回归风险。
  • 满足系统稳定性方面的监管要求：金融法规通常要求机构采取可靠的测试实践，以确保其关键系统的稳定性和可靠性。定期测试有助于证明符合这些要求。

如需定义和测试突发事件管理流程，请考虑以下建议。

制定明确的突发事件响应流程

一套完善的突发事件响应程序包含以下要素：

  • 为突发事件指挥官、调查员、沟通员和技术专家定义的角色和职责，以确保有效且协调的响应。
  • 已定义的通信协议和升级途径，以确保在突发事件期间及时有效地共享信息。
  • 记录在 runbook 或 playbook 中的程序，其中概述了沟通、分诊、调查和解决步骤。
  • 定期培训和准备，让团队掌握有效应对所需的知识和技能。

定期实施性能和负载测试

定期进行性能和负载测试有助于确保基于云的应用和基础架构能够处理峰值负载并保持最佳性能。负载测试会模拟真实的流量模式。压力测试会使系统达到极限，以找出潜在的瓶颈和性能限制。您可以使用 Cloud Load Balancing 等产品和负载测试服务来模拟实际流量。根据测试结果，您可以调整云基础架构和应用，以实现最佳性能和可伸缩性。例如，您可以调整资源分配或调整应用配置。

在 CI/CD 流水线中自动执行测试

将自动化测试纳入 CI/CD 流水线有助于在部署前验证更改，从而确保云应用的质量和可靠性。这种方法可显著降低出错和回归的风险，并有助于您构建更稳定、更强大的软件系统。 您可以在 CI/CD 流水线中纳入不同类型的测试，包括单元测试、集成测试和端到端测试。使用 Cloud Build 和 Cloud Deploy 等产品创建和管理 CI/CD 流水线。

持续改进和创新

对于云中的金融服务工作负载，迁移到云只是第一步。持续改进和创新至关重要，原因如下：

  • 加快创新速度：利用 AI 等新技术来改进您的服务。
  • 降低成本：消除低效问题并优化资源使用。
  • 提高敏捷性：快速适应市场和监管变化。
  • 改进决策流程：使用 BigQuery 和 Looker 等数据分析产品做出明智的选择。

为确保持续改进和创新，请考虑以下建议。

定期开展回顾会议

回顾对于持续改进突发事件响应程序至关重要，并且有助于根据常规性能和负载测试的结果优化测试策略。为确保回顾会议有效，请执行以下操作：

  • 让团队有机会反思自己的体验，找出哪些方面做得好，并确定需要改进的方面。
  • 在项目里程碑、重大突发事件或重要测试周期结束后，举行回顾会议。团队可以从成功和失败中吸取经验教训，并不断改进流程和实践。
  • 使用结构化方法（例如开始-停止-继续模型）可确保回顾会议富有成效，并促成可行的步骤。
  • 通过回顾性分析，找出可以进一步增强变更管理自动化程度的领域，以提高可靠性并降低风险。

培养学习文化

学习文化有助于在Google Cloud中安全探索新技术，例如利用 AI 和机器学习功能来改进欺诈检测和个性化理财建议等服务。如需营造学习文化，请执行以下操作：

  • 鼓励团队进行实验、分享知识并不断学习。
  • 采用不追究责任的文化，将失败视为成长和改进的机会。
  • 营造心理安全感，让团队敢于冒险并考虑创新解决方案。团队会从成功和失败中学习，从而打造更具韧性和适应性的组织。
  • 培养一种有助于分享从突发事件管理流程和测试练习中获得的知识的文化。

及时了解云技术

持续学习对于了解和实施新的安全措施、利用高级数据分析获得更深入的洞见，以及采用与金融服务相关的创新解决方案至关重要。

  • 及时了解最新进展、功能和最佳实践，充分发挥 Google Cloud 服务的潜力。
  • 当推出新的 Google Cloud 功能和服务时，请确定可进一步实现流程自动化、增强安全性并提高应用性能和可伸缩性的机会。
  • 参加相关会议、网络研讨会和培训课程，以扩展知识并了解新功能。
  • 鼓励团队成员获得Google Cloud 认证，以帮助确保组织具备在云端取得成功所需的技能。

金融服务视角：安全性、隐私权和合规性

Google Cloud Well-Architected Framework：金融服务 (FS) 视角中的本文档概述了相关原则和建议，旨在解决 Google Cloud中金融服务 (FS) 工作负载的安全、隐私权和合规性要求。这些建议可帮助您构建弹性且合规的基础设施、保护敏感数据、维护客户信任、应对复杂的监管要求，并有效管理网络威胁。本文档中的建议与 Well-Architected Framework 的安全核心保持一致。

对于金融服务 (FS) 组织而言，云计算中的安全性是一个至关重要的问题。由于这些组织管理着大量敏感数据（包括客户详细信息和财务记录），因此对网络犯罪分子极具吸引力。安全事故的后果非常严重，包括巨额财务损失、长期声誉损害和巨额监管罚款。因此，FS 工作负载需要严格的安全控制措施。

为帮助确保全面的安全性和合规性，您需要了解您（金融服务组织）与 Google Cloud之间的共同责任。 Google Cloud 负责保护底层基础架构的安全，包括物理安全和网络安全。您负责保护数据和应用、配置访问权限控制，以及配置和管理安全服务。为了支持您的安全工作，Google Cloud 合作伙伴生态系统提供安全集成和托管服务。

本文档中的安全建议与以下核心原则相对应：

践行“设计即安全”理念

支付卡行业数据安全标准 (PCI DSS)、美国《格拉斯-利奇-布莱利法案》(GLBA) 等金融法规以及各种国家级金融数据保护法都要求从一开始就将安全性集成到系统中。“设计即安全”原则强调在整个开发生命周期中融入安全性，以帮助确保从一开始就尽可能减少漏洞。

如需在Google Cloud中为 FS 工作负载应用“安全至上”原则，请考虑以下建议：

  • 通过 Identity and Access Management (IAM) 中的精细基于角色的访问权限控制 (RBAC) 应用最小权限原则，确保仅授予必要的权限。在许多金融法规中，使用 RBAC 是一项关键要求。
  • 使用 VPC Service Controls 在 Google Cloud 内为敏感服务和数据强制执行安全边界。安全边界有助于根据法规要求，对敏感数据和资源进行分段和保护，并有助于防止数据渗漏和未经授权的访问。
  • 使用 Terraform 等基础架构即代码 (IaC) 工具将安全配置定义为代码。 此方法从初始部署阶段就嵌入了安全控制措施，有助于确保一致性和可审核性。
  • 通过将静态应用安全保障测试 (SAST) 与 Cloud Build 集成到 CI/CD 流水线中，扫描应用代码。 建立自动化安全门，以防止部署不合规的代码。
  • 使用 Security Command Center 提供统一的界面来获取安全性数据分析。 使用 Security Command Center 可持续监控并及早检测可能导致违规的配置错误或威胁。为满足 ISO 27001 和 NIST 800-53 等标准的要求，您可以使用姿态管理模板。
  • 跟踪生产部署中发现的漏洞数量的减少情况，以及符合安全最佳实践的 IaC 部署所占的百分比。您可以使用 Security Command Center 检测和查看漏洞以及有关安全标准合规性的信息。如需了解详情，请参阅漏洞发现结果。

落地零信任架构

现代金融法规越来越强调需要实施严格的访问控制和持续验证。这些要求体现了零信任原则，旨在保护工作负载免遭内部和外部威胁以及恶意行为者的侵害。零信任原则主张对每个用户和设备进行持续验证，从而消除隐式信任并缓解横向移动。

如需实施零信任，请考虑以下建议：

  • 将 IAM 控制与 Chrome 企业进阶版相结合，根据用户身份、设备安全状况、位置和其他因素启用情境感知访问权限。此方法可确保在授予对财务数据和系统的访问权限之前进行持续验证。
  • 通过配置 Identity Platform（如果您使用员工身份联合，则为您的外部身份提供方）来提供安全且可伸缩的身份和访问权限管理。设置多重身份验证 (MFA) 和其他对于实现零信任至关重要的控制措施，有助于确保符合监管合规要求。
  • 为所有用户账号（尤其是可访问敏感数据或系统的账号）实现 MFA。
  • 通过建立全面的日志记录和监控用户访问权限和网络活动，支持与监管合规相关的审核和调查。
  • 使用 Private Service Connect，可在Google Cloud 内的服务与本地环境之间实现私密且安全的通信，而无需将流量暴露到公共互联网。
  • 使用 Identity-Aware Proxy (IAP) 而不是依赖 VPN 隧道等基于网络的安全性机制，在应用级实现精细的身份控制和授权访问。此方法有助于减少环境中的横向移动。

实现提前确保安全性

金融监管机构鼓励采取主动安全措施。在开发生命周期中尽早识别并解决漏洞有助于降低安全事件的风险，并减少因违规而受到处罚的可能性。“左移”安全原则提倡尽早进行安全测试和集成，这有助于降低补救成本和复杂性。

如需实施左移安全，请考虑以下建议：

  • 通过将安全扫描工具（例如容器漏洞扫描和静态代码分析）与 Cloud Build 集成到 CI/CD 流水线中，确保在开发流程的早期阶段进行自动化安全检查。

  • 使用 Artifact Registry 为软件包和容器映像提供安全且集中的存储库，并集成漏洞扫描功能，确保仅部署安全的制品。使用虚拟制品库，通过优先考虑您的私有制品而非远程制品库，来缓解依赖项混淆攻击。

  • 通过将 Security Command Center 的一部分 Web Security Scanner 集成到开发流水线中，自动扫描 Web 应用是否存在常见漏洞。

  • 使用软件制品的供应链等级 (SLSA) 框架，针对源代码、构建流程和代码来源实施安全检查。使用 Binary Authorization 等解决方案，强制执行环境中运行的工作负载的来源。 使用 Assured Open Source 确保工作负载仅使用经过验证的开源软件库。

  • 跟踪开发生命周期中发现和修复的漏洞数量、通过安全扫描的代码部署百分比，以及因软件漏洞而导致的安全事件减少情况。 Google Cloud 提供了相关工具，可帮助您跟踪不同类型的工作负载。例如，对于容器化工作负载，请使用 Artifact Registry 的容器扫描功能。

构建预防性网络防御体系

金融机构是复杂网络攻击的主要目标。 法规通常要求采用强大的威胁情报和主动防御机制。预防性网络防御侧重于通过高级分析和自动化技术主动检测和应对威胁。

请考虑以下建议：

以安全、负责任的方式使用 AI，并利用 AI 强化安全防护

AI 和机器学习技术正日益广泛地应用于金融服务用例，例如欺诈检测和算法交易。法规要求以合乎道德、透明且安全的方式使用这些技术。AI 还可以帮助您增强安全功能。不妨考虑以下有关使用 AI 的建议：

  • 使用 Vertex AI 在安全且受监管的环境中开发和部署机器学习模型。 模型可解释性和公平性指标等功能有助于解决负责任的 AI 问题。
  • 利用 Google Security Operations 的安全分析与运营功能，该产品使用 AI 和机器学习技术来分析大量安全数据、检测异常情况并自动响应威胁。这些功能有助于提升您的整体安全状况，并帮助您监控合规情况。
  • 为 AI 和 ML 开发及部署制定明确的治理政策，包括安全和伦理方面的考虑因素。
  • 与安全 AI 框架 (SAIF) 的要素保持一致，该框架提供了一种切实可行的方法来解决 AI 系统的安全和风险问题。
  • 跟踪 AI 赋能的欺诈检测系统的准确性和有效性、安全提醒中误报的减少情况，以及 AI 驱动的安全自动化带来的效率提升。

满足监管、合规性和隐私权需求

金融服务受各种法规的约束，包括数据驻留要求、特定审核轨迹和数据保护标准。为确保敏感数据得到妥善识别、保护和管理，金融服务组织需要制定完善的数据治理政策和数据分类方案。请考虑以下建议，以帮助您满足监管要求：

  • 使用 Assured Workloads 在 Google Cloud 中为敏感工作负载和受监管的工作负载设置数据边界。这样做有助于您满足政府和行业特定的合规要求，例如 FedRAMP 和 CJIS。
  • 通过实施 Cloud Data Loss Prevention (Cloud DLP) 来识别、分类和保护敏感数据，包括财务信息。这样做有助于您遵守 GDPR 和 CCPA 等数据隐私权法规。
  • 使用 Cloud Audit Logs 跟踪管理活动和资源访问的详细信息。这些日志对于满足许多金融法规规定的审核要求至关重要。
  • 为工作负载和数据选择Google Cloud 区域时，请考虑与数据驻留相关的当地法规。 Google Cloud 全球基础设施可让您选择有助于满足数据驻留要求的区域。
  • 使用 Cloud Key Management Service 管理用于加密静态和传输中的敏感财务数据的密钥。 这种加密是许多安全和隐私权法规的基本要求。
  • 实施必要的控制措施，以满足监管要求。验证控件是否按预期运行。让外部审核人员再次验证这些控制措施，以向监管机构证明您的工作负载符合相关法规。

确定安全计划的优先级

鉴于安全要求的广泛性，金融机构必须优先考虑基于风险评估和监管要求的计划。我们建议采用以下分阶段方法：

  1. 奠定坚实的安全基础：重点关注安全的核心领域，包括身份和访问权限管理、网络安全和数据保护。这种侧重有助于打造强大的安全态势，并有助于确保全面防御不断演变的威胁。
  2. 遵守关键法规：优先遵守 PCI DSS、GDPR 和相关国家/地区法律等关键法规。这样做有助于确保数据保护、降低法律风险，并与客户建立信任。
  3. 实施高级安全措施：逐步采用高级安全实践，例如零信任、AI 驱动的安全解决方案和主动威胁搜寻。

金融服务视角：可靠性

Google Cloud Well-Architected Framework：金融服务 (FS) 视角中的本文档概述了在 Google Cloud中设计、部署和运营可靠的 FS 工作负载的原则和建议。本文档探讨了如何将高级可靠性实践和可观测性集成到架构蓝图中。本文档中的建议与 Well-Architected Framework 的可靠性核心保持一致。

对于金融机构而言，可靠且富有弹性的基础设施既是业务需求，也是监管要求。为确保Google Cloud 中的 FS 工作负载可靠，您必须了解并缓解潜在的故障点、以冗余方式部署资源，并规划恢复方案。运营弹性是可靠性的结果。是指吸收、适应和从中断中恢复的能力。运营韧性有助于金融服务组织满足严格的监管要求。还有助于避免对客户造成无法容忍的伤害。

Google Cloud 中的关键可靠性构建块是区域、可用区以及云资源的各种位置范围：可用区级、区域级、多区域级、全球级。您可以通过使用托管服务、分配资源、实现高可用性模式和自动执行流程来提高可用性。

法规要求

金融服务机构在监管机构（例如美国的联邦储备系统、欧盟的欧洲银行管理局和英国的审慎监管局）的严格可靠性要求下运营。在全球范围内，监管机构都非常重视运营韧性，这对于金融稳定和消费者保护至关重要。运营韧性是指能够承受中断、有效恢复并维持关键服务的能力。这就需要采取协调一致的方法来管理技术风险和对第三方的依赖。

大多数司法管辖区的监管要求都具有以下共同主题：

  • 网络安全和技术弹性：加强针对网络威胁的防御，确保 IT 系统的弹性。
  • 第三方风险管理：管理与将服务外包给信息和通信技术 (ICT) 提供商相关的风险。
  • 业务连续性和突发事件响应：制定周密的计划，以便在中断期间维持关键运营并有效恢复。
  • 维护金融稳定：确保整个金融体系的稳健性和稳定性。

本文档中的可靠性建议与以下核心原则相对应：

优先考虑多可用区和多区域部署

对于关键金融服务应用，我们建议您使用多区域拓扑，该拓扑分布在至少两个区域以及每个区域内的三个可用区中。此方法对于提高可用区和区域服务中断的应对能力至关重要。法规通常会规定这种方法，因为如果一个可用区或区域发生故障，大多数司法管辖区都会认为第二个可用区严重中断是可能的结果。原因是，当一个位置发生故障时，另一个位置可能会收到异常高的额外流量。

请考虑以下建议，以增强针对可用区和区域中断的恢复能力：

  • 优先选择位置范围更广的资源。尽可能使用区域级资源（而不是可用区级资源），并使用多区域或全球性资源（而不是区域级资源）。这种方法有助于避免使用备份来恢复操作。
  • 在每个区域中，利用三个可用区而不是两个。为了处理故障转移，请将容量预配量增加到估计值的 1.33 倍。
  • 通过实施主动-主动部署（如以下示例所示）来最大限度地减少手动恢复步骤：
    • Spanner 等分布式数据库可提供跨区域的内置冗余和同步功能。
    • Cloud SQL 的高可用性功能提供了一种近乎主动-主动的拓扑，其中包含跨可用区的只读副本。它可实现接近于 0 的区域间恢复点目标 (RPO)。
  • 使用 Cloud DNS 在各个区域之间分配用户流量，并在每个区域中部署区域级负载均衡器。根据您的需求和关键程度，您还可以考虑使用全球负载均衡器。如需了解详情，请参阅多区域部署的全球负载均衡的优势和风险。
  • 如需存储数据，请使用 Spanner 和 Cloud Storage 等多区域服务。

消除单点故障

跨不同位置分配资源并使用冗余资源，以防止任何单点故障 (SPOF) 影响整个应用堆栈。

请考虑以下建议，以避免出现 SPOF：

如需了解详情，请参阅在 Google Cloud中为工作负载设计可靠的基础设施。

了解和管理汇总的空房情况

请注意，系统的总体或汇总可用性会受到系统每个层级或组件的可用性的影响。应用堆栈中的层级数与堆栈的总体可用性具有反向关系。请考虑以下有关管理汇总可用性的建议：

  • 使用公式层级 1 的可用性 × 层级 2 的可用性 × 层级 N 的可用性计算多层式堆栈的总体可用性。

    下图展示了由四项服务组成的多层级系统的汇总可用性计算：

    具有四项服务的多层服务的总体可用性公式。

    在上图中，每个层级的服务都提供 99.9% 的可用性，但系统的总体可用性较低，为 99.6% (0.999 × 0.999 × 0.999 × 0.999)。一般来说，多层式堆栈的总体可用性低于提供最低可用性的层级的可用性。

  • 在可行的情况下，选择并行化而非链式调用。借助并行化服务，端到端可用性高于每个单独服务的可用性。

    下图展示了通过链接和并行化方法部署的两个服务 A 和 B：

    链式服务与并行化服务的汇总可用性公式。

    在上述示例中，两项服务的 SLA 均为 99%，因此根据实现方法的不同，总可用性如下：

    • 链式服务的总体可用性仅为 98%（0.99 × 0.99）。
    • 并行化服务可实现 99.99% 的更高总体可用性，因为每个服务都是独立运行的，单个服务不会受到其他服务的可用性影响。并行化服务的汇总公式为 1 − (1 − A) × (1 − B)。

  • 选择 Google Cloud 具有正常运行时间 SLA 的服务，以帮助满足应用堆栈所需的总体正常运行时间水平。

  • 在设计架构时，请考虑可用性、运营复杂性、延迟时间和费用之间的权衡取舍。提高可用性（以“9”的数量表示）通常会增加费用，但有助于您满足监管要求。

    例如，99.9% 的可用性（三个 9）意味着 24 小时内可能会有 86 秒的停机时间。相比之下，99%（两个 9）意味着在同一时间段内停机 864 秒，这比可用性为三个 9 的停机时间多 10 倍。

    对于关键金融服务，架构选项可能有限。不过，确定可用性要求并准确计算可用性至关重要。进行此类评估有助于您评估设计决策对架构和预算的影响。

实施稳健的灾难恢复策略

针对不同的灾难场景（包括地区级和区域级服务中断）制定明确的计划。借助明确的灾难恢复 (DR) 策略，您可以从中断中恢复，并以最小的影响恢复正常运营。

灾难恢复 (DR) 和高可用性 (HA) 是不同的概念。对于云部署，一般来说，DR 适用于多区域部署，而 HA 适用于区域部署。这些部署原型支持不同的复制机制。

  • HA：许多受管服务默认在单个区域内的可用区之间提供同步复制。此类服务支持零或接近零的恢复时间目标 (RTO) 和恢复点目标 (RPO)。借助此支持，您可以创建没有任何 SPOF 的主动-主动部署拓扑。
  • 灾难恢复：对于部署在两个或更多区域中的工作负载，如果您不使用多区域或全球服务，则必须定义复制策略。复制策略通常是异步的。请仔细评估此类复制对关键应用的 RTO 和 RPO 有何影响。确定故障切换所需的手动或半自动化操作。

对于金融机构，您选择的故障切换区域可能会受到有关数据主权和数据驻留的法规限制。如果您需要在两个区域中实现主动-主动拓扑，我们建议您选择托管式多区域服务，例如 Spanner 和 Cloud Storage，尤其是在数据复制至关重要的情况下。

请考虑以下建议：

  • 使用托管式多区域存储服务来存储数据。
  • 为永久性磁盘中的数据拍摄快照，并将快照存储在多区域位置。
  • 使用区域级或可用区级资源时，请设置数据复制到其他区域。
  • 通过定期测试灾难恢复计划，验证其有效性。
  • 请注意 RTO 和 RPO，以及它们与您所在管辖区金融法规规定的影响容忍度的相关性。

如需了解详情，请参阅针对云基础设施服务中断设计灾难恢复架构。

利用代管式服务

尽可能使用托管式服务，以利用内置的备份、高可用性和可伸缩性功能。请考虑以下有关使用托管式服务的建议：

  • 在 Google Cloud中使用托管式服务。它们提供由 SLA 支持的 HA。它们还提供内置备份机制和恢复功能。
  • 对于数据管理，请考虑使用 Cloud SQL、Cloud Storage 和 Spanner 等服务。
  • 对于计算和应用托管，请考虑 Compute Engine 托管实例组 (MIG) 和 Google Kubernetes Engine (GKE) 集群。区域 MIG 和 GKE 区域级集群能够灵活应对可用区服务中断。
  • 如需提高应对区域级服务中断的弹性，请使用托管式多区域服务。
  • 确定具有独特特征的服务是否需要退出计划，并定义所需的计划。FCA、PRA 和 EBA 等金融监管机构要求公司制定数据检索和运营连续性策略及应急计划，以应对与云提供商的关系终止的情况。公司必须在签订云合同之前评估退出可行性，并且必须保持在不中断运营的情况下更换提供商的能力。
  • 验证您选择的服务是否支持将数据导出为 CSV、Parquet 和 Avro 等开放格式。验证服务是否基于开放技术，例如 GKE 支持 Open Container Initiative (OCI) 格式，或者 Managed Service for Apache Airflow 基于 Apache Airflow 构建。

自动执行基础架构预配和恢复流程

Automation 有助于最大限度地减少人为错误，并有助于减少响应突发事件所需的时间和资源。使用自动化功能有助于确保更快地从故障中恢复，并获得更一致的结果。请考虑以下建议，以自动执行资源预配和恢复操作：

  • 使用 Terraform 等基础设施即代码 (IaC) 工具，最大限度地减少人为错误。
  • 通过自动化故障切换流程来减少人工干预。自动回复还有助于减少故障的影响。例如，您可以使用 Eventarc 或 Workflows 自动触发补救措施，以响应通过审核日志发现的问题。
  • 在故障切换期间，使用自动扩缩功能来增加云资源的容量。
  • 通过采用平台工程，在服务部署期间自动应用政策和安全措施，以满足云拓扑中的监管要求。

金融服务视角：费用优化

Google Cloud Well-Architected Framework：金融服务 (FS) 视角中的本文档简要介绍了优化 Google Cloud中金融服务工作负载费用的原则和建议。本文档中的建议与 Well-Architected Framework 的费用优化支柱保持一致。

如需针对金融服务工作负载实现强大的费用优化，需要具备以下基本要素：

  • 能够识别浪费性资源利用与价值驱动型资源利用。
  • 嵌入式财务责任文化。

如需优化费用，您需要全面了解整个组织的费用驱动因素和资源需求。在一些大型组织中，尤其是在云历程的早期阶段，通常由一个团队负责优化众多网域的支出。此方法假设中心团队最适合发现提高效率的高价值机会。

在云采用的初始阶段或对于非关键工作负载，集中式方法可能会取得一些成功。不过，单个团队无法在整个组织内实现费用优化。当资源使用量或监管审查级别提高时，集中式方法就不可持续了。集中式团队在处理大量金融产品和服务时，尤其会面临可伸缩性方面的挑战。负责产品和服务的项目团队可能会抵制外部团队所做的更改。

为了有效优化费用，与支出相关的数据必须高度可见，并且接近工作负载的工程师和其他云用户必须有动力采取行动来优化费用。从组织的角度来看，成本优化的挑战在于确定应优化的领域、负责这些领域的工程师，然后说服他们采取所需的优化措施。本文档提供了一些建议来应对这一挑战。

本文档中的费用优化建议与以下核心原则相对应：

使用 Google Cloud 工具识别浪费

Google Cloud 提供了多种产品、工具和功能，可帮助您找出浪费之处。请考虑以下建议。

使用自动化和 AI 系统地确定要优化的内容

Active Assist 可针对各种服务提供智能建议，例如针对微服务的 Cloud Run、针对数据分析的 BigQuery、针对核心应用的 Compute Engine 以及针对关系型数据库的 Cloud SQL。Active Assist 建议免费提供，无需您进行任何配置。这些建议有助于您识别空闲资源和未充分利用的承诺。

通过统一的界面集中进行 FinOps 监控和控制

借助 Cloud Billing 报告和 FinOps 中心，您可以实现全面的费用监控。这种全面的视图对于财务审核员和内部财务团队至关重要，有助于他们跟踪云支出、评估财务状况、评估各个业务部门或成本中心的 FinOps 成熟度，并提供一致的财务叙述。

通过分析和丰富支出数据来发掘价值

Active Assist 可有效识别明显的浪费。不过，确定价值可能更具挑战性，尤其是在工作负载位于不合适的产品上或工作负载与业务价值缺乏明确的关联时。对于 FS 工作负载，业务价值不仅限于降低成本。这些价值包括降低风险、遵守法规和获得竞争优势。

若要全面了解云支出和价值，您需要从多个层面进行全面了解：支出来自何处、支出推动了哪些业务职能，以及重构或优化相关工作负载的技术可行性。

下图展示了如何应用数据-信息-知识-智慧 (DIKW) 金字塔和 Google Cloud 工具来全面了解云费用和价值。

数据-信息-知识-智慧 (DIKW) 金字塔展示了如何使用云支出数据来制定明智的决策。

上图展示了如何使用 DIKW 方法将原始云支出数据提炼为可据以采取行动的数据洞见和决策，从而提升业务价值。

  • 数据：在此层中，您可以收集云资源的原始、未经处理的用量和费用数据流。您的中央 FinOps 团队使用 Cloud Billing 账单、结算导出和 Cloud Monitoring 等工具来获取精细的详细数据。例如，一个数据点可能是指名为 app1-test-vmA 的虚拟机在 us-central1 区域运行了 730 小时，费用为 70 美元。
  • 信息：在此层级，您的中央 FinOps 团队会使用 Cloud Billing 报告和 FinOps 中心等工具来整理原始数据，以帮助回答“人们在哪些类别的资源上花费了资金？”之类的问题。例如，您可能会发现，在美国的两个区域中，机器类型为 n4-standard-2 的虚拟机的总支出为 1,050 美元。
  • 知识：在此层级，中央 FinOps 团队会为信息添加适当的业务背景信息，以说明谁花了钱以及出于什么目的。您可以使用标记、标签、资源层次结构、结算账号和自定义 Looker 信息中心等机制。例如，您可能会确定美国 app1 测试团队在 7 月第二周花费了 650 美元，用于进行压力测试。
  • 智慧：在此层级，产品和应用团队会使用情境化知识来评估云支出的业务价值，并做出明智的战略决策。您的团队可能会回答以下问题：
    • 花费在数据分析流水线上的 5,000 美元是否产生了业务价值？
    • 我们能否重新设计流水线，在不降低性能的情况下提高效率？

在分析云支出数据时，请考虑以下建议。

分析由 Google Cloud提供的支出数据

首先，使用导出到 BigQuery 的详细 Cloud Billing 数据以及监控日志中提供的数据。为了获得富有实用价值的分析洞见并做出决策，您需要整理这些数据，并添加业务背景信息来丰富数据。

通过可用工具直观呈现数据

通过在 BigQuery 导出数据的基础上使用 数据洞察 等工具，利用自定义报告来增强内置 Google Cloud 信息中心的功能。财务团队可以构建自定义信息中心，将云支出与财务指标、监管报告要求和业务单位盈利能力相关联。然后，它们可以为高管利益相关者提供清晰的财务叙事，以供分析和决策。

分配支出以明确责任

在了解云支出的驱动因素后，您需要确定是谁在花钱以及原因。这种程度的了解需要完善的费用分配实践，即为云资源附加与业务相关的元数据。例如，如果某个特定资源由 Banking-AppDev 团队使用，您可以将 team=banking_appdev 等标记附加到该资源，以跟踪该团队在该资源上产生的费用。理想情况下，您应将 100% 的云费用分配给支出来源。在实践中，您可能会从较低的目标开始，因为构建支持 100% 费用分摊的元数据结构是一项复杂的工作。

如需制定支持费用分摊的元数据策略，请考虑以下建议：

  • 有效性：确保跟踪代码有助于确定与业务相关的关键绩效指标 (KPI) 和监管要求。这种关联对于内部费用返还、监管报告以及使云支出与业务部门目标保持一致至关重要。例如，以下标记清楚地标识了支出团队、其所在区域以及他们负责的产品：team=banking_appdev、region=emea、product=frontend。
  • 自动化：为了实现高水平的标记合规性，请通过自动化强制执行标记。手动标记容易出错且不一致，这在金融服务 (FS) 环境中是不可接受的，因为在这些环境中，可审核性和财务准确性至关重要。自动添加标记功能可确保资源在创建时得到正确分类。
  • 简单性：衡量简单且不相关的因素。FS 环境非常复杂。为确保此类环境中的费用分摊规则易于理解和执行，规则必须尽可能简单。避免针对高度特定的（边缘）情况过度设计规则。复杂的规则可能会导致运营团队感到困惑和抵触。

使用标记定义分配策略后，您需要确定实施该策略的粒度级别。所需的精细程度取决于您的业务需求。例如，有些组织可能需要跟踪产品级费用，有些组织可能需要每个成本中心的数据，还有些组织可能需要每个环境（开发、预发布和生产）的费用数据。

您可以考虑采用以下方法，为组织实现适当的费用分摊细化程度：

  • 使用 Google Cloud 中的项目层次结构作为费用分摊的自然起点。项目代表 Google Cloud中的政策执行点。默认情况下，IAM 权限、安全政策和费用归因于项目和文件夹。查看从 Cloud Billing 导出的费用数据时，您可以查看文件夹层次结构以及与费用数据关联的项目。如果您的Google Cloud 资源层次结构反映了组织在支出方面的责任结构，那么这是实现费用分配的最简单方法。
  • 使用标记和标签可实现更精细的控制。它们提供了灵活的方式来对结算导出中的资源进行分类。标记和标签有助于按应用和环境细分费用。

通常，您可能需要将项目层次结构与标记和标签结合使用，才能有效分配费用。无论您选择哪种费用分摊方法，都应遵循前面介绍的建议，制定稳健的元数据策略：验证、自动化和简洁性。

明确责任并激励工程师采取行动

云 FinOps 团队负责推动组织重视成本和价值。各个产品团队和工程团队必须采取必要的费用优化措施。这些团队还负责金融服务工作负载的费用行为，并确保其工作负载提供所需的业务价值。

请考虑以下建议，以提高责任感并激励团队优化费用。

建立集中式 FinOps 团队以进行治理

Cloud FinOps 实践不会自然而然地发展。专门的 FinOps 团队必须通过以下方式来定义和确立 FinOps 实践：

  • 构建所需的流程、工具和指南。
  • 制定、传达和执行必要的政策，例如强制性标记、预算审核和优化流程。
  • 鼓励工程团队对费用负责。
  • 如果工程团队不承担费用责任，请进行干预。

获得高管支持和授权

包括 CTO、CFO 和 CIO 在内的高级领导者必须积极倡导在整个组织内向 FinOps 文化转型。他们的支持对于优先考虑成本责任、为 FinOps 计划分配资源、确保跨职能参与以及推动遵守 FinOps 要求至关重要。

激励团队优化费用

工程师和工程团队可能没有足够的自我激励来专注于费用优化。请务必通过实施以下激励措施，使团队和个人目标与成本效益保持一致：

  • 将成本优化节省的部分资金重新投资于实现优化的团队。
  • 公开认可并庆祝费用优化工作和取得的成功。
  • 使用游戏化技巧奖励有效优化费用的团队。
  • 将效率指标纳入效果目标。

实施反馈和退款技术

确保团队能够清楚地了解其拥有的云资源和费用。将财务责任分配给团队内的相应人员。使用正式机制来强制执行严格的标记，并实施透明的规则来分配共同费用。

着重说明价值和总拥有成本，而不是成本

在评估云解决方案时，请考虑长期总拥有成本 (TCO)。例如，自行托管应用的数据库可能看起来比使用 Cloud SQL 等托管式数据库服务更便宜。不过，若要评估长期价值和总拥有成本，您必须考虑与自托管数据库相关的隐性成本。此类成本包括用于修补、伸缩、安全强化和灾难恢复的专用工程资源，这些都是 FS 工作负载的关键要求。托管服务可提供显著更高的长期价值，从而抵消基础架构成本。托管式服务提供强大的合规性功能、内置的可靠性功能，并有助于减少运营开销。

请考虑以下建议，以便专注于价值和总拥有成本。

使用特定于产品的资源优化技术和工具

利用 Google Cloud产品提供的费用优化工具和功能，例如：

享受超值折扣优惠

利用 Google 提供的折扣，确保云资源的结算费率尽可能低。各个产品和工程团队通常负责管理资源优化。中心 FinOps 团队负责优化结算费率，因为他们可以了解整个组织的资源需求。因此，他们可以汇总需求，最大限度地享受基于承诺的折扣。

您可以为Google Cloud 资源享受以下类型的折扣：

  • 企业折扣是根据组织承诺以较低的结算费率支付 Google Cloud 最低总支出来协商的折扣。
  • 基于资源的 CUD 是以承诺在一年期或三年期内使用最少数量的 Compute Engine 资源为前提的。基于资源的 CUD 适用于特定项目和区域中的资源。如需在多个项目之间共享 CUD，您可以启用 CUD 共享。
  • 基于支出的 CUD 换取的是在一年期或三年期内，在特定产品上支出最低金额的承诺。基于支出的折扣适用于结算账号级别。折扣是区域性还是全球性，取决于具体产品。

在企业折扣的基础上使用 CUD，可大幅节省费用。

除了 CUD 之外，您还可以使用以下方法来降低结算费率：

  • 对于容错型和灵活型工作负载，请使用 Spot 虚拟机。Spot 虚拟机比常规虚拟机的费用便宜 80% 以上。
  • BigQuery 提供多种价格模式，包括按需价格和基于版本的价格（具体取决于承诺和自动扩缩要求）。如果您使用的 BigQuery 资源量很大，请选择合适的版本，以降低分析工作负载的每槽费用。
  • 请仔细评估您需要使用的服务的可用 Google Cloud 区域。选择符合您的费用目标以及延迟时间和合规性要求等因素的区域。如需了解费用、可持续性和延迟时间之间的权衡取舍，请使用Google Cloud 区域选择器。

金融服务视角：性能优化

Google Cloud Well-Architected Framework：金融服务 (FS) 视角中的本文档简要介绍了优化 Google Cloud中 FS 工作负载性能的原则和建议。本文档中的建议与 Well-Architected Framework 的性能优化核心保持一致。

在金融服务领域，性能优化由来已久。它帮助金融服务组织克服了技术挑战，并且几乎总是能够促成或加速新业务模式的创建。例如，自动取款机（1967 年推出）可自动执行现金发放流程，并帮助银行降低核心业务的成本。绕过操作系统内核并将应用线程固定到计算核心等技术有助于实现交易应用的确定性和低延迟。延迟的缩短有助于提高金融市场的流动性，并使流动性更加稳定，点差更小。

云计算为优化性能创造了新的机会。它还对一些历史上被接受的优化模式提出了挑战。具体而言，在云端，以下权衡取舍更加透明且可控：

  • 上市期与成本。
  • 系统级端到端性能与节点级性能。
  • 人才可用性与技术相关决策的敏捷性。

例如，在云中，根据特定技能要求调整硬件和 IT 资源是一项微不足道的任务。为了支持 GPU 编程，您可以创建基于 GPU 的虚拟机。您可以扩缩云中的容量，以应对需求高峰，而无需过度预配资源。此功能有助于确保您的工作负载能够处理高峰负载，例如在非农就业数据发布日以及交易量远高于历史水平时。您无需花费大量精力来编写单个服务器级别的高度优化代码（例如 C 语言中的高度精细调整的代码），也无需为传统的高性能计算 (HPC) 环境编写代码，只需使用精心设计的基于 Kubernetes 的分布式系统，即可实现最佳的横向扩容。

本文档中的性能优化建议与以下核心原则相对应：

将技术性能指标与关键业务指标保持一致

您可以通过多种方式将性能优化与业务价值成果相关联。例如，在买方研究部门，业务目标可能是优化每研究小时的产出，或优先考虑具有良好过往记录的团队的实验，例如具有较高 Sharpe 比率的团队。在销售方面，您可以使用分析来跟踪客户兴趣，并相应地优先考虑对支持最有趣研究的 AI 模型的吞吐量。

将性能目标与业务关键绩效指标 (KPI) 相关联，对于为提升效果提供资金支持也至关重要。业务创新和转型计划（有时称为“改变银行”计划）的预算各不相同，与日常业务 (BAU) 或“运营银行”运营相比，它们对资源的访问权限可能有所不同。例如， Google Cloud 帮助全球系统重要性金融机构 (G-SIFI) 的风险管理和技术团队与前台量化分析师协作，共同开发出一种解决方案，可在几分钟内（而不是几小时或几天内）执行风险分析计算（例如 XVA）。此解决方案帮助该组织满足了相关的合规性要求。此外，它还使交易员能够与客户进行更高质量的对话，从而有可能提供更小的点差、更稳定的流动性和更具成本效益的对冲。

将性能指标与业务指标保持一致时，请考虑以下建议：

  • 将每项技术计划与相关的业务目标和主要成果 (OKR) 联系起来，例如更高效或更全面地提高收入或利润、降低成本和降低风险。
  • 专注于在系统级优化性能。不要只关注传统的“变革银行”与“运营银行”分离以及前台与后台孤岛。

在不牺牲性能的前提下优先处理安全性问题，避免因未经证实的风险而牺牲性能

金融服务组织的安全性和监管合规性必须达到毫无疑问的高标准。保持高标准对于避免失去客户以及防止组织品牌遭受无法弥补的损害至关重要。通常，最高价值是通过生成式 AI 等技术创新和 Spanner 等独特的托管式服务实现的。 不要因为对操作风险过高或监管合规状况不足存在笼统的误解，而自动舍弃此类技术选项。

Google Cloud 与 G-SIFI 密切合作，确保反洗钱 (AML) 的 AI 解决方案可用于金融机构服务客户的所有司法管辖区。例如，HSBC显著提升了其金融犯罪 (Fincrime) 部门的绩效，取得了以下成果：

  • 确认可疑活动的数量比原来增加了近 2-4 倍。
  • 由于消除了超过 60% 的假正例，并将调查时间集中在高风险、可采取行动的提醒上，因此降低了运营成本。
  • 可审核且可解释的输出，为支持监管合规提供支持。

请考虑以下建议：

  • 确认您打算使用的产品有助于满足您运营所在司法管辖区的安全性、恢复能力和合规性要求。为实现此目标，请与 Google Cloud客户支持团队、风险团队和产品团队合作。
  • 利用 AI 可解释性（例如 Shapley 值归因）创建更强大的模型并提高客户透明度。 Shapley 值归因等技术可以将模型决策归因于输入级别的特定特征。

  • 通过使用来源引用、接地和RAG 等技术，实现生成式 AI 工作负载的透明度。

  • 如果可解释性不够，请在价值流中分离出决策步骤，并仅使用 AI 自动执行非决策步骤。在某些情况下，可解释 AI 可能不够充分，或者由于监管方面的顾虑（例如，GDPR 第 22 条），某个流程可能需要人工干预。在这种情况下，请在单个控制窗格中显示人工客服人员做出决策所需的所有信息，但要自动执行数据收集、注入、处理和总结任务。

重新思考您的架构，以适应新的机遇和要求

利用基于云的功能增强当前架构可以带来显著价值。如需取得更具变革性的成果，您需要采用云优先方法，定期重新思考您的架构。

请考虑以下建议，定期重新思考工作负载的架构，以进一步优化性能。

使用基于云的替代方案来取代本地 HPC 系统和调度器

为了充分利用更高的弹性、更稳定的安全状况以及广泛的监控和治理功能，您可以在云端运行 HPC 工作负载，也可以将本地工作负载突发到云端。不过，对于某些数值建模使用情形（例如投资策略模拟或 XVA 建模），将 Kubernetes 与 Kueue 结合使用可能会提供更强大的解决方案。

切换到基于图表的模拟编程

在 Dataflow 等基于图的执行系统中，蒙特卡罗模拟的性能可能会好得多。例如，HSBC 使用 Dataflow 运行风险计算的速度比之前的方法快 16 倍。

运营基于云的交易所和交易平台

与 Google Cloud 客户的对话表明，80/20 帕累托原则适用于市场和交易应用的性能要求。

  • 超过 80% 的交易应用不需要极低的延迟时间。不过，他们可以从云的弹性、安全性和灵活性功能中获益匪浅。例如，外汇多交易商平台 BidFX 使用云服务快速发布新产品，并显著提高其可用性和覆盖面，而无需增加资源。
  • 其余应用（不到 20%）需要低延迟（不到 1 毫秒）、确定性和消息传递公平性。传统上，这些系统在严格且昂贵的同地托管设施中运行。越来越多的此类应用正在云端进行平台重构，无论是作为边缘应用还是云优先应用。

打造面向未来的技术，满足当前和未来的业务需求

从历史上看，许多金融服务组织都曾构建专有技术来获得竞争优势。例如，在 21 世纪初，成功的投资银行和交易公司都有自己的基础技术实现，例如发布-订阅系统和消息代理。随着开源技术和云的不断发展，此类技术已成为商品，无法提供增量业务价值。

不妨考虑以下建议，让您的技术能够应对未来的变化。

采用数据即服务 (DaaS) 方法，缩短产品上市期并提高成本透明度

金融服务组织通常通过有机增长与并购 (M&A) 相结合的方式发展壮大。因此，组织需要集成各种不同的技术。他们还需要管理重复的资源，例如数据供应商、数据许可和集成点。 Google Cloud 为合并后的集成创造了机会，以打造差异化的价值。

例如，您可以使用 BigQuery Sharing 等服务来构建可用于分析的数据即服务 (DaaS) 平台。该平台可以提供市场数据和来自替代来源的输入。这种方法无需构建冗余的数据流水线，让您可以专注于更具价值的计划。此外，合并或收购后的公司可以快速高效地合理化其合并后的数据许可和基础设施需求。合并后的企业无需费力调整和合并旧版数据资产和运营，而是可以专注于新的业务机会。

构建抽象层以隔离现有系统并适应新兴业务模式

银行的竞争优势越来越不在于核心银行系统，而在于客户体验层。不过，旧版银行系统通常使用以 Cobol 等语言开发的单体式应用，这些应用集成在整个银行价值链中。这种集成使得很难分离价值链的各个层，因此几乎不可能升级和现代化此类系统。

解决此问题的一种方法是使用隔离层，例如 API 管理系统或像 Spanner 这样的过渡层，该层可复制记录簿，并有助于通过高级分析和 AI 实现服务现代化。例如，Deutsche Bank 使用 Spanner 来隔离其旧版核心银行系统，并开始其创新历程。