本文来自一位资深CIO Niel Nickolaisen的经验总结，现任O.C. Tanner公司的CIO，本文讨论的是灾难恢复过程中的一些技巧。

　　对于自己的IT生涯，我认为一直都是担任扭转局面的角色。由于某些原因，IT并不能一直如人们所期望的那样运转，因此公司让我担任新的IT领袖，让系统更加协调和稳定。还有些公司让我对其IT流程和系统进行为期一到两天的评估。在灾难恢复方面，我遇到了几个典型案例：

• 在某家公司，当IT员工在同一台服务器上进行备份。对于我来说，这种方法几乎丧失了备份本应有的全部意义。
• 在另一家公司，每当IT出问题不得不重启系统时，IT团队会顺便将重启也看做灾难恢复的一部分，认为这是合乎各种标准的。这意味着，生产环境也成为了灾难恢复的场所，只要其能够重新正常运转，灾难恢复规划就是成功的。
• 一家公共机构多年来一直受阻于各类灾难恢复规划的实施。由于没有足够的资金支持，其希望在故障时将生产环境的所有要素都备份到远程站点的计划一直未能成功。

　　这些情况和我们选择灾难恢复服务商（包括云服务商）有什么关系呢？

　　让我们从首当其冲的灾难恢复服务提供商谈起，那就是我们自己。自力更生当然是好的，除非有些事情不应该由我们自己来完成。那些用自己的服务器来进行灾备的公司可能缺乏相应的专业知识来制定有效的规划和流程。那个将系统重启看做灾备组成部分的公司显然是缺乏对于系统冗余性的正确认识。那个希望能备份一切的机构则是对于服务没有理性的认知。在上述情况下，你应该去找那些对于灾难恢复理解更为深入并有实践经验的人。

　　但是，该如何选择服务提供商呢?在寻找比我更为熟悉灾难恢复的人的过程中，我总结了下列原则来进行指导：

• 服务商要能够对我的服务进行分级和归类。有些服务是如此关键，必须有冗余机制。而其他很多服务也很重要，但是仅仅需要恢复而不是冗余。任何服务提供商要能了解其中的差别并进行相应的规划。对于那家公共机构来说，我们认为仅有极少数的系统是不能中断的。因此，只需要不多的冗余规划，其他大部分则只是针对恢复来设计。如此一来，成本大为降低，灾难恢复计划变得可接受和可实施了。
• 必须要具有相应的测试能力。或者，即使我不打算进行测试，也希望有其他成功案例作为其能力的证明（我并非想和服务商交流，而是想和其客户沟通）。
• 必须证明不存在单一故障点。我不希望在同一台服务器上进行备份的情况出现。
• 必须财务健康运营稳健。对于服务商的选择，是我一辈子只希望做一次的决定。如果有任何前景不妙的迹象，不要犹豫，抛弃这家厂商。

　　在某些情况下，云服务商是最好的选择，至少可以满足上述部分的要求。如果云服务商有着大型的、地理分布的系统，则出现单一故障点的可能性就会变得非常小，你的系统就有很多的备份选择。如果云服务商有着大量的客户基础，在灾难恢复实践方面就具有丰富的实践经验，而且这种公司基本不会出现财务方面的危机。

　　当前，在灾难恢复方面，我们拥有如此多优质可靠的选择。唯一的障碍，只可能是我们自己。