文档介绍：银行数据潜伏“祸首”不如未雨绸缪
当IT灾难不可避免地发生时,导致问题发生的根本原因已经不那么重要了。最重要的是如何快速、可靠地解决问题,并将系统崩溃所造成的损失降到最低。
假如在某个星期一晚上进行批处理时,银行的后台办公系统发生了严重的瘫痪事故,也许最初没有人会把这个问题当回事。但在获知银行几千兆的数据库发生崩溃后,银行CIO们一定是悔不当初。这时,进行异地热备份的努力也宣告失败,因为备份文件对崩溃的系统进行了镜像,一场真正的危机摆在了银行CIO们的面前。由于数据恢复操作(需要花费四个小时)的窗口跳出,应用程序小组成员会和其他同事暂停其他处于优先级的程序。但该窗口并没有说明引起系统瘫痪的根本原因,也没有提示如何快速修复。小组成员花了几天时间苦思解决方法。
而银行还是必须继续营业。仅仅是同步新增数据就已经让IT小组成员够头疼的了,他们必须首先找到一个干净的数据备份。但他们发现在系统瘫痪前两天似乎已经发生了数据崩溃,而确认之前数据备份是否干净的惟一方法,就是进行耗时36小时的检测。
接下来,IT小组必须更新生产系统,重新运行业务日志文件直到发生系统瘫痪时间点为止,同时需要在接下来的几天内执行在该时间点后积累的业务。银行的高级主管必须时刻在场,方便即时决定哪些流程必须立即执行,哪些可以暂时放弃以便争取时间。
到周五,IT小组几乎完成了最新数据的同步,但他们仍然不敢确定银行是否可以在周一正常营业。虽然与此同时交易员仍可以继续处理业务,但在五天多的时间里不能进行准确的结算对账仍显得过于冒险,监管人员对此事必然异常警觉。
尽管结局完美(在周末完成了追补处理),但银行已经到了很危险的边缘,差点就要暂停所有业务。而造成这一危机的罪魁祸首只是软件包中的缺陷与服务器管理软件的小冲突造成的。没人能预料会发生冲突,更不用说事先进行测试。
恢复措施还有待改善
绝不可以将此次事故看作是孤立的突发事件。在IT系统的运行中总是伴随着类似的事故。即使采取再为严密的防范措施也无法阻止类似事故的发生。如今结论已经非常明显了:由于一些无法准确预知的原因,大多数企业都面临着关键IT设备发生严重瘫痪的危险。
当然,进行防范还是必要的。但公司领导和IT部门的领导必须将更多的资金投入到灵活的灾难恢复策略上来。为保证公司业务持续运转必然要开展很多工作,现在你必须将这些工作的重心迅速转移到确保IT系统可以从任何可能发生的事故中恢复过来。
近几年,大多数公司都开始更多地关注灾难恢复策略与业务持续方案,并投入了不少资金。一些自然灾害,如在美国发生的“卡特里娜”飓风、欧洲的热浪、印尼的海啸,都迫使各公司强化其防范措施。这些公司通过异地部署数据中心、呼叫中心,弹性安置运营与制造设施,从而极大地分散了潜在的风险。
如今,早在新流程、新系统的设计阶段,以及新业务运营地点的选址阶段,公司就会开始考虑IT系统瘫痪后的后果评估方案、风险缓解措施,以及业务的可持续性与可恢复性问题。许多公司还定期对其预案和数据备份中心进行测试。另外,大多数公司现在都设立了首席风险官或类似职位,负责公司的风险管理。他下面有专门的员工或顾问负责制定标准,监控业务流程的正常运行,并向利益相关者进行汇报。
尽管企业在不断改善这些措施,但效果仍不明显。在企业目前所采取的措施与应该采取的措施之间的鸿沟