 |
| Bellacosa Mainframe e o blast radius em desenvolvimento de software |
Blast Radius: Por Que um Pequeno Erro Pode Derrubar um Banco Inteiro
Uma das perguntas mais importantes da engenharia moderna
Imagine que você acabou de entrar em uma grande instituição financeira.
Você é um desenvolvedor COBOL Jr.
Recebe uma tarefa aparentemente simples.
Alterar uma rotina de validação em um programa batch.
O código possui apenas algumas linhas.
A mudança é pequena.
O teste passou.
O deploy foi aprovado.
Tudo parece sob controle.
Dois dias depois surge uma reunião de crise.
Executivos estão reunidos.
Gerentes estão nervosos.
Equipes de infraestrutura trabalham durante a madrugada.
Milhões de registros foram processados incorretamente.
O prejuízo é enorme.
E então alguém faz uma pergunta que todo arquiteto experiente conhece:
Qual era o Blast Radius dessa mudança?
Essa pergunta vale mais do que qualquer revisão de código.
Mais do que qualquer ferramenta de monitoramento.
Mais do que qualquer framework moderno.
Porque ela determina o tamanho potencial do desastre.
O que significa Blast Radius?
A tradução literal seria:
Raio de Explosão.
O termo vem do universo militar.
Quando ocorre uma explosão, existe uma área diretamente afetada.
Quanto maior a explosão, maior o raio de destruição.
A engenharia de software adotou exatamente a mesma ideia.
Quando um sistema falha, uma pergunta precisa ser respondida:
Quantas pessoas, sistemas, operações ou clientes serão impactados?
Essa área de impacto é chamada Blast Radius.
O erro que afeta um cliente
Imagine um programa COBOL responsável por atualizar dados cadastrais.
Um erro afeta:
1 cliente
Problema?
Sim.
Crise?
Provavelmente não.
O impacto é localizado.
O Blast Radius é pequeno.
O erro que afeta um banco inteiro
Agora imagine um programa responsável pela compensação financeira nacional.
Um erro afeta:
30 milhões de clientes
Mesma quantidade de linhas alteradas.
Mesmo programador.
Mesmo tipo de erro.
Resultado completamente diferente.
Por quê?
Porque o Blast Radius mudou.
A pergunta que diferencia um programador de um engenheiro
O desenvolvedor iniciante normalmente pergunta:
Meu código funciona?
O engenheiro experiente pergunta:
O que acontece se ele falhar?
Essa mudança de mentalidade é uma das maiores evoluções na carreira de tecnologia.
Porque sistemas críticos não são avaliados apenas pelo sucesso.
Eles são avaliados pela forma como falham.
O mito do pequeno erro
Existe uma crença perigosa em ambientes corporativos.
"Foi só uma alteração pequena."
O tamanho do código raramente determina o tamanho do impacto.
Um único caractere já derrubou sistemas inteiros.
Um único parâmetro incorreto já gerou perdas milionárias.
Uma única configuração errada já interrompeu operações globais.
O impacto depende do Blast Radius.
Não da quantidade de código.
O universo COBOL e o poder invisível
Desenvolvedores COBOL trabalham em uma situação peculiar.
Muitas vezes manipulam sistemas que movimentam bilhões de reais diariamente.
Mas a interface parece simples.
Uma tela verde.
Alguns arquivos.
JCLs.
Datasets.
Rotinas batch.
Tudo parece tranquilo.
Até que alguém descobre que aquele programa processa:
contas correntes;
cartões;
empréstimos;
investimentos;
liquidações;
compensações.
De repente o código ganha outra dimensão.
O efeito dominó
Imagine uma falha em um cadastro.
Cliente incorreto.
Esse dado alimenta:
CRM;
antifraude;
cobrança;
compliance;
atendimento;
relatórios regulatórios.
Agora uma pequena falha inicial se transforma em dezenas de falhas secundárias.
Isso é amplificação de Blast Radius.
O conceito de dependências
Sistemas modernos não vivem isolados.
Um programa chama outro.
Que chama outro.
Que alimenta outro.
Que gera arquivos para outro.
O resultado é uma rede gigantesca.
Quando um componente falha, o impacto se propaga.
Como peças de dominó.
O exemplo do CPF inválido
Imagine uma rotina simples.
Um CPF inválido passa pela validação.
O erro parece pequeno.
Mas esse dado segue adiante.
Abre conta.
Gera cartão.
Produz relatórios.
Entra em auditorias.
Alimenta modelos analíticos.
Meses depois ninguém sabe mais onde o problema começou.
O Blast Radius cresceu silenciosamente.
O incidente do Nubank como estudo de caso
O episódio envolvendo o falso aviso de liquidação trouxe uma lição interessante.
Independentemente dos detalhes internos, a pergunta arquitetural é:
Qual era o Blast Radius daquele processo?
Se a mensagem atingisse:
10 clientes
O incidente seria pequeno.
Se atingir milhões:
O cenário muda completamente.
A mesma falha produz consequências exponencialmente maiores.
Blast Radius e ambientes de produção
Uma regra simples:
Quanto mais próximo da produção, maior o Blast Radius.
Ambiente de desenvolvimento:
Impacto quase zero.
Homologação:
Impacto limitado.
Produção:
Impacto real.
Produção financeira:
Impacto potencialmente gigantesco.
É por isso que instituições financeiras possuem tantos controles.
Não por burocracia.
Mas porque o custo do erro é enorme.
O perigo dos batches
O mundo COBOL é dominado por processamento em massa.
Um programa pode executar durante horas.
Processando milhões de registros.
O problema é simples.
Se houver um erro:
Ele será repetido milhões de vezes.
Um erro individual torna-se um erro industrializado.
O erro multiplicado
Imagine:
1 registro incorreto
Sem batch:
impacto pequeno.
Agora imagine:
50 milhões de registros
Processados pela mesma lógica defeituosa.
O erro não mudou.
O Blast Radius mudou.
Como arquitetos pensam
Arquitetos raramente perguntam:
"Qual tecnologia usamos?"
Eles perguntam:
"Qual o pior cenário possível?"
Essa pergunta direciona toda a arquitetura.
Porque sistemas críticos são construídos para sobreviver a falhas.
Não apenas para funcionar.
Blast Radius e permissões
Um desenvolvedor possui acesso de leitura.
Blast Radius reduzido.
Um desenvolvedor possui acesso irrestrito.
Blast Radius elevado.
É por isso que ambientes maduros trabalham com:
menor privilégio;
segregação;
controle de acesso;
aprovações.
Tudo isso é gestão de Blast Radius.
Blast Radius e banco de dados
Imagine um comando SQL.
Primeiro cenário:
UPDATE CLIENTES
SET STATUS='A'
WHERE ID=100;
Impacto:
um cliente.
Segundo cenário:
UPDATE CLIENTES
SET STATUS='A';
Impacto:
todos os clientes.
A diferença visual é mínima.
A diferença operacional é gigantesca.
O princípio da contenção
Existe uma palavra muito importante.
Contenção.
Todo sistema moderno deveria conter falhas.
Não espalhá-las.
Por isso empresas investem em:
segmentação;
isolamento;
partições;
zonas independentes.
O objetivo é impedir que uma falha local se torne global.
O conceito de células
Empresas como Amazon popularizaram a ideia de Cell Architecture.
Em vez de uma estrutura única gigante.
Criam-se células menores.
Se uma célula falhar:
As demais continuam operando.
Isso reduz drasticamente o Blast Radius.
Mainframe já fazia isso há décadas
Curiosamente, ambientes mainframe utilizavam conceitos semelhantes muito antes da computação em nuvem.
Exemplos:
LPARs;
regiões CICS;
filas separadas;
ambientes segregados;
jobs independentes.
A filosofia era exatamente a mesma.
Conter impactos.
O problema do compartilhamento excessivo
Quanto mais sistemas compartilham recursos, maior o Blast Radius.
Banco compartilhado.
Fila compartilhada.
Storage compartilhado.
Processamento compartilhado.
Tudo isso cria pontos únicos de falha.
Um problema em um componente afeta dezenas de outros.
O conceito de Blast Radius Humano
Pouca gente fala sobre isso.
Mas pessoas também possuem Blast Radius.
Imagine:
Um único operador consegue executar qualquer comando em produção.
Blast Radius enorme.
Agora imagine:
Necessidade de aprovação dupla.
Blast Radius reduzido.
A governança existe para limitar o alcance dos erros humanos.
O papel dos Guard Rails
Blast Radius e Guard Rails caminham juntos.
Guard Rails tentam impedir erros.
Blast Radius tenta limitar consequências.
Exemplo:
Guard Rail:
impedir exclusão acidental.
Blast Radius:
caso a exclusão ocorra, limitar o impacto.
São conceitos complementares.
Rollout gradual
Uma das formas mais modernas de controlar Blast Radius é o rollout progressivo.
Em vez de liberar uma mudança para todos.
Liberamos para poucos.
Por exemplo:
1%.
Depois 5%.
Depois 10%.
Depois 100%.
Se houver erro, ele será detectado cedo.
O impacto permanece pequeno.
O medo saudável da produção
Existe uma característica interessante nos profissionais experientes de mainframe.
Eles respeitam produção.
Não porque tenham medo da tecnologia.
Mas porque entendem o Blast Radius.
Produção concentra:
clientes;
dinheiro;
contratos;
obrigações regulatórias;
reputação.
Uma pequena falha pode produzir consequências gigantescas.
Observabilidade e Blast Radius
Você não controla aquilo que não consegue enxergar.
Por isso monitoramento é fundamental.
Imagine um batch que normalmente processa:
500 mil registros
Hoje processou:
50 milhões
Algo claramente está errado.
Um sistema observável detecta rapidamente.
Quanto mais cedo o problema é identificado, menor o Blast Radius.
O custo da reputação
Em bancos existe um ativo invisível.
Confiança.
Quando uma falha afeta poucos clientes, a recuperação costuma ser simples.
Quando afeta milhões, surge um problema adicional.
Reputação.
O Blast Radius passa a incluir:
imprensa;
investidores;
reguladores;
mercado.
O dano deixa de ser apenas tecnológico.
O exercício mental que todo COBOL Jr deveria fazer
Antes de qualquer alteração, pergunte:
Se eu errar:
Quantos clientes serão impactados?
Quantos sistemas dependem disso?
Existe rollback?
Existe monitoramento?
Existe plano de contingência?
Existe limite operacional?
Existe validação?
Existe segregação?
Essas perguntas valem mais do que qualquer linha de código.
A verdadeira maturidade profissional
Existe um momento em que o desenvolvedor deixa de ser apenas um programador.
Ele passa a enxergar sistemas.
Passa a enxergar operações.
Passa a enxergar negócios.
Passa a enxergar riscos.
Nesse momento surge uma nova pergunta.
Não mais:
O programa funciona?
Mas sim:
Qual é o Blast Radius se ele parar de funcionar?
Essa mudança de perspectiva transforma a forma de desenvolver software.
Conclusão
Blast Radius é um dos conceitos mais importantes da engenharia moderna porque nos obriga a pensar além do código.
Ele nos força a enxergar impacto.
A enxergar consequências.
A enxergar riscos.
Para um desenvolvedor COBOL Jr, compreender Blast Radius significa entender que o tamanho de uma alteração não determina sua importância.
Uma linha de código pode alterar milhões de contas.
Um único parâmetro pode interromper operações nacionais.
Uma pequena falha pode se propagar por dezenas de sistemas.
Os melhores engenheiros não são aqueles que acreditam que nunca errarão.
São aqueles que projetam sistemas assumindo que erros inevitavelmente acontecerão.
E quando eles acontecerem, o objetivo não será impedir a explosão.
Será garantir que o raio da explosão seja o menor possível.
Esse é o verdadeiro significado de Blast Radius.
