高可用应急 Runbook 应该包含什么？

简化版

应急 Runbook 要让不熟悉系统的人也能安全执行，至少包含触发条件、影响判断、角色分工、前置检查、分步命令、每步验证、停止/回滚条件、升级联系人和事后清理。 它必须版本化、可审计并通过演练保持新鲜，只有“重启服务、联系负责人”的文档不具备操作性。

详细版

开头写明适用故障与不适用边界，随后给出仪表盘、日志查询和业务验证入口。步骤使用“动作—预期—异常分支”格式，危险命令提供占位符校验和作用域，不允许复制后直接全局执行。切换类流程还需记录 epoch、数据位点和当前权威主。

Runbook 设总指挥、操作人、观察人和业务确认人，明确谁有权切流或回滚。每次演练/事故记录实际耗时、失效链接和人工判断，并由 owner 更新；过期、未演练或依赖权限失效的 Runbook 应视为不可用。

完整版教学

一、Runbook 解决事故中的认知负担

事故时信息不全、时间紧、多人并行，靠记忆容易跳过 fencing、输错地域或重复操作。Runbook 把关键判断、顺序和安全门槛提前固化，让团队把精力放在异常事实而非回忆命令。

记忆钩子：好的 Runbook 不只是告诉你“做什么”，还告诉你“看到什么才继续、看到什么必须停”。

二、文档头部的必要信息

字段	作用
适用症状/告警	避免用错剧本
影响与风险等级	决定响应级别
owner/升级联系人	找到决策者
最近验证时间	判断是否可信
所需权限/工具	避免执行中才申请
预计 RPO/RTO	管理业务预期

还要标出禁止条件，例如无法 fencing 旧主时禁止提升新主。

三、步骤必须是可验证状态迁移

步骤 3：将 region-b 提升为写租约持有者，epoch=52
预期：控制台显示 owner=region-b, epoch=52
验证：旧主写测试返回 STALE_EPOCH
失败：停止切流，执行回滚 R-3，并升级 DBA

这比“切换数据库”可操作得多。每步分配编号，沟通时能明确当前状态，重复执行还要幂等。

四、命令和参数的安全设计

禁止硬编码生产密钥，地域、集群、租户使用显式变量并在执行前回显。破坏性命令先提供只读预检，要求双人确认。工具输出要有可识别成功条件，不能只凭退出码 0 判断业务已恢复。

PRECHECK cluster=prod-a expectedPrimary=db-1
ACTION   promote target=db-2 expectedEpoch=51
VERIFY   currentPrimary=db-2 currentEpoch=52

五、角色和沟通节奏

Incident Commander 决策与控节奏，Operator 执行，Observer 看指标，Scribe 记录时间线，业务负责人确认用户结果。操作人不应同时在多个群解释，避免漏步骤。每 10 或 15 分钟固定同步影响、当前阶段、下一动作和是否需要升级。

外部沟通使用业务语言，不暴露内部敏感拓扑；内部记录保留完整命令、版本和数据位点。

六、持续验证和新鲜度

链接会失效、命令会改、权限会过期。至少按业务等级周期演练，并在每次代码、拓扑或平台重大变更后复查关联 Runbook。自动检查文档中的 URL、脚本 --dry-run 和权限，降低临战失败。

指标包括最近演练时间、步骤成功率、人工耗时、RTO 偏差、回滚成功和待修问题。事故结束还要完成临时开关、扩容、告警静默和权限清理。

七、常见误区与追问

• 误区：Runbook 越长越完整。 关键是决策清晰和可执行，背景知识可链接附录。
• 误区：只列命令无需预期输出。 操作者无法判断是否可以进入下一步。
• 误区：由一个人边操作边观察最省人。 高压下容易漏看指标和误执行。
• 误区：事故后恢复就结束了。 临时状态、数据回补和文档修订都要关闭。
• 追问：如何防 Runbook 过期？ owner、到期日、变更关联和周期演练共同保证。
• 追问：自动化后还需要文档吗？ 需要说明触发条件、护栏、人工接管和自动化失败分支。
• 追问：怎样评价质量？ 让非作者在演练中执行，并测错误、耗时和求助次数。

八、加强记忆

Runbook 围绕“何时用、谁来做、每步做什么、如何验、何时停、怎样回”编写。命令前有预检，动作后有可观察结果，异常有分支，结束有清理。版本和演练让它保持可信，否则文档越详细，过期时误导越危险。