 |
| Bellacosa Mainframe e a boiling frog rules |
☕ Um Café no Bellacosa Mainframe
Boiling Frog Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Não Caiu de Uma Vez… Ela Foi Esquentando Até Ninguém Perceber o Colapso
"Nenhum grande sistema entra em colapso de um dia para o outro. Primeiro surgem pequenos avisos. Depois pequenas exceções. Depois pequenos atrasos. Quando todos percebem, o caos já virou rotina."
Prólogo — A Temperatura Invisível da Matrix
Neo caminhava pela sala principal da Nebuchadnezzar quando percebeu algo estranho.
Os monitores mostravam pequenos alertas.
Nada grave.
Um deles dizia:
Tempo médio de resposta: +3 ms
Outro:
CPU: +1%
Outro:
Fila MQ: +5 mensagens
Outro:
Job Batch: +12 segundos
Neo perguntou a Morpheus:
— Devemos nos preocupar?
Morpheus respondeu:
— Ainda não.
No dia seguinte.
Mais alguns milissegundos.
Mais alguns avisos.
Mais algumas exceções.
Depois de alguns meses...
CPU em 98%.
Filas gigantes.
ABENDs.
Clientes reclamando.
Jobs invadindo a manhã.
PIX atrasando.
Neo ficou espantado.
— Como chegamos até aqui?
O Oráculo apareceu segurando uma panela com água.
Ela sorriu.
— A Matrix não explodiu.
Ela apenas foi ficando quente.
Bem-vindo ao Boiling Frog.
O que é Boiling Frog?
Boiling Frog (A Rã Fervida) é um antipadrão de gestão e engenharia de software que descreve situações em que pequenos problemas vão se acumulando lentamente até que o sistema inteiro entre em crise.
Nenhuma mudança isoladamente parece perigosa.
Mas a soma delas transforma um sistema saudável em um ambiente caótico.
É um dos fenômenos mais comuns em projetos de longa duração.
A origem da metáfora
A metáfora da "rã fervida" ficou famosa por afirmar que, se uma rã fosse colocada em água fria aquecida lentamente, ela não perceberia o perigo e acabaria morrendo.
Do ponto de vista biológico, essa história não é considerada correta como descrição do comportamento real de uma rã.
Mesmo assim, a metáfora tornou-se extremamente popular em administração, psicologia e engenharia para ilustrar como mudanças graduais podem passar despercebidas até que seja tarde demais.
Na Engenharia de Software, ela representa a normalização da degradação.
Matrix explica perfeitamente
Quando assistimos ao primeiro Matrix, acreditamos que a simulação é perfeita.
Depois percebemos pequenas falhas.
Um déjà vu.
Um gato repetido.
Um bug.
Depois descobrimos:
programas fugitivos;
agentes descontrolados;
Smith multiplicando-se;
máquinas fora do previsto.
Nada aconteceu de uma vez.
A Matrix deteriorou-se lentamente.
Como nasce o Boiling Frog?
Quase nunca existe um grande erro.
Existem centenas de pequenos.
Hoje:
"Vamos aceitar esse IF."
Amanhã:
"Depois refatoramos."
Semana seguinte:
"Esse warning pode esperar."
Mês seguinte:
"Essa documentação fazemos depois."
Ano seguinte:
"Esse batch já está demorando, mas funciona."
Cinco anos depois.
O sistema virou um campo minado.
O COBOL conhece muito bem esse cenário
Imagine um sistema bancário.
Tempo do fechamento diário:
20 minutos.
25 minutos.
40 minutos.
1 hora.
2 horas.
O batch termina às 10h da manhã.
Ninguém lembra quando começou o problema.
Porque ele nunca chegou de repente.
Um exemplo COBOL
Primeira alteração.
IF WS-TIPO = "A"
Depois.
IF WS-TIPO = "A"
OR WS-TIPO = "B"
Depois.
OR WS-TIPO = "C"
Depois.
OR WS-TIPO = "D"
Depois.
Mais quinze exceções.
O código continua compilando.
Mas sua legibilidade desaparece.
Matrix Reloaded
Neo conversa com o Arquiteto.
O Arquiteto revela que houve diversas versões anteriores da Matrix.
Cada versão acumulou pequenas adaptações.
Nenhuma parecia crítica.
Mas, juntas, tornaram inevitável a criação de uma nova versão.
Essa é exatamente a lógica do Boiling Frog.
O efeito psicológico
Existe um fenômeno conhecido como normalização do desvio.
Quando um pequeno problema ocorre repetidamente e não provoca um desastre imediato, ele passa a ser tratado como normal.
Frases típicas:
"Sempre foi assim."
"Nunca deu problema."
"Depois a gente resolve."
"É só reiniciar."
Essas frases são sinais de alerta.
O Programador COBOL Padawan
Imagine seu primeiro dia.
Você pergunta:
— Por que esse job sempre termina com warning?
Resposta.
— Ah...
ele sempre termina assim.
Outra pergunta.
— E por que o CICS reinicia toda terça?
Resposta.
— Sempre foi assim.
Esse "sempre" merece investigação.
O Agente Smith adora isso
Smith não precisa destruir a Matrix.
Basta convencer todos de que pequenos problemas são aceitáveis.
Cada pequena degradação reduz a capacidade de reação da equipe.
Quando finalmente ocorre o incidente crítico...
já não existe margem para recuperação simples.
Um exemplo inspirado na Matrix
Neo percebe uma rachadura na parede.
Pequena.
No dia seguinte.
Outra.
Depois outra.
Os moradores de Zion dizem:
— Não é nada.
Meses depois.
A muralha desaba.
Nenhuma rachadura individual causou o desastre.
Foi o conjunto.
Como reconhecer?
Alguns sintomas são muito comuns.
Warnings ignorados
Todos convivem com eles.
Performance caindo lentamente
Cada mês um pouco pior.
Débito técnico crescente
Sem plano de redução.
Incidentes recorrentes
Mesma causa.
Logs enormes
Ninguém mais analisa.
Monitoramento cheio de alertas
Mas todos já se acostumaram.
O custo invisível
O sistema continua funcionando.
Mas exige:
mais CPU;
mais memória;
mais operadores;
mais horas extras;
mais especialistas.
A produtividade cai sem que ninguém perceba exatamente quando começou.
O impacto no Mainframe
No IBM Z, pequenos desvios podem aparecer como:
aumento gradual do consumo de MIPS;
crescimento das filas CICS;
aumento do tempo de resposta do Db2;
expansão de datasets;
jobs batch ultrapassando a janela noturna;
crescimento do volume de SMF.
Nenhum deles isoladamente significa desastre.
Juntos, indicam que a temperatura está aumentando.
Atenção!
Boiling Frog não significa que toda pequena mudança seja ruim.
Mudanças graduais são naturais.
O problema é quando elas deixam de ser medidas.
A diferença
Evolução controlada
Mudanças acompanhadas por métricas.
Boiling Frog
Mudanças acumuladas sem acompanhamento.
Curiosidade
Grandes acidentes industriais e tecnológicos frequentemente foram precedidos por pequenos sinais ignorados durante anos.
Na Engenharia de Software acontece o mesmo.
Os grandes incidentes raramente surgem sem avisos.
Ferramentas ajudam
Hoje temos recursos que reduzem esse risco.
No ecossistema IBM:
RMF;
SMF;
OMEGAMON;
IBM Instana;
IBM Z IntelliMagic;
Grafana;
Prometheus.
Essas ferramentas mostram tendências.
O importante não é apenas observar o valor atual.
É perceber sua evolução ao longo do tempo.
Como evitar?
Monitore tendências
Não apenas incidentes.
Faça revisões técnicas periódicas
Arquitetura também envelhece.
Reserve tempo para refatoração
Ela faz parte do projeto.
Elimine pequenos problemas rapidamente
Não espere acumularem.
Defina indicadores
CPU.
Tempo de resposta.
Complexidade.
Cobertura de testes.
Débito técnico.
Questione o "sempre foi assim"
Essa frase merece investigação.
Matrix e o Código Verde
Quando Neo finalmente enxerga a Matrix como código, ele percebe padrões invisíveis.
Engenharia moderna também.
As métricas revelam problemas antes que eles se transformem em crises.
Quem observa apenas o resultado final já chegou tarde.
O papel da IA
A Inteligência Artificial pode identificar tendências difíceis de perceber manualmente.
Ela pode:
detectar crescimento anormal de consumo;
prever degradação de performance;
sugerir áreas com maior dívida técnica;
identificar módulos que recebem alterações excessivas.
Mas a decisão de agir continua sendo humana.
Os riscos
Incidentes inesperados
Na verdade, eram esperados.
Custos crescentes
Infraestrutura aumenta.
Burnout
A equipe vive apagando incêndios.
Baixa inovação
Todo tempo é gasto com manutenção.
Perda de confiança
Clientes percebem lentidão.
Modernização mais cara
Quanto mais se espera, maior o esforço.
Erros clássicos
Ignorar pequenos warnings.
Adiar refatorações indefinidamente.
Não acompanhar indicadores.
Aceitar degradação como normal.
Tratar sintomas, nunca as causas.
Boas práticas
Cultura de melhoria contínua.
Observabilidade.
Métricas objetivas.
Revisões arquiteturais.
Testes automatizados.
Planejamento de redução da dívida técnica.
Compartilhamento de conhecimento.
O ensinamento do Oráculo
O Oráculo coloca uma panela sobre o fogo.
A água aquece lentamente.
Ela pergunta a Neo:
— Quando começou o problema?
Neo observa.
Não consegue responder.
Ela então diz:
"Os maiores desastres raramente começam com explosões. Eles começam com pequenos sinais que ninguém considera importantes."
Aplicabilidade
O Boiling Frog aparece em qualquer ambiente:
COBOL;
Java;
C#;
Python;
microsserviços;
APIs;
Kubernetes;
sistemas embarcados;
plataformas em nuvem;
DevOps.
Sempre que pequenas degradações deixam de ser tratadas, o risco cresce.
Lições para um Programador COBOL Padawan
Durante sua carreira, você ouvirá muitas frases como:
"Depois a gente otimiza."
"Esse warning é normal."
"Só mais um IF."
"É só mais uma exceção."
Nenhuma dessas decisões isoladamente destruirá um sistema.
Mas centenas delas, ao longo dos anos, podem transformar uma aplicação sólida em um ambiente extremamente caro, lento e difícil de evoluir.
Aprenda a valorizar pequenas correções.
Elas são muito mais baratas do que grandes reconstruções.
Conclusão — A Matrix Não Quebrou de Uma Vez
No universo Matrix, o colapso nunca aconteceu em um único instante. Pequenas anomalias foram se acumulando até que a própria simulação precisou ser reiniciada.
Na Engenharia de Software acontece exatamente o mesmo.
O antipadrão Boiling Frog ensina que o verdadeiro inimigo não é apenas o grande erro.
São os pequenos problemas aceitos diariamente.
Um warning ignorado.
Uma exceção temporária.
Uma rotina nunca otimizada.
Uma documentação adiada.
Um teste que "fica para depois".
Separadamente parecem inofensivos.
Juntos, transformam sistemas robustos em ambientes frágeis.
Para um Programador COBOL, especialmente no universo IBM Z, a maior habilidade não é apagar incêndios heroicamente.
É perceber quando a temperatura começou a subir.
No universo Bellacosa Mainframe existe uma máxima que Morpheus certamente repetiria aos novos Padawans:
"O caos raramente chega correndo. Ele costuma entrar silenciosamente, um pequeno problema de cada vez."
E aqueles que aprendem a enxergar esses pequenos sinais, assim como Neo passou a enxergar o código verde da Matrix, conseguem preservar sistemas por décadas sem permitir que a água chegue ao ponto de ebulição.
