 |
| Bellacosa Mainframe e a lei de murphy rules |
☕ Um Café no Bellacosa Mainframe
Murphy's Law Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Não Era Derrotada Pelos Grandes Bugs… Mas Pelos Pequenos Erros que Ninguém Testou
"Tudo o que pode dar errado, dará errado... principalmente às 2h17 da madrugada, durante o fechamento mensal, quando o especialista está de férias e o gerente pergunta: 'Mas vocês não testaram isso?'"
Prólogo — O Bug Impossível da Matrix
Era o último minuto antes da implantação da nova versão da Matrix.
Toda a equipe estava reunida.
Neo revisava cuidadosamente o último programa COBOL.
Trinity conferia as APIs.
Tank monitorava o CICS.
Link acompanhava as filas MQ.
O Arquiteto perguntou:
— Todos os testes passaram?
Neo respondeu confiante.
— Sim.
O Arquiteto sorriu.
— Todos?
Neo hesitou.
— Bem...
todos os que imaginamos.
O sistema entrou em produção.
Cinco segundos depois.
O telefone tocou.
Era Zion.
O saldo de todos os habitantes havia desaparecido.
Neo olhou para Morpheus.
— Como isso aconteceu?
O Oráculo apareceu.
Pegou um pequeno parafuso metálico.
Colocou sobre a mesa.
E disse:
"Vocês testaram tudo... menos aquilo que realmente iria acontecer."
Neo respirou fundo.
Naquele instante compreendeu a Lei de Murphy.
O que é a Lei de Murphy?
A Lei de Murphy é um princípio informal que afirma:
"Anything that can go wrong, will go wrong."
Ou, em português:
"Tudo o que pode dar errado, dará errado."
Na Engenharia de Software, essa frase não significa pessimismo.
Ela significa preparação.
Projetamos sistemas assumindo que falhas acontecerão.
Porque elas realmente acontecem.
A verdadeira origem da Lei de Murphy
Ao contrário do que muita gente imagina, a Lei de Murphy não nasceu da computação.
Ela surgiu em 1949, durante experimentos da Força Aérea dos Estados Unidos.
O engenheiro Edward A. Murphy Jr. trabalhava em testes de aceleração com foguetes.
Em um dos experimentos, sensores foram instalados de maneira incorreta.
Todos.
O teste inteiro falhou.
Murphy comentou algo equivalente a:
"Se existir uma maneira de alguém montar isso errado, alguém vai montar."
Com o tempo a frase evoluiu para a forma conhecida mundialmente.
Matrix explica perfeitamente
Imagine Neo.
Existe apenas uma porta errada.
Qual porta o Agente Smith escolhe?
Exatamente aquela.
Existe um cabo conectado invertido.
Qual cabo será usado na produção?
Esse mesmo.
Existe um único usuário que digita um caractere inesperado.
Quem aparece primeiro?
Ele.
Murphy nunca dorme.
O COBOL conhece Murphy há décadas
Imagine um programa.
Você testou:
CPF válido.
Saldo positivo.
Cliente ativo.
Tudo funciona.
Primeiro dia em produção.
Chega um cliente com:
CPF estrangeiro.
Conta conjunta.
Limite especial.
Saldo negativo.
Produto encerrado.
Agência incorporada.
Dados vindos via Open Finance.
ABEND.
Murphy sorri.
Murphy não cria problemas
Essa é uma confusão comum.
Murphy não "faz" algo dar errado.
Ele apenas lembra que:
seres humanos erram.
Hardware falha.
Redes caem.
Discos quebram.
Usuários digitam errado.
APIs ficam indisponíveis.
Sistemas distribuídos apresentam atrasos.
Falhas fazem parte da realidade.
Matrix Reloaded
Neo finalmente aprende a enxergar o código verde.
Mesmo assim.
Ele nunca assume que a Matrix será perfeita.
Sempre existe:
um agente escondido.
um programa exilado.
uma porta secreta.
uma variável inesperada.
Essa postura é exatamente o espírito da Engenharia de Software.
O efeito psicológico
Existe um viés chamado:
Excesso de confiança.
Pensamos:
"Comigo não acontece."
Até acontecer.
Murphy combate exatamente esse comportamento.
O Programador COBOL Padawan
Imagine seu primeiro programa.
Você testa:
10
20
30
Tudo funciona.
Produção recebe:
-999999999999
Ou:
ZERO
SPACES
NULL
UTF-8
EBCDIC inesperado
Você nunca imaginou.
Murphy imaginou.
O Agente Smith adora pressupostos
Smith sabe que basta uma hipótese falsa.
"Esse campo nunca vem vazio."
"Esse arquivo sempre chega."
"Essa API nunca cai."
"Esse usuário nunca faz isso."
É exatamente aí que ele ataca.
Um exemplo COBOL
Programa.
DIVIDE WS-VALOR
BY WS-QUANTIDADE
Pergunta.
Quem garantiu que:
WS-QUANTIDADE
nunca será zero?
Se ninguém garantiu.
Murphy garantirá o contrário.
Outro exemplo clássico
READ CLIENTE
E se o registro não existir?
Foi testado?
Como Murphy aparece?
Pequenos detalhes.
Arquivo cheio.
Disco indisponível.
Dataset bloqueado.
Job cancelado.
Db2 indisponível.
MQ congestionado.
Timeout REST.
Token expirado.
Data inválida.
Leap Year.
Horário de verão.
Nenhum parece impossível.
Todos acontecem.
O custo invisível
A maior parte do desenvolvimento testa:
caminhos felizes.
Pouca gente testa:
fracassos.
Mas é justamente neles que sistemas críticos demonstram qualidade.
O impacto no Mainframe
Mainframes executam bilhões de transações.
Logo.
Mesmo eventos raríssimos acabam acontecendo.
Se uma falha possui probabilidade de:
1 em 100 milhões.
Um banco processando bilhões de operações provavelmente a encontrará.
Curiosidade
Existe uma frase muito conhecida entre engenheiros:
"Hope is not a strategy."
Esperança não substitui testes.
Matrix e os Sentinelas
Imagine construir Zion assumindo que:
"Os Sentinelas nunca encontrarão este túnel."
Essa não é uma estratégia.
É um desejo.
Ferramentas ajudam
Hoje possuímos recursos incríveis.
No universo IBM.
ZUnit.
IBM Test Accelerator.
Galasa.
Debug Tool.
Fault Analyzer.
File Manager.
Application Performance Analyzer.
OMEGAMON.
Instana.
Eles ajudam a descobrir falhas antes da produção.
O papel dos testes
Murphy explica exatamente por que existem:
Testes Unitários
Cada módulo.
Testes Integrados
Comunicação.
Testes de Performance
Carga.
Testes de Segurança
Ataques.
Chaos Engineering
Falhas controladas.
Disaster Recovery
Pior cenário.
Matrix e Chaos Engineering
Imagine Morpheus desligando propositalmente parte da Matrix.
Por quê?
Para descobrir.
Antes de Smith.
Essa é exatamente a ideia do Chaos Engineering.
O papel da IA
A IA pode:
gerar casos de teste;
encontrar caminhos pouco explorados;
sugerir cenários extremos;
revisar código;
detectar riscos.
Mas continua dependendo da criatividade humana para imaginar situações improváveis.
Atenção!
Murphy não significa paranoia.
Significa preparação.
Existe enorme diferença.
A diferença
Pessimismo
"Nada funciona."
Engenharia
"Se falhar, estaremos preparados."
Os riscos
Quando Murphy é ignorado.
Surgem.
ABENDs.
Incidentes.
Perda financeira.
Vazamento de dados.
Retrabalho.
Imagem comprometida.
Erros clássicos
Testar apenas cenário feliz.
Ignorar exceções.
Não validar entrada.
Assumir infraestrutura perfeita.
Não testar recuperação.
Boas práticas
Teste entradas inválidas.
Faça testes negativos.
Automatize regressão.
Valide limites.
Simule falhas.
Faça rollback.
Monitore produção.
Aplicabilidade
Murphy aparece em:
COBOL.
CICS.
Db2.
MQ.
Cloud.
Java.
Python.
Kubernetes.
APIs.
IA.
Nenhuma tecnologia escapa.
O ensinamento do Oráculo
O Oráculo entrega duas xícaras para Neo.
Uma perfeita.
Outra com uma pequena rachadura.
Pergunta.
— Qual você levaria para atravessar o deserto?
Neo escolhe a perfeita.
Ela sorri.
Depois derruba as duas.
A perfeita quebra.
A rachada continua inteira porque era mais espessa.
Ela olha para Neo.
"Você testou apenas a aparência. Nunca testou a queda."
Murphy e o Mainframe Moderno
No universo IBM Z existe um princípio silencioso que acompanha décadas de engenharia: construa sistemas assumindo que componentes falharão.
Por isso existem:
Parallel Sysplex para alta disponibilidade.
GDPS para recuperação de desastres.
RACF para minimizar erros de acesso.
CICS Transaction Server com recuperação automática.
Db2 com logs e rollback.
MQ garantindo entrega confiável de mensagens.
Nada disso existe porque os engenheiros acreditavam que tudo funcionaria para sempre.
Existe porque eles sabiam que Murphy apareceria.
Lições para um Programador COBOL Padawan
Durante sua carreira você escreverá programas que movimentarão dinheiro, impostos, aposentadorias, seguros e milhões de transações críticas.
Nunca pergunte apenas:
"O programa funciona?"
Pergunte também:
O que acontece se o arquivo não existir?
E se o banco estiver indisponível?
E se o usuário informar dados inválidos?
E se houver timeout?
E se a conexão cair durante o COMMIT?
E se o disco ficar cheio?
E se o horário mudar por causa do fuso?
Essas perguntas transformam um programador em um engenheiro.
Curiosidades
A Lei de Murphy inspirou diversos conceitos modernos:
Defensive Programming
Fail Fast
Circuit Breaker
Retry Pattern
Bulkhead Pattern
Chaos Engineering
Site Reliability Engineering (SRE)
Todos partem da mesma premissa:
falhas acontecerão.
A diferença está em como o sistema reage a elas.
Conclusão — A Matrix Não Era Forte Porque Nunca Falhava
No final da trilogia percebemos algo importante.
A Matrix nunca foi perfeita.
Ela possuía mecanismos para detectar falhas, adaptar-se e continuar funcionando.
Essa é exatamente a essência da Engenharia de Software.
A Lei de Murphy não é um convite ao pessimismo.
É um convite à humildade.
Ela nos lembra que usuários surpreendem, infraestrutura falha, requisitos mudam e eventos improváveis acabam acontecendo — especialmente em sistemas que executam milhões ou bilhões de operações.
Para um Programador COBOL, especialmente no ambiente IBM Z, isso significa projetar aplicações resilientes, validar entradas, tratar exceções, automatizar testes e preparar planos de recuperação antes que a produção cobre essa preparação.
No universo Bellacosa Mainframe existe uma máxima que Morpheus certamente diria aos novos Padawans antes do primeiro deploy:
"Não escreva código esperando que nada falhe. Escreva código sabendo que um dia tudo poderá falhar — e que, mesmo assim, o sistema continuará de pé."
Porque o verdadeiro Escolhido não é aquele que nunca encontra um bug.
É aquele que já havia imaginado esse bug muito antes de ele aparecer na tela verde do terminal.
Sem comentários:
Enviar um comentário