我们熟知的 Kubernetes 是 Google 内部容器编排工具 Borg 的开源实现，Prometheus 是其内部监控系统 Borgmon 的开源版本。那么 Google 内部的 On-call 工具 Outalator，有没有对应的产品？
这是个很自然的提问，但它问错了重点。Google SRE 在《Site Reliability Engineering》里用了将近三个章节讲他们如何做 On-call，工具只占其中很小一部分。决定 On-call 质量的，是文化、机制、工具三者的咬合。工具最容易复制，也最容易被高估。
这篇文章拆开 Google SRE 和 Datadog 两套被反复验证过的实践，看看顶级公司到底把功夫下在了哪里，以及一支团队能从中拿走什么。
一个公开的硬指标：琐事低于 50%
Google SRE 有一条广为人知的原则：用软件工程的方式解决运维问题，把"琐事"（toil）压下去。落到可执行的层面，他们设了一个公开的、可考核的目标：每个 SRE 花在琐事上的时间不超过 50%，剩下至少一半时间投入工程项目，用来消灭未来的琐事或为服务增加能力。
这条线为什么是 50%，而不是"尽量少"？因为模糊的目标等于没有目标。一旦写成可度量的硬指标，超标就会暴露、就有人要负责、就会触发补人或减负的动作。Google SRE 之所以反复强调要控制琐事，是因为他们清楚地列出了琐事失控的代价：
- 职业停滞：工程时间被挤占，个人成长变慢甚至停滞。脏活累活在不可避免且影响巨大时值得做，但没人能靠重复劳动建立职业生涯。
- 士气与留存：每个人对琐事的容忍都有上限，超过就会倦怠、厌烦、不满。琐事过载，最先想走的往往是团队里最强的工程师。
- 角色被侵蚀：SRE 本质是工程组织。一旦过度陷入琐事，研发会更倾向于把本该自己承担的运维甩过来，其他团队也开始默认 SRE 该接这些活。这是一条很难逆转的下坡路。
统计上，琐事的最大来源是中断性工作，其次是 On-call。前者多是与服务相关的非紧急事务，后者是紧急的应急响应。Google 给出的经验值是：一个 SRE 团队至少要有 6~8 人，才能让轮值 On-call 带来的琐事保持在低位。人不够，轮换就摊不开，最后一定退化成"只有值班、没有轮换"。
Outalator：工具的本分是"以故障为单位"
回到那个最初的问题。Google 内部的 On-call 工具叫 Outalator，SRE 在一个集中平台上管理告警的完整生命周期。它的核心能力其实很克制：
- 告警聚合：把多条相关告警聚合成一个"故障"，SRE 以故障而非单条告警为单位来跟进。这一步直接砍掉了大量重复通知和重复处理，是降噪的根。
- 打标签：给故障加标签描述上下文，方便按标签筛选、统计、复盘。
- 数据分析：从团队、个人、服务、机房等维度分析告警量趋势、响应效率、处理效率，让团队能从宏观上看清 On-call 的薄弱环节。
- 一键交接与报告：选中一组故障，把标题、标签和关键记录以邮件交给下一班 On-call 工程师，交接因此变得轻松。它还支持"报告模式"，服务于很多团队每周一次的生产评审。
Outalator 没有去做花哨的事。它做的全是"把告警收敛成故障、让人能协同和复盘"这类朴素工作。**好的 On-call 工具不解决稳定性，它解决的是"让人有能力解决稳定性"。**这一点下文还会再印证一次。
Datadog：把"可持续"写进排班规则
如果说 Google SRE 给了我们一套理念框架，那 Datadog 提供了一份更贴近落地的排班操作手册。Datadog 是可观测性领域的头部玩家，自身对服务可用性的要求极高，其 On-call 实践相当成熟。
Datadog 的排班设计有几条很值得抄作业的规则：
- 组的规模有下限：理想是 6~8 人一组轮换；人实在不够，也要凑够 3~4 人，才排得开一张可持续的值班表。这与 Google 的 6~8 人经验线完全一致。轮换的本质是稀释，人数不够，再好的流程也救不了。
- 单次时长有上限：每班一般 8~12 小时，并把工作量、假期、临时调班一起纳入排班，而不是排完就不管。
- 值班期只做值班的事：当值工程师专注接告警、巡检、维护告警规则与 SOP，不开发新功能。这条看似简单，却是在制度上承认"值班是一份独立的工作"，而不是"顺手兼着干"。
- 频率要适中：值班太频繁会倦怠，太少则失去改进值班流程的动力。这是个常被忽略的微妙平衡。
除了排班，Datadog 还在两个地方下了功夫，而这恰恰是很多团队的盲区：
给值班人足够的支持。 不培训、不给资料就直接上岗是不负责任的。除了工具，Datadog 坚持一主一备：主值班睡着了，系统自动通知备份；备份还顶不住，再上升到直线经理。这套兜底链路，保证了"半夜没人接"不会演变成一次事故。
让经理也进轮值。 Datadog 让直接经理参与值班，一是给团队做榜样，二是让经理亲身挨炮火。只有真切感受到 On-call 的疾苦，经理才有动力去优化流程和工具。管理者一旦脱离一线，久而久之会失去对一线的感知，On-call 流程于是越来越糟。这是一个朴素却极其有效的纠偏机制。
把两套实践合起来看
并排放在一起，Google 和 Datadog 指向同一个结论：On-call 做得好不好，不取决于买了什么工具，而取决于有没有把它当成一件需要被设计、被度量、被持续投入的正经事。
- 文化上：以人为本，关注长期结果，承认值班是一份消耗，需要补偿和保护。
- 机制上：6~8 人成组、可持续的排班、明确的备份与升级链路、经理下场、琐事不超 50% 的硬约束。
- 工具上：以故障为单位聚合告警，支撑协同、交接、度量和复盘。
这三层里，工具最容易补齐，文化和机制才是门槛。
怎么把这套机制用起来
把 Google 的模式完整照搬，对大多数团队都不现实。值班和加班的界限本就模糊，"只有值班、没有轮换"是很多团队的常态；规划被短期目标驱动，技术债越堆越高；不少公司 SRE 与研发人数比接近 1:100，凑出一个 6 人 SRE 组几乎不可能。这些是结构性阻力，不必假装它们不存在。
但"全套学不来"不等于"无从下手"。可以从代价最低、回报最快的几件事开始。
第一，先建立度量。 没有度量就没有改进。运维负责人表面看到的是"告警太多、团队疲于奔命"，但看不清告警处理的真实工作量，于是无法规划补人，更看不清优化方向，情况只会持续恶化。一套基本的 On-call 度量至少要包含：
- 降噪比：告警聚合后的压缩比，越高越好；
- 响应比：被认领的告警占比，衡量告警是否真的有用，越高越好；
- 告警总量：窗口内的告警数，越低越好，基于 SLO 的告警能显著压低它；
- MTTA（平均认领时长）：反映处理效率和团队压力，合适即可，长期偏低也可能意味着人被榨干；
- MTTR（平均恢复时长）：反映观测能力、基础设施和对业务的理解，越快越好。
这五个指标一旦能稳定看到，"该补人还是该治理告警""哪条告警该删"这类决策才有了依据。
第二，先让排班可持续。 人凑不齐 6 人，那就先保住 34 人的最小轮换，把单班时长压到 812 小时，明确一主一备和升级到经理的链路。这些都不需要额外预算，只需要把规则定下来并执行。
第三，工具这一层，今天有现成选择。 Outalator 没有开源，但市面上已有对标的产品。它们能在一个平台上接入各类监控系统的告警，做聚合降噪、认领升级分派、值班排班调班，并打通 IM 和手机 App，把 Google 和 Datadog 在工具层做的事直接交到你手里。
Flashduty 由开源监控工具夜莺背后的团队开发，能接入主流监控系统与 IM，上手简单。如果你正在做选型，可以看当前的 Flashduty 与 PagerDuty 对比。
工具只是起点。把告警收敛成故障、把度量摆上桌、把排班变得可持续，这三步走通了，"像顶级公司一样做 On-call"就不只是一句口号。
