告警在阈值附近反复开关？用滞回先处理抖动，再考虑在线学习

指标在80附近来回走，告警一会儿触发、一会儿恢复。给模型增加更多历史特征未必是第一步；一条明确的状态机，可能已经能消除最直接的开关抖动。

触发与恢复不必使用同一条线

滞回使用较高阈值触发、较低阈值恢复，中间区域保留已知状态。它与持续时间条件不同：前者处理幅度区间，后者处理时间稳定性，两者可以组合，但都需要历史回放评估。

图是概念曲线，不是业务测量。阈值也不是行业通用值；业务容忍度、采样间隔与指标量纲必须先确定。

不要让缺失数据自动恢复告警

from math import isfinite def replay(values, high=80, low=70): if low >= high: raise ValueError('low must be below high') known_state = 'OK' states = [] for value in values: if value is None or not isfinite(value): states.append('UNKNOWN') continue if value >= high: known_state = 'FIRING' elif value <= low: known_state = 'OK' states.append(known_state) return states values = [79, 81, 79, 78, None, 75, 69] assert replay(values) == ['OK', 'FIRING', 'FIRING', 'FIRING', 'UNKNOWN', 'FIRING', 'OK'] assert replay([80, float('nan'), 79]) == ['FIRING', 'UNKNOWN', 'FIRING'] print(replay(values))

未知状态独立输出，同时保留最后一个已知状态；恢复有效数据后，不因为中间断采就丢掉原来的告警上下文。真实系统还需要定义首次启动、长时间断采、乱序与状态持久化行为。

在线阈值为什么要慢一步

如果模型把事故期间的数据立即学成“新常态”，阈值可能跟着故障一起升高。更新基线时，应先过滤已确认事故和维护窗口，设定变化上限，并让旧规则与新规则并行回放。标签延迟也要记录，不能只用事后完整标签模拟实时效果。

Prometheus 规则单测文档提供了用输入序列检查不同评估时刻告警状态的方法。即便算法更复杂，也应保留这类可复现的状态样本，包括不触发、触发、恢复与数据缺失。

本文仅测试上述离线状态机，没有运行在线学习器或 Prometheus。评价应关注漏报、误报、恢复延迟与通知次数，而不是仅证明告警少了。能解释为什么仍在 FIRING，比在阈值附近不断发出“已恢复”更能帮助值班判断。