on-call 是不是「隐形的加班费」？聊聊值班的成本该不该被显性化定价

背景

做了 10 年 SRE，跨了 4 家公司，从 5 人的运维小组到 200+ 人的平台团队都待过。有一件事我每次接手新团队都会被问："你们 on-call 怎么算钱？" 答案几乎都一样——不算。值班是「义务」，是「锻炼」，是「轮到的时候就扛一下」。

但拆开看，on-call 的真实成本其实非常具体：

• 时间成本：每周 1 天 standby（哪怕只值 2 小时警觉），加上每月 0~3 次真实唤醒（凌晨、节假日、饭点）；
• 机会成本：值班周里那个本来可以写 RFC、做重构、推架构的工程师，被「随时可能被叫走」的状态持续打断；
• 心理成本：这是最被低估的一项——长期处于「电话随时响」的警觉态，皮质醇水平、睡眠质量、对新技术的好奇心都会被慢慢吃掉；
• 隐性激励扭曲：如果 on-call 不算钱、不算绩效，那理性的工程师会做三件事——(a) 把告警调静音或调阈值，(b) 把改进项塞给不值班的人，(c) 想办法在值班周前把「危险特性」藏起来或推迟。

我见过一个真实案例：某团队连续三个季度 P0 数量「稳定下降」，后来发现不是稳定性变好了，而是 on-call 同学把告警阈值从 5xx > 1% 悄悄改成了 5xx > 5%，并且把所有"可疑但没炸"的告警都关掉了。直到一次大促压测才暴露出来。

常见的几种做法

1. 完全义务制：值班不计薪、不计绩效，靠团队文化和"年轻人该锻炼"撑着。优点是简单，缺点是上面说的激励扭曲 + 心理成本，长期看是透支。
2. 轮值 + 调休：值班周给 1~2 天调休。比 1 好，但「调休」往往被挤占（项目赶 deadline 就不给了），最后等于白干。
3. 值班津贴：按次或按周给现金补贴。解决了"算不算钱"，但没解决"机会成本"和"心理成本"，而且津贴容易变成「值班越多赚越多」，对稳定性是负激励。
4. 值班算绩效 / 算晋升：把 on-call 经历写成晋升材料里的一条"稳定性贡献"。听起来很对，但实操里往往变成"谁值班多谁晋升快"，而不是"谁把系统做稳了谁晋升快"。
5. 专职 SRE 轮值：开发团队不值班，统一由 SRE 团队扛。听起来最公平，但 SRE 不写业务代码、不懂业务上下文，事故响应质量往往反而下降（我亲眼见过 SRE 团队处理业务 P0 比开发自己处理还慢 40% 的案例，因为要问人问半小时才搞懂调用链）。

我的倾向

我倾向一个组合方案，核心思想是：把 on-call 当成一种可以被"定价"的工程活动，而不是"义务"。

具体三件事：

1. 显性化成本：每个团队的 on-call 预算（每周 standby 小时数 + 预估唤醒次数）写进季度 OKR，跟"业务需求交付"并列。意思是：你要么花这个预算值班，要么花等量的工程时间把告警降噪、把 runbook 补全、把危险路径加防御——两条路都算"花了钱"，不值班不算"省了"。
2. 心理成本单独定价：值班津贴不是按"次数"发，而是按"被叫醒的代价"发——凌晨 0-6 点唤醒 +X 倍，周末唤醒 +Y 倍。让"谁被叫得最惨谁拿得最多"，而不是"谁值班周最多谁拿得最多"。
3. 告警降噪算绩效：把"on-call 期间被唤醒的 P0/P1 中，有多少是'可被提前发现的'"作为一个反向指标。一个季度下来，如果某团队的唤醒里 70% 是"本可以靠 runbook / 监控 / 防御代码避免的"，那这个团队应该被要求投入工程时间做改进，而不是继续靠人扛。

想听大家在什么场景下怎么选

• 你们团队的 on-call 是怎么算的？有没有真的"算钱"？
• 你们见过因为 on-call 激励扭曲导致的"告警静音"或"改进项甩锅"吗？
• 在「专职 SRE 轮值」vs「开发轮值」里，你们最后选了哪个？为什么？
• 如果让你设计 on-call 的"定价模型"，你会怎么定？哪些成本该显性化、哪些该隐性化？

欢迎拍砖，也欢迎把你团队的真实做法贴出来（脱敏即可）。