1. On-Call 文化概述
1.1 什么是 On-Call
On-Call（值班）是指工程师在非工作时间或轮值周期内，承担系统稳定性保障的第一响应职责。当监控告警触发、用户报障或系统出现异常时，On-Call 工程师需要在约定的响应时间内介入，执行故障排查、止损恢复或升级处理。
On-Call 不是简单的“接电话”或“看告警”，而是一套包含值班排班、告警分派、响应 SLA、升级策略、事后复盘在内的完整工程实践。它要求组织在人员、工具、流程三个维度同时具备成熟度。
关键认知： On-Call 不是惩罚，而是系统复杂性与业务连续性之间的必然缓冲层。优秀的 On-Call 文化能显著降低事故平均恢复时间（MTTR），并反向驱动系统韧性的提升。
1.2 On-Call 的核心目标
On-Call 体系围绕三个核心目标展开，这些目标直接对应 SRE 的经典指标：
| 目标维度 | 核心指标 | 说明 |
|---|---|---|
| 快速发现 | MTTD（Mean Time to Detect） | 从故障发生到被 On-Call 工程师确认的时间。依赖告警覆盖率、告警准确率和通知渠道可达性。 |
| 快速恢复 | MTTR（Mean Time to Resolve） | 从确认故障到服务恢复正常的时间。依赖 Runbook 完备度、变更回滚能力和工程师的领域知识。 |
| 减少影响 | 故障影响范围 / 用户感知时长 | 通过熔断、降级、限流等手段缩小爆炸半径，避免单点故障扩散为大规模中断。 |
实践建议： 在 On-Call 值班体系中，MTTR 是最常被关注的指标，但 MTTD 的优化往往能带来更显著的效率提升——每提前 1 分钟发现故障，可能减少 10 分钟的恢复时间。
1.3 On-Call 与事故响应的关系
On-Call 和事故响应（Incident Response）是两个紧密关联但层次不同的概念。下表梳理了它们的核心差异与衔接关系：
| 维度 | On-Call（值班） | 事故响应（Incident Response） |
|---|---|---|
| 触发条件 | 按排班周期轮值，持续监控告警 | 由 On-Call 工程师评估后升级，或由重大故障直接触发 |
| 参与角色 | 通常 1-2 名值班工程师 | 事故指挥官、联络人、执行人、SRE 团队、相关业务方 |
| 时间窗口 | 值班周期内持续覆盖（如 7×24 轮换） | 从事故宣布到解除的有限时间段 |
| 主要动作 | 告警确认、初步排查、快速止损、按需升级 | 正式宣布事故、启动指挥体系、协调资源、执行恢复、事后复盘 |
| 输出产物 | 值班日志、告警处理记录、升级工单 | 事故时间线、根因分析（RCA）、行动项（Action Items） |
两者的关系可以概括为：On-Call 是事故响应的第一道防线，事故响应是 On-Call 的升级通道。高效的 On-Call 体系能够在事故正式宣布之前完成止损，从而避免进入完整的事故响应流程；而当故障超出值班工程师的处理能力或影响范围时，On-Call 负责及时触发升级，将控制权移交给事故响应团队。
常见误区： 不要把 On-Call 等同于事故响应。On-Call 强调“值班覆盖”和“快速止损”，事故响应强调“正式流程”和“多角色协作”。混淆两者会导致值班工程师负担过重、事故响应流程被滥用、复盘质量下降。
1.4 On-Call 与事故响应的协作流程
下图展示了从告警触发到事故解除的完整协作链路，清晰标出 On-Call 与事故响应的职责边界：
1.5 高效 On-Call 文化的关键要素
建立健康的 On-Call 文化需要组织在以下方面持续投入：
- 清晰的排班与轮换机制：避免单点疲劳，确保知识传递和备份覆盖。
- 完善的 Runbook 与自动化：将常见故障的处理步骤文档化、自动化，降低值班工程师的认知负荷。
- 合理的告警治理：减少告警风暴，确保每条告警都 actionable，避免“狼来了”效应。
- 事后无指责复盘：聚焦系统改进而非追责，鼓励工程师坦诚分享故障细节。
- 值班补偿与认可：通过轮值补贴、调休、绩效认可等方式体现对值班工程师付出的尊重。