Skip to content
返回运维与 SRE

值班轮换

在团队中公平排值班班，含 follow-the-sun、交接和补偿策略。

为什么

值班是对付它的工程师的税 — 他们睡更浅、不能喝酒、page 时硬上下文切换。把税倒在一个人或一个时区的轮换滋生倦怠和流失，且"这告警怎么处理"的机构知识集中在一个人头而非全队扩散。公平轮换（4-6 工程师、1 周班、可能时 follow-the-sun）使任一工程师值班 <25% 时间，给每人运维肌肉记忆使团队韧性，并在值班者非系统作者时暴露文档缺口。跳过轮换的团队最终有单一"ops 人"成为 bus factor 一。

何时使用

当服务到生产需 24/7 覆盖时。团队规模变 >2 人时重平衡。

如何做

1. 按团队规模排轮换
   - 24/7 SEV1 覆盖需 ≥4 工程师（1 周班 = 每人约 25% 值班负载）
   - <4 工程师 → 别承诺 24/7；设工作时间 SLA
   - 每工程师应值班 ≤1 周/4 周

2. 选班形
   - 单队单时区：1 周主 + 1 周副（副处理溢出）
   - 多时区：follow-the-sun — 每时区处理自己白天，无夜 page
   - 文档化交接："主把未决事件 + 已知问题传给下个主"

3. 补偿并保护值班工程师
   - 付值班津贴或调休；明确承认这税
   - 值班周无大功能截止；保护其专注
   - 班后复盘：被 page >5 次？→ 告警疲劳，修告警

4. 副也轮换
   - 副是升级目标；他们也须新鲜
   - 别把主+副配同一功能团队（单点知识）

5. 排班可见且自动化
   - PagerDuty/Opsgenie 排班，导出全队可见日历
   - 别经 DM 手动换班 — 用工具换班功能使排班保持唯一真相

示例

# PagerDuty 排班 — 1 周主轮换，4 工程师
resource "pagerduty_schedule" "payments_primary" {
  name = "payments-primary"
  time_zone = "America/New_York"
  layer {
    name = "weekly-rotation"
    start = "2026-01-04T00:00:00Z"  # 周一
    rotation_turn_length_seconds = 604800  # 1 周
    users = [  # 4 工程师，周轮换
      pagerduty_user.alice.id, pagerduty_user.bob.id,
      pagerduty_user.carol.id, pagerduty_user.dan.id,
    ]
  }
}
# 每工程师：值班 1 周/4 周 = 25% 负载
# 交接文档（周一 9 点）：主审查未决事件，在 #payments 发：
#   "从 @alice 接手。未决：INC-123（DB 故障转移进行中）。无已知问题。"
# 策略：值班周无功能截止；每班 $X 津贴

常见问题

  • ⚠单一"ops 人"持轮换 — 他们倦怠、成 bus factor 一，离开时团队失韧性。
  • ⚠值班无补偿或调休 — 工程师怨恨无付税并悄悄停志愿，轮换崩塌。
  • ⚠主和副来自同一功能团队 — 两者共享盲点和发布计划，破坏升级目的。
  • ⚠经 DM 手动换班不更新 paging 系统 — 排班说 Alice 主但 Bob 换了；SEV1 page 度假的 Alice。

最佳实践

  • ✓24/7 覆盖要求 ≥4 工程师使无人值班 >25% 时间；低于此设工作时间 SLA 而非假装 24/7。
  • ✓明确补偿值班（津贴或调休）并保护值班周无功能截止 — 税是真的而倦怠很贵。
  • ✓独立轮换主和副且绝不配同一功能团队 — 升级须到不同知识库。
  • ✓排班做成全队可见日历，换班经 paging 工具使排班永远唯一真相。