2. On-Call 交接概述

On-Call 交接是指当一线值班工程师（Primary）或二线值班工程师（Secondary）的轮值周期结束时，将当前未解决的告警、进行中的故障、待办事项以及上下文信息，完整、准确地传递给下一班次工程师的过程。它不仅是“交钥匙”，更是“交上下文”。

2.1 什么是 On-Call 交接

On-Call 交接的核心是信息与责任的转移。一个标准的交接流程通常包含以下要素：

• 未关闭告警清单：当前仍处于触发状态、尚未恢复或尚未确认的告警。
• 进行中事件：正在处理的故障、变更或问题，包括当前状态、已执行操作、待执行操作。
• 上下文信息：告警的根因分析、临时规避措施、相关工单链接、沟通记录。
• 待办事项：需要下一班次继续跟进的任务，如“观察某指标趋势”、“联系某团队确认”、“执行回滚操作”。
• 值班工具状态：监控系统、告警平台、协作工具（如 Slack、钉钉）的当前配置或静默规则。

2.2 交接的重要性

在 7×24 小时运维体系中，On-Call 交接是保障服务连续性的关键环节。其重要性体现在以下三个维度：

一个高质量的交接，能让下一班次工程师在 5 分钟内掌握全局，而不是花 30 分钟重新翻看告警历史。

2.3 交接失败导致的典型事故案例

以下三个真实案例，均因 On-Call 交接环节出现严重缺陷，最终导致重大服务中断或数据损失。

案例一：静默窗口未交接，导致关键告警被忽略

• 背景：A 工程师在值班期间，因数据库主从延迟触发告警，他手动创建了一个 2 小时的静默窗口，计划等业务低峰期再处理。
• 交接过程：A 工程师在交接时口头提了一句“数据库有点延迟，我设了个静默”，但未在交接文档中记录静默窗口的结束时间和具体告警规则。
• 结果：B 工程师接班后，静默窗口自动关闭，数据库延迟告警再次触发。B 工程师认为这是新告警，未与 A 确认，直接按常规流程重启数据库，导致主库数据丢失，服务中断 45 分钟。
• 根因：静默窗口的创建、原因、结束时间未作为交接项传递。

案例二：进行中事件未交接，导致重复操作

• 背景：C 工程师正在处理一个缓存集群的故障，已执行了部分节点重启，并正在等待监控数据恢复。
• 交接过程：C 工程师因临时会议，仅通过即时消息发送了一句“缓存有问题，我在处理”，未说明已执行的操作和当前状态。
• 结果：D 工程师接班后，看到缓存告警仍在，认为 C 未开始处理，于是重新执行了全部节点的重启操作，导致缓存雪崩，核心 API 响应超时，影响线上交易。
• 根因：进行中事件的状态和已执行操作未结构化记录。

案例三：上下文信息缺失，导致误判根因

• 背景：E 工程师在值班期间发现某微服务错误率升高，经排查确认是上游依赖的配置变更导致，已联系上游团队回滚。
• 交接过程：E 工程师在交接文档中只写了“错误率告警已处理”，未记录根因分析结果和上游变更的关联。
• 结果：F 工程师接班后，错误率再次短暂升高（上游回滚生效中），F 工程师误判为自身服务代码问题，紧急回滚了正常版本，导致功能不可用 2 小时。
• 根因：根因分析结果和关联变更信息未传递。

2.4 交接的核心要素清单

为避免上述事故，一个完整的 On-Call 交接应包含以下清单项。建议团队使用标准化模板或交接工具进行记录。