Uma migração falhada da infraestrutura de TI resultou na corrupção de 1,3 mil milhões de registos de clientes bancários. Tudo isto se deveu a testes insuficientes e a uma atitude frívola em relação a sistemas de TI complexos. Cloud4Y conta como isso aconteceu.
Em 2018 Inglês percebeu que o seu “divórcio” de dois anos com o grupo bancário Lloyds (ambas as empresas se fundiram em 1995) era demasiado caro. A TSB ainda estava ligada ao seu antigo parceiro através de sistemas de TI do Lloyds clonados às pressas. O pior de tudo é que o banco teve de pagar “pensão alimentícia”, uma taxa de licenciamento anual de 127 milhões de dólares.
Poucas pessoas gostam de pagar dinheiro aos ex-namorados, então no dia 22 de abril de 2018 às 18h TSB começou a fase final de um plano de 00 meses que deveria mudar tudo. Foi planejado transferir bilhões de registros de clientes para o sistema de TI da empresa espanhola Banco Sabadell, que comprou o TSB por US$ 18 bilhões em 2,2.
O CEO do Banco Sabadell, José Olu, falou sobre o próximo evento duas semanas antes do Natal de 2, durante uma festiva reunião de funcionários em uma prestigiada sala de conferências em Barcelona. A ferramenta de migração mais importante seria uma nova versão do sistema desenvolvido pelo Banco Sabadell: Proteo. Foi até renomeado como Proteo2017UK especificamente para o projeto de migração TSB.
Na apresentação do Proteo4UK, o diretor executivo do Banco Sabadell, Jaime Guardiola Romojaro, gabou-se de que o novo sistema é um projeto de grande escala que não tem análogos na Europa, no qual trabalharam mais de 1000 especialistas. E que a sua implementação proporcionará um impulso significativo ao crescimento do Banco Sabadell no Reino Unido.
22 de abril de 2018 foi definido como o dia da migração. Era uma noite tranquila de domingo, no meio da primavera. Os sistemas de TI do banco ficaram inativos à medida que os registros eram transferidos de um sistema para outro. Com o acesso público às contas bancárias restaurado na noite de domingo, seria de esperar que o banco voltasse ao serviço lenta e suavemente.
Mas enquanto Olyu e Guardiola Romojaro transmitiam alegremente do palco sobre a implementação do projeto Proteo4UK, os funcionários responsáveis pelo processo de migração estavam muito nervosos. O projeto, que levou 18 meses para ser concluído, estava seriamente atrasado e acima do orçamento. Não houve tempo para realizar testes adicionais. Mas transferir todos os dados da empresa (que, lembre-se, são bilhões de registros) para outro sistema é uma tarefa hercúlea.
Acontece que os engenheiros estavam nervosos por um bom motivo.
Um esboço no site que os clientes viram por muito tempo
20 minutos depois que o TSB abriu o acesso às contas, estando plenamente confiante de que a migração ocorreu sem problemas, chegaram os primeiros relatos de problemas.
As poupanças das pessoas desapareceram subitamente das suas contas. Compras de valores insignificantes foram erroneamente registradas como despesas de vários milhares de dólares. Algumas pessoas acessaram suas contas pessoais e não viram suas contas bancárias, mas contas de pessoas completamente diferentes.
Às 21h00, os representantes do TSB informaram o regulador financeiro local (a Autoridade de Conduta Financeira do Reino Unido, FCA) que o banco estava em apuros. Mas a FCA já percebeu: o TSB realmente estragou tudo e os clientes foram enganados. E, claro, eles começaram a reclamar (e hoje em dia, deixar algumas linhas no Twitter ou no Facebook não é particularmente difícil). Às 23h30, a FCA foi contactada por outro regulador financeiro, a Autoridade de Regulação Prudencial (PRA), que também percebeu que algo estava errado.
Já bem depois da meia-noite conseguiram falar com um dos representantes do banco. E faça-lhes a única pergunta: “o que diabos está acontecendo?”
Demorou algum tempo para compreender a dimensão da tragédia, mas agora sabemos que 1,3 mil milhões de registos de 5,4 milhões de clientes foram danificados durante a migração. Durante pelo menos uma semana, os clientes não conseguiram gerir o seu dinheiro a partir dos seus computadores ou dispositivos móveis. Eles não conseguiram pagar o empréstimo e muitos clientes do banco sofreram uma mancha em seu histórico de crédito, bem como multas por atraso.
Esta é a aparência do banco online do cliente TSB
Quando as falhas começaram a aparecer, quase imediatamente depois, os representantes dos bancos insistiram que os problemas eram “intermitentes”. Três dias depois, foi emitida uma declaração de que todos os sistemas estavam normais. Mas os clientes continuaram a relatar problemas. Só em 26 de abril de 2018 é que o executivo-chefe do banco, Paul Pester, admitiu que o TSB estava "de joelhos", pois a infraestrutura de TI do banco continuava a ter um "problema de largura de banda" que impedia cerca de um milhão de clientes de aceder aos serviços bancários online.
Duas semanas após a migração, o aplicativo de banco on-line ainda apresentava erros internos relacionados ao banco de dados SQL.
As dificuldades de pagamento, especialmente com contas comerciais e hipotecárias, continuaram por até quatro semanas. E jornalistas omnipresentes descobriram que o TSB rejeitou uma oferta de ajuda do Lloyds Banking Group logo no início da crise migratória. Em geral, foram observados problemas associados ao login em serviços online e à capacidade de transferir dinheiro até 3 de setembro.
Um pouco de história
O primeiro caixa eletrônico foi inaugurado em 27 de junho de 1967 perto do Barclays em Enfield
Os sistemas de TI bancários estão se tornando cada vez mais complexos à medida que aumentam as necessidades e expectativas dos clientes em relação ao banco. Cerca de 40-60 anos atrás, teríamos prazer em visitar nossa agência bancária local durante o horário comercial para depositar dinheiro ou retirá-lo no caixa.
A quantidade de dinheiro na conta estava diretamente relacionada ao dinheiro e às moedas que demos ao banco. Nossa contabilidade doméstica podia ser controlada com caneta e papel, e os sistemas de computador não eram acessíveis aos clientes. Os funcionários do banco colocaram dados de cadernetas e outras mídias em dispositivos que contavam o dinheiro.
Mas em 1967, no norte de Londres, pela primeira vez um caixa eletrônico que não estava localizado nas dependências do banco. E este evento mudou o setor bancário. A conveniência do usuário tornou-se referência para o desenvolvimento das instituições financeiras. E isto ajudou os bancos a tornarem-se mais sofisticados em termos de trabalho com os clientes e com o seu dinheiro. Afinal, embora os sistemas informáticos estivessem disponíveis apenas para os funcionários do banco, eles estavam satisfeitos com a antiga forma “em papel” de interagir com os clientes. Foi somente com o advento dos caixas eletrônicos e, posteriormente, dos serviços bancários on-line que o público em geral obteve acesso direto aos sistemas de TI dos bancos.
Os caixas eletrônicos foram apenas o começo. Logo as pessoas conseguiram evitar a fila do caixa simplesmente ligando para o banco. Isso exigia cartões especiais inseridos em um leitor capaz de decifrar os sinais de multifrequência de tom duplo (DTMF) transmitidos quando o usuário pressionava a tecla “1” (sacar dinheiro) ou “2” (depositar fundos).
A Internet e o mobile banking aproximaram os clientes dos principais sistemas que alimentam os bancos. Apesar de suas diversas limitações e configurações, todos esses sistemas devem interagir efetivamente entre si e com o mainframe principal, realizando verificações de saldo de contas, fazendo transferências de dinheiro e assim por diante.
Poucos clientes pensam em quão complexo é o caminho das informações quando você, por exemplo, faz login em um banco on-line para visualizar ou atualizar informações sobre o dinheiro em sua conta. Quando você faz login, esses dados passam por um conjunto de servidores; quando você faz uma transação, o sistema duplica esses dados na infraestrutura de back-end, que então faz o trabalho pesado – transferir dinheiro de uma conta para outra para pagar contas, fazer pagamentos e continuar assinaturas.
Agora multiplique esse processo por vários bilhões. Segundo dados compilados pelo Banco Mundial com a ajuda da Fundação Bill e Melinda Gates, adultos em todo o mundo têm uma conta bancária. Cada uma dessas pessoas tem contas a pagar. Alguém paga uma hipoteca ou transfere dinheiro para clubes infantis, alguém paga uma assinatura do Netflix ou aluga um servidor em nuvem. E todas essas pessoas usam mais de um banco.
Numerosos sistemas informáticos internos de um banco (bancos móveis, caixas eletrônicos, etc.) não devem simplesmente interagir uns com os outros. Eles precisam interagir com outros sistemas bancários no Brasil, na China e na Alemanha. Um caixa eletrônico francês deve ser capaz de dispensar o dinheiro contido em um cartão bancário emitido em algum lugar da Bolívia.
O dinheiro sempre foi global, mas nunca antes o sistema foi tão complexo. O número de formas de utilizar os sistemas informáticos bancários está a aumentar, mas as formas antigas ainda estão em uso. O sucesso de um banco depende em grande parte da “manutenção” da sua infra-estrutura de TI e da eficácia com que o banco consegue lidar com uma falha repentina devido à qual o sistema ficará ocioso.
Sem testes - prepare-se para problemas
O CEO do Banco de Sabadell, Jaime Guardiola (à esquerda), estava confiante de que tudo correria bem. Não funcionou.
Os sistemas computacionais do TSB não eram muito bons em resolver problemas rapidamente. É claro que houve falhas de software, mas na realidade o banco “quebrou” devido à excessiva complexidade dos seus sistemas de TI. De acordo com o relatório, que foi preparado nos primeiros dias da interrupção massiva, “a combinação de novos aplicativos, o aumento do uso de microsserviços combinados com o uso de dois data centers Ativos/Ativos levaram a riscos complexos na produção”.
Alguns bancos, como o HSBC, operam globalmente e, portanto, também possuem sistemas muito complexos e interligados. Mas eles são testados, migrados e atualizados regularmente, de acordo com um gerente de TI do HSBC em Lancaster. Ele vê o HSBC como um modelo de como outros bancos deveriam gerir os seus sistemas de TI: dedicando pessoal e gastando o seu tempo. Mas, ao mesmo tempo, admite que para um banco mais pequeno, especialmente aquele que não tem experiência em migração, fazer isto corretamente é uma tarefa muito difícil.
A migração do TSB foi difícil. E, segundo especialistas, os funcionários do banco simplesmente não poderiam atingir este nível de complexidade em termos de qualificações. Além disso, eles nem se preocuparam em verificar a solução ou testar a migração com antecedência.
Durante um discurso no Parlamento britânico sobre problemas bancários, Andrew Bailey, executivo-chefe da FCA, confirmou esta suspeita. O mau código provavelmente só causou os problemas iniciais no TSB, mas os sistemas interligados da rede financeira global fizeram com que os seus erros fossem perpetuados e irreversíveis. O banco continuou a detectar erros inesperados em outras partes da sua arquitetura de TI. Os clientes receberam mensagens sem sentido ou não relacionadas aos seus problemas.
Os testes de regressão podem ajudar a prevenir desastres, detectando códigos incorretos antes de serem lançados em produção e causando danos ao criar bugs que não podem ser revertidos. Mas o banco decidiu percorrer um campo minado que nem conhecia. As consequências eram previsíveis. Outro problema foi a “otimização” de custos. Como isso se manifestou? O facto é que anteriormente foi decidido acabar com as cópias de segurança armazenadas no Lloyds, uma vez que “consumiam” muito dinheiro.
Os bancos britânicos (e outros também) estão a esforçar-se para atingir um nível de disponibilidade de quatro noves, ou seja, 99,99%. Na prática, isto significa que o sistema informático deve estar sempre disponível, com até 52 minutos de inatividade por ano. O sistema dos “três noves”, 99,9%, à primeira vista não difere muito. Mas na realidade isto significa que o tempo de inatividade chega a 8 horas por ano. Para o banco, “quatro noves” é bom, mas “três noves” não é.
Mas sempre que uma empresa faz alterações na sua infraestrutura de TI, ela assume riscos. Afinal, algo pode dar errado. Reduzir as alterações pode ajudar a evitar problemas, enquanto as alterações necessárias necessitam de testes cuidadosos. E os reguladores britânicos concentraram a sua atenção neste ponto.
Talvez a maneira mais fácil de evitar o tempo de inatividade seja simplesmente fazer menos alterações. Mas todo banco, como qualquer outra empresa, é forçado a introduzir cada vez mais recursos úteis para os clientes e para o seu próprio negócio, a fim de permanecer competitivo. Ao mesmo tempo, os bancos continuam obrigados a cuidar dos seus clientes, protegendo as suas poupanças e dados pessoais, proporcionando condições cómodas de utilização dos serviços. Acontece que as organizações são forçadas a gastar muito tempo e dinheiro mantendo a saúde da sua infra-estrutura de TI, ao mesmo tempo que oferecem novos serviços.
O número de falhas tecnológicas reportadas no sector dos serviços financeiros no Reino Unido aumentou 187 por cento entre 2017 e 2018, de acordo com dados divulgados pela Autoridade de Conduta Financeira do Reino Unido. Na maioria das vezes, a causa das falhas são problemas na operação de novas funcionalidades. Ao mesmo tempo, é fundamental que os bancos garantam o funcionamento constante e ininterrupto de todos os serviços e a comunicação quase instantânea das transações. Os clientes ficam sempre nervosos quando seu dinheiro está em algum lugar. E um cliente que fica nervoso com dinheiro é sempre sinal de problema.
Poucos meses após o fracasso do TSB (quando o CEO do banco já havia renunciado), os reguladores financeiros do Reino Unido e o Banco da Inglaterra para discussão sobre questões de sustentabilidade operacional. Por isso, tentaram levantar a questão de até que ponto os bancos se aprofundaram na procura da inovação e se conseguem garantir o funcionamento estável do sistema que possuem agora.
O documento também propôs mudanças na legislação. Tratava-se de responsabilizar as pessoas dentro da empresa pelo que acontece de errado nos sistemas de TI da empresa. Os parlamentares britânicos explicaram desta forma: “Quando você é pessoalmente responsável e pode ir à falência ou ir para a prisão, isso mudará enormemente a atitude em relação ao trabalho, incluindo o aumento da quantidade de tempo dedicado à questão da confiabilidade e segurança”.
Resultados de
Cada atualização e patch se resumem ao gerenciamento de riscos, especialmente quando centenas de milhões de dólares estão envolvidos. Afinal, se algo der errado, pode custar caro em termos de dinheiro e reputação. Pareceriam coisas óbvias. E o fracasso do banco durante a migração deveria ter-lhes ensinado muito.
Tive. Mas ele não me ensinou. Em novembro de 2019, a TSB, que voltou a atingir rentabilidade e aos poucos melhorou a sua reputação, “encantou” os clientes na área de tecnologia da informação. O segundo golpe para o banco significou que este será forçado a fechar 82 agências em 2020 para reduzir custos. Ou ele simplesmente não poderia economizar em especialistas em TI.
A mesquinhez com a TI tem um custo. A TSB relatou um prejuízo de US$ 134 milhões em 2018, em comparação com um lucro de US$ 206 milhões em 2017. Os custos pós-migração, incluindo compensação de clientes, correção de transações fraudulentas (que aumentaram acentuadamente durante o caos bancário) e assistência de terceiros, totalizaram 419 milhões de dólares. O fornecedor de TI do banco também recebeu US$ 194 milhões por seu papel na crise.
No entanto, independentemente das lições aprendidas com a falência do banco TSB, continuarão a ocorrer perturbações. Eles são inevitáveis. Mas com testes e um bom código, travamentos e tempo de inatividade podem ser bastante reduzidos. A Cloud4Y, que muitas vezes ajuda grandes empresas a migrar para infraestrutura em nuvem, entende a importância de migrar rapidamente de um sistema para outro. Portanto, podemos realizar testes de carga e utilizar um sistema de backup multinível, além de outras opções que permitem verificar tudo o que é possível antes de iniciar a migração.
O que mais você pode ler no blog?
→
→
→
→
→
Assine o nosso -channel para não perder o próximo artigo! Escrevemos no máximo duas vezes por semana e apenas a negócios.
Fonte: habr.com