节假日期间有的公司节奏会变快，但大部分公司的节奏会慢下来，当然，这取决于它们所在的行业。我们公司既不是零售企业也不是交易量大的企业，因此我们一般安排节假日期间执行重大升级或修改，因为在此期间引起停机并不会影响到多少人。这段时间也是对数据中心灾难恢复（Disaster Recovery，简称DR）计划进行评审的最佳时机，如果你只有一个核心成员，借此机会也可以好好研究下人员编制问题。

　　管理灾难恢复人员

　　无论是节假日还是在灾难发生时，人员管理可能是数据中心面临的最大困难。有一点经常被忽略的是，当你的人员在休假时发生了灾难事故，启动DR站点运行结果出现了一系列的问题，这个时候人们往往会想到请求专业的技术支持公司支援，但在此之前他们却从不会考虑这个问题。

　　我们处理这种问题的方法是预先告诉人们在灾难发生时应该尽快回到办公室，但真正要每个人都做到确实不是一件容易的事情，当事前告知人们发生灾难时该如何做，如真有需要时，他们可以拿出已准备就绪的计划开始实施。每一位在IT部门工作的人应该都清楚，他们的工作是保证IT系统在发生灾难时要一直运行，即使灾难发生在节假日也如此。

　　确定灾难恢复响应团队的成员是另一个挑战，我以为指定一个团队的高级成员就可以了，但事实证明我错了。

　　灾难场景游戏

　　为你的数据中心开发灾难恢复计划需数据中心或IT管理人员全盘考虑，开发各种不同的与手头工作人员水平相当的灾难场景是非常明智的选择，因为你必须考虑人员不在的情况，如节假日。

　　我们要做的事情就是玩游戏，安排专人担任裁判，并和IT管理人员一起合作，对灾难响应小组成员进行不同灾难场景的反复训练。从一个正常的情况开始，突然发生一个灾难，你该怎么办？数据中心管理人员很可能做出惯性反应：激活DR站点。随后指定人员相继报到，大家一起协调工作保持系统正常运转。

　　然后裁判员开始对场景做出变动：假设有12个人，但其中6个不在，那你该怎么处置？数据中心管理人员第一次玩这个游戏时，他们往往都不知所措，这个游戏让人们知道平时做好计划是多么的重要。

　　数据中心管理人员可能会辩解到他们的灾难恢复人员可能会有一半都不在，似乎可以不用考虑什么灾难恢复计划，如果你的目标是开发一个有效的数据中心灾难恢复或节假日应急计划，那这样回答是错误的。

　　灾难风险分析

　　要做的关键事情是风险分析，以确定漏洞和成本，每个风险都有一个与之关联的成本，你可能需要增加资金投入以指定足够的人来应对灾难恢复，但如果你做的计划可操作性太低，从长远来看，其成本可能会更加昂贵。

　　通常，灾难恢复计划有一个中长期问题，例如，你需要研究一下你的应用程序，问一下你自己能够承担得起多长的宕机时间，需要做几件事情：规划DR站点的大小，同时找出你需要什么样的人来管理这些应用程序。

　　此外，你的灾难恢复计划应是业务运行的一部分，换句话说，如果你不能调整你开发和测试灾难恢复计划的成本，那么你必须考虑是否要调整剩下的业务。

　　灾难恢复计划是一个持续的过程

　　值得注意的是人们可能很努力地开发出一套灾难恢复计划，但束之高阁，也许三年都不会翻一下，直到它们过期，如果你没更新过你的计划，当发生灾难时，很可能就没有适合的响应文档。

　　军队在这方面做得非常好，如果你查看它们的灾难恢复计划，他们已经写明了具体的步骤，你完全可以按照步骤一步一步地执行灾难恢复，因为他们事先就做好了全盘考虑。

　　在理想的环境下，你已经有这些场景的灾难恢复计划和“灾难手册”，当真正遇到灾难时，你可以大声说“这和书中第27页的灾难类似”，翻到那一页按照步骤执行即可。顺便说一下，应将灾难手册多复制几份，我记得有个数据中心就做得很好，有专门的文档和详细的步骤，夸张一点地说，一只经过强化训练的猴子也可以执行灾难恢复，但当他们遇到火灾时，他们的文档存放区域可能遭受大火，因此管理好文档也非常重要。

　　每个节假日都提醒灾难响应团队成员，如果发生灾难应及时到位，但有时有些人总是做不到，因此数据中心也要做好这方面的准备。最后记得要对灾难恢复计划进行测试和评审，这是确保你的计划覆盖整个业务层面的唯一方式。