S17-A12 · 值班制度的组织设计：轮值、升级与交接

值班表排得很公平：八个人，每人一周。真实场景却是——凌晨两点的磁盘告警落在一个入职三个月的新人头上，他打开面板看不出所以然，群里发一条消息，没人回，等主管上班，故障已持续六小时。

**排班公平和值班有效是两件不相关的事。**前者是日历问题，后者是一组组织约定：谁在什么时候有什么权力、何时必须叫人、交班交什么。

1. 值班制度要回答的三个问题

问题	必须写清的东西	缺失后的表现
谁响应	覆盖窗口、备班人、缺席替代规则	@所有人无人认领，告警在频道里过夜
谁有权处置	可独立执行清单、需确认清单	只能看不能动，等主管醒来才回滚
什么时候必须叫人	时间阈值、判定条件、升级对象	一个人硬扛到天亮，或小事拉十个人

第三条几乎总是最先缺失，因为它要求提前决定"到什么程度算我处理不了"，而人天然倾向于再等五分钟。

"谁有权"要单列，因为多数制度的瓶颈不在覆盖率而在授权：半夜发现是某次配置变更导致，值班人有没有权力直接回滚？没有的话，值班就退化成报信岗位，响应时长再好看也没意义。

授权矩阵（占位，按自身风险等级填写）

动作                        可独立执行   需二线确认   仅变更发起人
─────────────────────────────────────────────────────────────
回滚到上一版本                    ✓
重启无状态单实例                  ✓
重启有状态节点                               ✓

这张表的价值在于逼人承认：哪些动作平时说得轻松，真出事时没人敢签。

2. 轮值的三种形态与组织前提

形态	成立前提	主要代价	常见失效
全员轮	≥6 人、系统面单一、告警密度低	反复重建上下文，交接损耗大	不熟的人被排进去，"轮"变抽签
专职值班	有独立平台/SRE 组、面广、告警密	一线离业务变远，判断依赖文档	专职者成唯一会修的人，知识垄断
分层值班	规模大、领域划分清晰	每次升级都有转述损耗	一线退化成转发岗，永不一定位

判据很直接：如果团队里一半人无法在十分钟内判断一条告警是否紧急，全员轮就已经不成立，此时该考虑分层，而不是继续教育。

轮值周期也有量级感：一周一换的交接成本明显低于一天一换，每人每月夜班通常控制在个位数（典型量级 3–6 晚，按自身告警分布校准）。轮值必须与发布窗口错开——让当晚值班的人同时负责发布，等于取消两道防线中的一道。

─── 轮值表片段（占位）：主班 + 备班，备班不排发布任务
rotation:
  period: 1w
  primary:   [ROLE_A, ROLE_B, ROLE_C]
  secondary: [ROLE_D, ROLE_E, ROLE_F]     // 主班 30min 未响应时接管
  blackout:  "每周三 18:00-21:00"          // 发布窗口，不排新班

没有备班的全员轮，覆盖率取决于那人当晚是否恰好手机有信号。

3. 告警质量决定值班是否可承受

**每班次负担 = 告警条数 × 单条处理成本。**加人只能摊薄前一项，摊不掉后一项；后一项由告警质量决定，不由值班人决定。

指标	口径	判断方式
每班次告警数	去重后落在班次内	超过"能逐条看完"的量级即过载
无效告警率	无需人工动作的占比	高于三成说明噪声主导，值班变扫雷
归属明确率	告警自带 owner 的比例	决定它是被修掉还是被忽略

硬规则：**谁的服务产生告警，谁负责让这条告警可行动。**把降噪责任交给值班人，是组织上最省事也最无效的安排——值班人只有权处理，没有权改别人的阈值。

4. 升级路径：阈值、判定与对象

要素	合格写法	反面写法
时间阈值	15min 未定位 → 二线；45min 未缓解 → 主管	"视情况而定"
判定条件	满足其一即升：影响用户、影响收入、无已知回滚路径	"觉得严重就叫"
升级对象	明确到角色 + 联系方式 + 备份人	只写"找老张"

─── 升级策略（占位）：条件与阈值都要可判定
escalation:
  - after: 15m
    when: "未定位 或 用户侧错误率 > 阈值"
    to:   ROLE_TIER2
  - after: 45m
    when: "未缓解 或 已确认需回滚"
    to:   [ROLE_OWNER, ROLE_COMMS]
    action: "同步对外口径，暂停同窗口其他变更"

**"不敢升级"是制度问题，不是性格问题。**成因通常三条：升级曾在事后被评价为"过度反应"；升级后问题回到自己头上没人接；升级意味着半夜承认搞不定。都能靠设计消掉——把升级写成标准动作、要求接手人给出下一步而非评价、复盘只讨论判据不讨论"谁该更早叫"。

5. 交接的必备内容

交接不是"这周没啥事"。四项缺一项，下一班就会重新踩一遍已知的坑。

必交项	具体到什么程度	漏掉的后果
未闭环事件	现象、已做动作、当前状态、谁在跟	重新排查，或误判为已恢复
已知风险	哪块带病运行、还能撑多久	换班后爆发，无人有预期
临时绕过	绕过了什么、什么条件下必须撤销	被遗忘，三个月后变成"架构"
待观察项	观察哪个指标、到什么值要动手	观察项随人走，指标恶化无人知

交接记录模板（占位）

班次: 2026-11-02 10:00 → 11-09 10:00   主班: ROLE_A   备班: ROLE_D
───
未闭环: INC-2311 订单导出偶发 500，已加日志，等复现；跟进人 ROLE_B
已知风险: 搜索集群少一个副本，重建预计 11-12 完成；P99 上浮可接受
临时绕过: 关闭图片压缩（CPU 打满时的手动开关）；回落至基线后必须打开
待观察: DB 连接池 active 长期 > 70% 即异常，当前 62%

交接口头化等于没交接；跨区交接还要额外吃掉一小时上下文重建。

6. 补偿机制与它的实际作用

补偿方式	实际作用	局限
调休	补回工时，让夜班可持续	忙时调不了，等于欠账
轮空	下一轮免排，恢复公平感	造成覆盖缺口，需备班兜住
津贴	明确"这是工作不是奉献"	提不了值班质量，治不了噪声

补偿的作用是维持制度可持续，不是提高值班质量：真正的成本是夜间响应后的次日产能，把它算进排期比发津贴更接近真实。

7. 手册写到什么程度、新人什么时候能上

验收标准只有一条：**一个没参与过该系统建设的人，凌晨三点、只读文档、不看代码，能按步骤把服务恢复可用。**写不到这个程度的手册是给人看的，不是给值班用的。

on-call 手册骨架（每个告警一条入口）

告警: APIErrorRateHigh
───
1. 确认影响面：错误率曲线 / 受影响接口 top3 / 是否影响写入
2. 判断是否与本班次变更相关：看发布与变更时间轴
3. 可独立执行：回滚上一版本 → 观察 3 分钟 → 未恢复则第 4 步
4. 升级 ROLE_TIER2，附上 1-3 步结论与已排除项
禁止: 直接改库、直接重启有状态节点（走第 4 步）

新人上值班的前置条件写成可核查清单，而不是"跟几次就会了"：独立处理过一次演练故障、能读懂三个核心面板、知道升级对象并真打通过一次、完成过一次交接。没做过演练就上真班，等于把生产当教学环境。

"谁值班谁改"的边界划在临时止血与根因修复之间：值班人有权做可逆止血，不承担根因修复的排期。把根因压给值班人，结果是所有人都在打紧急补丁，没人做结构性修复；而止血不留记录，根因就永远失去线索。

8. 度量：五个能改变决策的数

指标	口径	用来决定什么
每班次告警数	去重、按班次聚合	是否做降噪专项，而不是加人
无效告警率	无人工动作的占比	归哪个服务整改
响应时长	告警到有人接手	覆盖窗口与备班是否有效
升级率	每百次事件中升级次数	过低不敢升，过高说明授权不足
值班满意度	匿名、按班次不按人	制度是否已到该重做的程度

升级率没有"健康值"，只有解释：极低而响应时长很长，指向"不敢升级"；极高而一线几乎不动作，指向"授权缺失"。

9. 排错：制度失效的五种现场

现象	真实成因	处理方向
告警在频道过夜	覆盖窗口有洞，备班形同虚设	先补覆盖，再谈响应时长
值班人只报信不动手	授权矩阵缺失或从未被评审	与变更分级一起列出可执行动作
换班后问题重新排查	交接只留口头的"没啥事"	固定交接四项并在线交接
老人不愿值班	夜间响应未计入排期	把次日产能损失纳入排期，而非只发津贴

10. 边界：什么时候正式值班制度是过度设计

场景	为什么不该上	更合适的做法
极少告警（典型量级：每周个位数且无夜间）	值班成本高于故障实际损失	共担频道 + 明确第一响应人
团队小于三人	轮值必然覆盖不全，制度只是自我安慰	约定响应时段，接受非响应期更长恢复
告警已全部自动处置	人工值班只增加确认动作	保留异常汇总与每日巡检
无外部用户（内部工具、离线批处理）	故障影响有天然缓冲窗口	工作时间响应 + 次日处理

判断口径：当"没人值班"的实际损失小于"维持值班"的组织成本时，就不该有值班表。

11. 自测

值班表排得公平，为什么仍然会出现"每次告警都是一个人扛"？
授权矩阵缺失时，值班制度实际退化成了什么岗位？
团队里一半人无法在十分钟内判断告警紧急程度，说明哪种轮值形态的前提不成立？
升级率极低且响应时长很长，最可能指向哪种组织成因？
交接里"临时绕过"漏掉，三个月后通常以什么形式出现？
什么条件下，"没有值班表"比"有值班表"更正确？