我被委托领导一个项目，该项目涉及更新一项旧的、有些片面的灾难恢复计划。目前，我们只是在考虑解决灾难恢复的 IT 方面的问题。上次他们这样做时，他们通过虚构一个灾难（数据中心被洪水淹没）并为此制定计划，排除所有其他灾难类型。我想采取一种更全面的方法。我知道这是一个已解决的问题，其他组织已经制定了灾难恢复计划。
我们的计划是采用我们的 IT 灾难恢复计划并继续推进，然后说“嘿，这是我们想要的 IT 灾难恢复计划，它与大学其他部门正在做的事情相吻合吗？您是否希望更改恢复服务的优先级？”我们对计划的其余部分有一个很好的想法，我们期待这一切顺利进行。
我正在寻找有关如何确定灾难恢复计划范围以及我应该考虑哪些问题的指导。您是否有与灾难恢复计划制定相关的最喜欢的资源、书籍和培训？
答案1
可用的社区资源包括其普遍接受的做法 (GAP)文档，其中提供了构成可靠业务连续性计划和流程的流程和交付物的出色概述。此外还有几个白皮书涵盖各种 DR/BC 主题。
这个过程看起来很艰巨，但如果系统地进行，并明确最终目标（如 DRJ GAP 文档），您就可以确保优化投入的时间并最大化最终产品的价值。
我发现他们的季刊很有趣，内容也很丰富（订阅）。
答案2
确保您有一份紧急联系人名册。 又称召回名单
它应该看起来像一棵树，并显示谁联系了谁。在树枝的末端，最后一个人应该给第一个人打电话，并报告任何无法联系的人。
（这可以通过人力资源进行协调，并用于任何类型的灾难）
答案3
如果我们添加自己的想法，那么一旦每个人都添加了自己的想法，我们就可以从这篇文章中创建一个不错的 wiki。我知道有很多人可以效仿，但我们中的一些人在恢复方面有特定的优先事项。首先，这是我的：
确保你拥有网络的离线/远程文档
答案4
实际上，“单一事件”开发模型作为第一步是一个好主意。原因之一是它使规划工作更加现实和有针对性。从始至终为洪水做好规划。然后假设发生另一起事件（例如，长期停电），将该计划应用于该事件，并修复出现的问题。经过几次迭代后，该计划应该相对稳健。
一些想法... - 一定要考虑到无法使用的人员。如果发生洪水，您不能假设所有相关人员都可以使用。有人可能在度假，受伤或与家人打交道。
- 为沟通问题和弱点制定计划。有多个号码和多种模式。
- DR 计划需要指挥链。知道谁做决定至关重要。
- 该计划需要广泛分发，包括场外和离网。它需要在灾难期间可访问！