> ## 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.

# 搭建值班与通知

> 确保每次通知都能送到能处理问题的人：经过验证的通知方式、没有空班的排班、默认升级策略、兜底路由，以及一次演练。

凌晨 3 点触发的规则，效果取决于通往能处理它的人的那条路径。大多数漏掉的通知问题出在路径上，而不是规则上：未验证的手机号、周日有空班的排班、没人创建的升级策略。先把路径一次搭好，再用演练证明它可用。

## 决定谁响应什么

配置任何东西之前，先为每个服务写下：负责它的团队、谁第一个值班、谁接着值班，以及哪些严重度值得在夜里打电话。

| 严重度 | 典型响应 | 典型渠道 |
| - | - | - |
| **严重** | 立即叫醒值班人。 | 先发 IM，再发短信，最后打电话。 |
| **错误** | 工作时间内或尽快处理。 | 先发 IM，再发短信。 |
| **警告** | 白天查看。 | 只发 IM 或邮件。 |
| **信息** | 不发通知。 | 仪表盘或报告。 |

把每个负责团队的人员归入[团队](https://docs.molesignal.com/zh-Hans/identity/teams.md#团队)：排班、升级目标和兜底路由都引用团队。

## 为每个人准备经过验证的联系方式

1. 管理员在[设置 → 通知 → 连接器](https://docs.molesignal.com/zh-Hans/notification-channels#创建并测试连接器)中配置连接器：IM App、邮件，以及用于严重告警的电话和短信。逐个 **发送测试**。
2. 每位成员在[账号设置 → 通知设置](https://docs.molesignal.com/zh-Hans/account.md#通知设置)中绑定个人通知方式，并逐个发送测试。
3. 拥有 `org.members.manage` 的管理员确认通知方式属于本人后，逐个点击 **验证**。未验证的通知方式永远不会投递。
4. 每位成员为 **告警事件** 排列通知方式的顺序，并用等待时间逐级升级渠道：例如立即发 IM，3 分钟后发短信，5 分钟后打电话。一旦有人确认，后续步骤就会停止。

免打扰时段会停止向本人发送通知，这些通知之后也不会补发。所有接收严重告警的值班人员都应开启 **严重告警可绕过免打扰**。

## 搭建没有空班的排班

为每个团队按团队所在时区创建一个[值班排班](https://docs.molesignal.com/zh-Hans/alerting/on-call.md#创建排班)：

* 使用 **每周** 轮换，交接时间放在双方都清醒的工作时间；
* 需要跟随日照或只覆盖工作时间时，第一个轮值限定在工作时段，第二个轮值放在它下方覆盖其余时间；
* 按轮换顺序加入所有成员，每个排班至少两个人。

保存前检查 **未来 7 天预览**，并在排班列表和[首页](https://docs.molesignal.com/zh-Hans/home.md)上留意 **存在空班**。提前把请假和换班记录为[临时替班](https://docs.molesignal.com/zh-Hans/alerting/on-call.md#临时替班)，并 **导出日历**，让大家在自己的日历中看到班次。

## 先创建默认升级策略

在规则工作台中保存的规则使用名为 `default` 的策略；没有它，这些规则的事件不会通知任何人。参见[默认策略](https://docs.molesignal.com/zh-Hans/alerting/on-call.md#默认策略)。

| 级别 | 目标 | 确认超时 | 生效起始严重度 |
| - | - | - | - |
| 1 | 团队的主值班排班。 | 5 分钟 | 任意严重度 |
| 2 | 备用值班排班，或团队负责人。 | 10 分钟 | **错误** |
| 3 | 整个团队。 | 15 分钟 | **严重** |

对关键服务开启 **循环整个策略直到被确认**，并设置较小的 **最大循环次数**。需求不同的团队另建策略，并通过 API 用 `escalation_policy_id` 把规则指向这些策略。

## 加上安全网

* [兜底路由](https://docs.molesignal.com/zh-Hans/notification-channels#配置兜底路由)在接收人的个人通知方式都不可用时，投递到团队频道或组织地址。
* [通知策略](https://docs.molesignal.com/zh-Hans/notification-channels#创建模板和策略)决定每个事件的模板和连接器；实时预览会显示谁会收到事件，而不会真的发送。
* [投递记录](https://docs.molesignal.com/zh-Hans/notification-channels#查看和重试投递)显示每一次投递尝试，让失效的连接器在事件真正需要它之前就被发现。

## 演练

在工作时间进行一次演练，并在每次较大的改动后重复：

1. 用[触发规则](https://docs.molesignal.com/zh-Hans/api/alerting/trigger-rule.md)接口有意触发一条测试规则。
2. 确认值班人在每个渠道上按预期顺序收到通知。
3. 不确认并等待，确认升级推进到第 2 级。
4. 确认事件，检查后续级别和渠道都已停止。
5. 解决事件，并在 **投递记录** 中检查失败的投递。

## 验收标准

* 排班中的每个人至少有两种已验证的通知方式，其中一种是用于严重告警的电话。
* 未来 7 天内没有排班存在空班。
* 存在名为 `default` 的策略，并且每一级都指向人员或排班。
* 每个接收告警的团队都配置了兜底路由。
* 最近一次演练送达了值班人，按预期升级，并在确认后停止。

## 相关指南

* [值班与升级](https://docs.molesignal.com/zh-Hans/alerting/on-call.md)
* [通知渠道与投递](https://docs.molesignal.com/zh-Hans/notification-channels)
* [账号设置](https://docs.molesignal.com/zh-Hans/account.md)
* [让生产告警能够指导响应](https://docs.molesignal.com/zh-Hans/best-practices/actionable-alerts.md)


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