灾难准备清单

如果灾难即将来临，您的企业会发生什么情况？如果您的业务停顿一天会发生什么？停顿一个星期呢？停顿一个月呢？在某些情况下，如果您的业务无法运作，您的企业就无法生存下去。您并不总是能阻止灾难，但是有了灾难恢复计划（DRP）将防止您的企业在灾难中毁于一旦。
DRP也被称为业务连续性计划，它概述了当发生某个事件，使您企业的工作地点无法继续运作的情况下，应该采取哪些步骤。DRP帮助您的企业继续运作。
使您的公司免于停顿不是件简单的事情，但是仔细地规划并跟进可以让潜在的业务终结事件转变成暂时的业务中断。Gartner Group认为，40%遭遇灾难的企业会在灾难发生的五年内销声匿迹。如果您想成为继续存活的60%企业中的一员，您就必须在灾难发生前准备好DRP，并且在灾难发生时按照计划采取行动。Gartner在灾难准备方面做过许多报告，您可以在下面的网址找到：http://www.gartner.com/1_researchanalysis/focus/aftermath.html。
您的灾难准备的复杂程度取决于几个因素，其中包括企业的规模。在大多数情况下，恢复一个小型企业要比恢复一个大型企业要容易。尽管大型企业比小型企业可能需要更庞大或更复杂的计划，但是无论企业的规模如何，所有灾难计划过程都应该包括附文“灾难恢复检查清单”中所述的那些步骤。
完整的恢复计划包括技术、人员和设施方面的考虑。在这里我对IT方面进行了讨论，但是请记住，您的计划还必须充分地考虑到重要的设施和人员需求。

组建DRP小组
建立DRP的第一步是组建规划小组，一般这是一个管理小组，他们决定DRP中需要什么，并指定计划的每个部分都由谁来负责。在小企业中，DRP小组可能就是公司的拥有者和IT人员。在大型企业里，DRP小组则可能由各部门的领导或者分部的副总裁组成。对于任何企业，DRP小组都需要包括有权做出关键决定的人，以及知道在发生危机时要保护哪些数据和业务流程的人。
在您的DRP中，您需要考虑预算、组织机构和业务流程的需求，DRP小组必须对于如何处理这些需求达成一致。DRP小组可以委派一些职责——例如，小组可能会把某些工作步骤分配给清楚需要做什么的下属——但是DRP小组成员必须有权力做出实施整个计划所必须的决策，这非常重要。

评估您的业务流程
当您有了DRP小组以后，应该开始对业务流程进行评估，确定哪些业务功能是关键的（Mission Critical），哪些是必需的（Must-have），哪些是一般的（Nice to Have），以及哪些是不重要的。首先，您要识别出发生危机时哪些业务流程是企业继续运作所需要的。然后，确定企业恢复这些流程起码需要哪些技术资源。要注意，虽然灾难恢复往往很昂贵（即使对于小公司也是如此），但是当DRP小组确定了最小需求后，您必须准备保留这些资源，并且不能让资源少于最低需求。如果DRP要求保留冗余的硬件和软件系统，而公司高层却决定不为这些资源提供足够的财力或支持的话，这样的DRP是没有意义的。
在决定恢复计划需要什么设备时，您会希望指出哪些投资有双重的作用。例如，您可能会决定需要有备用的网络服务器，但是在等待使用它时您不能利用它的硬件；如果您将备用服务器投入使用，反而会增加需要冗余硬件的系统数目。不过您可以使投资利用率最大化。尽管在线或脱机的数据保护系统对于您的DRP很重要，您也可以使它们成为IT流程的日常部分。在这种情况下，您的恢复计划可能会促使公司添加超出日常备份和恢复所需的功能和部件，因而针对DRP的开支会得到增加。例如，您可能要添置新一代的备份和恢复硬件，这不仅改进了日常的工作流程，也使您更好地为灾难做好准备。
DRP小组还需要决定企业准备从什么级别的灾难中恢复。您的DRP可能会覆盖各种情况，从简单的短期电话或网络中断，到对本地公用和私有基础架构的飓风级的破坏。但是，大多数计划往往主要针对最有可能发生的灾难（如火灾、水灾、天气问题）。请确保指定您的DRP将要应对的灾难级别。

把灾难恢复的IT方面具体化
在后面的“备份恢复基础”一文中，我们谈到了您的数据备份和恢复计划。您希望把数据计划也包括在DRP中。数据恢复计划至少应该能够保护您的关键的（和有价值的）企业数据。注意，在简单数据备份计划中可有可无的一些项目在DRP中可能会变成必需的。例如，您的备份和恢复计划很可能会包括在服务器瘫痪时恢复它们的能力。您甚至可能已经提供了备用的服务器硬件。但是作为良好的DRP的一部分，您可能会希望有能力将服务器恢复到不同的硬件上，这将需要在备份和恢复过程中执行额外的操作步骤。
如果您的企业规模很大，您的DRP可能包括为备用的数据中心制订的计划，并将该中心设置为冗余站点。如果您的企业规模很大，有多个数据中心，您可能会希望每个站点有额外的能力，在某个数据中心无法使用时提供协助。在任何情况下，您都将需要对数据进行异地备份，这样在主要地点发生的数据丢失才不至于导致业务完结。

测试和实施灾难恢复计划
您已经决定了要保护业务的哪些方面，以及如何进行保护。现在您已经准备好测试和实施DRP。这意味着记录每个DRP任务，概括要按什么顺序执行这些任务，指定相关人员负责查看是不是每个任务都已完成，指定由谁来管理整个DRP操作，并测试整个DRP。
当您部署任何额外的硬件或软件时，您将需要复查整个DRP，确定计划的文档与实际的恢复过程一致。这时候应该对计划或者技术做出必要的修改。请记住，在您修改的时候，您会希望重新确认以前的步骤来确保它们仍然适用。制订DRP的过程并非一次性的事件：您需要不断地完善DRP，直到您获得可重复、持续的结果为止。
当您确定DRP能够使用，并且文档准确地反映了整个过程时，您就可以让DRP小组批准最终版本的DRP了。然后，您可以适当地将计划全部或部分地分发给相关的人员。另外，请确保将详细的DRP的打印副本安全地保存在异地。

持续不断的DRP过程
尽管现在您已经有了DRP，但这只是您开始灾难恢复过程的第一步。很少有企业是一成不变的，所以当业务发生变化时，您的DRP也应相应地改变。对于任何关键的业务活动来说，测试和维护DRP是个持续的过程。在您为业务添加新技术时，您必须要考虑新技术会对DRP产生什么影响，必要时应修改DRP和相关的流程。您的业务方式的改变也会影响DRP，因此请确保您修改DRP，来反映业务工作流的变化。请定期地评估您的计划——评估的频率取决于业务变化的速度和频率。只是简单地记录更改并不足够。您的DRP应该与业务模型紧密地集成——任何业务的改变都意味着DRP将改变，并且需要更新DRP和重新测试DRP。
DRP规划小组的工作也在继续。在有了功能完善的DRP以后，小组的组成成员可能会有些变化，但是DRP小组还是需要组织DRP的管理和维护。定期地举行DRP小组会议可以让不同的部门有机会参与，有机会为DRP及其流程目前和将来的更新提供建议。DRP小组的持续参与还可以提醒业务人员拥有保持更新的灾难恢复计划的重要性。
研究灾难恢复的各个分析员都注意到，几乎50%的大型公司缺乏某种形式的全面DRP，而如果把小型公司也算在内的话，这个数目将高达80%（要了解更多信息，请访问http://www.gartner.com/1_researchanalysis/focus/aftermath.html）。任何一个企业，无论规模大小，都能从DRP中获益。确定在紧急情况发生时需要什么能让您在危机中掌握控制权，否则您的企业将可能会无法继续经营。实施DRP，哪怕是小规模地实施，也能决定企业的生死存亡。

附文：
灾难恢复检查清单

步骤1：组建灾难恢复计划（DRP）规划小组
• 选择有决策审批权，以及有足够的权限收集公司范围内所有信息的小组成员。
• 定义小组成员的职责。
• 建立清晰的组织架构图，说明灾难恢复计划的每个方面分别由谁负责。

步骤2：评估您的业务流程
• 评估所有业务流程并按重要程度排序。
• 确定哪些业务流程、技术、系统和应用程序必须恢复才能让业务继续运作。
• 确定您希望达到的灾难保护级别。

步骤3：确定哪些IT流程将整合在DRP中
• 评估现有的备份和恢复流程。
• 将现有流程整合到DRP中。
• 必要时改进现有流程。

步骤4：实施和测试DRP
• 记录拥有灾难恢复角色的人员的所有职责与义务。
• 部署任何需要的额外硬件或软件。
• 通过测试一遍灾难恢复流程来测试DRP。
• 根据测试的反馈，修改DRP以便反映实际流程。
• 在分发最终的DRP文档前先获得最后的管理层审批。
• 将最终的DRP文档分发给所有相关人员。
• 维护所有DRP文档，并将文档的打印副本安全地保存在异地。

步骤5：维护持续不断的DRP过程
• 定期举行DRP小组会议，这样不同的部门可以相互沟通，并不断地提供信息，使DRP保持更新。
• 进行定期的DRP测试。
• 定期对DRP进行更新以便加入对业务流程或技术架构的修改。
• 定期对技术和工作流程进行评估，并相应地更新DRP。
• 将所有的DRP更新和维护程序的责任分配给关键人员，并指定一个（或一组）核心人员负责反复校对各种修改。