OTP 到达率在特定地区异常下降时，运营团队该查什么

重点监测信号

• 单一地区投诉量在 48 小时内持续上升
• 其他地区到达率稳定但该地区连续下跌
• 上游路由日志出现非标准超时码

复合行业案例。 本文描述可复用的业务问题与判断方法，不代表具名客户、真实对话、合同、收入结果或客户证言。

周五下午，运营后台的投诉工单开始堆积。用户反馈集中在同一个省份——收不到验证码，重试三次仍然失败。工程师查了号码格式校验规则，没有报错。检查了风控策略，也没有批量拦截记录。上游短信路由的监控面板上，到达率曲线从中午开始下滑，但日志里没有明确的错误码。

这种情况在很多身份验证团队里反复出现：故障信号清晰——到达率下降、投诉集中——但排查链条上的每一环都说“我这里正常”。没有人能确认根因，也就没有人敢执行修复动作。

为什么“看起来都正常”才是陷阱

问题不是故障本身，而是故障的可见性剪裁。号码格式校验只看号码是否通过正则，不管该号码在目标运营商是否活跃。风控策略只看请求是否命中规则，不管短信是否真实触达手机。上游路由只看是否成功提交给运营商网关，不管运营商网关之后的下发结果。

每一层工具都只对自己边界内的数据负责。当故障恰好落在三层之间的空白地带——比如号码格式合法、风控未拦截、路由提交成功，但运营商在网关之后做了局部拦截——所有监控面板都会显示绿色，只有用户投诉在涨。

证据核实框架：三层排查，一次定位

运营团队需要一个能跨层拼接证据的工作框架。这套框架不依赖新系统上线，只要现有日志和工单数据可导出，就能执行。

第一层：号码格式与运营商兼容性排查。 导出投诉号码的前七位（号段），与历史正常号码做号段分布对比。如果投诉号码集中在少数号段，说明是运营商局部问题；如果号段分布与正常期一致，说明问题不在号码侧。这一步排除“是不是格式清洗漏了某些号段”的怀疑，耗时约 30 分钟。

第二层：风控策略误伤排查。 将投诉号码在风控系统的请求日志里做一次回查，区分“被风控拒绝”和“通过风控但未到达”两类。如果通过风控但未到达的比例在目标地区显著高于其他地区，则风控不是根因，故障在更下游。这一步让风控团队可以退出排查序列，减少跨组沟通时间。

第三层：上游路由与运营商反馈码分析。 收集该地区所有短信提交后运营商返回的状态码，按码值分组计数。重点找两类信号：一类是非标准超时码（运营商网关已接收但未出最终结果），另一类是特定错误码在投诉时段内数量陡增。这两种信号都指向路由配置——可能是该地区的路由未设置备用通道，也可能是上游通道的并发配额被占满。

团队下一步：把排查流程固化成运营手册

三层排查完成后，责任人已经明确——投诉集中在某个号段、风控无拦截、运营商返回了非标准超时码。这个结论不需要等待上游供应商的工单回复，团队内部就可以执行第一轮修复：切换备用路由通道，观察下一小时到达率变化。

但一个地区的故障解决后，更重要的动作是更新运营手册。应该把这次排查中发现的号段、运营商状态码、投诉时间窗口记录成一条规则，加入日常监控的排查清单。下次同类问题出现时，运营值班人员可以直接跳过基础排查，进入验证阶段。

自动化不能替代什么

分层排查框架可以减少从投诉到根因的平均耗时，但它依赖一个前提：每个环节的日志数据可以按“投诉地区 + 号段 + 时间窗口”这三个维度拼接。如果团队仍然依赖人工导出 CSV 再逐列对比，排查窗口可能被数据准备时间拖长。

这也是为什么有些团队在积累足够多的排查模板后，会考虑用工具将前三层排查做成自动化信号聚合——让系统每小时自动比对投诉集中度、风控通过率和运营商状态码分布，只在出现跨层信号交叉时才生成一条待复核告警。

自动化处理的是“数据拼接”这个操作性步骤，而“判断这是否是一条需要干预的信号”仍然是运营负责人的决策。工具可以告诉你号段分布变了、状态码数量涨了，但要不要切换路由、要不要通知上游、要不要临时期限内放宽该地区的风控阈值——这些判断需要业务上下文，无法交给规则引擎。

对于身份验证运营团队来说，最有效的改进不是引入更贵的路由，而是让每一次投诉都有清晰的排查路径可走。当故障信号从“用户说收不到”变成“号段 A 在运营商 B 返回超时码 C”，修复就不再是猜测，而是验证。

常见问题

到达率异常是否一定是上游路由问题？

不。号码格式清洗异常、风控策略误伤、运营商局部拦截都可能表现成“到达率下降”。路由问题是最后排查的层，不是第一个。

人工复核的窗口期多长？

取决于业务容忍度。常规建议是投诉上升后 4 小时内完成第一轮分层排查，24 小时内给出根因判断。超过 48 小时未分层的问题，往往被新投诉淹没。