灾难恢复计划制定最佳实践或资源？

Question

我的任务是领导一个关于更新旧的、有点片面的灾难恢复计划的项目。现在，我们只是想解决 DR 的 IT 方面问题。上次他们这样做时，他们通过制造单一灾难（数据中心被淹）并对其进行规划以排除所有其他灾难类型来设置范围。我想采取更全面的方法。我知道这是一个已解决的问题，其他组织已经编写了 DR 计划。

我们的计划是采用我们的 IT DR 计划并继续执行它并说“嘿，这就是我们想要的 IT DR 计划，它是否与大学其他部门正在做的事情相吻合？是否有恢复的服务优先级？要换吗？” 我们很清楚计划的其余部分是什么，我们期待这一切顺利。

我正在寻找的是有关如何确定 DR 计划范围以及我应该考虑哪些问题的指导。您是否有与 DR 计划制定相关的最喜欢的资源、书籍和培训？

Answer 1

确保您有紧急联系人名单。 又名召回名单

它应该看起来像一棵树，并显示谁联系了谁。在分支结束时，最后一个人应该打电话给第一个并报告任何无法联系到的人。

（这可以通过 HR 协调，并用于任何类型的灾难）

Answer 2

一个极好的信息来源是灾难恢复日志（关于）。

可用的社区资源包括其普遍接受的实践 (GAP)文件的当前草案，该文件提供了构成可靠业务连续性计划和流程的流程和可交付成果的出色概述。还提供了一些涵盖各种 DR/BC 主题的白皮书。

这个过程似乎令人生畏，但如果系统地接近您想要结束的地方（如 DRJ GAP 文档），您可以确保优化投入的时间并使最终产品的价值最大化。

我发现他们的季刊也很有趣且内容丰富（订阅）。

Answer 3

如果我们添加我们的想法，一旦每个人都添加了自己的想法，我们就可以从这篇文章中创建一个很好的 wiki。我知道有很多事情要遵循，但我们中的一些人在恢复方面有特定的优先事项。首先，这是我的：

确保您拥有网络的离线/远程文档

Answer 4

对于 DR，基本内容是您的 RTO（恢复时间目标）和 RPO（恢复点目标），大致可以理解为“需要花费多少时间来恢复它，以及我们可以承受丢失多少数据”。在理想情况下，答案是“无和无”，但 DR 场景是一种特殊情况。这些确实应该由您的客户驱动，但由于您是从 IT 角度出发，您可以做出最佳猜测，但要准备好根据需要向上或向下调整。尽可能接近“无和无”的目标是好的，但您需要能够识别收益递减点何时到来。

这两个因素在一年中的不同时间可能会有所不同，并且在不同的系统上可能会有所不同。

我喜欢更全面的方法；列出可能导致 DR 场景的事件很诱人，但这些事件实际上更属于风险分析/缓解练习。对于灾难恢复，事件已经发生，其具体细节不太相关（除非可能影响灾难恢复设施的可用性）。如果您丢失了服务器，则需要将其取回，无论它是被闪电击中、意外格式化还是其他任何原因。侧重于灾害规模和蔓延的方法更有可能产生结果。

如果您发现客户不愿意参与，那么对客户使用的一种方法是从非 IT 角度向他们询问 DR 问题。询问他们的计划是什么，如果他们所有的纸质文件都着火了，这里就是一个例子。这有助于让他们更多地参与更广泛的 DR 事情，并且可以将有用的信息提供到您自己的计划中。

最后，定期测试您的计划对成功至关重要。有一个漂亮的 DR 计划在纸上看起来很棒，但不符合它的目标是不好的。