很多团队的 On-call 问题，不是没有值班人。
而是值班机制本身设计得太随意。
有人靠 Excel 排班。
有人靠群公告。
有人靠团队 Leader 临时指派。
有人长期默认“谁熟悉系统谁兜底”。
有人名义上有值班表，但告警来了还是全群轰炸。
有人排了主备，但没人知道主备分别承担什么责任。
这种状态在系统小的时候还能勉强运行。
但团队一大、服务一多、夜间告警一多，问题很快就会暴露。
值班人疲劳。
故障没人认领。
升级靠人工催。
周末和夜间总是同几个人扛。
值班责任不清，出了问题互相问“今晚是谁看？”
所以，值班表不是把几个人排进日历那么简单。
真正合理的 On-call 轮班机制，要同时回答四个问题：
谁负责第一响应？
没人响应时谁兜底？
不同时间段应该通知谁？
怎么避免长期把压力压给少数人？
值班表的本质，是把故障和人连接起来
很多团队把值班表理解成一个排班日历。
今天张三。
明天李四。
周末王五。
节假日再临时调整。
这只是表面。
值班表真正的作用，是在故障发生时，让系统自动知道“此刻应该通知谁”。
如果值班表不能被告警系统调用，它就只是一个静态文档。
静态文档最大的问题是：关键时刻还要人去查。
告警来了，大家先翻群公告。
查到今天值班人，再手工 @ 他。
没人回复，再找备份人。
备份人也没回复，再找负责人。
整个过程靠人工推进。
这不是 On-call。
这是人工转发告警。
真正的 On-call 机制应该是：告警进入系统后，根据当前时间、告警级别、业务标签、值班表和升级策略，自动通知当前负责人；如果负责人没响应，自动升级到下一环节。
值班表是这条链路里的核心组件。
它把“故障”连接到“当前应该处理的人”。
先别急着排班，先定义责任范围
很多值班表排不好，是因为一开始就跳到了“谁值哪天”。
这太早了。
排班之前，先要定义责任范围。
这个值班表负责哪些系统？
哪些告警会进入这张值班表？
是业务研发值班，还是 SRE 值班，还是平台值班？
值班人负责第一响应，还是负责真正修复？
数据库、网络、安全、中间件这些专业问题是否有独立升级链路？
如果责任范围不清，值班表一定会变成大杂烩。
比如一个“技术值班表”同时接收办公网络、支付系统、测试环境、数据库、Kubernetes、云监控账单告警。
听起来方便。
但真正故障来了，值班人很难判断优先级，也不一定有权限处理。
更合理的方式，是按责任边界拆分。
核心交易系统可以有交易 SRE 值班。
基础设施可以有平台值班。
数据库可以有 DBA 值班。
网络可以有网络值班。
业务研发可以有服务 Owner 值班。
不是值班表越多越好，而是每张表都要有清晰边界。
一张值班表应该让人一眼看懂：它负责什么，不负责什么。
主备值班不是形式主义
很多团队会设主备值班。
但主备最容易流于形式。
主值班收到告警。
备值班也收到告警。
群里所有人也收到告警。
最后大家都看一眼，但没人知道谁该先认领。
这不是主备。
这是多人围观。
主备机制应该有明确分工。
主值班负责第一响应。
他应该第一时间收到 Critical 告警，打开故障详情，判断影响范围，认领或暂缓，必要时拉起协同。
备值班负责兜底。
如果主值班在规定时间内没有认领，系统自动升级给备值班。备值班不是每条告警都同时处理，而是在主值班不可用、响应超时、故障升级时接手。
负责人负责升级后的管理判断。
如果主备都没有关闭故障，或者故障持续扩大，就应该升级给团队负责人、服务 Owner 或更高级别响应人。
这样主备才有意义。
一条常见策略可以是：
Critical 告警先通知主值班。
5 分钟未认领，升级给备值班。
15 分钟未关闭或未暂缓，升级给服务 Owner。
30 分钟仍未恢复，升级给团队负责人或重大故障群。
具体时间可以按业务调整。
关键不是分钟数，而是升级条件要明确。
轮换周期不要只看公平，还要看疲劳
值班排班最常见的问题，是只看“轮到谁”，不看“值班负担”。
一个人值班一天，和一个人值班一周，体验完全不同。
白天值班和夜间值班不同。
工作日值班和周末值班不同。
低噪音系统和高噪音系统不同。
只收 IM 通知和可能被电话叫醒不同。
所以，排班周期不能拍脑袋。
常见有几种模式。
按天轮换
适合告警量相对稳定、团队人数较多、希望降低单人连续压力的团队。
优点是单次负担短，心理压力小。
缺点是交接频繁。每个人刚进入状态，第二天就换人。对于复杂系统，可能不利于连续跟进问题。
按周轮换
这是很多 SRE 团队常用模式。
优点是责任连续。一个人负责一周，可以持续跟进同一批问题，周报和复盘也更清晰。
缺点是压力集中。如果夜间告警多，一周下来会很累。
按周轮换适合告警降噪已经比较好的团队。如果告警质量很差，按周值班会非常痛苦。
白班 / 夜班拆分
适合 7x24 高强度系统。
白天和夜间的响应方式不同。白天可以依赖办公 IM、团队协作、研发快速介入；夜间更依赖电话、短信、App 推送和升级策略。
把白班和夜班拆开，可以让排班更贴近真实负担。
但管理复杂度也更高，需要更好的工具支持。
工作日 / 周末拆分
周末值班通常比工作日更消耗人。
如果长期随机轮换，可能出现某些人频繁覆盖周末。团队会觉得不公平。
合理的排班应该统计周末、节假日、夜间的分布，尽量让高负担时段公平轮换。
所谓公平，不只是“次数一样”，而是“负担接近”。
服务日历很重要
很多团队只有一张固定值班表，却忽略了业务日历。
这会出问题。
比如：
大促期间应该加强值班。
节假日期间应该提前安排备份。
发布窗口应该让相关研发在岗。
数据库维护窗口应该通知 DBA。
重要活动期间低级别告警也可能需要更高关注。
这类场景不能只靠固定轮班。
它需要服务日历。
服务日历的作用是把业务时间、维护时间、特殊保障时间纳入分派策略。
同一条告警，在普通工作日和大促活动期间，处理方式可能不同。
普通工作日 Warning 只进群。
大促期间同样的 Warning 可能需要通知值班人。
计划维护期间某些告警应该静默。
核心发布窗口出现异常，需要同步发布负责人。
如果值班机制不理解这些时间背景，就会过度通知或漏通知。
所以，成熟的 On-call 机制一定要把值班表和服务日历结合起来。
不要所有告警都走同一张值班表
这是另一个常见错误。
为了简单，很多团队把所有告警都发给同一个值班表。
CPU 高也发。
支付失败也发。
数据库慢查询也发。
测试环境异常也发。
办公网络不通也发。
低级别 Warning 也发。
这会把值班人变成告警垃圾桶。
值班表应该和分派策略配合。
不同告警走不同路径。
按严重级别分：
Critical 进入主值班和升级链路。
Warning 进入 IM 群或工作时间处理。
Info 只记录，不打扰人。
按业务线分：
支付告警通知支付值班。
订单告警通知订单值班。
平台告警通知平台值班。
数据库告警通知 DBA 值班。
按时间分：
工作时间可以先通知团队群。
夜间只通知真正需要立即处理的 Critical。
维护窗口内的已知告警静默或降级。
按环境分：
生产环境走正式 On-call。
测试环境进入低优先级通道。
预发环境可以只通知相关研发。
值班表不是唯一规则。
它要和告警标签、严重级别、服务日历、通知方式、升级条件一起工作。
值班人需要通知偏好
很多团队只关注“通知到谁”，忽略“怎么通知”。
这也会影响响应效果。
不同严重级别应该有不同通知方式。
Critical 可以 App 推送 + IM 单聊 + 必要时电话。
Warning 可以 IM 群通知。
Info 可以只进列表或日报。
不同时间段也应该不同。
白天 IM 可能足够。
夜间关键告警要有 App、短信或语音兜底。
睡眠时间不应该被低级别告警打断。
个人也需要通知偏好。
有的人更依赖 App。
有的人更依赖电话。
有的人在境外或出差，短信和电话策略可能不同。
有的人临时请假，需要调班。
如果通知偏好不可配置，On-call 很容易变成粗暴打扰。
好的值班机制应该做到：关键故障一定触达，低价值告警尽量不打扰。
这两件事都重要。
只强调触达，会把人打疲劳。
只强调少打扰，会漏掉关键故障。
调班机制必须简单
值班表最怕两种情况。
一种是排完没人维护。
另一种是调班太麻烦。
现实里，值班人会请假、出差、生病、临时有事，也会遇到家庭安排、活动保障、节假日调整。
如果调班流程复杂，大家就会在群里口头约定。
“今晚我替你。”
“周末你帮我看一下。”
“这两天我不在，有事找他。”
这些口头约定最危险。
系统不知道。
告警来了，仍然通知原值班人。原值班人以为别人替了，替班人以为只是帮忙看一眼，最后故障没人认领。
所以，调班必须进入系统。
临时调班、假期覆盖、主备替换，都应该在值班表里体现，并且能被分派策略实时使用。
一个值班工具好不好用，很大程度取决于调班是否简单。
因为排班一年一次，调班每个月都可能发生。
升级策略比值班表更容易被低估
有值班表，不代表有 On-call 闭环。
如果主值班没响应怎么办？
很多团队的答案是：群里再喊一下。
这不可靠。
升级策略应该自动化。
常见升级条件有两类：
未认领升级。
也就是故障触发后，指定时间内没人认领，就升级到备值班或负责人。这适合保证第一响应。
未关闭升级。
也就是故障持续未恢复或未关闭，达到一定时间后继续升级。这适合保证问题持续被关注。
这两个条件要区分。
一个故障可能已经被认领，但还没恢复。如果一直未关闭，说明影响可能持续，需要更高层级介入。
另一个故障可能没人认领，这时要尽快找备份人。
好的升级链路通常会包括：
主值班。
备值班。
服务 Owner。
团队负责人。
重大故障响应群。
不是每条故障都要走完整链路。
但 Critical 告警必须有明确升级路径。
否则值班表只是“通知一次”，不是响应机制。
排班是否合理，要用数据看
很多团队讨论排班公平，最后容易变成主观感受。
有人觉得自己夜里被吵太多。
有人觉得周末总轮到自己。
有人觉得某个服务太吵。
有人觉得主值班压力比备值班大很多。
这些感受都可能是真的。
但要治理，就要变成数据。
至少应该看几个指标。
每个人被分派次数。
每个人夜间通知次数。
每个人周末通知次数。
每个人 MTTA。
每个人响应投入。
每个值班表触发的故障数量。
每个服务贡献的夜间告警数量。
升级次数和升级原因。
如果某个人长期响应投入高，就要看是排班不均，还是他负责的服务噪音太大。
如果某个值班表经常升级，就要看是通知触达问题，还是值班人负担过重。
如果夜间中断集中来自几个低价值告警，就应该治理规则，而不是继续调整排班。
排班公平不是靠感觉维护的。
它要靠数据反馈。
小团队怎么排
小团队最常见的问题是人少。
如果只有 3 到 5 个人，想做严格 7x24 主备值班，压力会很大。
这时不要盲目模仿大厂。
更现实的方式是分层。
核心业务 Critical 告警必须有人响应。
低级别告警只在工作时间处理。
夜间只保留少量真正需要叫醒人的告警。
周末采用轻量主备，避免所有人同时被打扰。
小团队尤其要重视告警降噪。
因为人少，任何低质量告警都会直接消耗团队。
如果告警质量没有治理好，小团队做 On-call 会非常痛苦。
对小团队来说，值班表不是越复杂越好。
先做一张最小可用值班表：
每周轮换一次。
一个主值班。
一个备值班。
Critical 先通知主值班，未认领升级备值班。
Warning 只进工作群。
维护窗口静默。
跑起来之后，再根据数据调整。
中大型团队怎么排
中大型团队的问题不是人少，而是责任复杂。
多个业务线。
多个基础平台。
多个研发团队。
多个专业角色。
多个环境和地区。
这时最重要的是分层分域。
不要试图用一张总值班表解决所有问题。
可以按职责拆：
业务线值班。
平台 SRE 值班。
数据库值班。
网络值班。
安全值班。
重大故障管理值班。
然后用分派策略把告警路由到正确值班表。
比如：
team=payment 且 severity=critical，通知支付主值班。
component=mysql，通知 DBA 值班。
service=kubernetes，通知平台值班。
severity=critical 且持续未关闭，升级重大故障管理值班。
中大型团队还要重视权限和审计。
谁能改值班表？
谁能临时调班？
谁能修改分派策略？
谁能关闭故障？
谁能查看其他团队故障？
这些问题如果不管理，On-call 平台会变成另一个混乱入口。
一个可落地的值班表模板
如果你现在还没有正式值班机制，可以从这个模板开始。
值班对象：核心生产系统。
参与人员：4 到 8 人。
轮换周期：每周轮换。
角色：主值班、备值班。
覆盖时间：7x24，工作时间和非工作时间通知方式不同。
Critical 策略：先通知主值班，5 分钟未认领升级备值班，15 分钟未关闭升级服务 Owner。
Warning 策略：工作时间通知团队群，非工作时间进入列表或延迟通知。
Info 策略：只记录，不主动打扰。
维护窗口：通过服务日历或静默规则处理。
调班：必须在系统里调整，不接受只在群里口头约定。
复盘指标：每周看分派次数、夜间打扰、升级次数、MTTA、MTTR、Top 告警来源。
这个模板不复杂。
但它已经覆盖了 On-call 排班最关键的机制。
很多团队不需要一开始就做复杂的全球轮班、跨时区排班、Follow-the-sun。
先把主备、升级、调班、服务日历和数据反馈跑通，就已经比群公告和 Excel 强很多。
Flashduty 在这里解决什么
Flashduty 的价值不是帮你画一张排班表。
它要解决的是排班表和告警响应之间的连接。
值班表可以按小时、天、周、月轮换，支持白班、夜班、主备、临时调班、日期掩码和公平轮换等场景。
分派策略可以根据告警条件，把故障通知给当前值班人，也可以设置通知方式、延迟窗口、通知模板和升级规则。
当故障触发后，系统会记录分派、通知、认领、暂缓、升级、关闭等时间线。
管理者可以再通过分析看板看响应投入、MTTA、MTTR、中断次数和高频告警来源。
这就把值班从静态日历，变成了可执行、可追踪、可分析的响应机制。
最后
值班表怎么排才合理？
没有一个放之四海皆准的答案。
但有几个原则很稳定。
值班表要有清晰责任范围。
主备要有明确分工。
轮换周期要考虑疲劳，而不是只看次数。
服务日历要覆盖特殊时间。
告警要按级别、业务、环境和时间分派。
调班必须进入系统。
升级策略必须自动化。
排班是否公平，要用数据看。
如果你的团队现在还靠 Excel、群公告和人工 @ 人来做 On-call，不一定要一步到位建设很复杂的体系。
可以先从一张最小可用值班表开始。
选一个核心系统。
确定主备。
配置 Critical 告警分派。
设置未认领升级。
跑一周。
看数据。
再调整。
On-call 机制不是一次设计完美的。
它应该像告警治理一样，持续迭代。
真正重要的是，不要让生产故障长期依赖“谁刚好在线、谁刚好看到群消息、谁比较熟悉系统”。
一个稳定的工程团队，需要把这件事变成机制。
值班表，就是这个机制的起点。
