短信OTP送达故障转移：一个供应商倒下之后你的用户等了多久

判断时关注的线索

典型场景演示。 本文用于解释业务信号的判断与人工核实方法，不代表真实客户、对话、合同、收入结果或转化数据。

某个周二下午，东南亚区域的主要短信网关突然不可用。不是部分不可用——是完全中断。你的监控面板上，该区域的 OTP 送达率从正常水平骤降至接近零。用户开始抱怨“登录收不到验证码”，客服队列瞬间塞满。业务团队在群里追问：“还要多久恢复？”

你的团队只有这一家短信网关的正式合同和路由配置。虽然年初技术评审时提过“应该加一条备用通道”，但这个需求一直被排在了优先级列表的下方——毕竟主网关在过去两年里只出现过两次重大故障，每次都在两个小时内恢复了。这次不一样。三个小时过去了，供应商的状态页面仍然是“正在调查中”。

这个场景不是虚构的——任何依赖单一短信网关的验证平台，迟早都会遇到类似情况。区别只在于：你的团队是在故障发生后第一次认真思考多供应商架构，还是在故障发生前就已经把故障转移机制作为基础设施的一部分来设计。

当故障已经发生时，人的本能反应是“先切到备用供应商再说”。但这个本能会带来三个后续问题：你不知道备用供应商在该区域的覆盖是否跟主供应商一致；你不知道切过去之后成本会涨到什么水平；你不知道故障恢复后怎么切回来而不造成新的混乱。

所以故障转移机制的设计起点不是选择备用供应商，而是先完成一次故障模式与影响分析。你需要回答的问题包括：哪些区域是单点故障（只有一家供应商覆盖）？哪些运营商在每家供应商上的历史送达率分布如何？每种故障类型（完全中断、部分降级、延迟升高）分别需要什么级别的响应？

做完这些分析之后，你会得到一个清晰的地图：哪些区域必须立即补充备用供应商、哪些区域的现有覆盖已经足够、以及哪些故障类型适合自动切换而哪些需要人工介入。

多供应商故障转移的自动切换规则需要平衡三个互相矛盾的约束：速度（故障发生后多快切走）、准确性（是否真的需要切换，还是只是短暂波动）、以及成本控制（备用供应商的单价可能更高）。

速度层面，切换阈值需要基于滚动窗口而非单点采样。比如连续两个五分钟窗口内的送达率都低于基线的一半，才触发切换。单点采样容易被瞬时网络抖动误触发，导致不必要的切换和成本浪费。

准确性层面，需要区分“供应商故障”和“区域网络故障”。如果三家覆盖同一市场的供应商同时出现送达率下降，问题更可能出在运营商侧而非供应商侧。这时候切换供应商无济于事，反而会让问题更难定位。自动切换规则需要包含跨供应商的交叉验证逻辑。

成本层面，需要为每个备用供应商设置流量上限和成本预算。自动切换不加限制地让流量涌入备用供应商，可能导致当日预算在数小时内耗尽。切换规则需要包含流量封顶——例如备用通道最多承担正常流量的两倍，超出部分进入队列等待而非无限堆积。

故障转移容易，故障恢复后的回切更难。主供应商恢复服务后，有两个选择：立即将所有流量切回，或者逐步切回。

立即切回的风险是：主供应商可能还在不稳定状态，刚恢复又被流量冲垮。逐步切回的风险是：在过渡期内同时维护两套路由逻辑，运维复杂度翻倍，且两套路由之间可能因为流量分配不均产生新的问题。

实践中，更可控的策略是：先让一部分低优先级流量（如密码重置验证而非登录验证）走主供应商，观察一段时间的送达率是否稳定，再逐步将高优先级流量切回。这个优先级分级本身需要在切换规则中预先定义，而不是在故障恢复时临时拍脑袋。

回切完成后，还需要对这次故障做一次完整的复盘：故障的实际持续时长、切换过程中是否有重复扣费、用户在切换期间是否收到了重复验证码、以及本次事件的成本影响。这次复盘产出的行动项，会成为下一次优化切换规则的输入。

每一次生产故障都是架构升级的机会——前提是你的团队有足够的复盘纪律，能将故障中学到的经验固化为系统规则。故障转移机制不是一次性项目，而是随着供应商格局、区域覆盖和业务规模持续演进的架构组件。

最值得投入的是两件事：建立基于实时数据的送达率监控面板（不仅显示当前状态，也显示各供应商在各区域的趋势），以及定期执行故障转移演练（不等到下一次真实故障才验证切换逻辑是否仍然有效）。这两件事的成本远低于一次大型故障带来的用户流失和客服成本。

故障转移后为什么会出现重复扣费？

当主供应商返回超时但没有明确返回失败状态时，转移逻辑可能认为请求未送达而通过备用供应商重新发送。最终两条短信都成功送达，用户收到两条验证码，平台被两家供应商各扣一次费用。需要在切换逻辑中设置幂等性标识，确保同一个验证会话不会触发多条计费短信。

自动切换和人工判断各负责什么？

自动切换负责快速止损——当监控指标超过阈值时，将流量从故障供应商切走，这个动作不应有人工延迟。人工判断负责事后恢复——当故障供应商指标恢复正常后，是立即切回还是保留在备用供应商上观察，需要SRE根据故障根因和恢复质量做决定。