值班排班怎么安排：7 步做出开发者不反感的 On-Call 表

**值班排班（On-Call Scheduling）**是把"非工作时间谁来响应告警"制度化的过程。排得不好，团队怨声载道、告警没人接；排得好，故障响应快、成员负担公平。下面 7 步从零搭起一张可长期运转的值班表。

什么是值班表

值班表定义了任意时刻谁是故障第一响应人。工作时间之外的时段尤其关键：半夜服务器宕机，告警必须精准打到当班人手机，而不是发进没人看的群。

一张合格的值班表要回答三个问题：谁在岗（覆盖全天 24 小时）、联系不上怎么办（升级链）、值完班有什么补偿（调休或津贴）。

第一步：先摸清团队的真实偏好

排班前先做一轮匿名调研，问清楚：

• 每周能接受几次值班？能接受连续值几天？
• 家里有没有硬性约束（接孩子、照顾老人、跨城通勤）？
• 夜班和白班的意愿差异有多大？

调研的意义在于：值班制度最大的失败模式不是"没人值"，而是长期违背个人生活安排导致核心成员离职。小团队尤其要尊重个体约束。

第二步：选定一种常见轮换模式

没有银弹。5 人以下优先周轮换，跨 3 个以上时区再上 Follow the Sun。模式细节见本系列下一篇《4 种值班排班模板》。

第三步：设主备双岗（Primary + Backup）

只排一个值班人是常见隐患：他在洗澡、开会、手机没电，告警就漏了。正确做法是同时排主值班（Primary）和备值班（Backup）：

• 主值班负责第一时间响应和处理；
• 主值班 5-15 分钟未确认，告警自动升级给备值班；
• 备值班同时是主值班的"军师"，复杂故障可以拉进来会诊。

主备每周同步轮换，避免备班变成"永不响的闲职"。

第四步：写清值班流程和职责边界

值班人收到告警后"该做什么"必须事先写下来，否则每个人响应质量参差不齐。至少定义：

1. 确认时限：告警发出后多久内必须 Ack（建议 15 分钟内）；
2. 升级路径：搞不定找谁——二线专家、DBA、供应商支持，各留联系方式；
3. 通报义务：什么情况要发公告、通知客户或上报管理层；
4. 移交规范：交接班时未完结的事件如何同步（推荐写交接笔记）。

第五步：扔掉 Excel，上专业值班工具

电子表格排值班表的痛点：改一次全员通知一遍、无法和告警联动、联系不上时不会自动升级。专业工具把排班、通知、升级三件事打通。

在观测云里，可以用告警策略与通知对象管理来实现值班化通知：按时间段把不同成员/群组挂到告警策略上，告警自动路由给当前值班人；配置升级规则后，超时未确认自动转给备班或上级。轮换表变更只需在控制台改一次，全员即时生效。 1

第六步：建设"值班不背锅"的支持性文化

制度再精细，文化不对也会崩。三条红线：

• 对事不对人：值班引发的事故复盘聚焦流程和系统缺陷，不追责个人；
• 值班有补偿：明确调休或津贴规则（详见本系列《值班薪酬怎么定》）；
• 值班负担可申诉：任何人觉得排班不公，有渠道提出且真的会被调整。

第七步：度量、复盘、持续改进

值班表不是一次排完就一劳永逸。每月看这几个数：

• 人均值班时长与告警次数：是否严重不均；
• 夜间告警占比：夜告警太多说明告警规则太敏感，该治理噪声；
• 升级触发率：备班频繁被拉起来，说明主班培训或告警分级有问题；
• MTTA（平均确认时间）：反映值班响应纪律。

数据达标就微调，不达标就回到第一步重新调研。值班制度是活的流程，不是墙上的表格。

观测云对照

• 监控器与告警策略：告警按策略路由，可绑定不同通知对象组，实现按班次定向通知； 1
• 通知对象管理：支持邮件、短信、电话、钉钉、企微、Webhook 等渠道，值班人自选触达方式；
• 告警升级：在告警策略中配置超时升级，把"主备双岗"落成系统规则而非口头约定；
• 结合可用性监测：值班人收到的不只是服务器告警，还有站点拨测告警，覆盖用户视角。 2

常见问题（FAQ）

Q：两个人也要排值班表吗？
要。哪怕是"单双周轮流"这种极简规则，写下来就能避免"以为对方在看"的真空期。两人团队重点是把升级对象定为外部资源（如云厂商工单、技术外援群）。

Q：值班期间被告警轰炸怎么办？
这是告警质量问题，不是排班问题。先给告警分级（P1 打电话、P3 发群），再治理抖动告警。本系列《MTTR 等事件指标》一篇有治理方法。

Q：Follow the Sun 是不是最好的模式？
对跨时区团队是，对单一时区团队反而增加协调成本。模式选择跟着团队地理分布走，不要盲目学大厂。

Q：值班表多久轮换一次合理？
主流是一周一换。低于 3 天交接太频繁，高于 2 周倦怠感明显。假期密集的月份可临时改为半周轮换。

参考资料

• 观测云告警策略与通知对象文档
• 观测云可用性监测（云拨测）