我是一个IT总监。必须承认，当一个人有了权利，他总是渴望权力更大。拿我来说，就总是幻想自己是位仁慈的“凯撒”，可以完全掌控组织中的所有IT事务。然而，组织是不断扩张的，集中式的IT管理也越来越难。我能集中采购各分部的IT设备，我却无从知道这些设备的使用情况；我能标准化各分部的IT系统，我却对这些系统的运行时状态一无所知。很明显，这些对我接下来要谈到的远程灾备和业务连续性规划有直接影响。

　　而且影响每天都可能发生。譬如说，有个分部就有这么一位Carl－分部的人认为他IT很牛，于是遇到问题了觉得我们是“远水不救近火”，竟直接找他解决。Carl如此这般地“牛”过一把，就把分部的系统搞挂了。Carl没辙了，只有打电话找我们救命。当我们赶到时，本来的小问题已演变得不可收拾了。这样的事情真不少，而我费尽心机也鞭长莫及。每每至此我便幻想：如果自己是一位真正的“凯撒“，我一定不会让Carl这号人介入IT，要么老老实实赚钱，要么走人。

　　回到灾备和业务连续性的话题，抱怨是没用的，还是面对现实吧：我们IT能直接负责的“灾难恢复”，只是那些与我们的主数据中心有紧密连接的核心系统，我们不可能照顾到每个迅速扩张的远程分部。因此，既然我们不能“亲自照顾”，何不为分部员工提供简单明了的灾备文档，让他们遇到问题自行解决？

　　思路明确了，分析问题就容易多了。认真思考之后，我按照分部对系统的需要/依赖程度将之分成以下三类：

1. A类系统－宕机哪怕几分钟业务也会遭受严重影响；
2. B类系统－宕机超过数小时后业务才会面临危险；
3. C类系统－宕机甚至停运很长时间业务都不受影响（有一次，这样的一个系统宕机6周都无人过问，最后还是先被IT的发现了）。

　　我制定的政策是，属于我们专职IT人员管理的仅是所有的A类系统，B类、C类我们提供操作文档，分部自行处理。这样做的好处是：很多时候我们IT部门根本不用为分部的系统灾备操心，因为他们不是B类就是C类－还有什么比这更爽的事？

　　分类后，虽然我仍需给A类系统制定灾备和业务连续性实施方案，但是我只用专注于撰写相关文档即可，包括备份、恢复流程，碰到特定问题的沟通方式，以及和客户通气应该怎么措辞，等等。

　　实际中我们这样工作来保证文档的清晰明了无误：首先，从IT团队中找人来设计初稿，其中会辅以大量图片来对行动方案做补充说明；接下来，仍从IT团队中找人，按照初稿操作，以观成效；数易其稿后，我们从最终用户中找人来测试，测试通过，我们会向所有需要的分部发布文档。

　　这样还不算准备充分，最后一步是灾备演练。演练的目的是明确下列问题的答案：“灾难”降临时人们是否能找到备份的数据并恢复业务，当网络/互联网断掉时怎么办，电话掐断时如何联系员工和客户，等等。我的经验是，一两个演练后就会发现这些答案了。演练虽然有着良好严肃的动机，当你看到员工们演练结束四散徘徊寻找集合地点的场面时，是个人都会忍俊不禁。

　　我为分部IT进行灾备准备的工作，总结起来就是：排列活动顺序，撰写流程文档，实施灾备演练。虽然至今不是自己幻想的“凯撒”，对于以前后怕的事情，现在我多少能够安心了。