灾难恢复流程图（IT 系统）
IT 灾难恢复流程的泳道图：启动标准、按 RTO 与 RPO 排定优先级、切换、数据恢复、验证，以及回切至正常运行。
什么是灾难恢复流程图（it 系统）流程
灾难恢复是连续性工作中技术的那一半：在普通事件处理无法解决的事件之后，把 IT 系统和数据恢复回来，例如站点损失、存储故障，或托管服务商发生的大规模中断。它不是业务连续性。连续性计划涵盖的是系统停摆期间组织如何继续经营（人工替代方案、备用场地、人员、供应商、对客户的承诺）；而本流程涵盖的是服务器、数据，以及它们恢复回来的先后顺序。两者只在一个点上衔接：这里使用的恢复优先级应当来自连续性计划中的业务影响分析，而不是来自工程师在中断当中的临场判断。
它同样不是事件管理流程，也不是安全事件响应。正常运营中单个服务出故障，仍然留在服务台，永远不会走到启动这一步。如果中断由攻击造成，安全事件响应流程会与本流程并行运行，并决定何时恢复才是安全的，因为在范围尚未弄清之前就重建，可能把访问权重新交回给攻击者，或者毁掉证据。在流程的另一端，回切是一次有计划的变更，属于变更控制，而不属于应急流程。
多数灾难恢复计划都栽在同样的那几件事上：没有商定的启动标准，于是人们花几个小时争论这次算不算；恢复顺序随意，于是应用先于它们依赖的身份与数据库服务上线；恢复出来的数据还没有人验证就切给了用户；以及在没有任何应用负责人真正核对过的情况下就宣布服务已经回来。本模板把流程铺在五条泳道和五个阶段上，包含一个启动决策、一次带重做回路的完整性校验，以及一道由应用负责人而不是由做恢复工作的基础设施团队把守的验证关卡。
本流程图涵盖的内容
本模板包含
- 五条泳道，每个步骤都有明确责任人（检测／运维、灾难恢复协调人、管理层、基础设施团队、应用负责人），横跨五个阶段：检测与评估、启动、恢复、验证，以及回切与复盘。
- 检测与评估阶段：“检测到破坏性事件”接入“评估影响与受影响系统”和“升级至灾难恢复协调人”，然后才谈得上宣布任何事情。
- 灾难恢复协调人泳道中的“是否满足灾难恢复启动标准？”决策：不满足的分支终止于“按普通事件处理”，满足的分支进入管理层泳道的“批准启动灾难恢复”，把宣布权留在被授权的角色手里。
- 动员与优先级排序：“动员灾难恢复团队”，然后“按 RTO 与 RPO 排定系统优先级”，并附注说明每个目标的含义，以及为什么共享依赖（身份、网络、数据库）要先于需要它们的应用恢复。
- 基础设施泳道中的恢复工作：“切换到恢复站点”“从备份恢复数据”，以及“数据完整性是否已验证？”决策，其失败分支走“从更早的副本恢复”，并回到恢复步骤形成回路。
- 验证与结案：“执行应用验证检查”，以及“服务是否运行正常？”这道关卡把故障退回给基础设施团队；随后是“向用户通报已恢复的服务”、回切规划、解除响应状态、事后复盘，以及更新后的计划与测试排期。
何时使用本模板
- 编写灾难恢复计划，或连续性计划中的信息通信技术恢复章节，让每个步骤的顺序和责任人都放得进一页纸。
- 在凌晨三点的中断把问题逼出来之前，先商定启动标准，以及谁握有宣布灾难的权力。
- 准备一次灾难恢复测试或桌面推演：其中的决策、回路和交接给了你们一份检验计划的脚本。
- 向可能要在计划编写者不在场的情况下执行部分恢复工作的值班工程师做交底。
- 向审计师或客户说明信息通信技术恢复既有文档也有演练（图示是流程的证据，它本身并不能证明符合任何标准）。
运作方式
把泳道改成你们真实拥有的角色
把检测／运维、灾难恢复协调人、管理层、基础设施团队和应用负责人换成你们真实的角色：网络运营中心或监控团队、IT 服务连续性经理、危机值班表上的高管、平台与数据库团队、具名的服务负责人。规模较小的组织常把协调人和基础设施两条泳道合并；如果一条泳道里没有人，就删掉它，而不是留着一条无人承担的泳道。
把你们的启动标准写到决策上
让“是否满足灾难恢复启动标准？”客观到有人能在压力之下直接套用：主站点无法进入、预计中断时间超过某个一级系统的 RTO、主存储或数据库在原地无法恢复。写明被授权启动的角色和一位替补，并记录在工作时间之外如何联系到他们。
为每个系统附上真实的 RTO 与 RPO 数值
这些目标应取自业务影响分析，而不是取自基础设施目前能做到的水平，并按层级列在“按 RTO 与 RPO 排定系统优先级”旁边。除了优先级顺序，也要记录依赖顺序，因为一个一级应用在它下面的身份、网络和数据库服务起来之前，根本无法验证。
写清楚你们真实的恢复机制
对复制式基础设施、温备站点、第二个云区域和从备份介质重建来说，“切换到恢复站点”的含义各不相同。把机制、操作手册链接、凭据与应急账户的存放位置，以及任何需要人工执行的 DNS 或网络变更写进方框注释，让这张图在恢复过程中也用得上，而不只是在复盘时才拿出来看。
定义“完整性已验证”是什么意思，以及由谁判定
把“数据完整性是否已验证？”背后的检查项定下来：记录条数、一致性与引用完整性检查、应用级冒烟测试、与最后一个已知良好状态的比对。决定“更早的副本”指的是什么、在升级上报之前你们尝试几次恢复，并注明每往回退一步，你们最终要按 RPO 申报的数据丢失量就会增加。
补上回切，然后演练这张图并保留版本
确认回切路径与你们的实际做法一致：时间窗口、从恢复站点回同步数据、变更控制审批，以及正式解除灾难恢复状态的时点。然后演练这张图，在事后复盘中把你们实际达成的恢复时间和数据丢失量与目标对照，并发布获批版本，让大家演练的修订版就是他们在真实事件中会遵循的那一版。
常见问题
灾难恢复和业务连续性有什么区别？
业务连续性关注的是在中断期间用一切可用手段让组织继续交付产品与服务：人工替代方案、备用场地、人员调配、备用供应商、客户沟通。灾难恢复是其中的 IT 部分：恢复组织赖以运转的系统、数据和基础设施。优先级由连续性工作设定，因为业务影响分析决定哪些活动最重要、以及它们最长能被中断多久；灾难恢复把这些时限继承为 RTO 与 RPO 目标并去达成。没有连续性输入的灾难恢复计划，往往会先恢复最容易恢复的东西。
RTO 和 RPO 到底是什么意思？
RTO，即恢复时间目标，是一个系统或服务必须重新可用的目标时间，从中断发生起向前计算，而不是从有人签下启动表单的那一刻起算。RPO，即恢复点目标，是数据必须被恢复到的那个时间点，从中断向回计算，因此实际上它就是组织愿意接受的最大数据丢失量。两者驱动的投入并不相同：RTO 取决于你们把基础设施拉起来的速度（备用容量、自动化、演练），而 RPO 受限于数据被复制出去的频率，因此无论恢复跑得多快，每晚一次的备份都支撑不了短于约一天的 RPO。这两个术语在 ISO 22301 等业务连续性标准中都有定义。
灾难恢复的启动应由谁批准，什么时候批准？
启动权应当落在能够承担切换成本与风险的角色上，通常是一位高管或危机负责人，并配一位具名替补和一条成文的非工作时间联络路径。本图刻意把它与灾难恢复协调人的角色分开：协调人评估并提出建议，管理层批准，然后由协调人执行恢复。触发条件应当事先写好，并且能够用中断早期就拿得到的事实来检验，因为代价高昂的错误不是启动得太早，而是在 RTO 时钟一直在走的时候，花三个小时讨论这次算不算。
如果恢复出来的数据没通过完整性校验会怎样？
本图选择形成回路，而不是硬着头皮往前推：“数据完整性是否已验证？”的失败分支通向“从更早的副本恢复”，再回到恢复步骤，于是验证会重新执行一次。这个回路正是 RPO 在真实条件下受到检验的地方，因为每往回退到一个更旧的副本，你们最终要申报的数据丢失量就更大；到了某个程度，诚实的答案是目标无法达成，业务方需要被告知他们必须手工重建哪一段时间的数据。值得事先商定的是：你们尝试几次、谁有权接受比 RPO 更差的恢复点，以及这个缺口如何记录。
灾难恢复流程应该多久测试一次？
频率要足以让计划反映当前的环境，而且结果要写下来。多数组织采用组合做法：对备份做频繁的恢复校验，全年做若干次组件级或部分切换测试，并按固定周期做一次更完整的演练，通常是一年一次，受监管行业和关键服务会被期待做得更多。比间隔更重要的是测试了什么。一份从未真正挂载并读取过的备份什么也证明不了；而一次跳过验证与回切步骤的演练，往往会掩盖真实事件中最伤人的那两个问题：应用负责人发现了没人预料到的故障，以及没有商定好回到主站点的路径。