号码状态查询的告警：别让误报叫醒值班
凌晨两点被叫醒三次，两次是名单里几十个号码格式不对，真正把并发打满的那一轮反而没告警。这篇按场景讲清号码状态查询的告警该怎么挂：失败先分三类、五个数挂监控、阈值用基线定、分级写进值班手册。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
凌晨两点十分，值班同学被电话叫醒，这是四小时里的第三次。前两次是同一批名单里四十来个号码格式不对，请求全被挡在参数校验那一步；第三次是一轮批量任务把账号级并发顶满，接口开始返回限流——而这次偏偏没告警，因为看板上成功率还挂着 99.7%。
问题不在告警太少，而在告警只有一个数。失败率把所有失败混在一起，谁都能把它拉响，真正该看的那一类反而被平均数盖住。
调用的失败至少要分成三类，处置方式完全不同。
第一类是请求侧：号码缺位、带区号、含全角字符，或者名单里混进了固话。这类失败重试一百次也是同一个结果，它指向自己的上游校验，属于要改代码的 bug。
第二类是容量侧：触发限流、读超时、连接被占满。这类失败重试有意义，但要带退避，而且要算总预算，否则重试本身会把限流打得更狠。名单高峰期的号码状态查询：把限流跑成常态讲过怎么把限流当常态处理。
第三类是服务端：内部错误、连续没有返回。这类要按 SLA 走，先切备用或降级，再谈原因。
三类混在一个失败率里，后果是可预期的：名单一批格式出错，成功率掉到 80%，告警拉响；同一时间容量问题已经持续了半小时，却因为被平均数稀释而没人看见。
指标不用多，五个够用。
分类失败率，三类各一个，别合成一个总失败率。无结论率单独算，它不算失败但同样消耗额度，比例抬升通常意味着名单质量或覆盖范围变了。延迟看 P95 而不是平均，一轮批量任务的尾巴全在分位数里。号码状态查询的耗时构成：平均两百毫秒为何跑一夜拆过这个尾巴。限流响应的次数要单独计数，它是最早的容量信号。最后是余额与配额的消耗速度，按天折算还剩几天的量。
五个数背后是同一个原则：每个指标要能独立指向一个动作，指不出动作的指标不该上告警，只该进报表。
拍一个失败率超过 5% 就告警，是最常见的写法，也是最容易失效的写法。名单结构一变，常态失败率就变了，阈值还停在原处。
稳一点的做法是取近四周同一时段的基线，偏离基线三倍且连续两个统计窗口才触发。数量小的批次别用比例，一千条以下按绝对条数兜底，避免三条失败就报警。
阈值要跟着名单量走，名单量翻倍的时候顺手复核一遍。这一步不做，半年后阈值和业务早就对不上了。
分级不按严重程度排，按「十分钟内不处理会不会扩大」排。
会扩大的才叫人：鉴权失败说明凭据有问题，整条链路都在空转；账号级限流持续说明配额或并发已经打满；连续三个窗口没有返回，大概率是服务方侧故障；余额低于一周用量，充值流程走不完就会断供。
不会扩大的一律记账：无结论率小幅上浮、单批次延迟略高、偶发一次限流。这些进日报，次日上午一起看。
分级定完，还要给值班手册配一条纪律：每月 P1 超过两次，回头查阈值或链路，而不是让人多扛几次。误报不会自己变少，只会让真报没人信。
按请求逐条告警，是值班崩溃的直接原因。正确做法是按批次聚合：一条消息带上批次号、总量、三类失败的条数、首次发生时间，以及最多三个脱敏后的样例。
聚合要配抑制窗口，同一批次同一类失败半小时内只发一次；恢复通知也得发，否则下一个人会从头再排查一遍。
第一步看分类计数，判断是哪一类失败。第二步看同一时段其他批次是不是也这样，单批次异常多半在数据，全批次异常多半在链路。第三步看凭据、出口地址、配置最近有没有变更，变更窗口和故障时间对得上，基本就定了。
三步都正常，再往外找服务方。没有这三步，告警就只是把人叫醒，不解决问题。号码状态查询的六个报表问题：成功率该怎么算里的分母口径，也适用于告警里的比例——分母换了，同一个故障看起来能从 5% 变成 50%。
看五条：失败有没有分三类；指标是不是都指向一个具体动作；阈值有没有基线；分级是不是按会不会扩大；同一批次会不会只发一条。
五条都做到，值班桌上的电话会安静不少，而安静的夜晚才是监控系统合格的样子。
指标做得再细，也补不上覆盖的缺口：由转售企业放号的号段、装进设备里的物联卡、机主登记在境外的号码，这三类在任何批次里都只产出一条无结论。把它们算进失败率，等于每天给自己报一次假警；正确做法是在清洗阶段标成范围外，不进分母。
告警里最值得盯的那个数始终是延迟与限流，它们决定一批名单能不能在截止时间前跑完：直连移动、联通、电信三网，八种状态与携号转网识别是基础能力，鉴权走请求头携带 AppCode，按次计费、即买即用，每次调用的耗时与配额口径以【阿里云号码状态检测】商品页为准，对着它设基线比拍一个百分比靠谱。
文章评论
发表评论
请先注册/登录后评论