预警分级策略：从P0到P3的通道组合选择

2026-09-24

预警分级：不同严重度该配什么通道运维告警一拥而上、值班人员被轰炸到麻木，是很多团队的常态。根因不是通道不够强，而是没有分级——把磁盘使用率75%和数据库宕机放在同一个通知级别里，前者浪费通道，后者反而被稀释。预警分级的本质，是让告警打扰强…

预警分级：不同严重度该配什么通道

运维告警一拥而上、值班人员被轰炸到麻木，是很多团队的常态。根因不是通道不够强，而是没有分级——把磁盘使用率75%和数据库宕机放在同一个通知级别里，前者浪费通道，后者反而被稀释。预警分级的本质，是让告警打扰强度和业务损失程度匹配起来。

互亿无线预警通知API（alert.ihuyi.com）提供短信、语音、闪信三种通道，可按P0到P3四个级别灵活组合。本文梳理一套可落地的分级策略。

四个级别的定义边界

先把P0到P3的边界划清楚，避免团队内部对级别理解不一致：

级别	业务影响	响应时效	典型事件
P0	核心业务中断/数据安全风险	分钟级	数据库宕机、数据泄露、安全入侵
P1	核心功能受损但有降级	15分钟内	支付超时、主从切换失败
P2	非核心功能异常	工作时间内	接口变慢、备份延迟
P3	趋势性/提示性事件	当天处理即可	磁盘超阈值、证书到期

级别定义要和业务方对齐，不能运维自己拍脑袋。P0和P1的边界尤其要写清楚——哪些事值得起凌晨三点叫醒人，团队共识很重要。

每级配什么通道

通道打扰强度从低到高是：短信 < 闪信 < 语音。按级别匹配：

P3：仅短信。成本低、留档，知道即可
P2：短信加状态回执。跟踪是否送达，必要时升级
P1：短信加语音双呼。电话振铃叫醒，短信留档
P0：短信加语音加闪信三合一。三重备份，多人轮呼

这个配比的逻辑是：打扰强度随级别递增，成本也随级别递增，但P0/P1本身低频，总成本可控。反过来如果P3也打电话，几周之内值班人员就会形成拒接条件反射，真正P0来了也被叫不醒。

升级机制：从低级别自动爬到高级别

分级不是一次性判定。一条P2告警如果长时间无人响应，应该自动升级：

P3短信发出后30分钟无回执确认，升级为P2短信加语音
P1双呼后15分钟无人接听，升级为P0三合一并通知备班
P0三合一发出后仍无人响应，按通讯录继续轮呼下一人

互亿无线的多人通知能力支持一次告警通知多个号码，升级逻辑可以在业务系统里编排，也可以通过模板配置实现。关键是让「无人响应」这个状态本身触发动作，而不是干等。

代码示例：分级分发

下面是一段按级别路由到不同模板的简化逻辑，实际项目中可接入现有监控系统：

import requests

ROUTING = {
    "P3": {"url": "https://api.ihuyi.com/sms/Submit.json", "tpl": "TPL_P3"},
    "P2": {"url": "https://api.ihuyi.com/sms/Submit.json", "tpl": "TPL_P2_ACK"},
    "P1": {"url": "https://api.ihuyi.com/sms/Submit.json", "tpl": "TPL_P1_DUAL"},
    "P0": {"url": "https://api.ihuyi.com/sms/Submit.json", "tpl": "TPL_P0_ALL"},
}

def dispatch(level, mobiles, content):
    route = ROUTING[level]
    for m in mobiles:  # 多人轮呼
        requests.post(route["url"], data={
            "account": "API_ID", "password": "API_KEY",
            "mobile": m, "templateid": route["tpl"], "content": content,
        })

dispatch("P1", ["13800138000", "13900139000"],
         "【P1】支付接口成功率降至88%，持续10分钟。")

这段代码把分级、多人、模板三件事串起来。通道组合、失败切换、回执跟踪都在互亿无线平台侧完成。