FSI Meetup 2025 Q4 - 规模化提升韧性

场次笔记

USAA 是什么？

USAA 是一家金融服务公司。
提供涵盖银行、保险和财富管理的各类产品。
将客户服务视为一项核心产品。
服务 1,400 万名会员，主要是军人及其家属。
针对会员的独特需求，重点关注可用性和韧性。

USAA 的云上之旅

2019 年开始进行云部署，最初部署在 US East 1。
此后几年，云端流量和发展势头逐步提升。
到 2023 年 6 月，已完成数十项部署。
秉持“绝不浪费任何一次故障”的理念。
没有将工作负载迁回本地，而是把故障视为提升平台成熟度的机会。
通过将应用程序部署到 US West 2，启用了辅助区域。
到 2024 年，已有数百个应用程序部署至 AWS，其中数十个部署至 US West 2。
将 10 月的故障视为又一次学习和成长的机会。

多区域部署策略

决定采用多区域部署策略。
重点关注三种故障切换模式：备份与恢复、预置最小规模和热备用。
备份与恢复至关重要，尤其关系到数据可用性。
如果数据不可用，就无法故障切换到辅助区域。
必须建立将数据传送到辅助区域的流程，即使需要从快照恢复。
预置最小规模和热备用用于高重要性和关键应用程序。
目标是改善恢复时间目标（RTO）和恢复点目标（RPO）。
旨在增强韧性，并改善军人会员的客户体验。

应用程序韧性的三个阶段：架构设计：

评估每个应用程序并识别其依赖项。
了解要使应用程序具备韧性所需采取的措施。
考虑关键路径上的下游依赖项。
重点关注即时响应和恢复要求。
定义所需的恢复时间目标（RTO）。
在架构设计中将 RTO 纳入要求。
为具体使用场景选择合适的故障切换模式（备份与恢复、预置最小规模、热备用）。

运营就绪：

配置部署所需的设置。
编制操作手册并开发监控工具。
确保资源可用，以满足 RTO、恢复点目标（RPO）指标以及服务等级目标（SLO）。

测试与反馈：

开展韧性测试并制定故障应对计划。
从故障中学习并持续收集反馈。
执行回顾分析，确保达到 RTO 和 RPO 的 SLO 目标。
通过持续学习和调整提高平台成熟度。

流程和工具：集中管理韧性：

组织并集中管理韧性标准和框架。
确保整个组织采用一套统一标准。

分布式 DevOps 平台：

构建贴合应用程序工程师实际工作方式的 DevOps 平台。
确保所有开发团队保持一致。
为提升 DevOps 成熟度提供必要的工具和支持。

自动化：

寻找韧性流程的自动化机会。
实施集成到 SDLC 流程中的自助式蓝图。
提供基础设施即代码模板和快速入门指南。
确保应用程序团队能够快速开始开发，并内置韧性要求。

USAA 韧性流程的具体示例定制的 Well-Architected 评审：

从 Well-Architected Framework 入手，并将其应用于 USAA 的所有应用程序。
由于公司采用集中管理和 DevOps 平台等组织结构，识别出了各应用程序之间的一致要素。
在 Well-Architected Review 之上构建定制视角，实现更有意义的自动评分。
识别并突出显示每个应用程序可自主控制、用于提升韧性的组件。

左移：

“左移”是软件开发和 IT 服务管理中的一种策略，指将测试、安全和质量保证等关键活动移至开发或支持生命周期的更早阶段。这种方法旨在更早发现并修复问题，从而降低成本、提高质量并加快交付。
提前验证 RTO，减少应用程序构建过程中的返工并提高韧性。
确保在制定业务使用场景解决方案时，充分理解韧性至关重要。

CI/CD 流水线中的工具集成：

在 CI/CD 流水线中使用 GitLab。
集成 AWS Resilience Hub 和 Resource Groups 以获取洞察。
应用程序团队可在流水线运行期间立即收到评估反馈。
在投入生产之前提供基于证据的实时韧性报告。
较低环境阶段也会提供反馈。

金丝雀部署策略：

通过逐步将一小部分用户流量切换到新版本来发布软件新版本。
通过流水线实现自动化金丝雀部署。
对无服务器应用程序和基于容器的应用程序尤其有用。
使用加权路由逐步发布变更并测试韧性。
能够从变更中学习，并在向会员逐步发布时了解应用程序的韧性。

模式库组件快速入门指南：

让开发人员能够快速上手，同时确保 USAA 开发实践的一致性。
包含与韧性相关的非功能性要求。

无服务器模式：

示例包括异步 API、使用 EventBridge 的编排协作模式，以及使用 Step Functions 进行编排的实时 API。
为无服务器应用程序提供快速入门方案。

容器模式：

使用 Helm chart（用于在 Kubernetes 中定义、安装和升级应用程序的软件包）作为模板，根据具体需求部署基于容器的应用程序。

归档数据模式：

将非活跃数据从活跃系统迁移到成本更低的长期存储中，以提高性能并降低成本；采用本地、云端或混合模式等分层存储，并实施数据分区等策略以实现高效迁移。
包括将数据从应用程序 VPC 迁移到数据 VPC 进行归档的模式。
提供自动快照以及从归档数据 VPC 或本地快照恢复的模式。
根据应用程序需求，确保区域内或跨区域的数据安全迁移和韧性。

选择标准：

根据可靠性、性能、延迟和敏感性，为使用场景确定最佳模式。
帮助应用程序实现一致性，并选择最佳韧性架构。

示例：存款申请的账户开立系统概述：

USAA 用于开立新存款账户（活期、储蓄）的关键系统。
新会员注册流程的一部分。
依赖下游系统的复杂多服务架构。

实施多区域韧性之前：

评估显示其灾难恢复、持久性和可观测性表现不佳。
对会员而言，其韧性和可用性均不够充分。

实施热备用模式之后：

RTO 从 4 小时缩短至 30 分钟。
RPO 从 1 小时缩短至 5 分钟。
在 US East 1 故障期间，可在 30 分钟内完成故障切换，确保会员体验不受影响。
恢复能力和数据处理得到改善，产生了显著的业务影响。

架构设计：

平台账户负责处理网络流量和路由。
应用程序部署在 US East 1 和 US West 2 的 VPC 中（热备用实现）。
使用 DynamoDB 全局表向辅助区域进行近实时复制。

多区域部署的其他注意事项幂等性：

关注同一笔交易能否提交多次而不产生不良影响。
在银行领域至关重要，因为资金交易绝不能重复。
从区域内韧性的角度加以考虑。

重试和交易 ID：

必须在 DynamoDB 中管理重试并维护交易 ID。
对于管理 Step Functions 中的状态至关重要。

故障切换期间的状态管理：

在 Step Function 执行过程中进行故障切换时，状态维护是一项挑战。
切换到辅助区域时，状态不会被保留。
必须围绕这一情况进行设计，以确保故障切换期间的韧性。

架构设计（第一阶段）：

纳入幂等性和状态管理等注意事项。
确保故障切换流程在设计层面具备韧性。

运营操作手册（第二阶段）：

描述运营韧性的流程和注意事项。
包括重试、交易 ID 和状态管理的处理方式。

测试和持续反馈（第三阶段）：

从测试和真实场景中的错误与差异中学习。
解决幂等性、性能下降、冷启动以及辅助区域缓存预热等问题。

构建韧性系统的关键：

在设计中充分理解并考虑相关因素。
不仅要确保单个区域内的韧性，还要确保跨多个区域的韧性。
这对于向 USAA 会员提供具备韧性的服务至关重要。

USAA 的韧性框架和成功因素 100% 的新应用程序均通过韧性框架：

USAA 的所有新应用程序目前均须通过韧性框架。
重新评估已部署至 AWS 的现有应用程序，确保其满足韧性需求。

转向稳健的多区域策略：

根据总结出的最佳实践，将更多应用程序迁移到多区域架构。
示例：账户开立系统的 RTO 和 RPO 得到显著改善。

改进韧性评审和架构评审：

随着学习和反馈的增加，韧性评审和架构评审速度越来越快。
对各项权衡的理解加快了这一流程。
在近期故障期间，与韧性相关的事件减少了 66%。

实现韧性的组织成功因素文化：

技术人员、IT 团队和业务合作伙伴共同承担责任。
理解韧性的含义并定义服务等级目标（SLO）。

架构领导力：

获得高管支持和专项资金，将韧性作为主要目标。
以会员需求为使命，推动对韧性的投入。

方法：

从小处着手，先对单个应用程序进行多区域部署。
从初始部署中学习，并通过短反馈循环扩大规模。
提高平台成熟度以及韧性实施的一致性。

工具：

投资自动化和自助服务能力。
在 SDLC 中提供蓝图，并提供基础设施即代码（IaC）模板。
确保开发人员无需反复返工或进行繁重的手工操作，即可实施韧性实践。
这是在提供优质会员服务的同时实现业务目标的关键。

会议要点标准化可加速采用：

使用蓝图和模板降低复杂性。
帮助开发人员和业务利益相关者更轻松地理解韧性。

左移：

在项目构思阶段更早考虑韧性。
与业务合作伙伴建立协作关系，使韧性策略与业务需求保持一致。

持续测试：

测试必须持续并迭代开展。
从故障和韧性测试中学习，不浪费任何学习机会。
通过持续测试和反馈建立信心。

文化和技术必须共同演进：

在整个组织内树立韧性思维。
运用这种思维影响技术开发。
确保文化和技术协同发展，以实现长期成功。

FSI Meetup 2025 Q4 - 规模化提升韧性

回顾系列

场次笔记