本文翻譯自“ What broke the bank ”，原作者爲 Chris Stokel-Walker，翻譯已取得原網站授權 。

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

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。

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

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 分鐘，第一個故障投訴電話就打了進來。人們發現自己一生的積蓄忽然不冀而飛了。有些非常小額的交易卻被誤記成了幾千元的支出。有些客戶登錄之後卻發現，他們查看的並不是自己的銀行賬號，裏面的信息壓根就屬於不相干的人。

晚上九點，TSB 的領導層向英國的金融監管機構英國金融行爲監管局（Financial Conduct Authority，FCA）彙報，自己這邊出了問題。而事實上在 TSB 自己彙報之前，FCA 就已經注意到了這個事件，因爲好事不出門，壞事傳千里，尤其是在這個有互聯網有 Twitter 的時代，出了問題時人們首先想到的就是去 Twitter 上吐槽。到了晚上 11：30，FCA 終於和另一個金融監管機構 PRA（Prudential Regulation Authority）碰了頭，並在零點之後成功地與 TSB 的管理者們開起了電話會議。這時候已經是 4 月 23 日，星期一的凌晨了。他們只想問一個問題：到底發生了什麼？

儘管當時的局面很混亂，但現在我們對事件已經有了一個比較清晰的結論：13 億的用戶數據在遷移中被損壞了。事後銀行的 IT 系統用了幾個星期才恢復服務，在此期間有幾百萬人的日常存取錢行爲受到了影響。 而直到這個事件發生一年多之後，專家們才自認爲找到了問題的根本原因：缺乏嚴格的測試 。

遷移並不是想象中的那麼簡單

隨着用戶的需求和期望不斷增加，銀行的 IT 系統也變得越來越複雜。60 年前，我們需要自己在營業時間去到銀行的某個分行或營業部，在營業員的幫助下在櫃檯上把錢存入銀行，或者把錢從銀行取出來。我們銀行賬戶裏的數字變動與我們拿在手上的真實的錢是完全對應的。銀行工作人員會用筆和紙記下我們賬戶的變動，普通顧客是接觸不到任何計算機系統的。然後當一天或一週結束時，銀行工作人員再把傳統的記錄在卡片或紙帶上的數據輸入巨型計算機，做最終彙總。

到了 1967 年，世界上第一臺自動提款機（automated teller machine，ATM） 在倫敦北部的一家銀行門前正式投入使用 。它徹底地改變了銀行爲顧客提供服務的方式，也改變了銀行的方方面面。方便成了銀行服務的基本標準，這個標準也讓用戶與屏幕後面運行的銀行系統之間的距離大大地拉近了。

“在很久以前，IT 系統只是給銀行內部工作人員使用的，只需要在櫃檯上做些紙質工作，銀行就完全可以正常運轉”，ITRS 集團的首席執行官 Guy Warren 說。ITRS 集團是全世界 190 多家銀行的技術供應商。“後來 ATM 出現了，再後來又有了網上銀行系統，普通顧客才真的直接與銀行的 IT 系統打交道了。”

ATM 還只是個開始。很快人們就可以通過電話進行轉賬，再也不必去現場排隊了。這個功能需要把特製的卡片插入可以解密雙音多頻（dual-tone multifrequency，DTMF）信號的硬件中，這樣當客戶按下“1”時，它就可以把這個命令翻譯成“取錢”，而把“2”翻譯成“存錢”。

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

據 BLMS 諮詢公司的 Brian Lancaste 所說，典型的零售銀行核心系統都會運行在一臺大型機上。他曾經在 IBM 工作過 13 年，而在 HSBC 負責管理 IT 技術部門的時間則更長。他現在爲銀行提供諮詢服務，並在全英國範圍內推動社區（對客戶服務的社區銀行）的構建。他說，“那可能是你能夠運行核心系統的最可靠的平臺了，也是最具備可擴展性的”。把核心的用戶數據庫放在大型機上，再加上運行在許多服務器之上的其它不同的 IT 基礎設施，就可以構建對大型機進行訪問的應用接口，從而提供互聯網接入了。

當用戶在網上登錄進自己的銀行賬號，看到了自己的最新信息時，很少有人會想到發生在後臺的數據處理過程有多麼複雜。登錄信息會在多臺服務器之間傳遞。當你做一筆交易時，系統會從後端的基礎設施拷貝一份數據過來，然後就是複雜的部份了：把錢從一個賬戶搬到另一個賬戶，完成交水電費、還款等實際業務，然後再繼續處理其它請求。

再設想一下，如果上面描述的過程每秒鐘同時發生幾十億次，又會是怎樣呢？世界銀行組織在比爾和梅琳達·蓋茨基金會（The Bill & Melinda Gates Foundation）的幫助下，推算出現在全世界有 69% 的成年人 都有銀行賬戶。這些成年人每個人都要還賬單，有些還要還貸款，而有 Netflix 或優酷土豆賬號的人就更多了。另外他們的銀行賬號也不屬於同一家銀行。

手機銀行、ATM 等數不清的銀行內部 IT 系統不僅要在彼此之間進行交互，它們還要與不同地域的不同銀行進行交互，比如玻利維亞、危地馬拉甚至巴西等。如果你把一張美國發行的信用卡插進了一臺中國的 ATM 機，它仍然要能夠取出錢來。錢一直是全球化的，但與錢相關的操作從來沒有這麼複雜過。

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

“如果你考慮的問題是用各種各樣的平臺來滿足各種不同的用戶羣體，以及它們能夠提供多少在線服務的時間，那麼很明顯，你會有大問題”，Warren 說。事實上，衡量一個好的 IT 系統的標準是“你的系統有多大能力做自我修復，在出現嚴重故障甚至停服時，它能夠處理得怎麼樣”。

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

問題覆盤

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 說，相反，人們必須接受：“你能接受多大程度的可用性？換句話說，就是多少停服時間？”

相關文章