4、告警路由与分派：告警分派策略（轮询/权重/智能）、告警升级机制、告警通知渠道（电话/短信/钉钉/邮件）

告警分派，说白了就是「这个告警该找谁」。很多团队把告警一股脑全发到群里，结果就是「三个和尚没水喝」——谁都觉得别人会处理，最后谁都没处理。我见过最夸张的一次，一个P0级告警在群里躺了40分钟没人响应，直到用户投诉到老板那里……嗯，从那以后我下定决心，必须把分派逻辑搞明白。

4.1 告警分派策略：三种模式怎么选

分派策略决定了告警到达谁手里。我个人习惯把策略分成三类，你根据团队规模和业务重要性来选。

4.1.1 轮询分派

最简单粗暴的方式。告警来了，按值班表轮流分配。比如今天A值班，明天B值班，后天C值班。轮着来，公平。

我在项目中遇到过一个小团队，就3个人轮班。轮询分派对他们来说够用了，但有个坑——如果A正在处理一个复杂问题，新告警又来了，轮询不会管A忙不忙，照样分给他。结果就是A被压垮，B和C闲着。

4.1.2 权重分派

给每个人设一个权重值。权重高的接得多，权重低的接得少。比如高级工程师权重3，中级权重2，初级权重1。告警来了，按权重比例分配。

为什么要用权重？说白了就是「能者多劳，但也要给新人成长空间」。我建议权重分派配合「技能标签」一起用。比如数据库相关的告警，权重只对DBA生效；网络相关的告警，只对网络工程师生效。

4.1.3 智能分派

这是目前最推荐的方式。基于历史数据、人员技能、当前负载、告警类型等多维度，自动匹配最合适的人。

智能分派的核心逻辑其实不复杂：

# 伪代码示例
def smart_dispatch(alert):
    candidates = []
    for engineer in on_duty_list:
        score = 0
        # 技能匹配度
        if alert.type in engineer.skills:
            score += 40
        # 历史处理成功率
        score += engineer.success_rate * 30
        # 当前负载（处理中告警数越少越好）
        score += (1 - engineer.active_alerts / max_alerts) * 20
        # 最近处理过同类告警（加分）
        if engineer.last_similar_alert < 1h:
            score += 10
        candidates.append((engineer, score))
    return max(candidates, key=lambda x: x[1])

我在项目中遇到过智能分派的一个经典场景：凌晨3点，数据库连接池告警。系统自动匹配了最近处理过3次同类告警的小张，而且小张当时负载最低。结果5分钟就定位到了问题——连接泄漏。如果按轮询分派，可能分给一个不熟悉数据库的新人，那这个晚上就热闹了。

4.2 告警升级机制：别让告警烂在手里

告警升级，就是「第一响应人搞不定，自动找更高级的人」。我见过太多团队没有升级机制，结果一个低级告警因为没人处理，最后演变成P0级事故。

升级机制一般分三级：

升级时间窗口怎么设？我建议根据告警级别来：

• P0级（核心业务中断）： 1分钟未确认 → 升级，3分钟未处理 → 再升级
• P1级（主要功能受损）： 3分钟未确认 → 升级，10分钟未处理 → 再升级
• P2级（非核心功能异常）： 10分钟未确认 → 升级，30分钟未处理 → 再升级
• P3级（告警/警告）： 30分钟未确认 → 升级，2小时未处理 → 再升级

4.3 告警通知渠道：选对渠道，事半功倍

通知渠道不是越多越好，而是「什么场景用什么渠道」。我总结了一个原则：

• 电话： 只用于P0/P1级告警，且必须配合升级机制。电话是最强打扰，别滥用。
• 短信： 用于P1/P2级告警，适合「需要知道但不一定立即处理」的场景。
• 钉钉/企业微信： 日常告警的主要渠道。支持图文、链接、@指定人，信息量丰富。
• 邮件： 用于日报、周报、非紧急告警汇总。别用邮件发紧急告警，没人实时看邮件。

我在项目中遇到过一个问题：同一个告警，电话、短信、钉钉、邮件全发一遍。结果值班工程师的手机震了4次，他以为出了大事，结果一看是同一个告警。后来我改了配置：

# 通知渠道配置示例
alert_rules:
  - level: P0
    channels:
      - type: phone
        timeout: 30s  # 30秒内不接，自动转短信
      - type: dingtalk
        at: true      # @指定人
      - type: sms
        delay: 60s    # 延迟60秒发送，避免重复打扰
  - level: P1
    channels:
      - type: dingtalk
        at: true
      - type: sms
        delay: 120s
  - level: P2
    channels:
      - type: dingtalk
      - type: email
        summary: true  # 只发摘要

4.4 本章知识体系

下面这张图总结了告警路由与分派的整体逻辑，你可以对照着梳理自己的系统：

告警路由与分派，说到底就是「让对的人在对的时间处理对的告警」。轮询简单但粗糙，权重灵活但需要维护，智能分派效果好但需要数据积累。升级机制是兜底，通知渠道是手段。把这些串起来，你的告警系统才算真正「活」了。

公众号:蓝海资料掘金营，微信deep3321