假如在某个星期一晚上进行批处理时，银行的后台办公系统发生了严重的瘫痪事故，也许最初没有人会把这个问题当回事。但在获知银行几千兆的数据库发生崩溃后，心很快就会凉半截。

　　进行异地热备份的努力也宣告失败，因为备份文件对崩溃的系统进行了镜像。一场真正的危机摆在面前。由于数据恢复操作（需要花费四个小时）的窗口跳出，应用程序小组成员会同其他同事暂停了其他处于优先级的程序。但该窗口并没有说明引起系统瘫痪的根本原因，也没有提示如何快速修复。小组成员花了几天时间苦思解决方法。

　　与此同时，银行不得不继续营业。仅仅是同步新增数据就已经让IT小组成员够头疼的了。他们必须首先找到一个干净的数据备份。他们发现在系统瘫痪前两天似乎已经发生了数据崩溃。而确认之前数据备份是否干净的惟一方法，就是进行耗时36小时的检测。

　　接下来，IT小组必须更新生产系统，重新运行业务日志文件直到发生系统瘫痪时间点为止，同时需要在接下来的几天内执行在该时间点后积累的业务。银行的高级主管必须时刻在场，方便即时决定哪些流程必须立即执行，哪些可以暂时放弃以便争取时间。

　　到周五，IT小组几乎完成了最新数据的同步。但他们仍然不敢确定银行是否可以在周一正常营业。虽然与此同时交易员仍可以继续处理业务，但在五天多的时间里不能进行准确的结算对账仍显得过于冒险。监管人员对此事非常警觉。

　　尽管结局完美（在周末完成了追补处理），但银行已经到了很危险的边缘，差点就要暂停所有业务。而造成这一危机的罪魁祸首只是软件包中的缺陷与服务器管理软件的小冲突造成的。没人能预料会发生冲突，更不用说事先进行测试。

　　恢复措施还有待改善

　　绝不可以将此次事故看作是孤立的突发事件。在IT系统的运行中总是伴随着类似的事故。即使采取再为严密的防范措施也无法阻止类似事故的发生。如今结论已经非常明显了：由于一些无法准确预知的原因，大多数企业都面临着关键IT设备发生严重瘫痪的危险。

　　当然，进行防范还是必要的。但公司领导和IT部门的领导必须将更多的资金投入到灵活的灾难恢复策略上来。为保证公司业务持续运转必然要开展很多工作，现在你必须将这些工作的重心迅速转移到确保IT系统可以从任何可能发生的事故中恢复过来。

　　近几年，大多数公司都开始更多地关注灾难恢复策略与业务持续方案，并投入了不少资金。一些自然灾害，如在美国发生的“卡特里娜”飓风、欧洲的热浪、印尼的海啸，都迫使各公司强化其防范措施。这些公司通过异地部署数据中心、呼叫中心，弹性安置运营与制造设施，从而极大地分散了潜在的风险。

　　如今，早在新流程、新系统的设计阶段，以及新业务运营地点的选址阶段，公司就会开始考虑IT系统瘫痪后的后果评估方案、风险缓解措施，以及业务的可持续性与可恢复性问题。许多公司还定期对其预案和数据备份中心进行测试。另外，大多数公司现在都设立了首席风险官或类似职位，负责公司的风险管理。他下面有专门的员工或顾问负责制定标准，监控业务流程的正常运行，并向利益相关者进行汇报。

　　尽管企业在不断改善这些措施，但效果仍不明显。在企业目前所采取的措施与应该采取的措施之间的鸿沟已经越拉越大了。

　　当灾难不可避免地发生时，导致问题发生的根本原因已经不那么重要了。最重要的是如何快速、可靠地解决问题，并将系统崩溃所造成的损失降到最低。这对CIO的前途也同样重要。

　　IT员工需提高能力

　　从此类事故中，我们可以看出两个方面的问题。第一，以保证公司业务正常进行为己任的IT部门员工，大多数经常将工作的重心放在解决当前的系统中断问题上，而没有前瞻性，不会主动思考当下一次又出现软件冲突或安全缺口时，可以如何让系统迅速恢复过来。

　　第二，当IT部门员工为潜在的事故隐患制定预案并进行演练时，他们往往将事故对象想象为立即发生的、一目了然的灾难性事故。作为凡人，这些高级主管也只能想象得到此类“大厦倾覆”似的灾难性场景。但在现实世界，例如上述的银行及其软件缺陷的案例，其实是复杂得多的，根本无法预测。

　　IT系统性能出现降低时往往无声无息，而其原因并不一定就是某一个系统组件的故障。

　　最近，一家业界领先的通讯服务供应商进行了大规模的扩张。这一举措的确吸引了许多投资者的眼球，但对公司某些业务领域造成了严重影响。具体点说，就是公司的IT系统架构面临极大压力，死机时间始料未及，达到了告警级别。99%的数据中心系统资源被占用，每进行八次数据备份就会失败一次。而IT部门员工针对系统告警做出的反应则稍显迟钝。“严重死机时间”（即系统瘫痪对客户造成直接影响）比例相当之高。

　　幸运的是这个故障是可以解决的。这个案例是为了说明IT系统故障往往是毫无征兆地发生。无论造成问题的根本原因是大是小，是日积月累造成的还是突然急性发作的，都值得企业领导者认真思考。IT人员通常无法兑现保证公司业务持续进行的承诺。他们也许可以保证使系统从硬件故障中恢复过来，但在软件问题上却无法保证。

　　调整心态，未雨绸缪

　　某些未雨绸缪的公司现在已经在探索新的系统恢复方法。埃森哲与这些公司一道归纳了这些新方法中七个重要的共同点。其中每一点都要求IT部门的领导改变心态，而非大量的资金投入。这七点非常实用，是规划详细的业务持续策略与措施的重要参考。

　　1.关注业务价值与业务风险。IT部门的员工非常不愿意问业务用户这个问题：当某些IT系统的特定进程不可用或性能降低时，你们会受到何种影响。尽管心中不悦，但必须面对这个问题。同时，企业还要参考所需资源，包括成本，来确定恢复业务正常运营的策略。业务运营的恢复速度，只需内部人员来解决还是需要第三方参与等，都直接关系到对特定恢复策略的资源分配。

　　2.频繁演练应急预案。在上文所述的银行，由于可以事先决策好的应对措施拖到事故发生后才进行决策，业务恢复所花费的时间远远超出了这些技术人员的预期。

　　事实上，对类似的业务恢复进行模拟演练用不了多少投入。进行模拟演练时，一定要选择演练如何在最糟糕的情况下使业务最快速、最稳定地恢复。因为使业务快速恢复正常运营可以降低对客户、公司利润、成本、时间的影响。

　　3.建立持续的“学习”机制。IT部门需要建立一种机制，当同行公司发生类似事故时可以向其进行全面的咨询和学习。只有对发生在其他公司和自己内部的类似事故进行解析，才能够真正学到一些教训和经验。IT部门应当设置一个专职人员收集相关方面的经验和知识。

　　4.任命一个IT风险调查员。设置首席风险官等类似职位十分重要，一些公司还认为有必要设置一个IT风险调查员的职位。换句话说，就是一位受人尊敬的高级主管，IT部门的员工可以毫无顾忌地向他提出担忧的事情。调查员可以扮演一个问题发现者的角色，没有固定的日程安排，也不从属于哪个部门，而且还可以作为经验丰富、对IT系统了如指掌的技术专家，给IT人员提供指导。

　　调查员应该是恢复理论的支持者，应当关注如何保持业务的价值，而不仅仅是充当业务持续经理的角色。调查员还应当全力支持创建综合的故障诊断方法，为实施广大的业务恢复管理措施打好基础。

　　5.重新评估系统的鲁棒性（robustness，即系统的健壮性，它是在异常和危险情况下系统生存的关键—编者注）。在一家顶级信用卡处理器公司的总部，由于飓风后工作人员无法进入打扫其中的积水，导致其呼叫中心被迫关闭。之后，由于公司想方设法将呼叫接入到其外包的呼叫中心，避免了呼叫中心业务继续关闭。

　　6.不要迷信平均数据。根据平均数据来设置应急措施或看待系统死机的可能性会有失偏颇。当系统在最糟糕的时刻出现死机时，客户是不会和你谈论系统性能的平均数据的。使用平均数据表明你认为：在不太可能发生系统瘫痪事故的前提下，事先的准备措施不完善也无所谓。

　　7.从全局看问题，而不是将问题割裂开来。当系统瘫痪后，IT人员通常首先会一个应用接一个应用地重建系统的处理能力，然后考虑为什么该流程一直不能及时恢复数据中心的业务。其实，每一个应用都会映射到至少一个技术平台，以及相关的（通常是集成的）应用。所以，你必须识别并修复这些关联的应用。

　　将关注的焦点延伸到制定恢复策略上永远都是一个挑战。只要业务流程、组织机构、应用程序、基础设施不断发展，新的系统瘫痪问题和系统恢复场景就会层出不穷。若要制定出有效的恢复策略，你需要彻底调整心态，既不唯唯诺诺也不洋洋得意，而是时刻做好思想准备。

　　如果没有设置专职岗位，且员工没有在全面的恢复场景中得到培训和演练，系统瘫痪的时间会从几分钟变成几小时，从几小时变成几天，并越来越可能影响到客户，最终导致客户的投诉。这些原因足够让公司CEO重视起来并采取行动了。

　　原文经许可摘自埃森哲旗下杂志Outlook 2008年1月号。Outlook杂志2008年登记版权。刘维译。

　　Gil Brodnitz是埃森哲公司负责战略IT 系统有效性实践的高级主管。Gary A. Curtis是埃森哲公司负责技术咨询全球业务的团队经理。Robert Emmel是埃森哲公司芝加哥分部负责业务持续性计划实践的团队经理。