凌晨 2 点 13 分，手机响了第一声。
“订单同步延迟 18 分钟。”
值班同事刚坐起来，第二条又到了：明细分区缺失。接着是汇总任务失败、指标服务超时、经营看板刷新失败。十分钟里，群里攒了 20 条红色消息，像 20 个人同时拍门。
他一边开电脑，一边在心里给今晚判了刑：大事故。
后来查到 2 点 13 分那条同步延迟，后面 19 条都是它一路传下去的回声。
告警数量，不等于事故数量
一条上游任务失败，下游可能有很多种反应。
明细表没产出，汇总表便缺分区；汇总表缺分区，指标服务读不到新数据；服务没有新数据，看板刷新又会报错。如果每一层都把自己看到的现象单独推给值班人，系统确实很尽职，只是尽职得有点吵。
人在凌晨看到 20 条告警，会本能地逐条处理。先看同步，再看分区，再登录看板。十几个页面开完，真正的第一现场反而被埋到了聊天记录上方。
这就是告警风暴：同一根因在依赖链上产生许多副本，消息数量快速增长，新增信息却很少。
先找第一条异常，不要先处理最响的一条
告警风暴里，最晚到的消息往往最接近业务，也最容易让人紧张。“经营看板不可用”当然比“同步任务延迟”更刺眼。
可是最刺眼的不一定最接近根因。
我会先按三个线索把消息排一遍。
第一是时间。哪条告警最早偏离正常状态？如果 19 条消息都在第一条之后的几分钟内出现，它们很可能属于同一组。
第二是依赖。后面的任务、表、指标和看板，是否都经过同一个失败节点？没有完整血缘图也没关系，先沿调度依赖和最近一次成功时间往上找。
第三是影响对象。二十条消息是在描述同一批订单、同一个分区、同一段时间窗口，还是出现了第二个无关问题？只看时间会误合并，影响对象能帮你把真正的新事故留下来。
把这三件事放在一起，值班人要找的就不再是“哪条最严重”，而是“哪些消息可以被同一个修复动作消除”。
降噪不是关掉告警
一说告警太多，有人会提议把下游告警全关了。
这也危险。上游任务恢复以后，看板可能仍然因为缓存、权限或自己的逻辑没有恢复。那条看板告警就从副本变成了新的信号。
所以降噪不等于少装几个烟雾报警器。它更像让整栋楼在同一处起烟时，先由值班台告诉你起点和影响范围，而不是让每个房间轮流打电话。
一组聚合后的告警，至少应该保留这些信息：
- 最早异常的时间和节点；
- 已知受影响的任务、表、指标或看板；
- 当前仍在增长的新增异常；
- 负责响应的人与最近一次更新；
- 被合并进去的原始告警记录。
原始记录不能丢。聚合是为了帮助判断，不是为了把证据扫到地毯下面。
值班时先做这 3 个动作
告警系统的规则可以以后慢慢改。今晚被叫醒时，先做三件能立刻减少混乱的事。
第一，把时间相近、依赖相连、对象相同的消息建成一个根因组。
在群里或事故单里明确写：“暂按同一事件处理，当前根因候选为订单同步延迟。”这句话不是最终结论，但它能让团队停止同时追逐 20 个现象。
第二，只静音已确认的副本，保留新信号。
同一任务的重复失败、同一分区的连续提醒可以暂时合并；新的业务域、新的时间窗口，以及上游恢复后仍未恢复的下游，继续单独提醒。
第三，每次更新都写清‘修哪里，预计消掉哪些告警’。
例如：“正在恢复 01:55 订单同步分区；成功后，明细、汇总、指标服务 12 条告警应一起恢复。看板刷新单独验证。”
这句话有个好处：它把根因判断变成了可验证的假设。十二条一起恢复，说明分组大致正确；有三条还在响，就把它们拆出来继续查。
白天再补一条聚合规则
事故过去以后，不必立刻上一个昂贵的新平台。先从昨晚最重复的那一组开始。
可以给告警增加一个稳定的事件键，例如“数据域 + 上游任务 + 业务日期 + 异常类型”。短时间内事件键相同的消息进入同一组；下游告警保留为影响项，不再每条都把人叫醒。
然后再加两个边界：根因候选恢复后，下游必须逐项验证；出现新的影响对象或异常类型时，自动拆成新组。
这套规则不完美。依赖关系会变，根因判断也可能猜错。但它至少让系统承认一件常识：消息之间有关系，值班人的注意力也有上限。
真正珍贵的不是安静，而是新信息
凌晨的值班群当然越安静越好。
不过我们真正想要的，不是把声音都关掉，而是让每一声都值得抬头。第一条告诉你哪里开始坏，后续更新告诉你影响是否扩大，恢复消息告诉你假设有没有被验证。
剩下那 19 次回声，可以被记录，可以被聚合，不必每次都重新吓人一跳。
机器不怕重复。
人会累，也会因此错过第 21 条真正不同的消息。
我叫石头，在数据行业里摸爬滚打了十几年，也被半夜里一长串看似不同的红字叫醒过。这里写的，就是这些教训——我觉得值得说出来的那部分。
