学步园

 

 

 

业务连贯性规划

本章中，你将会学习以下内容：

· 业务影响分析

· 测试和演习的类型

· 恢复和连贯性规划需求

· 选择、制定和实施灾难及连贯性计划

· 备份的和离线的设备

 

我们不可能预见每一种可能，就如最近的事件所证明的那样。2001年在西雅图发生的地震并没有造成和地震严重程度一样的损失，但是过去许多公司都遭到了未曾预料到的灾难的沉重打击。佛罗里达州迈阿密的安德鲁飓风给当地造成了无以复加的损害，不仅公司的业务受到影响，建筑物也遭到了毁坏，而且许多人在灾害中丧失了生命。日本的神户在遭受了一场意外的地震袭击之后变得满目疮痍。加利福尼亚州2001年夏天由于缺电造成了电力供应的故障，那时候有几家公司显然没有为此做好准备因而造成了损失。世界贸易中心的塔楼在遭到恐怖分子劫持的飞机的撞击之后倒塌，这一事件对许多周围的公司、美国公民和政府造成了很大影响，而且这样的事件大多数人做梦也不会想到。每一年，总有地区有数以千计的公司受到洪水、火灾、龙卷风、恐怖分子和故意破坏行为的袭击。那些能逃过这些劫难的公司一定是做了前瞻性的思考，为最坏的情形做了打算，对可能遭受的损失做了估计，并预先制定好了必要的保护措施。当然仅仅有很少一部分的公司会能这样做，大多数的公司在遇到这样的不幸之后就从此一蹶不振了。

一个组织对一些资源、职员和它们正进行的日常业务有很强的依赖性，因为这些使它们得以健康、愉快地生存并能够获得利润。许多组织拥有有形的资源、知识产权、员工、计算机、通信线路、设备以及为设备提供的服务。如果其中的任何一项受到破坏，或是因为各种原因而无法获得，公司将受到损害。如果有不止一项受到破坏，这个公司就将面临更为困难的处境，而且这些东西缺失的时间越长，公司恢复元气所用的时间也就越长。在遭遇灾难事件之后一些公司就再也无力回天了。然而，那些有预见性、为可能的灾难做出应对计划、不把它们的鸡蛋放在一个篮子里的公司，有更好的卷土重来，并在市场中继续搏击的机会。

 

 

 

 

9.1  业务连贯性和灾难恢复

如果所有东西都炸毁了，我们做什么？我们如何继续下去？

灾难恢复的目的是将灾难造成的影响减少到最小程度，并采取必要的步骤来保证资源、员工和业务流程能够及时地继续运行。灾难恢复和连贯性计划不一样，连贯性计划是用来为长时间的停工和灾难提供处理方法和步骤。而灾难恢复计划的目标是在灾害发生后马上处理灾难及其后果。灾难恢复计划在所有的事情都还处于紧急状态的时候就应该开始执行，这时要勉强拼凑使得关键的系统能够重新投入工作。而连贯性计划考虑问题的方面更加长远一些：原有设施正在修理的时候应该将关键系统转移到另一个地方去，安排正确的人员到正确的岗位上去，在正常秩序恢复之前要改变业务的运转模式，通过各种渠道处理与客户、合作伙伴和持股者的关系，直到一切都恢复正常为止。因此，灾难恢复处理的是，“哦上帝，天正在塌下啊！”而连贯性计划处理的是，“好吧，现在天已经塌下来了，现在我们应该怎样保证营业直到有人把天放回原处呢？”图9-1描述的就是格言式的天在塌下的过程中的情景。

图9-1  灾难是无法预知的，有时候最好的保护就是做一个好的计划

注意  (ISC)²曾经区分灾难恢复计划（disaster recovery plans）和业务连贯性计划（businesscontinuity plans）。在目前的文献上，它们已经把这两种计划合并在一起。本章只讨论与考试相关的内容：业务连贯性。

这本书中的许多章节都始终贯穿着这样一个主题：可用性、完整性和机密性。因为每一章都主要涉及一个话题，这样看待这三个安全特性的角度稍微有所不同。在第4章，我们讨论访问控制，那里可用性指的是资源应该总是可被用户和主体使用，而不应被任何访问控制措施所阻碍。访问控制措施不应该侵犯资源的完整性和机密性。实际上，要保证资源的机密性，也就是说在资源被访问时没有可能改变它的内容，要采取许多步骤。在这一章，我们不再从日常操作这一方面来讨论完整性和机密性，而是从发生灾难后我们要马上采取的措施这个角度来讨论。在灾难发生的时候，如果将其他一切都转移到了另外一个地方而将一个包含有重要信息的服务器还留在原处，那么显然是不合适的。一个公司在遭受一场灾难事件之后会变得比原来脆弱得多，因此这时候重要的是保证保密材料的机密性，以及数据和系统的完整性，尽管这时候场面会十分可怕。可用性在灾难恢复和业务连贯性方面是十分重要的，保证业务运行的那些资源必须能够被那些依赖于它们的人和系统使用。这意味着必须严格进行备份、系统结构必须有冗余性，如果通信线路失效，应该有快捷而可靠的方法来建立其他的通信联系。

 

恢复计划的定义

恢复计划包括制定一个计划，在灾难发生之前就为之做好准备，以期达到减少损失及保证关键系统和人员的可用性。

 

 

在我们谈到业务连贯性计划的时候，一些公司将注意力仅仅放在备份数据和准备冗余的硬件这些方面。毫无疑问，这些都是十分重要的，但是它们还不是问题的全部。硬件系统和计算机需要人们去设置和操作，而数据只有在被其他系统或者外部实体访问的时候才真正发挥了作用。正因为如此，如果我们需要理解商业活动并为之做出应急性的计划，就需要将适当的人安排到适当的位置上，将必要的配置归档，并保证一个冗余的电源供应。对我们来说同样重要的是知道在必要时如何将自动任务进行人工的运行，还需要知道如何安全地对业务过程做出更改，以保证公司的正常运转。如果没有这样的远见，当灾难发生的时候，公司尽管可能有备份的数据和冗余的服务器，但是职员们很可能手足无措，因为他们不知道在这样一个不同的环境下应该如何开始和进行操作。

9.2  将其作为安全策略和纲要的一部分

我们为什么要把业务计划和安全计划结合在一起？答：笨蛋，它们都能保护业务。

在第5章已经提到过，任何公司都必须有一个安全策略、规程、标准和方针。当我们把这些都结合起来的时候，就形成了一个安全纲要，这个安全纲要应该是一个活动的实体。也就是说，因为公司总是在不断地发生变化，因此这个纲要也应该经历变化，以保证它是适合当前情况的、有用的和有效的。

业务连贯性计划应该成为安全策略和纲要的一部分，而不应该独立存在。如果它和其他的安全因素集成起来，它将能够更好地不断更新和完善，并且这样做可以使得灾难恢复和业务连贯性计划中的每一步都考虑到安全的因素。业务连贯性计划是一个有效的安全纲要中的基础的组成部分。

在着手制定一个业务连贯性计划之前，我们需要提出一个很重要的问题，就是为什么要这样做。这个问题可能看起来很幼稚，答案也十分的明显，但是情况并不总是这样。可能会有人认为制定这些计划的原因是为了处理意外的灾难，使员工们能够继续进行手头的工作。大多数公司经营的目的是什么？是为了赚钱，为了利润。如果这些是公司营业的主要目标，那么我们制定的计划也需要有助于这些目标的完成。制定这些计划的主要目的首先是通过提升公司恢复和重建的能力来降低财务上的风险。这包括了减轻灾难所造成损失的目的。

注意  一些小公司可能将连贯性计划作为他们整个安全计划的一部分。一些较大和较复杂的公司应该将连贯性计划的提纲包含在安全计划中，但是应该分别为两个计划维护独立的文档。

业务连贯性计划中最重要的因素是管理层的支持。管理层必须确信这些计划的必要性。因此，实践一次灾难恢复必须获得这方面的支持。这方面要考虑的问题可能包括当前的脆弱性、制度上和法律上的义务、当前恢复计划的状态和一些建议。管理层通常考虑的是成本/利润方面的问题，因此需要初步收集一些数据用来估计潜在的损失。一个公司应该如何为灾难恢复做计划完全是一个商业上的决定，实际实施上也是这样。

9.3  业务影响分析

业务连贯性计划涉及到不确定性和偶然性。制定这些计划的关键是努力考虑到所有可能发生的情况，对潜在的损害和损失做出估计，并制定可行的备用措施以防备这些事件的发生。

在估计所有的威胁时应该进行风险的评估和分析（对风险分析的全面讨论请参考第3章）。威胁可能来自于人为、自然或技术等因素。人为的威胁可能是一个纵火犯、恐怖分子，或是来自于一个可能产生严重后果的简单的过失。来自自然的威胁可能是龙卷风、洪水、飓风和地震。技术方面的威胁可能是数据破坏、断电、设备故障，或是T1通信线路的故障。重要的是找出所有可能的威胁并估计它们发生的概率。在制定这些计划时可能忽略了一些因素，如员工罢工、故意破坏、不满的员工或黑客。这些因素应该放在一起考虑，并应该安排基于情景的练习。这样就保证了在威胁产生的时候，这个计划包括了所有的经营任务、部门和关键的操作。越仔细地考虑这些问题，那么在这些问题发生的时候我们就更有准备。

风险分析的下一步是为每一个可能遭到某种威胁的设备指定一个财产价值，这有助于确立整个计划在经济上的可行性。一旦知道了可能的威胁和潜在的损失的数量，我们就能够从中挑选出前5或前10个最大的风险并将这些信息归档，这样管理层就能够清楚地知道公司面临的主要威胁是什么。

以上的问题都是业务影响分析（BusinessImpact Analysis，BIA）中的一部分，业务影响分析是业务连贯性计划的关键性的第一步。这时应该收集定性的和定量的信息，并加以适当的分析和解释。这样做的目的是弄清楚到底不同的威胁会给业务活动造成怎样的影响。影响可能是经济上的、运作上的或是两方面都有。可以使用标准的调查工具或是对公司中最有知识的人进行问卷来收集这些信息。这样我们就能够得到对可能的业务影响的更全面的认识。

在收集和归档这些信息时应该注意到格式的清晰和易懂，因为这些信息将要呈示给管理层，如图9-2所示。对一件灾害事件的报告有两种方式，一种方式是：发生龙卷风了，真是糟糕；另一种方式是：遭到了龙卷风的袭击，65%的设施受到了影响，公司的计算可能要中断72小时，供电要中断24小时，所有操作需要完全中止76小时，相当于造成每天125 000美元的损失。对于“糟糕”这样的措辞，公司的管理层很难处理，但是如果提供真实的数字，情况就会有很大改观。

图9-2  连贯性计划是基于真实的数字和事实的商业决策

业务连贯性计划应该被包括到正常的业务决策中，这样在业务的其他方面发生变化时，业务连贯性计划也会被考虑到。

注意  在开始制定业务连贯性计划的时候就需要进行业务影响分析，这样就能够确定在灾难或破坏发生的时候，哪些区域所受的财政和运行方面的损失最大。这还可以确定公司需要尽力保全的关键系统，并评估在面临灾难和破坏时公司能承受的中断时间。

我们需要确定基本的业务功能，制定损失标准。业务功能可能包括：

· IT网络支持

· 数据处理

· 会计

· 软件开发

· 薪水发放

· 客户支持

· 订单接收

· 生产计划安排

· 采购

· 通信

这些需要确定的业务功能以及它们的实施部门之间存在相互依赖关系，因此它们应该受到适当的保护，在恢复时也应该按照一定的步骤进行。

一旦认识到威胁和确定了关键的业务功能之后，就能够应用特定的损失标准了，这种标准包括：

· 名誉和公众信心的损失

· 利润的损失

· 竞争优势的损失

· 运行费用的增加

· 违反合同约定造成的损失

· 违反法律和规章制度要求造成的损失

· 收入延迟造成的损失

· 收入损失

· 生产力方面的损失

以上的损失可能是直接的，也可能是间接的，都应该以合适的方式计入。

因此，一个业务连贯性规划小组在考察恐怖炸弹袭击的威胁时，确定最有可能遭到损害的业务功能，所有的业务功能将受到如何的影响，以及直接和间接的损失项目是十分重要的。许多时候一时的破坏可能造成持久的影响。如果说客户支持的业务功能2天不能使用还可以接受的话，那么如果客户支持功能5天都不能使用，公司就将面临破产了。因此，我们需要绘制反映经过一定时间阶段的总损失值的时间-损失曲线，并对它进行分析，如图9-3所示。

时间-损失曲线图

图9-3  要绘制时间-损失曲线来描绘一个公司如果停止营业一段时间所受的损失严重程度

BIA确定了公司赖以生存的关键系统，并估计万一不幸事件发生时，公司可以承受的坚持时间的估计。坚持时间被叫做最大容忍时间（Maximum Tolerable Downtime，MTD）。

下面列出可供参考的MTD级别。

· 无关紧要（non-essential）=30天

· 正常 = 7 天

· 要紧 = 72小时

· 紧急 = 24小时

· 非常危急 = 几分钟到几个小时

每个关键的业务功能和资产都应该给予一个MTD。这个MTD根据公司没有它的时候还能运作的时间来计算。这些估计帮助公司确定需要什么备份流程来保证这些资源的可用性。例如，如果一个T1线路中断3个小时可以使公司损失13万美元，那么他们需要另一个T1线路做备份。如果一个服务器停止10个小时会造成250美元的经济损失，他们可能需要其他服务器做镜像。另一个选择是指望厂商的服务水平协议（SLA），由厂商来保证服务器不会停止超过8个小时。

努力考虑到所有可能发生的事件是必要的，因为这些事件可能会对公司有害。但是我们同时也要想到，不可能考虑到所有的情况，因此不可能为每一个情景提供保护措施。这使我们回想起公司要营业的主要原因，就是为了获得利润。业务连贯性计划应该在经济因素的约束下提供必要级别的安全保护。需要进行全面的风险分析来了解所有可能发生的事件、估计潜在的损失，因为这样才能够得到一份经济上可行的计划。换句话说，如果一个公司有一处设施处于可能发生洪水的区域，如果发生大的洪水就会造成120万美元的损失，那么公司投资200万美元来防范洪水的袭击就是没有意义的。如果公司在可能发生洪水的区域拥有一处设施，而且发生洪水的几率很大，那么首先应该为应付这个灾害而制定计划。公司也有可能遭到外星人的大规模绑架，但是这种灾难不应该在考虑范围之内，因为发生的几率和洪水相比实在太小。

相互依赖

操作依赖于生产，生产依赖于研发，薪水支付依赖于会计，它们都依赖于IT。答：等一等。我要把这个记下来。

也许我们应该将公司看成一个复杂的动物，而不是一个静态的二维实体。它由许多类型的设备、人员、任务、部门、通信和与外部的接口组成。业务连贯性计划的真正复杂性在于理解这些错综复杂的事务以及它们之间的相互关系。一个团队可以制定备份和恢复数据的计划、安装冗余的数据处理设备、训练员工如何人工完成自动任务，以及配备冗余的电源。但是如果这些部分不能够在一个不同的环境下共同工作并生产出产品，那么执行这个计划只能是浪费时间。

在作为结果的计划中应该研究和解决以下这些相互关系和相互依赖的问题：

· 定义基本的业务功能和支持部门。

· 确定这些功能和部门之间的相互依赖。

· 找出所有的会对允许这些部门协同工作的机制造成影响的破坏因素。

· 确定那些可能中断跨部门的通信联系的威胁并将其归档。

· 收集有关这些威胁的定性和定量的信息。

· 准备好用来恢复功能和通信的备用方案。

· 为每一个威胁和相关的信息准备一个原理性的简要陈述。

以上的这些信息，和前面章节解释的其他信息应该被一同送交高层管理机构。这些信息经过他们的审议和批准之后，真正的计划就应该开始制定了。

参考文献

Business Impact Analysis: www.disasterrecoveryworld.com/bia.htm

9.4  业务连贯性计划的需求

对一个公司来说，像制定一个业务连贯性计划那样需要涉及到如此之多问题的事情，主要的需求就是管理支持。重要的是让管理层知道公司的真正的风险在哪里，这些风险造成的后果是什么，每一项风险会造成的潜在损失有多大。没有这种理解，管理层对业务连贯性计划的支持就是空话；有时候这样还不如不要任何的计划，因为对安全的错误理解往往会造成更坏的结果。离开了管理层的支持，就不能保证对这些计划在必要的资源、资金和时间方面的投入，这会使得最后制定出一个很坏的计划，因为它造成了对安全的错误理解。制定计划的失败意味着管理层在理解、眼力和正常的关注职责方面出了问题。

行政管理人员在不同的法律和规章的强制下对公司负责。如果他们在遇到灾难恢复和业务连贯性问题的时候不够努力，没有履行职责，那么他们将可能被持股者和/或客户起诉。一些类型的商务活动需要严格遵守一些法律和规章制度，那么在开始制定计划的时候就应该将这些条例都考虑进去。银行和投资组织需要保证，即使灾难发生，客户的机密信息都不能够被未经授权的个人轻易得到，也不能遭到任何形式的攻击。灾难恢复、连贯性和计划最好以自顶向下的方式工作，而不是以自底向上的方式。

许多公司看不到在灾难恢复问题上花费时间和资源所带来的效益，因为他们正快速发展以紧跟这个动态的和时刻变化的商业世界。那些能够看到这些努力的价值的公司却很难说服高级管理层，因为高级管理层看不到因此带来的利润率和股价的上升，但是一旦灾难发生，而公司又确实做好了适当的准备，那么它的价值是无法估量的。现在的商界要求两种重要的特质：生产大量产品或服务并将其推向市场的干劲，以及对意外的麻烦处理的洞察力和智慧。

恢复计划的策略和目标需要管理层来建立。管理层对公司的观察的立足点比其他的员工要高。他们应该理解保证业务运行和发展的复杂性，以及对这些过程的破坏会如何造成深远的影响。对于管理层来说，重要的是制定业务连贯性计划的总体目标，而且他们必须确定应首先处理事件的优先级。一旦管理层设定了目标、策略和优先级别，其他负责这些计划的员工就将完成剩下的任务。然而，管理层的支持决不仅限于此。他们需要保证这些制定的计划和程序在实际上是有助于生产的和运行成功的，管理层同时要保证这些计划不断地更新，以反映企业的优先级别随时间的变化。

业务连贯性计划的主要目的是改进员工在不同情形下的反应，通过提供书面的步骤指南和参加训练的机会来减少混乱，并帮助在危急关头做出合理的决定。如果在所有警报器都响起的时候，员工知道他们应该到哪里去，而且对他们应该做的事情和如何去做感到很熟悉，那么那些决定如何适当处理此事件的人就可以以一种更加冷静和克制的方式来完成他们的任务。实践证明，这是灾难恢复的关键因素。

注意  另一个要求是进行持续的数据备份。这看起来像一个每天都要做的重复工作，但是当其他任何设备都损坏了，只要公司的信息还保留着，那么这项重复的工作就成为了公司的救生圈，它使得公司还能够继续生存下去。恢复的数据文件能够使公司开始重建。不仅那些至关重要的文件需要备份，那些用来访问这些文件的程序也应该备份。即使在灾难恢复和业务连贯性方面没有其他措施，备份关键的信息和至关重要的记录总是需要进行的。

接下来需要确定计划中的一些参数。这要通过与高层管理人员和来自每个部门的员工进行商议的方式来进行，如图9-4所示。首先，需要确定管理层的考虑和他们所认为的优先级别，这样就可以确定这个项目和计划的大部分范围。然后这个范围可以按照地理、组织或是功能的范畴细分下去。来自管理层和每一个部门的代表都应该被参考到，这样就能够保证覆盖公司所有的有关业务连贯性的考虑和优先级别。

图9-4  需要和每个部门的代表以及管理层的员工商议

9.4.1  制定意外事故计划的目标

我的目标是拥有一艘船，在55岁退休，长更多的头发。答：没出息。

如果你没有确定目标，那么你怎样知道你做了些什么，你的努力是否富有成效呢？目标确定后所有的人就能够知道最后的目的了。建立目标对完成任何任务来说都是很重要的，对业务连贯性计划尤其如此。对目标的定义有助于指引资源和任务的适当分配、必要的策略的制定，并有助于对计划的经济性以及整个计划的理性判断。一旦设定了目标，计划的制定就有了指导方向。那些参与过一些大型项目的人都知道，由于同时又要处理许多琐碎、复杂的细节问题，有时候很容易偏离主题，于是到最后很可能不能完成最主要的目标。确定目标有助于使人不偏离主题，这样到最后就能实现目标。图9-5描绘了达到目标的简要的轮廓。

 

图9-5  目标、策略和行动有着集成的关系

好了，我们现在已经知道目标的重要性了。但是目标可能会是这样：“在地震发生的时候要保证公司的运营。”这的确是一个好目标，但是却不实用。一个实用的目标应该包含以下的一些关键信息：

· 责任  参与到业务连贯性计划中的每一个人都应该将他们的责任以书面的形式说明，这样在混乱的情况下他们会保持清醒的认识。所有的任务都应该被划分和指派给最有逻辑性的个人。这些个人必须懂得对他们的期望是什么，这种认识是通过训练、演习、信息的传达和文档来得到的。这样在发生紧急情况的时候，这个人就不会只是跑出建筑呼救，因为她知道她应该先关闭服务器，然后再跑出去呼救。

· 权利  在危急时刻，知道由谁来负责是很重要的。在这种情形下团队工作十分重要，而且如果拥有一个确定的和可信的领导者，几乎每个团队都会做得更好。领导者必须知道和理解，职员期待他们提供正确的方向带领大家走出困境。权利明晰将有助于减少迷惑并增加协作。

· 优先级别  特别重要的是，要知道什么是关键性的，什么是最好能完成的。不同的部门为一个组织提供不同的功能，而关键的部门应该单独划分出来，以区别于那些离开它们一两个星期企业都可以生存的部门。我们必须知道首先应该恢复哪个部门，随后是哪个，依次类推。这样的话，我们就能够以一种最实用、最有效、最集中的方式来做出努力。同样地，应该建立部门优先级、系统优先级、信息优先级，而且应该为之建立一定的程序。比起知道数据库应该比文件服务器先恢复，这种优先级程序更加必要。总的优先级必须由管理层来设定，当然要在各个部门和IT职员的帮助之下。

·  实施和测试  把每个深奥的想法和制定好的计划写下来固然很好，但是除非它们被真正地实施、执行和测试，否则于事无补。一旦一个业务连贯性计划被制定好，那么它们就必须付诸实际。这些计划应该被归档，并放在危急时刻很容易到达的地方，需要对那些被指派了特定任务的人进行训练并要时刻提醒他们，要安排演习以保证人员适应各种不同的情况。这种演习至少一年要进行一次，这个计划需要不断地更新和改进。

研究表明，65%的计算机系统瘫痪一周以上的企业都不能恢复并重新营业了。如果一个公司不能够通过在其他地方开始业务这种方式有效地并且很快地恢复，它就会失去自己的业务，更重要的是失去了信誉。在这样一个竞争的世界中，客户拥有许多选择，如果一个公司在遭到破坏或灾难之后不准备快速恢复，客户们就会转向其他的供应商并成为他们的客户。

9.4.2  发展团队

我不想让他加入这个队伍，他身上有臭味。

一旦确定需要一个业务连贯性计划，管理高层就必须指定特定的人员来完成必要的任务。对任务的了解可以帮助管理层确定他们为这个团队指定了合适的人员。

接下来这个团队就必须和管理层的员工一道制定这个计划的最终目标，确定在灾难发生时要首先处理的关键业务部分，部门和任务的优先级别。一旦管理层下发了这些指示，这个团队就有了目的、目标和优先级，这就构成了这个计划的雏形。然后这个团队就必须将注意力放在每一种威胁上，注意这些威胁是怎样影响到那些管理层最看重的问题的。他们为每一种情景制定任务和执行步骤，为不同的任务指定不同的员工来负责。在这一步上多花一些时间，可以使我们的计划更加实用、有效和完整。

这个团队可能还需要与外界的供应商联系以建立场外解决方案、冗余通信方案、数据备份服务和冗余的硬件设备。所有的协定都应该归档并备有提纲，以减少危急时刻的混乱。

还有一条很重要，就是要保证团队要么由那些对公司的每个部门都很熟悉的人组成，要么由每个部门的代表组成。这是因为每个部门在功能上都是独一无二的，在面临的风险和威胁上也是独一无二的。最好在制定计划的时候能够将所有的问题和威胁都拿到桌面上来讨论，而如果团队由一些仅熟悉部分部门的人组成的话，这种讨论就不会那么有效。而且很重要的是各个部门的代表不仅要在计划阶段参加，而且在测试和实施阶段也要参加。

业务连贯性计划有几个不同的发展阶段，如图9-6所示。到目前为止我们还仅仅讨论了其中的几个阶段（剩下的将在本章的其余部分讨论），但是，将这些阶段作为一个完整的计划来做一番考察也是十分重要的。

好的计划包括了经过仔细考虑的和有预见性的问题。许多在计划中没有考虑到的问题将会不断涌现；这样计划的灵活性就是至关紧要的。计划以一种系统的方式为发生灾难之后要采取的行动提供了选择，这些行动都已经预先设想好，用来帮助人们以一种实际的和高效的方式来处理灾难事件。

图9-6  业务连贯性计划的发展阶段

9.4.3  企业范围

业务连贯性计划的主要目的是以最小的成本最快地恢复业务。主要计划必须上升到企业范围。在大的公司里，每一个部门都应该有它们自己的业务连贯性计划，因为很难制定一个大的计划，能够为每个部门的使用提供足够的粒度。因此每个部门应该制定自己的计划，然后将其集成到公司的全面恢复计划中去，如图9-7所示。

图9-7  每个部门应该有它自己的灾难恢复计划，并应集成由整个企业的业务连贯性计划中

全面的业务中断和恢复计划应该包括所有的组织元素，确定关键的服务和功能，为紧急状态下的操作提供备用措施，并需要集成每个部门计划。这个计划可以由内部指定的员工完成，也可以由外部的咨询人员来完成，或是两者结合。两者结合的方法能够给公司带来很多好处，因为咨询人员是该领域的专家，懂得必要的步骤、应该问的问题、需要寻找的问题和总体上合理的建议，然而内部的员工十分熟悉公司，而且他们知道某些威胁是如何影响公司的运行的。如果能够覆盖以上的两个方面就很好了，因此在很多时候咨询人员和公司员工的结合是一个很好的解决方案。

至此，我们已经确立了管理层的如下职责：

· 全面的义务

· 策略和目标的设定

· 保证提供必要的资金和资源

· 对制定业务连贯性计划造成的结果负责

· 为制定计划指定一个团队

团队有如下职责：

· 确定必须满足的法律和规章制度方面的要求

· 确定所有可能的威胁和风险

· 估算这些可能威胁的发生几率和潜在的损失

· 进行业务影响分析

· 概括出哪些部门、系统和过程需要在其他项目之前被恢复

· 制定在灾害发生后恢复业务的程序和步骤

现在已经有许多种软件工具可以用来帮助制定业务连贯性计划，这会简化这项工作。这些步骤的自动化能够加快项目进行的步伐，而且计划中许多必要的条目都在文件模板中提供。

9.4.4  计划的发展

计划需要详细叙述我们在前面几节讨论到的那些部分。实际的计划的形式取决于环境、计划的目标、优先级别和确定的风险。在考察了这些项目并将其归档之后，计划的其余部分可以分为以下4类：终端用户环境、备份措施、恢复和重建。根据公司的需要可能还有更多的部分。计划的形式还取决于确定的灾难造成的后果。一类情形可能仅要求将数据中心搬到另一个地方去，另一类可能要求大部分的用户都重新部署，或者通信的中断可能要求实施另一种备用通信方式。

计划变得过时的原因：

· 基础设施和环境的改变。

· 公司结构的重新组织，解雇，合并。

· 硬件、软件和应用程序的改变。

· 计划建立之后，人们感到他们的任务都完成了。

· 员工的周转。

· 大的计划会带来许多维护工作。

· 没有与利润建立直接联系。

保持计划先进性的办法：

· 将业务连贯性计划作为任何商务决定的一部分。

· 在岗位描述中加入维护的职责。

· 在员工评估中包括维护方面的内容。

· 进行包括灾难恢复和业务连贯性文档及步骤在内的内部审计。

· 使用这个计划进行定期的演习。

有一个分为6步的方法来制定一个业务连贯性计划，这将在接下来的章节讨论。每一步的目的都是为了转移潜在的意外事故和灾难，或是减小一个组织可能遭受的损失。

参考文献

Disaster Recovery World: www.disasterrecoveryworld.com

Business Continuity Planning Directory: www.business-continuity-and-disaster-recovery-
world.co.uk

Business Impact Analysis: www.dri.ca/dric_pp3.html

9.4.5  确定业务关键功能

如果没有实现确定，很难保护公司最重要的财产。通常管理高层应该参与到这一步中来，因为他们的观点超出了每个部门经理注意力的职责范围。公司的业务计划通常就决定了公司关键的使命和业务功能。必须为这些功能设定优先级别，这样才能指出什么对于公司的生存才是至关紧要的。

9.4.6  确定支持关键功能的资源和系统

在确定了关键的功能之后，就有必要找出实现这些功能究竟需要那些支持。这些支持不一定只是计算机系统，它们也可能是员工、程序、任务、供给和供应商的支持。我们需要理解的是如果这些支持机制中的一项或几项不可得到了，那么关键功能的执行将瘫痪。做计划的团队必须确定对这些关键功能来说，如果有些资源和系统无法得到，那么将产生什么样的后果。

需要有人来对这些资源进行分析，这样的分析应该由那些理解资源并知道它们是如何为企业提供功能的人来完成。这些人通常应该懂得各种资源之间的相互依赖关系，以及资源缺失造成的真正后果。

9.4.7  估计潜在的灾难事件

在这一步中，我们要确定所有可能的意外事故和灾难，这很具有挑战性。这也是我们愿意请外面的咨询人员来参与制定计划的原因之一：他们能够想到一些我们的团队想不到的问题。我们经常为这些特定的威胁设置情景，这样就能够估计出每一类威胁所有可能的风险。

9.4.8  选择计划策略

这一步包括制定有关如何恢复关键资源和评估应急方案。一个灾难恢复计划通常包括突发事件响应、恢复和重新开始等活动。突发事件响应涉及保护生命和制止进一步的损害。恢复包括为使关键功能重新回到工作状态而采取的一系列必要步骤，重新开始是使公司回到初始工作状态的活动。

 

计划所采取的策略要基于逻辑性、可行性和经济性等几个方面来考虑。为了恢复关键功能，有时候要在某些方面作出牺牲，在制定计划的时候就应该决定这种牺牲。

9.4.9  实施策略

一旦决定了策略，就需要将它们归档，并使它们各就各位。这使得我们的努力从纯粹的计划阶段进入到了实际的实施和行动阶段。

要注意将计划的备份保留在除主站点之外的一个或多个地方。这样一旦主站点被破坏，团队仍然可以获得连贯性计划。

9.4.10  测试和修订计划

我们需要对业务连贯性计划做定期测试，因为环境总是在持续变化，每一次测试都能够带来一些改进。需要专门指派一个或多个员工来履行定期测试和维护这个计划的职责。

该计划的维护工作可以被包含到变更管理程序中，这样环境的任何变化都将一定反映到计划之中。

参考文献

Business Continuity Planning Model: www.drj.com/new2dr/model/bcmodel.htm

Disaster Prevention and Recovery Program: www.so.cc.va.us/its/models/secpl.htm

9.5  终端用户环境

我根本不知道我的网络的工作机制。答：那在出了灾难之后你怎么重建它？

因为终端用户通常都是公司辛勤工作的工人，因此在灾难发生之后尽可能快地为他们提供一个工作环境是十分重要的。这意味这需要理解现有的工作环境，分析其中的关键部分，这样就可能将这些部分加以复制。

有关用户的第一个问题就是如何告知他们灾难的发生，谁将告诉他们什么时候应该去什么地方。应该将管理人员的结构表示成树状，一旦灾难发生，位于树顶的人通知他下面的两个管理者，这两个管理者依次通知下面的三个管理者，如此进行下去，直到所有的管理者都被通知到为止。每一个管理者负责通知他负责的人员，直到所有的人都被通知到。接下来，需要一个或两个人来负责协调同用户有关的问题。这些问题包括指挥他们转移到一处新的设施，保证他们能够得到完成任务所需的必要资源，恢复数据和联络各个不同的组织。

需要了解用户的工作环境，也就是说计划者必须知道一些问题，比如说用户是否能够在单机上工作，或者他们必须连接上网络以完成特定的任务。例如，在一个金融机构中，在单机上工作的用户可能可以完成一些简单的工作，比如说填写账目表格、做文字处理和一些会计方面的工作，但是如果要更新客户资料和与数据库交互，就需要连接到主机系统上。

同时，用户机器上的部分和全部数据可能需要备份和离站保存。计划者需要知道这个事实，并提供在破坏或灾难发生之后取回和安装数据的程序。如果用户系统被破坏了，要确定他们的系统是需要用完全一样的硬件来替代还是使用类似的就可以了。如果备份是通过磁盘镜像完成的，就需要完全一样的硬件，如果备份仅包含文件，那么使用其他的硬件就可以了。

9.6  备份方案选择

备份方案的选择包括硬件、数据、员工和离站设备等方面。应该由每个公司和它的连贯性小组来决定是否以上的所有部分对公司的生存都是必要的。接下来的几个小节解释了如何着手选择这些备份方案。

9.6.1  硬件备份

我不喜欢热站或冷站，我想要一个暖站。答：随你的便。

对物理设备的备份是意外事故计划中的一个重要元素，因为公司对物理设备的依赖性很强。硬件备份的规程中应该包括在场和离站的策略。由于大多数的破坏和灾难都是比较微小的，本地的个别硬件应该能够被快速地和容易地更换。一个公司可能会准备有冗余的设备这样某个设备就能够被快速更换，但是这种方法对大多数公司来说通常都太昂贵。另一种方案是和供应商签订服务和约，这样就能保证设备在一定的小时或天数以内被修好，或者是替代品会在一个合理的时间内运到。

破坏主要分为三类：非灾难、灾难、大灾难。非灾难（nondisater）指的是因设备故障引起的服务的中断。对这种破坏的解决方案可能包括硬件、软件或文件恢复。灾难（disaster）指的是这样一个事件，整个设施在一天或更长的时间内都不能使用。这种情况下通常需要使用备用的处理设施、软件的恢复和从离站备份中的数据恢复。备用的地点必须能为公司所使用，直到主设施被修好而重新投入使用。大灾难（catastrophe）指的是对整个设施的完全破坏。发生这样的情况时需要一个短期解决方案，如一个离站设施；同时需要一个长期解决方案，如可能需要重建原来的设施。

感谢上帝，与非灾难事件相比，灾难和大灾难都十分罕见。处理非灾难事件的通常办法是更换设备和从在场的备份中恢复文件。需要仔细考虑在场备份需要的条件，在做决定之前应该进行良好的判断。为处理公司所有重要交易和客户购买业务的服务器做一个在场备份是很有意义的，如果为一个不经常使用的文件服务器做一个备份就不是一个明智的做法。需要确定关键的设备，并应该估计它们的平均故障间隔时间（MTBF）和平均修复时间（MTTR），这些统计数据在修理和更换新的设备的时候都很必要。

对于那些对主设施造成负面影响的大一些的灾难，需要准备离站的备份设施。公司可以从以下三种之中选择：

· 热站（hot site）  这是一种配置完全的设施，在数个小时内就可以准备就绪投入运行。这里的设备和系统软件必须与主站点备份而来的数据兼容，这样才能保证不带来互操作方面的问题。这种热站对那些需要保证站点能够尽快运行并为他们所专用的公司来说是一个很好的选择；也就是说，公司对设施享有特权。一个热站能够对短期或长期的系统中断起到支持作用，配置和选择方面也十分灵活。许多热站的设备都支持由公司进行的一年一度的检查，这样能够保证站点处于必要的工作状态。在三种离站设施中这是花费最多的一种，而且如果公司需要使用专有的或不常见的软硬件，使用热站就可能遇到问题。

· 暖站（warm site）  这种设施只进行部分的配置，使用一些设备，但不是真正的计算机。换句话说，暖站通常就是缺少昂贵设备的热站。为一个设施配置完全和主站点一样的硬件和计算机可以使操作马上恢复，但是这样做成本太高，因此暖站只提供了一个设施和部分的外围设备。这是一种应用最为广泛的模式。它比热站的成本低很多，它的响应时间要长一些，可以提供专门的使用。对那些使用专有的或者不常见的硬件和软件的公司来说，暖站可能是一个较好的选择，因为在灾难发生后可以将主设施中的硬件和软件带到此处来。然而，在热站中可以进行的年度测试在暖站中通常不可行，而且公司也不能确定他们在几个小时之内就能够恢复运行。

· 冷站（cold site）  这种设施提供基本的工作环境、电线、空调、管道和地板，但是要使得这个地方能够活动起来并为工作做好准备可能要花几个星期的时间。冷站可以接受设备，但是它本身并不提供任何设备。冷站是最便宜的一种选择方案，但是在灾难发生后使其发挥作用所花的时间和精力也最多。

注意  理解这一点非常重要：这里列出的不同设备类型都是指服务机构的（service bureaus），就是公司从另一个公司（服务机构）租这些空间和服务，按月支付租金。“热”站（hot site）是一种租用服务，而冗站（redundant site）是公司自己的，由他们维护，所以他们不需要付租金。一个冗站有可能被叫做“热站”，这表示它已就绪，可以马上投入生产。在考试中，一定要区分热站（租用服务）和冗站（公司自己的）。

只有在停工会给公司造成重大的损失于是他们需要在几小时之内恢复运行的情况下，公司才会选择热站。这样公司必须能够为热站供应全部的冗余系统和设备。有一些商业公司专门提供这些设施，使用这些商业的热站的费用通常包括基本的租用费用、在实际使用时的开工费和以小时或天计算的使用费用。热站通常作为短期的解决方案，因为和正常的运行费相比要付出额外的费用。

大多数公司使用暖站，事先要准备好一些设备，如磁盘驱动器、磁带机和控制器，也仅限于这些了。这些公司通常支付不起使用热站的高额费用，而且对于他们来说停工期长一些也没有太大关系。与热站相比，暖站能够提供一个较为长期的解决方案。决定使用冷站的那些公司一定要能够忍受一到两周的停工期。冷站通常要提供电力、抬高的地板、空调和布线。

以下是对这几种离站设施的区别的一个总体上的概括：

· 热站的优点

Ø 几小时内就可以做好准备投入运行

Ø 高度的可用性

Ø 经常作为短期的解决方案使用，但是长期有效

Ø 可以进行年度的测试

· 热站的缺点

Ø 十分昂贵

Ø 硬件和软件的选择上受限制

· 暖站和冷站的优点

Ø 比较便宜

Ø 因为费用较少，可以提供较长的使用期限

Ø 如果使用专有的硬件和软件，选择暖站和冷站较为实际一些

· 暖站和冷站的缺点

Ø 不是立即可以使用

Ø 通常不能进行功能测试

Ø 运行所需资源不能够立即就位

如果备份的磁带或其他媒质保存在热站中，它们应该在热站的设备上做定期的测试，以保证这些媒质能够被这些设备读取。如果备份磁带或其他媒质保存在暖站中，那么应该把磁带拿到原来的地点，在那里的系统上进行测试。产生这种区别的原因是当公司使用热站时，它将依赖于热站中一直存放着的设备，而当公司使用暖站时，他们将会从原来的地点带来设备，因此这些媒质需要能被原来的设备读取。

注意  在选择备用设施的时候，应该保证备用设施和原来的设施隔得足够远，这样当原来的地方受到灾难袭击的时候，备用设施并不会受影响。换句话说，如果我们在考虑公司要遭受龙卷风的袭击，那么将备用地点选在离原始地点仅几英里的地方是不合逻辑的，因为备用地点同样可能遭受袭击而损坏。

另一个备用离站设施的选择方法是与另一家公司签订一个双边协议（reciprocal agreement），这意味着公司A允许公司B在遭到灾害袭击时使用公司A的设施。这比其他的离站设施价格都要低廉一些，但是它不一定是一个好的选择。因为在许多环境下设施空间、资源和计算能力的使用都达到了一个极致，这时候再加入另外一个公司并在同一个设施中工作，这可能给两个公司都带来损害。两个公司在一个环境下工作带来的压力是极大的，图9-8诙谐地描绘了这种情况。如果它确实可以解决问题，它也仅仅是一个短期的解决方案；配置管理将是一场噩梦，操作的混杂会带来许多安全问题。

双边协议有许多重要的安全问题需要考虑。如果你允许其他公司的人员在你的场所里工作，你可能完全相信该公司的CEO，即你的朋友，但是你并不了解他们公司的这些职员，这些职员可能有权使用你公司的资源。在市场上，这个公司可能是你的竞争对手。所以你应该把该公司和公司的许多职员看成是一种威胁，而不是一个在需要时能够出手相助的人。因此，如果不得不让其他公司的人使用某些资源，一定要特别警惕。

双边协议至多只是灾难保护的差强人意的选择。这种协议没有强制性，因此并不能保证在需要的时候这些设施就能够真正供他们使用。然而，许多公司选择了这种解决方案，这是因为它的低成本，而且在一些场合，这是惟一可行的方案。

图9-8  一个双边协议可能导致原先意想不到的压力和冲突

如果一个公司决定与另一个公司签订双边协议，那么在灾害发生之前就应该考虑到以下的问题：

· 在需要时该设施要经过多长时间才能投入使用？

·  该公司的员工能够在集成两个工作环境方面提供多少帮助？在业务的支持方面呢？

· 在需要时公司要用多长的时间才能搬到这个设施中去？

· 在互操作方面有哪些问题？

· 实际上有多少资源可供公司使用？

· 怎样处理分歧和冲突？

· 怎样进行变更控制和配置管理？

· 应该多久进行一次演习和测试？

一些公司选择准备冗余站点（redundantsite）的方法，这意味着准备一个和主站点在设备和配置上完全一样的站点，这个站点用来作为一个局部的冗余环境。

这些设备是公司自己的，是生产环境中正在使用的设备的镜像。这是一种最昂贵的备份方式，因为整个备份系统都需要维护但基本不提供什么服务，除非是生产系统中的设备出了问题。然而这里的昂贵是相对的。如果因为5~12小时的业务中断导致公司损失100万美元，那么这个损失远远超过维护备份系统的费用。很多组织都遵守必须备有冗余备份设备这一惯例，因此这种场合下价格问题不是很重要。

另一种设施备份的措施是“滚动热站（rolling hot sites）”，也就是将一辆大的卡车或者拖车的后部变成一个数据处理或者工作的区域。拖车可以放在公司的停车场内，也可以放在其他位置上。另一种解决方法是可以被容易地和快速地组装起来的预制安装建筑。

公司最好能够知道所有可行的硬件和设施的备份方案，这样他们就拥有多种选择，并能够根据自己的需要作出最好的决定。

9.6.2  软件备份

我有一个备份服务器和备份好的数据，但没有操作系统或应用程序。答：好运气。

如果离开了在上面运行的软件，对公司来说硬件就不会那么值钱了。需要备份的软件可能以应用程序、文件、系统程序、数据库和操作系统等形式存在。连贯性计划必须提供对软件的备份和保护措施，和对硬件及设施的措施一道。

软件通常比硬件的变化更频繁一些，因此备份过程应该建立在连续的基础上。对我们来说很重要的是保证为公司备份软件的这项工作是有意义的。如果文件中的数据一天中要变化几次，那么为了保证捕捉和保留所有的变化，每天都应该备份几次数据，或者在每天晚上进行备份。如果数据一个月变化一次，每天晚上都备份软件就是对时间和资源的浪费了。和保留一个文件的多重复制相比，我们通常更愿意备份文件和相应的改变。在线的文件通常将文件的改变记录到一个事务日志中，该事务日志和原来的文件是分开的。

重要的数据应该保留有在场的和离站的备份。在场备份在发生非灾难性的意外事件时能够很容易得到，并使得恢复操作能够很快完成，这样公司很快就能够恢复正常的运行。然而，在场备份对于提供真正的安全性来说还是不够的。软件应该同时保存在离站的设施中以防止真正灾难的发生。我们需要做的一个选择是，考虑到主设施的位置，离站设施的位置应该在哪里。离站备份存放地离主设施越近，就越容易得到，但是如果两个地方同时发生灾难就会使备份遇到危险。将备份设施选择得远一些可能是明智的，但是较难达到。一些公司拥有两个备份设施：一个离得很近的和一个离得很远的。

在场的备份信息应该存放在一个防火的保险箱内。备份和恢复数据的规程应该很容易拿到，而且很容易理解。在紧急情况下，那个一直做备份和恢复的人可能不在场，因此这些信息需要很容易地被其他人得到。

应该根据一个合理的周期来更新主文件，需要保留好事务文件以和主文件保持一致。这使得那些先前产生的主文件能够很容易地被更新，能够重新产生反映所有新数据的现在的主文件。我们还必须考虑到备份的策略，因为每一步都可能产生错误，因此如果在备份和恢复的步骤中遇到了问题，应该有一种方便的办法回退，或者是从头开始重建数据。

数据库需要专门的备份操作，因此备份操作经常作为一项功能集成到数据库管理软件当中。能够将数据库配置成使用磁盘镜像，或称为数据镜像的技术。磁盘镜像子系统使用两块物理磁盘，为了达到冗余的目的数据被同时写入两块磁盘。该子系统执行数据镜像的功能，如果一个磁盘出现故障，另一个可以提供数据。这和使用双磁盘不同，使用双磁盘要用到两个磁盘控制器，这样如果一个控制器出了故障，另外一个还能够使用。

需要和分离的数据字典一道维护文件的描述信息。这两者都需要和文件的版本保持一致，这样每一次备份的步骤都能够按照一种可以预见的方式进行。数据库本身就有恢复和前滚的功能。（数据库的概念和有关问题在第11章中讨论。）

 

不同的备份类型

·增量备份  仅对上次任何备份后的那些变动的文件做备份。将去掉存档属

性。

· 差量备份  对上次完全备份后的那些变动的所有文件做备份。不去掉存档

属性。

· 完全备份  备份所有文件，变动过的或是没有变动的，将去掉存档属性。

 

增量备份比差量备份完成得要快一些，但是恢复起来要慢一些，因为每一个差量备份都要从上次的完全备份开始恢复。

 

 

手工的对系统和数据的备份可能很耗费时间，容易出错，并且成本很高。有几种技术可以用来完成自动的备份，这将带来额外的成本，但使得备份过程更加迅速和精确，这对那些经常变化的在线信息来说是十分必要的。一种叫电子备份传送（electronic vaulting）的方法能够为一个改变了的文件或一个事务文件做一个直接的复制，然后将它发送到原始备份存放的远处的某地去。信息可以存放在一个离站设施中，这样在短时间内就可以从那里取回数据。在许多金融机构都是这样做的，因此当银行的出纳员接收一笔存款或取款业务时，在本地机构中和维护所有的客户数据的远程地点中的用户账户记录都需要做改变。

电子备份传送是为了备份目的而向离站设施传送大批信息的方法。远程日志（remote journaling）是另一种向离站设施传送数据的方法，但它通常只是将日志记录传送到离站设施中，而不是传送实际的文件。

保留软件和文件的不同版本是十分必要的，特别是在软件开发的环境下。对象和源代码需要和库、补丁一同备份。离站设施需要成为在场设施的镜像，也就是说，将所有数据都放在在场设施中而只将源代码放在离站设施中是没有意义的。每一个地点都应该保留有一整套的最近更新的信息和文件。

 

事务冗余(transaction redundancy)

电子备份传送

· 修改过的文件的复制被传到存放该文件原始备份的远程系统。

· 传输大块的备份信息。

· 用批处理过程来移动数据。

远程日志

· 把日志或者处理记录传到远程系统，而不是文件本身。

· 使用并行处理过程把数据传送到备份设备。

· 占用的通信线路只是生成数据所需的（即节省通信链路）。

 

 

另外两种备份技术是层次存储管理（HSM）和存储区域网络（SAN）。HSM提供连续在线备份功能。它同时使用硬盘存储器和其他便宜但读写速度慢的存储器，如磁带。HSM可以动态地管理存储器和恢复文件，文件被存放在不同速度和价格的存储器上。常用的数据被放在速度快的存储器上，不常用的数据被放在速度较慢的存储器上，或者可以放在离线（near-line）设备上。存储媒体包括光盘、磁盘、磁带，实现这些功能不需要用户的参与。SAN由多个存储器组成，这些存储器互相连接构成一个备份网络。SAN构成了一个联网的存储结构，允许多个设备连接到任何一个存储器，一般使用交换技术将多个存储器组成一个交换网格（fabric），如图9-9所示。这个交换网格允许多个设备连接到终端存储器。因为网络不只依赖于特殊线路或者连接，所以交换网格提供冗余和容错（fault
tolerance）。专用通道（private channel）或者存储控制器提供主机对存储设备的透明访问。

图9-9  SAN提供交换网格，允许所有的系统同时与多个存储设备通信

本章讨论的最后一种软件备份技术是磁带传输（tap vaulting）。很多企业使用手工的磁带备份方式，数据被写到磁带，然后由职员把磁带送到存放处。数据在传输的时候可能会出问题。已经发生很多有意思的实例，职员在等地铁的时候把备份数据的磁带放在地铁站地面上。地铁站有很多连续运转的大发动机，发动机产生的磁场会破坏甚至删除磁带上的数据。除此以外，数据恢复方式也会有问题，如果公司需要恢复数据，它就要数据马上能恢复，而不是三天以后。

使用自动磁带传输，数据通过一个串行线路传到存放处的磁带系统。存放处的管理公司维护系统，需要时可以换磁带，这样数据可以快速备份和恢复。这个技术简化了传统磁带备份流程中的手工操作步骤。

9.7  选择软件备份设施

我喜欢这个设施，因为它是粉红色的。

在一个公司为它的备份材料选择存储设施的时候，需要讨论几个议题，并要向公司提出几个问题。以下提供了一些在决定使用某个设施之前应该考虑好的问题：

· 记录或者冗余的硬件能够在必要的时限内被访问到吗？

· 该设施在周末和假日关闭吗？或者它只在一天中的某几个小时工作？

· 访问控制机制和报警系统或警察局联系起来了吗？

· 设施是否防火？

· 设施的物理布局是什么样的？

· 设施的布局会在使用时造成妨碍吗？

· 设施具有适当保存存有公司备份数据的媒质的能力吗？

· 担保的传输服务的可用性如何？

· 当地是否有任何地理环境上的灾害？如洪水、地震、龙卷风等等。

· 那里有火灾探测和扑灭系统吗？

· 设施提供温度和湿度的监视和控制吗？

这些需要解决的问题和议题因公司的类型、需要和对备份设施的要求而不同。

9.7.1  文档

我们6个月前制定了一个伟大的计划。有人把它记下来了吗？

对大多数人来说文档记录似乎是一项讨厌的工作，许多人宁愿找其他的工作来做，来保证他们不是整天忙于将程序和步骤归档的工作。尽管一个公司可以很负责任地做离站的软硬件备份、维护它并保证一切都是最近更新的，但是当灾难发生时，可能没有人知道如何使用这些东西来恢复业务的运行。

文件恢复可能是一项有挑战性的工作，但是恢复整个在龙卷风中被一扫而空的环境可能是一项几乎不可能的任务。需要将操作规程归档，因为当真正需要它们的时候，将是一个混乱和疯狂的时刻，而且有苛刻的时间限制。文档可能需要包括如何安装镜像、配置操作系统和服务器、安装系统软件和专用软件。

大多数的环境都随时间而变化，软件在其他软件的基础上安装，多少年来配置被不断地更改以保证在独特的环境下工作，服务包和补丁程序被安装以修补这样那样的问题。期望一个人或一群人能够完成所有的步骤，带来一个和原来环境极为类似并能够无缝地集成工作的环境，可能只是一个高尚的梦想。

因此归档这个讨厌的工作可能在某天就成了我们的优势所在。这是业务的一个基础，当然也是灾难恢复和业务连贯的基础。

9.7.2  人力资源

我们所有设备都到位了，不过到哪去寻找运行系统的人员？

公司中最常遗漏的资源是人。公司可以恢复它们的网络和关键系统，使业务尽快恢复运作，但是“谁来做这些恢复工作？”人力资源对于任何恢复和可持续过程都是最关键的部分，需要在计划中精心考虑。

如果我们必须从250英里以外把备份设备搬过来会怎么样？我们不能指望员工从家里驱车赶来，我们应该为必须的雇员支付临时的房租吗？我们必须付他们搬运费吗？我们需要在当地雇佣新的人员吗？如果需要，他们需要什么样的技术呢？

如果发生了重大的灾难，不仅影响公司的设备，还影响周围的地区和房屋，你认为你的雇员更担心你的公司还是担心他们的家庭？有些公司假定雇员会在这种时候坚持在工作岗位上进行生产，但是事实上他们需要留在家里，因为他们对自己的家庭负有责任。

可悲的是，有可能有些雇员在灾难中殉职了，于是团队可能会借助临时的机构或猎头公司寻找新的职员取代他的位置。这的确很残酷，但是却是事实。团队应该明确所有这些威胁，并负责为防范每一种威胁寻找解决方案。

9.8  恢复和重建

应该指定一个重建小组并就他们的任务展开训练，这是业务连贯性计划的一部分。可能需要一个小组负责使备用场所投入运行，另一个小组开始原有场所的恢复工作。这些小组必须知道如何完成许多工作，比如如何安装操作系统、配置工作站和服务器、布置电线和电缆、建立网络和配置网络服务，以及安装设备和应用程序。这个小组也必须知道从备份设施中恢复数据的合适步骤，这可能比听起来要难一些。

一个公司直到原来的主站点操作都恢复正常时才脱离紧急状态。在一个公司必须从备用场所搬回到原来的场所的时候，需要考虑许多后勤问题。应该先搬回最不关键的组织单元，这样如果程序上出现问题、连通性出