很多团队治理告警疲劳，第一反应是换通知方式。飞书群太吵，就改成私聊；私聊没人看，就加短信；短信还不够，就加电话；电话太扰民，再去调值班表和升级策略。工具一轮一轮换，值班人还是累，群里还是乱，真正事故还是会被淹没在重复通知里。
这不是飞书、钉钉、企业微信、短信或电话的问题。通知只是最后一公里。前面如果没有把监控系统推过来的原始信号整理成可判断、可分派、可认领、可升级的故障对象，后面换什么通知渠道都只是把噪声换一种形式送到人面前。
告警疲劳的根因，通常不是“通知太多”这么简单，而是事件、告警、故障没有分层。重复触发、恢复事件、派生告警、真实故障、维护窗口、抖动信号混在一起，最后全部以“消息”的形式打给值班人。人被迫在半夜完成一件系统本该提前做好的事：判断这些信号到底是不是同一个问题。
先把对象说清楚：Event、Alert、Incident
Flashduty 文档里有一个很关键的模型：
Monitoring System -> Event -> Alert -> Incident
这个模型看起来简单，但它正是告警治理的起点。
Event 是监控系统推送过来的原始通知。一次触发、一次恢复、一次更新，都可以是 Event。比如 Prometheus、Zabbix、Nightingale 或云监控发现 CPU 过高，推送一次触发事件；指标恢复后，再推送一次恢复事件。Event 是最底层的信号，它保留现场，但不应该直接等同于人要处理的工作项。
Alert 是由 Event 自动触发出来的告警对象。同一个 alert_key 的事件，在事件聚合窗口内可以合入同一条 Alert。也就是说，触发、更新、恢复这些原始事件，不一定要各自变成一个独立处理项。它们可以共同描述同一条告警的生命周期。
Incident 才是响应系统里真正要处理的对象。Flashduty 文档里对 Incident 的定义很直接：它表示一个正在发生、需要处理的问题，通常由告警触发，也经常关联一组相似告警。没有降噪时，一个 Alert 往往就会触发一个 Incident；有了降噪后，多条相似 Alert 可以合入同一个 Incident，用于统一分派、通知和处理。
这三层如果不分清，告警治理一定会走偏。很多团队以为自己在处理故障，实际上是在处理 Event；以为自己在做响应流程，实际上只是在转发 Alert；以为自己在降噪，实际上只是把通知关小一点。
通知太多，只是对象建模失败的结果
假设一台核心服务器宕机。监控系统可能同时推送 CPU、内存、磁盘、网络、进程存活、端口探活、服务可用性、业务接口错误率等多类事件。如果每一个事件都直接变成一条独立告警，每一条告警又直接触发一个独立故障，值班人看到的就是几十甚至上百个“问题”。
但从响应角度看，这不一定是几十个问题。它可能只是一个服务器不可用，带出了一串派生信号。
Kubernetes 场景更典型。一个 Node 抖动，可能引发 Pod 重启、Deployment 副本异常、Service 延迟、Ingress 5xx、下游依赖超时、业务接口成功率下降。每条信号都是真的，但它们不一定都值得独立叫醒一个人。值班人真正需要处理的是“某个集群节点异常导致一组服务受影响”，而不是逐条确认每个派生告警。
这就是故障对象建模的价值。系统要先把原始事件聚合成 Alert，再把相似 Alert 聚合成 Incident。人处理的是 Incident，而不是每一次事件波动。
这个差别很重要。Event 保留细节，Alert 描述某个检查项或对象的告警状态，Incident 承载响应流程。Incident 上应该能看到关联了哪些 Alert，每条 Alert 又关联了哪些原始 Event。这样既不会丢证据，也不会把所有证据都变成人的待办事项。
Event Aggregation 解决的是“重复事件”
第一层治理是 Event Aggregation，也就是从 Event 到 Alert 的聚合。
它解决的是同一条告警在一段时间内反复更新的问题。Flashduty 的文档里说，新 channel 默认开启 Event Aggregation，默认窗口是 24 小时，配置范围是 1 到 1440 分钟。开启后，具有相同 alert_key 的事件会在窗口内合入同一条 Alert；关闭后，每个 Event 都会创建独立 Alert。
这里的关键是 alert_key。它是告警关联和去重的标识，可能由上游集成上报，也可能由集成规则自动生成。如果 alert_key 设计得太细，同一个问题会被拆成很多 Alert；如果设计得太粗，不同问题可能被错误合并。
举个例子，同一台主机的同一检查项反复触发和恢复，通常应该进入同一条 Alert。这样值班人能看到它的状态变化，而不是被每次变化重新通知。但如果把整个集群的 CPU 告警都用同一个 alert_key，就可能把不同主机、不同原因的 CPU 异常揉成一条 Alert，后续分析反而更困难。
Event Aggregation 的目标不是让数据消失，而是把同一告警生命周期内的事件放在一起。它降低的是重复事件带来的扰动。
Alert Grouping 解决的是“相似告警”
第二层治理是 Alert Grouping，也就是从 Alert 到 Incident 的聚合。
它解决的是一个故障引发多条相似或相关 Alert 的问题。Flashduty 支持智能聚合和规则聚合两种模式。智能聚合基于标题、描述、labels.service、labels.resource 等字段计算相似度，适合快速开始；规则聚合按指定属性或标签精确匹配，适合需要严格控制边界的场景。
这两种模式各有位置。刚开始治理告警风暴时，智能聚合能快速把明显相似的告警收敛到同一个 Incident，减少重复通知。等团队逐渐看清告警结构后，可以对高风险业务使用规则聚合，例如按 service + check + env，或者按 cluster + namespace + workload，把边界控制得更清楚。
但这里有一个常见误区：聚合不是越多越好。
如果把不相关的 Alert 聚合到同一个 Incident，值班人会以为它们是同一个故障，结果排障方向被带偏。比如支付服务错误率升高和推荐服务缓存命中率下降，时间上可能接近，严重级别也可能相似，但如果业务链路没有关系，把它们合成一个 Incident 只会制造新的混乱。
告警压缩率应该是结果指标，不是唯一目标。压缩率上升说明通知量下降了，但不能证明故障模型正确。真正要看的，是压缩后的 Incident 是否更接近人处理问题的方式：影响面清楚、责任团队清楚、关联告警合理、后续合入不重复打扰、故障关闭后能复盘。
标签质量决定聚合质量
很多团队一上来就调聚合规则，结果规则越来越复杂，效果仍然不稳定。根因通常不是聚合功能不够强，而是标签质量太差。
Flashduty 文档里讲得很明确：Labels 会贯穿告警处理流程，用于 Incident 过滤、路由分发、分派通知、Alert Grouping、Silence 和 Inhibition。也就是说，标签不是页面上展示给人看的附属信息，而是告警治理的基础数据。
至少要有几类稳定标签：service 表示业务服务或应用，resource 表示告警对象，check 表示检查项，env 表示环境，team 表示责任团队，cluster 或 region 表示集群、机房或地域。不同企业字段名可以不一样，但语义要稳定。
标签不稳定会带来三个问题。第一，路由不准，同一个服务的告警可能被送到不同 channel。第二，聚合不准，同一个故障拆成多个 Incident，或者不同故障被错误合并。第三，复盘不准，分析看板里看不出真正的高频服务、对象和检查项。
Flashduty 的 Label Enhancement 可以在告警进入系统时自动生成或修改标签，支持从标题、描述或已有标签中用正则提取，也可以组合生成新标签、通过映射表把 ID 转换为可读值，或者删除不需要的标签。更高级的场景还可以通过 API 映射查询外部系统，补充责任团队、服务等级等信息。
这类工作很工程化，也不如“AI 降噪”听起来性感，但它决定了后续治理能不能长期稳定。
静默、抑制、抖动检测，不要混着用
Event Aggregation 和 Alert Grouping 解决的是“如何把信号变成对象”。但告警疲劳还有几类典型噪声，需要用不同机制处理。
静默适合维护窗口和已知问题。比如计划发布、数据迁移、压测、硬件更换、定期重启，这些期间出现告警并不意外，继续通知只会制造干扰。Flashduty 的 Silence Rules 可以按严重程度、标题、描述、集成来源和标签匹配，行为可以选择直接丢弃，也可以保留并标记。更稳妥的做法通常是保留并标记，因为复盘时还能知道静默规则命中了什么。
抑制适合根因和派生告警。比如 Critical 级别的网络故障已经存在时，同一检查项或同一对象上的 Warning/Info 级别告警可能只是派生结果。Flashduty 的 Inhibit Rules 会在满足条件的活跃告警存在时，抑制相关的次要告警。这里要表达清楚三个东西：新的告警条件、作为抑制源的活跃告警条件、二者必须相同的属性或标签。抑制不是简单把低等级告警关掉，而是在根因存在时减少派生噪声。
抖动检测适合反复触发和恢复。网络短暂波动、依赖偶发超时、监控采集不稳定，都可能让同一个问题在短时间内不断触发和恢复。Flashduty 的 Flapping Detection 可以在同一 Incident 频繁触发和恢复时，将其标记为 flapping，并按策略减少通知干扰。
这些能力不能互相替代。把维护窗口告警用聚合处理，仍然会创建不必要的 Incident；把派生告警用静默处理，容易把真实变化也一起盖掉；把抖动问题简单调高阈值，可能漏掉临界状态恶化。正确做法是先判断噪声类型，再选择机制。
路由和分派也依赖对象模型
告警疲劳还有一部分来自“打给了不该处理的人”。
如果所有告警都先进一个大群，再靠群里的人判断谁负责，响应流程一定会慢。因为每个人都看到了消息，但没有人确定自己应该接手。严重时，大家都以为别人会处理，真正事故反而无人认领。
Flashduty 的 Routing Rules 用于共享集成场景，可以基于标签、属性等条件把告警事件分发到对应 channel。路由模式包括标准路由和名称映射。标准路由适合固定映射，名称映射适合告警标签里已经带有业务标识，并且 channel 名称与标签值匹配的场景。路由规则还支持继续匹配或停止匹配，也支持默认路由兜底。
这意味着路由不是“通知渠道选择”，而是故障对象进入响应流程的第一道分类。一个好的路由策略，应该让支付服务的故障进入支付团队或核心业务 channel，让基础设施故障进入基础设施 channel，让低等级非生产告警进入弱通知通道。
但路由依赖标签，标签依赖上游数据和标签增强。这个链条断一环，最后都会表现为“通知乱”。
一个实用的建模顺序
如果你的团队现在已经有很多告警，不建议一开始就大规模删除监控规则。更稳的顺序是从响应层建模，再回到监控侧治理。
第一步，接住多源告警。Prometheus、Zabbix、Nightingale、云监控、Grafana、邮件、自定义 webhook 都可以继续存在，先不要急着替换。关键是把这些信号统一接入响应平台，让团队能看到 Event、Alert、Incident 的层次关系。
第二步，确认 alert_key 和标签。先找最吵的 10 类告警，看它们的 alert_key 是否合理，service、resource、check、env、team 等标签是否稳定。缺失的用 Label Enhancement 补，明显错误的从上游修。
第三步，开启 Event Aggregation。让同一告警生命周期里的触发、更新、恢复进入同一条 Alert，避免把状态变化变成人的重复待办。
第四步，设计 Alert Grouping。先对最明确的场景做规则聚合，比如同一服务同一检查项、同一集群同一 workload、同一数据库实例同一检查项。对于字段不稳定但相似度明显的场景，可以先用智能聚合降低噪声，再逐步沉淀规则。
第五步，补充静默、抑制、抖动检测和风暴预警。维护窗口用静默，派生告警用抑制，反复触发恢复用抖动检测，聚合后仍然持续合入大量 Alert 的 Incident 用 Alert Storm Warning 提醒团队升级关注。
第六步，看数据而不是听感觉。至少跟踪通知次数、Incident 数量、压缩率、认领率、MTTA、MTTR、误合并反馈和漏报反馈。没有这些指标，团队很容易把“安静了”误判成“治理好了”。
验收标准不是压缩率，而是可处理性
告警压缩率很有用，但它不是唯一验收标准。压缩率太低，说明重复通知仍然很多；压缩率太高，也可能说明不同故障被错误合并。真正的验收标准应该是可处理性。
一个好的 Incident，至少要满足几个条件。它代表一个相对明确的问题，而不是一堆随机告警；它能说明影响对象、严重级别、关联 Alert 和原始 Event；它能被路由到合适的 channel，并按升级规则触达正确的人；后续相似 Alert 合入时，不会反复通知；如果合入数量异常增长，系统会通过风暴预警提醒团队；事故结束后，团队能从 Incident 回看时间线、关联告警和处理动作。
这才是告警降噪的核心：不是让消息少一点，而是让每一次通知都更接近一个需要人判断和处理的真实问题。
结尾：先建模，再降噪
告警疲劳不是通知工具的问题。飞书、钉钉、短信、电话只是把结果送到人面前。真正决定值班人是否疲惫的，是前面有没有把监控信号整理成正确的对象。
如果 Event、Alert、Incident 混在一起，任何通知渠道都会变吵。如果这三层分清楚，再配合标签增强、路由、聚合、静默、抑制、抖动检测和风暴预警，告警治理才会从“凭感觉关规则”变成可验证的响应工程。
对已经被告警风暴困扰的团队，下一步可以很小：用 Flashduty 做一个 14 天试用，只接入一个最吵的告警源，先不改监控规则。看清楚 Event 如何进入 Alert，Alert 如何聚合成 Incident，再用真实数据验证通知次数、Incident 数量、压缩率、认领率和误合并情况。
你会很快知道，团队真正需要治理的是通知渠道，还是故障对象模型。
