【話題討論】從6·23工行事件 談企業(yè)IT系統(tǒng)災(zāi)備問題（獲獎名單已公布-2013-7-25）

sofa110

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

鐵道部12306網(wǎng)站癱瘓，給全國百姓回家買票添堵，可以把責(zé)任推給CDN外包服務(wù)商，而四大銀行只能自己做檢討�！肮ば械臑�(zāi)備系統(tǒng)是自己做的，如果災(zāi)備做得到位，完全可以在系統(tǒng)發(fā)生問題時秒級恢復(fù)�！秉S偉說。

亮點啊

wolfop

回復(fù) 40# arron劉
數(shù)據(jù)庫的大版本升級應(yīng)該是非常謹(jǐn)慎的事情，本應(yīng)該在前期進行大量的測試，而且對于工行這樣的系統(tǒng)絕不要做小白鼠，應(yīng)該充分等到DB2 10 On Z有充分的關(guān)鍵生產(chǎn)案例和在測試系統(tǒng)上進行過充分的回歸測試后才考慮升級。
其后，就是其具體錯誤的原因，對于Z可能特殊一點，不清楚這個內(nèi)存清楚的BUG是怎么導(dǎo)致整個多節(jié)點的DB2 with sysplex宕機的，難道是工行的自己操作的問題要IBM來背黑鍋？這類事情在別的IT系統(tǒng)中我知道是發(fā)生過的，根本不是硬件或者軟件問題，操作失誤但是對外宣稱是硬件或者軟件故障。
如果是ORACLE，原則上MAA架構(gòu)建議在同一個機房除生產(chǎn)用RAC外，增加一個同網(wǎng)段的DG standby，如果主RAC故障，考慮用同機房的DG STANDBY來接管，而不是馬上考慮切換到遠(yuǎn)程的DR站點。相同機房的DB切換，顯然比遠(yuǎn)程的DR切換成本低的多。而且這種情況還是非常嚴(yán)重的DB損壞不能打開的情況，如果只是某些內(nèi)存清除啥機制的問題，也許單獨重啟RAC集群有問題的instance即可。

   

kinfinger

回復(fù) 1# arron劉
看到這個topic，十分驚訝，認(rèn)真的讀過大家的評論，感受頗深，現(xiàn)總結(jié)如下：
1 點評：
       再一次被活動獎勵深深的折服了。到底神馬情況下會用到這樣的本子呢？？最新一期的核心期刊《走進科學(xué)》雜志發(fā)表署名三蛋文章《再論筆記本之現(xiàn)代必要性》，科研人員經(jīng)過長達數(shù)千項分析，一致謹(jǐn)慎認(rèn)為此種筆記本很適合大熱天扇扇子，但是要注意將封皮取下并打開使用。對于lz的這種選題娛樂目的大于科研目的的標(biāo)題行為，本吊表示很無語。而三蛋表示很開心，因為這樣的論題距離他的論題又開始天淵之別了？？？？
本topic的獎品深深地折服~~~~~~~~~

鐵道部12306網(wǎng)站癱瘓，給全國百姓回家買票添堵，可以把責(zé)任推給CDN外包服務(wù)商，而四大銀行只能自己做檢討�！肮ば械臑�(zāi)備系統(tǒng)是自己做的，如果災(zāi)備做得到位，完全可以在系統(tǒng)發(fā)生問題時秒級恢復(fù)�！秉S偉說。
真如有人評論，真是人才！，不知道‘所謂的秒級恢復(fù)’是什么神奇的技術(shù)？寫過一篇博客，關(guān)于災(zāi)備的，本意是推薦到博客首頁的，結(jié)果被沒成功，但是，感覺，很多人對災(zāi)備真的很是陌生，（我們的小編也很陌生，偶猜）~~~，感覺有點空談?wù)`國
http://blog.chinaunix.net/uid-22334392-id-3781493.html

數(shù)據(jù)庫的大版本升級應(yīng)該是非常謹(jǐn)慎的事情，本應(yīng)該在前期進行大量的測試，而且對于工行這樣的系統(tǒng)絕不要做小白鼠，應(yīng)該充分等到DB2 10 On Z有充分的關(guān)鍵生產(chǎn)案例和在測試系統(tǒng)上進行過充分的回歸測試后才考慮升級。
其后，就是其具體錯誤的原因，對于Z可能特殊一點，不清楚這個內(nèi)存清楚的BUG是怎么導(dǎo)致整個多節(jié)點的DB2 with sysplex宕機的，難道是工行的自己操作的問題要IBM來背黑鍋？這類事情在別的IT系統(tǒng)中我知道是發(fā)生過的，根本不是硬件或者軟件問題，操作失誤但是對外宣稱是硬件或者軟件故障。
如果是ORACLE，原則上MAA架構(gòu)建議在同一個機房除生產(chǎn)用RAC外，增加一個同網(wǎng)段的DG standby，如果主RAC故障，考慮用同機房的DG STANDBY來接管，而不是馬上考慮切換到遠(yuǎn)程的DR站點。相同機房的DB切換，顯然比遠(yuǎn)程的DR切換成本低的多。而且這種情況還是非常嚴(yán)重的DB損壞不能打開的情況，如果只是某些內(nèi)存清除啥機制的問題，也許單獨重啟RAC集群有問題的instance即可。
感覺樓上應(yīng)該是做運維的，相對的分析還是比較入理，但是架構(gòu)談的應(yīng)該是oracle，關(guān)于DB2的架構(gòu)，可以參考博客
http://blog.chinaunix.net/uid-22334392-id-3719453.html  淺析DB2 中的DBMS CLUSTER技術(shù)

吐槽了這么多，感覺最應(yīng)該吐槽的本topic的標(biāo)題，
你認(rèn)為這次事故后,災(zāi)備系統(tǒng)無法迅速恢復(fù)系統(tǒng)的原因是什么?
這里不是太明白？6.23事故暴露出來的問題同災(zāi)備系統(tǒng)的關(guān)系，不知道小編如得出如此的結(jié)論？事故發(fā)生，個人感覺事故發(fā)生后首要的問題是應(yīng)急，但是應(yīng)急不應(yīng)該等價于災(zāi)備吧？對于任何一個運維人員來說，災(zāi)備一般不到萬不得已時不會啟用的，不論你是oracle 的rac,,mysql master-slave,db2 dSG，等等，AA,AQ,AS不是萬能的，總有延遲，總有數(shù)據(jù)丟失，總要給技術(shù)人員決策的時間，感覺這里的標(biāo)題的引出同6.23暴漏的問題有點出入，僅是一家之言，不要對號入座
說了這么多，現(xiàn)在談?wù)?我們的話題，
1,你認(rèn)為這次事故后,災(zāi)備系統(tǒng)無法迅速恢復(fù)系統(tǒng)的原因是什么? 第一個上面已經(jīng)解釋
2,你認(rèn)為目前銀行的IT系統(tǒng)建設(shè)目前存在哪些問題？
感覺現(xiàn)在的問題是集中式，集中帶來的問題就是牽一發(fā)而動全身，導(dǎo)致了IDC本身對RAS的高要求，而且個人感覺是不可避免的

3,你認(rèn)為災(zāi)備系統(tǒng)的有效性如何得以實現(xiàn)？
至于災(zāi)備的有效性，所謂的備份總有延遲，總有數(shù)據(jù)丟失，參考博客http://blog.chinaunix.net/uid-22334392-id-3781493.html
最小化ＲＴＯ，ＲＰＯ吧，但是至于具體的實現(xiàn)就要問供應(yīng)商了

mcshell

回復(fù) 10# yaozhibing41001


    拜膜高手{:3_186:}   

yaozhibing41001

回復(fù) 44# mcshell


   
哈哈，馬仔，人才啊。

koolji

既是管理問題，又是技術(shù)問題，歸根結(jié)底是管理問題。

zgxtiger

不知道工行的備份機制，我也是管理數(shù)據(jù)庫，也試過數(shù)據(jù)庫搞壞了，如果有硬盤備份，加上歸檔日志就比較好處理，不行就從磁帶拷出，我覺得人是關(guān)鍵，有時候越簡單就越安全