> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 让生产告警能够指导响应

> 围绕客户影响设计告警，减少短暂波动噪声，并验证从检测到恢复的完整响应链路。

服务频繁触发紧急通知却很少产生有效处置时，同时检查检测策略与响应策略。从客户可见的故障开始，为每条需要立即响应的规则明确处置动作。

## 根据影响决定是否通知值班人员

优先关注业务请求失败、持续延迟升高或关键路径[拨测](https://docs.molesignal.com/zh-Hans/synthetics.md)失败。[SLO 燃烧率告警](https://docs.molesignal.com/zh-Hans/apm#燃烧率告警)按错误预算通知，而不是每次尖峰都通知。诊断性症状放入仪表盘和调查视图；只有及时处置能避免客户影响时，才直接触发紧急通知。

低流量服务的错误率查询应同时限制最小请求量。一次请求中出现一次失败虽然错误率很高，但不足以证明大范围故障。根据有代表性的正常时段与故障时段选择阈值，避免直接复制其他服务的数值；规则工作台中的 **测试规则** 会在最近 6 小时的数据上画出查询结果和阈值线。

## 根据问题选择规则

| 场景 | 推荐规则 | 注意事项 |
| - | - | - |
| 持续错误率升高或延迟增加 | [阈值规则](https://docs.molesignal.com/zh-Hans/alerting/rules.md#创建阈值规则)，**并持续** 几分钟 | 延长确认过程能减少短暂波动噪声，也会推迟检测。 |
| 同一故障出现在很多主机或服务上 | 设置了[**按维度拆分**](https://docs.molesignal.com/zh-Hans/alerting/rules.md#按维度拆分)的阈值规则 | 每一组各开一个事件，因此只按稳定的列拆分。 |
| 有历史数据且基线持续变化 | [异常规则](https://docs.molesignal.com/zh-Hans/alerting/rules.md#异常规则)，流量按周变化时打开 **周季节性** | 发布、周期性波动与流量变化都可能改变基线。 |
| 需要立即处理的匹配事件突增 | 通过 API 创建的[实时规则](https://docs.molesignal.com/zh-Hans/alerting/rules.md#实时规则) | 每个接入节点独立计数，重启后从零开始。 |

**并持续** 的分钟数会换算成评估次数，因此要与评估间隔和查询窗口一起设计。重叠窗口会复用观测数据，连续命中不等于独立样本。实时规则的 `for_periods` 只允许 `0` 或 `1`，不能直接套用多周期去抖方案。

把[恢复阈值](https://docs.molesignal.com/zh-Hans/alerting/rules.md#恢复条件与没有数据)设在触发阈值的健康一侧，避免数值在阈值附近来回时反复触发、反复恢复。想清楚没有数据意味着什么：**按 0 计算** 适合计数，**开无数据事件** 适合绝不能断流的数据源。

## 明确归属与升级路径

每条会通知值班的规则都要填写 **服务** 和 **处理指南 / Runbook URL**。通知谁由[升级策略](https://docs.molesignal.com/zh-Hans/alerting/on-call.md#升级策略)决定，而不是由规则决定；在规则工作台中保存的规则使用名为 `default` 的策略。优先使用稳定的拆分列和标签。唯一请求标识用于调查上下文，避免按请求标识把每次发生都拆成独立的事件。

根据严重级别与人员安排设置确认超时。用每个排班的 **未来 7 天预览** 检查跨时区和交接时段的覆盖情况。在受控演练中故意不确认事件，验证下一步升级是否生效。

计划维护期间，使用范围明确、有时间限制的[静默策略](https://docs.molesignal.com/zh-Hans/alerting/silences.md#静默策略)，写明受影响的服务，并让它到期自动结束。静默会抑制通知投递，不能证明服务已经恢复。

## 演练完整响应过程

连接器 **测试连接** 成功只验证了部分链路。用[触发规则](https://docs.molesignal.com/zh-Hans/api/alerting/trigger-rule.md)接口触发一条受控规则，检查事件创建、接收人路由、实际收信、确认与恢复。检查事件确认后是否停止升级，以及故障条件恢复后是否进入预期的已解决状态。

演练中加入主投递路径失败的情况。向预期接收人验证已配置的[兜底路由](https://docs.molesignal.com/zh-Hans/notification-channels#配置兜底路由)，并在[投递记录](https://docs.molesignal.com/zh-Hans/notification-channels#查看和重试投递)中查看每次尝试，避免把存在兜底配置等同于投递成功。

## 在事件结束后复盘

比较检测延迟、确认延迟、重复通知和遗漏的客户影响。[告警 → 洞察](https://docs.molesignal.com/zh-Hans/alerting/incidents.md#洞察)列出 **主要触发规则** 和 **快速恢复事件** 的占比（规则噪声较大的信号）；[自动化](https://docs.molesignal.com/zh-Hans/automations.md)的 **告警降噪周报** 模板会让 Mole Agent 为每条噪声规则给出调整建议。

删除没有有效响应动作的规则，调整噪声阈值，并保留每次调整的依据。使用正常流量与已知故障场景共同验证新策略。

## 验收标准

* 每条会通知值班的规则都从客户影响出发：请求失败、延迟、拨测失败或 SLO 燃烧。
* 每条会通知值班的规则都写明了服务和 Runbook，它的升级策略能通知到人。
* 规则在触发阈值的健康一侧恢复，没有数据时的处理方式是有意选择的。
* 受控演练能通知到值班人，没人确认时会升级，并最终解决。
* 每周复查主要触发规则。

## 相关指南

* [告警规则](https://docs.molesignal.com/zh-Hans/alerting/rules.md)
* [值班与升级](https://docs.molesignal.com/zh-Hans/alerting/on-call.md)
* [搭建值班与通知](https://docs.molesignal.com/zh-Hans/best-practices/on-call-setup.md)
* [处理一次线上事件：从告警到复盘](https://docs.molesignal.com/zh-Hans/best-practices/incident-response.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.