在一家声誉卓著的全球银行，这是一个正常的周一批处理流程，直到一个关键的后台系统出现故障。一开始，IT管理员对它泰然处之。这并不是他们唯一一次需要恢复丢失的数据。但很快，事情变得明朗起来，一些不祥的事情正在发生:该行的多tb数据库已经损坏。
管理员试图切换到热脱机备份。不幸的是，它反映了腐败。在IT界，形势开始预示着“危机”。应用程序团队和其他能够提供帮助的人不得不暂停所有优先级，专注于失败。尽管做出了最大的努力，目标恢复时间——4个小时——来了又去，却没有找到问题的根本原因或解决方法的线索。
它开始看起来像一个'房子'的一集，它有管理者焦急地头脑风暴一天，试图诊断他们垂死的患者中的神秘疾病。他们知道过早的举动可能会使事情变得更糟。
在外界看来，这家银行并没有显示出严重状况的迹象。客户们继续交易，却不知道这家备受瞩目的机构即将损失数百万美元，受到监管机构的调查，并损害其良好声誉。
在客户的视野之外，IT团队努力维持病人的生命。他们急忙去找一个清白的后援。他们发现腐败是在坠机前两天发生的;对早期的数据副本进行检查，看是否干净，需要36个小时。他们致力于更新生产系统，重新运行事务日志文件以赶上崩溃点，并处理此后积累的事务天数。高级经理们开夜车决定优先处理哪些流程。截至上周五，该行还不确定能否在周一开业。如果超过5天不进行准确的结算和解，风险可能太大。该银行向监管机构发出了警告。整个周末，这个团队都在埋头进行后续处理。 Fortunately, they completed it in time. By Monday the patient was out of danger and the bank was able to open its doors.
只是时间的问题，而不是是否的问题
并非只有这家银行如此。事实上，类似的侥幸脱险越来越普遍。一家全球零售商在假日购物季将其销售点交易冻结了18个小时。原因是一个存储网络软件的错误，这个错误从未被准确地识别出来。尽管这家全球银行的结局皆大欢喜，但它的高级经理和IT团队却陷入了困境。损失本来不大，但如果失败发生在年底——当时正值投资者清理投资组合，交易正全速进行——结果可能是灾难性的。
事实证明，打包软件漏洞和服务器管理软件之间的微小冲突——这是没有人能预见的——造成了潜在的巨大灾难。这是一个没有在任何标准操作手册中解决的问题。对于银行的领导层来说，令人不安的事实是:尽管银行完全遵守内部政策和外部法规，尽管做好了站点丢失或主要硬件组件故障的准备，但它对灾难恢复的准备仍然不足。
世行是众多企业和公共机构之一，自满、复杂性和紧张的遗留系统正将IT灾难的风险提高到令人担忧的水平。尽管近年来，灾害恢复和业务连续性得到了重视，并获得了大量资金，但情况还是如此。虽然实践得到了改进，但它们已经不够了。
许多大企业现在如此依赖其系统的完美运行，以至于它们很容易受到重大、甚至无法弥补的业务损害。灾难发生的可能性越来越成为何时发生的问题，而不是是否发生的问题。
很多时候，组织让管理者和其他涉众将业务连续性的努力导向单个IT处理站点或组件的失败。在匆忙遵守规定的过程中，商界领袖忽视了他们面临的其他风险——就像这家全球银行所经历的那样，发生了无数次规模较小的事件。当服务器关闭或去中心化软件出现故障时，这些较小的问题可能会造成巨大的损失。用本杰明·富兰克林(Benjamin Franklin)的话来说，一个小漏洞会让一艘大船沉没。
作为CIO，您可以通过观察以下任何一种情况来看到您的组织没有为灾难恢复做好准备的早期警告信号:
- IT组织更专注于对最近中断的反应而不是计划从主要意外问题的快速恢复。
IT组织计划和演练灾难恢复，但过分强调明显的灾难，如建筑物的损失。大多数现实世界的问题远没有那么引人注目。
——贵公司主要IT人员即将退休。几十年的商业和应用知识将随着婴儿潮一代的退休而消失。
- 您正在实现面向服务的体系结构（SOA），帮助将单片应用程序转换为从各种包和自定义应用程序构建的分层复合材料，并提高软件错误裁剪的可能性。
新策略
当灾难发生时，是什么导致了问题并不重要。真正重要的是如何快速和可靠地解决问题，以最大限度地减少业务损害。
预防工作，包括标准备份策略和冗余系统，仍然很重要，但还不够。为了有效地最小化风险，IT主管必须将他们的业务连续性工作转向从不可预见的情况中进行可靠的恢复。
现在需要的是对快速和良好的康复的战略性强调。幸运的是，一些公司正在开创新的智能灾难恢复方法。与这些公司合作，埃森哲已经确定了新战略共同的七个关键点。每个点都需要在IT领导者的心态转变，但不是主要的资本投资。它们共同组成了一个有用的起点，以获得更详细的业务 - 连续性战略和行动。
1.讨论商业价值和业务风险。正如人们一般往往避免对死亡的详细讨论一样，人们倾向于害羞地远离商务用户如果特定的IT过程严重受损，他们将失败。然而，智能恢复策略必须揭示此类细节，以便充分分配资源。
2.多玩些战争游戏。对恢复情景的模拟(战争游戏)很少被推得足够远或足够快。在这家全球银行，技术人员还没有准备好应对经济复苏，因为他们没有演练过那样的场景。演习成本相对较低，其目的是在对客户、收入、成本和时间影响最小的情况下迅速恢复运营。
3.保持持续的“汇报”模式。IT团队应该有指定的领导者从失败中获取知识。他们也应该整合外部的知识和第三方的观点。每次有侥幸脱险的时候，他们都应该进行全面的汇报，剖析问题，捕捉并记录从中学到的关键经验教训。
4.委任资讯科技风险监察专员。除了首席风险官，任命一位受人尊敬的it风险监察专员可能会有所帮助，it员工可以向他提出担忧，而不必担心个人风险暴露。监察专员应该是一位经验丰富的技术专家，对整个IT架构有深刻的理解，能够在没有议程或从属关系的情况下发现问题。
5.重新考虑健壮性:健壮性不仅仅意味着备份的数量;它包括劳动力可用性和伙伴能力。例如，一家顶级信用卡处理公司的呼叫中心在飓风切断了员工的清洁用水后关闭了，但该公司能够将呼叫量转移到外包中心。
6.“De-average”数据。当系统在最糟糕的时刻因宕机而受到损害时，客户并不关心平均值。通过使用平均值作为基准，你实际上是在说，“如果不太可能发生，那么准备不足也没关系。”
7.修复整个事情，不仅仅是元素。而不是通过应用程序重建应用程序，识别每个应用程序如何映射到技术平台和相关（通常集成）应用程序。为了更快的结果，请协会修复它们。智能灾难恢复策略呼吁在思想中延伸永久性 - 远离合规性和自满，并朝着提高的准备感。随着组织，业务流程，应用程序和基础架构的增长，新的失败和恢复方案将继续出现。除非组织指定综合恢复方案的角色和培训人员，否则停机时间将变为数小时，数小时。客户可能会感受到影响力，并在其他地方进行业务。CIO可以没有更好的理由来行动。
Craig Sands是加拿大埃森哲的系统集成和技术实践中的一名执行合作伙伴。他的重点是帮助客户通过对齐和执行IT驱动的业务策略来成为高性能业务。
安德鲁特斯科特是加拿大埃森哲的安全领导。他是公司思想领导人的安全问题，加拿大领导项目。
你能回答这12个问题吗?
灾后恢复计划已列入董事会议程。但为了让首席执行官们给董事们一个结论性的答案，他们首先必须与首席信息官进行详尽的交谈。以下是你应该准备回答的12个关键问题:
1.告诉我我们的反应模拟和排练计划和活动。我们上一次全面演练IT灾难恢复是什么时候?
2.我们从中学到什么?我们如何从别人的业务连续性错误中吸取教训?
3.我们的复苏计划将如何在财务上帮助公司?
4.我们的恢复计划活动使我们公司更具弹性吗？
5.管理层如何知道我们在真正的紧急情况下反应的速度有多快?
6.我们需要什么样的事件监控系统来提供早期预警，这样我们就不用启动我们的应急计划了?
7.谁负责IT灾难恢复?
8.我们如何确定我们的人民训练才能有效地应对？
9.除了我们自己的员工，我们还有什么其他资源来恢复呢?
10.我们已经为硬件故障做好了准备，但如果发生大规模病毒或恶意软件攻击怎么办?
11.我们必须快速传达哪些自动响应能力并开始响应实施？
12.我们的恢复计划是否扩展到业务支持能力以及技术能力?
风险耐受性和恢复速度
恢复计划开发要求准确会计风险类型，以及了解其对业务的接受程度和潜在影响。四个实际因素值得提及。
可以在内部或第三方恢复业务运营的速度与愿意为特定的恢复策略分配资源直接相关。
ONE应根据业务需求选择恢复策略，而不仅仅是技术或设备制造商的能力或第三方热点供应商的建议。
当将业务损失与恢复成本进行对比时，两条线的交点不一定代表最谨慎的整体恢复策略。(换句话说，数学结果并不总是最好的答案。)
支持所选择的恢复策略必须理解哪种资源会被交换:时间还是金钱。
了解更多关于这个主题的信息
这篇文章，“保持灾难恢复目标的策略”最初是由首席信息官 ．