监控系统报了十种异常，值班群却只收到两种，剩下八种靠客户投诉发现——告警体系没设计好的典型症状。本文复盘机器人告警体系的设计：什么该报、报给谁、怎么避免狼来了。

背景痛点

告警体系最常见的两个极端：要么什么都报，值班群每天几百条，最后所有人静音了群；要么什么都不报，故障靠客户先发现。告警的价值在于信噪比，不在数量。

原理

所谓机器人告警体系，是指按分级、分路、防抖原则组织的异常通知机制：

异常事件采集 → 按级别分类 → 高级别直推值班群 → 低级别进日报 → 同源告警窗口内聚合 → 处置后自动记录。

五个关键点对应五个设计维度：分级（什么该报）、分路（报给谁）、聚合（防风暴）、静默（防打扰）、闭环（处置留痕）。告警的出口就用机器人自身——用消息接口把告警推到值班群，Eyun 开发文档按文档接入，机器人自己给自己报警。

核心实现

分级告警的推送逻辑（仅演示，上线前对照官方文档校验）：

def alert(evt):
    # 仅演示，上线前对照官方文档校验
    # dedup/aggregate/send/daily_report 为告警体系内部组件
    key = f"{evt.source}:{evt.kind}"
    if dedup.window_hit(key, seconds=300):
        return aggregate.merge(key, evt)       # 5分钟窗口内同源告警聚合
    if evt.level == "P0":
        send(["oncall_group"], fmt(evt))       # P0 直推值班群
    else:
        daily_report.append(evt)               # 其余进日报

聚合器定时把窗口内合并的告警补发一条汇总。

踩坑

一、分级标准要写文档：P0 的定义是"客户可感知且需要人立即处理"，写不清楚的分级执行两个月就会退化成全部 P0——分级文档和告警代码一起维护。

二、告警渠道不能只有机器人一条：机器人自身故障时它没法报警自己，P0 告警留一条短信或电话通道作为最后防线，这条通道只在机器人失联时启用。

三、静默窗口要可查询：值班期间正在处理某个故障时，同源告警的重复推送要可暂停——静默是处置的一部分，不是掩盖问题。

四、每天一条告警日报：低级别异常进日报而不是实时推送，日报里零异常的日子也要发"今日无异常"，证明采集链路本身活着。

总结

告警体系的验收标准：值班群每天的消息量稳定在个位数，每条都需要人看。做到这个信噪比，告警才会被认真对待。本文基于 Eyun 平台的企微接口实践整理，消息推送与回调事件的结构以官方文档为准，先做分级和聚合两件事，告警体系立刻能上一个台阶。开通与调试环境可参考Eyun 平台。