on-call 值班到底是必要的痛，还是被设计成惩罚的痛？聊聊你们团队怎么把它做对的

背景

做了 15 年运维，从 2010 年写 crontab 脚本看监控，到现在在 K8s + Prometheus + Grafana 体系里值班，"on-call" 这个词我听了十几年。但每次事故复盘绕不开一个事实：值班这件事，70% 的团队做的是"惩罚机制"，只有 30% 做的是"必要的痛"。

我印象最深的一次：2018 年，一个 6 人后端团队，每周轮换 on-call，单人制。某位同事连续两周值班，第二周凌晨 2:47 被 PagerDuty 叫醒，P1 告警。他爬起来 15 分钟后接电话，发现是 Grafana 的一条"磁盘使用率 > 80%"告警——后来查，那条告警阈值在 2017 年就被设错了，应该是 > 95%。他被叫醒的那 15 分钟，团队其实没有任何业务损失。 但那位同事从此再没主动申请过值班，半年后转岗。

从那以后我开始认真想：值班的目的是什么？

常见的几种做法（我观察到的）

1. 单人 + 周轮换派：最简单，成本最低。问题是单点风险大，凌晨 3 点一个人面对生产，决策质量约等于零。我们团队 2016 年前就是这么干的，复盘时经常看到"当时为什么这么操作"答不上来。
2. 双人 + 周轮换派：主备制，on-call + backup。主 on-call 30 分钟没响应就升级到 backup。逻辑是"凌晨 3 点单人的判断力 < 2 人 15 分钟的讨论"。我们 2017 年改成这套，误判率从 40% 降到 12%（数据是复盘会里数出来的）。
3. 固定值班级派：不轮换，固定 2~3 人组成 on-call 组，按周排班。逻辑是"值班需要经验，新人来了只会加重告警疲劳"。问题是不公平，组内的人会被钉死。
4. 无值班 + 全自动化派：所有告警走自愈链路，人只处理自愈失败的 P0。理想很美好，但前提是"自愈边界划得对"——这恰好是我上一轮讨论帖的主题。

我的倾向

我站"双人 + 周轮换 + 告警分级"，但想强调一个被普遍忽略的细节：值班的痛，80% 不是来自"被叫醒"，而是来自"被叫醒后不知道该怎么办"。

具体标准我用了五年，分享出来大家讨论：

• 告警分级必须可执行：P0 = 业务不可用 + 有收入损失 + 自愈失败，三条同时满足才叫人；P1 = 业务降级但可用，值班人判断是否需要升级；P2 = 阈值告警，只进 on-call 日志，不打电话。我们团队 P2 占告警总量的 72%，改成"只进日志"后，被叫醒的频率从每周 3.2 次降到 0.4 次。
• 值班必须有 runbook：不是"看日志"三个字，而是"看到 X 告警 → 执行 Y 命令 → 判断 Z 指标 → 决策 A/B"。我们团队要求每个 P0/P1 告警必须有对应 runbook，新告警上线前 runbook 必须 review 通过。
• 值班补偿必须透明：不是"调休"这种模糊承诺，而是"值班周 + 1 天带薪休假"或"值班津贴"。我们团队是后者，每月固定 800 元（脱敏为 [已脱敏] 具体金额），写进 OKR。
• 值班复盘必须 blameless：复盘会只讨论"系统为什么没拦住"，不讨论"人为什么没处理对"。这条我们执行得最差，但也是收益最大的一条。

想听大家聊聊

1. 你们团队值班的实际安排？单人还是双人？轮换周期？用什么工具（PagerDuty / 自建 / 钉钉机器人）？
2. 告警分级怎么划的？P0/P1/P2 的边界是什么？有没有"只进日志不叫人"的告警类型？
3. runbook 覆盖率大概多少？新告警上线前有没有 runbook review 这个卡点？
4. 你们最痛的一次值班经历是什么？事后改了什么？
5. 值班补偿怎么做的？调休 / 津贴 / 都没有？

我特别想听**中小团队（5~15 人）**的做法——大厂有专门的 SRE 团队，但大多数团队就是"开发兼运维"，值班机制往往是被"熬"出来的，不是被"设计"出来的。这种"熬"出来的机制，哪些值得保留，哪些必须改？