预警通知API超时与重试：保障告警不丢失

请求卡住没有下文怎么办

凌晨三点，监控系统检测到核心服务宕机，程序调用预警通知API发送告警，结果请求因网络抖动一直挂起，既不返回成功也不返回失败。值班人员没有收到任何通知，故障持续扩大，直到两小时后人工巡检才发现。这是典型的未设置超时与重试导致的告警丢失。互亿无线预警通知API本身响应较快，但调用方必须在工程上做好超时与重试兜底，不能假设网络永远通畅、接口永远可用。

本文说明如何为发送请求设置合理超时、如何设计重试策略，以及重试与换通道的配合。

为HTTP请求设置超时

使用Python requests时，必须同时传入连接超时和读取超时，避免请求无限等待：

import requests

try:
    resp = requests.post(
        "https://api.ihuyi.com/sms/Submit.json",
        data={"account": "API_ID", "password": "API_KEY",
              "mobile": "13800138000", "content": "【告警】服务不可用"},
        timeout=(3.0, 5.0)
    )
    result = resp.json()
except requests.exceptions.Timeout:
    result = {"code": "-1", "msg": "请求超时"}

连接超时控制建立连接的等待时间，读取超时控制等待响应的时间。预警场景建议读取超时设在5秒左右，配合平台5秒首发失败自动换通道能力使用。其他语言同样要在HTTP客户端配置超时，不要使用默认的无限等待。

重试策略设计

超时或返回可重试错误码时，可进行有限次重试。注意接口有幂等保护，重复提交同一内容不会造成混乱，但仍建议控制次数：

1. 仅对网络超时、网关类错误重试，参数错误、认证错误不要重试，重试也不会成功。
2. 采用指数退避，例如间隔1秒、2秒、4秒，不超过3次，避免重试风暴。
3. 重试仍失败时，切换备选通道，短信改语音或闪信。
4. 记录每次重试结果，便于事后审计与问题定位。

import time

def send_with_retry(data, url, attempts=3):
    for i in range(attempts):
        try:
            r = requests.post(url, data=data, timeout=(3, 5))
            if r.json().get("code") == "2":
                return r.json()
        except requests.exceptions.Timeout:
            pass
        time.sleep(2 ** i)
    requests.post("https://api.ihuyi.com/voice/vm", data=data, timeout=(3, 5))

重试与告警升级的配合

重试解决的是临时性网络故障，而通道本身可能失败。建议把重试、换通道、升级通知串成一条兜底链路：

• 短信首发5秒未成功，自动换语音或闪信。
• 语音未接自动重呼一次，振铃60秒，给被叫留出注意时间。
• 主联系人多通道均未触达，升级通知到备班与上级。

重试时要防重复通知

重试虽然必要，但也要避免误重试导致负责人被同一告警叫醒好几次。做法是：给每条告警生成一个独立事件ID，重试和换通道都带上这个ID，下游据此去重。比如短信首次实际已经送达，只是响应在传输中丢了，这时不要盲目重发短信，而是先凭smsid查一次回执，确认未送达再换语音。这样既不丢失告警，也不会重复打扰。互亿无线按成功计费，重复提交未成功的部分不产生费用。

超时设置的参考值

连接超时建议设3秒，读取超时建议设5秒。如果跨地域网络较差，可适当放宽到读取8秒，但不要无限等待。配合平台5秒首发失败自动换通道，整体链路在十秒内就能完成一次兜底，不会让告警卡在半路。

这样即使单次请求出现抖动，告警也不会在某一环静默丢失。互亿无线按成功计费，重试未成功的请求不产生费用。注册免费试用，用测试条数验证超时与重试链路在弱网下的表现。