9.2 On-call、事件响应、复盘与 Toil

On-call 是生产责任的最后防线，不是用睡眠偿还设计债务。可持续值班要求可操作告警、足够权限、经过验证的 runbook、明确升级和事故后的系统改进。

Page 必须可行动

一个有效 page 应回答：

没有立即动作的告警应降为 ticket 或删除。重复噪声会训练值班人员忽略真正事故。

小事件可以一人兼任，影响扩大后应尽早分工。大量专家无序加入会增加沟通成本和危险操作。

事件中首要目标是减少用户影响：回滚、切流、降级、限流、扩容或关闭危险功能。找到完整根因可以在稳定后继续。

每次操作写明假设、执行者、时间、预期信号和回退。不要多人同时改同一系统，也不要在没有状态记录时连续尝试不可逆修复。

状态更新包含：影响、开始时间、当前缓解、下一次更新时间和已知/未知。避免用“应该很快恢复”替代证据。

对外状态与内部技术细节可以不同，但不能隐瞒用户需要采取的动作。交接时明确当前系统状态、未验证假设和正在进行的变更。

复盘关注当时信息和系统条件下，为什么一个动作看起来合理，以及哪些防线缺失。它不以羞辱个人为目标，也不回避所有权、决策和改进责任。

复盘至少包括：

“加强培训”“以后小心”不是可验证行动。优先减少同类事故发生概率、缩小 blast radius 或缩短恢复时间。

Toil 常具有手工、重复、可自动化、战术性、线性增长和低长期价值等特征。不是所有运维工作都是 toil：设计容量模型、改进恢复协议和演练可能很有工程价值。

自动化前先简化和标准化流程。把不稳定手册直接脚本化，只会更快地执行错误。高风险自动化需要 dry-run、幂等、审计、限速和回退。