顶级 SaaS 公司 Datadog 是如何做 OnCall 的

导读

Datadog 是监控和可观测性领域的头部 SaaS 公司，服务稳定性和客户可用性要求很高。它的 OnCall 轮班方式值得关注，不是因为“值班表复杂”，而是因为它把人、工具、升级路径和管理者责任放在同一套机制里设计。

这篇文章围绕 Datadog 公开分享的 OnCall 轮班实践，回答三个问题：

很多公司早期没有正式的值班表，故障来了就找最熟悉系统、最愿意兜底、最容易被联系到的人。短期看问题解决了，长期看会积累三个风险。

第一，工作量会集中到少数人身上。长期夜间被电话叫醒的人会持续疲惫，没有足够时间做架构改造、自动化、告警治理等更高价值的工作。

第二，疲惫会反过来影响稳定性。值班人精神紧绷、上下文切换频繁，处理告警时更容易漏看信息、误判优先级，甚至把小故障处理成大故障。

第三，团队会失去边界感。没有明确轮班、备份和升级机制时，个人生活和工作长期混在一起，离职风险会上升，团队招聘和知识传承也会受影响。

其实吧，不重视值班 OnCall，本质就是不重视稳定性。

Datadog 的轮班实践里，值班表不是简单地把人名排成日历，而是同时考虑工作量、假期、临时调班和响应质量。

几个设计点比较关键：

上图是 Datadog 的 OnCall 值班表，确实挺复杂。实际上，国内用户的值班需求往往更驳杂，假期、临时调班、跨团队升级和值班补偿都需要提前设计。

好的 OnCall 机制不能只要求工程师“随时在线”，还要给值班人足够的支撑。

培训和资料是第一层支撑。新人直接上岗值班，很容易在告警风暴中不知道先看什么、找谁确认、哪些动作有风险。值班前至少要准备基本培训、常见故障 SOP、服务负责人信息和升级路径。

工具平台是第二层支撑。Datadog 自然使用自己的 OnCall 工具，国内用户也可以使用 Flashduty。这类平台要解决的不是“发一条通知”，而是在一个地方完成值班、调班、告警接收、响应、认领、升级和分派，并通过手机 App 或 IM 触达值班人。

备份机制是第三层支撑。每次值班最好有主值班人和备份值班人。主值班人没有响应时，系统自动通知备份人员；仍然无法响应时，再升级到直线经理。这样做可以避免单点依赖，也能让升级路径在事故前就被设计好。

Datadog 会让直接经理参与值班。这个安排至少有两个价值。

第一，经理参与能给团队一个明确态度：OnCall 不是一线工程师单方面承担的脏活累活，而是稳定性体系的一部分。

第二，经理需要感受到一线的真实摩擦。只有亲自经历误报、通知噪音、文档缺失、升级不清晰、工具不好用，管理者才会更有动力优化 OnCall 流程和工具。

国内很多团队的问题恰恰相反：经理做了管理以后逐渐远离一线，对告警质量、排障链路和值班负担失去体感。时间长了，OnCall 流程会越来越像“制度”，但越来越不像“能让故障更快恢复的机制”。

如果要从 Datadog 的实践里抽取可落地的做法，可以先检查这几项：