On-call 不是惩罚

很多团队把 on-call 当苦差——这是文化问题，不是制度问题。健康的 on-call：

  • 认可它的价值：on-call 能产出最重要的运营改进（被叫多次的 issue 暴露真问题）
  • 给补偿：薪资 / 调休 / 班次明示——别让人凭"觉悟"扛
  • 让所有 SWE 轮：包括写代码的工程师，逼大家把可靠性纳入设计
  • 不要让一个人独扛：bus-factor 1 的 on-call 是定时炸弹

轮班模式

模式 节奏 适合
每周轮换（Weekly） 一周 7×24，下周交班 多数中等规模团队
每日轮换（Daily） 一天一班 小团队或事故密集
跟太阳走（Follow-the-sun） 跨时区团队接力 全球团队，避免半夜叫醒
工作时间 + 非工作时间分两班 白班一组人，夜班另一组 较成熟的大团队

7×24 一周是常见起步——关键是不要让同一个人连续多周。

Primary / Secondary

Primary（主）：第一手接告警，30 分钟内响应
Secondary（副）：Primary 没响应，自动升级；或 Primary 需要支援

Primary 不应是 24×7 一个人：通常一周一班，超过 7 天会导致疲劳和质量下降。

升级路径（Escalation Path）

告警 → Primary （5–15 分钟没 ack）
    → Secondary
    → 团队 Lead
    → 跨团队 Manager
    → CTO

每一级有时间窗口+ 有联系方式——PagerDuty / Opsgenie 等工具就是为此而生。

工具

  • PagerDuty：业内事实标准，功能最全
  • Opsgenie（Atlassian 收购，现叫 Atlassian On-call 集成 Jira）
  • VictorOps（Splunk 旗下）
  • Squadcast：相对新但全功能
  • 国内：观涌 / OneAlert / 腾讯蓝鲸告警等

核心能力：值班排班 + 多渠道（电话 / 短信 / App push）+ 升级 + ack 机制 + 后置事故工作流。

交班

每次轮换前必须有正式交班：

交班清单（写在群 / Wiki / 工具）：
- 这一班期间发生的告警 / 事故
- 处理到一半还没解决的问题（incident 单号）
- 当前生产是否有"不要碰"的状态（如发布冻结、依赖方故障中）
- 下一班需要特别留意的服务

无声交班 = 信息丢失 = 重复故障。

心智健康

这一项常被忽视——SRE Book 专门一章讲：

  • 告警疲劳：见上一篇告警体系文章；首要解决方式是减少告警数量，不是加人
  • "半夜被叫醒不必再上班"：如果当晚处理超过一定时长，第二天该补休
  • 不要孤立 on-call：建专门 Slack 频道、有支援机制
  • 观察异常：on-call 工程师抱怨变多 / 离职率上升 → 看 on-call 数据，不是骂员工

如何衡量 on-call 健康度

  • 告警数量 / 月（趋势是否下降）
  • 告警 → page 比例（无效告警占比）
  • MTTA（Mean Time To Acknowledge）
  • MTTR（Mean Time To Resolve）
  • 半夜呼叫次数 / 班
  • on-call 满意度问卷（季度做一次）

反模式

  • "我们没专职 SRE，开发自己看着办"：开发 + on-call 不区分时段时长 → 烧人
  • 告警群进 200 条/天，没人看：见告警章节
  • PagerDuty 设了但没人配 escalation：Primary 失联 → 故障扩大
  • 小团队半夜的电话默认全公司轮：不看技能匹配 → 接到也搞不定

推荐阅读

下一篇：故障真发生后——blameless post-mortem。