根据影响决定是否通知值班人员
优先关注业务请求失败、持续延迟升高或关键路径拨测失败。SLO 燃烧率告警按错误预算通知，而不是每次尖峰都通知。诊断性症状放入仪表盘和调查视图；只有及时处置能避免客户影响时，才直接触发紧急通知。 低流量服务的错误率查询应同时限制最小请求量。一次请求中出现一次失败虽然错误率很高，但不足以证明大范围故障。根据有代表性的正常时段与故障时段选择阈值，避免直接复制其他服务的数值；规则工作台中的 测试规则 会在最近 6 小时的数据上画出查询结果和阈值线。根据问题选择规则
并持续 的分钟数会换算成评估次数，因此要与评估间隔和查询窗口一起设计。重叠窗口会复用观测数据，连续命中不等于独立样本。实时规则的
for_periods 只允许 0 或 1，不能直接套用多周期去抖方案。
把恢复阈值设在触发阈值的健康一侧，避免数值在阈值附近来回时反复触发、反复恢复。想清楚没有数据意味着什么：按 0 计算 适合计数，开无数据事件 适合绝不能断流的数据源。
明确归属与升级路径
每条会通知值班的规则都要填写 服务 和 处理指南 / Runbook URL。通知谁由升级策略决定，而不是由规则决定；在规则工作台中保存的规则使用名为default 的策略。优先使用稳定的拆分列和标签。唯一请求标识用于调查上下文，避免按请求标识把每次发生都拆成独立的事件。
根据严重级别与人员安排设置确认超时。用每个排班的 未来 7 天预览 检查跨时区和交接时段的覆盖情况。在受控演练中故意不确认事件，验证下一步升级是否生效。
计划维护期间，使用范围明确、有时间限制的静默策略，写明受影响的服务，并让它到期自动结束。静默会抑制通知投递，不能证明服务已经恢复。
演练完整响应过程
连接器 测试连接 成功只验证了部分链路。用触发规则接口触发一条受控规则，检查事件创建、接收人路由、实际收信、确认与恢复。检查事件确认后是否停止升级，以及故障条件恢复后是否进入预期的已解决状态。 演练中加入主投递路径失败的情况。向预期接收人验证已配置的兜底路由，并在投递记录中查看每次尝试，避免把存在兜底配置等同于投递成功。在事件结束后复盘
比较检测延迟、确认延迟、重复通知和遗漏的客户影响。告警 → 洞察列出 主要触发规则 和 快速恢复事件 的占比（规则噪声较大的信号）；自动化的 告警降噪周报 模板会让 Mole Agent 为每条噪声规则给出调整建议。 删除没有有效响应动作的规则，调整噪声阈值，并保留每次调整的依据。使用正常流量与已知故障场景共同验证新策略。验收标准
- 每条会通知值班的规则都从客户影响出发：请求失败、延迟、拨测失败或 SLO 燃烧。
- 每条会通知值班的规则都写明了服务和 Runbook，它的升级策略能通知到人。
- 规则在触发阈值的健康一侧恢复，没有数据时的处理方式是有意选择的。
- 受控演练能通知到值班人，没人确认时会升级，并最终解决。
- 每周复查主要触发规则。