Categories
程式開發

為節省8億做系統遷移,13億記錄出錯,最終賠了29億


本文翻譯自“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工作,現在是Cyber​​ian 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說,相反,人們必須接受:“你能接受多大程度的可用性?換句話說,就是多少停服時間?”

原文鏈接
https://increment.com/testing/what-broke-the-bank/