☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta riscos. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta riscos. Mostrar todas as mensagens

sábado, 20 de junho de 2026

Quando a Auditoria Falha? O que Mainframes, COBOL e Quarenta Anos de Escândalos Financeiros nos Ensinam Sobre Confiança, Controles e a Ilusão da Segurança

 

Bellacosa Mainframe quando a auditoria falha

☕ Um Café no Bellacosa Mainframe

Quando a Auditoria Falha?

O que Mainframes, COBOL e Quarenta Anos de Escândalos Financeiros nos Ensinam Sobre Confiança, Controles e a Ilusão da Segurança

"No mundo do IBM Z aprendemos cedo uma lição: confiar é importante. Validar é obrigatório."

Durante mais de quarenta anos trabalhando com tecnologia para instituições financeiras, seguradoras e grandes empresas, existe uma pergunta que sempre volta.

Como empresas auditadas por gigantes da auditoria mundial conseguem quebrar praticamente da noite para o dia?

Como bancos supervisionados, empresas listadas em bolsa, organizações com conselhos de administração, comitês de auditoria, controles internos, departamentos de compliance, gestão de riscos, auditorias externas e milhares de funcionários conseguem esconder problemas gigantescos?

E mais intrigante ainda...

Por que poucos meses antes da quebra muitas delas recebiam pareceres sem ressalvas?

A pergunta inevitável aparece.

Existe conluio?

Ou simplesmente o modelo de auditoria possui limitações que poucas pessoas conhecem?

Hoje vamos conversar sobre isso sem teorias conspiratórias, mas também sem ingenuidade.


A ilusão da empresa "saudável"

Existe uma ideia bastante difundida.

Se uma empresa possui:

  • auditoria independente;

  • conselho de administração;

  • compliance;

  • gestão de riscos;

  • controles internos;

  • fiscalização do regulador;

  • balanços publicados;

então ela está segura.

Infelizmente isso nunca foi verdade.

Esses mecanismos reduzem riscos.

Eles não eliminam riscos.

Existe uma enorme diferença.


A auditoria não garante que uma empresa nunca irá quebrar

Este talvez seja o maior mal-entendido do mercado.

Uma auditoria não certifica que uma empresa é saudável.

Ela também não garante que não exista fraude.

Nem afirma que a empresa continuará existindo.

O parecer normalmente diz algo muito diferente.

Ele afirma, em essência, que as demonstrações financeiras representam adequadamente a posição patrimonial da empresa de acordo com determinadas normas contábeis.

Observe a diferença.

Uma coisa é afirmar que os números apresentados seguem as regras contábeis.

Outra completamente diferente é dizer que o negócio é sustentável.



Bellacosa Mainframe e a auditoria falhando

É como um programa COBOL

Imagine um sistema bancário.

O programa COBOL compila perfeitamente.

Não possui nenhum erro.

Passa em todos os testes.

Produz exatamente o resultado esperado.

Isso significa que o negócio do banco é lucrativo?

Não.

Significa apenas que o programa faz corretamente aquilo que foi especificado.

Auditoria funciona de maneira parecida.

Ela avalia evidências.

Não prevê o futuro.


O auditor trabalha com amostragem

Aqui está um detalhe que surpreende muita gente.

Auditores normalmente não verificam 100% das operações.

Isso seria praticamente impossível.

Imagine um banco.

Milhões de TEDs.

PIX.

Cartões.

Contratos.

Investimentos.

Empréstimos.

Aplicações.

Não existe tempo suficiente.

Então utiliza-se amostragem estatística.

É exatamente como testar um grande sistema COBOL.

Você executa milhares de casos de teste.

Não todos os bilhões possíveis.


O problema aparece quando alguém conhece o processo

Fraudes sofisticadas normalmente não acontecem por acaso.

Elas são planejadas.

Quem planeja conhece:

  • quando ocorre a auditoria;

  • quais documentos serão solicitados;

  • quais controles são testados;

  • quais processos possuem maior atenção.

Em outras palavras...

Conhece exatamente o radar.

E quando alguém conhece o radar, aprende a voar abaixo dele.


O caso Enron mudou o mundo

No início dos anos 2000 a Enron era considerada uma das empresas mais inovadoras do planeta.

Recebia prêmios.

Era elogiada por analistas.

As ações só subiam.

Até que tudo desmoronou.

Descobriu-se uma gigantesca engenharia financeira.

Empresas eram criadas apenas para esconder dívidas.

Prejuízos desapareciam.

Lucros apareciam artificialmente.

A empresa era auditada pela Arthur Andersen.

Uma das cinco maiores auditorias do mundo.

Depois do escândalo, a Arthur Andersen simplesmente deixou de existir.

Esse episódio mostrou que tamanho não significa infalibilidade.


WorldCom

Pouco depois veio outro choque.

A WorldCom.

Mais de 11 bilhões de dólares em fraudes contábeis.

Novamente...

Auditoria.

Controles.

Conselho.

Mercado.

Tudo parecia funcionar.

Até deixar de funcionar.


Parmalat

Na Itália ocorreu outro caso emblemático.

Bilhões em ativos simplesmente não existiam.

Extratos bancários falsificados.

Empresas ligadas.

Movimentações artificiais.

Durante anos ninguém percebeu.


Wirecard

Mais recentemente surgiu a Wirecard.

Empresa alemã.

Tecnologia financeira.

Queridinha do mercado.

Entrou no principal índice da bolsa alemã.

Depois descobriu-se que aproximadamente dois bilhões de euros em caixa simplesmente não existiam.

Nunca existiram.


Carillion

No Reino Unido.

Gigante da construção.

Recebia contratos públicos.

Parecia sólida.

Quebrou deixando milhares de funcionários e fornecedores prejudicados.


Banco Master

O caso do Banco Master chamou atenção justamente porque reacendeu um velho debate: como avaliar riscos antes que eles se tornem evidentes? Em situações assim, supervisão regulatória, auditoria independente, classificações de risco e demonstrações financeiras coexistem, mas nenhum desses mecanismos, isoladamente, garante que uma instituição esteja livre de problemas futuros. A deterioração pode ocorrer rapidamente quando há perda de confiança, mudanças no ambiente econômico ou fragilidades que ainda não eram visíveis ao mercado. O episódio reforçou que pareceres de auditoria não são uma "certidão de saúde eterna"; eles retratam informações e evidências disponíveis em determinado momento.


Lojas Americanas

O caso das Lojas Americanas impressionou pela dimensão das inconsistências contábeis reveladas em 2023, envolvendo bilhões de reais relacionados principalmente à contabilização de operações com fornecedores conhecidas como "risco sacado". O episódio gerou investigações, debates sobre governança, controles internos e o papel dos diversos agentes envolvidos. Para muitos investidores, a surpresa veio justamente porque a companhia possuía estrutura de governança, auditoria externa e acompanhamento do mercado, demonstrando que esses mecanismos reduzem riscos, mas não eliminam a possibilidade de erros ou fraudes sofisticadas.


Então existe conluio?

Agora chegamos à pergunta mais difícil.

A resposta honesta é:

Às vezes sim.

Na maioria das vezes, não há evidência disso.

Ao longo das últimas décadas houve casos em que auditores foram condenados por negligência.

Em outros, por participação direta.

Mas transformar todos os casos em uma grande conspiração seria intelectualmente desonesto.

O que realmente existe são conflitos de interesse estruturais.


Quem paga a auditoria?

Essa pergunta muda tudo.

Quem remunera a auditoria?

A própria empresa auditada.

Imagine.

Você é contratado pela empresa.

Recebe milhões.

Se perder aquele cliente...

Sua empresa perde receita.

Mesmo mantendo total ética profissional, essa estrutura cria uma tensão permanente entre independência técnica e interesse comercial.

É exatamente por isso que diversos países exigem regras rígidas sobre independência, rotação de sócios responsáveis, comitês de auditoria e limitações para prestação de serviços adicionais.


O problema dos serviços de consultoria

Historicamente muitas firmas de auditoria também vendiam consultoria.

Imagine.

Você desenha um processo.

Depois audita o próprio processo.

Existe um conflito evidente.

Após escândalos como Enron, diversas regras restringiram esse tipo de atuação.

Mesmo assim o debate permanece.


Existe captura psicológica

Nem toda perda de independência envolve dinheiro.

Existe algo chamado familiaridade.

Depois de quinze anos auditando a mesma empresa...

Você conhece todos.

Os diretores.

Os gerentes.

Os controladores.

As pessoas tornam-se amigas.

O senso crítico diminui naturalmente.

É um comportamento humano.


O Mainframe ensina uma filosofia diferente

Quem trabalha em IBM Z conhece um princípio simples.

Nunca confiar em uma única camada.

Existe RACF.

Existe SMF.

Existe JES.

Existe SDSF.

Existe RMF.

Existe LOG.

Existe trilha de auditoria.

Existe segregação de funções.

Existe dupla validação.

Existe controle de acesso.

Existe histórico.

Tudo conversa.

Tudo registra.

Tudo pode ser reconstruído.

Essa arquitetura não impede fraudes.

Mas aumenta enormemente o custo para quem tenta fraudar.


O COBOL também ensina

Um bom programa COBOL nunca assume que os dados estão corretos.

Ele valida.

Se o CPF vier inválido...

Erro.

Se a data vier impossível...

Erro.

Se o saldo ficar negativo...

Erro.

Se existir inconsistência...

Erro.

Confiar é pouco.

Validar sempre.


O mercado financeiro deveria aprender com o Mainframe

Imagine se cada operação financeira tivesse:

imutabilidade dos registros;

trilhas completas;

assinaturas criptográficas;

reconciliações automáticas;

logs independentes;

inteligência artificial procurando padrões anormais;

cruzamento contínuo de bases;

monitoramento em tempo real.

Grande parte das fraudes seria descoberta muito antes.

Aliás...

Grande parte dos grandes bancos já utiliza diversas dessas técnicas justamente em ambientes IBM Z.


O fator humano continua sendo o maior risco

Depois de milhares de incidentes tecnológicos aprendemos uma verdade.

Computadores raramente mentem.

Pessoas podem mentir.

O sistema registra exatamente aquilo que recebeu.

Se alguém envia informação falsa...

O computador processa informação falsa.

O famoso princípio:

Garbage In.

Garbage Out.


A auditoria do futuro

A tendência mundial já começou.

Sair da auditoria anual.

Entrar na auditoria contínua.

Monitoramento em tempo real.

Machine Learning.

Inteligência Artificial.

Análise de 100% das transações.

Não apenas amostras.

Blockchain para determinadas cadeias.

Data Lake.

Analytics.

Modelos preditivos.

É praticamente o equivalente à observabilidade moderna aplicada às finanças.


O papel da Inteligência Artificial

Nos próximos anos veremos IA analisando bilhões de lançamentos contábeis diariamente.

Ela não ficará cansada.

Não sofrerá pressão política.

Não esquecerá um documento.

Encontrará padrões invisíveis ao ser humano.

Mas existe um detalhe.

A IA também depende dos dados recebidos.

Se os dados forem deliberadamente falsificados na origem, até ela terá limitações.

Tecnologia melhora controles.

Não substitui ética.


A maior lição

Sempre que ocorre um grande escândalo financeiro surgem duas reações extremas.

A primeira.

"A auditoria é inútil."

A segunda.

"Foi uma conspiração."

As duas simplificam demais um problema complexo.

Auditorias são fundamentais.

Sem elas, provavelmente haveria muito mais fraudes.

Ao mesmo tempo, auditorias não são infalíveis.

São realizadas por pessoas.

Dentro de limites de tempo.

Custos.

Normas.

Amostragens.

Julgamentos profissionais.

E seres humanos erram.

Às vezes por incompetência.

Às vezes por excesso de confiança.

Às vezes por negligência.

E, infelizmente, em alguns casos, por corrupção.


O que o Mainframe nos ensina

Depois de décadas desenvolvendo sistemas para alguns dos maiores bancos do mundo, aprendi uma filosofia que continua atual.

Nunca concentre toda a confiança em um único mecanismo de controle.

No IBM Z existe defesa em profundidade.

Camadas sobre camadas.

Logs.

Controles.

Segregação.

Revisões.

Auditoria.

Monitoramento.

Recuperação.

Tudo coexistindo.

Essa mesma filosofia deveria orientar qualquer organização moderna.

Não basta confiar na auditoria externa.

É preciso combinar governança, controles internos robustos, auditoria interna independente, supervisão regulatória, tecnologia, cultura ética e monitoramento contínuo.

Nenhum desses elementos, sozinho, é suficiente. Juntos, porém, tornam a fraude muito mais difícil de ser praticada e, principalmente, muito mais rápida de ser descoberta.

Talvez essa seja a maior contribuição do universo Mainframe para o mundo corporativo.

No IBM Z nunca partimos do princípio de que alguém jamais tentará falhar ou fraudar um processo.

Partimos do princípio oposto: erros e tentativas de fraude podem acontecer. Por isso criamos sistemas resilientes, auditáveis e rastreáveis.

No fim das contas, a verdadeira segurança não nasce da confiança cega.

Ela nasce da capacidade permanente de verificar.

E essa talvez seja a maior lição que um velho programador COBOL pode deixar para a nova geração.

Porque, no Mainframe, confiança nunca substituiu evidência.

Se desejar, posso transformar este artigo em uma versão para LinkedIn (1.500–2.000 palavras), em uma apresentação de 15 slides ou em um infográfico estilo Bellacosa Mainframe.


quarta-feira, 19 de janeiro de 2022

💀💀💀 Zalgo uma pequena sabotagem na biblioteca FAKER.Js 💀💀💀

 


Bellacosa Mainframe e o virus Zalgo assuntando o mundo JS

Risco de Software? Sabotagem em código: Estudo do Caso Zalgo

Salve jovem padawan, hoje vamos comentar sobre um acontecimento quente que ocorreu nos últimos dias, mais precisamente por volta de 10 de janeiro, algo que nos faz parar, avaliar, analisar e pensar em todo o enredo.

No alt text provided for this image

Calma que explicarei, bombasticamente aconteceu uma alteração no código fonte de duas famosas bibliotecas em JavaScript, utilizada por milhares de desenvolvedores no mundo afora. Coisas de software livre e comunidade colaborativa.

Num primeiro momento foi uma sabotagem no código fonte, que gerou comportamento errático e anômalo em ambas as bibliotecas, que causou comoção na comunidade.

O que aconteceu na faker.js e colors.js?

No começo do ano vários desenvolvedores notaram uma situação anômala, semelhante há um vírus no funcionamento destas bibliotecas, que no decorrer da sua execução apresentavam uma mensagem no console, seguida de uma série de caracteres estranhos.

LIBERTY LIBERTY LIBERTY

No alt text provided for this image

Liberdade Liberdade Liberdade.

No alt text provided for this image

Inúmeros programas foram retirados de produção e backups foram utilizados para restaurar a versão anterior, deixando gerentes de TI e equipes muitíssimas preocupadas, seria apenas isso, ou existiria algum backdoor ou outra rotina maliciosa dentro das bibliotecas?

Por vias das dúvidas, os programas ficaram em quarentena, enquanto os especialistas em segurança avaliavam a ameaça e elaboravam relatórios de segurança.

O que é Faker.Js ?

É uma biblioteca utilizada para mockar dados em back-end utilizada especificamente para teste em apis, testes de carga e funcionamento de workflows com uma massiva criação de dados fake.

Podendo ser utilizado via instalação NPM ou Yarm, mas também referenciada em páginas HTML sendo muito útil para os desenvolvedores

O que é Colors.js?

É uma biblioteca de cores utilizada para front-end auxiliando o desenvolvimento de pagina parametrizando códigos de cores em CSS, HTML e aplicativos.

A história por trás do caos

Em teoria não existe nenhum risco nas Bibliotecas, os analistas de segurança correram a verificar e recomendaram a não utilização, pois a credibilidade ficou abalada, porem segundo algumas fontes não ocorreu nenhuma invasão ou ataque de crackers.

A princípio a comunidade DEV creditou a cyberpiratas ou mesmo trolls, que poderiam usar uma quebra de senha e infiltrando-se na comunidade para inserir vírus, worms, trojans e outros malwares num código amplamente utilizado por milhões de programadores em milhares de empresas.

Mas na verdade foi um ato de anarquia digital, onde o próprio autor fez um manifesto de revolta e honrou a memória de uma vítima dos abusos policial, sendo vítima de um golpe kafkiano.

Investigando o fonte

Uma análise no código de ambas as bilbiotecas encontrou uma explicação no arquivo README.TXT do projeto, estava uma questão: o que realmente aconteceu com Aaron Swartz?”

https://github.com/Marak/faker.js

O grande Aaron Swartz

No alt text provided for this image

Estou me referindo ao grande programador e hackativista pro-SOPA, em vida participou ativamente em diversos projetos open-source, auxiliou na criação e melhorias no RSS, no markdown.

Acabou sendo vítima de uma armadilha do FBI e acabou sendo processado correndo o risco de pegar até 30 anos de cadeia, mas devido as suas habilidades como programador, queriam agenciar seu trabalho e faze-lo renegar o seu ativismo, levando-o para o lado negro da força, sendo que se aceitasse comutaria sua pena de prisão para apenas 6 meses.

Declarando-se inocente, não aceitou o acordo com a promotoria e como último ato nesta tragédia tirou a própria vida, enforcando-se no dia 11-01-2013, mas não vendendo-se.

O principal suspeito

Após análises preliminares foi constatado que não houve invasão e o código estava seguro, sendo que o autor da pichação virtual foi Marak Squires, o responsável pelo código malicioso, sendo que ele é o autor de ambas as bibliotecas.

O ato e a tragédia

Afinal o Zalgo não causou danos a ninguém, apenas assustou a comunidade pegando as empresas de segurança de software de surpresa, afinal o uso de bibliotecas de terceiros é um furo de segurança.

Podendo ser explorado por crackers para no futuro usa-las como cavalos de troia e adentrarem CPDs de empresas importantes.

A princípio as políticas de segurança devem ser revistas e todo software open-source devem ser utilizados com atenção.

O que é zalgo?

Hoje apresentei inúmeros termos novos, vamos explorar um outro termo, comum na Deep Web, Zalgo, também conhecido como Z'algatoth, originalmente era um meme oriundo do site de discussão e compartilhamento de imagens Something Awful criado pelo usuário Shmork pseudônimo de Dave Kelly), que acabou se tornando um personagem significativo dentre a comunidade de creepypastas e migrou para inúmeras redes sociais.

Cyber protestos

A cada dia surge uma nova maneira dos cyberativistas se pronunciarem e compartilhar com toda a comunidade seu ponto de vista e lançar memória de uma grande pessoa vítima do sistema, Swartz foi um gênio e imagine o quando poderia ter produzido se sua vida não tivesse sido abreviada, convido a todos a lerem sua biografia no Wikipédia.

Uma comunidade atuante

Se gosta de programar convido-o a explorar o GITHUB, que existem inúmeras comunidades que trabalham para o bem comum, codificando ferramentas para auxiliar a produtividade e criar apps livres e sem licenças.

Muitas pessoas ficaram indignadas com os administradores do GitHub por terem suspenso a conta de Squires, afinal de contas, ele nao fez nenhum ato indevido, afinal o código era dele e o repositório idem, nao prejudicou ninguém apenas gerou muita repercussão e fez a comunidade parar, pensar e homenagear a memoria de um grande Dev.

Conclusão

Caro padawan hoje o tiozão apresentou mais um caso curioso no mundo da informática, quem conhece alguns dos temas abordados e quiserem aproveitar para enriquecer nosso artigo, fiquem a vontade e deixem nos comentários.

Eu particularmente fiquei muito emocionado na sigila homenagem e ao mesmo tempo protesto bem-humorado, que deixou muita gente de cabelo em pé.

Espero ter ajudado, lembre-se que é um trabalho continuo.


No alt text provided for this image


Mais momento jabá, para distrair, uma visita a Araraquara, num insólito posto de gasolina, onde o Batman e seu grande fan, criaram inúmeras atrações para ser explorado, para a alegria de miúdos e graúdos, e se tiverem um pouco de sorte poderão dar uma volta no Bat-movel, visite meu vídeo e veja para onde fui desta vez:


Pode me dar uma ajudinha no YouTube?


Artigo original : https://web.dio.me/articles/zalgo-uma-pequena-sabotagem-bibliotecas-na-fakerjs?back=%2Farticles&open-modal=true&page=1&order=oldest

terça-feira, 23 de novembro de 2021

Boiling Frog Rules : Quando um Programador COBOL Descobriu que a Matrix Não Caiu de Uma Vez… Ela Foi Esquentando Até Ninguém Perceber o Colapso

 

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.


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...