指标在80附近来回走告警一会儿触发、一会儿恢复。给模型增加更多历史特征未必是第一步一条明确的状态机可能已经能消除最直接的开关抖动。触发与恢复不必使用同一条线滞回使用较高阈值触发、较低阈值恢复中间区域保留已知状态。它与持续时间条件不同前者处理幅度区间后者处理时间稳定性两者可以组合但都需要历史回放评估。图是概念曲线不是业务测量。阈值也不是行业通用值业务容忍度、采样间隔与指标量纲必须先确定。不要让缺失数据自动恢复告警from math import isfinite def replay(values, high80, low70): 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比在阈值附近不断发出“已恢复”更能帮助值班判断。