【话题讨论】从6·23工行事件 谈企业IT系统灾备问题（获奖名单已公布-2013-7-25）

sofa110

http://news.ccw.com.cn/corp/htm2013/20130712_1016857.shtml

铁道部12306网站瘫痪，给全国百姓回家买票添堵，可以把责任推给CDN外包服务商，而四大银行只能自己做检讨。“工行的灾备系统是自己做的，如果灾备做得到位，完全可以在系统发生问题时秒级恢复。”黄伟说。

亮点啊

wolfop

回复 40# arron刘
数据库的大版本升级应该是非常谨慎的事情，本应该在前期进行大量的测试，而且对于工行这样的系统绝不要做小白鼠，应该充分等到DB2 10 On Z有充分的关键生产案例和在测试系统上进行过充分的回归测试后才考虑升级。
其后，就是其具体错误的原因，对于Z可能特殊一点，不清楚这个内存清楚的BUG是怎么导致整个多节点的DB2 with sysplex宕机的，难道是工行的自己操作的问题要IBM来背黑锅？这类事情在别的IT系统中我知道是发生过的，根本不是硬件或者软件问题，操作失误但是对外宣称是硬件或者软件故障。
如果是ORACLE，原则上MAA架构建议在同一个机房除生产用RAC外，增加一个同网段的DG standby，如果主RAC故障，考虑用同机房的DG STANDBY来接管，而不是马上考虑切换到远程的DR站点。相同机房的DB切换，显然比远程的DR切换成本低的多。而且这种情况还是非常严重的DB损坏不能打开的情况，如果只是某些内存清除啥机制的问题，也许单独重启RAC集群有问题的instance即可。

   

kinfinger

回复 1# arron刘
看到这个topic，十分惊讶，认真的读过大家的评论，感受颇深，现总结如下：
1 点评：
       再一次被活动奖励深深的折服了。到底神马情况下会用到这样的本子呢？？最新一期的核心期刊《走进科学》杂志发表署名三蛋文章《再论笔记本之现代必要性》，科研人员经过长达数千项分析，一致谨慎认为此种笔记本很适合大热天扇扇子，但是要注意将封皮取下并打开使用。对于lz的这种选题娱乐目的大于科研目的的标题行为，本吊表示很无语。而三蛋表示很开心，因为这样的论题距离他的论题又开始天渊之别了？？？？
本topic的奖品深深地折服~~~~~~~~~

铁道部12306网站瘫痪，给全国百姓回家买票添堵，可以把责任推给CDN外包服务商，而四大银行只能自己做检讨。“工行的灾备系统是自己做的，如果灾备做得到位，完全可以在系统发生问题时秒级恢复。”黄伟说。
真如有人评论，真是人才！，不知道‘所谓的秒级恢复’是什么神奇的技术？写过一篇博客，关于灾备的，本意是推荐到博客首页的，结果被没成功，但是，感觉，很多人对灾备真的很是陌生，（我们的小编也很陌生，偶猜）~~~，感觉有点空谈误国
http://blog.chinaunix.net/uid-22334392-id-3781493.html

数据库的大版本升级应该是非常谨慎的事情，本应该在前期进行大量的测试，而且对于工行这样的系统绝不要做小白鼠，应该充分等到DB2 10 On Z有充分的关键生产案例和在测试系统上进行过充分的回归测试后才考虑升级。
其后，就是其具体错误的原因，对于Z可能特殊一点，不清楚这个内存清楚的BUG是怎么导致整个多节点的DB2 with sysplex宕机的，难道是工行的自己操作的问题要IBM来背黑锅？这类事情在别的IT系统中我知道是发生过的，根本不是硬件或者软件问题，操作失误但是对外宣称是硬件或者软件故障。
如果是ORACLE，原则上MAA架构建议在同一个机房除生产用RAC外，增加一个同网段的DG standby，如果主RAC故障，考虑用同机房的DG STANDBY来接管，而不是马上考虑切换到远程的DR站点。相同机房的DB切换，显然比远程的DR切换成本低的多。而且这种情况还是非常严重的DB损坏不能打开的情况，如果只是某些内存清除啥机制的问题，也许单独重启RAC集群有问题的instance即可。
感觉楼上应该是做运维的，相对的分析还是比较入理，但是架构谈的应该是oracle，关于DB2的架构，可以参考博客
http://blog.chinaunix.net/uid-22334392-id-3719453.html  浅析DB2 中的DBMS CLUSTER技术

吐槽了这么多，感觉最应该吐槽的本topic的标题，
你认为这次事故后,灾备系统无法迅速恢复系统的原因是什么?
这里不是太明白？6.23事故暴露出来的问题同灾备系统的关系，不知道小编如得出如此的结论？事故发生，个人感觉事故发生后首要的问题是应急，但是应急不应该等价于灾备吧？对于任何一个运维人员来说，灾备一般不到万不得已时不会启用的，不论你是oracle 的rac,,mysql master-slave,db2 dSG，等等，AA,AQ,AS不是万能的，总有延迟，总有数据丢失，总要给技术人员决策的时间，感觉这里的标题的引出同6.23暴漏的问题有点出入，仅是一家之言，不要对号入座
说了这么多，现在谈谈 我们的话题，
1,你认为这次事故后,灾备系统无法迅速恢复系统的原因是什么? 第一个上面已经解释
2,你认为目前银行的IT系统建设目前存在哪些问题？
感觉现在的问题是集中式，集中带来的问题就是牵一发而动全身，导致了IDC本身对RAS的高要求，而且个人感觉是不可避免的

3,你认为灾备系统的有效性如何得以实现？
至于灾备的有效性，所谓的备份总有延迟，总有数据丢失，参考博客http://blog.chinaunix.net/uid-22334392-id-3781493.html
最小化ＲＴＯ，ＲＰＯ吧，但是至于具体的实现就要问供应商了

mcshell

回复 10# yaozhibing41001


    拜膜高手{:3_186:}   

yaozhibing41001

回复 44# mcshell


   
哈哈，马仔，人才啊。

koolji

既是管理问题，又是技术问题，归根结底是管理问题。

zgxtiger

不知道工行的备份机制，我也是管理数据库，也试过数据库搞坏了，如果有硬盘备份，加上归档日志就比较好处理，不行就从磁带拷出，我觉得人是关键，有时候越简单就越安全