银行卡为什么会被盗刷银行的会是这样？

来源：蜘蛛抓取(WebSpider) 时间：2015-10-07 01:59 标签： 为什么银行卡会扣钱
2013 年 6 月 23 日工行系统大规模瘫痪具体情况有多严重？为什么中国最大银行会出现这么大的故障？
今天早晨起来听工行的朋友说他们的系统大规模瘫痪了，有知道内情的人来解释一下是啥情况嘛？
按投票排序
Man is least himself when he talks in his own person. Give him a mask, and he will tell you the truth. 呵呵，匿名了。阴谋论者退散吧。有同学提到是ibm数据库升级导致的故障，这只是部分事实，但是远远不是问题的全部。先来介绍下工商银行的数据中心，工行包括两个数据中心，北京一个，上海一个，还有一个容灾中心，在珠海。北京的称为北数，在西三旗建材城；上海的称为南数，在外高桥台南西路。其中南数是工行绝大部分数据库核心所在，北数大多数是周边业务居多。和其它大型国有银行一样，工行的核心业务系统运行在IBM db2 for zos， 非核心大部分是oracle，还有少量sql server。上面有人提到，工行的运维和研发是分开的，跟其它大型银行一样，核心业务系统bancs并非自主研发，而是在国外成熟的银行核心业务系统之上改的。（中行曾经花了很大力气自主研发核心系统，但是最终还是流产，现在用的是印度tata consulting services的系统）。银行，电信行业的核心数据库都是严重依赖IBM和Oracle的，而这两两种数据库非常庞大与复杂，事实绝对超出了大多数人的想象，我敢说数据库管理rdbms远比Linux内核复杂n倍。数据库的升级复杂性和windows/linux的升级根本不是一个概念，在核心数据库中打一个非常小的补丁都需要经过反复测试验证才能应用上线，更何况是升级？正是因为不可控的因素太多，所以有时候出问题甚至是不可避免的。中国特色的系统往往都有一个特点： 用户并发数大的出奇，各种奇葩业务，新的业务需求源源不断。所以对于开发以及运维人员来说都是非常大的挑战，开发的工作就是天天改需求，运维的工作很大一部分都是耗费在高并发高压力系统的维护。（同样一段代码，一个人使用与一千万人同时使用，结果截然不同）。你以为工行会没有高可用，没有容灾，没有备份，没有测试？ 高可用，容灾系统的建设多数厂商多少专家废了多少时间和心血？如果真的可以迅速切换他们不会切？测试是不可能测试到所有的场景的，有一些潜在的问题因为用户数量多会被无限放大。例如一条sql需要运行1s出结果，结果由于某种因素例如升级变慢了最后需要2s，全国几百万用户同时使用，瞬间就被放大了几百万倍，接着雪崩效应出现，骆驼被一个稻草压死。同样数据库升级完以后，并不意味着立马就能发现问题，很多问题只有到第二天正常业务时间才有可能发现。不要以为工行的人运维的水平差，很多都是技术背景很资深的，犯低级错误的可能性很小。如果你有机会看过工行数据库升级的文档你就会发现一个事实：细致的程度令人发指。即使IBM/Oracle这样的厂商的资深工程师都很容易被一些细节问得哑口无言，事实也是如此，IBM/Oracle没有任何一名工程师很乐意去工行处理问题。工行内部实行的是问责制，问题最终追究责任到人，俗称“拍板子”。像这次这样的故障，估计最终被板子拍到的部门会“生不如死“。工”行运维人员很少，并且没有引入外包，所以每个人劳动强度非常大，几乎是天天加班，碰到重大的系统割接上线更是没日没夜，工作劳动强度大，压力责任大，所以私底下里骂娘的人一大片。为了把可能的影响降到最低，维护工作基本都是放在半夜或者周末，这些工程师的牺牲是非常大的。银行业务会发生故障几乎是无法避免的，相对其它银行而言，工行的故障率已经是非常低了。
没想到我的知乎第一帖竟然是匿名呀。外资银行IT部门5年多混饭吃的人飘过。为了减少对客户的影响，一般银行的系统修改发布时间都是晚上0点开始，而系统的大规模维护，比如第一楼的匿名用户说的数据库版本升级，一般是从周六早上0点开始。这样有了问题，就算解决花时间，也不会影响到业务的正常使用。虽然普通客户使用的网银之类的是web页面，但据我所知银行柜员实际使用的一般都是类似大机的操作页面。虽然我们不负责那个部分，对大机不是很熟，但这回的问题影响到网银，ATM，柜面，那应该就是连接DB出了问题。以我们公司为例，系统环境要分开发，开发自测、biz测试、实际、4个环境。无论是application修正，还是环境改变，在开发人员测试过后，必须放到biz测试环境，由biz检测验收，之后才能正式安排上实际环境。我们现在维护的系统，为了规避风险，在biz测试和实际之间又加了一层。因为从理论上来说，biz环境应该是和实际环境相同，但是因为数据库及各个server的不同，所以有可能会因为环境配置的原因，导致在biz测试时好用的更改，放到实际环境产生问题。所以新设的DR环境，除了使用的server和instance不同之外，连数据库都是从实际环境copy出来的。这样尽可能的减少上实际环境所产生的问题。当然，就算是这样，还是会不断有问题发生。上个月我们发布的一个修正，导致银行门店的移动设备无法使用，我的同事从凌晨0点一直忙到了下午3,4点。还好是一个app的问题，没有影响到业务的办理。像这样的DB问题导致所有的app都无法使用，以我对公司的对应体制的了解，和到现在出现问题的解决方法来看：如果在早上6，7点都无法解决的话，应该直接rollback修正，或是直接切到灾备。实际环境和灾备的app, web, DB server应该是放在不同的地方。在做发布的时候，先做实际环境，通过biz测试以后，才可以将修正同步到灾备上面。国内的银行我不大清楚，但是我们公司实际上是实际环境和灾备同时运行，就算出现问题，最多单个server比较拥挤，不会出现完全down机的情况发生。上一次日本大地震加核泄漏，系统完全没有受到影响。不过听同事说，日本有个银行在灾后有一天早上银行无法正常营业，我们都开玩笑说是因为server有影响加数据量过大，导致的夜间batch花的时间过多。所以这次的工行问题的原因，由工行外部人员来看，就是：1、没有做好测试2、灾备机制问题3、应对方法有问题----------------------------------------------洗澡回来修改若干错别字。补充：1、关于版本的问题好象有许多人诟病工行修改的版本比较多。但是正常的，除了不断发生的bug fix之外，还有银行内部提出的新需求，以及正常的系统维护升级。在端午期间，我看到自己银行的主页上面有五个维护信息，基本上放假的几天天天都有维护。我们正在维护的系统，去年有一个版本升级。之后的那段时间基本上每个星期有三，四次版本发布。在一切稍微正常了以后，又做了一次UI变更。在那段混乱的日子里，据说有callcenter的小姑娘因为不知道IE是什么没法回答客户问题，直接被骂哭的。所幸没有发生系统当机之类的重大事故，这也是我可以现在继续混饭吃的原因。所以，有版本更新不是问题，问题是，发生的issue会造成多大的影响。如果真有在运行的程序发生问题，就算是凌晨，也会有人把我们call起床连夜解决，领导为了向上面的领导交差也会用小皮鞭抽打我们尽快解决。2、关于发布时间我们维持的web系统是没有green zone的，所以我们都是在凌晨发布。但是后台的许多程序则不同。如内部客户使用的系统，我们在同biz协商之后，就可以在下午6点之后做升级。如大机之类的，是需要在晚上跑batch处理数据。这就需要或暂停batch，或避开这段时间。这可能就是匿名用户爆料说工行是凌晨4点做的升级。
纠正一下'工行珠海不是容灾中心，而是开发中心。真相已经大白，IBM DB2的一个隐藏较深的Bug而已，交易量低的时候不会触发，交易量上去后就暴露了。
IBM DB2 V9升V10故障回退的时候数据库挂了，无法开启备份，经查为IBM原因，数据中心（南）及软开上研应用支持均未有人员受到任何处分
大公司并不意味着不会出现大的故障，只是出现大故障的概率相对小。其实平时也会故障，只是灾备及时、处理得当，以至于在用户层面看不到。还有就是平台大了之后，任何一个小问题都有可能触发未知的bug。
外包模式和国企管理体制，注定开发不出高性能高可用高可运维的大型系统。核心技术掌握在别人手里，不出事才怪。
我知道不能说，百年不遇的事情
工行南数据中心前非技术部门员工飘过……一年四次大的版本投产，前年就亲身经历了一次系统升级故障到早晨九点下夜班都没解决，如果再多一个小时估计也就会造成灾难性的影响，据说只是因为南北中心之间一个数据包的漏传。帮助中心 - 财付通

我要回帖

更多关于 为什么银行卡会扣钱 的文章

 

随机推荐