第5章值班

运维值班的科学与艺术

章节导读

值班（on-call）是 SRE 工作中最特殊的一部分：它把软件工程师推到生产系统的第一线，在深夜、在周末、在假期中，独自面对系统的故障与不确定性。值班做得好，它是工程师成长最快的途径——没有什么比真实故障更能教会你系统的行为；值班做得差，它是团队士气的第一杀手——持续的睡眠剥夺、无休止的告警轰炸、缺乏支持的孤军奋战，会让最优秀的工程师选择离开。蓝皮书第 5 章用整整一章的篇幅讨论值班的「科学与艺术」，因为 Google 在二十年实践中深刻认识到：值班不是排个表那么简单，它涉及心理学、组织设计、量化管理和工程自动化的交叉。先说心理学维度。人在压力下的决策质量会显著下降：认知隧道效应（tunnel vision）让工程师只盯着眼前的一个指标而忽略全局；疲劳状态下，工作记忆容量缩小，多步骤操作容易遗漏；深夜被叫醒后的判断力相当于血液酒精浓度超标状态——这不是比喻，睡眠科学研究显示连续清醒 17 小时的认知损伤约等于 0.05% 的血醇浓度。理解这些生理限制，才能设计出「不依赖英雄主义」的值班体系：告警要少而准（减少无效唤醒）、操作要简单（一键回滚优于十步手工操作）、文档要清晰（runbook 在凌晨三点必须能被半睡半醒的人看懂）、升级要顺畅（15 分钟无进展就拉人，不鼓励硬扛）。Google 对值班的量化管理围绕一个核心概念：操作负载（operational load）。操作负载是值班期间所有工作的总和：响应告警、处理工单、执行发布、回答咨询、处理例行任务。Google 用「每次值班事件消耗的时间」和「值班期间的总事件数」来度量负载，并设定了明确的上限：一个健康的值班轮换中，值班工程师每班处理的事件不应超过 2 起紧急事件；如果持续超标，说明系统可靠性或告警体系有问题，必须投入工程资源解决，而不是让值班硬扛。操作负载的度量让「值班太累」从主观抱怨变成了客观数据，为「加人、减负、还是修系统」的决策提供了依据。值班补偿是另一个绕不开的话题。Google 的立场明确：值班应该获得补偿，形式可以是值班津贴、调休时间或两者结合。补偿的意义不仅是公平——它更是一个信号机制：公司承认值班是真实的工作负担，而不是「工程师分内之事」的道德绑架。没有补偿的值班制度会悄悄筛选出两类人：不敢拒绝的新人和准备离职的人，两者都不是可持续的值班力量。补偿的量化可以参考：值班期间被叫醒一次的成本（睡眠中断 + 第二天效率损失）大约相当于半天工作时间，据此计算津贴标准。当然，最好的补偿是让值班不需要被叫醒——这就是为什么告警治理（第 4 章）和自动化（本章后面讨论）是对值班团队最大的福利。值班团队的设计有若干硬性约束。规模：至少 8 人，保证每人每月值班不超过一周（值一周休三周的节奏）；如果只有 4 个人，每人每月值两周，疲劳累积会迅速摧毁团队。轮换频率：周轮换优于日轮换——交接有成本，频繁交接导致信息丢失和责任模糊；但也不宜超过两周，过长的值班期让工程师长期处于待命压力。交接流程：结构化交接是值班质量的关键，交接内容应包括：进行中的问题、近期变更计划、已知的风险点、上一班的事故摘要。Google 的许多团队用固定的交接会议（15 分钟）加交接文档模板来保证信息不丢失。值班手册（playbook）是值班工程师的武器库。一份好的 playbook 不是系统文档的复制，而是「以行动为导向」的处置指南：每条告警对应什么处置步骤、常见故障的诊断决策树、升级路径和联系人、危险操作的检查清单。playbook 的编写原则是「为凌晨三点的自己而写」：假设读者睡眠不足、压力很大、记不住细节，每一步都要具体到命令和链接。playbook 必须活维护：每次事故复盘后更新对应条目，每季度验证一次（让新人照着 playbook 处理模拟故障，卡住的地方就是要改进的地方）。值班期间的决策框架同样重要。什么时候升级（escalate）？Google 的建议是「15 分钟规则」：尝试 15 分钟没有明确进展就升级，拉入更多人手。硬扛不是敬业，是风险——事故的影响随时间累积，早升级早控制。什么时候回滚？如果故障发生在变更后 30 分钟内，默认动作是回滚而不是排查——先止血再验尸。什么时候求助？任何时候。值班文化中最有毒的观念是「求助显得无能」，Google 用无指责文化对抗这一点：升级和求助是被鼓励的行为，事后分析只关注系统改进不追究个人。无指责事后分析（blameless postmortem）是值班体系的闭环机制。每次重大事故后，团队撰写事后分析文档：时间线（精确到分钟）、影响范围、根因分析（用五个为什么深挖）、行动项（可执行、有负责人、有期限）。无指责的含义是：文档中不出现「某某犯了错」的表述，而聚焦「什么样的系统让这种错误可能发生」。这不是和稀泥——无指责的前提是所有人都诚实还原事实，如果分析变成追责大会，人们就会隐瞒细节，组织就失去了学习机会。Google 的事后分析文化甚至发展出「事后分析俱乐部」：定期分享最有教育意义的事故报告，把个体团队的教训变成全组织的知识。最后是值班的自动化。值班的终极目标是「无人值班」——不是取消值班，而是让值班期间需要人做的事情越来越少。自动化的优先级：自动诊断（告警触发时自动收集相关日志、指标、最近变更，附在告警通知里）；自动修复（已知问题的标准处置脚本化，值班一键执行甚至全自动执行）；自动升级（值班未确认自动转备份，备份未确认自动转团队负责人）；自动缓解（检测到过载自动限流、检测到实例异常自动隔离）。每一项自动化都直接减少操作负载，让值班从「救火队员」变成「监督自动化系统的人」。本章的案例部分将展示 Google 值班文化二十年的演进：从早期的英雄式救火，到量化管理的现代值班体系。接下来的要点将深入每个主题的细节。

核心概念

操作负载
值班手册
无指责事后分析
值班补偿

要点精析

值班的心理学：压力、疲劳与决策质量。值班工程师的工作状态有一个残酷的特点：大部分时间无事发生，但必须在几秒内从深度休息切换到高度专注，并且在信息不完整、时间紧迫的条件下做出影响巨大的决策。这种「平时闲置、瞬间高压」的模式对人的心理和生理都有独特损耗。睡眠科学的研究表明：夜间被叫醒后，人的反应时间延长 30% 到 50%，工作记忆容量显著下降，复杂推理能力受损最严重——而事故处置恰恰需要复杂推理（在多个可能根因中判断、权衡处置方案的风险）。连续值班多天后，疲劳会累积，即使白天补觉也无法完全恢复认知功能。压力心理学还有一个重要发现：高压下的人会出现「认知隧道」——注意力收窄到最显眼的信号上，忽略周边信息。事故中常见的「盯着一个错误指标排查半小时」就是认知隧道的表现。基于这些科学事实，Google 的值班设计遵循「降低认知需求」原则：告警通知自带上下文（当前指标值、最近变更、相关仪表盘链接），让值班不用从零开始收集信息；runbook 提供决策树而不是开放式排查指南，把「自由推理」转化为「按图索骥」；15 分钟升级规则承认个人判断的局限，用团队智慧兜底；重大事故自动拉起战争房间（war room），让值班从「独自决策」变成「团队协作」。心理安全同样关键：如果值班工程师害怕犯错被追责，他会倾向于保守和不作为（不敢回滚、不敢升级、不敢执行有风险但正确的操作），这比犯错本身危害更大。Google 的无指责文化明确传递一个信息：在信息不完整时做出合理判断，即使事后证明是错的，也不会被追责；会被复盘的是「为什么系统让错误决策变得可能」，而不是「谁做了错误决策」。值班补偿的心理学意义也在于此：补偿不仅是钱，更是组织对值班负担的正式承认，它把值班从「无偿的义务」变成「有对价的职责」，显著改善值班者的心理契约。

值班的量化管理：操作负载的度量与上限。Google 把值班负担定义为「操作负载」（operational load），并建立了完整的度量体系。操作负载的组成：紧急事件响应（告警触发后的诊断与处置）、工单处理（非紧急但需要人工的任务）、例行操作（发布审批、权限变更、数据修复）、咨询答疑（回答其他团队的问题）。度量方法：每类负载记录「事件数 × 平均处理时长」，汇总为每班次的总负载小时数。健康标准：Google 的经验值是值班工程师每班（12 小时）的操作负载不应超过 6 小时（50% 红线），其中紧急事件不超过 2 起；夜间被叫醒不超过 1 次。超标处理机制是量化的关键：负载超标不是「这周运气不好」，而是系统发出的明确信号——要么服务可靠性不足（故障太多），要么告警体系有问题（误报太多），要么自动化缺失（例行操作太多）。Google 的做法是把操作负载数据纳入团队季度评审：连续超标的服务必须立项改进，改进方向按负载构成分析确定（紧急事件多 → 修可靠性；工单多 → 做自动化；咨询多 → 补文档和自助工具）。操作负载度量还有一个组织层面的用途：公平性。当 SRE 团队支持多个服务时，负载数据揭示哪些服务「省心」哪些服务「费人」，为资源分配和接管决策提供依据——一个操作负载是别的服务十倍的产品，要么投入改造，要么 SRE 退出支持。度量的实施细节：不要依赖值班手工记录（疲劳时没人愿意填表），尽量从告警系统、工单系统自动采集；手工部分简化为每次事件结束时一键打标（事件类型、耗时区间、是否导致行动）。数据不需要精确到分钟，量级正确就足以驱动决策。

值班团队的设计：规模、轮换与交接。值班团队设计有三个硬约束和一套最佳实践。硬约束一：轮换规模至少 8 人。数学很简单：周轮换制下，8 人团队每人每 8 周值 1 周班，即每月约 3.75 天，处于健康区间；4 人团队每人每月值 7.5 天以上，疲劳累积不可持续。凑不齐 8 人的解法按优先级：与相邻团队合并值班池（共享轮换但各自保留专业升级路径）、降低值班强度（夜间仅响应 P1、P2 以下次日处理）、用自动化削减负载后重新评估。硬约束二：主备双人制。每个班次至少两人：主值班（primary）负责响应，备份值班（secondary）在主值班 15 分钟未确认时自动接管，同时作为复杂问题的第二大脑。单人值班的风险不仅是「睡着了没人兜底」，还有「独自决策无人挑战」——事故中第二双眼睛的价值巨大。硬约束三：结构化交接。交接是值班体系最脆弱的环节，信息在交接中丢失是事故的常见诱因（「上一班知道这个告警是误报但没告诉下一班」）。最佳实践：固定交接时间（周一上午 10 点，避开周五和深夜）、交接会议（15 分钟，议程固定）、交接文档（模板化：进行中问题、未来 48 小时变更、已知风险、经验提示）、交接确认（接班人复述关键事项）。轮换周期的选择：周轮换是主流（交接成本低、责任边界清晰）；日轮换只适合负载极低的团队；双周轮换让单次值班压力期拉长，一般不推荐。排班的公平性管理：统计每人累计值班天数和夜间唤醒次数，节假日值班轮流承担，值班偏好（有人愿意多值换调休）在系统里显式管理。最后，值班资格有门槛：新成员必须完成影子值班（跟随资深值班 2 到 4 周）、通过模拟事故演练、熟悉全部 runbook 后才能独立值班——让新人直接扛值班是对用户和对新人的双重不负责任。

值班手册（playbook）：如何编写有效的操作文档。Playbook 是值班工程师的作战手册，其质量标准只有一个：凌晨三点、睡眠不足、压力巨大的工程师能否照着它正确行动。这个标准决定了 playbook 的写法与常规技术文档截然不同。结构上，playbook 以「告警」为索引组织：每条紧急告警对应一个条目，因为值班的入口永远是告警。每个条目的固定结构：症状（这条告警长什么样、用户会报告什么）→ 快速确认（一步操作确认问题真实存在，附命令或仪表盘链接）→ 决策树（如果指标 A 异常走分支 X，如果指标 B 异常走分支 Y）→ 处置步骤（精确到可复制粘贴的命令，危险操作用醒目格式标注前置检查）→ 升级条件（明确写出「尝试 15 分钟无进展 → 拉入 XX 团队」「涉及数据丢失 → 立即升级」）→ 恢复验证（如何确认服务已恢复正常，避免「处置完了但其实没好」）。写作原则：每步一行、动词开头、避免解释性长文（原理放在链接的深层文档里，playbook 只保留行动）；所有链接必须是持久链接（不要用会过期的临时仪表盘 URL）；命令必须包含具体的服务名和参数占位符说明。维护机制：playbook 的腐烂速度惊人——服务重构、工具更换、架构调整都会让步骤失效。对策有三：事故复盘强制检查项「本次处置用到的 playbook 条目是否准确？不准确立即修订」；每季度 playbook 验证日（新人照条目处理模拟故障，记录卡点）；每条条目带「最近验证时间」元数据，超过 6 个月自动标记待验证。Google 的经验数据：维护良好的 playbook 能把平均故障恢复时间缩短 40% 以上，因为它把「每次从零推理」变成了「执行已验证的方案」，同时大幅降低了值班的认知门槛——有 playbook 兜底，经验较浅的工程师也能处理大部分常见故障。

无指责事后分析：从事故中学习的系统方法。事后分析（postmortem）是值班体系的闭环：事故不只是被处置，还要被理解、被转化为系统改进。Google 的事后分析制度有几个关键设计。触发标准明确化：不是所有事故都写事后分析，触发条件事先约定——用户可见的宕机超过阈值时长、数据丢失（任何规模）、值班工程师被升级拉入的事故、错误预算单日消耗超过 5% 的事件。明确标准避免了「大事化小不写报告」的操作空间。时间线精确到分钟：从第一个异常信号（往往早于告警）到完全恢复，每个关键节点记录时间和动作。时间线常揭示惊人事实：故障 14:02 开始，告警 14:35 才触发（告警体系问题），值班 14:41 开始排查但方向错误（runbook 问题），15:19 才回滚（升级机制问题）——一次事故暴露三层系统缺陷。根因分析用「五个为什么」但不止于技术根因：为什么配置变更没有灰度？因为发布系统不支持配置灰度。为什么不支持？因为立项时优先级低。为什么优先级低？因为没人量化过配置变更的风险。技术根因背后往往是流程和决策根因。行动项的纪律：每条行动项必须具体（「接入灰度」不够，「配置变更接入 XX 灰度系统，负责人 A，期限 X 月 X 日」才够）、有负责人、有期限，并且被跟踪到关闭。Google 的数据显示事后分析行动项的完成率与事故复发率强相关——写了报告不落实行动的组织会重复同样的事故。无指责的执行细节：文档中用「变更被执行」而非「张三执行了变更」的被动语态描述人为动作；评审会上禁止「他怎么会犯这种错」的提问，替换为「什么系统缺陷让这个错误可能发生并造成这么大影响」；对诚实报告自己失误的人公开致谢——这是维持心理安全的关键仪式。无指责不等于无标准：如果调查发现故意违规或隐瞒，会走独立的人事流程，但那不属于事后分析的范畴。事后分析的组织级放大：Google 有跨团队的事后分析分享机制，重大事故的报告在更大范围传阅，让一个团队的教训变成全公司的免疫力。

值班期间的决策：何时升级、何时回滚、何时求助。事故处置中最贵的不是技术能力，而是决策时机。Google 为值班工程师提供了三条明确的决策规则，用「默认动作」取代「临场纠结」。规则一：15 分钟升级规则。开始处置后 15 分钟内没有明确进展（没有缩小根因范围、没有缓解措施生效），立即升级：拉入备份值班、通知团队负责人、启动战争房间。15 分钟的依据是事故影响的累积速度——大多数 P1 事故每分钟都在造成用户损失，个人英雄主义的排查每多花 10 分钟，损失就多累积 10 分钟，而升级带来的并行处理能力远超个人。升级不是失败，拖延才是。规则二：变更后 30 分钟默认回滚。如果故障发生在某次变更（发布、配置、基础设施调整）后 30 分钟内，默认动作是回滚该变更，而不是排查根因。逻辑：变更是事故的最大来源（约 70%），回滚是最确定的止血手段；「先回滚再验尸」让服务快速恢复，根因分析可以在恢复后的从容状态下进行。犹豫回滚的常见心理是「万一根因不是这次变更，回滚就白做了」——但回滚的成本（重新发布一次）远低于持续故障的成本。规则三：任何时候都可以求助。求助没有门槛、不需要理由、不会被记录为负面评价。与求助相对的是「独自硬扛」，Google 用文化机制对抗它：事后分析会明确检查「升级是否及时」，如果发现值班独自挣扎了 40 分钟才拉人，复盘的问题是「为什么我们的机制没有让升级更容易发生」（比如升级流程太繁琐、升级的心理成本太高），而不是批评值班。三条规则之外还有一个元原则：缓解优先于诊断（mitigate first, diagnose later）。值班的最高优先级是恢复用户服务，手段包括回滚、重启、扩容、切流、降级——哪个快用哪个；完整的根因诊断留给事后。一个典型的错误模式是值班工程师沉迷于「搞清楚到底为什么」，在终端里翻日志一小时，而服务一直在流血。正确的姿势是先止血（哪怕手段粗暴），确认用户恢复后再从容排查。这些决策规则应该写进值班手册的首页，并在每次影子值班培训中反复演练——规则只有内化为条件反射，才能在凌晨三点的高压状态下生效。

值班的自动化：减少人工干预的工程路径。值班自动化的目标是让「需要人做的事」系统性减少，Google 把自动化路径分为四个层次，按投入产出比排序。第一层：自动诊断（auto-triage）。告警触发时，自动化系统立即收集上下文并附在告警通知里：相关指标的当前值与历史对比、最近 24 小时的变更记录、错误日志的聚类摘要、依赖服务的健康状态。价值：把值班从「被叫醒后花 10 分钟搞清楚发生了什么」变成「看通知 30 秒就有初步判断」。实现成本低（一个收集脚本 + 告警模板），收益立竿见影。第二层：自动缓解（auto-mitigation）。对已知故障模式配置自动处置：实例健康检查连续失败自动隔离并从负载均衡摘除；服务过载自动触发限流；磁盘将满自动清理已知可删除的临时数据；进程 OOM 自动重启（带次数上限防止循环）。关键设计：自动缓解必须有「熔断」——同一自动动作短时间内重复触发说明它没解决问题，停止自动操作并升级给人。第三层：自动升级与路由。告警未确认自动转备份值班，备份未确认自动转团队负责人；根据告警标签自动路由到最合适的处置人（数据库告警直接找 DBA 值班而不是通用值班）。这层自动化消灭了「告警发给了错误的人」和「没人确认告警」两类经典失败。第四层：预测性干预。基于趋势预测在问题发生前行动：容量预测显示三天后磁盘满，提前自动扩容；错误率缓慢爬升尚未触发告警，自动开工单提示排查。这层投入最大，适合自动化成熟度高的团队。自动化的度量：每月统计「自动处置的事件数 ÷ 总事件数」，这个比例是值班负载趋势的最直接指标。Google 某存储团队的实践数据：两年内自动化处置率从 15% 提升到 70%，每班操作负载从 8 小时降到 2 小时，值班从团队最讨厌的负担变成了可接受的常规职责。自动化的选题来源就是值班日志：每次人工处置后问一句「这个操作能否脚本化？脚本能否自动触发？」——值班的痛苦清单就是自动化的需求清单。

案例：Google 值班文化的演进。Google 的值班制度并非一开始就成熟，蓝皮书和黑皮书记录了二十年的演进轨迹，其中几个转折点对今天的实践影响深远。早期（2003 到 2008 前后）：SRE 团队规模小、服务增长快，值班是「英雄时代」——工程师以能扛住大事故为荣，半夜处理故障是常态，没有系统的负载度量，也没有正式的补偿制度。这个阶段的隐患逐渐显现：资深工程师疲劳流失、新人成长依赖「被事故毒打」、同样的故障反复发生因为没人有精力做系统性改进。转折一：操作负载红线的确立。管理层意识到值班负担不可持续后，确立了「SRE 团队操作负载不超过 50%」的硬性规则，并配套了「超标必须立项改进」的机制。这条规则把值班问题从「个人忍耐度」变成了「组织资源分配」问题——负载超标不再是值班的耻辱，而是需要工程投入的信号。转折二：值班补偿制度化。Google 为值班建立了正式的补偿体系（津贴 + 调休），承认值班的真实成本。补偿制度意外地改善了值班质量：因为负担被正式承认，工程师更愿意坦诚报告负载数据（此前少报负载是普遍现象，因为「扛不住」被视为能力不足）。转折三：告警治理与值班的联动。2010 年代多窗口燃烧率告警普及后，夜间唤醒次数大幅下降，Google 发现告警质量是值班体验的第一决定因素——比补偿、比轮换设计都重要。这促成了「告警体系审查作为值班负载超标的第一响应动作」的实践。转折四：心理安全的正式化。无指责事后分析从「文化倡导」变成「流程强制」：事后分析文档有标准模板和评审机制，指责性语言会被评审打回。当前状态：Google 的值班已经是高度工程化的体系——8 人以上轮换、主备双人、结构化交接、自动化处置率超过 50%、每班紧急事件平均不到 1 起。这个演进史的最大启示是：值班文化的每一步改善都来自「把隐性问题显性化」——负载数据显性化促成红线制度，成本显性化促成补偿制度，告警噪音显性化促成治理联动。你的组织改进值班的第一步，也是把数据摆上桌面。

代码示例

/* 示例 1：值班排班健康度检查器（TypeScript） */
interface Shift { engineer: string; start: string; end: string; isHoliday: boolean; }
function checkRosterHealth(shifts: Shift[], periodDays: number) {
  const perEngineer = new Map<string, number>();
  for (const s of shifts) {
    perEngineer.set(s.engineer, (perEngineer.get(s.engineer) ?? 0) + 7);
  }
  const teamSize = perEngineer.size;
  const report = {
    teamSize,
    healthy: teamSize >= 8,
    maxDaysPerMonth: Math.max(...perEngineer.values()),
    verdict: "",
  };
  report.verdict =
    teamSize < 8 ? "不健康：轮换规模不足 8 人，考虑合并值班池或降低值班强度" :
    report.maxDaysPerMonth > 7 ? "警告：有人每月值班超过 7 天，检查排班公平性" :
    "健康";
  return report;
}

这个检查器把值班团队设计的硬约束编码为自动验证。核心逻辑：8 人下限来自「每人每月值班不超过一周」的健康标准——周轮换制下 N 人团队每人每 N 周值一次班，8 人团队每人每月约 3.75 天，4 人团队则高达 7.5 天以上。实践中建议把排班表存为结构化数据（JSON 或 iCal），每月自动运行健康检查，同时统计附加维度：节假日值班的分布公平性（是否总是同几个人扛节假日）、夜间唤醒次数的个人累积（疲劳风险预警）、连续值班间隔（两次值班之间是否有足够恢复期）。当检查器报告「不健康」时，四个选项按优先级排列：用自动化削减负载（治本）、与相邻团队合并值班池（快速见效）、降低值班强度为仅响应 P1（妥协方案）、增加人手（最慢但有时是唯一解）。

/* 示例 2：值班交接文档模板（Markdown 生成器） */
const handoverTemplate = (data: {
  outgoing: string; incoming: string; date: string;
  ongoingIncidents: string[];
  upcomingChanges: { time: string; change: string; risk: string }[];
  knownIssues: string[];
  tips: string[];
}) => `
# 值班交接 ${data.date}
交接人: ${data.outgoing} -> 接班人: ${data.incoming}

## 进行中的事故/工单
${data.ongoingIncidents.map((i) => "- " + i).join("\n") || "- 无"}

## 未来 48 小时计划变更
| 时间 | 变更 | 风险 |
|------|------|------|
${data.upcomingChanges.map((c) => "| " + c.time + " | " + c.change + " | " + c.risk + " |").join("\n")}

## 已知问题与观察项
${data.knownIssues.map((i) => "- " + i).join("\n")}

## 上一班经验提示
${data.tips.map((t) => "- " + t).join("\n")}

## 接班确认
接班人需口头复述: 进行中的事故处置状态、最高风险变更、升级路径
`;

结构化交接模板的价值在于「强制完整性」：自由发挥的交接总是遗漏信息，而模板的每个 section 都在提醒交班者「这部分你想到了吗」。四个 section 各有深意：进行中事故防止「处置到一半的问题被遗忘」；计划变更让接班人对未来 48 小时的风险有预期（大部分事故与变更相关，知道变更计划等于提前武装）；已知问题记录「灰色地带」——不够格立项但值得留意的慢性异常；经验提示传递隐性知识（「X 告警最近频繁误报，已建单修复，可暂时忽略」这类信息对接班人的睡眠质量至关重要）。最后的「接班确认」环节借鉴了航空业的交叉检查文化：接班人复述关键信息，交班者确认理解无误——这个 30 秒的仪式能拦截绝大多数交接误解。建议把模板做成命令行工具或表单，交接会前 10 分钟由交班者填好发出，会议只讨论疑点不朗读文档。

/* 示例 3：操作负载统计脚本 */
const events = loadOncallEvents("shift_2026_10_13.json");
/* 事件结构: {type: page|ticket|routine, minutes: number, automated: boolean} */
function operationalLoad(events) {
  const byType = { page: 0, ticket: 0, routine: 0 };
  let interrupted = 0;
  for (const e of events) {
    byType[e.type] += e.minutes;
    if (!e.automated) interrupted++;
  }
  const totalMinutes = Object.values(byType).reduce((a, b) => a + b, 0);
  return {
    pages: events.filter((e) => e.type === "page").length,
    totalHours: (totalMinutes / 60).toFixed(1),
    loadRatio: (totalMinutes / 60 / 12).toFixed(2),  /* 12小时班次 */
    healthy: totalMinutes / 60 <= 6 && byType.page <= 2,
    byType,
  };
}
/* 健康标准: 总负载 <= 6 小时(50%红线) 且紧急事件 <= 2 起 */

这个脚本实现了 Google 操作负载度量的核心逻辑：50% 红线（12 小时班次中人工操作不超过 6 小时）和紧急事件上限（每班不超过 2 起）。automated 字段区分自动处置与人工处置——自动处置的事件不计入操作负载，这正是自动化投入的直接回报体现。loadRatio 是最值得长期追踪的指标：它的月度趋势揭示团队是在「越干越轻松」（自动化见效）还是「越干越重」（系统劣化或规模增长快于自动化）。建议把统计接入值班结束流程：交班前脚本自动从告警系统和工单系统拉取数据生成报告，值班只需补充手工事件。当 healthy 为 false 时触发标准响应：连续两班超标 → 告警体系审查（是不是误报太多）；紧急事件多 → 可靠性专项（是不是系统太脆弱）；routine 占比高 → 自动化立项（例行操作该脚本化了）。负载数据的季度汇总还是「SRE 是否应该继续支持该服务」决策的关键输入。

/* 示例 4：Playbook 条目模板（告警处置决策树） */
const playbookEntry = {
  alert: "CheckoutAPIHighBurnRate (P1 燃烧率告警)",
  meaning: "错误预算以 >=14.4 倍速燃烧，用户正在经历显著失败率",
  quickCheck: [
    "1. 打开 SLO 仪表盘: https://grafana.internal/d/checkout-slo",
    "2. 确认当前错误率与开始时间",
    "3. 查看告警附带的最近变更列表",
  ],
  decisionTree: [
    { if: "错误开始时间在某次变更后 30 分钟内", then: "立即回滚该变更（见回滚手册 RB-01），不要先排查根因" },
    { if: "错误集中在单一可用区", then: "执行流量切换 AZ-FAILOVER-02，然后排查该 AZ 基础设施" },
    { if: "依赖服务 payment-api 同时告警", then: "确认为上游故障，启用降级开关 checkout.degrade.skip_payment_retry，通知 payment 值班" },
    { if: "以上都不符合", then: "收集诊断包 diag-checkout.sh，15 分钟无进展立即升级" },
  ],
  escalation: "15 分钟无进展 -> 备份值班; 30 分钟无进展 -> SRE 负责人 + 产品负责人; 涉及资金损失 -> 立即上报",
  recoveryCheck: "燃烧率告警恢复 + 错误率回到 0.1% 以下持续 15 分钟 + SLO 仪表盘确认",
};

这份 playbook 条目展示了「为凌晨三点而写」的具体含义。quickCheck 限制在 3 步以内——疲劳状态下人无法执行冗长的信息收集流程。decisionTree 是精髓：它把开放式排查转化为模式匹配，前三个分支覆盖了 80% 的历史事故场景（变更后故障、单 AZ 故障、依赖故障），每个分支的 then 都是具体动作加手册编号，不需要临场发明。注意第一个分支直接编码了「变更后 30 分钟默认回滚」的决策规则——把 Google 的最佳实践固化进文档，值班不需要记住规则，只需要跟着树走。escalation 部分用明确的时间和角色取代模糊的「必要时升级」，特别列出「涉及资金损失立即上报」这类业务敏感条件。recoveryCheck 防止「假恢复」：告警消失不等于问题解决（可能只是流量低谷），要求错误率持续正常 15 分钟才算恢复。每个条目的维护元数据（最近验证时间、最近修订人）建议一并存储，季度验证日按此清单演练。

/* 示例 5：无指责事后分析时间线生成器 */
function buildTimeline(rawEvents: { ts: string; actor: string; event: string }[]) {
  const start = new Date(rawEvents[0].ts).getTime();
  return rawEvents.map((e) => {
    const offsetMin = Math.round((new Date(e.ts).getTime() - start) / 60000);
    /* 无指责处理: 用角色代替人名, 用被动语态描述动作 */
    const anonymized = e.event
      .replace(/张三|李四|王五/g, "值班工程师")
      .replace(/执行了错误的/, "执行了")
      .replace(/忘记了/, "遗漏了");
    return { t: "+" + offsetMin + "min", actor: e.actor, event: anonymized };
  });
}
/* 输出示例:
   +0min   监控系统  配置变更被部署到生产环境
   +3min   监控系统  搜索空结果率从 0.1% 升至 12%
   +33min  告警系统  P1 告警触发（告警延迟 30 分钟 -> 行动项）
   +39min  值班工程师 开始排查，初步判断为索引问题
   +60min  值班工程师 识别到与配置变更相关
   +77min  值班工程师 完成回滚，服务恢复 */

这个工具演示了事后分析写作的两个技术要点。第一是相对时间线：所有事件以「+Nmin」表示相对故障起点的时间，比绝对时间戳更容易看出时间都花在了哪里——示例中「+3min 空结果率飙升」到「+33min 告警才触发」的 30 分钟差距直接暴露了告警体系缺陷，「+39min 判断为索引问题」到「+60min 才关联到变更」的 21 分钟暴露了「告警未附带变更记录」的工具缺陷。时间线的价值就在于让「系统性延迟」无处遁形，每个大的时间间隙都是一个行动项候选。第二是无指责的语言处理：用角色（值班工程师）代替人名，用中性动词（遗漏了）代替指责性表述（忘记了）——工具层面的自动替换只是辅助，真正的无指责是评审文化：评审会上任何「他怎么会犯这种错」的提问都应被主持人替换为「什么系统缺陷让这个错误可能发生」。注意时间线的起点选择：从「第一个异常信号」开始而不是从「告警触发」开始，因为异常与告警之间的间隙往往是最有价值的改进线索。

实验笔记

本实验的目标是设计一套完整的值班体系，包括轮换排班、负载度量、交接流程、playbook 和事后分析模板。实验分五个部分，预计 4 到 5 小时。第一部分：值班轮换设计（约 1 小时）。假设你的团队有 N 名工程师（用真实数字，如果少于 8 人，设计跨团队合并方案）。计算：每人每月值班天数 = 30 ÷ N × 值班周期占比；验证是否满足「每人每月值班 ≤ 7 天」的健康标准；如果不满足，列出选项（合并值班池、降低值班强度为「仅响应 P1」、招聘、自动化减负）并评估各自成本。设计轮换表：周轮换、周一上午 10 点交接（避开周五交接——周末出问题找不到人）、主值班 + 备份值班双人制、备份值班在主值班 15 分钟未确认时自动接管。产出：未来 8 周的排班表 + 值班职责说明书（值班期间负责什么、不负责什么、有权做什么决定）。第二部分：操作负载度量体系（约 45 分钟）。定义负载指标：每班紧急事件数（目标 ≤2）、每班工单数（目标 ≤5）、值班时间中被中断的次数、每次事件的平均处理时长、夜间被叫醒次数（目标 ≤1）。设计数据采集方式：告警系统自动记录 + 值班日志手动补充。制定超标响应规则：连续两个班次紧急事件 >2，触发告警体系审查；连续一个月夜间叫醒 >4 次/班，触发自动化专项。用模拟数据练习：给定一个班次的告警时间戳列表，计算各指标并判断是否超标。第三部分：交接流程与模板（约 45 分钟）。设计 15 分钟结构化交接会议议程：上一班事件回顾（5 分钟）、进行中问题移交（5 分钟）、本周变更计划与风险提示（3 分钟）、疑问澄清（2 分钟）。编写交接文档模板：进行中的事故/工单及当前状态、未来 48 小时的计划变更、已知风险与观察项、上一班的经验提示（「X 服务的 Y 告警最近频繁误报，可暂时忽略，已建单修复」）。与同伴演练一次完整交接：一人扮演交班者一人扮演接班者，用模拟场景填充模板，记录交接中信息遗漏的地方。第四部分：Playbook 编写（约 1.5 小时）。选择服务的三个最常见故障场景（如「数据库连接池耗尽」「上游依赖超时」「实例 OOM 循环重启」），为每个场景编写 playbook 条目。格式要求：症状描述（告警长什么样、用户报告什么）→ 快速确认（一条命令或一个仪表盘链接确认问题）→ 处置决策树（如果 A 则执行 X，如果 B 则执行 Y）→ 具体操作步骤（精确到命令，标注危险操作）→ 升级条件（什么情况下停止自救拉人）→ 恢复验证（怎么确认问题解决了）。编写原则：为凌晨三点的半睡半醒状态而写，每步不超过一行，所有链接可直接点击。写完后做「新人测试」：让一个不熟悉该场景的同伴只看 playbook 处理模拟故障，记录每个卡点并修订。第五部分：无指责事后分析演练（约 1 小时）。给定一个事故场景：「周二 14:32，一次配置变更导致搜索服务对 15% 的用户返回空结果，持续 47 分钟，14:35 告警触发，值班工程师 14:41 开始排查但方向错误（以为是索引问题），15:02 才意识到与变更相关，15:19 完成回滚」。撰写完整事后分析：精确时间线、影响量化（受影响请求数、用户投诉数）、根因分析（用五个为什么：为什么配置变更没有灰度？为什么告警没有关联变更记录？为什么排查方向错误？）、行动项（每条有负责人和期限，至少包括：配置变更接入灰度流程、告警通知自动附带最近变更、搜索空结果率加入 SLI）。语言检查：全文不得出现指责性表述（「XX 疏忽了」改为「流程缺少 XX 检查环节」）。通过五个部分的完整演练，你将拥有一套可以直接带回团队落地的值班体系设计。

第5章 值班