灾难恢复测试及其对您的业务的重要性

教程

无论今天的硬件和软件变得多么可靠，机器仍然因不同原因而容易出现故障。当它们崩溃时，系统可能会下线，数据可能会长时间不可用。即使系统恢复在线，有时数据也无法恢复，永久丢失。减轻这些风险的最可靠方法是制定一项全面的灾难恢复（DR）计划。

A disaster recovery plan is a set of procedures that must be undertaken to restore data and workloads within set time limits. This detailed DR checklist includes mechanisms put in place in advance to prepare for different disaster scenarios.

统计数据显示，全球95%的公司投入了大量资源来规划最坏的情况，包括灾难恢复。然而，只有78%的公司使用灾难恢复测试来验证他们的计划是否真正达到了目标。继续阅读，了解什么是灾难恢复测试以及如何为您的组织制定一项DR测试策略，以确保系统在任何事件中可用性和业务连续性。

什么是灾难恢复测试？

灾难恢复测试是验证DR计划步骤的过程，以确保计划可以成功实施，并且关键应用程序和数据可以在中断后恢复。测试灾难恢复计划的目的是确保业务运营和关键服务在事件期间和之后可以维持。

灾难恢复测试在最全面的形式中涉及模拟IT故障或任何其他类型的业务中断，以评估DR计划。DR测试的主要目标是检查组织是否可以满足灾难恢复计划中设定的恢复时间目标（RTO）和恢复点目标（RPO）。您应了解RPO与RTO并为每个应用程序和VM设置它们。DR测试还提供了系统在任何部分基础设施变得不可用时的行为情况。这些信息可以帮助您细化组织的DR计划，并在真正的中断发生之前修复任何弱链。

请记住，灾难恢复测试计划不应仅限于DR计划的技术组件。测试每个参与灾难恢复的员工理解他们的角色并在中断期间访问他们需要的资源同样重要。

灾难恢复计划测试应定期进行，最好每年几次。IT环境定期变化，软件被废弃，新应用程序被介绍，或硬件被替换，这将需要相应地更新您的DR计划。DR测试过程可以成为维护例行程序和员工培训的一部分。

灾难恢复测试的重要性

未测试灾难恢复计划的风险是数据丢失和系统访问受阻。您可以为业务投保以弥补损失，但任何保险政策都无法取代由事件造成的数据丢失或对业务长时间停机的影响。确保持续正常运行和可用性的唯一方法是制定灾难恢复计划并定期进行测试。如果您仍然不确定测试灾难恢复计划的必要性，以下是在事件发生之前测试灾难恢复计划可以帮助您实现的目标清单：

发现灾难恢复计划中的空白或缺陷
确保您在恢复过程中采取了正确的操作顺序
验证恢复目标是现实的并且可以实现
最小化数据丢失
执行灾难恢复团队的操作，并确保每个成员都理解自己的角色
在为时已晚之前引入更新和修复

灾难恢复测试过程的组成部分

A DR test should be planned to ensure that it brings results and helps improve DR readiness. This means that disaster recovery test objectives should be clear, and you should have a specified timetable for how often to conduct tests, the criteria for success, evaluation of results, and steps to address gaps and any DR failures. Let’s go over these components in more detail.

设定灾难恢复测试范围

灾难恢复测试范围涉及一系列应在测试过程中满足的假设和期望。设定测试范围应包括：

确定将包含在灾难恢复测试中的系统和功能
定义将要测试的灾难恢复过程类型：从备份中恢复完整的机器、切换到灾难恢复站点等
事先确定例外和限制，因为您的灾难恢复计划的某些部分可能无法按计划执行
指定包含在灾难恢复测试过程中的部门和人员
定义将进行测试的场景：主要网站故障，勒索软件攻击，连接丢失，服务器/数据库故障等。

审查灾难恢复计划

在进行测试之前，您应该审查灾难恢复计划。灾难恢复测试应以有组织的方式进行，重点是组织的政策和实践。因此，灾难恢复团队应与高级管理层会面，审查现有的灾难恢复计划，并确定应根据业务的当前状态实施的任何更改或更新。这些包括诸如引入新的硬件或软件产品，业务扩展，预算削减，人员流失等因素。

DR测试频率

鉴于当前的IT环境具有高度动态性，确定审查频率对于不断更新您的灾难恢复计划至关重要。一些组织每年审查和更新其灾难恢复计划一次。然而，最有效的策略是在组织的关键组件发生变化时更新（并重新测试）您的灾难恢复计划。尽管灾难恢复测试可能耗时且成本高昂，但您应根据业务需求和资源创建您的测试计划，考虑DR流程的范围。

测试成功标准

您需要设定确定您的虚拟机灾难恢复测试是否成功的标准。理想情况下，当DR计划被证明是有效且可行的时，可以认为VM DR测试已经通过。

然而，即使灾难恢复计划未能通过测试，灾难恢复测试仍然可以被视为成功。这种情况可以帮助您在实际灾难发生之前识别灾难恢复计划中的缺陷，并在下一次计划迭代中解决这些问题。基本上，测试成功的标准是基于预先确定的期望而定义的，这些期望应在灾难恢复测试计划中明确表达，以避免任何混淆。

测试结果评估

虚拟机灾难恢复测试过程的结果提供了公司当前使用的灾难恢复策略的概览。恢复团队可以评估测试结果，并根据确定的问题提出改进或调整灾难恢复计划。

评估灾难恢复测试结果时还应考虑以下指标：

重要任务恢复所需的时间
计划执行的每个步骤执行情况如何（是否发生了任何错误和延迟）
在灾难恢复测试过程中成功完成的操作数量

应对灾难恢复计划进行更改和更新，并进行测试以改进。目标是提供更有效和可管理的恢复过程。

灾难恢复计划的后期审查

在测试模式下运行灾难恢复计划后，建议再次审查您的灾难恢复计划。在灾难恢复测试过程中应记录优点和缺点，以及任何意外结果，并应测量其对业务连续性的影响。这可以显着改进您的灾难恢复策略并提升整体性能。应详细说明解决差距和失败的步骤，并将其添加到下一次灾难恢复计划的迭代中。

在测试灾难恢复计划之前要考虑的因素

灾难恢复团队中的人数：灾难恢复团队至少应该有两个人，以避免“单点故障”的问题。有了多个团队成员，如果一个人在灾难期间无法联系，您可以放心地知道有另一个具有所需知识和访问灾难恢复站点的替代人员。
选择进行灾难恢复测试的时间：通常，灾难恢复测试在工作时间之外进行，因为这个过程耗时，并可能中断业务操作或影响整体性能。然而，这些测试结果可能无法反映灾难恢复计划在实际工作条件下的运行情况。在工作时间内单独测试虚拟机灾难恢复计划的组件可能是一个理想的解决方案。这有助于降低全面测试所带来的系统过载风险。
团队变动或IT基础设施变化：在测试灾难恢复计划之前，请考虑可能使您的DR计划不完整和过时的各种因素。如上所述，这些因素可能包括新的基础设施组件、人员变动等等。及时通知DR团队环境的新变化，并发送简要备忘录，通知员工最新的更新。

灾难恢复测试方法

在本节中，我们涵盖了四种最常见的灾难恢复测试方法。在决定哪种方法适合您的组织，或者是否可以结合这些方法时，请仔细考虑。

检查清单测试

A checklist test of a disaster recovery plan involves reviewing the list of requirements and conditions that must be met. This review is a great starting point as it is the most basic option and involves analyzing the current plan and looking over every point in order to spot the outdated or missing parts. This means verifying, for example, that the backup site is of sufficient size, that the recovery team is notified of the latest updates, that the data protection solution is running, etc.

通过使用这种DR测试方法，恢复团队可以快速审查DR计划，确保每个组件都就位，并确定DR策略中的任何缺失组件。这个过程可以在很短的时间内完成，而且不需要大量的员工参与。

演练DR测试

这种策略的目的是口头逐步进行VM灾难恢复计划的每个步骤，并确定任何问题和缺陷。在这里，恢复团队的所有成员都参与了DR计划的审查和讨论，并提出了建议。

确保每个人都对计划有深刻的理解，并且在DR事件期间了解自己的责任是至关重要的。这种方法只涉及对DR过程的口头讨论。在演练测试中，实际上并不测试或批准您的DR计划的技术方面。

桌面/模拟DR测试

对于桌面测试，组织经历模拟灾难场景，以确定灾难恢复计划是否足够，并且是否可以实现所定义的目标。这种灾难恢复测试方法可以被视为演练测试的延伸。所有团队成员都将面对各种灾难场景，通过讨论他们在这种情况下如何行动来审查。这使您能够在更真实的环境中测试员工的准备情况，并检查您的灾难恢复计划是否能够应对意外问题。

桌面运行通过。DR团队按步骤进行计划演练，就好像真正的灾难已经发生一样。这种灾难恢复测试方法有助于识别潜在的盲点和隐藏的问题。
场景模拟。这种方法涉及在测试环境中执行DR计划，而不会中断生产工作流程。模拟根据具体的恢复场景进行。
完全灾难恢复模拟。这种DR测试方法类似于上述描述的模拟，但这次情景包括主要站点操作的完全失败。该方法涉及在外部位置尝试完全恢复。

并行测试

并行测试允许您测试恢复系统的功能，以确定其是否能够执行业务操作并保护关键流程。主要系统不包括在灾难恢复测试过程中，因为它们预计将支持完整的生产工作负载。这是一种安全且非干扰性的测试技术系统的方法。

全中断测试

A full-interruption DR test provides thorough testing of your VM DR plan. In this case, your DR site assumes the full production workload and the primary site is shut down. The goal is to recover as quickly as possible using the corporate disaster recovery plan. The execution of a full-interruption test should be well thought out as normal operations can be disrupted and it is quite costly.

应记录每个恢复过程。在 DR 测试执行期间识别所有问题和关注点，以便以后解决。应密切观察恢复团队的行动，以准确定位您的 VM DR 计划中的潜在漏洞。全中断测试也是一种适当的灾难恢复测试方法，可检查您的 DR 目标是否可接受和可实现。

您可以考虑在事先不通知员工的情况下进行全中断测试。这样可以更准确地评估团队在灾难发生时的准备情况。

灾难恢复测试的实用提示

测试 DR 计划是一项重要的任务，有时可能会让人感到不知所措。以下 DR 测试提示可以帮助您节省时间并减轻压力：

在安装任何新硬件或软件产品后，立即对其进行测试，以验证其功能和完整性。这也有助于您找到产品的 RTO 并了解它在 DR 过程中的表现。
在设计DR计划之前，执行风险分析（RA）和业务影响分析（BIA）。不断审查这些分析的结果，如果有任何变化，考虑如何在DR策略中反映这些变化。
测试应该在尽可能接近DR场景的情况下进行。通过模拟真实的灾难场景，您可以看到员工在DR环境中如何执行其职责。这也有助于减轻员工的压力，因为员工对各种DR场景更加习以为常，并了解他们所期望的行为。
邀请独立观察员审查您的DR计划并监控测试过程。这种方法确保员工不会采取捷径来快速完成测试。此外，独立观察员可以帮助重新编写DR计划并改进它，通常可以识别出组织内部看不到的问题。
拥有您基础设施中所有应用程序的完整列表。该列表应包括每个应用程序的详细信息、配置、应用程序所有者的联系方式以及您的合同/许可详细信息。
在初期阶段，DR测试应该分部分进行，并且在工作时间之后进行，以免过载系统。在识别任何不足并相应改进计划之后，您可以考虑在工作时间进行进一步的全面测试。