扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
ZDNet至顶网软件频道消息:6月23日,中国工商银行系统瘫痪导致全国多地工行系统柜面取款、ATM、网银等无法办理。24日,中国银行系统也短暂瘫痪,一时间金融业钱荒,银行股价暴跌,金融市场流动性紧张……引发民众猜想。有人揣测是“资金量缩紧的过激反应”;还有揣测是被黑客入侵?甚至微博有人暗示此事并非事故,那么真实情况是怎样的?
由于银行业务的特殊性,对于系统的可用性要求极高,针对此事件,笔者收集了相关资料:
事故原因很简单,期货公司没按报文保送要求发了空文本,导致系统处理缓慢。注意,是处理缓慢,不是宕机,更不是瘫痪,更与什么所谓“钱荒”没有半毛钱关系。
很多网友对此描述并不买账,认为这个理由太牵强。
对此,IT顾问jaccc发表了一些看法,分析的很透彻,我们一起来看下:
为什么IT系统会出问题?
为什么会大面积的出现问题?
因为三个字:大集中。最早之前,银行系统还没联网,一出问题只是某个区或者某个市。最近十多年银行业都在搞大集中:五大行除了中国银行之外的四家都已经完成了大集中。
为什么这种故障好像越来越多了?
以前没有微博没有微信,只要你不是倒霉的用户就不会知道出过问题。我要不是上微博也不知道工行出这么大的事。以前没有网银没有淘宝,你半夜不会买东西刷卡。用行话来说就是以前没那么多7*24的需求(一周7天,一天24小时运行)。
为什么没有应急预案或者应急预案没有起作用?
与电信运营商,政府行业,普通企业相比,银行是中国IT业中IT基础最好,最严谨的行业。比如有的银行还要求厂商维护人员不能操作,只能银行员工操作。
大的变更一定会有预案,甚至换个硬盘,改个IP这种做过几百次的操作都会有预案。但预案与真实一般都有相当差距。上面已经提到系统非常复杂,可能出现的问题如果真全部写下来,可能有几百几千分支。而且,系统的故障并不会根据你的应急预案来发生。
只靠应急预案真解决问题的概率比拿着《泡妞指南》泡到美眉的几率还低,应急预案的最重要的作用是应付上级监管,根据应急预案搭好可能需要的应急软硬件环境,大致理清概要思路,以及锻炼团队。真有复杂问题,还是靠牛人现场解决的多。
平心而论,工行的IT能力和运维水平在四大行里面不是第一就是第二了(不同的省份略有不同)。
为什么要停几个小时这么久?
先说定位问题的时间:从发现问题上报到IT信息中心(或者在监控系统发现问题),IT中心的人开始查系统,定位故障原因,如果定位不清还要找相关的软硬件人员到场或者远程网络支持(基于安全原因,银行大部分都不能远程网络查看系统,维护人员到数据中心也需要时间,如果还堵车.....),找出问题的根源,一小时算超快的了。类似你莫名高烧,到底是哪个器官出问题,去医院做检查做判断总需要时间吧?
解决问题就更不好说了,其实和大家的电脑一样,往往重启是最有效的方法,但很多业务系统部分出现问题是不能重启的(可能会影响别的业务系统)。至今国外各大厂商的标准维护合同,绝大部分都没有承诺修复时间。
根据手头的一份略过时的银监会突发事件应急管理规范:一个省停业6个小时以上才算I级特别重大突发事件,3小时是II级,半小时以上是III级。以管窥豹,落叶知秋,几小时真不算什么。
不是说有容灾和备份吗?为啥不快速切过去就好了?
这是一个很常见的误解:出了故障的时候,有备份系统和容灾系统就可以很快恢复业务。一怀愁绪,几年离索,错,错,错。
先说备份系统,常规备份系统是不能运行业务程序的:备份一般只是把数据保存多一份或者几份,一般是在丢数据的时候才用来恢复,而且恢复的时间很多都在几小时以上。类似大家手头只有一个avi文件,没有播放软件也没法看啊,只不过银行的“播放软件”要架设起来就复杂了.....
再说容灾系统,强调一个连很多IT人都不清楚的事实:银行容灾系统不会轻易启用整体切换!前面已经说了,IT系统已经这么复杂了,容灾系统相当于再复制一套,复杂性增加了不止2倍。切换起来是非常麻烦,非常伤筋动骨,惊动非常多人力物力,不是碰到大灾大难(比如地震,机房着火,恐怖分子爆炸之类)不会进行切换。
当然平时会进行容灾切换演练,但一般不会拿核心系统来真实切换,原因是有风险。以前也出现过华东某省级行(还是某省某运营商?记不太清楚了)切换到了容灾中心后切不回生产中心的悲催惨剧。最近西北某地农信社成功的把核心生产切到了容灾系统上,比较不简单,不过这毕竟是独立法人的小银行,大行不是这么个玩法。
这么说吧,迄今为止,五千年来,四大行的核心容灾系统都没出现过需要两地切换的重大灾难的场景,和准备买iPhone6的肾一样,有两个,没切过,但时刻准备着切....其实个人不太靠谱的猜想,就算停个三五天,各大行都不会愿意全业务切换,今天这种停几小时的算个毛有啥好切的,赶快修好系统就是了。
另外,看到有不少评论说“没人敢担风险切换到灾备节点上”。其实一般是这样的:建好容灾系统之后往往都会写一套DRP(灾难恢复计划)或者BCP(业务连续性计划),就是容灾系统启动的流程方案,里面会规定好什么场景下由什么人拍板切换到灾备中心,一般不会真出问题才临时来拍脑袋来想,(当然临时调整也是有可能的),也不是谁说切换就谁去背黑锅。
当然,大部分的小故障会通过双机切换,快速重启部分应用的等方式解决。但很快解决了,你们就意识不了其实已经出过故障了嘛,是不是有点人择原理的味道?......但总有无法快速解决的问题。补充一句,当然业界有很多新技术已经把备份高可用灾备等揉在一起了,但银行业应用还不多,这里就不展开了。
升级要失败,快速回退不就好了嘛?
一个常见的误会:升级不成功马上回退啊。这是很理想的情形,现实的情形是这样的:
1. 技术上无法回退。我举个例子,你从winxp升级到win7,升到一半,蓝屏了,或者报某个文件包找不到了。你会回退吗?
2. 回退的风险更大,升级过程中很多配置,软硬件都改掉了,改不回来了,或者耗费的时间比继续升级更大。
3. 硬着头皮冲过去就算超了时间的还能找个理由掩饰一下,回退了就确定升级失败了,下次继续升级的政治压力会很大。
所以实际情况中,除非可以很干净利落的回退,而且实在升级无法成功,才会回退。真的升级切割出问题会进行回退的不超过5%。
周日到底出什么问题了?
在中国,无论出现什么IT系统问题,对外宣称总是电脑系统升级。我以前就有个变态的习惯在处理故障中途如果有空(等别人处理或者等系统回滚什么的时候)就打呼叫中心电话,听那些美眉怎么解释系统用不了了。清一色的,100%的,毫无例外都说是电脑系统升级。当我再问为什么大白天升级啊?为什么之前不通知我们客户啊?这时候就能体现呼叫中心的培训能力的差距了。
回到今天这事,别说我现在还没去八卦,就算知道了也不可能公开说,这是职业操守的问题。而且有的故障的真相是查不出来的(你知道你每次生病的确切原因吗?),有的故障是查出来但不能实说(一般故障分析报告书很快就能到竞争对手手中)。这种情况下,怎么去写故障分析报告,是一门艺术:真相不重要,达到目的才重要。这个目的有可能是大事化小,有可能是小事化大,水深着呢。
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者