Unha migración fallida da infraestrutura de TI provocou a corrupción de 1,3 millóns de rexistros de clientes bancarios. Todo isto debeuse a probas insuficientes e a unha actitude frívola cara a sistemas informáticos complexos. Cloud4Y conta como pasou.
En 2018 inglés decatouse de que o seu "divorcio" de dous anos co grupo bancario Lloyds (ambas empresas fusionadas en 1995) era demasiado caro. TSB aínda estaba ligado ao seu antigo socio a través dos sistemas informáticos de Lloyds clonados ás présas. O peor de todo é que o banco tivo que pagar unha "pensión alimenticia", unha taxa de licenza anual de 127 millóns de dólares.
A pouca xente gústalle pagar cartos aos seus ex, polo que o 22 de abril de 2018 ás 18:00 TSB comezou a etapa final dun plan de 18 meses que debía cambiar todo. Estaba previsto transferir miles de millóns de rexistros de clientes ao sistema informático da empresa española Banco Sabadell, que comprou TSB por 2,2 millóns de dólares en 2015.
O conselleiro delegado de Banco Sabadell, José Olu, falou do próximo evento dúas semanas antes do Nadal de 2 durante unha reunión festiva do persoal nun prestixioso salón de actos de Barcelona. A ferramenta de migración máis importante ía ser unha nova versión do sistema desenvolvido polo Banco Sabadell: Proteo. Mesmo foi renomeado como Proteo2017UK específicamente para o proxecto de migración de TSB.
Na presentación de Proteo4UK, o director executivo de Banco Sabadell, Jaime Guardiola Romojaro, presumía de que o novo sistema é un proxecto de gran envergadura que non ten análogos en Europa, no que traballaron máis de 1000 especialistas. E que a súa implantación suporá un importante impulso ao crecemento de Banco Sabadell no Reino Unido.
O 22 de abril de 2018 foi o día da migración. Era unha tranquila noite de domingo a mediados da primavera. Os sistemas informáticos do banco caeron a medida que se transfirían os rexistros dun sistema a outro. Co acceso público ás contas bancarias restablecida a última hora do domingo, cabería esperar que o banco volva ao servizo lentamente e sen problemas.
Pero mentres Olyu e Guardiola Romojaro emitían felices desde o escenario sobre a implementación do proxecto Proteo4UK, os empregados responsables do proceso de migración estaban moi nerviosos. O proxecto, que tardou 18 meses en completarse, foi moi atrasado e superou o orzamento. Non houbo tempo para realizar probas adicionais. Pero transferir todos os datos da empresa (que, lembra, son miles de millóns de rexistros) a outro sistema é unha tarefa herculina.
Resultou que os enxeñeiros estaban nerviosos por unha boa razón.
Un esbozo do sitio que os clientes viron durante demasiado tempo
20 minutos despois de que TSB abrise o acceso ás contas, confiando plenamente en que a migración foi sen problemas, chegaron os primeiros informes de problemas.
Os aforros da xente desapareceron de súpeto das súas contas. As compras de cantidades insignificantes rexistráronse erroneamente como gastos de varios miles de dólares. Algunhas persoas iniciaron sesión nas súas contas persoais e non viron as súas contas bancarias, senón as contas de persoas completamente diferentes.
Ás 21:00, os representantes de TSB informaron ao regulador financeiro local (a Autoridade de Conduta Financeira do Reino Unido, FCA) que o banco estaba en problemas. Pero a FCA xa se deu conta: a TSB fixo unha gran merda e os clientes fixéronse parvos. E, por suposto, comezaron a queixarse (e hoxe en día, deixar caer algunhas liñas en Twitter ou Facebook non é especialmente difícil). Ás 23:30 horas, outro regulador financeiro, a Autoridade de Regulación Prudencial (PRA), púxose en contacto coa FCA, que tamén percibiu que algo andaba mal.
Xa ben pasada a media noite conseguiron comunicarse cun dos representantes do banco. E failles a única pregunta: "que diaños está pasando?"
Levou tempo comprender a magnitude da traxedia, pero agora sabemos que 1,3 millóns de rexistros de 5,4 millóns de clientes resultaron danados durante a migración. Durante polo menos unha semana, os clientes non puideron xestionar o seu diñeiro desde os seus ordenadores ou dispositivos móbiles. Non puideron pagar o préstamo, e moitos clientes bancarios recibiron unha mancha no seu historial de crédito, así como comisións por demora.
Así era o banco en liña do cliente de TSB
Cando os fallos comezaron a aparecer, case inmediatamente despois, os representantes bancarios insistiron en que os problemas eran "intermitentes". Tres días despois, emitiuse un comunicado de que todos os sistemas eran normais. Pero os clientes seguiron informando problemas. Non foi ata o 26 de abril de 2018 que o director executivo do banco, Paul Pester, admitiu que TSB estaba "de xeonllos" xa que a infraestrutura informática do banco seguía tendo un "problema de ancho de banda" que impedía que preto dun millón de clientes accedan aos servizos bancarios en liña.
Dúas semanas despois da migración, aínda se informou de que a aplicación de banca en liña estaba experimentando erros internos relacionados coa base de datos SQL.
As dificultades de pago, especialmente coas facturas de negocios e hipotecas, continuaron ata catro semanas. E os xornalistas omnipresentes descubriron que TSB rexeitou unha oferta de axuda de Lloyds Banking Group ao comezo da crise migratoria. En xeral, ata o 3 de setembro observáronse problemas asociados ao inicio de sesión nos servizos en liña e á posibilidade de transferir diñeiro.
Un pouco de historia
O primeiro caixeiro automático abriuse o 27 de xuño de 1967 preto de Barclays en Enfield
Os sistemas informáticos bancarios son cada vez máis complexos a medida que aumentan as necesidades dos clientes e as expectativas do banco. Hai uns 40-60 anos, estariamos encantados de visitar a nosa sucursal bancaria local durante o horario comercial para depositar diñeiro en efectivo ou retiralo a través do caixeiro.
A cantidade de diñeiro da conta estaba directamente relacionada co diñeiro en efectivo e as moedas que lle dabamos ao banco. A nosa contabilidade doméstica podíase seguir con bolígrafo e papel, e os sistemas informáticos non eran accesibles para os clientes. Os empregados do banco colocaron datos de libretas e outros medios nos dispositivos que contaban o diñeiro.
Pero en 1967 no norte de Londres por primeira vez un caixeiro automático que non estaba situado nas instalacións bancarias. E este evento cambiou a banca. A comodidade do usuario converteuse nun referente para o desenvolvemento das entidades financeiras. E isto axudou aos bancos a ser máis sofisticados en canto a traballar cos clientes e o seu diñeiro. Despois de todo, aínda que os sistemas informáticos estaban dispoñibles só para os empregados dos bancos, estaban satisfeitos coa antiga forma "en papel" de interactuar cos clientes. Só coa chegada dos caixeiros automáticos e despois da banca en liña, o público en xeral tivo acceso directo aos sistemas informáticos bancarios.
Os caixeiros automáticos foron só o comezo. Pronto a xente puido evitar a cola na caixa rexistradora simplemente chamando ao banco por teléfono. Isto requiriu tarxetas especiais inseridas nun lector capaz de descifrar os sinais multifrecuencia de dobre ton (DTMF) transmitidos cando o usuario preme a tecla "1" (retirar diñeiro) ou "2" (depositar fondos).
Internet e a banca móbil achegaron aos clientes aos sistemas fundamentais que alimentan os bancos. A pesar das súas diferentes limitacións e configuracións, todos estes sistemas deben interactuar eficazmente entre si e co mainframe principal, realizando comprobacións de saldo da conta, realizando transferencias de diñeiro, etc.
Poucos clientes pensan no complexo que é o camiño da información cando, por exemplo, inicias sesión nun banco en liña para ver ou actualizar a información sobre o diñeiro da túa conta. Cando inicia sesión, estes datos pásanse a través dun conxunto de servidores; cando realiza unha transacción, o sistema duplica estes datos na infraestrutura de backend, que despois fai o traballo pesado: transferir diñeiro dunha conta a outra para pagar facturas, facer pagos e continuar coas subscricións.
Agora multiplica este proceso por varios miles de millóns. Segundo os datos recompilados polo Banco Mundial coa axuda da Fundación Bill e Melinda Gates, adultos de todo o mundo teñen unha conta bancaria. Cada unha destas persoas ten facturas que pagar. Alguén paga unha hipoteca ou transfire diñeiro para clubs infantís, alguén paga unha subscrición a Netflix ou aluga un servidor na nube. E todas estas persoas usan máis dun banco.
Numerosos sistemas informáticos internos dun banco (banca móbil, caixeiros automáticos, etc.) non deben simplemente interactuar entre si. Necesitan interactuar con outros sistemas bancarios en Brasil, China e Alemaña. Un caixeiro automático francés debería poder dispensar diñeiro que está nunha tarxeta bancaria emitida nalgún lugar de Bolivia.
O diñeiro sempre foi global, pero nunca antes o sistema foi tan complexo. O número de formas de utilizar os sistemas informáticos bancarios está aumentando, pero as antigas formas seguen en uso. O éxito dun banco depende en gran medida do "mantible" que sexa a súa infraestrutura de TI e da eficacia coa que o banco pode afrontar un fallo repentino debido ao cal o sistema estará inactivo.
Sen probas: prepárate para os problemas
O conselleiro delegado do Banco de Sabadell, Jaime Guardiola (esquerda), confiou en que todo sairá ben. Non funcionou.
Os sistemas informáticos de TSB non eran moi bos para resolver problemas rapidamente. Houbo, por suposto, fallos de software, pero en realidade o banco "rompeu" debido á excesiva complexidade dos seus sistemas informáticos. Segundo o informe, que se preparou nos primeiros días da interrupción masiva, "a combinación de novas aplicacións, o aumento do uso de microservizos combinado co uso de dous centros de datos activos/activos provocaron un risco complexo na produción".
Algúns bancos, como HSBC, operan a nivel mundial e, polo tanto, tamén teñen sistemas moi complexos e interconectados. Pero son probados, migrados e actualizados regularmente, segundo un responsable de TI de HSBC en Lancaster. Ve o HSBC como un modelo de como deberían xestionar os seus sistemas informáticos outros bancos: dedicando persoal e dedicando o seu tempo. Pero ao mesmo tempo admite que para un banco máis pequeno, especialmente un que non ten experiencia en migración, facelo correctamente é unha tarefa moi difícil.
A migración da TSB foi difícil. E, segundo os expertos, o persoal do banco simplemente non podería alcanzar este nivel de complexidade en termos de cualificacións. Ademais, nin sequera se molestaron en comprobar a súa solución ou probar a migración con antelación.
Durante un discurso no Parlamento británico sobre problemas bancarios, Andrew Bailey, xefe executivo da FCA, confirmou esta sospeita. O código malo probablemente só causou os problemas iniciais en TSB, pero os sistemas interconectados da rede financeira global fixeron que os seus erros fosen perpetuados e irreversibles. O banco continuou a ver erros inesperados noutros lugares da súa arquitectura de TI. Os clientes recibían mensaxes sen sentido ou sen relación cos seus problemas.
As probas de regresión poderían axudar a evitar desastres detectando código malo antes de que fose lanzado á produción e causaron danos ao crear erros que non se puideron revertir. Pero o banco decidiu atravesar un campo minado que nin sequera coñecía. As consecuencias eran previsibles. Outro problema foi a "optimización" dos custos. Como se manifestou? O caso é que previamente se decidiu eliminar as copias de seguridade almacenadas en Lloyds, xa que "comían" demasiado diñeiro.
Os bancos británicos (e outros tamén) esfórzanse por acadar un nivel de dispoñibilidade de catro nove, é dicir, do 99,99%. Na práctica, isto significa que o sistema informático debe estar dispoñible en todo momento, con ata 52 minutos de inactividade ao ano. O sistema "tres nove", 99,9%, a primeira vista non difire moito. Pero en realidade isto significa que o tempo de inactividade alcanza as 8 horas ao ano. Para o banco, "catro nove" é bo, pero "tres nove" non.
Pero cada vez que unha empresa fai cambios na súa infraestrutura de TI, asume riscos. Despois de todo, algo pode saír mal. Reducir os cambios pode axudar a evitar problemas, mentres que os cambios necesarios necesitan probas coidadosas. E os reguladores británicos centraron a súa atención neste punto.
Quizais a forma máis sinxela de evitar o tempo de inactividade sexa simplemente facer menos cambios. Pero todos os bancos, como calquera outra empresa, están obrigados a introducir cada vez máis funcións útiles para os clientes e para o seu propio negocio para seguir sendo competitivos. Ao mesmo tempo, os bancos seguen obrigados a coidar dos seus clientes, protexendo os seus aforros e datos persoais, proporcionando condicións cómodas para o uso dos servizos. Resulta que as organizacións vense obrigadas a gastar moito tempo e diñeiro en manter a saúde da súa infraestrutura informática, ao tempo que ofrecen novos servizos.
O número de fallos tecnolóxicos denunciados no sector dos servizos financeiros no Reino Unido aumentou un 187 por cento entre 2017 e 2018, segundo os datos publicados pola Financial Conduct Authority do Reino Unido. Na maioría das veces, a causa dos fallos son os problemas no funcionamento da nova funcionalidade. Ao mesmo tempo, é fundamental que os bancos garantan o funcionamento constante e ininterrompido de todos os servizos e o informe case instantáneo das transaccións. Os clientes sempre están nerviosos cando o seu diñeiro está nalgún lugar. E un cliente que está nervioso polo diñeiro é sempre un sinal de problemas.
Poucos meses despois do fracaso de TSB (momento no que o director xeral do banco dimitira), os reguladores financeiros do Reino Unido e o Banco de Inglaterra para o debate sobre cuestións de sustentabilidade operativa. Entón, intentaron plantexar a cuestión de ata que punto foron os bancos na procura da innovación e se poden garantir o funcionamento estable do sistema que teñen agora.
O documento tamén propoñía cambios na lexislación. Tratábase de responsabilizar ás persoas da empresa polo que falla nos sistemas informáticos da empresa. Os parlamentarios británicos explicárono deste xeito: "Cando es persoalmente responsable e podes ir á quebra ou ir a prisión, isto cambiará moito a actitude cara ao traballo, incluíndo o aumento do tempo dedicado á cuestión da fiabilidade e a seguridade".
Resultados de
Cada actualización e parche redúcese á xestión de riscos, especialmente cando están implicados centos de millóns de dólares. Despois de todo, se algo sae mal, pode ser caro en termos de diñeiro e reputación. Parecería cousas obvias. E a falla do banco durante a migración debería ensinarlles moito.
Tiña. Pero non me ensinou. En novembro de 2019, TSB, que volveu acadar a rendibilidade e foi mellorando lentamente a súa reputación, "encantaba" aos clientes no campo das tecnoloxías da información. O segundo golpe para o banco fixo que se verá obrigado a pechar 82 oficinas en 2020 para reducir os seus custos. Ou simplemente non podería aforrar en especialistas en TI.
A mezquindade coas TI ten un custo. TSB reportou unha perda de 134 millóns de dólares en 2018, en comparación cun beneficio de 206 millóns de dólares en 2017. Os custos posteriores á migración, incluíndo a compensación dos clientes, a corrección de transaccións fraudulentas (que aumentaron moito durante o caos bancario) e a asistencia de terceiros, sumaron 419 millóns de dólares. O provedor de TI do banco tamén recibiu unha factura de 194 millóns de dólares polo seu papel na crise.
Non obstante, independentemente das leccións que se aprendan da quebra bancaria da TSB, aínda se producirán interrupcións. Son inevitables. Pero coas probas e un bo código, pódense reducir moito os fallos e o tempo de inactividade. Cloud4Y, que a miúdo axuda ás grandes empresas a migrar á infraestrutura na nube, comprende a importancia de pasar rapidamente dun sistema a outro. Polo tanto, podemos realizar probas de carga e utilizar un sistema de copia de seguridade de varios niveis, así como outras opcións que che permiten comprobar todo o posible antes de iniciar a migración.
Que máis podes ler no blog?
→
→
→
→
→
Subscríbete ao noso -canle, para non perder o seguinte artigo! Escribimos non máis de dúas veces por semana e só por negocios.
Fonte: www.habr.com