 |
| Bellacosa Mainframe e a desastrosa migracao do TSB Bank |
☕ Um Café no Bellacosa Mainframe — Edição Especial
O Caso TSB Bank: Como uma Migração de Mainframe Destruiu a Reputação de um Banco
Imagine a seguinte cena.
É madrugada em Londres.
As luzes de um data center permanecem acesas enquanto milhões de pessoas dormem. Nos corredores refrigerados, servidores trabalham, discos giram, mensagens atravessam redes, transações são confirmadas e programas executam milhões de instruções sem que ninguém perceba.
Do lado de fora, tudo parece normal.
Dentro da sala de controle, porém, técnicos acompanham monitores, gráficos, indicadores de capacidade e listas intermináveis de tarefas.
Naquela noite, o TSB Bank está realizando uma das operações mais delicadas que uma instituição financeira pode tentar:
migrar todo o seu sistema bancário para uma nova plataforma.
Milhões de contas.
Milhões de clientes.
Pagamentos.
Cartões.
Empréstimos.
Transferências.
Saldos.
Débitos automáticos.
Históricos financeiros.
A operação deveria terminar com uma mensagem simples:
migração concluída com sucesso.
Mas, quando os sistemas voltaram ao ar, o que apareceu foi algo muito diferente.
Clientes sem acesso.
Aplicativos travados.
Pagamentos desaparecidos.
Contas exibindo informações incorretas.
Pessoas enxergando dados de outros clientes.
Chamadas explodindo nos call centers.
Agências lotadas.
Fraudadores aproveitando o caos.
E uma pergunta começou a circular pelos corredores da tecnologia bancária:
O que realmente aconteceu com o TSB Bank?
Coloque o café ao lado do teclado, abra o terminal 3270 imaginário e prepare o bloco de evidências.
Hoje, o Bellacosa Mainframe vai entrar na cena do crime digital.
Cena 1 — O banco que nasceu dependente
Para compreender o colapso do TSB, precisamos voltar alguns anos.
O TSB nasceu novamente como banco independente depois de uma reorganização do setor bancário britânico.
Embora tivesse marca própria, clientes próprios e agências próprias, sua infraestrutura tecnológica ainda dependia fortemente do Lloyds Banking Group.
Era como se o TSB tivesse recebido as chaves de uma casa, mas toda a eletricidade, a água, os encanamentos e a rede de segurança continuassem pertencendo ao antigo proprietário.
O banco utilizava sistemas hospedados e operados pela infraestrutura do Lloyds.
Ali estavam:
o core bancário;
os registros de clientes;
as contas;
os pagamentos;
os canais digitais;
os sistemas de cartão;
os serviços de compensação;
os processos noturnos;
os relatórios regulatórios.
Para um programador COBOL iniciante, podemos comparar essa situação a um grande ambiente compartilhado.
Imagine que uma empresa possui milhares de programas COBOL.
Esses programas usam:
arquivos VSAM;
tabelas Db2;
transações CICS;
filas MQ;
jobs em JES2;
regras RACF;
procedures catalogadas;
datasets GDG;
rotinas assembler;
módulos de comunicação.
Agora imagine que outra empresa deseja sair desse ambiente.
Não basta copiar um programa COBOL.
É necessário separar todo um ecossistema.
Esse era o desafio do TSB.
Cena 2 — A chegada do Banco Sabadell
Em 2015, o banco espanhol Sabadell comprou o TSB.
O Sabadell já possuía uma plataforma bancária própria chamada Proteo.
A lógica de negócio parecia convincente.
Por que continuar pagando para usar os sistemas do Lloyds se o novo proprietário já possuía uma plataforma bancária?
A promessa era reduzir custos, aumentar o controle e integrar o TSB ao modelo tecnológico do grupo espanhol.
No papel, a equação parecia perfeita.
Antigo ambiente:
dependência do Lloyds;
custos elevados;
contratos complexos;
pouca autonomia.
Novo ambiente:
plataforma própria;
maior controle;
redução de custos;
sinergia com o grupo;
liberdade tecnológica.
O problema é que apresentações de PowerPoint não processam transações bancárias.
Planilhas de economia não executam batch.
E uma seta colorida ligando “sistema antigo” a “sistema novo” não representa a verdadeira complexidade de uma migração de core bancário.
Em um diagrama executivo, a migração pode parecer assim:
Lloyds → Proteo4UK
Na vida real, ela se parece mais com isto:
Clientes
↓
Internet Banking
↓
Aplicativo móvel
↓
APIs
↓
Camada de autenticação
↓
Core bancário
↓
Contas / pagamentos / cartões / empréstimos
↓
Db2 / VSAM / arquivos / filas
↓
Compensação bancária
↓
Reguladores
↓
Sistemas externos
E isso ainda é uma simplificação.
Cena 3 — A vítima não era o mainframe
Quando um projeto desse tipo falha, é comum surgir uma narrativa simplificada:
“O sistema legado era velho.”
Ou:
“O problema era o mainframe.”
Essa conclusão é tentadora, mas não descreve corretamente o caso TSB.
O mainframe não era a vítima que precisava ser eliminada.
Também não era o criminoso.
Era parte de um ambiente estável que suportava operações bancárias críticas.
A motivação da migração estava ligada principalmente à independência tecnológica e à redução dos custos associados ao uso da infraestrutura do Lloyds.
Em outras palavras:
o TSB não precisava migrar porque o mainframe havia parado de funcionar.
Precisava migrar porque desejava deixar de depender de uma infraestrutura controlada por outra instituição.
Essa diferença é fundamental.
Em projetos de modernização, existem pelo menos quatro motivos comuns para migrar:
reduzir custos;
eliminar dependências;
acelerar mudanças;
substituir tecnologia sem suporte.
No caso do TSB, a independência e as sinergias econômicas tiveram enorme peso.
O erro começa quando uma necessidade empresarial real é traduzida como se fosse apenas uma troca de plataforma.
Cena 4 — O projeto Proteo4UK
A versão adaptada da plataforma do Sabadell para o mercado britânico ficou conhecida como Proteo4UK.
Ela precisava atender às particularidades do TSB e do sistema financeiro do Reino Unido.
Isso incluía:
regras bancárias locais;
produtos financeiros específicos;
pagamentos britânicos;
regulamentações;
segurança;
auditoria;
proteção de dados;
interfaces com terceiros;
requisitos operacionais;
volumes de transações.
Não era simplesmente instalar um software espanhol em servidores britânicos.
Era necessário adaptar o sistema, integrar componentes, migrar informações e garantir que tudo funcionasse sob carga real.
Aqui aparece uma lição importante para o programador COBOL iniciante:
Migrar dados não significa migrar comportamento
Você pode copiar corretamente todos os registros de um arquivo.
Mesmo assim, o novo sistema pode falhar.
Considere um arquivo VSAM de contas:
NUMERO-CONTA
NOME-CLIENTE
SALDO
LIMITE
STATUS
A migração pode transportar os campos corretamente.
Mas o sistema depende de muito mais:
regras de cálculo;
validações;
autorizações;
locks;
commits;
filas;
timeouts;
concorrência;
autenticação;
capacidade;
monitoramento;
recuperação;
integrações externas.
O dado pode chegar inteiro.
O serviço ao redor dele pode entrar em colapso.
Foi exatamente essa distinção que se tornou central no caso TSB.
Cena 5 — Os testes
O projeto passou por testes, ensaios e simulações.
Foram realizados ciclos preparatórios e migrações de teste.
Também houve um piloto envolvendo funcionários.
Aparentemente, havia evidências suficientes para autorizar a entrada em produção.
Mas testes não são mágicos.
Eles só demonstram aquilo que realmente foi testado.
Se o cenário de teste possui dez mil usuários e a produção recebe um milhão, o resultado pode ser completamente diferente.
Se o ambiente de teste não reproduz fielmente o ambiente de produção, surgem as chamadas diferenças de configuração.
Exemplos:
memória diferente;
rede diferente;
parâmetros diferentes;
versões de software diferentes;
balanceadores diferentes;
regras de firewall diferentes;
capacidade de banco diferente;
limites de sessão diferentes.
Um sistema pode funcionar perfeitamente no teste e falhar em produção.
Não porque o teste foi inútil, mas porque o teste não reproduziu a realidade.
No universo mainframe, isso equivaleria a testar um batch com cem mil registros e colocar em produção com quinhentos milhões.
O programa COBOL pode estar logicamente correto.
Ainda assim, o job pode estourar janela batch, consumir work files, gerar contenção no Db2 ou causar filas em outras aplicações.
Cena 6 — O fim de semana da migração
O grande corte ocorreu entre os dias 20 e 22 de abril de 2018.
O plano era retirar temporariamente os serviços, concluir a transferência e restaurar o acesso dos clientes.
Esse tipo de operação é chamado de cutover.
O cutover representa o momento em que o sistema novo assume a responsabilidade do sistema antigo.
Em uma migração bancária, o cutover pode incluir:
interromper alterações no sistema antigo;
extrair os dados finais;
transformar os registros;
carregar o novo ambiente;
reconciliar saldos;
validar totais;
ativar interfaces;
liberar canais;
monitorar a operação.
Parece simples quando escrito em nove linhas.
Na prática, cada linha pode conter milhares de tarefas.
Uma inconsistência em qualquer etapa pode comprometer o conjunto.
Quando os serviços começaram a voltar, surgiram problemas graves.
Clientes relataram:
falhas de login;
lentidão;
indisponibilidade;
erros de saldo;
operações não concluídas;
visualização de informações de terceiros.
O último item elevou o incidente a outro nível.
Uma indisponibilidade é grave.
Uma possível exposição de dados é gravíssima.
Nesse momento, a migração deixou de ser apenas um problema técnico.
Passou a ser também:
problema de segurança;
problema regulatório;
problema de reputação;
problema político;
problema de confiança.
Cena 7 — O efeito avalanche
Quando um sistema bancário falha, o volume de acessos não diminui.
Ele aumenta.
O cliente tenta entrar uma vez.
Falha.
Tenta novamente.
Falha.
Fecha o aplicativo.
Abre outra vez.
Tenta pelo navegador.
Tenta pelo celular.
Liga para o banco.
Vai até uma agência.
Essa repetição cria uma tempestade de carga.
Vamos imaginar um cenário simples.
Em condições normais:
100 mil clientes fazem 1 tentativa
Total: 100 mil requisições
Durante a crise:
100 mil clientes fazem 10 tentativas
Total: 1 milhão de requisições
O sistema já está degradado.
A pressão aumenta.
Mais clientes encontram erros.
Eles tentam novamente.
A fila cresce.
O tempo de resposta aumenta.
Os balanceadores acumulam conexões.
Os bancos recebem mais consultas.
Os logs explodem.
Os call centers ficam congestionados.
Temos então um ciclo de retroalimentação:
Erro
↓
Nova tentativa
↓
Mais carga
↓
Mais lentidão
↓
Mais erro
↓
Mais tentativas
Isso é parecido com uma cena de CSI em que cada nova pegada pisa sobre as evidências anteriores.
Quanto mais pessoas entram na cena, mais difícil fica descobrir a origem do problema.
Cena 8 — O que realmente falhou
As investigações posteriores apontaram um conjunto de problemas, não uma única causa.
Esse é um detalhe importante.
Grandes desastres tecnológicos raramente possuem um único erro.
Normalmente são o resultado de várias camadas de falha alinhadas.
Entre os fatores discutidos estavam:
diferenças entre ambientes;
falhas de configuração;
problemas de software;
capacidade inadequada;
dificuldades operacionais;
governança insuficiente;
supervisão inadequada de fornecedores;
cronograma agressivo;
confiança excessiva nos indicadores de prontidão.
O sistema não caiu porque alguém esqueceu um ponto final no COBOL.
Também não caiu por causa de uma única máquina defeituosa.
Foi um colapso sistêmico.
Esse conceito é essencial.
Falha local
Um componente quebra, mas o restante continua funcionando.
Exemplo:
um servidor de aplicação falha e o load balancer direciona tráfego para outro.
Falha sistêmica
Vários componentes, processos e decisões se combinam, impedindo a recuperação rápida.
Exemplo:
o sistema apresenta lentidão, o monitoramento é insuficiente, o call center entra em colapso, a comunicação falha e a carga aumenta continuamente.
O caso TSB pertence à segunda categoria.
Cena 9 — A empresa de consultoria e os fornecedores
Projetos dessa escala envolvem muitas empresas.
O grupo Sabadell utilizava sua estrutura tecnológica e empresas associadas para construir e operar a plataforma.
A entidade de tecnologia do grupo, conhecida como Sabis, teve papel importante na implementação.
Também participaram fornecedores e consultorias especializadas.
Antes da aquisição, houve aconselhamento estratégico sobre os caminhos possíveis para a tecnologia do TSB.
Uma alternativa mencionada era permanecer por mais tempo na plataforma Lloyds e, posteriormente, utilizar uma versão independente baseada na tecnologia existente.
Essa abordagem poderia reduzir alguns riscos técnicos, pois preservaria maior compatibilidade com os sistemas já utilizados.
No entanto, a estratégia escolhida priorizou a migração para a plataforma do Sabadell.
Aqui temos outra lição.
O melhor desenho técnico nem sempre vence
Projetos empresariais são decididos por uma combinação de:
custos;
prazo;
estratégia;
política interna;
contratos;
tecnologia;
pressão de investidores;
expectativa de retorno.
Um arquiteto pode recomendar a opção mais segura.
A diretoria pode escolher a opção mais econômica.
Uma consultoria pode apresentar três caminhos.
O conselho pode selecionar o mais rápido.
Isso não significa que os executivos sejam vilões.
Significa que risco técnico e pressão comercial precisam estar equilibrados.
Quando um deles domina completamente o outro, a probabilidade de desastre aumenta.
Cena 10 — A entrada da IBM
Quando a crise já estava instalada, especialistas da IBM foram chamados para auxiliar na estabilização.
É importante deixar isso claro:
a IBM não foi a empresa responsável pela migração original.
Ela entrou posteriormente para ajudar na recuperação.
Em uma analogia com CSI: New York, a IBM chegou quando a fita amarela já estava colocada ao redor da cena.
O objetivo era:
investigar o ambiente;
localizar gargalos;
identificar falhas;
apoiar a estabilização;
restaurar serviços;
melhorar a capacidade;
reduzir a incidência de erros.
Em grandes incidentes, empresas externas podem ser chamadas porque trazem:
experiência especializada;
visão independente;
ferramentas de diagnóstico;
equipes adicionais;
conhecimento de infraestrutura crítica.
Isso é comum em desastres de TI.
Quando a própria equipe está há dias tentando resolver o problema, o cansaço e a pressão podem dificultar a análise.
Uma equipe externa chega com olhar novo.
Cena 11 — O impacto humano
Em tecnologia, é fácil falar apenas de servidores e sistemas.
Mas cada registro representa uma pessoa.
Um pagamento atrasado pode significar:
aluguel não pago;
conta de energia vencida;
compra recusada;
salário inacessível;
empresa sem pagar funcionários;
viagem cancelada;
dívida gerada;
constrangimento público.
O incidente afetou milhões de clientes.
Alguns ficaram sem acessar serviços durante períodos prolongados.
Outros enfrentaram operações duplicadas, falhas de pagamento e dificuldades para falar com o banco.
Também houve aumento das tentativas de fraude.
Golpistas aproveitam crises.
Eles ligam para clientes dizendo:
“Somos do banco e precisamos confirmar seus dados por causa da falha do sistema.”
O cliente, assustado e sem acesso à conta, pode acreditar.
Assim, um incidente operacional transforma-se em risco de segurança.
Cena 12 — O prejuízo
O custo do desastre foi muito maior do que o valor de servidores ou programas.
O TSB teve despesas relacionadas a:
compensações;
recuperação técnica;
reforço de atendimento;
contratação de especialistas;
investigações;
medidas regulatórias;
perda de clientes;
impacto reputacional.
Centenas de milhões de libras foram associadas ao episódio entre custos diretos e efeitos comerciais.
Existe uma diferença entre custo contábil e custo real.
Custo contábil
É o que aparece claramente nos relatórios:
consultorias;
multas;
compensações;
infraestrutura;
despesas jurídicas.
Custo real
Inclui também:
clientes perdidos;
confiança destruída;
marca enfraquecida;
oportunidades comerciais perdidas;
queda na satisfação;
dificuldade de atrair novos clientes;
desgaste dos funcionários.
O segundo é muito mais difícil de medir.
Cena 13 — A multa
Em 2022, os reguladores britânicos aplicaram multas que totalizaram aproximadamente 48,65 milhões de libras.
As sanções estavam relacionadas às falhas na gestão dos riscos operacionais e na execução da migração.
A multa mostra que o incidente não foi tratado apenas como “um problema técnico”.
Para o regulador, o banco tinha responsabilidade de garantir:
continuidade;
resiliência;
governança;
supervisão;
proteção dos clientes;
gestão adequada do risco.
Em setores críticos, a frase “o sistema deu erro” não encerra a discussão.
Alguém aprovou o projeto.
Alguém definiu o cronograma.
Alguém avaliou os riscos.
Alguém autorizou o go-live.
Alguém precisava garantir o plano de contingência.
Cena 14 — A queda do CEO
Paul Pester, então CEO do TSB, enfrentou enorme pressão pública e política.
Ele foi convocado para prestar esclarecimentos ao Parlamento britânico.
Durante as audiências, surgiram perguntas sobre:
prontidão;
comunicação;
testes;
gestão de fornecedores;
resposta à crise;
tratamento dos clientes.
Em setembro de 2018, Pester deixou o cargo.
Em grandes colapsos tecnológicos, a responsabilidade raramente termina na área de TI.
O incidente pode atingir:
CIO;
CTO;
COO;
CEO;
conselho;
fornecedores;
gestores de risco.
Isso acontece porque a tecnologia bancária não é apenas suporte.
Ela é o próprio banco.
Sem sistema, não existe operação.
Cena 15 — O relatório independente
Uma revisão independente foi conduzida pelo escritório Slaughter and May.
O relatório examinou as decisões, os testes, a governança e os acontecimentos ligados à migração.
Entre as críticas estavam:
cronograma excessivamente otimista;
governança insuficiente;
supervisão inadequada;
testes incapazes de reproduzir plenamente o comportamento real;
excesso de confiança antes da entrada em produção.
Esse relatório é valioso porque demonstra que um desastre não deve ser analisado somente pelo erro visível.
O investigador precisa perguntar:
por que o risco não foi detectado?
por que o plano não foi interrompido?
por que os indicadores pareciam positivos?
por que o rollback não resolveu?
por que a recuperação demorou?
por que a comunicação foi confusa?
É o equivalente digital de encontrar uma impressão digital e depois investigar por que a porta estava aberta.
Cena 16 — O banco que não morreu
Apesar do colapso, o TSB não quebrou.
O banco continuou operando.
A plataforma foi estabilizada.
Foram realizados investimentos em resiliência, gestão e controle tecnológico.
Com o tempo, os incidentes diminuíram e a operação voltou a níveis mais normais.
Essa parte é importante.
Um desastre tecnológico pode destruir reputação, provocar multas e derrubar executivos.
Mas não necessariamente encerra a empresa.
A recuperação exige:
transparência;
investimento;
revisão de processos;
melhoria de arquitetura;
reforço da governança;
reconstrução da confiança.
O TSB continuou existindo, mas o episódio de 2018 passou a fazer parte permanente de sua história.
O passo a passo de uma migração mais segura
Agora vamos transformar o caso em aprendizado prático.
Passo 1 — Conheça o sistema antigo
Antes de migrar, documente:
programas;
dados;
integrações;
volumes;
regras;
dependências;
janelas;
usuários;
controles de segurança.
No mainframe, isso pode incluir:
programas COBOL;
copybooks;
JCLs;
PROCs;
arquivos VSAM;
tabelas Db2;
transações CICS;
filas MQ;
regras RACF;
jobs noturnos;
interfaces externas.
Passo 2 — Descubra os comportamentos invisíveis
Muitos sistemas possuem regras que não estão documentadas.
Exemplos:
arquivos processados em ordem específica;
programa que depende de retorno não documentado;
job que só funciona porque outro termina antes;
tabela usada como controle;
operador que executa uma tarefa manual.
Esses detalhes são chamados, muitas vezes, de conhecimento tribal.
Passo 3 — Modele a carga real
Não teste apenas a funcionalidade.
Teste:
volume;
concorrência;
picos;
falhas;
retomadas;
lentidão;
duplicidade;
indisponibilidade de terceiros.
Passo 4 — Faça reconciliação
Depois da migração, compare:
número de contas;
saldo total;
número de transações;
registros rejeitados;
totais financeiros;
históricos;
produtos ativos.
Em COBOL, poderíamos imaginar:
IF TOTAL-ORIGEM NOT = TOTAL-DESTINO
DISPLAY 'ERRO DE RECONCILIACAO'
MOVE 12 TO RETURN-CODE
STOP RUN
END-IF.
Em sistemas bancários, essa lógica precisa existir em escala gigantesca.
Passo 5 — Prepare rollback
Rollback não é apenas manter um backup.
É saber:
quando voltar;
como voltar;
quais dados podem ser perdidos;
como sincronizar alterações;
quem autoriza;
quanto tempo a reversão leva.
Passo 6 — Faça observabilidade
Monitore:
CPU;
memória;
filas;
erros;
tempo de resposta;
conexões;
locks;
commits;
falhas externas;
experiência do cliente.
Passo 7 — Simule o pior dia
Não teste apenas o dia normal.
Teste:
pagamento de salários;
vencimento de contas;
milhões de logins;
falha de data center;
ataque;
perda de rede;
lentidão do banco;
avalanche de retentativas.
Curiosidades da investigação
Curiosidade 1 — Os dados principais não desapareceram
O caso ficou famoso como se todas as contas tivessem sido perdidas.
Mas os dados principais foram migrados.
O colapso ocorreu principalmente na capacidade de disponibilizar e processar esses dados corretamente pelos serviços digitais.
Curiosidade 2 — O sucesso foi anunciado cedo demais
Houve comunicação comemorando a migração antes que a gravidade do problema estivesse clara.
Essa é uma lição clássica:
nunca declare vitória enquanto a produção ainda está respirando por aparelhos.
Curiosidade 3 — O incidente aumentou a atividade fraudulenta
Crises tecnológicas criam terreno fértil para engenharia social.
O criminoso não precisa invadir o mainframe.
Pode simplesmente convencer o cliente a entregar a senha.
Curiosidade 4 — O legado parecia caro até a falha ficar mais cara
O objetivo era economizar e conquistar independência.
O custo do incidente mostrou que uma plataforma estável pode parecer cara apenas até o momento em que sua substituição falha.
Easter egg do Bellacosa Mainframe
Em algum lugar do data center, durante a madrugada da migração, um velho operador de mainframe teria olhado para a tela verde e murmurado:
“No meu tempo, antes de liberar o job, a gente conferia o MAXCC.”
Talvez ninguém tenha ouvido.
Talvez o barulho dos servidores fosse alto demais.
Ou talvez o operador estivesse apenas terminando seu café.
Mas fica a homenagem aos profissionais que sabem que, em sistemas críticos, um simples:
MAXCC=00
não significa que o mundo inteiro esteja funcionando.
Significa apenas que aquele job terminou sem detectar erro.
O cliente pode estar vendo outra coisa.
Conclusão — A cena final
O caso TSB Bank não é uma história sobre tecnologia velha contra tecnologia nova.
É uma história sobre complexidade.
Sobre confiança.
Sobre pressão.
Sobre cronogramas.
Sobre governança.
Sobre a diferença entre migrar dados e migrar um banco.
O mainframe não destruiu a reputação do TSB.
A tentativa de sair de uma infraestrutura estável, combinada com falhas de planejamento, testes, capacidade, configuração, supervisão e resposta operacional, produziu uma crise de enormes proporções.
O maior ensinamento é simples:
Sistemas críticos não falham apenas por causa de código ruim. Eles falham quando tecnologia, processos, pessoas e decisões deixam de funcionar como um único organismo.
Para o programador COBOL iniciante, esse caso mostra que escrever um programa é apenas parte do trabalho.
Você também precisa compreender:
produção;
risco;
volume;
observabilidade;
recuperação;
segurança;
dependências;
impacto no cliente.
Porque, em um banco, cada byte representa dinheiro.
Cada registro representa uma pessoa.
Cada falha pode virar notícia.
E cada migração mal planejada pode transformar uma sala de servidores em uma cena de CSI.
No fim da investigação, as luzes do data center continuam acesas.
Os programas voltam a executar.
As contas reaparecem.
Os pagamentos são processados.
Mas a reputação não possui comando de restart.
Não existe:
//REPUTACAO EXEC PGM=RESTART
Ela precisa ser reconstruída lentamente.
Cliente por cliente.
Transação por transação.
Café por café.
E essa, talvez, seja a lição mais importante de todas.
