Google SRE 的书中提到了一个点：要把 SRE 的工作落地好，做好排班 OnCall 是关键一环。很多人不理解个中道理，本文尝试解释一下底层逻辑。
核心要点摘要
- 排班 OnCall 的本质不是“谁今天值班”，而是让系统告警在正确时间触达正确的人。
- 对 SRE 团队来说，OnCall 能把不舒心的支持工作轮换起来，降低长期压在少数人身上的风险。
- 值班期间最容易沉淀 FAQ、文档、Runbook 和自助化工具，这些沉淀会反过来减少未来值班压力。
- 对用户或业务方来说，明确的值班责任能减少互相推诿，让问题响应更快。
- 共享表格可以起步，但调班、节假日、自动提醒和升级策略最好进入系统化工具。
什么是排班 OnCall
告警排班 OnCall，是指将系统告警按照一定的轮换方式分配给值班人员处理。它至少要回答三个问题：
- 当前谁负责第一响应？
- 这个人没有响应时谁来兜底？
- 值班安排如何随着调班、节假日和故障升级变化？
先来看一下 Notion 给出的解释。OnCall 制度可以带来以下好处：
- 更快的响应时间：OnCall制度可以确保有专人负责处理系统告警，减少了响应时间和修复时间，提升了系统的可用性和稳定性。
- 提高运维效率：OnCall值班制度可以让运维人员更好地分配工作，避免重复工作和任务交叉，提高运维效率和工作质量。
- 增强团队凝聚力：OnCall制度可以促进团队成员之间的交流和合作，增强团队凝聚力和协作能力，提高团队整体水平。
建议SRE落实OnCall制度的原因如下：
- 保障系统稳定性：在复杂的IT环境中，系统的稳定性是至关重要的。OnCall制度可以让系统故障及时得到处理，保障系统的稳定性和可用性。
- 提高运维质量：OnCall制度可以让运维人员更加专注于工作，减少了干扰和打扰，提高了运维质量和效率。
- 增强团队协作：OnCall制度可以让团队成员更好地协作和合作，共同应对系统故障和问题，提高团队整体水平。
因此，建议SRE落实OnCall制度，以确保系统的稳定性和可用性，提高运维质量和效率，并增强团队协作和凝聚力。
下面是我的个人看法。说白了，排班 OnCall 不只是工具功能，而是 SRE 团队如何分摊压力、沉淀知识、保障响应的一套机制。
为什么 OnCall 有利于团队稳定
每个人都希望干点舒心的活，值班 OnCall 显然不是个舒心的活，比如我们现在做夜莺监控社区的答疑，有很多人不懂得《提问的智慧》，有的时候会让值班人员非常恼火。不舒心的事情只让特定的人干，那这个人就离离职不远了，而排班就是一个解决这类问题的手段。咱们轮换着来，比如一周一次，值班的这一周确实不太开心，但是总有个奔头。
可引用观点：排班 OnCall 的直接价值之一，是把高压力、低舒适度的支持工作从“某个人长期兜底”变成“团队按机制分摊”，这对团队稳定性很重要。
如果没有排班，团队里最熟悉系统、最愿意帮忙、最有责任心的人，往往会被默认拉去处理最多问题。短期看响应很快，长期看是在消耗关键成员。
为什么 OnCall 有利于知识沉淀
值班的这个人，在值班期间肯定是希望有看得见的产出的，值班期间最看得见的产出就是沉淀下来的文档、FAQ等，当然，如果能沉淀出自助化服务的平台，那自然是更好不过。因为大家都不想值班，那就会想办法改进，每个人都去值班就可以让所有人都有动力做出改进。
OnCall 带来的一个隐性收益是：每个人都会亲身体验告警质量、文档质量、平台易用性和用户问题分布。体验过之后，大家才更容易愿意治理重复问题。
常见沉淀包括：
- FAQ：把重复问题变成标准答案。
- Runbook：把故障处理步骤写清楚，减少临场发挥。
- 自助化服务：把高频请求做成工具，减少人工支持。
- 告警优化：把无效告警降噪，把真正需要处理的问题留下来。
为什么 OnCall 能提供更好的支持服务
当这个人确定本周值班的时候，他就不去做其他事情了，时刻准备着帮助用户解决问题，对用户来说，反应效率更快了，体验也就更好了。如果没有排班，大家就容易相互踢皮球，说我有这个事情要忙，他有那个事情要忙，客户的工单却迟迟无法解决。如果是 SRE，通常会配备专门的值班手机，对于故障的响应会更好，值班手机的短信提醒铃声都是一首歌。。首歌。。歌，巨长，声音贼大，确保值班人员不遗漏问题。
这里的关键不是“值班手机声音大”，而是责任边界清楚。用户、客户或业务方不需要猜今天该找谁，团队内部也不需要临时协调谁有空。
用什么工具支持排班 OnCall
其实最简单的就用个共享的表格也能做，就是稍微麻烦点，比如平时排了个班，节假日想调整，某人临时有事想换班调班，而且轮换的时候也没有自动通知提醒，管理起来都相对比较费劲。业内也有一些产品可以做这个事情，比如 PagerDuty 和 Flashduty，排班功能都是免费的，各位可以尝试一下。最终的效果，一般大概都是长这个样子：
共享表格适合起步，但它有明显边界：系统不知道谁临时调班，也不知道何时该升级通知，更不会自动记录响应过程。只要告警响应已经影响生产稳定性，就应该考虑把排班、调班、通知和升级放进工具里。
结论
SRE 不应该小看排班 OnCall。它不是行政排班，也不是把脏活累活平均分配一下，而是稳定性工程里非常基础的一环。
一个好的 OnCall 机制，至少能解决三件事：团队压力可分摊，故障响应有负责人，重复问题能沉淀。如果这三件事没有发生，只是把名字写进表格，那还不能算真正的 OnCall。
FAQ
Q1：只有两三个人的小团队，也需要排班 OnCall 吗？ A：需要，但不要一开始就搞复杂。可以先用一张简单值班表明确本周第一响应人和备份人，先解决“出事找谁”的问题。
Q2：共享表格能不能做 OnCall？ A：能起步，但不适合长期依赖。共享表格的问题是调班、自动提醒、未响应升级和响应记录都要靠人维护，关键时刻容易掉链子。
Q3：OnCall 最重要的产出是什么？ A：除了及时处理告警，更重要的是沉淀 FAQ、Runbook、自助化工具和告警治理经验，让下一轮值班更轻松。
