如何配置第一张值班表和升级策略

答案先说

第一次配置 On-call，不要先接入更多告警源。更短的路径是：

1. 选一个边界清楚的协作空间。
2. 创建一张只覆盖这个空间的值班表。
3. 先配置主值班和备值班。
4. 用一条 Critical 分派策略验证通知、认领、升级和关闭。
5. 保留兜底策略，防止标签或路由错误导致告警没人接。

目标不是一次做完所有排班规则，而是让一条真实告警进入 Flashduty 后，能自动找到当前值班人；无人响应时，能按规则升级给备值班、服务 Owner 或团队负责人。

值班表和分派策略的区别

值班表回答一个问题：

此刻谁在值班？

分派策略回答另一个问题：

什么故障，在什么时间，通过什么渠道，通知给谁；超时后升级给谁？

只建值班表，故障不会自动按你预期触达。只配置固定个人通知，生产告警会长期绑定某个人，遇到请假、离职、换岗或睡着时风险很高。

最小配置清单

推荐配置步骤

第一步，选择试点空间。优先选有明确负责人、有真实告警、范围不大的空间，例如支付系统、核心交易、基础设施 SRE、数据库 DBA。

第二步，创建值班表。名称不要写成“生产值班表”这类宽泛名字，建议写成“支付 SRE 值班表”“DBA 主备值班表”“订单服务工作日值班表”。

第三步，先用简单轮换。7x24 团队可以按周轮换，工作日响应团队可以只配置工作日白班。不要把实际没人响应的夜间时段伪装成 7x24。

第四步，确认每个人真的能收到通知。至少检查手机号、邮箱、App 推送、系统通知权限、飞书/钉钉/企业微信绑定和个人通知偏好。

第五步，在协作空间里配置第一条 Critical 分派策略。

触发条件：severity = Critical
通知对象：支付 SRE 值班表的主值班
通知方式：单聊，遵循个人偏好
群聊同步：支付故障响应群
升级条件：5 分钟未关闭且未认领，升级给备值班

升级条件怎么选

升级条件不要只用一种。第一次主备升级可以用三段式：

只看“未关闭”，可能让已认领、正在处理的故障过早升级。只看“未认领”，可能漏掉已经认领但长期未恢复的故障。

通知强度要分级

不同级别告警不要用同一种触达方式。

如果 Warning 多到需要高频重复通知，根因通常不是通知不够响，而是告警质量差。先治理告警聚合、抑制、静默和规则质量。

上线验收清单

用一条从告警源发出的真实测试告警验收，不要只看控制台配置。

故障是否进入正确协作空间
故障级别是否正确
分派策略是否命中预期规则
当前主值班是否收到单聊通知
群聊是否收到同步消息
主值班是否能认领故障
认领动作是否写入时间线
未认领时是否按时升级给备值班
继续未关闭时是否升级给 Owner 或负责人
故障恢复后是否能关闭或进入正确状态

测试升级时，不要立刻认领。让故障保持未认领，观察是否按时升级；再认领但不关闭，观察“未关闭”升级是否触发。

常见问题

有值班表，为什么没人收到通知？

先看协作空间的分派策略是否引用了这张值班表，再看故障时间线里是否有策略命中、通知发送或通知失败记录。

主备都收到了，为什么还是没人认领？

通常是责任设计问题。第一环节只通知主值班，超时未关闭且未认领再升级备值班。群聊可以同步，但不能替代个人分派。

测试环境告警半夜打电话怎么办？

分派策略里必须区分 env 和 severity。测试环境 Warning 通常只进群或低强度通知，不应该走生产 Critical 升级链路。

第一张值班表要做多复杂？

不要复杂。第一张表只要跑通“告警进入系统、责任到人、超时升级、时间线可复盘”这个闭环，就已经有价值。