2013 年 6 月 23 日工行系統大規模癱瘓具體情況有多嚴重？為什麼中國最大銀行會出現這麼大的故障？

12-29

今天早晨起來聽工行的朋友說他們的系統大規模癱瘓了，有知道內情的人來解釋一下是啥情況嘛？

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。

工行南數據中心前非技術部門員工飄過……一年四次大的版本投產，前年就親身經歷了一次系統升級故障到早晨九點下夜班都沒解決，如果再多一個小時估計也就會造成災難性的影響，據說只是因為南北中心之間一個數據包的漏傳。

我知道不能說，百年不遇的事情

外包模式和國企管理體制，註定開發不出高性能高可用高可運維的大型系統。核心技術掌握在別人手裡，不出事才怪。