很多团队把告警接到飞书、钉钉或企业微信之后，会短暂觉得问题解决了。
至少告警能进群了。
但很快，新的问题会出现：群里一天几百条告警，机器人刷屏，严重故障被 Warning 淹没，有人看到了但没人认领，处理过程散落在多个群聊里，事后也没人能还原当时发生了什么。
最后，告警确实进了 IM，但响应并没有变好。
原因很简单：IM 群不是告警响应平台。它只是团队协作入口。
真正要解决的问题不是“如何把告警发到群里”，而是“如何在 IM 里完成可追踪的故障响应”。
群机器人只能解决第一公里
很多团队最早接入 IM 告警，都是从群机器人开始：
Prometheus Alertmanager 发到飞书机器人
Zabbix 触发脚本发到企业微信群
云监控配置钉钉 Webhook
自研系统把告警 JSON 转成 Markdown 推到群里
这个方式简单、直接、成本低，适合做第一步：让告警从监控系统出来，被团队看见。
但机器人通常只负责推送消息。它不知道告警有没有人处理，不知道当前值班人是谁，也不知道五分钟没人响应时该升级给谁。
告警是否被认领，要靠人在群里回复。谁在处理，要靠人工 @。同一个故障触发了多少条告警，要靠人往上翻。事后复盘时，只能在群消息里搜索关键词。
这不是闭环，只是把通知搬到了 IM。
告警进群以后，最怕没有状态
IM 告警最大的问题，不是消息多，而是消息没有状态。
一条告警发出来之后，团队真正关心的是：
有没有人看到？
有没有人认领？
是谁在处理？
是否需要升级？
影响范围有没有扩大？
故障是否已经恢复？
后续有没有复盘和改进项？
如果这些信息都靠群聊里的自然语言维护，系统很容易失控。
在 Flashduty 里，告警进入后会形成故障。故障有处理进度、严重级别、分派对象、认领记录、时间线和关闭状态。
IM 消息只是故障对象的入口，不是唯一载体。
团队在 IM 里看到的是告警，但真正处理的是故障。
应用集成比机器人更适合长期使用
如果只是临时项目群，或者暂时没有 IM 管理员权限，机器人可以先用。
但如果团队要长期建设 On-call 机制，更建议优先使用应用集成。
原因很直接：应用集成可以把“通知”升级成“操作”。
通过飞书、钉钉、企业微信等 IM 应用消息，成员可以在熟悉的 IM 环境里接收故障通知，并基于卡片完成认领、关闭、升级等操作。
机器人消息更像一张截图。
应用卡片更像一个可操作的故障入口。
值班人不需要先打开控制台、登录系统、搜索故障，再点认领。他可以直接在 IM 卡片里完成第一响应。
这会明显缩短 MTTA。
告警不要直接发给所有人
很多群告警混乱，是因为所有告警都发给所有人。
CPU Warning 发全群，测试环境失败发全群，生产核心链路异常也发全群，恢复、认领、关闭、评论继续刷屏。
这种做法看起来透明，实际上会制造集体麻木。
更合理的方式，是按严重程度、服务、环境、团队和时间段设计通知策略：
Critical：优先通知当前值班人，并配置升级链路
Warning：可以进入团队群，或只在工作时间通知
Info：更多用于记录和排查，不一定主动打扰人
测试环境：不要和生产环境告警混在一起
不同业务线：进入不同协作空间或不同群组
IM 群不应该变成告警垃圾桶。
它只应该接收这个群真正需要知道、需要处理、需要协同的信息。
@ 人不是响应机制，分派才是
很多团队把 @ 当成响应机制。
告警来了机器人 @ 所有人。没人回，再 @ 值班人。还没人回，Leader 再 @ 一次。实在不行，打电话。
这套流程太依赖人工。
真正的 On-call 机制应该靠分派策略，而不是临时 @。
一条分派策略应该回答：
什么时间生效？
匹配哪些服务、环境、级别和标签？
先通知谁？
通过哪些渠道触达？
多久无人认领就升级？
升级给备值班、服务 Owner 还是负责人？
IM 里的 @ 只是触达手段。
分派策略才是响应机制。
高优先级告警不能只依赖 IM
IM 适合协作，但不适合承担所有触达责任。
飞书、钉钉、企业微信消息可能被静音，手机可能没有打开通知，群消息可能被刷掉，夜间值班人也未必盯着 IM。
所以高优先级告警不能只发群消息。
更合理的方式是按严重程度配置多渠道触达：
普通 Warning：IM 群
重要告警：IM 私聊 + App 推送
关键故障：短信或语音电话兜底
无人认领：逐级升级到备值班、负责人或主管
On-call 的目标不是“大家都能看到”。
目标是“正确的人一定会响应”。
通知群和作战室要分开
另一个常见误区，是把所有沟通都放在告警通知群里。
告警在这个群里，排查也在这个群里，临时拉人也在这个群里，业务方询问也在这个群里，复盘材料也从这个群里找。
最后，通知群变成大杂烩。
对重大故障来说，最好把“通知”和“协同”分开：
通知群：让相关人知道发生了故障
作战室：让处理人、相关方和负责人围绕同一个故障协同
重大故障需要一个临时但结构化的协同空间。
否则群聊越热闹，信息越容易散。
IM 告警治理要先设计标签
很多人以为 IM 告警混乱，是通知渠道没选好。
其实很多时候，是告警标签没设计好。
没有 service，系统不知道属于哪个服务。没有 env，系统不知道生产还是测试。没有 severity，系统不知道是否需要打电话。没有 team，系统不知道应该通知哪个团队。
最少应该有这些标签：
service：服务或应用
env：生产、预发、测试
severity：严重级别
team：负责团队
resource：资源对象
check：检查项
owner：责任人或服务 Owner
没有标签的 IM 告警，只是文本消息。
有标签的 IM 告警，才能进入自动化响应流程。
一个更合理的 IM 告警架构
如果从零设计，可以分成四层：
告警接入：Prometheus、Zabbix、Nightingale、Grafana、云监控、自研系统统一接入 Flashduty
降噪路由：相似告警聚合成故障，低价值告警通过静默、抑制、延迟窗口减少打扰
分派触达：按值班表、分派策略和严重级别选择 IM、App、电话、短信、邮件
协同闭环：IM 卡片认领、暂缓、关闭，重大故障创建作战室，时间线用于复盘
这套架构的好处是，IM 仍然是团队熟悉的工作入口，但不承担全部系统责任。
真正的状态、规则、升级和数据，都在告警响应平台里。
什么时候应该从机器人升级
不是所有团队都需要一开始就上完整平台。
如果每天只有几条告警，团队很小，靠一个群也能跑通，机器人足够。
但如果出现这些情况，就应该升级：
每天群里有几十条甚至上百条告警
关键故障经常混在普通告警里
没人知道某条告警到底有没有被处理
夜间告警靠人工转发和值班人自觉
主备值班和升级策略没有自动执行
不同监控系统各发各的通知
复盘时很难还原时间线
管理者看不到 MTTA、MTTR 和告警噪音来源
这些问题继续靠“优化机器人文案”解决不了。
你需要的不是更漂亮的群消息，而是完整的告警响应流程。
结语
飞书、钉钉、企业微信是很好的协作工具，但它们不是天然的 On-call 平台。
如果只是把告警推到群里，团队很快会遇到同样的问题：消息太多、责任不清、无人认领、升级靠催、复盘困难。
更好的方式，是让 Flashduty 承接告警响应流程，让 IM 成为处理入口。
告警统一接入，故障自动聚合，按级别和标签分派，在 IM 卡片里认领和关闭，无人响应自动升级，重大故障拉起作战室，最后用时间线和指标复盘。
这样，IM 才不会被告警淹没。
它会变成团队真正可用的故障响应工作台。
