研发平台灾备演练要回答的是“故障发生后，平台能不能在约定时间内把关键数据恢复到可用状态”。做法可以按七步推进：定范围与目标、定恢复指标、准备备份与隔离环境、编写演练脚本、执行切换与恢复、核验数据与业务、复盘整改。本文围绕代码仓库、工作项、测试用例、流水线配置、制品、文档与权限配置等对象，给出可照做的步骤、角色分工、示例和通过判定标准。
要点总览（TL;DR）
- 灾备演练按“定范围与目标—定RTO/RPO—准备备份与隔离环境—编写脚本—执行恢复—业务核验—复盘整改”推进，每步都留下时间戳和证据。
- 范围要落到具体数据对象：代码仓库、工作项、测试用例、流水线配置、制品、文档与权限配置，并写明恢复依赖顺序。
- 演练前必须确认备份可用、隔离环境可登录、四类角色到位，避免当天才发现输入缺失。
- 通过与否用判定表核对RTO/RPO达成、数据完整性、业务可用性和异常闭环，未达标项转成有负责人和期限的整改任务。
- 单域演练可按季度轮换对象域，全量演练按年度或重大架构变更后执行，整改项在下一轮优先复验。
先定演练范围：保哪些数据、恢复到什么程度
灾备演练的第一步是把“平台”拆成具体数据对象。范围不清，演练容易变成一次性的环境搭建，无法判断哪些数据真正被保住了。建议先列一份研发平台数据对象清单，再逐项确定本轮是否覆盖。
| 数据对象 | 典型内容 | 恢复依赖 | 本轮是否覆盖 |
|---|---|---|---|
| 代码仓库 | 仓库、分支、提交历史、合并记录 | 依赖账号与权限配置先行恢复 | 是/否 |
| 工作项与需求 | 需求、任务、缺陷、状态与流转记录 | 依赖用户与项目结构 | 是/否 |
| 测试用例 | 用例库、执行记录、关联需求 | 依赖工作项与项目结构 | 是/否 |
| 流水线配置 | 流水线定义、触发规则、凭据引用 | 依赖代码仓库与制品库地址 | 是/否 |
| 制品 | 构建产物、版本包、依赖缓存 | 依赖存储与访问凭据 | 是/否 |
| 文档 | 设计文档、接口说明、操作手册 | 依赖权限与目录结构 | 是/否 |
| 权限配置 | 用户、角色、项目成员关系 | 通常需最先恢复 | 是/否 |
范围确定后，为每类对象设定RTO（恢复时间目标）与RPO（恢复点目标）。RTO的依据是业务能容忍多长的不可用时间，例如代码仓库不可用会直接阻断提交与发布，通常要求更短；RPO的依据是能接受丢失多长时间内的数据，例如工作项允许回退到最近一次备份点，而代码仓库要求尽量接近故障前状态。恢复依赖顺序也要写进表里：权限与用户先恢复，项目结构其次，业务数据再次，流水线与制品最后。
全量演练覆盖清单内全部对象，适合年度或重大变更后执行；单域演练只覆盖一个对象域，例如只验证代码仓库与关联工作项的恢复，适合季度或新备份策略上线后执行。本轮演练在范围表中明确标注覆盖项，未覆盖项写明原因和计划轮次。
演练目标要写成可判断的句子，避免“验证备份可用”这类无法判定的表述。例如：“代码仓库A在故障宣告后4小时内恢复到指定提交，最近一次提交与工作项关联关系完整”“工作项数据恢复到故障前24小时内的状态，状态流转记录无缺失”。目标句包含对象、时间、恢复点和核验口径，演练结束才能直接对照判定。
交付物是一份演练范围与恢复指标表，字段包括对象、RTO、RPO、恢复依赖顺序、本轮是否覆盖、目标描述。这张表是后续准备、执行和判定的共同依据。
演练前的准备：备份、环境与人员三件事
演练当天才发现备份不可用或环境缺失，是最常见的失败原因。准备阶段要确认三类输入全部就绪，并把结果记录成清单。
备份可用性检查
先核对备份策略与实际执行记录是否一致：最近一次全量备份和增量备份的时间、存放位置、保留周期。然后做完整性检查，例如校验备份文件大小与校验值、尝试在隔离环境挂载或解包、抽查关键表或仓库对象是否存在。检查结论写成“可用/不可用/部分可用”，不可用项在演练开始前修复或调整本轮范围。备份检查的完成标志是：每个覆盖对象都有一份经过验证、可读取的备份点，并记录其时间戳。
隔离恢复环境
恢复环境要与生产环境隔离，避免恢复操作覆盖生产数据或造成地址冲突。准备内容包括：独立的计算与存储资源、独立的网络与访问入口、必要的账号与凭据、与生产一致的软件版本。环境就绪的完成标志是：能在隔离环境中启动平台服务并登录，且生产环境不受影响。若资源有限，可只搭建本轮覆盖对象所需的最小环境，但要在准备清单中写明裁剪范围。
人员与脚本
确定四类角色：演练指挥、执行、核验、记录，并留下联系方式与备用人员。准备演练脚本，按时间顺序写明每一步的输入、操作、预期输出和完成标志；同时准备时间窗口与回退预案，明确超时多久判定失败、失败后如何停止并恢复隔离环境。脚本和预案在演练前由指挥与执行共同确认，避免执行时临时发挥。
交付物是演练准备清单与角色分工表，清单逐项打勾，未就绪项标注责任人和补齐时间。
演练执行步骤：从触发到恢复的完整流程
执行阶段按固定顺序推进，每一步都留下时间戳和结果记录，演练记录本身就是复盘和判定的证据。
触发与宣告
输入是已批准的演练方案和时间窗口。指挥宣布演练开始，记录员记下开始时间，通知执行、核验和相关业务代表。完成标志是：所有角色确认收到开始通知，演练时钟启动。
恢复执行
按依赖顺序恢复：先恢复账号与权限配置，再恢复项目结构与工作项，然后恢复代码仓库、测试用例、文档，最后恢复流水线配置与制品。每一步记录开始时间、结束时间、使用的备份点、操作人和结果。遇到依赖未就绪时暂停并记录，不跳过顺序强行恢复。完成标志是：覆盖对象全部完成恢复操作，每步耗时可查。
业务核验
核验由业务代表按真实使用场景执行，而不是只看服务是否启动。典型动作包括：登录并确认权限正确、拉取代码并核对指定提交、查看工作项及其状态与关联关系、打开测试用例、触发一条流水线并确认运行结果、访问文档。每个动作记录预期结果与实际结果，附截图或日志作为证据。完成标志是：核验清单全部执行完毕，通过项与异常项分别标注。
异常处置
恢复失败或超出预定时间时，记录失败步骤、错误信息、已尝试的处理方式，并按回退预案停止演练或缩小范围。异常不隐藏、不现场“修到通过”后补记，保持记录与真实过程一致。完成标志是：每个异常都有编号、现象描述和处置结论。
结束宣告与归档
指挥宣布演练结束，记录员记下结束时间，汇总执行记录、核验证据和异常清单，归档到统一位置。完成标志是：演练执行记录包含步骤、耗时、结果、异常四类信息，且时间戳完整。
演练的范围、整改项和记录如果散落在个人文档里，下一轮很难追踪。ONES 可以把演练范围表、准备清单、异常项和整改任务建成工作项，按负责人和期限跟踪状态，核验证据作为附件留存，复盘时直接按工作项汇总未闭环事项。
角色与交付物：谁在演练里做什么
演练变成单人操作，核验就容易流于形式。四类角色各自承担明确职责，并对应固定产出。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 演练负责人（指挥） | 批准范围与RTO/RPO，宣布开始与结束，裁决异常时是否回退 | 签批的范围与指标表、开始与结束宣告记录 |
| 平台运维/管理员 | 执行备份检查、环境准备与恢复操作，记录每步耗时 | 备份检查结论、恢复操作记录 |
| 业务代表 | 按真实场景核验数据与功能，给出通过或异常结论 | 业务核验清单与证据 |
| 记录员 | 留存时间戳、操作步骤、证据与异常，汇总执行记录 | 演练执行记录、异常清单 |
角色可以由同一人兼任，但核验角色应与执行角色分离，避免自己恢复自己核验。每个角色的交付物在演练结束后统一归档，作为通过判定和下一轮改进的输入。
示例：一次单域灾备演练怎么走完
以下为演示情景，用于说明流程如何落地，不代表任何真实平台的实际表现。
场景设定：某研发平台的代码仓库A与关联工作项在故障后需要恢复，本轮为单域演练，目标为“代码仓库A在4小时内恢复到指定提交，关联工作项状态完整”。
- 范围与指标：覆盖代码仓库A、关联工作项、相关权限配置；代码仓库RTO 4小时、RPO 1小时；工作项RTO 4小时、RPO 24小时；测试用例、制品、流水线配置本轮不覆盖。
- 准备：确认最近一次备份可用并通过校验；搭建隔离环境并完成登录验证；确定指挥、执行、核验、记录各一人；脚本写明恢复顺序与超时回退条件。
- 执行：09:00宣布开始；09:10恢复权限配置；09:40恢复项目结构与工作项；10:30开始恢复代码仓库；12:20仓库恢复完成；12:30起业务代表核验。
- 核验证据：拉取代码后核对指定提交的哈希与提交信息一致；查看工作项状态、负责人和与提交的关联关系完整；触发一条关联流水线，运行结果正常。
- 复盘发现：代码仓库恢复耗时接近RTO上限，主要时间花在仓库对象逐个校验；工作项附件未纳入本轮备份范围。整改方向分别为优化校验脚本并行度、将附件纳入下一轮备份范围并补充到范围表。
这个示例的关键在于每个节点都有时间、有证据、有结论。迁移到自身平台时，替换对象名称和指标数值即可，流程结构保持不变。
完成检查：判断这次演练是否算通过
演练结束不等于通过。用一张判定表逐项核对，把未达标项转成整改任务，才算完成闭环。
| 检查项 | 通过标准 | 结论 |
|---|---|---|
| RTO达成 | 每个覆盖对象的实际恢复时间不超过设定值 | 通过/未通过 |
| RPO达成 | 恢复后的数据点不早于设定的恢复点要求 | 通过/未通过 |
| 数据完整性 | 提交历史、工作项状态与关联关系、权限配置无缺失 | 通过/未通过 |
| 业务可用性 | 核验清单中的登录、拉取、查看、触发等动作全部成功 | 通过/未通过 |
| 异常闭环 | 每个异常都有整改负责人和完成期限 | 通过/未通过 |
| 记录归档 | 范围表、准备清单、执行记录、核验证据已归档 | 通过/未通过 |
判定规则建议提前约定：全部检查项通过为通过；RTO/RPO未达成或数据完整性缺失为不通过；仅记录或归档类问题可判为有条件通过，但须限期补齐。未通过项进入整改清单，写明问题、整改动作、负责人和期限，并在下一轮演练中优先复验。
最后安排下一轮演练的时间与范围：单域演练可按季度轮换对象域，全量演练按年度或重大架构变更后执行；本轮未覆盖的对象和整改项列入下轮范围表。整改任务在ONES中按工作项跟踪，复验时直接对照状态和证据，形成“演练—整改—复验”的连续记录。
常见问题
研发平台灾备演练第一次做，应该选全量还是单域？
首次演练建议从单域开始，选一个恢复依赖较少、业务影响清楚的对象域，例如代码仓库与关联工作项。单域演练投入小、步骤可控，能先验证备份可用性、隔离环境和角色配合是否顺畅。等单域流程跑通、整改项闭环后，再安排覆盖全部对象的全量演练。全量演练适合年度安排或重大架构变更之后执行，因为它对时间窗口、环境和人员的要求更高。
RTO和RPO定不出来怎么办？
可以先从业务影响倒推，不必一次定到精确值。问两个问题：这类数据不可用时，哪些工作会停、停多久可以接受；这类数据丢失多长时间内的变更可以接受。先给出一个区间和依据，写进范围表，演练后再根据实际恢复耗时和业务反馈调整。关键是每个覆盖对象都有明确的数值和判定口径，而不是停留在“尽快恢复”这类无法对照的表述。
演练中恢复失败，是继续修到通过还是按预案停止？
按演练前约定的回退预案处理。超时或关键步骤失败时，记录失败步骤、错误信息和已尝试的处理方式，由演练负责人裁决是停止还是缩小范围继续。现场把问题修到通过再补记，会让记录与真实过程不一致，复盘时无法判断真实恢复能力。失败本身是有价值的演练结果，应进入异常清单并安排整改。
核验环节只看服务启动、能登录，够不够？
不够。服务启动只说明进程起来了，不能说明数据恢复到位。核验要由业务代表按真实使用场景执行：拉取代码并核对指定提交、查看工作项状态与关联关系、打开测试用例、触发一条流水线确认运行结果、访问文档并确认权限正确。每个动作记录预期结果与实际结果，附截图或日志作为证据，这样通过判定才有依据。
演练记录和整改项用什么方式管理比较好？
关键是让范围、异常和整改项能被持续追踪，而不是散落在个人文档里。可以把演练范围表、准备清单、异常项和整改任务建成工作项，按负责人和期限跟踪状态，核验证据作为附件留存。ONES 可以作为这类跟踪的载体，复盘时按工作项汇总未闭环事项，下一轮演练直接对照复验。工具选择服从团队现有习惯，重点是记录可查、责任到人、期限明确。
