您的KYC服务提供商出现故障。请继续进行客户注册和验证，避免盲目批准客户。

一位顾客已输入个人信息、拍摄身份证照片并完成自拍。最后一次验证超时。他们重试。您的应用发送了另一个请求。客服收到一张显示“验证失败”的屏幕截图。

您的客户并没有做错任何事，但您的系统却告诉他们做错了。

在系统中断前做好规划。目标是在保留审批所需证据的同时，保障客户体验。您不应该被迫在失去所有申请人和在没有必要证明的情况下批准申请之间做出选择。

将客户故障与服务故障区分开来

文档无法读取、身份不匹配和提供商不可用需要采取不同的应对措施。超时意味着您尚未获得可靠的答案，但这并不意味着 ID 无效，也不能因此就默认通过。

将您的产品设置为待处理或暂时不可用状态。记录下背后的技术原因，以便您的运维人员了解情况，同时向客户提供清晰的解释和后续步骤。

例如：“我们目前无法完成检查。您的进度已保存。完成后我们会通知您。” 只有在您的集成确实提供保存进度或通知功能的情况下，才承诺保存进度或提供通知。

保护已完成的工作

让客户持续关注同一流程，并提供权威记录，明确哪些步骤已完成，哪些步骤仍未解决。不要仅仅因为政府记录服务不可用就要求提供新的自拍照。

为顾客提供安全的离开和返回方式。告知他们是否需要采取行动、访问是否受限以及在哪里可以获取最新消息。避免显示会重新启动整个流程的重试按钮。

异步验证和幂等请求指南中涵盖了工程模式。您的业务连续性计划应决定这些机制何时运行以及由谁负责监控待办事项。

选择一个能回答相同问题的备选方案

第二个服务提供商并不一定意味着它是独立的备份。两种服务可能都依赖于同一政府资源或网络。务必询问在您计划的故障情况下，哪些服务仍然可用。

更换途径时，证据也可能发生变化。身份证照片和实时政府记录比对所证明的内容并不相同。请记录差异，并在可接受替代方案时获得保单持有人的批准。

您可以采取的措施包括等待、使用已批准的等效途径、请求提供适当的替代证据或将案件提交给审核员。人工审核仅在审核员拥有充分证据和权限的情况下才有效。它无法将缺失的强制性检查变成已完成的检查。

不要因为积压案件令人不舒服就放松筛选或身份验证要求。

在引发另一起事件之前进行控制重试

制定重试策略，限制重试次数，逐步增加延迟，并设定一个暂停点，以便操作员审核。遵循服务文档中记录的重试指南。保持请求与原始客户操作的关联性。 API 支持它。

如果服务提供商已完成检查，则应检查超时的请求。否则，延迟成功并重新尝试可能会导致记录冲突、产生额外费用或发送两条客户消息。

连续性测试应该包括延迟和乱序的结果，而不仅仅是清晰的“服务不可用”响应。

明确你要衡量的是什么。

询问供应商他们的可用性数据涵盖哪些内容。 API 健康探测、托管捕获页面和已完成的验证流程是不同的衡量标准。成功请求健康端点并不能证明所有外部数据源都可用。

Toden 的可靠性页面解释了其监控范围、观察周期和计算方法。请结合您自身的端到端成功和完成时间阅读这些详细信息。

事件发生期间，跟踪受影响的支票和国家/地区、待处理的行程、最长等待期的案例、重试次数和客户联系情况。指定一名升级负责人和一名可以做出相同决策的备用负责人。

故意恢复队列

服务恢复后，不要一次性释放所有排队的请求。应以可控的速率恢复服务，协调延迟的响应，并检查每个客户是否都收到了正确的最终结果。

抽取部分重试、放弃或收到相互矛盾信息的客户进行分析。统计客户受到的影响，而不仅仅是状态页面显示红色的分钟数。

Toden 工作流提供可配置的检查和决策规则。您的应用程序仍然需要围绕这些结果进行队列处理、客户消息传递和已批准的回退策略。未经确认，请勿假定存在自动跨提供商故障转移功能。

上线前，请与工程、支持和风险负责人一起进行停机演练。如果您正在评估 Toden 请与我们讨论您需要保护的具体依赖关系和客户旅程。