研发平台恢复runbook要解决的是压力下的执行问题：谁先做什么、每一步看到什么结果算通过、什么情况下停止并回退。本文提供一份可直接复制填写的空白模板，并逐字段说明填写口径、必填规则、完整样例和维护机制，帮助团队把恢复动作从个人经验变成可交接、可演练的文档。
要点总览（TL;DR）
- 恢复runbook应覆盖九个部分：文档头、恢复目标与范围、触发与分级、角色与联络、前置检查、恢复步骤、校验点、回退条件、沟通与记录、演练与维护。
- 恢复对象、RPO/RTO、触发条件、角色联络、前置检查、恢复步骤、校验点、回退条件属于必填项，缺失时不应启动恢复。
- 每个恢复步骤按“动作+对象+预期结果”写，每个校验点给出可复核的证据类型，回退条件尽量量化到现场可直接比对。
- runbook需随平台版本、架构、备份策略和事故复盘更新，建议每季度演练、每半年评审，并保留版本变更留痕。
可复制空白恢复runbook模板
以下骨架可直接粘贴到内部文档系统，按占位说明逐项填写。方括号内为填写提示，正式发布前应全部替换为具体内容。
# [平台名称] 恢复runbook ## 0. 文档头 - runbook名称：[如 研发平台生产环境数据库恢复] - 适用平台与版本：[平台名称、版本号、部署方式] - 负责人：[姓名/角色] - 版本号：[v1.0] - 最近更新日期：[YYYY-MM-DD] - 最近演练日期：[YYYY-MM-DD] - 评审人：[姓名/角色] ## 1. 恢复目标与范围 - 恢复对象：[数据库/代码仓库/制品库/配置中心/附件存储，逐项列出] - 不在本次范围：[明确排除项] - RPO：[可接受的数据丢失时间窗口] - RTO：[可接受的恢复完成时间] - 恢复粒度：[全量/单模块/单租户/指定时间点] ## 2. 触发与分级 - 启动恢复的情形：[数据误删、存储故障、升级失败等] - 事故等级与响应：[P1/P2/P3 对应响应时限与审批人] - 启动决策人：[角色] ## 3. 角色与联络 | 角色 | 姓名 | 联系方式 | 职责与决策权 | |---|---|---|---| | 指挥人 | | | | | 执行人 | | | | | 校验人 | | | | | 业务确认人 | | | | | 厂商/运维支持 | | | | ## 4. 前置检查 - [ ] 备份可用性：[备份时间点、完整性校验方式、校验结果] - [ ] 恢复环境：[目标环境就绪状态] - [ ] 权限：[执行账号与授权范围] - [ ] 变更冻结：[冻结窗口与通知范围] - [ ] 回退预案已确认：[回退目标状态] ## 5. 恢复步骤 | 序号 | 操作人 | 操作内容 | 预期结果 | 实际结果 | 完成时间 | |---|---|---|---|---|---| | 1 | | | | | | | 2 | | | | | | ## 6. 校验点 | 阶段 | 校验项 | 通过标准 | 证据类型 | 校验人 | |---|---|---|---|---| | | | | | | ## 7. 回退条件与回退步骤 - 触发回退的判定：[量化条件] - 回退操作步骤：[按顺序编号] - 回退后确认：[业务与数据状态确认方式] ## 8. 沟通与记录 - 通知对象与时间点：[启动、阶段完成、恢复完成、回退] - 记录字段：[事故编号、开始时间、恢复时间点、执行人、校验结论、遗留问题] ## 9. 演练与维护 - 演练频率：[如每季度一次] - 更新触发条件：[版本变更、架构调整、备份策略变化、事故复盘] - 评审周期与评审人：[填写] - 版本变更留痕方式：[填写]
字段说明：每个栏位填什么、怎么判断填对了
模板能否在事故中真正用起来，取决于字段口径是否统一。同一份runbook由不同人填写，结果应当一致，下面是各栏位的填写口径与合格判断。
| 字段 | 含义 | 填写口径 | 合格判断 |
|---|---|---|---|
| 恢复对象与范围 | 本次恢复覆盖的系统模块、数据类型和时间点 | 按“模块—数据类型—时间点”三层界定，如订单库全量、截至最近一次全量备份；同时写明排除项 | 执行人无需再询问即可判断哪些数据要恢复、哪些不动 |
| RPO | 可接受的数据丢失时间窗口 | 依据业务对数据丢失的容忍度填写，并与备份频率对齐；RPO小于备份间隔时需说明补充手段 | RPO与现有备份策略匹配，或已注明差距及应对方式 |
| RTO | 从启动恢复到业务可用的目标时长 | 按业务影响分级分别填写，包含校验与业务确认时间 | RTO可被步骤表的时间估算支撑，而非孤立数字 |
| 触发条件 | 什么情况启动恢复 | 写成可判断的事件描述，如“主库数据被误删且影响写入” | 值班人员对照现象即可判断是否启动 |
| 事故分级 | 事故严重程度与响应级别 | 按影响范围、影响用户数、是否可降级运行划分等级，每级对应审批人与响应时限 | 等级之间边界清晰，不存在“视情况而定” |
| 角色职责 | 指挥、执行、校验、业务确认的决策边界 | 指挥人决定启动与回退；执行人按步骤操作；校验人判定校验点是否通过；业务确认人确认业务可用 | 每个关键决策只有一个最终拍板角色 |
| 前置检查 | 恢复开始前必须满足的条件 | 每项写成可核验的检查动作，如“对最近备份执行完整性校验并记录结果” | 每项有明确的通过/不通过结论，而非“已确认” |
| 恢复步骤 | 按顺序执行的操作 | 采用“动作+对象+预期结果”写法，如“将数据库指向备份时间点，预期连接成功且表数量一致” | 步骤可被未参与设计的人独立执行 |
| 校验点 | 每阶段的可观察验证项 | 给出可观察证据：查询结果、日志片段、页面状态、数量比对 | 校验结论可被第三人复核 |
| 回退条件 | 停止恢复并回退的判定 | 尽量量化，如“校验点连续两次不通过”或“超过RTO的50%仍未完成数据导入” | 判定条件在执行现场可直接比对 |
| 记录字段 | 恢复过程留痕的最小集合 | 事故编号、启动时间、使用的备份时间点、各阶段完成时间、执行人与校验人、最终结论、遗留问题 | 事后可据此还原全过程并支撑复盘 |
必填与选填：哪些栏位缺失就不能执行
runbook不必一次写全，但有些栏位缺失时恢复动作不应启动。必填项对应“没有它就无法安全执行”的信息，选填项用于提升效率与可追溯性。
| 类别 | 栏位 | 缺失时的处理 |
|---|---|---|
| 必填 | 恢复对象与范围 | 不得启动，先确认恢复边界 |
| 必填 | RPO/RTO | 不得启动，无法判断恢复是否达标 |
| 必填 | 触发条件与事故分级 | 不得启动，避免误操作与越权 |
| 必填 | 角色与联络 | 不得启动，指挥与校验责任无法落实 |
| 必填 | 前置检查项及通过标准 | 不得启动，备份可用性未确认时恢复风险不可控 |
| 必填 | 恢复步骤 | 不得启动，现场临时摸索会放大事故 |
| 必填 | 校验点 | 不得启动，无法判断恢复是否成功 |
| 必填 | 回退条件与回退步骤 | 不得启动，失败时无退出路径 |
| 选填 | 演练记录模板 | 可后补，但应在首次演练前建立 |
| 选填 | 附录脚本与命令 | 可后补，建议标注适用版本 |
| 选填 | 历史事故参考 | 可后补，用于缩短判断时间 |
平台规模较小时，可先保证必填项完整，将角色合并为“指挥兼执行”“校验兼业务确认”，但合并后仍需在文档中写明谁对校验结论负责。平台模块多、部署方式复杂时，建议按模块拆分多份runbook，每份独立满足必填要求，避免一份文档覆盖过多对象导致步骤互相干扰。
填写示例：一份完整的恢复runbook样例
以下为演示用虚构情景，不对应任何真实客户或事故：某研发平台生产环境数据库因误操作被删除部分表，需从最近备份恢复。
# 研发平台生产数据库恢复runbook ## 0. 文档头 - runbook名称：研发平台生产数据库误删恢复 - 适用平台与版本：研发平台 v3.x，私有化部署 - 负责人：运维负责人 张工 - 版本号：v1.2 - 最近更新日期：2025-03-10 - 最近演练日期：2025-02-20 - 评审人：平台架构师 李工 ## 1. 恢复目标与范围 - 恢复对象：生产数据库中的需求、任务、缺陷三张核心表 - 不在本次范围：附件存储、日志库 - RPO：15分钟 - RTO：2小时 - 恢复粒度：指定时间点恢复至误删前最后一个备份 ## 2. 触发与分级 - 启动恢复的情形：核心表数据被误删且影响写入与查询 - 事故等级：P1，影响全部研发团队；审批人：运维负责人 - 启动决策人：值班指挥人 ## 3. 角色与联络 | 角色 | 姓名 | 职责与决策权 | |---|---|---| | 指挥人 | 张工 | 决定启动、暂停与回退 | | 执行人 | 王工 | 按步骤执行恢复操作 | | 校验人 | 赵工 | 判定各校验点是否通过 | | 业务确认人 | 产品负责人 | 确认业务功能可用 | | 厂商支持 | 平台厂商工单 | 提供恢复过程技术支持 | ## 4. 前置检查 - [x] 备份可用性：取误删前最近一次全量备份，执行完整性校验，结果通过 - [x] 恢复环境：预发环境已就绪，可承接恢复验证 - [x] 权限：执行账号具备数据库恢复权限 - [x] 变更冻结：已通知暂停发布，冻结窗口 2 小时 - [x] 回退预案：保留当前库快照，可回退至恢复前状态 ## 5. 恢复步骤 | 序号 | 操作人 | 操作内容 | 预期结果 | |---|---|---|---| | 1 | 王工 | 在预发环境导入备份至指定时间点 | 导入完成无报错 | | 2 | 王工 | 比对三张核心表记录数与备份清单 | 数量一致 | | 3 | 赵工 | 抽查关键业务数据 | 字段完整、关联正确 | | 4 | 王工 | 将验证通过的库切换为生产 | 业务连接正常 | ## 6. 校验点 | 阶段 | 校验项 | 通过标准 | 证据类型 | |---|---|---|---| | 导入后 | 表记录数 | 与备份清单一致 | 查询结果截图 | | 导入后 | 关键字段完整性 | 抽查100条无空值异常 | 查询结果 | | 切换后 | 业务可用性 | 需求、任务、缺陷页面可正常读写 | 业务确认记录 | ## 7. 回退条件与回退步骤 - 触发回退：导入报错两次，或记录数比对不一致，或超过RTO一半仍未完成导入 - 回退步骤：停止导入 → 恢复预发环境快照 → 生产保持原状态 → 通知指挥人与业务确认人 - 回退后确认：业务读写正常，数据状态与恢复前一致 ## 8. 沟通与记录 - 通知时间点：启动时、导入完成时、切换完成时、回退时 - 记录字段：事故编号、启动时间、备份时间点、各阶段完成时间、执行人与校验人、最终结论、遗留问题 ## 9. 演练与维护 - 演练频率：每季度一次 - 更新触发条件：平台版本升级、数据库架构调整、备份策略变化、事故复盘后 - 评审周期：每半年，评审人：平台架构师 - 版本变更留痕：文档版本号与变更说明
对照字段说明可以看到：恢复对象写到了表级，RPO与备份频率对齐，校验点给出了可复核的证据类型，回退条件写成了可现场比对的量化判定。这些写法保证执行人在压力下不需要临场解释文档。
调整与维护：让runbook随平台变化保持可用
runbook过期往往比没有runbook更危险，因为它会让人按错误步骤操作。维护机制要解决“什么时候改、谁来改、改了什么留痕”三个问题。
- 更新触发条件：平台版本升级、架构调整（如数据库拆分、存储迁移）、备份策略变化、事故复盘产生新结论时，均应在变更完成后两周内更新对应章节。
- 演练频率与记录：建议每季度至少演练一次，演练记录包含演练时间、参与角色、实际耗时与RTO对比、校验点通过情况、发现的问题及修订项。
- 评审角色与周期：由平台负责人或架构师每半年评审一次，重点检查角色联络是否有效、步骤是否与当前环境一致。
- 版本管理与变更留痕：每次修改更新版本号并记录变更说明，保留历史版本，便于回溯某次事故使用的是哪一版。
- 失效条目下线：已不存在的模块、已下线的脚本、已变更的联络人应及时删除或标注失效，避免执行时误用。
当runbook进入日常维护，评审记录、演练结论和变更说明需要有稳定的承载位置。ONES 支持通过工作项跟踪演练任务与整改项，并将runbook文档与评审记录放在同一协作空间中，使版本变更和演练结论可追溯；其数据备份采用多样化备份策略适配客户场景，具体备份频率、保留周期与恢复操作需结合部署方式与厂商支持确认后写入前置检查。这样，文档维护与恢复执行共享同一套记录，减少信息散落。
常见问题
团队规模较小、没有专职运维，runbook的角色怎么填？
可以合并角色，例如由一人担任指挥兼执行、另一人担任校验兼业务确认，但合并后要在文档中写明谁对校验结论负责、谁有权决定回退。必填项不能因为人少而省略，尤其是校验点和回退条件，它们决定恢复失败时能否及时止损。若确实只有一人可执行，建议在启动恢复前引入至少一名独立校验人，哪怕由相邻团队负责人临时担任。
备份完整性校验应该做到什么程度才算通过？
校验方式要与恢复对象匹配：数据库可核对备份文件可读、表结构与记录数与备份清单一致；代码仓库可验证最近提交与分支引用完整；制品库可抽查关键制品的元数据与校验和。合格的标准是校验人能给出明确的通过或不通过结论，并留下查询结果、日志片段等证据，而不是只写“已确认备份可用”。具体校验命令和工具需按平台实际部署方式确定。
恢复进行到一半发现校验不通过，应该先修还是先回退？
按runbook预先写好的回退条件判断。若属于可快速修复且不影响数据一致性的问题，例如连接配置错误，可在记录后修正并重新执行该步骤；若涉及数据导入不完整、记录数比对不一致，或耗时已超过RTO的一半仍未完成，应触发回退。回退前由指挥人确认，回退后保留现场证据，供复盘定位原因。把这类判断提前写进文档，可以避免现场争论。
平台升级或架构调整后，runbook哪些部分最容易失效？
最容易失效的是恢复步骤、前置检查中的环境与权限项、角色联络信息，以及附录脚本的适用版本。升级后数据库版本、存储路径、部署方式可能变化，原有命令和预期结果不再成立。建议在变更完成后两周内，由执行人对照新环境走查一遍步骤，更新版本号并记录变更说明；涉及备份策略变化时，同步复核RPO与备份频率是否仍然匹配。
演练时应该按真实事故全流程走，还是只验证关键步骤？
建议交替进行：季度演练可选取一个恢复对象做全流程演练，覆盖启动决策、前置检查、恢复、校验、业务确认和记录，测量实际耗时与RTO的差距；月度或临时演练可只验证备份可用性和关键校验点。每次演练都要记录参与角色、通过情况、发现的问题和修订项，并把修订落到runbook的新版本中，否则演练结论无法转化为可执行文档。
