告警没发出去，是很让人焦虑的故障之一。排查时如果东一榔头西一棒子，往往半小时还没定位。建立一套分层排查方法论，能把问题快速收敛到具体环节。本文按"从外到内"的顺序，梳理预警通知发送问题的排查步骤。 分层排查的整体思路 一次发送涉及五个环节：…
告警没发出去，是很让人焦虑的故障之一。排查时如果东一榔头西一棒子，往往半小时还没定位。建立一套分层排查方法论，能把问题快速收敛到具体环节。本文按"从外到内"的顺序，梳理预警通知发送问题的排查步骤。
分层排查的整体思路
一次发送涉及五个环节：业务代码、网络出口、接口认证、平台受理、运营商送达。排查时从外层开始，逐层缩小范围，不要一上来就怀疑服务商。核心原则是把"请求有没有到平台"和"平台有没有送到手机"两段分开看。
排查步骤清单
- 看业务日志：请求有没有发出去？参数对不对？超时了吗？
- 看接口返回码：code 是多少？是业务错误还是网络异常？
- 用 Postman 复现：绕过业务代码直接调，排除代码层问题。
- 查控制台记录：平台侧有没有这条流水？送达状态如何？
- 查手机端：是否被安全软件拦截、是否静音、是否停机。
# 快速自测脚本,定位是代码问题还是平台问题
curl -X POST https://api.ihuyi.com/sms/Submit.json \
-d "account=APIID" -d "password=APIKEY" \
-d "mobile=本人手机号" -d "content=【自测】排查测试"常见错误的对照
- 返回参数错误：检查 account/password 是否填反、mobile 格式、content 编码。
- 返回余额不足：去控制台确认套餐余量，或补充测试额度。
- 返回 code=2 但手机没收到：查回调状态，多半是被手机拦截。
- 语音没拨通：content 过长、号码无人接听，或换时段复测。
排查决策表
| 现象 | 前段：到平台了吗 | 后段：送到手机了吗 |
|---|---|---|
| 请求发不出 | 查网络/超时/参数 | — |
| code 非 2 | 查认证/余额/参数 | — |
| code=2 无短信 | 已到平台 | 查回调与手机拦截 |
| 语音未接 | 已到平台 | 查通话时长/重拨升级 |
排查时建议把每一步的请求参数、返回码、时间戳都记录下来，复现问题时一目了然；如果是偶发问题，保留当时的网络日志有助于服务商协助定位。
排查时保持一个原则：先确认请求有没有到平台，再确认平台有没有送到手机，两段分开看就不会乱。
建立排查知识库
每次排查完把现象、返回码、解决办法记下来，半年后就有一份属于自己团队的错误速查表。互亿无线返回码说明和接口文档是常备参考，遇到拿不准的情况也可以联系免费技术支持。
把排查经验沉淀成速查表
每次排查完，把现象、返回码、解决办法记一条，半年就有一份团队自己的速查表。新人遇到同样问题不用从头猜，照着速查走一遍就能定位大半。
| 现象 | 常见原因 | 快速处理 |
|---|---|---|
| 参数错误 | 账号填反或编码问题 | 核对参数 UTF-8 |
| code=2 无短信 | 手机拦截 | 换号或查回调 |
| 语音未接 | content 过长或无人接 | 缩短文案、重拨升级 |
| 请求卡住 | 没设超时 | 补 timeout |
排查时记得把请求参数、返回码、时间戳都留档，偶发问题靠这些日志才能复现。
排查时的心态
发送问题多半出在参数、拦截、超时这几处，按层推进很快能定位。保持冷静，先确认请求到没到平台，再确认送到没到手机，两段分开看就不会乱。拿不准时，接口文档和免费技术支持都能帮上忙。
分层排查的口诀
先看请求出没出，再看返回码对不对，接着绕过代码用 Postman 复现，然后查控制台流水，再查手机端。五步走完，问题基本定位在某一段，不用到处乱试。
排查收尾
把每次排查的现象、返回码、解法记下来，攒成团队速查表，下次同类问题直接照方处理。
按层推进、留好现场，大多数发送问题十分钟内就能定位，不必慌乱。
建立分层排查方法和团队速查表，发送问题定位会越来越快，不必每次都从头摸索。
按层排查、留好日志，发送问题多半十分钟内见分晓。
把每次排查结论沉淀进速查表，团队整体定位速度会越来越快。
排查告警问题时保持冷静、按层推进，大多数问题十分钟内能定位。注册免费试用在测试环境把排查流程练熟。