DORA 之下的移动运营韧性：面向 BFSI 关键旅程的最简演练库

如果说第 2 篇文章讲的是如何让 DORA 合规感觉像是正常的发布治理，那么本篇讲的就是移动团队总会被问到的下一个实际问题：

“当出问题的时候会怎样？”

在 BFSI 移动领域，这个问题很少是纯理论的。一个依赖出现性能下降、一家供应商遇上糟糕的一天、一次配置变更以错误的方式波及开来，客户突然就无法登录或无法批准一笔支付。运营韧性的目标并不是假装这些事情永远不会发生，而是要确保您已经演练过那些最重要的失效模式，并且能够展示您做了什么、学到了什么。

本文为您提供一个专注于移动关键旅程的简易演练库。它的设计宗旨是易于执行、易于取证，并且随着时间推移易于改进，而不会把您的团队变成一个全职的演练委员会。

如何使用本文

如果您想用最简单的方式获得价值，就从下面的演练库中挑选四个演练，从那里开始。一次针对一个旅程运行一个演练，并保持输出的一致性。使用第 3 步中的演练报告模板，并让后续事项保持小而具体。在开始之前，请确保所有人对您实际要保持韧性的对象达成一致。

“运营韧性”对移动团队意味着什么

对于移动而言，韧性最好用“客户能否安全地完成一个关键旅程”来衡量，而不是“系统是否在线”，也不是“监控是否触发”。旅程让您保持诚实，因为它们反映了用户的真实体验。

在 BFSI 移动领域，关键旅程是可预测的：

• 登录
• 增强认证（step-up），比如 OTP 或推送批准
• 账户恢复
• 支付与转账

当这些旅程出现性能下降时，客户会立即感受到。这就是为什么一个以移动为先的运营韧性计划要从旅程开始，然后反向推导到依赖。

让我们先选定旅程，再映射依赖，因为当所有人都对什么与什么相连达成一致时，演练会容易得多。

第 1 步：选定您的关键旅程，然后列出它们的依赖

保持简单。先从三到五个旅程开始。大多数团队起初并不需要超过这个数量。

推荐的 BFSI 移动旅程集合

• 登录
• 增强认证、OTP 和推送批准
• 账户恢复
• 支付与转账
• 开户与 KYC（如果您的应用中有的话）

为每个旅程记录依赖

您不需要一张完美的图。一份简短的清单就足够了。

登录的依赖清单示例：

• 身份提供方和令牌服务
• 后端 API 网关
• 风险或欺诈决策（如果在登录时使用）
• 可以改变认证行为的远程配置或功能开关
• 移动网络层配置，包括证书锁定（如果使用）
• 可观测性和遥测流水线

正是这份依赖清单，把“韧性”变成了您可以测试的东西。

现在我们可以运行与真实失效模式相匹配的演练，而不是为了制造混乱而制造的通用混乱。

第 2 步：演练库——BFSI 移动中最重要的那些场景

以下是一些无需庞大准备工作就能运行的演练。每一个都绑定到一个关键旅程以及一种会在 BFSI 中造成真实客户影响的依赖模式。先从三到四个开始，运行它们，写下让您感到意外的地方，然后再扩展。您并不是要成为一家混沌工程公司，而是要让最常见的失效模式变得平淡无奇。

保持这些演练一致的一个简单方法，是每次都回答相同的五个问题：我们模拟了什么、我们如何安全地模拟它、应用应当做什么、团队应当能够看到和决定什么，以及我们保留什么证据。

快速开始：如果您只运行四个演练

如果您一开始只运行四个演练，这一组就涵盖了 BFSI 移动的大量现实情况：

• 身份提供方性能下降
• OTP 延迟与投递失败
• API 网关、WAF 或限流拦截了合法的移动流量
• 远程配置或功能开关失误

演练	受影响的旅程	什么出了问题	“良好”是什么样子	要采集的证据
1. 身份提供方性能下降	登录、令牌刷新	认证延迟高、间歇性 5xx、刷新失败、会话引导失败	带退避的安全重试，不出现重试风暴；干净的会话状态；清晰的错误体验；快速的、按版本界定范围的影响评估	认证延迟和错误仪表板；按版本界定范围的影响说明；已测试缓解措施的决策日志
2. OTP 延迟与投递失败	增强认证	OTP 延迟或缺失、重发循环、限流、关联超时	强制执行的重发次数限制和冷却时间；没有用户死胡同；安全的提示信息；清晰的运营回退选择	OTP 成功率和延迟快照；用户体验状态的采集；对重发/UI 策略的后续变更说明
3. 推送批准中断	增强认证、批准	推送延迟/中断、令牌失效、超时后的迟到批准	干净的超时；没有卡住的批准；跨重试的一致状态；清晰的恢复路径	推送投递指标；迟到批准的时间线快照；面向支持/升级的运行手册更新
4. API 网关、WAF 或限流拦截移动流量	登录、支付	WAF 规则误触发、严格限流、API 网关部分性能下降、特定端点的拦截	对 4xx/5xx 的稳定处理；有界的重试；无负载放大；安全的支付重试行为	配置变更日志片段；回滚前后的错误率；针对 429/403 的客户端行为说明
5. 证书轮换与锁定失败演练	所有涉及网络的旅程	证书链问题、pin 集合不匹配、信任失败、设备时间偏移	可预测的失败状态；经过演练的恢复；没有不安全的“直接关掉它”式变通做法	运行手册摘录和改进；按应用版本界定范围的影响；轮换流程的关键经验
6. 远程配置或功能开关失误	登录、支付、启动稳定性	错误的配置发布、配置服务中断、陈旧或不一致的开关	安全的默认值；防范错误组合的护栏；稳定的启动；可被验证的快速回滚	配置审计轨迹快照；回滚前后的指标；对默认值/护栏的后续改进
7. 欺诈或风险决策配置错误	登录、增强认证、支付	误报、锁定、意外的增强认证激增、不一致的风险结果	一致的处理；安全的提示信息；给用户清晰的下一步；协调的回滚和恢复度量	风险决策指标快照；如有需要则更新支持指引；策略变更和回滚的决策日志
8. 影响某一旅程的第三方依赖事件	支付、开户/KYC、风险评分	供应商错误/延迟、响应格式异常、依赖行为降级	安全降级；一致的状态；没有反复的放大调用；清晰的回退决策	供应商错误/延迟快照；回退决策摘要；新增的监控/运行手册改进

只有当您采集了正确的证据时，演练才有用；否则它们就变成一个消失在聊天记录中的日历事件。

第 3 步：每个演练应当产出什么——真正有帮助的证据

让演练的输出保持轻量且一致。您想要的，是既能帮助工程团队改进、又能帮助决策者理解风险，并且能够支撑您日后会需要的证据的东西。

最简演练报告模板

每个演练都使用相同的模板。

演练报告	详情
演练摘要	测试的旅程 • 模拟的场景 • 环境 • 参与者（角色，而非姓名）
关键时刻	开始时间 • 检测时间 • 遏制措施及时间 • 恢复时间
影响	客户体验 • 受影响的应用版本（如相关）• 区域或供应商特定的说明
决策	改了什么、由谁改、为什么改 • 没改什么以及为什么不改
结果	哪些运转良好 • 哪些令人困惑或缓慢 • 缺失的监控/遥测
后续事项	1–3 项具体改进 • 每项改进的负责人 • 各项改进的验证计划

这样的证据足以有用，又不至于变成文书工作。

现在是最重要的部分——把演练的经验转化为发布控制，这样同样的问题就不会再次让您措手不及。

第 4 步：闭环——演练应当改变发布控制

正是在这里，韧性工作成为您发布计划的一部分，而不是一项平行开展的活动。

每次演练之后，提出两个问题：

• 在发布之前，什么本可以预防这个问题或减少影响？
• 我们应当往发布基线或运行手册中添加什么，以便下次做得更好？

“从演练到控制”式改进的示例：

这也是第 2 篇文章和第 3 篇文章相衔接的地方。发布基线应当包含一小组韧性就绪度控制。而演练正是让这些控制变得真实的东西。

最后一个实用细节：如何在不造成中断、也不把流程过度工程化的前提下运行演练。

如何在不让团队痛苦的情况下运行这些演练

几条小规则能让韧性演练对移动团队来说可持续。

如果实时测试有风险，就从桌面推演（tabletop）演练开始。您仍然可以走查场景、验证责任归属和决策点，并改进运行手册，而无需触及类生产系统。让每个演练一次只专注于一个旅程，因为一次测试所有东西通常意味着您什么都没清楚地学到。

每次都使用相同的演练报告模板，哪怕它很简短，以此保持输出的一致性。有意地限制后续事项。每个演练一到三项改进就足够了，否则演练会积累出一个没人愿意认领的待办积压。最后，稍后重新运行一个场景。重复是您证明这些改动提升了韧性的方式，也是让演练不再感觉像一次性事件、而开始感觉像正常移动运营的方式。

结论

DORA 之下的运营韧性不必复杂。对移动团队而言，最简单的方法就是聚焦于关键旅程，演练那些会破坏它们的失效模式，并产出能够带来具体改进的轻量证据。

在下一篇文章中，我们将处理移动领域往往制造最多意外的那个方面：第三方风险。我们将涵盖 SDK 清单与变更控制、关键旅程的供应商依赖，以及如何构建便于日后审查的证据包。

下期预告： 面向移动应用安全的 DORA 第三方风险：SDK 治理与可供审计的证据包