Niel Nickolaisen是O.C. Tanner Co.公司的首席技术官，同时也是TechTarget专栏作者，本文中，他将分享自己对于灾难恢复过程中IT部门的职责分工以及如何建立一套行之有效的灾难恢复路线图。

　　当收到来自高层的电子邮件，要求IT部门尽快完成一项任务时，CIO会让自己的团队立刻着手。但是，当涉及到灾难恢复时，CIO则必须说，’不’。

　　
　　在我成为新任CIO的两个月后，人们开始陆陆续续想让我参与前任CIO从来没有参与过的项目。这些项目包括被完全否定的应用程序，到其他繁琐小事，- 这些烦人的项目也许应该被处理，这样它们就不会再来找IT部门的麻烦了。然后，让我一直担心的电子邮件来了。是CFO发送的。邮件里说，为了减少我们的商业保险成本，并符合监管准则，我们需要实施一项灾难恢复（DR）计划，因为DR明显是IT部门的职责，他希望我能把它加入到我的项目清单中，并完成。我从我的椅子里站起来，离开办公室，走到了CFO的办公室。
　　
　　“Niel，很高兴见到你，我能为你做些什么？”
　　
　　“你关于灾难恢复的邮件引起了我的思考，所以我认为我应该来分享我的想法。”
　　
　　“太好了，我也这样希望。顺便说一句，我们真的很高兴你加入我们公司。”

　　
　　
“我也很高兴，加入公司，但是在我们谈论灾难恢复后，你也许会改变这个想法。”
　　
　　“这是为什么？”
　　
　　“在你的电子邮件中，你说灾难恢复是IT的职责。 我认为不是。灾难恢复计划属于整个公司，IT参与规划，但不应该完全是IT的职责。”
　　
　　“不是IT的责任吗？怎么可能呢？如果有灾难发生，你们需要确保我们能够恢复我们的系统。”
　　
　　“是的，而且我们会这样做。 但是，灾难影响的远不止是我们的系统。我们的系统遇到的问题，只是可以使公司陷入瘫痪的问题的其中一部分，我们的灾难恢复计划应该考虑我们企业的所有风险，而不仅仅只是我们的系统风险。”
　　
　　CFO一下子就明白了我的话，并同意扩大我们对于灾难恢复计划的定义。作为第一步，我们从每一个主要部门找到了些志愿者 – 他们中的一些是被迫的，以帮助建立我们的灾难恢复计划。
　　

　　影响和可能性的风险评估

　　
　　这样的规划可能导致一连串的长会议，长篇大论，各种分歧，没有任何进展的噩梦。为了避免这种情况发生，我采用了一种风险评估/缓解的方案。它是这样工作的。
　　
　　我首先让团队的每个成员进行头脑风暴 – 而且每一个大胆的想法都是欢迎的 – 所有可能让公司崩溃的灾难。这一列表随业务和地区，而各不相同，包括：心怀不满的员工，水灾，火灾，数据泄露，核心员工的流失，关键技术的流失，以及一切可能破坏区域办公室或办公点的情况 – 停电，等等。对于这些类型的每个风险，我们都通过影响和可能性的组合，对它们进行评估。
　　
　　对于那些低影响，低可能性的风险，我们可能不需要确定，我们将如何缓解它们。对于那些中度影响/高度可能性，或高度影响/中度可能性的风险，我们的灾难恢复计划应覆盖这些风险。
　　
　　一旦我们评估了风险， 我们就确定缓解计划，如何正确应对风险。灾难恢复可能会很昂贵，也很容易在那些我们也许永远不会使用的恢复选择上进行过度投资。而且，系统，流程和性能的冗余 – 是非常昂贵的，我们应该只在高度影响/高度可能性风险上采用冗余或部分冗余。对于其他风险，我们需要思考的是如何迅速从灾难中恢复， “迅速”则要根据具体情况。 （顺便说一句，我曾经与一位公共事业公司的CIO谈论过，他告诉我，在一个大型飓风过后，公司的灾难恢复计划被搁置，直到它能够确认其雇员是安全的，稳定的，并可以实施灾难恢复计划 – 这是他们的计划在之前没有预料到的。）
　　

　　演习

　　
　　下一步为所有值得缓解的风险，实施计划。但是，这一步要基于风险评估。首先执行高度影响/高度可能性的计划。
　　
　　这个过程的最后一步是测试这些计划，这就带来了些许的乐趣。用模拟和安全的方式 — 看着世界土崩瓦解总是有趣的：突然中断某个项目，然后看着恐慌发生。 （请务必告诉那个负责财务报告的人，观察这一过程，而不是参与这一过程。）准备一个远程站点，进行几天的人工事务处理，观察还有没有其他问题发生。 

　　
　　一旦测试结束，评估结果并重新制定你的风险缓解计划。无论是多么优秀的团队，制定了计划，他们几乎肯定会犯错误。