2000多個Bug！這個系統(tǒng)讓銀行癱瘓、13億人賬戶出錯、最終損失超過28億

魚羊 郭一璞 2019-12-25 13:34:26 來源：量子位

魚羊 郭一璞 發(fā)自 凹非寺
量子位 報道 | 公眾號 QbitAI

2000多個bug，這樣一個千瘡百孔的系統(tǒng)，被用在了一家有13億用戶的銀行里。

這是去年TSB銀行系統(tǒng)遷移大事故的報告結果，出自Slaughter and May律所。

Bug連篇、測試沒做好、IT服務商無能，這一切的一切，導致了災難級后果。

當系統(tǒng)啟用的時候，用戶們紛紛發(fā)現(xiàn)自己的錢不見了、花一兩塊扣掉幾千、賬戶被別人登錄……

銀行為了啟用這個系統(tǒng)，投入了2500人年的成本；而事后為了補鍋，也花費了高達28億的資金。

系統(tǒng)遷移捅了13億用戶的婁子

故事，是從一樁“離婚再嫁”的案子開始的。

離婚再嫁的主角，是英國銀行TSB。

2015年，TSB銀行結束了與勞埃德銀行（Lloyds Bank）長達20年的“婚姻”，從他們合并的集團中拆分出來，并賣身給了新歡、西班牙公司薩瓦德爾（Sabadell）集團，收購價17億英鎊，按當時的匯率大概是158億人民幣。

然而，過去的20年，世界變了太多，銀行業(yè)也進步了太多。20年的“婚姻”留給TSB銀行的，還有和“前夫”剪不斷理還亂的IT系統(tǒng)。

TSB銀行540萬客戶的數十億記錄，都還留在“前夫”勞埃德銀行的系統(tǒng)里，而且因為緣分已斷，不能白嫖人家的系統(tǒng)，每年還要給前夫交1億英鎊（大約9.3億人民幣）的費用。

這就好像肉身雖然已經和“新歡”在一起，但支付寶和微信賬號還是跟“前夫”共用一套，而且還要給“前夫”付賬號租金，自然令人不爽。

于是，在籌備了許久之后，2018年，他們終于要行動了：把“前夫”IT系統(tǒng)里的客戶信息記錄，遷移到“新歡”專門為TSB銀行準備的新系統(tǒng)里。

他們把遷移的日子，定在了4月22日星期日的晚上，先把銀行的IT系統(tǒng)離線，遷移完之后再上線，恢復客戶訪問自己銀行賬戶的權限。

為了這場遷移，他們已經投入了超過2500人年的人力成本，西班牙“新歡”集團的CEO在前一年的圣誕節(jié)就大聲放話：這是全歐洲史無前例的大項目，我們投入了1000多名專業(yè)人才，將極大地促進我們在英國的增長。

不過，雖然大佬們在臺上豪言壯語，實際上負責遷移的員工們心里卻慌得一逼。這個遷移項目本來要籌備18個月，結果時間超了，預算也超了，事情難辦的很。

Flag果然不能立太早，打臉的結果很快就來了。

遷移結束，客戶的訪問權限，他們以為萬無一失，但就在20分鐘后，收到了問題報告：

有的客戶發(fā)現(xiàn)自己的錢不見了；

有的客戶花了一點小錢，賬戶里卻記錄成了花費數千美元；

有的客戶登錄上去之后，發(fā)現(xiàn)不是自己的賬戶，而是看到了別人的銀行賬戶。

13億客戶的賬戶記錄都出了問題，于是，他們把TSB銀行罵成狗，金融監(jiān)管機構們則連夜找銀行喝茶。

而此后的幾個星期，銀行都在拼命的恢復系統(tǒng)，但數以百萬計的客戶們已經人心惶惶，拼命的把自己存在TSB銀行的錢取出來。

TSB銀行，被自己捅的簍子扔進了地獄模式。

而問題的根源，在于測試。

英國金融監(jiān)管機構金融行為監(jiān)管局（FCA）首席執(zhí)行官Andrew Bailey在事故幾周后對外公開表示，造成系統(tǒng)混亂的很大原因在于缺少測試，而TSB銀行請來救急的IBM專家也發(fā)現(xiàn)，TSB銀行沒有采用嚴格的上線標準。

而且由于地球上的金融體系都是相連的，事故所造成的錯誤被永久的保留在了金融體系里，不可逆轉。

這起彌天大禍，也讓TSB銀行賠了很多錢。為了賠償客戶、解決系統(tǒng)出問題后渾水摸魚的交易、找第三方幫忙總共花了3.302億英鎊，按當時匯率算大約28.4億人民幣。

而TSB的乙方、IT提供商Sabis也因為這起事故收到了1.53億英鎊（超過13億人民幣）的賠償賬單。

而受此影響，TSB銀行當年虧損了1.054億英鎊（9.2億人民幣），CEO Paul Pester引咎辭職。

業(yè)績這么差，銀行的經營也難以為繼，今年11月底TSB關閉了英國86個分行，至少400個工作崗位也因此消失。

銀行系統(tǒng)很復雜

信息化時代，銀行的IT系統(tǒng)也變得越來越復雜。

六十年前，人們只能選擇在柜臺存取現(xiàn)金，普通客戶并沒有機會直接接觸計算機系統(tǒng)。當時，銀行雖然也啟用了巨型計算機，但它們只會在一天或一周交易結束的時候對紙質數據進行匯總。

也就是說，銀行的IT系統(tǒng)僅由銀行員工使用，銀行與客戶在柜臺上的交互用的還是紙質工具。

這種情況在1967年發(fā)生了改變。

這一年，世界上第一臺自動柜員機（ATM）在英國誕生，并被安裝到倫敦北部的巴克萊銀行Enfield分行。從此，銀行和客戶交互的方式發(fā)生重大變革。

ITRS Group首席執(zhí)行官蓋伊·沃倫（Guy Warren）解釋說：

直到真正的ATM和在線銀行業(yè)務出現(xiàn)，公眾才可以直接訪問銀行的IT系統(tǒng)。

這還僅僅是個開始。

全球互聯(lián)的時代，互聯(lián)網和移動銀行的發(fā)展進一步拉近了客戶和銀行IT系統(tǒng)之間的距離，而這樣的系統(tǒng)，也越來越成為銀行賴以運營的關鍵所在。

或許你會覺得，登個支付寶/微信，亮出付款碼，讓小錢錢在銀行跟銀行之間發(fā)生小小的流動，并沒有什么難度。但事實上，每一次信息的加載和刷新背后，都發(fā)生了復雜的數據移動——

每一次動作可能關聯(lián)到許多個單獨的系統(tǒng)，所有這些系統(tǒng)都必須彼此交互，并與核心大型計算機連通。系統(tǒng)要現(xiàn)在后端復制數據，將現(xiàn)金從一個賬戶轉移到另一個賬戶，保持同步更新。

而這樣的運算量，還要乘以數十億倍。

根據世界銀行的數據，現(xiàn)在，全球至少有69%的成年人都擁有銀行賬戶。人們每一天都在通過銀行賬戶支付賬單、貸款還款、訂閱各種服務……并且，這些活動常常是跨行，甚至跨國進行的。

一家銀行內部的多個IT系統(tǒng)（移動銀行、ATM等），不僅需要彼此交互，甚至還必須跟其他國家的銀行建立聯(lián)系。比如我在國內辦了一張visa信用卡，在美國也要能消費才行。

遷移問題很麻煩

TSB正是栽在了這樣的高度復雜性上。

IBM在為TSB編寫的報告中指出：新應用程序的組合，對先進微服務的應用和雙活數據中心的使用，導致了TSB生產中的復合風險。

如何正確地處理銀行IT系統(tǒng)遷移中出現(xiàn)的問題，對于任何一個銀行來說，都是不小的挑戰(zhàn)。

其中，大量的事前規(guī)劃和測試工作是不可避免的。

像匯豐銀行這樣的跨國銀行，具有高度復雜、相互關聯(lián)的系統(tǒng)，這些系統(tǒng)會定期進行測試、遷移和更新。

即使在這方面如此經驗豐富，匯豐銀行的前IT主管蘭開斯特仍坦承：訣竅就是讓員工在這件事上付出更多的時間。

他還指出，TSB的IT系統(tǒng)遷移是一件很復雜的事：

我不確定他們是不是真的意識到了這件事的復雜程度。他們甚至沒有完全想好要怎么去測試系統(tǒng)。

FCA首席執(zhí)行官Andrew Bailey則表示：

TSB的這一事故反映出他們缺少強大的回歸測試。

注：回歸測試是軟件測試的一種，旨在檢驗軟件原有功能在修改后是否保持完整

而最新的事故報告也引起了hacker news上網友們的熱烈討論。

有網友表示，如果TSB能選擇小規(guī)模多次遷移，而不是在某一天進行大爆炸式遷移，那這種嚴重的事故可能就不會發(fā)生。

花幾周/幾個月的時間在生產過程中進行檢查，以確保舊數據庫和新數據庫返回的結構相同。最終，將數據都轉移到新數據庫中，并在一段時間之后再關閉舊的數據庫。這樣做效果是比較好的。

而對測試不足導致了銀行系統(tǒng)癱瘓的這一調查結論，有人吐槽說：

作為測試工程師，我一點也不意外。花費更多的時間、投入更多的人員來打造更好的測試架構，對于很多公司來說都是“可以節(jié)省的成本”。

經理們總是在設定的上線日期前問：“測試咋能花那么多時間？！”真要出事了他們又開始甩鍋了。

也有網友嚴厲批評道：TSB的問題不應該說是測試不足，而是在多個層面上都測試不足，并且缺少可恢復的備份。

也有人指出，避免出錯最簡單的辦法就是減少變化。

問題在于，無論是銀行還是其他領域的公司，業(yè)務都是在不斷進化的。

根據FCA發(fā)布的數據，從2017年到2018年，英國金融服務部門報告的技術中斷增加了187%。

蓋伊·沃倫就認為：系統(tǒng)停機不會消失。問題在于，可接受的度在哪里？

你怎么看呢？

參考鏈接：

https://news.ycombinator.com/item?id=21870089
https://www.tsb.co.uk/news-releases/slaughter-and-may/
https://www.tsb.co.uk/news-releases/slaughter-and-may/slaughter-and-may-report.pdf
https://increment.com/testing/what-broke-the-bank/
https://www.ft.com/content/d1f37ab2-0eb8-11ea-a225-db2f231cfeae

—?完?—