🚨 告警阈值设计：幅度、持续时间与业务影响
阈值并非单纯的“超过某数就通知”。同样的错误率，在核心交易接口和低流量后台任务上的影响不同；同样的资源尖峰，持续十秒与持续半小时代表的风险也不同。可靠规则要把信号幅度、持续时间、受影响对象和处置动作写在一起。告警的质量由可行动性决定：收到通知的人应能判断用户影响，并知道下一步做什么。🧭
一、先定义业务信号和统计口径
优先从成功率、关键路径尾延迟、订单完成率等用户可感知指标出发，再选择资源指标作为前兆。定义清楚分子和分母，例如错误率只统计实际服务端失败，还是也包括依赖超时；用户取消、预期业务拒绝是否排除。低流量服务上，百分比会剧烈摆动，应设置最低样本量，必要时结合失败绝对数、多探测点或固定频率合成探测。
如果服务目标按一个滚动周期衡量，就可观察错误预算的消耗速度。短窗口内快速消耗预算适合快速通知，长窗口内缓慢偏离可先交由工单处理。不要把资源利用率直接当成业务影响：CPU高但延迟和队列稳定，可能只是有效工作增加；CPU不高也可能因单线程锁或外部依赖等待而不可用。📊
二、持续时间要符合异常的变化速度
持续条件用于过滤短暂波动，但它会增加检测延迟。为短促尖峰设计的规则，可以要求信号连续满足条件一段时间；为队列增长设计的规则，则应同时观察增长斜率、当前积压和处理速率。若生产速率持续高于消费速率，即使队列尚未到硬上限，也可能很快耗尽空间。依赖失败可能具有突发性，可用多个独立探测或连续失败样本降低偶然网络丢包带来的噪声。
还要区分数据窗口和持续条件：统计窗口决定指标如何计算，持续条件决定计算结果要维持多久才告警。比如滚动五分钟错误率已超线，并要求连续三分钟成立，这两层叠加后的实际观察时间比任一参数都长。设计时应写出最坏检测延迟，并确保它仍早于业务可接受的故障窗口。⏱️
建议按响应等级分层
- 提示级：轻微偏离或容量趋势异常，创建工单，要求在工作时段分析。
- 值班级：错误预算快速消耗、关键路径尾延迟持续超目标，立即通知并附诊断信息。
- 紧急级：核心流程不可用或影响面快速扩大，明确升级链和用户沟通责任。
等级名称不是固定标准，关键是每级的响应时限、接收人和升级条件可验证。🔔
三、历史回放与故障演练
- 选取涵盖高峰、低谷、发布和已知故障的指标历史，回放候选规则。
- 把触发结果与真实用户影响对照，记录误报、漏报、提前量及通知次数。
- 针对缺失数据、实例重启、维护期和突发低流量分别验证规则状态转换。
- 在测试环境模拟短抖动和持续异常，确认不同等级按预期触发与恢复。
规则应显式处理无数据。采集链路故障若让查询结果变空，直接视为健康会漏报；将空数据视为故障又可能让采集器重启时全量告警。可单独监控采集完整性，并为业务指标定义合理的缺数行为。🔬
⚠️ 提醒：告警必须对应具体动作和责任人。无运行手册、无分派对象、无法确认恢复条件的规则，通常只会制造通知噪声。
四、验收条件与常见误区
每条规则都记录指标定义、查询窗口、持续时间、分组标签、低样本策略、缺数行为、通知等级与恢复条件。告警内容应带当前值、基线或目标、受影响服务和排查入口。常见误区包括全站统一阈值、只用绝对值忽略趋势、把恢复条件设得过于敏感，以及用更长持续时间掩盖错误指标。验收时让值班人员只看通知文本回答“影响什么、何时开始、先查哪里、何时算恢复”；答不出来就继续补足上下文。随后观察正常周期并复核误报率和漏报案例，所有阈值调整都要有历史证据。✅
