告警超过十条，团队就开始批量点关闭

我们的看板告警从三条加到十九条，用了大概一年。加的时候每条都有理由：这个指标很重要，异常了要马上知道。

加到第十条之后出现一个新现象：早上有人花十分钟把十九条告警全部点掉，一条都没处理。我问他为什么点，他说先清掉，重要的会再响。它们不会再响。

告警的价值取决于稀缺性

一条告警有没有用，不看它监控的指标重要不重要，看它响的时候人会不会立刻放下手上的事。十九条告警意味着平均两天响一次，这个频率下任何一条都不值得立刻放下手上的事。

我们做过一次统计：十九条告警里，真正导致过动作的只有四条，其余十五条在半年内没有产生过任何动作，只是反复被点掉。这十五条不是没用，是它们响的方式不对——合理待遇是进周报，不该占告警位。

砍完之后主屏留四条，周报收十五条。第一个月有人抱怨看不到原来的指标，第二个月没人再提。

合并规则三条

三条合并规则：同源合并、父子合并、冷却期合并

第一条，同源合并。同一个根因引起的多条告警合并成一条，报根因不报症状。断货会同时触发库存天数、可售周数、销量下滑三条，合并成一条「断货风险」，附三个数。

第二条，父子合并。父指标异常时，子指标的告警全部静默。品类整体转化掉了，下面十几个 ASIN 的转化告警全部不该响，响了就是噪声。

第三条，冷却期合并。同一条告警在冷却期内重复触发，只记次数不重复推送。冷却期按处理周期定——需要处理三天的告警，冷却期就设三天，中途再响没有意义，因为人已经在处理了。

阈值不是拍出来的

阈值最常见的定法是「跌 10% 就报」。这个数的问题是它不区分基数——日均两单的品跌 10% 是正常波动，日均两百单的品跌 10% 是真出事了。

我们现在统一用偏离近 90 天中位数多少个标准差来定，波动大的品类阈值自动放宽。同一个阈值套所有品，是告警数量失控的第一来源。

关掉告警也要留证

删一条告警要写两行：半年内它触发过几次、产生过几次动作。两行都填不出来，说明它从来没用过，直接删。

这条规则让删告警变成一件需要数据支撑的事，而不是凭感觉。我们砍掉的那十五条，全部是「触发过很多次、零动作」。

一个能自己降噪的机制

现在每季度跑一次告警健康度：触发次数、产生动作的比例、平均响应时间。产生动作比例低于两成的告警，自动进入待删清单，下个季度如果还是这样，直接下线。

加告警需要我批，删告警靠这个机制自动跑。方向反过来的话，告警数量只会单向增长。