有规划的小破坏将可以酿成巨大的灾难性事 情。这样的灾害性事件我们都可能会遇到，毕竟IT经理们没有什么不同。
我们都知道诸如南加州的地震、纽约市隧道里的火灾、佛罗里达州和路易斯安那州的飓风这些都属于大规模灾难。这些灾难性事件使得许多企业在灾后都必须制定 灾后重建计划，甚至在许多情况下给企业造成了巨大的商业损失。尽管这些灾难事件都有着巨大的破坏力，但毕竟它们并不经常发生。让我们来看看这些真正的大的 灾害性事件吧。
下面这些则属于妨碍我们业务上的小灾害。诸如电 子邮件服务器的数据库损坏、订单处理应用程序运行失常、网络运行失常、公司的关键服务器遭到黑客入侵、公司雇员为泄愤任意窜改企业的数据。这些问题发生的 可能性要比上述的那些大灾难要多得多。问题是我们当中有多少人曾考虑过如果上述这些所谓的“小灾害”发生在我们的数据中心，我们能做什么呢?
我们大家都曾思考过这些问题，并都有一些不步程度的解决方案。但我们的所谓的方案 都不够充分。我们每个人都有大量的关于如何能够恢复正常运作的想法，但我们的这些想法都未曾涉及到如果我们重新恢复到正常运作之后，我们将如何继续得问 题。问题是恰恰正是这种想法可以产生巨大影响。
事实上，电邮服 务器运转的失常倒不是导致商业失败的原因。真正导致商业失败的原因是我们的客户和员工缺乏良好的沟通。电子邮件是我们的重要工具。没有它，我们显然处于不 利地位。虽然我们不能想像我们的日常运作没有电子邮件的帮助会是怎样，但其实如果电子邮件真的无法使用，我们可能反而可以将损失减少到最低限度。
每一项灾害性事件都可能导致两方面的影响：
- 恢复进程
- 不存在的进程
恢复 进程对IT专业人员来说通常都非常简单：恢复快照、恢复备份、根据储运损耗的情况联系供应商等。即使我们从来没有执行这样的补救措施，方案仍然是相当标准 和固定的。我们甚至可以在许多情况下创造性的采取相关措施，毕竟我们有足够的经验来应对各种进程。
“不存在的进程”则要复杂得多。我们常常甚至从未启动过这一进程，因为我们认为恢复 过程会很快自动运行，因此为什么要自找麻烦呢?这就是所谓的傲慢，而这恰恰是我们的灾难性的问题的开始。如果我们对“不存在的进程”有一个很好的处理计 划，我们大概能够经受住所有风暴的考验。显然，我们需要花费大量的时间在这上面了。
运用设想进行难后恢复工作
要充分地做好各种灾害的准备，我们就必须考虑我们有可能遭遇的各种灾害的类型。我们可以通过如下这些步骤来进行：
第1步：设想最有可能的灾难性事件
当然这些灾难性事件根据企业规模性质行业的不同差别很大，但也有许多相似之处。一 般而言，我们可以想像关键应用程序出状况是最具破坏性的。在这项实验的研究过程中，我与我的同事考虑了可能的情景。我们很快设想了五种状态。前四中状态我 们都有第一手的经验。也许你正经历这第1步，而处理这第1步最好的方法是运用过去的经验。您或您的工作人员有经验的设想将是非常有价值的。
不管你在这方面思考得多或者少，但都必须彻底的考虑到。你在之前预测和想象的越 多，就越能掌握更多的资源以应对这些事件的发生。
第 2步：确定这些事件对公司业务的影响程度
从 高到低的列举出这些事件对公司业务的影响破坏程度以及从影响程度最高的事件开始，制定一套全面的恢复每个事件的计划。对公司业务的影响通常主要是以时间的 长短来衡量的。如果电邮服务器仅失常了5分钟，其影响也就无关紧要。但是，如果电邮服务器持续数小时甚至数天出状况的话，对业务的影响则要大得多。做最好 的希望，并提前为最坏的情况制定应急方案则是你工作的重中之重。
针对电子邮件运转失常的一项全面的灾后恢复计划必须考虑到所有在恢复后可能发生的事件，同时还必须要有足够的应变计划，来应对以防这些恢复计划出差错。
评估每种状况下对公司业务的影响，及时的对相关状况进行处理是必须的。并要特别关 注于具有影响力的事件。
第3步：对业务影响的 估计(从高到低的列举出这些事件对公司业务的影响破坏程度)
可以想像一些灾难情景不会对公司业务产生太大的影响或者不经常发生，所以也就不足以担心。但是，另一些情况会产生严重后果。要充分了解并掌握最有可能或 最关键的情景，你还有很长的路要走。而这样的情况下，充分的设想就可以帮助你。长远来看，在许多情况下简单地设想一些状况会导致什么事情的发生，将在很大 程度上帮助你。一些问题如果你曾考虑过，你很可能会再次考虑。
第 4步：制定恢复计划
对于每种情况都制定一套 详实而全面的恢复计划，包括涉及到的人员、事件、时间、地点以及如何有效的进行解决。对于传统的数据中心的问题，如一个应用程序的失常或数据的被篡改，将 对其制定详实的恢复计划，并要求体员工了解和很好的掌握。
对于 处理那些影响到公司基础设施的灾害性事件，可能需要另一个网站来协助回复。你是否有有备用的网站?
应急方案：如果A计划行不通，将采取什么措施?是否有一种替代方案?设想一些补救情 景。有一个是最佳的，但有可能要为此付出代价。
总的来说，我们 的计划如下：
- 人员：谁是恢复计划最主要的参与者?如果他 们无法及时赶到，我们如何与他们联系?有哪些替代人员?
- 事件：我们要恢复什么?如果我们的第一个恢复选项失败我们该怎么办?我们要必须 执行该计划需要什么资源?我们是否有一个备用的网站，其他所需的硬件，或替代的联系方式?
- 时间：我们预测补救措施什么时候可以切实的完 成?这对于“不存在”的进程是至关重要的。对该事件会持续多久的估计对“不存在”的进程的处理计划也是十分关键的。
- 地点：补救措施在哪 里进行?如果在应用失败情形下，大概在我们的数据中心的什么地方?除非有通讯中断，有可能是一个备用站点。
- 如何进行：我们需要多少资 源?有什么其他附庸资源?制定一个全面的恢复计划是相当棘手的。您的计划考虑得越周全，就越有助于您处理好灾后恢复事件。好消息是，这是一个标准的数据中 心的程序。我们要善于应对这一问题。只有我们将所有可能发生的状况都考虑周全了，尤其是那些迫使我们必须会迫使我们选择备选方案的问题也都考虑周全了。有 超过一个补救选择是至关重要的。我们了解的将会导致我们出现状况的问题已经不成其为问题了，而只有那些我们还不知道的问题才是关键所在。所以，我们在之前 越多的设想可能出现的状况，就越有助于我们较少因这些问题所产生的损失。
第5步：开发“不存在”的进程
你可以通过开发“不存在”的进程来赚钱。很好的实施这一步骤以及计划，将可以最大 限度地减少或者消除几乎任何状况所带来的影响!让我们以电邮服务器失常为例吧。
如果电子邮件是您的企业重要的通信的工具，你将很快面临很多大问题。你会怎样处理?是否有替代的通信方案?你是否有另一台电子邮件服务器?你是否有办法 让客户知道你的另一种替代通信方式?你的B计划是什么?(你的B计划是什么意思?我们甚至连A计划都还没有!)
理论上，您可能考虑过如果电邮无法正常提供服务您将怎么与客户沟通。您的计划也许多 余的时间来帮您确定您将使用哪套备选方案。基于来自所要补救恢复的信息，您能实施您的选择。例如，如果补救措施将需要八个小时以恢复电子邮件服务，您也许 会决定通过电话和网站公告及时与您的顾客沟通，解释问题和并告诉他们与您联系的可供选择的方法。您可能会开始使用一种替代的邮件服务器，不管你采取上述您 的数据中心的恢复措施中的二者中任何一种，甚至或许您有可能采用第三方电子邮件提供商。或许在你所在的企业中有另一个部门可能可以提供你所需要的资源。
如下是另一种关于所涉及人员、事件、何时、何地，以及如何处理灾后恢复的问题。
- 所涉及人员：谁需要被告知出现状况?由谁来告诉他们?在这一过程中谁提供所 需的相关信息?
- 事件：替代方案是什么?无此应用程序、通信方式我们怎样开展业务?
- 时间：我们何时采取补救行动?我们 合适切换到另一种可选方案，以便我们能够开发“不存在” 的进程?
- 地点：我们的客户在哪里可以继续与我们开展业务?我们的业务将在什么 位置?我们的工作人员在哪里?
在这期间的商业活动将如何进行?
时间问题是关键。如果你曾考虑过电子邮件服务失常将会持续的各种时间状况，并随着持 续时间的长短不同制定了不同的应对措施时，你会知道该怎么办，并随之采取相应措施。如果您的恢复计划是完美的，你可能不需要做任何事情。然而，一旦出现问 题，事前曾考虑过的一些替代方案被证明是非常宝贵的。
1967 年1月27日，一场悲剧性的大火席卷了佛罗里达州肯尼迪航天中心的阿波罗1号指令舱。飞船上所有3名宇航员全部丧生。指责声响彻政府大厅。美国参议院宇航 员Frank Borman指出，“这是一次事前设想的严重失败。我们的考虑还是有限的。我们没有预见到十一种意外情况。没有人想到会发生致命的火灾事故，或者说没有预 料到一个非爆炸性舱口可以防止宇航员逃避这种灾难。没有人想到它会发生。我们的责任在于未曾充分考虑过可能可能发生的事故。
阿波罗1号调查完成后，美国宇航局重新实施了登月计划。他们安然度过了最大的灾难， 并积累了更多的经验。他们实现考虑了更多的可能发生的问题及其解决办法。阿波罗13号给了他们再一次机会，他们的预先设想得到了回报。不但没有再次失去三 名宇航员，他们事先预想可能出现的状况和相应的实施解决方案能力大大提高。你甚至可以说，这次太空旅行定下了未来太空旅行的基调。
我们可以由美国航天局的教训中学到很多东西。设想灾难将影响我们。当我们解决目前所 面临的问题时，想象一下，解决目前这些问题的方案及其备选方案。根据我们的想象力培养良好的计划，这样我们就能选择处理问题的最佳方式。
我们无法想象我们的生活没有科技。因此，我们必须设法想象，如果我们有机会建立一 个现实的灾难恢复计划。
；QQ联络：1360095750。