은행은 어떻게 실패했는가?

IT 인프라 마이그레이션 실패로 인해 1,3억 개의 은행 고객 기록이 손상되었습니다. 이는 모두 테스트가 충분하지 않았고 복잡한 IT 시스템에 대한 경솔한 태도 때문이었습니다. Cloud4Y가 어떻게 그런 일이 일어났는지 알려드립니다.

2018년 영어 TSB 은행 그는 Lloyds 은행 그룹(두 회사 모두 1995년에 합병됨)과의 127년 간의 "이혼"이 너무 비싸다는 것을 깨달았습니다. TSB는 급하게 복제된 Lloyds IT 시스템을 통해 여전히 이전 파트너와 연결되어 있었습니다. 무엇보다도 은행이 연간 XNUMX억 XNUMX만 달러의 라이센스 비용인 "위자료"를 지불해야 했습니다.

전 애인에게 돈을 지불하는 것을 좋아하는 사람은 거의 없으므로 22년 2018월 18일 00:18에 TSB는 모든 것을 바꿀 예정인 2,2개월 계획의 마지막 단계를 시작했습니다. 수십억 개의 고객 기록을 2015년에 TSB를 XNUMX억 달러에 인수한 스페인 회사 Banco Sabadell의 IT 시스템으로 이전할 계획이었습니다.

Banco Sabadell의 CEO인 José Olu는 2년 크리스마스 2017주 전에 바르셀로나의 유명한 컨퍼런스 홀에서 열린 축제 직원 회의에서 다가오는 행사에 대해 말했습니다. 가장 중요한 마이그레이션 도구는 Banco Sabadell이 개발한 시스템의 새로운 버전인 Proteo였습니다. TSB 마이그레이션 프로젝트를 위해 특별히 Proteo4UK로 이름이 변경되었습니다.

Proteo4UK 프레젠테이션에서 Banco Sabadell 전무 이사 Jaime Guardiola Romojaro는 새로운 시스템이 1000명 이상의 전문가가 작업한 유럽에서 유례가 없는 대규모 프로젝트라고 자랑했습니다. 그리고 그 구현은 영국에서 Banco Sabadell의 성장을 크게 촉진할 것입니다.

22년 2018월 XNUMX일이 이주일로 지정되었습니다. 봄 중반의 조용한 일요일 저녁이었습니다. 기록이 한 시스템에서 다른 시스템으로 전송되는 동안 은행의 IT 시스템이 다운되었습니다. 일요일 늦게 은행 계좌에 대한 공개 액세스가 복원됨에 따라 은행이 천천히 원활하게 서비스를 재개할 것으로 예상됩니다.

그러나 올류(Olyu)와 과르디올라 로모자로(Guardiola Romojaro)가 무대에서 Proteo4UK 프로젝트 구현에 대해 즐겁게 방송하는 동안 마이그레이션 프로세스를 담당하는 직원들은 매우 긴장했습니다. 완료하는 데 18개월이 걸린 이 프로젝트는 일정보다 심각하게 뒤처졌고 예산도 초과되었습니다. 추가 테스트를 수행할 시간이 없었습니다. 그러나 회사의 모든 데이터(수십억 개의 기록)를 다른 시스템으로 전송하는 것은 엄청난 작업입니다.

엔지니어들이 긴장한 데에는 그럴 만한 이유가 있는 것으로 밝혀졌습니다.

고객이 너무 오랫동안 본 사이트의 스텁

TSB가 계정에 대한 액세스를 개시한 지 20분 후, 마이그레이션이 원활하게 진행되었다는 확신을 갖고 첫 번째 문제 보고서가 도착했습니다.

사람들의 저축이 갑자기 계좌에서 사라졌습니다. 미미한 금액의 구매가 수천 달러의 비용으로 잘못 기록되었습니다. 어떤 사람들은 개인 계좌에 로그인하여 은행 계좌가 아닌 완전히 다른 사람들의 계좌를 보았습니다.

21:00에 TSB 대표는 현지 금융 규제 기관(영국 금융 행위 당국, FCA)에 은행에 문제가 있음을 알렸습니다. 그러나 FCA는 이미 이를 알아차렸습니다. TSB는 정말 큰 실수를 저질렀고 고객은 바보가 되었습니다. 그리고 당연히 그들은 불평하기 시작했습니다. 소셜 네트워크 (그리고 요즘에는 트위터나 페이스북에 몇 줄을 올리는 것이 특별히 어렵지 않습니다.) 오후 23시 30분, FCA는 또 다른 금융 규제 기관인 건전성 규제 당국(PRA)으로부터 연락을 받았는데, 이 기관 역시 뭔가 잘못되었음을 감지했습니다.

자정이 훨씬 지나서야 그들은 은행 담당자 중 한 명에게 연락할 수 있었습니다. 그리고 그들에게 유일한 질문을 해보세요: “도대체 무슨 일이 일어나고 있는 거죠?”

참사 규모를 이해하는 데는 시간이 걸렸지만, 마이그레이션 과정에서 1,3만 고객의 5,4억 건의 기록이 손상되었다는 사실을 이제 알게 되었습니다. 적어도 일주일 동안 고객은 컴퓨터나 모바일 장치에서 돈을 관리할 수 없었습니다. 그들은 대출금을 지불할 수 없었고, 많은 은행 고객들이 연체료는 물론 신용 기록에 흠집을 받았습니다.

TSB 고객 온라인 은행의 모습은 다음과 같습니다.

거의 즉시 결함이 나타나기 시작하자 은행 담당자는 문제가 "간헐적"이라고 주장했습니다. 26일 후 모든 시스템이 정상이라는 성명이 발표됐다. 하지만 고객들은 계속해서 문제를 보고했습니다. 2018년 XNUMX월 XNUMX일이 되어서야 은행의 CEO인 폴 페스터(Paul Pester)는 은행의 IT 인프라에 약 백만 명의 고객이 온라인 뱅킹 서비스에 액세스하는 것을 방해하는 "대역폭 문제"가 계속 발생함에 따라 TSB가 "무릎을 꿇었다"고 인정했습니다.

마이그레이션이 시작된 지 XNUMX주가 지났지만 온라인 뱅킹 애플리케이션에서 여전히 SQL 데이터베이스와 관련된 내부 오류가 발생하는 것으로 보고되었습니다.
특히 비즈니스 및 모기지 청구서와 관련된 지불 문제가 최대 3주 동안 지속되었습니다. 그리고 유비쿼터스 언론인들은 이민 위기가 시작될 때 TSB가 Lloyds Banking Group의 도움 제안을 거부했다는 사실을 발견했습니다. 일반적으로 온라인 서비스 로그인 및 송금 기능과 관련된 문제는 XNUMX월 XNUMX일까지 관찰되었습니다.

역사의 비트

최초의 ATM은 27년 1967월 XNUMX일 Enfield의 Barclays 근처에 문을 열었습니다.

은행 IT 시스템은 고객의 요구와 은행의 기대가 증가함에 따라 점점 더 복잡해지고 있습니다. 약 40~60년 전만 해도 우리는 영업 시간 중에 현지 은행 지점을 방문하여 현금을 입금하거나 창구를 통해 출금하는 것을 즐겼을 것입니다.

계좌에 있는 금액은 우리가 은행에 준 현금과 동전과 직접적인 관련이 있었습니다. 우리 집 회계는 펜과 종이로 추적할 수 있었고 컴퓨터 시스템은 고객이 접근할 수 없었습니다. 은행 직원은 통장 및 기타 미디어의 데이터를 돈을 계산하는 장치에 배치했습니다.

하지만 1967년 북런던에서 처음으로 설치되었습니다 은행 구내에 없는 ATM. 그리고 이 사건은 은행 업무를 변화시켰습니다. 사용자 편의성은 금융기관 발전의 기준이 되었습니다. 그리고 이는 은행이 고객 및 고객의 자금과 협력하는 측면에서 더욱 정교해지는 데 도움이 되었습니다. 결국, 컴퓨터 시스템은 은행 직원들만 사용할 수 있었지만 그들은 고객과 상호 작용하는 오래된 "종이" 방식에 만족했습니다. 일반 대중이 은행 IT 시스템에 직접 접근할 수 있게 된 것은 ATM과 온라인 뱅킹의 출현 이후였습니다.

ATM은 시작에 불과했습니다. 곧 사람들은 단순히 은행에 전화를 걸어 금전 등록기의 줄을 피할 수 있게 되었습니다. 이를 위해서는 사용자가 "1"(현금 인출) 또는 "2"(예금 자금) 키를 눌렀을 때 전송되는 DTMF(Dual-Tone Multi-Frequency) 신호를 해독할 수 있는 판독기에 삽입된 특수 카드가 필요했습니다.

인터넷과 모바일 뱅킹을 통해 고객은 은행의 핵심 시스템에 더 가까이 다가갈 수 있게 되었습니다. 다양한 제한 사항과 설정에도 불구하고 이러한 모든 시스템은 서로 효과적으로 상호 작용하고 메인 프레임과 계정 잔액 확인, 자금 이체 등을 수행해야 합니다.

예를 들어, 온라인 은행에 로그인하여 계좌에 있는 돈에 대한 정보를 보거나 업데이트할 때 정보 경로가 얼마나 복잡한지 생각하는 고객은 거의 없습니다. 로그인하면 이 데이터는 일련의 서버를 통해 전달됩니다. 거래를 할 때 시스템은 이 데이터를 백엔드 인프라에 복제한 다음 청구서를 지불하기 위해 한 계좌에서 다른 계좌로 돈을 이체하는 등 무거운 작업을 수행합니다. 결제하고 구독을 계속하세요.

이제 이 프로세스에 수십억을 곱하십시오. 빌 앤 멜린다 게이츠 재단의 도움으로 세계은행이 수집한 데이터에 따르면, 69 비율 전 세계의 성인들은 은행 계좌를 가지고 있습니다. 이 사람들 각자는 지불해야 할 청구서를 가지고 있습니다. 누군가는 모기지를 지불하거나 어린이 클럽에 돈을 이체하고, 누군가는 Netflix 구독료를 지불하거나 클라우드 서버를 임대합니다. 그리고 이 사람들은 모두 하나 이상의 은행을 이용합니다.

한 은행의 수많은 내부 IT 시스템(모바일뱅킹, ATM 등)이 단순히 상호작용을 해서는 안 됩니다. 그들은 브라질, 중국, 독일의 다른 은행 시스템과 상호 작용해야 합니다. 프랑스 ATM은 볼리비아 어딘가에서 발행된 은행 카드에 있는 돈을 인출할 수 있어야 합니다.

돈은 항상 글로벌했지만 시스템이 이렇게 복잡한 적은 이전에 없었습니다. 은행 IT 시스템을 활용하는 방법이 늘어나고 있지만 여전히 기존 방식이 사용되고 있습니다. 은행의 성공은 주로 IT 인프라가 얼마나 "유지 관리 가능"하고 시스템이 유휴 상태가 되는 갑작스러운 장애에 은행이 얼마나 효과적으로 대처할 수 있는지에 달려 있습니다.

테스트 없음 - 문제에 대비

Banco de Sabadell CEO Jaime Guardiola(왼쪽)는 모든 일이 순조롭게 진행될 것이라고 확신했습니다. 운동하지 않았습니다.

TSB의 컴퓨터 시스템은 문제를 신속하게 해결하는 데 그다지 능숙하지 않았습니다. 물론 소프트웨어 결함도 있었지만 실제로는 IT 시스템의 과도한 복잡성으로 인해 은행이 '파산'했습니다. 대규모 정전 초기에 작성된 보고서에 따르면 "새로운 애플리케이션의 결합, 마이크로서비스 사용 증가, 두 개의 액티브/액티브 데이터 센터 사용이 결합되어 생산에 복잡한 위험이 발생했습니다."

HSBC와 같은 일부 은행은 전 세계적으로 운영되므로 매우 복잡하고 상호 연결된 시스템을 갖추고 있습니다. 그러나 Lancaster의 한 HSBC IT 관리자에 따르면 정기적으로 테스트, 마이그레이션 및 업데이트됩니다. 그는 HSBC를 다른 은행이 직원을 헌신하고 시간을 투자하여 IT 시스템을 관리하는 방법에 대한 모델로 보고 있습니다. 그러나 동시에 그는 소규모 은행, 특히 마이그레이션 경험이 없는 은행의 경우 이를 올바르게 수행하는 것이 매우 어려운 작업임을 인정합니다.

TSB 마이그레이션은 어려웠습니다. 그리고 전문가에 따르면 은행 직원은 자격 측면에서 이러한 수준의 복잡성에 도달할 수 없었습니다. 게다가 솔루션을 미리 확인하거나 마이그레이션을 테스트할 필요도 없었습니다.

금융 문제에 관한 영국 의회 연설에서 FCA의 CEO인 Andrew Bailey는 이러한 의혹을 확인했습니다. 잘못된 코드는 아마도 TSB의 초기 문제만을 야기했을 것입니다. 그러나 글로벌 금융 네트워크의 상호 연결된 시스템은 그 실수가 영속적이고 되돌릴 수 없음을 의미했습니다. 은행은 IT 아키텍처의 다른 부분에서 예상치 못한 오류를 계속해서 발견했습니다. 고객은 의미가 없거나 문제와 관련이 없는 메시지를 받았습니다.

회귀 테스트는 잘못된 코드가 프로덕션 환경에 출시되기 전에 포착하고 롤백할 수 없는 버그를 생성하여 피해를 입혀 재난을 예방하는 데 도움이 될 수 있습니다. 하지만 은행은 자신도 모르는 지뢰밭을 헤쳐나가기로 결정했습니다. 결과는 예측 가능했습니다. 또 다른 문제는 비용의 "최적화"였습니다. 그것은 어떻게 나타 났습니까? 사실 Lloyds에 저장된 백업 복사본은 너무 많은 돈을 "먹어"버렸기 때문에 이전에 이를 없애기로 결정되었습니다.

영국 은행(및 기타 은행)은 99,99%의 가용성 수준을 달성하기 위해 노력하고 있습니다. 실제로 이는 IT 시스템이 연간 최대 52분의 가동 중지 시간을 포함하여 항상 사용 가능해야 함을 의미합니다. 99,9%의 "8%" 시스템은 언뜻 보기에는 크게 다르지 않습니다. 그러나 실제로 이는 가동 중지 시간이 연간 XNUMX시간에 달한다는 것을 의미합니다. 은행의 경우 "XNUMX"는 좋지만 "XNUMX"는 그렇지 않습니다.

그러나 회사가 IT 인프라를 변경할 때마다 위험이 따릅니다. 결국 뭔가 잘못될 수 있습니다. 변경 사항을 줄이면 문제를 방지하는 데 도움이 될 수 있지만 필요한 변경 사항은 신중한 테스트가 필요합니다. 그리고 영국 규제 당국은 이 점에 관심을 집중해 왔습니다.

가동 중지 시간을 방지하는 가장 쉬운 방법은 아마도 변경 사항을 줄이는 것입니다. 그러나 모든 은행은 다른 회사와 마찬가지로 경쟁력을 유지하기 위해 고객과 자체 비즈니스에 점점 더 유용한 기능을 도입해야 합니다. 동시에 은행은 여전히 ​​고객을 돌보고 저축과 개인 데이터를 보호하며 서비스 이용을 위한 편안한 조건을 제공할 의무가 있습니다. 조직은 IT 인프라의 상태를 유지하는 동시에 새로운 서비스를 제공하는 데 많은 시간과 비용을 소비해야 하는 것으로 나타났습니다.

영국 금융행위감독청(Financial Conduct Authority)이 발표한 데이터에 따르면 영국 금융 서비스 부문에서 보고된 기술 실패 건수는 187년에서 2017년 사이에 2018% 증가했습니다. 대부분의 경우 실패의 원인은 새로운 기능의 작동 문제입니다. 동시에 은행이 모든 서비스를 지속적으로 중단 없이 운영하고 거의 즉각적인 거래 보고를 보장하는 것이 중요합니다. 고객은 돈이 어딘가에 있을 때 항상 긴장합니다. 그리고 돈에 대해 불안한 고객은 항상 문제의 징조입니다.

TSB의 실패(은행 CEO가 사임한 시점) 몇 달 후, 영국 금융 규제 기관과 영국 은행은 문서를 공개했다 운영 지속 가능성 문제에 대한 논의를 위해. 그래서 그들은 은행들이 혁신을 얼마나 깊이 추구했는지, 그리고 그들이 현재 가지고 있는 시스템의 안정적인 운영을 보장할 수 있는지에 대한 의문을 제기하려고 했습니다.

이 문서에서는 법안 변경도 제안했습니다. 이는 회사의 IT 시스템에 문제가 있는 경우 회사 내 사람들에게 책임을 묻는 것이었습니다. 영국 국회의원들은 이에 대해 이렇게 설명했습니다. “개인적으로 책임을 지고 파산하거나 감옥에 갈 수 있다면 신뢰성과 안전 문제에 전념하는 시간이 늘어나는 등 업무에 대한 태도가 크게 바뀔 것입니다.”

결과

모든 업데이트와 패치는 위험 관리와 관련이 있으며, 특히 수억 달러가 관련된 경우에는 더욱 그렇습니다. 결국, 문제가 발생하면 돈과 평판 측면에서 큰 비용이 들 수 있습니다. 그것은 명백한 것처럼 보일 것입니다. 그리고 이주 중 은행의 실패는 그들에게 많은 것을 가르쳐 주었을 것입니다.

가졌다. 하지만 그는 나에게 가르쳐주지 않았습니다. 2019년 XNUMX월, 다시 수익성을 달성하며 서서히 평판을 개선하고 있는 TSB는 고객을 “기뻐”했습니다. 새로운 실패 정보 기술 분야에서. 은행에 대한 두 번째 타격은 비용 절감을 위해 82년에 2020개 지점을 폐쇄해야 한다는 것을 의미했습니다. 아니면 IT 전문가를 구할 수도 없었습니다.

IT에 대한 인색함은 궁극적으로 비용을 초래합니다. TSB는 134년 2018억 206만 달러의 이익에 비해 2017년에는 419억 194만 달러의 손실을 보고했습니다. 고객 보상, 사기 거래 정정(은행 혼란 중에 급격히 증가), 제XNUMX자 지원을 포함한 마이그레이션 후 비용은 총 XNUMX억 XNUMX만 달러에 달했습니다. 은행의 IT 제공업체도 위기 상황에서의 역할에 대해 XNUMX억 XNUMX만 ​​달러를 청구 받았습니다.

그러나 TSB 은행 실패에서 어떤 교훈을 얻었더라도 혼란은 계속 발생할 것입니다. 그것은 불가피합니다. 그러나 테스트와 좋은 코드를 사용하면 충돌과 가동 중지 시간을 크게 줄일 수 있습니다. 대기업이 클라우드 인프라로 마이그레이션하는 데 종종 도움을 주는 Cloud4Y는 한 시스템에서 다른 시스템으로 빠르게 이동하는 것의 중요성을 이해합니다. 따라서 우리는 로드 테스트를 수행하고 다중 레벨 백업 시스템과 마이그레이션을 시작하기 전에 가능한 모든 것을 확인할 수 있는 기타 옵션을 사용할 수 있습니다.

블로그에서 무엇을 더 읽을 수 있습니까? 클라우드4Y

→ 짠 태양 에너지
→ 사이버 보안의 최전선에 있는 침투 테스터
→ 위대한 눈송이 이론
→ 풍선에 인터넷
→ 데이터 센터에 베개가 필요합니까?

우리의 구독 텔레그램-다음 기사를 놓치지 않도록 채널을 구독하세요! 우리는 일주일에 두 번 이상 사업에 대해서만 글을 씁니다.

출처 : habr.com