加载中…IT风险: 亡羊补牢了吗?
(2010-08-10 11:27:46)
标签：
星展银行cioibmit风险亚太地区it外包it灾难it |
分类： 综合 |
对于每一个CIO来说, 一场IT重大事故的发生都是一次重大的职业挑战:
他(她)一方面要应对外部客户和媒体的指责,并给出一再的承诺;另一方面,还要仔细地调查事件发生的来龙去脉,IT内部员工的士气低落,并处于严密的防守之中。
而很多IT事故涉及到的深层原因可能是系统性的和结构性的,甚至是必然的。
还有不少看似是超出人的控制,”不可避免”的。
在喧嚣的争论之后,从失败中获得什么经验教训? 有什么样的整改措施? 用传统的办法就是:
亡羊补牢了吗?
新加坡星展银行上个月的服务瘫痪长达7小时事件,也有了最新的调查结果和行动。 从这个鲜活的案例中,
众多的CIO们从中可以获得不少值得借鉴的东西。
亡羊补牢的第一步是什么?
承认错误!
在很多案例中,我们都发觉这一点很难做到。 假如不能或不愿意承认错误,
亡羊补牢事实上也就不能真正地彻底和有针对性。
IBM全球技术服务亚太地区总经理Andrew Sotiropoulos说:”
他们的维修次序是错误的,与系统本身所辨认出的问题所需要解决方案有落差,系统因此进行自我保护,切断了与主机的联系。”
星展银行科技与运营总经理David Gledhill 在说明系统瘫痪的导因时说: “ 肯定是人为疏忽。”
亡羊补牢的第二步是什么?
是不是在同样的地方”补的牢”足够坚固? 有没有其他的地方? 有没有举一反三? 有没有系统性的原因?
我们来看一下金融管理局要星展银行采取的七项措施:
分散和减少外包的风险
对主机的存储和系统配置进行彻底的内部审核
重新设计网上和分行的银行系统平台
审核外包商提供的服务, 硬件和软件相关的流程和功能
评估外包商达到银行提出的服务水平,恢复时间等要求的能力
在银行内部成立系统和网络指挥中心
加强银行迅速启动并成功运行灾难复原计划的能力
亡羊补牢的第三步是什么?
有没有转换为切实的行动
星展银行在金融管理局的要求下,抬高其运营风险加权资本,另外拨出2亿3000万新元作为监管资本,
银行已经开始对内部运作展开独立检讨,加快落实各项措施,包括加强与客户的沟通,更换新提款机,以及分散IT的外包工程等等。
CIO2020认为:
IT风险管理是一项长期而且艰巨的任务,需要大量扎实而且默默无闻的努力,并且要从企业文化的层面建立IT风险文化,你的IT风险成果如何,
不是审计人员给你多高的分数, 不是外部媒体对你如何的塑造,IT的结果通常可以清晰地给你打分: 系统在工作还是不工作 ?!
附录:
7月3日,早上 11点06分
IBM亚太地区支持中心接获星展数据库中心的软件监测系统的警报: 数据库与主机间的通信电缆出问题, 经星展批准,
IBM工程师赶到现场,尝试修复系统
7月3日,晚上7点50分
工程师替换了出问题的电缆, 虽然这是错误的解决步骤,但警报解除,数据库完好
7月4日,下午2点55分
警报再次出现,指通信电缆与相关数据卡出现问题, 工程师赶到现场,并通知IBM区域支持中心
7月4日,下午5点16分
现场工程师按照支持中心的指示,用同样错误的步骤把电缆拔出,检查后接回到系统中, 警报解除,数据库完好
7月4日, 下午6点14分
警报再次出现, 支持中心花了5小时22分研究系统的记录,然后提议工程师二度拔出电缆,看是否有受损的电缆针, 数据库完好
7月4日, 晚上11点38分
电缆针没有受损,工程师再次把电缆接回系统中,数据库仍能与主机相联,支持中心和工程师继续研究该问题,也三度拔出接回电缆
7月5日,凌晨2点50分
在接获IBM的通知和汇报后,星展决定二度更换电缆。
在用户流量较低的凌晨时分更换电缆是标准做法。在等待新电缆的同时,工程师决定用之前一样的错误解决步骤,再次检查电缆
7月5日,凌晨2点58分
工程师又用同样的步骤更换电缆,使得系统出现可能损害数据完整性的问题,
数据库于是自行切断与主机的联系,导致星展自动提款机和银行服务瘫痪
喜欢
0
赠金笔