 |
| Bellacosa Mainframe e a migragação que quase matou um banco case study TSB Bank |
☕ Um Café no Bellacosa Mainframe
O Paciente TSB: House, COBOL e a Migração Bancária de £1 Bilhão que Quase Matou um Banco
O relógio marcava poucos minutos depois da abertura dos serviços digitais quando os primeiros sintomas apareceram.
Um cliente não conseguia acessar a conta.
Outro via um saldo incorreto.
Um terceiro enxergava informações que aparentemente pertenciam a outra pessoa.
Pagamentos falhavam.
Cartões eram recusados.
O aplicativo móvel apresentava erros.
O internet banking oscilava entre lentidão, indisponibilidade e comportamentos estranhos.
Na sala de operações, os painéis começaram a piscar como monitores de uma UTI.
Alertas.
Filas crescendo.
APIs retornando erro.
Processos atrasados.
Centrais telefônicas congestionadas.
Milhões de clientes tentando descobrir se o dinheiro ainda estava no banco.
Em algum lugar do edifício, provavelmente alguém disse a frase mais perigosa da informática:
— Deve ser apenas um problema temporário.
Se o doutor Gregory House trabalhasse com mainframes, ele provavelmente entraria na sala apoiado em sua bengala, olharia para os gráficos de CPU, para os logs de aplicação e para os executivos reunidos ao redor da mesa e perguntaria:
— Quem foi o gênio que decidiu transplantar o coração, trocar o sistema nervoso e atualizar o cérebro do paciente na mesma cirurgia?
Silêncio.
O paciente era o TSB Bank.
O procedimento era uma gigantesca migração de sistemas e dados.
E o diagnóstico inicial estava completamente errado.
Capítulo 1 — O paciente chega à emergência
O TSB era um banco britânico com milhões de clientes, milhares de funcionários, agências, cartões, contas, empréstimos, pagamentos e serviços digitais.
Embora funcionasse como uma instituição independente, grande parte de sua tecnologia ainda estava hospedada na infraestrutura do Lloyds Banking Group.
Isso significava que os clientes enxergavam a marca TSB, mas muitos sistemas por trás das telas ainda dependiam da plataforma tecnológica do antigo grupo.
Em 2015, o banco espanhol Sabadell adquiriu o TSB.
A aquisição trouxe uma necessidade estratégica bastante compreensível: transferir os sistemas do TSB para uma nova plataforma controlada pelo próprio Sabadell.
A plataforma escolhida era conhecida como Proteo4UK, uma adaptação do sistema Proteo utilizado pelo grupo espanhol.
No papel, o projeto parecia racional.
O banco deixaria de pagar pela dependência tecnológica da Lloyds.
Passaria a controlar sua própria infraestrutura.
Reduziria custos.
Ganharia autonomia.
Modernizaria canais digitais.
Unificaria processos.
Era como transferir um paciente de um hospital antigo para uma nova clínica, equipada com aparelhos modernos, prontuário eletrônico e quartos recém-pintados.
O problema é que um banco não é apenas um edifício cheio de computadores.
Um banco é um organismo vivo.
Cada conta é uma célula.
Cada programa é um órgão.
Cada fila de mensagens é uma artéria.
Cada arquivo VSAM é uma memória.
Cada tabela Db2 é uma parte do DNA.
Cada transação CICS é um impulso nervoso.
Cada job batch é um processo metabólico que precisa acontecer na hora certa.
Migrar um banco não é transportar caixas.
É realizar um transplante completo enquanto o paciente continua respirando, pagando boletos, recebendo salários, autorizando cartões e transferindo dinheiro.
- Para saber mais
https://eljefemidnightlunch.blogspot.com/2020/04/o-caso-tsb-bank-como-uma-migracao-de.html
Capítulo 2 — “Todo mundo mente”, inclusive os dados
Uma das frases mais famosas associadas ao estilo House é:
Todo mundo mente.
Na engenharia de dados, podemos adaptar a frase:
Todo dado mente até ser validado.
Um registro pode parecer correto e ainda estar errado.
Imagine o seguinte conteúdo no sistema antigo:
CLIENTE: 00012345
SALDO: 00000150000
O programador iniciante olha e interpreta:
Saldo = 150.000
Mas o copybook COBOL informa:
05 SALDO-CONTA PIC S9(9)V99 COMP-3.
Agora sabemos que existem duas casas decimais implícitas.
O valor real pode ser:
1.500,00
Além disso, o dado está armazenado em formato decimal compactado.
Se alguém tratar o conteúdo como texto comum, o resultado pode ser inválido.
Esse é um exemplo simples.
Em um banco real, existem milhares de variações:
campos com sinal;
valores em COMP;
números em COMP-3;
datas julianas;
indicadores de um caractere;
campos redefinidos com REDEFINES;
layouts diferentes para tipos diferentes de conta;
valores históricos mantidos em moedas antigas;
campos cujo significado depende de outro campo;
registros criados antes de certas regras modernas;
códigos que só fazem sentido para programas antigos.
Veja um exemplo:
01 REGISTRO-CONTA.
05 TIPO-REGISTRO PIC X.
05 DADOS-GERAIS.
10 NUMERO-CONTA PIC 9(10).
10 CODIGO-CLIENTE PIC 9(08).
05 DADOS-ESPECIFICOS PIC X(100).
01 REGISTRO-CORRENTE REDEFINES REGISTRO-CONTA.
05 FILLER PIC X(19).
05 LIMITE-CHEQUE PIC S9(7)V99 COMP-3.
05 TAXA-JUROS PIC S9(3)V9999 COMP-3.
05 FILLER PIC X(88).
Sem o copybook, o campo DADOS-ESPECIFICOS parece um bloco sem significado.
Com o copybook, descobrimos que parte dele representa limite, juros e informações específicas da conta corrente.
É por isso que acessar os dados de origem sem possuir os modelos, layouts, programas e regras de negócio é como examinar uma radiografia sem saber qual parte do corpo está sendo observada.
Você vê sombras.
Mas não sabe se elas representam um osso, um tumor ou apenas um botão da camisa.
Capítulo 3 — O erro de acreditar que migração é apenas copiar
Um dos maiores enganos em projetos tecnológicos é considerar a migração de dados uma operação simples:
Extrair
Transformar
Carregar
O famoso ETL.
A sigla é correta.
A interpretação simplificada é que causa problemas.
Em um sistema bancário, migrar uma conta exige preservar muito mais do que uma linha de tabela.
É necessário manter:
identificação do cliente;
titularidade;
contas conjuntas;
saldos;
limites;
cartões associados;
empréstimos;
débitos automáticos;
pagamentos agendados;
beneficiários cadastrados;
autenticação;
tokens;
autorizações;
bloqueios judiciais;
histórico;
auditoria;
prevenção à fraude;
regras de compliance;
relacionamento com sistemas externos.
Considere uma tabela simples:
CLIENTE
CONTA
CARTAO
EMPRESTIMO
PAGAMENTO
A princípio, parece suficiente mover cinco conjuntos de dados.
Mas logo surgem as perguntas.
Uma conta pode ter mais de um titular?
Um cliente pode ter várias contas?
Um cartão pode estar temporariamente bloqueado?
Uma dívida pode ser renegociada?
Um pagamento agendado pode depender de saldo futuro?
Uma conta encerrada precisa continuar disponível para auditoria?
Um cliente falecido pode manter processos sucessórios ativos?
Uma conta pode estar sob investigação?
Uma transação pode ter sido autorizada, mas ainda não compensada?
É aqui que o caso deixa de parecer uma simples cópia e passa a se parecer com um episódio de diagnóstico médico.
O sintoma visível é:
O cliente não consegue entrar no aplicativo.
Mas a causa pode estar em:
autenticação;
perfil migrado incorretamente;
chave de acesso ausente;
conta não associada;
API indisponível;
timeout;
fila congestionada;
banco de dados lento;
cache inconsistente;
regra de segurança incompatível;
capacidade insuficiente.
Como House diria:
— O aplicativo não é a doença. É apenas onde a doença decidiu aparecer.
Capítulo 4 — A tempestade perfeita
O desastre do TSB não foi causado por um único erro.
Essa é uma das lições mais importantes.
Grandes colapsos raramente nascem de uma única falha gigantesca.
Eles surgem da combinação de diversas falhas menores que se fortalecem mutuamente.
No caso TSB, houve uma verdadeira tempestade perfeita:
migração de milhões de clientes;
transformação de dados;
mudança de plataforma;
alterações de infraestrutura;
adaptações de software;
novos canais digitais;
integração com diversos sistemas;
pressão por prazo;
planejamento insuficiente;
testes inadequados;
dificuldades operacionais;
respostas lentas durante a crise.
Cada elemento isolado já seria complexo.
Todos juntos criaram um paciente com falência múltipla de órgãos.
Em engenharia de sistemas, devemos evitar mudar várias camadas críticas simultaneamente.
Por exemplo, executar na mesma janela:
Migração de banco de dados
+
Upgrade do sistema operacional
+
Nova versão da aplicação
+
Mudança de infraestrutura
+
Alteração de autenticação
+
Novo aplicativo móvel
Quando algo falha, onde está a causa?
No banco?
Na rede?
Na aplicação?
Na API?
No sistema operacional?
Na autenticação?
No dado convertido?
Na configuração?
Na capacidade?
Sem isolamento de variáveis, a investigação torna-se caótica.
Em medicina, se um paciente toma seis medicamentos novos e apresenta uma reação, fica difícil descobrir qual substância provocou o problema.
Em TI, é a mesma coisa.
O tratamento pode acabar piorando o paciente.
Capítulo 5 — O diagnóstico por amostragem
Um dos pontos mais perigosos em qualquer migração é a confiança exagerada em amostras.
A equipe seleciona alguns milhares de registros.
Compara origem e destino.
Os valores parecem corretos.
O relatório fica verde.
A reunião termina com aplausos.
Mas há um detalhe.
O banco possui milhões de clientes.
Suponha que uma anomalia afete apenas 0,1% dos registros.
Em 5,2 milhões de clientes, isso representa:
5.200 clientes
Cinco mil e duzentas pessoas sem acesso correto ao dinheiro já são suficientes para gerar:
reclamações;
denúncias;
chamadas telefônicas;
repercussão na imprensa;
investigação regulatória;
dano reputacional.
Agora imagine uma falha de 1%.
Temos:
52.000 clientes
Uma amostra aleatória pode não capturar casos raros.
E sistemas bancários são repletos de casos raros.
Entre eles:
conta muito antiga;
endereço internacional;
nome com caracteres especiais;
cliente com múltiplas nacionalidades;
conta bloqueada;
conta conjunta com regras incomuns;
empréstimo renegociado;
cartão substituído;
cliente menor de idade;
cliente falecido;
conta órfã;
saldo negativo com condição especial;
registro criado por sistema desativado;
contrato com código legado.
A amostragem é útil para análise exploratória.
Ela não deve ser confundida com reconciliação completa.
Para dados críticos, o ideal é automatizar a comparação do conjunto inteiro sempre que possível.
Não basta executar:
SELECT COUNT(*) FROM CLIENTES;
e concluir que tudo está correto porque os dois bancos possuem 5.200.000 linhas.
Duas bibliotecas podem ter exatamente um milhão de livros.
Isso não significa que possuam os mesmos livros.
É necessário comparar:
chaves;
valores;
relacionamentos;
totais;
regras;
integridade;
exceções;
duplicidades;
dados ausentes;
transformações.
Capítulo 6 — A anatomia de uma validação verdadeira
Uma boa validação ocorre em várias camadas.
Primeira camada: contagem
Quantos registros existiam na origem?
Quantos chegaram ao destino?
SELECT COUNT(*) FROM CONTA_ORIGEM;
SELECT COUNT(*) FROM CONTA_DESTINO;
Essa verificação é necessária, mas insuficiente.
Segunda camada: somatórios
Compare valores agregados.
SELECT SUM(SALDO) FROM CONTA_ORIGEM;
SELECT SUM(SALDO) FROM CONTA_DESTINO;
Se a quantidade de contas for igual, mas o total financeiro for diferente, existe um problema grave.
Terceira camada: comparação por chave
Cada conta deve existir nos dois lados.
Conta 123 existe na origem?
Conta 123 existe no destino?
Quarta camada: comparação de atributos
Para cada chave:
Saldo origem = saldo destino?
Status origem = status destino?
Limite origem = limite destino?
Data origem = data destino?
Quinta camada: integridade referencial
Todo cartão aponta para uma conta válida?
Todo empréstimo aponta para um cliente existente?
Todo pagamento agendado mantém seu beneficiário?
Sexta camada: regras de negócio
Mesmo que os valores sejam tecnicamente iguais, o comportamento pode estar incorreto.
Exemplo:
Status antigo: B
Status novo: 2
A conversão pode ser válida.
Mas o código 2 significa “bloqueado” ou “encerrado”?
É necessário validar o significado, não apenas o formato.
Sétima camada: comportamento
Depois da migração, o cliente consegue:
entrar;
consultar saldo;
pagar;
transferir;
bloquear cartão;
atualizar cadastro;
receber salário;
consultar extrato?
Dados corretos em repouso podem produzir comportamento incorreto quando utilizados pelas aplicações.
É como um exame de sangue aparentemente normal em um paciente que continua desmaiando.
O diagnóstico ainda não terminou.
Capítulo 7 — O Big Bang e o botão vermelho
O TSB adotou uma abordagem de grande corte, frequentemente chamada de Big Bang.
Em essência:
parar ou congelar partes do sistema antigo;
extrair dados;
converter;
carregar no novo ambiente;
direcionar os clientes para a nova plataforma;
esperar que tudo funcione.
O Big Bang é sedutor.
Executivos gostam dele porque parece definitivo.
Existe uma data.
Existe uma noite de virada.
Existe uma apresentação com foguetes, setas e a palavra “transformação”.
Mas a concentração de risco é enorme.
Se o novo ambiente apresentar problemas, milhões de clientes são afetados simultaneamente.
Uma alternativa é a migração progressiva.
Pode-se dividir por:
produto;
região;
grupo de clientes;
funcionalidade;
canal;
tipo de conta.
Outra abordagem é o chamado Strangler Pattern.
O sistema novo vai gradualmente substituindo funções do antigo.
Imagine:
Semana 1: consulta de saldo
Semana 2: extrato
Semana 3: atualização cadastral
Semana 4: pagamentos
Semana 5: cartões
Ou:
Grupo piloto: 10 mil clientes
Segundo grupo: 100 mil
Terceiro grupo: 500 mil
Expansão gradual
Cada etapa produz aprendizado.
O risco é limitado.
Falhas são descobertas antes de atingir toda a população.
Nem sempre a migração gradual é simples.
Sistemas antigos podem ser altamente acoplados.
Regulamentos e contratos podem impor prazos.
Manter dois ambientes custa dinheiro.
Ainda assim, quando o paciente é um banco com milhões de clientes, prudência custa menos do que uma crise de £1 bilhão.
Capítulo 8 — Reconciliação contínua: o eletrocardiograma dos dados
Durante uma migração, a origem não permanece congelada por semanas.
Clientes continuam movimentando contas.
Novas transações surgem.
Endereços são alterados.
Cartões são bloqueados.
Pagamentos são agendados.
Empréstimos recebem parcelas.
Por isso existe o conceito de delta.
Delta é aquilo que mudou desde a última sincronização.
Considere:
Base completa: 5,2 milhões de clientes
Mudanças na última hora: 12 mil registros
Não é necessário comparar tudo o tempo todo.
Podemos comparar apenas as alterações recentes.
Esse processo é chamado de reconciliação contínua de deltas.
O fluxo pode ser:
Sistema de origem
↓
Captura de alterações
↓
Transformação
↓
Sistema de destino
↓
Comparação automática
↓
Relatório de diferenças
Se a origem recebeu 100 transações e o destino recebeu 98, precisamos descobrir imediatamente quais duas desapareceram.
Não no dia seguinte.
Não depois da abertura das agências.
Não depois que os clientes reclamarem.
Imediatamente.
Essa reconciliação funciona como um monitor cardíaco.
O paciente pode parecer estável, mas o eletrocardiograma mostra pequenas arritmias antes do colapso.
Em ambientes modernos, essa observação pode envolver:
Change Data Capture;
logs de transação;
timestamps;
números sequenciais;
filas;
eventos;
trilhas de auditoria;
checksums;
hashes;
tabelas de controle.
No mainframe, conceitos semelhantes já existem há décadas.
Logs do Db2.
Journals.
SMF.
Logs do CICS.
Registros de recuperação.
Arquivos de controle.
O nome das ferramentas muda.
O princípio permanece.
Capítulo 9 — Ferramentas automáticas não são luxo
Imagine cinco milhões de clientes.
Agora suponha que cada cliente possua 200 atributos relevantes.
Temos aproximadamente:
1 bilhão de valores
Nenhuma equipe humana consegue comparar manualmente esse volume.
Mesmo que cada conferência levasse apenas um segundo, seriam décadas de trabalho.
Automação não é opcional.
É requisito básico.
Uma plataforma de testes de dados deve ser capaz de:
comparar origem e destino;
executar regras;
gerar exceções;
identificar duplicidades;
encontrar registros ausentes;
validar formatos;
calcular somatórios;
verificar relacionamentos;
repetir testes;
manter evidências;
produzir relatórios auditáveis.
Um script simples já pode ajudar.
Pseudo-COBOL:
READ ARQUIVO-ORIGEM
READ ARQUIVO-DESTINO
PERFORM UNTIL FIM-DOS-ARQUIVOS
IF CHAVE-ORIGEM NOT = CHAVE-DESTINO
DISPLAY 'DIFERENCA DE CHAVE'
ELSE
IF SALDO-ORIGEM NOT = SALDO-DESTINO
DISPLAY 'DIFERENCA DE SALDO'
END-IF
END-IF
READ ARQUIVO-ORIGEM
READ ARQUIVO-DESTINO
END-PERFORM
Em produção, a solução seria muito mais sofisticada.
Mas o princípio é exatamente esse:
Comparar de forma repetível, automática e rastreável.
Capítulo 10 — O sistema de origem é o prontuário do paciente
Outra lição crítica é a necessidade de acesso completo ao sistema de origem.
Não basta receber arquivos exportados.
A equipe precisa entender:
copybooks;
modelos de dados;
programas;
regras;
interfaces;
códigos;
exceções;
histórico;
processos batch;
transações online.
Em sistemas COBOL antigos, muitas regras de negócio não estão documentadas em manuais.
Elas vivem no código.
Veja:
IF TIPO-CONTA = 'P'
AND DATA-ABERTURA < 19950101
AND IND-ESPECIAL = 'S'
MOVE TAXA-HISTORICA TO TAXA-APLICADA
ELSE
MOVE TAXA-ATUAL TO TAXA-APLICADA
END-IF.
Essa regra pode ter sido criada trinta anos atrás.
Talvez exista apenas porque um produto antigo concedia uma condição especial.
Se a nova plataforma migrar todos os clientes para a taxa atual, os dados estarão estruturalmente corretos.
Mas o negócio estará errado.
Essa é a diferença entre migrar bytes e migrar significado.
O programador COBOL experiente frequentemente conhece essas exceções.
Ele sabe que determinado campo não pode ser tratado como zero.
Sabe que um código aparentemente obsoleto ainda é usado por um job mensal.
Sabe que um arquivo “temporário” alimenta um relatório regulatório.
Sabe que uma rotina chamada CALCULA-AJUSTE também atualiza auditoria.
Esses profissionais são como médicos veteranos que reconhecem uma doença rara apenas observando um pequeno detalhe.
Quando são excluídos do projeto porque “a plataforma nova não usa COBOL”, o projeto perde parte da memória institucional.
Capítulo 11 — Prazos políticos não curam sistemas
Há duas datas em qualquer grande projeto.
A data desejada.
E a data segura.
Elas nem sempre são iguais.
Executivos trabalham com contratos, custos, compromissos públicos e metas estratégicas.
Engenheiros trabalham com evidências, testes, capacidade, estabilidade e risco.
O conflito nasce quando a data desejada se transforma em uma verdade absoluta.
A reunião de decisão deveria perguntar:
Os dados foram reconciliados?
Os testes críticos passaram?
A capacidade suporta o pico?
O rollback foi ensaiado?
As equipes estão preparadas?
Existem defeitos bloqueadores?
Mas muitas vezes pergunta apenas:
Vamos cumprir a data?
House provavelmente responderia:
— Claro. O funeral também pode ser realizado na data prevista.
Um prazo não corrige defeitos.
Uma apresentação não aumenta capacidade.
Um gráfico verde não apaga erros.
Uma declaração de confiança não substitui um teste.
O critério de entrada em produção deve ser baseado em condições objetivas.
Exemplo:
Zero diferenças financeiras não explicadas
100% das funções críticas aprovadas
Tempo de resposta dentro do limite
Rollback executado com sucesso
Equipe de suporte completa
Defeitos críticos resolvidos
Sem isso, a decisão é uma aposta.
E bancos não deveriam apostar com o dinheiro dos clientes.
Capítulo 12 — Rollback: o desfibrilador que precisa funcionar
Todo grande projeto fala em rollback.
Poucos realmente o testam.
Rollback significa retornar ao estado anterior quando a migração falha.
Mas há perguntas desconfortáveis:
Quanto tempo leva?
Os dados novos podem ser devolvidos?
As transações realizadas no ambiente novo serão perdidas?
Os dois sistemas continuam compatíveis?
Quem autoriza a reversão?
Até que momento é possível voltar?
O rollback foi ensaiado?
Há capacidade operacional para executá-lo?
Imagine:
22h00 — sistema antigo desligado
23h00 — dados extraídos
02h00 — carga concluída
06h00 — novo sistema liberado
08h00 — clientes realizam transações
10h00 — falhas graves confirmadas
Agora não basta religar o sistema antigo.
Entre 06h00 e 10h00 surgiram novas transações.
Como transportá-las de volta?
É por isso que rollback não é um botão mágico.
É um projeto dentro do projeto.
Uma estratégia pode incluir:
congelamento controlado;
logs de transação;
captura de deltas;
sincronização reversa;
limites claros para abortar;
pontos de não retorno;
ensaios completos.
Um plano não testado é apenas literatura corporativa.
Capítulo 13 — Observabilidade: os exames do paciente
Durante uma migração, não devemos observar apenas se o servidor está ligado.
Precisamos medir o comportamento completo.
Infraestrutura:
CPU;
memória;
disco;
rede;
filas;
latência.
Aplicação:
erros;
exceções;
tempo de resposta;
sessões;
threads;
conexões.
Banco de dados:
locks;
deadlocks;
I/O;
buffer pools;
consultas lentas;
contenção.
Negócio:
logins realizados;
pagamentos concluídos;
cartões autorizados;
transferências processadas;
saldos consultados;
falhas por produto.
Esse último grupo é essencial.
O servidor pode apresentar CPU de 40% e ainda assim os clientes não conseguirem pagar contas.
Métricas técnicas dizem como o sistema está respirando.
Métricas de negócio dizem se ele está vivendo.
Em mainframe, podemos utilizar informações provenientes de:
SMF;
RMF;
CICS statistics;
Db2 accounting;
logs;
traces;
MQ;
WLM;
ferramentas de APM.
O segredo é definir limites antes da migração.
Não basta olhar um gráfico e dizer:
— Parece alto.
Devemos saber:
Tempo normal: 300 ms
Limite aceitável: 800 ms
Estado crítico: acima de 2 segundos
Sem baseline, não existe diagnóstico.
Capítulo 14 — A equipe também pode entrar em colapso
Grandes viradas frequentemente envolvem equipes trabalhando durante noites, finais de semana e feriados.
A pressão aumenta.
O sono diminui.
A comunicação piora.
Erros simples tornam-se frequentes.
Uma pessoa executa um comando no ambiente errado.
Outra interpreta incorretamente um alerta.
Uma terceira deixa de escalar um problema porque acredita que será resolvido.
Em incidentes graves, o comportamento humano faz parte do sistema.
Por isso uma migração precisa de:
turnos definidos;
descanso;
funções claras;
canais de comunicação;
autoridade para abortar;
registros de decisão;
responsáveis por cada componente;
war room estruturada.
Uma boa war room não é uma sala cheia de executivos perguntando a cada cinco minutos se o problema acabou.
É um ambiente disciplinado com:
líder do incidente;
especialistas técnicos;
cronologia;
hipóteses;
evidências;
ações;
responsáveis;
próximos passos.
House era brilhante porque testava hipóteses.
Ele não aceitava a primeira explicação.
Na TI, devemos fazer o mesmo.
Sintoma:
Login lento
Hipóteses:
Banco lento
API saturada
Cache vazio
Autenticação com falha
Rede congestionada
Sessões excessivas
Cada hipótese precisa de evidência.
Não de opinião.
Capítulo 15 — Um roteiro prático para migrar sem matar o paciente
Para um programador COBOL iniciante, aqui está um roteiro simplificado.
Passo 1 — Inventarie tudo
Liste:
arquivos;
tabelas;
copybooks;
programas;
jobs;
transações;
interfaces;
filas;
relatórios;
sistemas externos.
Não migre o que você não conhece.
Passo 2 — Descubra as regras escondidas
Leia:
código COBOL;
JCL;
procedures;
stored procedures;
documentação;
logs;
manuais.
Converse com especialistas antigos.
Eles conhecem as cicatrizes do paciente.
Passo 3 — Crie o mapeamento de dados
Para cada campo:
Origem
Destino
Tipo
Tamanho
Regra de transformação
Valor padrão
Exceções
Exemplo:
ORIGEM: STATUS-CLI PIC X
DESTINO: CUSTOMER_STATUS VARCHAR(20)
A = ACTIVE
B = BLOCKED
E = CLOSED
F = DECEASED
Passo 4 — Teste todos os tipos de registro
Não apenas os casos comuns.
Inclua:
extremos;
nulos;
caracteres especiais;
registros antigos;
valores máximos;
valores negativos;
exceções.
Passo 5 — Automatize a reconciliação
Compare:
contagens;
totais;
chaves;
valores;
relacionamentos;
exceções.
Passo 6 — Execute ensaios completos
Faça várias migrações simuladas.
Meça:
duração;
erros;
gargalos;
capacidade;
tempo de recuperação.
Passo 7 — Teste o rollback
Não apenas no PowerPoint.
Execute de verdade.
Passo 8 — Defina critérios de go/no-go
Exemplo:
Se houver diferença financeira não explicada:
NO-GO
Se o tempo exceder a janela:
NO-GO
Se o rollback não estiver disponível:
NO-GO
Passo 9 — Migre progressivamente quando possível
Reduza o raio de impacto.
Passo 10 — Monitore dados e negócio
Não encerre o projeto quando o sistema ligar.
A estabilização pode durar semanas.
Capítulo 16 — Curiosidades da enfermaria mainframe
Primeira curiosidade: sistemas bancários modernos ainda carregam regras criadas décadas atrás.
Não porque ninguém quis modernizá-los, mas porque o dinheiro possui memória.
Um contrato de 1989 pode continuar válido.
Uma hipoteca de vinte anos atrás ainda precisa ser calculada corretamente.
Segunda curiosidade: muitas falhas de migração não são causadas por dados inválidos, mas por dados válidos que o novo sistema não esperava.
O paciente não está mentindo.
O médico apenas nunca viu aquela condição.
Terceira curiosidade: registros encerrados podem ser tão importantes quanto registros ativos.
Auditoria, processos judiciais e reguladores podem exigir histórico por muitos anos.
Quarta curiosidade: a parte mais difícil não é transportar o dado.
É provar que ele chegou corretamente.
Quinta curiosidade: o melhor programador em uma migração pode não ser quem escreve o código mais elegante.
Pode ser aquele analista veterano que pergunta:
— E as contas conjuntas abertas antes da conversão de 1997?
Todos riem.
Depois descobrem 40 mil registros exatamente assim.
Easter egg — O diagnóstico diferencial
Na sala de reunião, o painel mostrava milhões de erros.
O gerente perguntou:
— Pode ser vírus?
O especialista em segurança respondeu:
— Não há evidência.
Outro sugeriu:
— Talvez seja a rede.
O DBA culpou a aplicação.
A aplicação culpou o banco.
O banco culpou a infraestrutura.
A infraestrutura culpou o volume.
O programador COBOL permaneceu em silêncio.
House olhou para ele:
— Você sabe alguma coisa.
O programador abriu um copybook escrito em 1994.
Apontou para uma linha:
88 CLIENTE-ESPECIAL VALUE 'X' 'Y' 'Z'.
— A plataforma nova só reconhece X e Y.
Silêncio.
— Quantos clientes possuem Z? — perguntou alguém.
O programador executou uma consulta.
348.721 registros
House sorriu.
— Finalmente alguém examinou o paciente em vez de culpar o estetoscópio.
Conclusão — A migração nunca é apenas técnica
O desastre do TSB ensina que grandes migrações não fracassam apenas por causa de código defeituoso.
Elas fracassam quando tecnologia, gestão, planejamento, testes, pessoas e governança deixam de trabalhar como um único organismo.
O custo financeiro ultrapassou a dimensão de um simples incidente.
A reputação do banco foi afetada.
Clientes perderam confiança.
Funcionários enfrentaram enorme pressão.
Reguladores investigaram.
Executivos foram responsabilizados.
Tudo porque a operação foi tratada como um projeto tecnológico quando, na realidade, era uma cirurgia no coração da instituição.
Para um programador COBOL iniciante, a grande lição é esta:
Nunca subestime um campo.
Nunca ignore um copybook antigo.
Nunca confie apenas em amostras.
Nunca aceite uma contagem como prova de integridade.
Nunca acredite que o sistema novo compreende automaticamente o significado do sistema antigo.
Nunca considere rollback apenas uma formalidade.
Nunca deixe a data ser mais importante do que a segurança.
E, sobretudo, lembre-se:
Em ambientes bancários, o programa que você escreve não movimenta apenas números.
Ele movimenta salários.
Aposentadorias.
Economias.
Sonhos.
Casas.
Empresas.
Vidas.
Um erro de uma casa decimal pode parecer pequeno na tela.
Multiplicado por milhões de clientes, ele se transforma em uma catástrofe.
A verdadeira modernização não consiste em abandonar o passado.
Consiste em compreendê-lo profundamente antes de construir o futuro.
Na medicina, o primeiro princípio é não causar dano.
Na engenharia de sistemas críticos, deveria ser o mesmo.
E quando alguém disser:
— É apenas uma migração de dados.
Pegue sua bengala imaginária, olhe para os logs e responda:
— Não. É um transplante de memória. E o paciente ainda está acordado.
