灾备测试 Skill：验证 RTO、RPO 与业务恢复能力

灾备测试要回答：发生已定义的灾难后，能否用可恢复的数据和服务所需依赖恢复业务流程。仅有备份文件或健康的数据库，都不能证明业务已经恢复。

从恢复合同确定目标

依据已有合同确认主备区域、灾难范围、可接受的数据丢失，以及业务恢复标准。明确 RTO 的起点和什么事件算作“恢复完成”。RTO、RPO 或数据丢失规则缺少来源时，保留为未知，不套用惯例目标。

按依赖顺序串起恢复路径

根据依赖图，将恢复数据点连接到可用的业务流程。

恢复层次	需要的证据
数据	备份时间点、完整性证据、解密及恢复结果
配置与身份	必需配置、密钥、权限和服务身份
网络与路由	恢复区域所需的 DNS、端点、路由和访问条件
业务服务	关键流程、对账记录和用户可见的就绪状态

备份存在不证明其可以解密或已成功恢复。依赖未验证、密钥不可用或恢复结果缺失时，对应路径仍未评估。

根据证据计算 RTO 与 RPO

使用已有事故和恢复记录中的时间戳。RTO 应计算到约定的业务就绪事件，不能只算到进程启动或数据库健康。RPO 要关联灾难时刻与实际恢复的数据点，并保留原始记录和计算过程。起止时间或目标定义缺失时，应报告无法计算。

把账本、支付或订单引用及必要补偿与可接受丢失策略对照。不要用四舍五入掩盖超出 RPO 的数据，也不能仅凭服务健康宣称数据完整。

说明性计算示例：假设有来源的记录把灾难起点记为 10:00，业务恢复标准在 10:45 满足，最近可恢复数据点为 09:55，则按这些事件计算的恢复时间为 45 分钟，恢复数据点距灾难起点为 5 分钟。将两项结果与已批准的 RTO/RPO 及数据丢失规则对照；没有目标、起止事件或时间戳来源时，结果应保持未评估。

将故障切换放在完整恢复计划中

区域故障时，故障切换可能把流量转到备用节点。灾备还要确认所选数据点可用，以及身份、配置、网络、服务依赖和业务对账都已恢复。路由切换成功只是可能的一步，不代表完整恢复目标已经满足。

记录 DRT-## 发现

记录受影响对象或规则、灾难触发条件与范围、目标来源、预期关注点、证据状态、影响与优先级、责任角色、关闭条件及验证方法。恢复时间线要关联故障时间、选定的备份或数据点、恢复阶段、业务就绪事件和完整性缺口。

保持验证边界

把已有备份清单、Runbook、依赖图和过往恢复证据作为静态材料复核。恢复演练应另行设计为获授权、隔离且有停止条件的候选动作；不要调用生产系统，也不要在没有运行记录时声称已经完成恢复。

安装与调用

安装这个 Skill：

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill disaster-recovery-testing

调用 disaster-recovery-testing 时，提供获批准的恢复目标、区域和灾难范围、备份证据、依赖图及业务恢复标准：

请用 disaster-recovery-testing 复核这份脱敏灾备材料。
目标与范围：[批准的 RTO/RPO、灾难起点、主备区域、业务恢复标准]
证据：[备份/数据点、依赖图、恢复时间线、数据完整性和业务对账记录]
请说明哪些目标可计算、哪些仍未评估，给出 DRT-## 候选发现和最小获授权的恢复演练建议。不要把备份存在或进程启动当成业务恢复证明。

常见问题

备份文件存在，就能说明灾备可恢复吗？ 不能。还要核实备份完整性、解密和恢复结果，以及身份、配置、网络、依赖和业务对账。

RTO/RPO 没有定义时，可以套用常见目标吗？ 不可以。把目标和起止事件列为待确认，不要自行设定阈值。

源文件

阅读灾备测试 Prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/disaster-recovery-testing/prompts/disaster-recovery-testing.md。其中定义 DRT-## 发现合同，并要求区分目标对照结果和未验证项。