2013.6.23，工行发生重大系统故障，已经有一阵子了。今天想起写这个话题，完全是因为昨天看到了一条现在已经被和谐的微博，当时随手收藏却忘记了粉一下Po主，和谐之后已经死无对证，找不到“传谣”的人了，于是标题的最后形容某群体组织的四个字的专有名词变成了“工行”，不过也好，原来想的标题估计是跨不过深壑的。

   先来还原一下现场。2013.6.21，@中国工商银行电子银行 微博发布维护公告：

   尊敬的客户：为了能够向您提供更加优质的服务，我行将于2013年6月23日0:10—1:40进行系统优化。期间，我行网上银行、电话银行、手机银行、短信银行、银企互联等相关系统将暂停服务。由此给您带来不便，敬请谅解。

   从公告来看，这次维护涉及的面非常广，而时间只有90分钟。一般来说这种计划内的维护都会包括实际操作时间和系统验证的时间，金融类系统的验证工作一般也会比较耗时。因此推测前期准备工作应该还是比较充分。但凌晨2点到4点左右是业务最低峰时间(按照网购业务的低峰期推测)，问题可能就出在这里，由于缺乏实际业务压力，验证工作可能只是做了功能性测试。到早上9点，业务压力上来以后，问题陆续出现，根据上述微博在当天12:50发布的消息推测，系统在10点半左右彻底崩溃：

   6月23日上午10点38分至11点23分，中国工商银行部分地区因计算机系统升级原因造成柜面和电子渠道业务办理缓慢。目前系统已恢复，各项业务业务正常办理。中国工商银行对因此给客户带来的不便深表歉意。

   大约11:23，系统故障排除，业务陆续恢复。这次故障同时影响柜台、ATM、网银和电话银行等各个业务渠道，问题应该是出在交易系统的数据库，和当天凌晨的升级肯定有因果关系。今天网上有消息称工行发布了内部通报：

   “6月23日上午，数据中心(上海)监控发现主机CPU利用率升高，经分析判断与6月23日凌晨实施的主机DB2数据库软件升级版本有关(从V9升级到V10)，在紧急回退升级系统软件版本后系统运行恢复正常。”

   并且关于紧急回退版本的具体原因被归结为：

   由于IBM提供的主机DB2V10版本内存清理机制存在缺陷引发。

   首先补充一点技术背景知识，我对DB2也不是很熟悉，但是根据多年的Oracle/MySQL DBA经验，升级数据库有两种方案，一种是将新版本安装到新位置，用新版本数据库软件启动实例，执行升级脚本升级数据库的元数据，这样因为旧版本的软件还在，如果升级出现问题，还可以使用旧版本重新启动实例并执行降级脚本；另外一种是直接覆盖升级旧版本的数据库到新版本，但这样遇到问题就需要重新安装旧版本数据库软件。很明显，所有的数据库升级操作都应该选择第一种方案，而这次工商银行的升级也应该是做出了正确的选择。

   好，现在假设我们是这次升级的负责人，凌晨顺利升级完成，检测所有功能正常，回家倒头睡觉。早上九点陆续收到告警，心里一惊，立即登录系统发现系统可用内存被快速消耗，随着业务压力越来越大，数据库链连接不断上涨，内存用尽，大量数据被交换到swap导致I/O响应越来越慢，最终数据库主机挂死，异常宕机。这时候又面临两种选择：一种是重新启动主机，回退到旧版本数据库，这需要大约30分钟到60分钟的重启和执行降级脚本的时间，但可以保证数据的一致性；另外一种选择，先不管已经挂死的主机，立即切换到灾备中心的备库(这里还需要假设备库的数据库版本没有升级，否则在业务压力下问题重现的几率非常高，所以也提醒我们，在制定数据库升级的方案时，主备库最好能错开时间执行)，这样只需要将备库切换成主库的时间，一般几分钟内就能恢复业务，但是由于原来的主库宕机时，还有部分数据在内存和磁盘缓存的日志文件中可能没有同步到备库，可能会导致部分最新的交易数据受损。

   在这种情况下，你会如何选择？尤其是你心里还很清楚，灾备中心平时很少做切换演习工作，你根本不敢保证切换到备库就能100%将业务恢复正常，还要承担部分交易数据不一致的后果。宕机一个小时会成为新闻头条，但要是交易数据不一致导致用户或者银行的money受损，那自己的头可能被老板敲成一条。。。

   所以，理性的人一定会选择重启故障主机，使用旧版本数据库软件启动实例，执行降级脚本，恢复业务。这个过程由于紧张，加上应用软件可能还有些依赖要依次启动，业务流量需要限流慢慢放入系统，以便系统充分预热，因此恢复的时间会比计划内的维护时间要长很多，最终到11:23分，数据库终于有新的连接进来，各业务方陆续反馈恢复正常，你终于可以长吁一口气，揉一下眼睛，敲一下脑袋，开始思考怎么写故障报告吧。

   所以，不用惊讶为什么花费了大量成本建设的灾备中心在这种情况下毫无用处，大部分灾备中心就是这么设计的。在对事务一致性要求非常严格的场景下，牺牲一定的业务连续性时间来获取一致性，这是符合CPA定理的合理选择。2008年，淘宝面临过同样的情况，当时机房异常停电，运营商一声不吭的躲在角落里抢修。终于在UPS电源支撑到最后一分钟时，运营商才打电话通知我们，电话还没说完，所有数据库就直接嗝屁了。当时的淘宝，虽然也有了备用机房，但两边还没有完全做到1:1对等，灾备演习也还没有成为常态(计划内切换已经是常态)，加上在机房和运营商抢修人员沟通时，他们拍胸脯保证一个小时内能修好。于是我也就在机房里忐忑的度过了一个小时，中间有几次想下定决心做异常切换启用备库，最后在心理底线前电源恢复，赶紧启动小型机，启动数据库，还好都能正常启动，一场忙乱，现在想起来还历历如新。

   这几年，淘宝的系统架构在发展的过程中，应该说充分的考虑了2008年这种惊险一小时的整机房断电的场景，从web到应用到数据库，都做了比较充分的容灾架构，并且从2010年开始实行严格的定期灾备切换演习。现在已经可以做到高峰期暴力演习，数据库和应用流量都能够做到自动切换，而用户几乎无感知。2008年的那次断电，也可以说功不可没。

   故障不可怕，可怕的是对故障视而不见，推脱责任，找替罪羊。至于工行的这次故障，据说内部通报的结论是这样的：

   同时，工行总行信息科技部将该事件直接原因归为IBM公司提供的软件产品存在缺陷，并称这点“经IBM公司正式确认”。

   所以，我们都懂的。

   ===== 一零二四的分割线 =====

   最近刚开了个微信公众帐号【数据说话】，这是在上面推送的一篇文章，自从有了微博以后慢慢的很少写稍微长一点的东西了，准备用微信公众号督促一下。

   如果有兴趣，欢迎关注，我会分享一些互联网和移动互联网方面的数据和观点。有几种方式可以都可以进行关注：

   1. 可以用任何一款有扫码功能的App(微信，火眼，或者淘宝客户端等)扫描本站右上角的二维码

   2. 微信->朋友们->添加朋友->搜号码，输入微信号【DataTalk】搜索

建议继续学习：

1. 企业掘金大数据的两种选择    (阅读：2199)
2. 数据化比大数据更靠谱    (阅读：2143)
3. 妄谈时间序列表格型大数据系统设计    (阅读：1435)
4. 大数据过滤及判断算法 -- Bitmap / Bloomfilter    (阅读：1363)
5. 五种常用基数估计算法效果实验及实践建议    (阅读：1080)