早前，英國 TSB 銀行籌劃了良久的遷移方案失敗，13 億客戶記錄出錯，事后各類賠償總計花費約 29 億元人民幣。時隔一年，這家銀行終于想明白原因是缺乏嚴格的測試。

[[311840]] 

圖片來自 Pexels

2018 年，英國的 TSB 銀行陷入了困境。雖然這家金融機構與勞埃德銀行集團(Lloyds Banking Group，兩者最初于 1995 年合并)拆分已有兩年時間。

但 TSB 仍然與前伙伴勞埃德銀行集團有著關密不可分的關系，因為她的 IT 系統是非常匆忙地從勞埃德銀行集團復制而來的。

更糟糕的是，TSB 每年還要支付 1 億英鎊的許可費給對方(撰寫本文時按匯率計算相當于 1.27 億美元，約 8.9 億人民幣)。

沒人會愿意為“前任”付費。

為了改變這種局面，2018 年 4 月 22 日晚上 6 點鐘，TSB 啟動了一個已經蓄謀數月的計劃，要把他們 540 萬用戶的數十億條數據遷移到西班牙公司 Banco Sabadell 的 IT 系統上來，后者在 2015 年 3 月以 17 億歐元(22 億美元)的價格收購了 TSB。

01.前所未有的遷移，前所未有的糟糕

Banco Sabadell 的主席 Josep Oliu 于 2017 年圣誕前兩周的一次超過 1800 人的公司集會上宣布了這項計劃。

這次大規模集會是在巴塞羅那商業街上的一個又大又現代的會議大廳中舉行的。這次遷移工作的重中之重是 Banco Sabadell 公司在 2000 年開發的 Proteo 系統的新版本，并為這次 TSB 遷移項目而專門命名為 Proteo4UK。

Banco Sabadell 的首席執行官 Jaime Guardiola Romojaro 曾對巴塞羅那的公眾宣稱，Proteo4UK 項目投入的人力超過 2500 人年。

“在歐洲，像 Proteo4UK 這么大型的整合項目絕對是史無前例的，我們投入的技術專家已經超過了 1000 人”，他繼續說，“這個項目會為我們在英國的業務帶來極大助力”。

4 月 22 日，一個平常的星期天晚上，TSB 的遷移項目 Proteo4UK 接近完工了。

幾乎整個周末 TSB 舊的 IT 系統都處于停服狀態，客戶數據不斷地從舊系統向新系統遷移。

到了周日晚上，新系統慢慢啟用了，并對外開放入口，平滑地恢復了對外服務。

雖然在圣誕之前的公司會議上，Oliu 和 Guardiola Romojaro 都對這個項目表現得信心滿滿，可是 TSB 參與具體遷移工作的工程師們卻非常緊張。

這個項目原計劃是要進行 18 個月的，但它已經延期了，而且超出了預算。畢竟，把一個公司的全部數據從一個系統遷移到另一個系統，這絕非易事。

他們所擔心的事情真的發生了。

在確認數據遷移很順利，TSB 重新對外開放了對賬戶的訪問之后，不到 20 分鐘，第一個故障投訴電話就打了進來。

人們發現自己一生的積蓄忽然不翼而飛了。有些非常小額的交易卻被誤記成了幾千元的支出。

有些客戶登錄之后卻發現，他們查看的并不是自己的銀行賬號，里面的信息壓根就屬于不相干的人。

晚上 9 點，TSB 的領導層向英國的金融監管機構英國金融行為監管局(Financial Conduct Authority，FCA)匯報，自己這邊出了問題。

而事實上在 TSB 自己匯報之前，FCA 就已經注意到了這個事件，因為好事不出門，壞事傳千里，尤其是在這個有互聯網有 Twitter 的時代，出了問題時人們首先想到的就是去 Twitter 上吐槽。

到了晚上 11：30，FCA 終于和另一個金融監管機構 PRA(Prudential Regulation Authority)碰了頭，并在零點之后成功地與 TSB 的管理者們開起了電話會議。

這時候已經是 4 月 23 日，星期一的凌晨了。他們只想問一個問題：到底發生了什么?

盡管當時的局面很混亂，但現在我們對事件已經有了一個比較清晰的結論：13 億的用戶數據在遷移中被損壞了。

事后銀行的 IT 系統用了幾個星期才恢復服務，在此期間有幾百萬人的日常存取錢行為受到了影響。

而直到這個事件發生一年多之后，專家們才自認為找到了問題的根本原因：缺乏嚴格的測試。

[[311841]] 

02.遷移并不是想象中的那么簡單

隨著用戶的需求和期望不斷增加，銀行的 IT 系統也變得越來越復雜。

60 年前，我們需要自己在營業時間去到銀行的某個分行或營業部，在營業員的幫助下在柜臺上把錢存入銀行，或者把錢從銀行取出來。

我們銀行賬戶里的數字變動與我們拿在手上的真實的錢是完全對應的。銀行工作人員會用筆和紙記下我們賬戶的變動，普通顧客是接觸不到任何計算機系統的。

然后當一天或一周結束時，銀行工作人員再把傳統的記錄在卡片或紙帶上的數據輸入巨型計算機，做最終匯總。

到了 1967 年，世界上第一臺自動提款機(Automated Teller Machine，ATM)在倫敦北部的一家銀行門前正式投入使用。

它徹底地改變了銀行為顧客提供服務的方式，也改變了銀行的方方面面。方便成了銀行服務的基本標準，這個標準也讓用戶與屏幕后面運行的銀行系統之間的距離大大地拉近了。

“在很久以前，IT 系統只是給銀行內部工作人員使用的，只需要在柜臺上做些紙質工作，銀行就完全可以正常運轉”，ITRS 集團的首席執行官 Guy Warren 說。

ITRS 集團是全世界 190 多家銀行的技術供應商。“后來 ATM 出現了，再后來又有了網上銀行系統，普通顧客才真的直接與銀行的 IT 系統打交道了。”

ATM 還只是個開始。很快人們就可以通過電話進行轉賬，再也不必去現場排隊了。

這個功能需要把特制的卡片插入可以解密雙音多頻(Dual-Tone Multi-Frequency，DTMF)信號的硬件中，這樣當客戶按下“1”時，它就可以把這個命令翻譯成“取錢”，而把“2”翻譯成“存錢”。

網上銀行和手機銀行把客戶與銀行核心系統之間的距離拉得更近了。盡管不同的功能會由不同的子系統來實現，但所有子系統之間都要進行交互，并且向最核心的系統發出請求，比如更新余額、記錄轉賬等等。

據 BLMS 咨詢公司的 Brian Lancaste 所說，典型的零售銀行核心系統都會運行在一臺大型機上。

他曾經在 IBM 工作過 13 年，而在 HSBC 負責管理 IT 技術部門的時間則更長。他現在為銀行提供咨詢服務，并在全英國范圍內推動社區(對客戶服務的社區銀行)的構建。

他說，“那可能是你能夠運行核心系統的最可靠的平臺了，也是最具備可擴展性的”。

把核心的用戶數據庫放在大型機上，再加上運行在許多服務器之上的其他不同的 IT 基礎設施，就可以構建對大型機進行訪問的應用接口，從而提供互聯網接入了。

當用戶在網上登錄進自己的銀行賬號，看到了自己的最新信息時，很少有人會想到發生在后臺的數據處理過程有多么復雜。登錄信息會在多臺服務器之間傳遞。

當你做一筆交易時，系統會從后端的基礎設施拷貝一份數據過來，然后就是復雜的部分了：把錢從一個賬戶搬到另一個賬戶，完成交水電費、還款等實際業務，然后再繼續處理其他請求。

再設想一下，如果上面描述的過程每秒鐘同時發生幾十億次，又會是怎樣呢?

世界銀行組織在比爾和梅琳達·蓋茨基金會(The Bill & Melinda Gates Foundation)的幫助下，推算出現在全世界有 69% 的成年人都有銀行賬戶。

這些成年人每個人都要還賬單，有些還要還貸款，而有 Netflix 或優酷土豆賬號的人就更多了。另外他們的銀行賬號也不屬于同一家銀行。

[[311842]] 

手機銀行、ATM 等數不清的銀行內部 IT 系統不僅要在彼此之間進行交互，它們還要與不同地域的不同銀行進行交互，比如玻利維亞、危地馬拉甚至巴西等。

如果你把一張美國發行的信用卡插進了一臺中國的 ATM 機，它仍然要能夠取出錢來。錢一直是全球化的，但與錢相關的操作從來沒有這么復雜過。

“使用銀行 IT 系統的方式不斷在增加”，ITRS 集團高管 Warren 說。而且舊的系統幾乎永遠都不會下線，新的系統還會不斷涌現出來。

“如果你考慮的問題是用各種各樣的平臺來滿足各種不同的用戶群體，以及它們能夠提供多少在線服務的時間，那么很明顯，你會有大問題”，Warren 說。

事實上，衡量一個好的 IT 系統的標準是“你的系統有多大能力做自我修復，在出現嚴重故障甚至停服時，它能夠處理得怎么樣”。

“雙活數據中心”這個詞講的是至少要有兩個數據中心來一起提供服務，保證在任何時刻都可以正常處理業務，它通過冗余來提高了可靠性。

[[311843]] 

03.問題復盤

TSB 的 IT 系統就不擅長自我修復，銀行的技術團隊在處理嚴重故障時也很痛苦。但導致 TSB 的 IT 系統故障的根本原因在于它的復雜性。

根據事故早期 IBM 為 TSB 出具的一份報告，“新應用與微服務的高級用法相結合，再加上使用了雙活數據中心，導致了生產環境的多重風險”。

對于像 HSBC 一樣的全球性銀行，IT 系統都是高度復雜并且內部互聯的，因此會有規律地進行測試、遷移和升級等活動。

“對于像 HSBC 這樣的公司，這些事情是時時刻刻在發生的”，前 HSBC 的 IT 技術負責人 Lancaster 說。

他覺得 HSBC 可以做為其他銀行如何運營 IT 系統的典范：要有專職的員工，付出專門的時間。

“就算你標記好所有的 I，劃上所有的 T，最后總會發現 IT 系統還是需要相當大量的計劃和測試工作”，Lancaster 說。

對于小型銀行，尤其是那些沒有豐富的數據遷移經驗的小型銀行來說，要把這事做好就更有挑戰性了。

“TSB 的遷移工作就很復雜”，Lancaster 說，“我不確定他們是不是真的明白這事有多復雜，我印象很深的是他們并沒有制訂出非常明確的測試計劃”。

故障發生幾個星期之后，FCA 的首席執行官 Andrew Bailey 在回應英國議會就這個問題的問詢時確認了這一點。

有問題的代碼當然是 TSB 問題的根源，但全球金融網絡相互關聯的各個系統讓它的錯誤層出不窮并且無法逆轉。

各種意想不到的錯誤不斷地從這個 IT 架構各個地方冒出來。用戶不斷地收到各種冒名其妙的消息，而且壓根與自己的問題無關。

“對我來說，這表明他們缺乏健壯的回歸測試，因為銀行系統是與支付系統、短信系統等許多外部系統相關聯的”，Bailey 告訴議員們，“當你提交了修復代碼，又引發了各種意想不到的問題時，那我們就又回到了測試的問題上”。

回歸測試可能可以有助于避免這樣的災難，它可以幫你在把有問題的代碼部署到生產環境之前，在有問題的代碼與外部依賴相互作用造成不可逆轉的錯誤、造成嚴重破壞之前，就把問題定位出來。

其他人也表示了同意。被邀請來幫忙定位問題的 IBM 專家一點也沒有掩飾對 TSB 的批評之意。

他們說本應該看到“國際標準級的嚴格設計、測試方法、全面的運營論證、預上線試運行和就緒的運維支撐等”。

而實際上他們看到的完全不一樣：“IBM 并沒有看到有任何證據表明這些系統經過了哪些可以達到上線標準的嚴格測試，以證明它們可以投入生產了”。

TSB 已經踏入了雷區，而看起來她還毫不知情。

“他們所使用的技術是有相當大復雜度的，而且這些復雜度又有著不同的表現形式”，Ryan Rubin 說。

他是一個 IT 專家，之前曾在 EY 工作，現在是 Cyberian Defence 的管理總監，這是一家專門幫助大型公司管理網絡風險的咨詢公司。“這可能會導致宕機和各種復雜事件，正如我們所看到的那樣”。

Warren 說，英國的銀行一般的行業標準是要達到“四個九”的可用性，即在 99.99% 的時間里他們的服務要對用戶可用。

在現實中，這意味著和網上銀行一樣，銀行的 IT 系統在一天中的每個小時都要正常對外提供服務，在一年中也最多只能有 52 分鐘的離線時間。

“三個九”，即 99.9% 的可能性，聽起來與四個九好像沒有太大區別，但那就意味著一年超過 8 小時的停服時間。

“對于一家英國銀行來說，四個九的標準是可以的，三個九的標準不可接受”，Warren 說，他回想起來他提供咨詢服務的第一個軟件項目就要求達到六個九的標準——那是一家核電站的控制系統。

每當一家公司對她的 IT 基礎設施做出變更時，就會有引入故障的風險。減少變化當然有助于避免問題，但對于必要的改變來說，就要經過嚴格的測試，這正是 IBM 所強調的在 TSB 的故障中所缺乏的。

Shujun Li 在肯特大學教授網絡安全課程，也為包括一家大型銀行和許多保險公司在內的大型公司提供咨詢服務。

他說，每次升級和打補丁操作最后都會歸結到風險管理的問題，對那些客戶投資幾億的大型項目來說尤其如此。

“要有流程來保證風險都得到了有效的控制”，他說，“另外你還要心里有數，萬一出了問題的話，可能會付出多少金錢和名譽上的代價”。

詳細的計劃可以降低 TSB 所經歷的這種重大事故的風險。“故障還是會發生的，但進行快速恢復和保持冗余所要付出的代價卻會減少”，Rubin 說。

隨著網絡供應商和云解決方案的發展，存儲費用已經大大降低了。“所有東西都是現成的，當災難發生時，它們可以幫助銀行管理風險，并將故障影響控制到最小”。

不過，對于一些機構來說，為應對災難的發生而要實施備份計劃的成本可能太高。Warren 認為，一些銀行在如何實現 IT 彈性方面做得過于保守。

他解釋說：“你不能靠預算來做這件事。這是一項金融服務：要么有，要么沒有。他們本來就應該再多投入一些錢。”

吝嗇的 IT 投入最終讓人付出了慘痛的代價。

TSB 聲稱他們在 2018 年因為事故造成的損失是 1.05 億歐元(1.34 億美元)，與之形成對比的是 2017 年他們的利潤是 1.63 億歐元(2.06 億美元)。

遷移事故后續的總支出達到了 3.3 億歐元(4.19 億美元)，包括補償用戶、更正虛假交易(在事故發生后的混亂情況下，虛假交易的數量急劇上升)、以及為臨時聘請技術專家而要支出的費用等。

對應在這次事故中所要承擔的責任，TSB 的 IT 服務供應商 Sabis 也收到了一張 1.53 億歐元(1.94 億美元)的賬單。

要降低風險，也許最簡單的辦法就是盡量不要做改動。

但是正如 Lancaster 所說，“每間銀行，每個發展中的社區，每家公司都無時無刻不被業務驅動著，要構建出越來越多的好東西來服務客戶，支撐業務”。

他觀察到，“為了變得更有競爭力，你就會有動力引入更多的新系統和新功能”。同時，對于各家公司，尤其是金融服務類的公司來說，他們對客戶承擔著責任，要保證他們的財產安全，并且在使用現有服務時要保持良好的體驗。

“當你承受著巨大的業務壓力要引入新東西時，兩難之處在于你該投入多少成本來讓所有系統保持正常運行”。

根據 FCA 公布的數據，從 2017 年到 2018 年，英國金融服務業上報的技術故障發生次數增長了 187%。

究其原因，最常見的故障根本原因都在于變更管理做得很失敗。尤其對于銀行系統來說，需要保持時刻在線，而且需要近乎實時的交易報告。

客戶可能擔心他們的錢會不會不翼而飛，如果感受不到自己的錢的存在，他們肯定會抓狂。

在 TSB 的事故發生幾個月之后，英國金融監管機構和英格蘭銀行一起發布了一份關于運營彈性的討論文件。

“文件的目的是提醒各家金融公司：你會不會把天平向引入新功能的一側傾斜了太多，從而忽略了現有系統的平穩運行?”Lancaster 解釋到。

文件也對監管規則提出了修改建議：

公司里相關員工也應該為公司的 IT 系統所出的故障負責。“如果你對此負有責任，你可能會因此而破產，甚至可能被送進監獄。這會讓許多東西都隨之發生改變，包括大家對事情的重視程度，”Warren 說。“你會非常慎重地對待它，因為它事關你的家庭財產和你的人身自由。”

Rubin 說：

“從 TSB 的事件之后，大家做事情時肯定會更加認真地審查。高級管理者再也不會忽視 IT 系統的建設，也不會對技術資產投入不足了。由于有著處罰和合規性要求，現在的形勢已經發生了很大變化。”

不管大家從 TSB 身上學到了什么經驗和教訓，嚴重的停服事件肯定還是會發生的，這無可避免。

“我不認為故障會消失”，Warren 說，相反，人們必須接受：“你能接受多大程度的可用性?換句話說，就是多少停服時間?”

作者：Chris Stokel-Walker，足下編譯

簡介：本文翻譯自“ What broke the bank ”翻譯已取得原網站授權。