如何通过七个步骤制定数据灾难恢复计划

关键要点

• 灾难恢复计划有助于在发生自然灾害、网络攻击等事件后，最大限度减少数据丢失与系统停机时间。

• 恢复时间目标 (RTO) 和恢复点目标 (RPO) 是衡量灾难恢复计划成效的核心指标。

• 使用简单的七步框架，可更轻松地制定贴合组织自身需求、行之有效的恢复计划。

• Jira Service Management 和 Statuspage 能够简化灾难恢复流程，并助力企业与客户、利益相关者保持透明沟通。

为网络攻击、硬件故障和类似事件做好准备，有助于最大限度降低此类事件造成的损失。依托数据灾难恢复计划，企业可从容应对各类潜在业务中断。

数据灾难恢复计划明确了事件发生后基础架构与数据的恢复方式，是服务连续性管理的关键环节。了解如何制定数据灾难恢复计划，以最大限度缩短系统停机时间，有效应对各类业务中断。

免费试用 Service Collection，了解如何通过 Service Collection 使用 Jira Service Management 来制定和实施灾难恢复计划。

什么是灾难恢复？

灾难恢复是组织在遭遇网络攻击、硬件故障、自然灾害等破坏性事件后，用于恢复 IT 系统、数据及核心业务运营的一系列计划、流程与技术手段。

其目标是缩短系统停机时间、减少数据丢失，帮助组织尽快恢复正常运营。灾难恢复侧重恢复 IT 服务与基础架构；而业务连续性规划的范畴更广，关注组织在中断发生期间及之后如何维持整体业务运转。

灾难恢复如何运作？

制定灾难恢复计划，首先需要识别关键系统、定义恢复时间目标 (RTO) 与恢复点目标 (RPO)、选择恢复策略，并执行预设行动手册以简化事件管理流程。

Jira Service Management (JSM) 等工具可统筹事件处理工作流与恢复任务，从而简化事件管理；而 Statuspage 能够向客户及利益相关者推送实时更新，以优化事件沟通工作。

灾难恢复可应对哪些威胁与故障？

每种类型的数据灾难都有各自的挑战和影响。了解这些类型的灾难是制定有效恢复计划的第一步。

• 自然灾害：地震、洪水、飓风和火灾等自然事件会对 IT 基础架构造成实际损害。

• 网络攻击：勒索软件、网络钓鱼和黑客攻击等恶意活动会危害数据安全。

• 硬件故障：服务器、存储设备和网络设备等物理组件的故障或损坏会影响业务运营。

• 软件错误：缺陷、错误或故障等软件功能障碍可能会中断运营。

• 人为错误：意外删除数据或错误配置等员工的错误可能会危及数据的完整性。

如何通过七个步骤制定灾难恢复计划

制定灾难恢复计划是持续改进的关键环节。采用以下七步框架，可助力您从文档落地为运营就绪能力。每一步均需形成文档、开展测试，并借助 JSM 等工具，融入 IT 服务管理 (ITSM) 工作流。

第 1 步：定义“灾难”的含义及宣告人

首先，您需要制定清晰的判定标准，区分灾难与需启动重大事件管理的重大事件。可构建一套与 RTO/RPO 阈值关联的简易灾难宣告决策树，以简化判定流程。

快速识别灾难并执行预设应急预案，有助于最大限度降低灾难造成的损失，因此明确的灾难识别标准至关重要。

第 2 步：开展风险评估以识别威胁

下一步是开展风险评估，以识别各类潜在威胁。识别潜在威胁时，需从基础架构、应用、供应商及安全风险等维度全面考量。

应根据发生概率和影响程度对威胁进行评分，以此轻松判定优先级最高的威胁。高影响、高概率的威胁会对组织带来更严重的风险，因此其优先级应高于低影响或低概率的威胁。

第 3 步：开展业务影响分析，以确定优先恢复项

在制定好清晰的灾难界定流程并识别出贵组织面临的潜在威胁后，您可开展业务影响分析，以明确需优先恢复的内容，从而最大限度降低灾难造成的影响。

识别关键业务功能，并将其与组织内的支撑系统一一对应，随后，使用标准化模板表格，为各系统定义 RTO 和 RPO。以此作为基准，衡量灾难恢复计划的有效性。

对系统按优先级划分层级并归类。例如，一级为任务关键性系统，二级系统的业务影响相对较小。这有助于您指导恢复顺序与资源分配，从而确保核心系统与数据尽快恢复。可借助 RTO/RPO 模板表简化此流程。

第 4 步：结合实际场景选择恢复策略

本步骤需根据自身实际情况开始制定恢复策略。对于恢复策略，可在以下两种方案中进行选择：

• 备份与还原：该策略在特定时间点生成数据副本，让您能够访问长期业务记录和历史数据。备份是一种性价比相对较高的数据防丢失手段，同时有助于组织满足合规要求。

• 复制：复制功能可在不同站点间复制、迁移数据，分为同步复制、异步复制及近同步复制。复制可最大限度缩短 RTO、提升业务可用性，但属于成本更高的恢复策略。

您还需在热备站点、温备站点、冷备站点中做出选择：

• 热备站点：是功能完备的完整副本，恢复速度最快；但因基础架构需全盘复制，成本也最高。

• 温备站点：是预先完成配置的站点，仍需部分人工操作（如安装软件）。此类站点在性价比与恢复时长之间取得平衡，但需要一定人工投入。

• 冷备站点：是性价比最优的选择，因为长期维护成本最低。但冷备站点需大量配置工作才能启动并运行，因此恢复时间最长。

第 5 步：编制恢复运行手册并集中存储

当事件发生时，您的运行手册对简化灾难恢复流程、缩短系统停机时间起到关键作用。需为每个核心系统制定清晰、分步的运行手册，包含激活步骤、故障切换程序、验证检查项及责任归属。

可将这些运行手册在统一工作区内集中存储与管理，并直接关联至 JSM 的事件和变更工作流，以便恢复期间快速访问。

第 6 步：搭建沟通工作流，以实现团队协同

沟通在整个灾难恢复过程中至关重要，因此制定清晰的沟通工作流是明智的做法。明确内外部沟通触发条件、利益相关者信息同步频次，以及监管通知要求，以确保组织核心成员及时掌握情况。

可借助 JSM 管理跨团队内部协同与任务可视化，在事件处置期间，利用 Statuspage 发布面向客户的实时更新，让客户及利益相关者及时知晓情况。

第 7 步：测试、评估与优化，为后续恢复计划提供依据

查看灾难恢复计划示例有助于制定自身计划，但定期测试是确保计划有效的最佳方式。应安排每季度桌面演练、每半年部分故障切换测试、每年全面模拟演练，以确保策略在实际操作中有效。基础架构发生重大变更后，还需立即安排重新测试。

跟踪关键指标，例如实际恢复时间与 RTO 对比、实际数据丢失量与 RPO 对比、平均恢复时间 (MTTR)。开展事后回顾，以持续优化运行手册与工作流。

可参考的数据灾难恢复策略

企业可以采用多种数据灾难恢复策略来确保业务连续性，例如：

• 备份和还原：定期备份数据以进行数据灾难恢复，并在需要时进行还原。

• 基于云的灾难恢复：使用云服务提供可扩展的灵活恢复选项。

• DevOps 实践：将灾难恢复集成到 DevOps 管道中，以实现恢复的自动化和简化。

• 高可用性解决方案：实施即使在故障期间也能确保持续运行的系统。

• 事件响应：在定义明确的事件响应计划中，概述检测、分析、控制和从网络安全事件恢复的步骤。

• 冗余：实施冗余系统和组件，防止出现单点故障。

• 复制：将数据和系统复制到辅助位置，以便快速恢复。

• 虚拟化：使用虚拟机快速还原 IT 服务。

最后，通过将 IT 服务管理 (ITSM) 实践纳入灾难恢复策略，可以提高恢复工作的效率和有效性。ITSM 软件可以管理和简化灾难恢复流程，确保进行顺利和全面的恢复。

将灾难恢复计划转化为运营就绪状态

制定灾难恢复计划只是其中一步。灾难恢复计划落地后，需将其融入日常工作流、实现上报自动化，并将 RTO 和 RPO 等恢复指标与服务级别目标保持一致，让计划真正可执行。

Jira Service Management 可简化规范化的事件响应与恢复协同工作；Statuspage 便于与客户及利益相关者保持透明沟通。您还可使用 Jira Service Management 模板库，简化并统一灾难恢复计划。

参与 Jira 实时演示与问答，详细了解 Jira 如何帮助您制定有效的灾难恢复计划。