3. On-Call 机制概述：轮值模型、职责边界与变更窗口关联
On-Call 机制是 SRE 体系中最直接的“救火”环节，但若缺乏结构化设计，容易陷入“全员疲劳、响应混乱、变更与故障脱节”的困境。本节从轮值模型、职责边界、变更窗口三个维度拆解 On-Call 机制的核心设计原则。
3.1 On-Call 轮值模型
轮值模型决定了告警响应的人力覆盖方式与疲劳度分布。常见模型对比如下：
| 模型 | 轮值周期 | 适用规模 | 优点 | 缺点 |
|---|---|---|---|---|
| 主备模型 | 7×24 小时 | 小型团队（3-5人） | 责任清晰，切换成本低 | 单点疲劳，备岗易生疏 |
| 轮转模型 | 1周/2周 | 中型团队（6-12人） | 疲劳均摊，技能覆盖广 | 交接成本高，上下文丢失 |
| 分层模型 | L1/L2 分层 | 大型团队（12人+） | 过滤低级别告警，专家聚焦复杂问题 | 层级延迟，L1 能力要求高 |
| 随叫随到模型 | 事件驱动 | 极小型团队或创业期 | 灵活性高，无固定排班 | 响应不可控，易 burnout |
关键指标： 轮值周期建议不超过 7 天，连续 On-Call 后至少安排 2 天“无告警恢复期”，以降低认知疲劳和误操作风险。
3.2 On-Call 职责边界
职责边界模糊是 On-Call 效率低下的首要原因。必须明确 On-Call 工程师的“该做什么”与“不该做什么”：
- 核心职责：
- 接收并确认告警（SLA 内响应）
- 执行标准操作流程（SOP）进行故障诊断与恢复
- 升级无法处理的复杂问题至 L2/L3 专家
- 记录事件时间线、操作步骤与根因初步分析
- 非职责：
- 在 On-Call 期间进行非紧急的代码开发或架构变更
- 独自处理未文档化的“黑盒”问题（必须升级）
- 承担跨团队协调（应由值班经理或 Incident Commander 负责）
最佳实践： 为每个 On-Call 角色编写“职责清单”（Responsibility Matrix），贴在值班手册首页，并在每次轮值交接时逐条确认。
3.3 On-Call 与变更窗口的关联
变更窗口是 On-Call 告警的“放大器”。统计表明，60%-70% 的 P0/P1 故障与近期变更直接相关。因此，On-Call 机制必须与变更窗口深度绑定：
- 变更前： On-Call 工程师需知晓当日变更窗口计划，提前检查变更涉及系统的监控与告警阈值。
- 变更中： 变更窗口期间，On-Call 应处于“高戒备”状态，缩短响应时间（例如从 15 分钟降至 5 分钟）。
- 变更后： 变更窗口关闭后 1 小时内，On-Call 需确认系统指标回归基线，并记录变更引入的异常事件。
下图展示了变更窗口与 On-Call 响应状态的协同关系：
3.4 变更窗口与 On-Call 的关联矩阵
在实际运营中，变更窗口与 On-Call 的关联可通过以下矩阵进行量化管理：
| 变更类型 | 窗口时段 | On-Call 响应要求 | 事后确认动作 |
|---|---|---|---|
| 常规发布 | 工作日 14:00-16:00 | 5 分钟内响应，10 分钟内介入 | 窗口关闭后 30 分钟指标快照 |
| 紧急热修复 | 任意时段 | 立即响应，2 分钟内介入 | 修复后 1 小时持续监控 |
| 基础设施变更 | 凌晨 02:00-04:00 | 10 分钟内响应，20 分钟内介入 | 次日早 8 点全量指标复核 |
| 配置变更 | 随窗口 | 15 分钟内响应，30 分钟内介入 | 变更后 15 分钟配置校验 |
常见陷阱： 变更窗口期间 On-Call 工程师同时承担变更执行角色。这会导致“自己变更、自己监控、自己恢复”的闭环盲区，建议变更执行与 On-Call 监控角色分离。