一次失敗的 IT 基礎設施遷移導致 1,3 億筆銀行客戶記錄遭到破壞。 這都是由於測試不足以及對複雜IT系統的輕率態度所造成的。 Cloud4Y 講述了事情是如何發生的。
2018年英語
很少有人願意給前任付錢,因此,22 年 2018 月 18 日 00:18,TSB 開始了為期 2,2 個月的計劃的最後階段,該計劃本應改變一切。 計劃將數十億筆客戶記錄轉移到西班牙薩瓦德爾銀行 (Banco Sabadell) 的 IT 系統,該公司於 2015 年以 XNUMX 億美元收購了 TSB。
2 年聖誕節前兩週,Banco Sabadell 執行長 José Olu 在巴塞隆納著名會議廳舉行的節日員工會議上談到了即將舉行的活動。 最重要的遷移工具是 Banco Sabadell 開發的系統的新版本:Proteo。 它甚至被重新命名為 Proteo2017UK,專門用於 TSB 遷移專案。
在 Proteo4UK 的演示會上,Banco Sabadell 執行董事 Jaime Guardiola Romojaro 誇口說,新系統是一個大型項目,在歐洲沒有類似項目,有超過 1000 名專家參與其中。 它的實施將大大促進薩瓦德爾銀行在英國的發展。
22年2018月XNUMX日定為遷移日。 那是仲春時節一個安靜的星期日晚上。 由於記錄從一個系統轉移到另一個系統,該銀行的 IT 系統出現故障。 隨著週日晚間公眾對銀行帳戶的訪問恢復,人們預計銀行將緩慢而順利地恢復服務。
不過,當 Olyu 和 Guardiola Romojaro 在台上愉快地廣播 Proteo4UK 計畫的實施情況時,負責遷移過程的員工卻非常緊張。 該項目歷時 18 個月才完成,嚴重落後於計劃並超出預算。 沒有時間進行額外的測試。 但是,將公司的所有資料(請記住,有數十億筆記錄)傳輸到另一個系統是一項艱鉅的任務。
事實證明,工程師的緊張是有充分理由的。
客戶在網站上看到時間過長的存根
TSB 完全相信遷移順利進行,在開放帳戶存取權限 20 分鐘後,第一個問題報告就到了。
人們的存款突然從帳戶上消失了。 少量的採購被錯誤地記錄為數千美元的支出。 有些人登入他們的個人帳戶,看到的不是他們的銀行帳戶,而是完全不同的人的帳戶。
21:00,TSB代表通知當地金融監理機構(英國金融行為監理局,FCA),該銀行遇到了麻煩。 但FCA已經注意到了:TSB確實搞砸了,客戶被愚弄了。 當然,他們開始抱怨
午夜過後,他們設法聯繫了一位銀行代表。 並問他們唯一的問題:“到底發生了什麼事?”
我們需要一段時間才能了解這場悲劇的規模,但我們現在知道 1,3 萬客戶的 5,4 億筆記錄在遷移過程中遭到損壞。 至少一周以來,客戶無法透過電腦或行動裝置管理資金。 他們無法償還貸款,許多銀行客戶的信用記錄受到損害,並被收取滯納金。
這就是 TSB 客戶網路銀行的樣子
當故障開始出現時,幾乎立即,銀行代表堅稱這些問題是「間歇性的」。 三天后,發布聲明稱所有系統均正常。 但客戶繼續報告問題。 直到 26 年 2018 月 XNUMX 日,該銀行首席執行官 Paul Pester 才承認,TSB 已“陷入困境”,因為該銀行的 IT 基礎設施仍然存在“頻寬問題”,導致約 XNUMX 萬客戶無法訪問網上銀行服務。
遷移兩週後,網路銀行應用程式仍報告遇到與 SQL 資料庫相關的內部錯誤。
付款困難,尤其是商業和抵押貸款帳單,持續了長達四週。 隨處可見的記者發現,在移民危機一開始,加拿大運輸安全委員會就拒絕了勞埃德銀行集團提出的協助提案。 總體而言,直到 3 月 XNUMX 日為止,仍觀察到與登入線上服務和轉帳能力相關的問題。
歷史上的位
第一台 ATM 於 27 年 1967 月 XNUMX 日在恩菲爾德巴克萊銀行附近開業
隨著客戶需求和銀行期望的增加,銀行 IT 系統變得越來越複雜。 大約 40-60 年前,我們很樂意在營業時間前往當地銀行分行透過櫃員存入或提取現金。
帳戶裡的錢多少和我們給銀行的現金和硬幣直接相關。 我們的家庭會計可以用筆和紙進行跟踪,而客戶無法訪問電腦系統。 銀行員工將存摺和其他介質中的資料放入點算設備中。
但1967年第一次在倫敦北部
ATM 機只是一個開始。 很快,人們只需打電話給銀行就可以避免在收銀台前排隊。 這需要將特殊卡插入讀卡機中,該讀卡機能夠解密當使用者按下「1」(提款)或「2」(存款)鍵時發送的雙音多頻(DTMF)訊號。
網路和手機銀行讓客戶更接近銀行的核心系統。 儘管存在不同的限制和設置,所有這些系統都必須有效地相互交互以及與主機交互,執行帳戶餘額檢查、轉帳等。
例如,當您登入線上銀行查看或更新有關帳戶中資金的資訊時,很少有客戶會想到資訊路徑有多麼複雜。 當您登入時,這些數據會透過一組伺服器傳遞;當您進行交易時,系統會在後端基礎設施中複製這些數據,然後由後端基礎設施完成繁重的工作——將錢從一個帳戶轉移到另一個帳戶以支付帳單、付款並繼續訂閱。
現在將這個過程乘以數十億。 根據世界銀行在比爾及梅琳達蓋茲基金會的協助下編製的數據,
一家銀行的眾多內部IT系統(手機銀行、ATM等)不能簡單地互相互動。 他們需要與巴西、中國和德國的其他銀行系統互動。 法國 ATM 機應該能夠提取玻利維亞某地發行的銀行卡上的錢。
貨幣一直是全球性的,但係統從未如此複雜。 使用銀行IT系統的方式越來越多,但仍然使用舊的方式。 銀行的成功很大程度上取決於其IT基礎設施的“可維護性”,以及銀行如何有效地應對突然出現的故障,從而導致系統閒置。
沒有測試 - 為問題做好準備
Banco de Sabadell 執行長 Jaime Guardiola(左)對一切都會順利進行充滿信心。 沒有成功。
TSB 的電腦系統不太擅長快速解決問題。 當然,存在軟體故障,但實際上銀行「破產」是由於其 IT 系統過於複雜。 根據這份在大規模停機初期準備的報告,“新應用程式的組合、微服務的使用增加以及兩個主動/主動數據中心的使用導致了生產中的複雜風險。”
匯豐銀行等一些銀行在全球範圍內運營,因此也擁有非常複雜的互連系統。 但蘭開斯特的匯豐銀行 IT 經理表示,它們會定期進行測試、遷移和更新。 他將匯豐銀行視為其他銀行管理 IT 系統的典範:投入員工並投入時間。 但他同時也承認,對於規模較小的銀行,尤其是沒有遷移經驗的銀行來說,要正確地做到這一點是一項非常困難的任務。
TSB 遷移很困難。 而且,據專家稱,銀行工作人員的資格根本無法達到如此複雜的水平。 此外,他們甚至懶得提前檢查他們的解決方案或測試遷移。
英國金融市場行為監理局(FCA)執行長安德魯貝利(Andrew Bailey)在英國議會就銀行業問題發表演講時證實了這項懷疑。 糟糕的程式碼可能只導致了 TSB 最初的問題,但全球金融網路的互連系統意味著它的錯誤將永久存在且不可逆轉。 該銀行繼續在其 IT 架構的其他地方發現意外錯誤。 客戶收到的訊息毫無意義或與他們的問題無關。
回歸測試可以在將錯誤代碼發佈到生產環境之前捕獲它,並通過創建無法回滾的錯誤而造成損害,從而幫助防止災難。 但銀行決定穿越一個它甚至不知道的雷區。 後果是可以預見的。 另一個問題是成本的「最佳化」。 它是如何表現出來的? 事實上,之前曾決定取消勞埃德銀行儲存的備份副本,因為它們「吃掉」了太多錢。
英國銀行(以及其他銀行)正在努力實現四個九的可用性水平,即 99,99%。 實際上,這意味著 IT 系統必須始終可用,每年最多有 52 分鐘的停機時間。 「三個九」系統,99,9%,乍看之下並沒有太大差別。 但實際上這意味著每年的停機時間達到 8 小時。 對銀行來說,「四個九」是好的,但「三個九」則不好。
但每次公司對其 IT 基礎設施進行更改時,都會面臨風險。 畢竟,有些事情可能會出錯。 減少變更有助於避免問題,而所需的變更則需要仔細測試。 而英國監管機構也將注意力集中在了這一點上。
也許避免停機的最簡單方法就是減少變更。 但與其他公司一樣,每家銀行都被迫為客戶和自身業務引入越來越多有用的功能,以保持競爭力。 同時,銀行仍有義務照顧客戶,保護他們的儲蓄和個人數據,為使用服務提供舒適的條件。 事實證明,組織被迫花費大量時間和金錢來維護 IT 基礎設施的健康,同時提供新服務。
英國金融行為監理局發布的數據顯示,187 年至 2017 年間,英國金融服務業報告的技術故障數量增加了 2018%。 大多數情況下,失敗的原因是新功能運作中的問題。 同時,對於銀行來說,確保所有服務持續不間斷運作以及幾乎即時的交易報告至關重要。 當客戶的錢閒置在某個地方時,他們總是會感到緊張。 一個對錢感到緊張的客戶總是有麻煩的徵兆。
TSB 倒閉(當時該銀行執行長已辭職)幾個月後,英國金融監管機構和英格蘭銀行
該文件還提議修改立法。 這是為了讓公司內部的人員對公司 IT 系統出現的問題負責。 英國議員這樣解釋:“當你個人負責時,你可能會破產或入獄,這將極大地改變人們對工作的態度,包括增加投入到可靠性和安全問題上的時間。”
結果
每次更新和修補程式都歸結為風險管理,尤其是涉及數億美元時。 畢竟,如果出現問題,可能會付出高昂的金錢和聲望代價。 這似乎是顯而易見的事。 銀行在移民過程中的失敗應該會讓他們學到很多。
有。 但他沒有教我。 2019年XNUMX月,再次實現盈利並慢慢提升聲譽的TSB讓客戶“高興”
對 IT 的吝嗇最終是要付出代價的。 TSB 報告 134 年虧損 2018 億美元,而 206 年獲利 2017 億美元。 遷移後成本,包括客戶賠償、糾正詐欺交易(在銀行業混亂期間急劇增加)以及第三方援助,總計 419 億美元。 該銀行的 IT 供應商也因其在危機中所扮演的角色而被罰款 194 億美元。
然而,無論從 TSB 銀行倒閉中吸取什麼教訓,混亂仍然會發生。 它們是不可避免的。 但透過測試和良好的程式碼,可以大大減少崩潰和停機時間。 Cloud4Y 經常幫助大公司遷移到雲端基礎設施,它了解快速從一個系統遷移到另一個系統的重要性。 因此,我們可以進行負載測試並使用多層備份系統,以及其他選項,讓您在開始遷移之前檢查一切可能的情況。
您還可以在博客上閱讀什麼?
→
→
→
→
→
訂閱我們的
來源: www.habr.com