系统维护现不到账 2013 年 6 月 23 日工行系统大规模瘫痪具体情况有多严重？为什么中国最大银行会出现这么大的故障？

没想到我的知乎第一帖竟然是匿名呀。

外资银行IT部门5年多混饭吃的人飘过。

为了减少对客户的影响，一般银行的系统修改发布时间都是晚上0点开始，而系统的大规模维护，比如第一楼的匿名用户说的数据库版本升级，一般是从周六早上0点开始。这样有了问题，就算解决花时间，也不会影响到业务的正常使用。

虽然普通客户使用的网银之类的是web页面，但据我所知银行柜员实际使用的一般都是类似大机的操作页面。虽然我们不负责那个部分，对大机不是很熟，但这回的问题影响到网银，ATM，柜面，那应该就是连接DB出了问题。

以我们公司为例，系统环境要分开发，开发自测、biz测试、实际、4个环境。无论是修正，还是环境改变，在开发人员测试过后，必须放到biz测试环境，由biz检测验收，之后才能正式安排上实际环境。

我们现在维护的系统，为了规避风险，在biz测试和实际之间又加了一层。因为从理论上来说，biz环境应该是和实际环境相同，但是因为数据库及各个的不同，所以有可能会因为环境配置的原因，导致在biz测试时好用的更改，放到实际环境产生问题。所以新设的DR环境，除了使用的和不同之外，连数据库都是从实际环境copy出来的。这样尽可能的减少上实际环境所产生的问题。

当然，就算是这样，还是会不断有问题发生。上个月我们发布的一个修正，导致银行门店的移动设备无法使用，我的同事从凌晨0点一直忙到了下午3,4点。还好是一个app的问题，没有影响到业务的办理。

像这样的DB问题导致所有的app都无法使用，以我对公司的对应体制的了解，和到现在出现问题的解决方法来看：如果在早上6，7点都无法解决的话，应该直接修正，或是直接切到灾备。

实际环境和灾备的app, web, DB 应该是放在不同的地方。在做发布的时候，先做实际环境，通过biz测试以后，才可以将修正同步到灾备上面。国内的银行我不大清楚，但是我们公司实际上是实际环境和灾备同时运行，就算出现问题，最多单个比较拥挤，不会出现完全down机的情况发生。上一次日本大地震加核泄漏，系统完全没有受到影响。不过听同事说，日本有个银行在灾后有一天早上银行无法正常营业，我们都开玩笑说是因为有影响加数据量过大，导致的夜间batch花的时间过多。

电脑系统地震后大规模故障 日本瑞穗银行行长引咎辞职 国际受地震影响 日本瑞穗银行大量汇款业务仍未到账--国际--人民网

所以这次的工行问题的原因，由工行外部人员来看，就是：

1、没有做好测试

2、灾备机制问题

3、应对方法有问题

----------------------------------------------

洗澡回来修改若干错别字。

补充：

1、关于版本的问题

好象有许多人诟病工行修改的版本比较多。但是正常的，除了不断发生的bug fix之外，还有银行内部提出的新需求，以及正常的系统维护升级。在端午期间，我看到自己银行的主页上面有五个维护信息，基本上放假的几天天天都有维护。

我们正在维护的系统，去年有一个版本升级。之后的那段时间基本上每个星期有三，四次版本发布。在一切稍微正常了以后，又做了一次UI变更。在那段混乱的日子里，据说有的小姑娘因为不知道IE是什么没法回答客户问题，直接被骂哭的。所幸没有发生系统当机之类的重大事故，这也是我可以现在继续混饭吃的原因。

所以，有版本更新不是问题，问题是，发生的issue会造成多大的影响。如果真有在运行的程序发生问题，就算是凌晨，也会有人把我们call起床连夜解决，领导为了向上面的领导交差也会用小皮鞭抽打我们尽快解决。

2、关于发布时间

我们维持的web系统是没有green zone的，所以我们都是在凌晨发布。

但是后台的许多程序则不同。如内部客户使用的系统，我们在同biz协商之后，就可以在下午6点之后做升级。如大机之类的，是需要在晚上跑batch处理数据。这就需要或暂停batch，或避开这段时间。这可能就是匿名用户爆料说工行是凌晨4点做的升级。