☕ 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 Probabilidade. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Probabilidade. Mostrar todas as mensagens

domingo, 23 de agosto de 2026

Os Números Malditos, o Efeito VEJA e Um Milhão de Chimpanzés

 

Bellacosa Mainframe e como um sonho cria uma bola de neve 

☕ Um Café no Bellacosa Mainframe

Os Números Malditos, o Efeito VEJA e Um Milhão de Chimpanzés

Ou: como acordei irritado com uma estação da CPTM, tentei roubar seis números do meu próprio sonho, tropecei em Lost e descobri que, quando humanos, imprensa, algoritmos e probabilidade trabalham juntos, até uma coincidência aprende a se reproduzir


Há pesadelos em que você corre de monstros.

Há pesadelos em que alguma criatura de dentes enormes tenta arrancar sua cabeça.

Há também aqueles em que o elevador despenca, o avião cai, o morto levanta da sepultura ou alguma entidade vestida de branco aparece no corredor dizendo coisas desagradáveis em latim.

Meus pesadelos aparentemente têm orçamento menor.

Neles, a CPTM está em obras.

E, curiosamente, isso consegue ser muito pior.

Na madrugada de hoje acordei de um daqueles sonhos que meu cérebro parece produzir com um estranho compromisso com a coerência. Não havia demônio, zumbi ou alienígena.

Eu estava numa casa que, por alguma razão que somente a geografia dos sonhos conhece, sabia estar na Zona Leste de São Paulo.

Havia uma mulher que não consegui identificar.

Tivemos uma discussão banal.

Peguei uma mala e fui embora.

Até aí, meu cérebro aparentemente considerou tudo tão desinteressante que quase não guardou a cena.

O filme começa mesmo quando entro num trem rumo ao Brás/Roosevelt.

Estou com uma mala de viagem.

Dentro do vagão, alguém tenta se aproximar usando aquilo que nos filmes seria clorofórmio ou alguma substância semelhante para me apagar.

Percebo.

Reajo.

Não entro numa briga cinematográfica.

O sujeito foge.

Eu continuo.

Já bastante nervoso, desço numa estação decadente que lembrava enormemente a antiga Carlos de Campos.

Só que não era Carlos de Campos.

Era uma daquelas maravilhas arquitetônicas que existem exclusivamente dentro do cérebro adormecido.

A estação possuía uma bifurcação que permitiria pegar outra linha.

A estação estava em obras.

Havia escada quebrada.

Escada rolante desligada.

Passagens improvisadas.

Fluxos de passageiros indo para lugares que não eram o lugar para onde eu queria ir.

Seguindo as pessoas, terminei na plataforma errada.

Voltei.

Para voltar à linha correta, por alguma razão burocraticamente perfeita para um pesadelo ferroviário, tive de sair da estação para entrar novamente na estação.

Foi quando apareceu um taxista com aquela aparência que, em qualquer filme razoável, faria o espectador berrar:

NÃO ENTRE NESSE CARRO.

Ele se ofereceu para me levar.

Recusei.

Comecei a subir uma escada.

E acordei.

Não apavorado.

Irritado.

Com o peito apertado e aquela maravilhosa sensação de que alguém havia desenvolvido um sistema de transporte público especificamente para me contrariar.



🧠 O sexto dedo do sonho

Depois que a tensão física passou, comecei a perceber uma característica recorrente dos meus sonhos.

Meu cérebro tolera coisas absurdas.

Mas não gosta de coisas incoerentes.

Um trem pode levar a uma estação inexistente.

Tudo bem.

Uma estação pode ser uma mistura de três estações diferentes.

Aceitável.

Pode haver uma bifurcação ferroviária impossível.

Continue o filme.

Mas chega determinado momento em que algo viola as regras que o próprio sonho estabeleceu.

E então acontece aquela sensação hoje bastante familiar para quem já viu imagens produzidas pelas primeiras gerações de inteligência artificial.

Você olha para uma pessoa.

Está tudo certo.

Olha novamente.

Seis dedos.

Ops.

Alguma coisa que parecia plausível deixou de passar pelo verificador interno.

Meu cérebro parece executar uma espécie de:

CONTINUITY_CHECK

Enquanto o roteiro passa, continuo dormindo.

Quando alguma coisa falha:

WARNING: WORLD MODEL INCONSISTENCY

E então:

WAKE USER

É quase um watchdog noturno.

O mais engraçado é que esse mesmo mecanismo aparece em outro tipo de sonho que tenho com alguma frequência.

O sonho da loteria.



🎰 Eu ganhei! Agora me mostre os malditos números

Já sonhei muitas vezes que ganhei na loteria.

Não uma.

Não duas.

Dezenas.

E existe uma regra extraordinariamente persistente nesse universo:

eu posso saber que ganhei, mas nunca consigo acessar os seis números.

Às vezes estou diante da televisão.

Vejo dois números sorteados.

Sei que os outros correspondem ao meu bilhete.

Pulo de alegria.

Tento olhar novamente.

O sonho não mostra.

Em outra versão estou no banco.

Entrego o comprovante.

O gerente pega o canhoto para conferir.

Eu sei que está premiado.

Mas justamente o pedaço de papel que interessa desaparece das minhas mãos.

Em outra narrativa nem existe sorteio.

Eu simplesmente já sou rico.

Falo sobre o bilhete vencedor.

Comento que acertei os números.

A história inteira aceita como fato incontestável que ganhei uma fortuna.

Só existe um pequeno detalhe:

ninguém informa quais eram os números.

É como se meu cérebro mantivesse:

STATUS_APOSTA = PREMIADA
VALOR = MILHÕES
NUMEROS = ACCESS DENIED

E há uma possível explicação menos sobrenatural e muito mais divertida.

Para sonhar que ganhei, meu cérebro não precisa gerar uma combinação.

Ele precisa apenas gerar o conceito:

GANHEI.

Assim como uma inteligência artificial pode produzir uma fotografia convincente de um homem segurando um jornal sem necessariamente possuir um texto coerente para cada coluna daquela página.

Enquanto observo a imagem global, funciona.

Quando tento ler as letras...

seis dedos.

Meu problema começa quando, ainda dentro do sonho, surge um pouco de metacognição:

“Espere. Preciso decorar esses números para jogar quando acordar.”

Nesse instante deixo de ser apenas personagem.

Viro auditor.

Estou tentando fazer exfiltração de dados entre o ambiente DREAM e o ambiente WAKE.

E aparentemente existe um firewall.



🏝️ Então aparecem 4, 8, 15, 16, 23 e 42

E foi aí que a conversa entrou em território Lost.

Quem acompanhou a série certamente reconhece:

4 — 8 — 15 — 16 — 23 — 42

São os famosos números que perseguem a trama e, principalmente, Hugo “Hurley” Reyes.

Na ficção, Hurley utiliza a sequência numa loteria e fica milionário.

Depois passa a acreditar que os números são amaldiçoados porque acontecimentos terríveis começam a cercá-lo.

Para o universo de Lost, os números eram muito mais do que números.

Para a cultura popular também acabaram deixando de ser.

Milhões de espectadores assistiram à série entre 2004 e 2010.

Milhões viram a sequência repetida.

Parte deles decorou.

Parte passou a brincar com ela.

E parte fez aquilo que qualquer Homo sapiens diante de uma sequência associada a uma loteria acabaria fazendo:

apostou.

E continuou apostando.

Ano após ano.



🇺🇸 Quando os números atravessaram a televisão

Em 4 de janeiro de 2011 aconteceu uma pequena travessura estatística nos Estados Unidos.

O Mega Millions sorteou:

4 — 8 — 15 — 25 — 47

com 42 como Mega Ball.

Ou seja, quatro dos famosos números associados a Lost apareceram no mesmo sorteio.

Não era a sequência completa.

Não havia profecia.

Nenhuma ilha saiu navegando pelo Pacífico.

Mas para uma cultura que já tinha atribuído significado a:

4 — 8 — 15 — 16 — 23 — 42

aquilo era irresistível.

A coincidência passou a fazer parte da própria história dos números.

Agora eles não eram apenas:

“os números que aparecem em Lost.”

Também eram:

“os números de Lost que quase apareceram numa loteria real.”

Uma nova camada narrativa havia sido adicionada.

E a banana passou para outro chimpanzé.



🇧🇷 Então o Brasil resolveu melhorar a piada

No dia 4 de maio de 2024, concurso 2720 da Mega-Sena, saíram:

08 — 15 — 16 — 23 — 42 — 43.

Agora coloque ao lado:

Lost:
04 — 08 — 15 — 16 — 23 — 42

Mega-Sena:
08 — 15 — 16 — 23 — 42 — 43

Cinco.

Cinco dos seis.

O universo colocou 43 onde todo fã esperava encontrar 04.

Isso sozinho já seria suficiente para alimentar memes por algumas semanas.

Mas a história ficou melhor.

Ninguém acertou as seis dezenas.

Porém 2.967 apostas acertaram a quina, recebendo R$ 1.878,49 cada. Houve ainda 6.884 acertadores da quadra.

Não temos como afirmar que os 2.967 ganhadores estavam jogando deliberadamente números de Lost.

Mas o número excepcional de quinas ilustra perfeitamente uma diferença fundamental:

o sorteio pode ser aleatório.

As escolhas humanas não são.



🐒 Chamem os chimpanzés

E aqui entram nossos velhos conhecidos.

Um milhão de chimpanzés.

A metáfora clássica diz que um macaco pressionando teclas aleatoriamente durante tempo suficiente poderia eventualmente produzir uma obra de Shakespeare.

É claro que o universo real contém limitações físicas que tornam a versão literalmente infinita uma brincadeira matemática.

Mas a ideia é poderosa:

quando aumentamos brutalmente o número de tentativas, eventos individualmente improváveis começam a aparecer.

Não porque ficaram menos improváveis por tentativa.

Mas porque criamos oportunidades suficientes para que ocorram.

Imagine jogar uma moeda.

Dar dez caras consecutivas parece impressionante.

Agora imagine bilhões de sequências de dez lançamentos acontecendo ao redor do planeta.

Em algum lugar, alguém obterá dez caras.

Talvez onze.

Talvez vinte.

E provavelmente haverá alguém filmando justamente aquela sequência e publicando:

VOCÊ NÃO VAI ACREDITAR NO QUE ESSA MOEDA FEZ.



📊 Mas atenção: isso não é exatamente a Lei dos Grandes Números

Aqui vale não maltratar a matemática em nome de uma boa história.

A Lei dos Grandes Números diz, simplificando, que conforme repetimos muitas vezes um experimento independente nas mesmas condições, a média observada tende a se aproximar de seu valor esperado.

Jogue uma moeda equilibrada poucas vezes e pode obter 8 caras e 2 coroas.

Jogue milhões de vezes e a proporção tende a ficar próxima de 50% para cada lado.

Isso não significa que “quanto mais jogamos, mais qualquer coisa impossível precisa acontecer”.

O fenômeno dos nossos chimpanzés está ligado a outra ideia:

eventos raros acumulam oportunidades de ocorrência quando multiplicamos o número de tentativas.

Se um evento tem probabilidade p de acontecer numa tentativa, a probabilidade de ele não acontecer em n tentativas independentes é:

(1 - p)^n

Portanto, a probabilidade de acontecer pelo menos uma vez é:

1 - (1 - p)^n

Quando n cresce muito, coisas muito raras deixam de parecer tão extraterrestres.

Isso é o coração matemático dos nossos chimpanzés.



🎲 “Mas as combinações são bilhões!”

E é justamente aí que nosso cérebro tropeça.

Imagine uma loteria produzindo:

07 — 12 — 26 — 37 — 49 — 58

Você provavelmente olha e diz:

“Tá.”

Agora imagine:

04 — 08 — 15 — 16 — 23 — 42

E imediatamente:

MEU DEUS, LOST PREVIU A LOTERIA!

Só existe um problema.

Antes do sorteio, aquela primeira combinação também era extraordinariamente improvável.

Cada combinação específica válida possui a mesma chance de ser sorteada, supondo um sorteio ideal.

O que muda não é a matemática do sorteador.

É a matemática da nossa atenção.

A combinação aleatória não significa nada.

A sequência de Lost chega ao sorteio carregando vinte anos de bagagem cultural.

É uma celebridade numérica.



👁️ O cérebro não procura probabilidades. Procura histórias.

E isso nos traz de volta ao meu sonho.

Nosso cérebro é extraordinário em detectar padrões.

Foi extremamente útil durante nossa evolução.

Um ruído repetido no mato poderia significar predador.

Uma alteração nas nuvens poderia anunciar chuva.

Pegadas poderiam indicar caça.

Frutas amadureciam em determinadas épocas.

Sobreviver frequentemente significava perceber regularidades antes dos outros.

Só que o detector não veio acompanhado de um botão:

“não gerar falso positivo.”

Encontramos rostos nas nuvens.

Animais em manchas de parede.

Significados em coincidências.

Sequências em resultados aleatórios.

E quando já conhecemos uma sequência como:

4 — 8 — 15 — 16 — 23 — 42

nosso cérebro funciona como um mecanismo de busca configurado com uma consulta permanente.

Apareceu 8.

Nada.

Apareceu 8, 15.

Hmm.

8, 15, 16.

Espera.

8, 15, 16, 23, 42.

ALARME GERAL.



📰 E então entra o Efeito VEJA

Chamamos em nossas conversas de Efeito VEJA um fenômeno que não pretende ser uma nova lei acadêmica, mas funciona muito bem como metáfora.

A imprensa não apenas registra fatos.

Ela também aumenta sua superfície cultural.

Publicar significa criar:

um título;

uma página;

uma URL;

uma descrição;

palavras-chave;

links;

citações;

republicações;

comentários;

posts;

prints;

discussões;

memes;

resultados de busca.

Algo que talvez tivesse sobrevivido por algumas horas como curiosidade passa a ter persistência documental.

A matéria diz:

“Olhe que coincidência extraordinária.”

Mil pessoas olham.

Cem compartilham.

Dez escrevem novamente.

Outros veículos publicam.

Google indexa.

Redes sociais distribuem.

Anos depois alguém pesquisa.

A matéria reaparece.

Novo artigo.

Nova publicação.

Novo crawler.

Novo índice.

Nova banana.


🍌 A imprensa descreve o meme e alimenta o meme

Aqui acontece algo maravilhoso.

Uma matéria afirma:

“As pessoas continuam jogando os números de Lost.”

Alguém que nunca pensou em jogar aqueles números lê.

Agora conhece:

4 — 8 — 15 — 16 — 23 — 42

No próximo sorteio resolve brincar:

“Vou apostar os números de Lost.”

Ou seja:

a imprensa observa que a cultura mantém determinada sequência viva e, ao informar que ela continua viva, ajuda a mantê-la viva.

O observador participa do fenômeno.

Não porque altere as bolas dentro do globo da Mega-Sena.

Mas porque altera aquilo que seres humanos colocam nos bilhetes.

A loteria permanece aleatória.

A população de apostas ganha estrutura.




🐒🐒🐒 UM MILHÃO DE CHIMPANZÉS RECEBE INTERNET

Agora aumente a escala.

Não temos realmente um milhão de macacos digitando.

Temos algo muito mais eficiente.

Bilhões de pessoas.

Bilhões de smartphones.

Bilhões de buscas.

Milhões de matérias.

Redes sociais.

YouTube.

TikTok.

Blogs.

Fóruns.

Wikipedia.

Arquivos de jornais.

Modelos de inteligência artificial.

Crawlers.

Sistemas de recomendação.

Cada um executando pequenas operações de:

encontrar → reconhecer → copiar → relacionar → publicar → encontrar novamente.

O velho teorema do macaco infinito ganhou datacenter.



🤖 E os chimpanzés agora treinam máquinas

Aqui surge uma camada que Shakespeare certamente não previu.

Toda vez que uma coincidência culturalmente interessante é documentada, ela aumenta a possibilidade de ser recuperada futuramente por sistemas automatizados.

Uma pessoa escreve sobre Lost.

Outro portal referencia.

Um blog comenta.

Um buscador indexa.

Uma IA encontra textos durante treinamento ou recuperação de informações.

Anos depois alguém pergunta:

“Alguma vez os números de Lost apareceram numa loteria?”

E a máquina responde.

Isso aumenta novamente a circulação da história.

Estamos criando uma espécie de memória cultural assistida por máquinas.

A Internet não esquece perfeitamente.

Mas esquece muito menos eficientemente do que uma conversa de bar.



♻️ O ciclo completo

Podemos representar nosso balaio de gato assim:

FICÇÃO

Lost cria números memoráveis.

↓

MEMÓRIA HUMANA

Milhões de espectadores decoram.

↓

COMPORTAMENTO

Parte deles começa a apostar.

↓

ALEATORIEDADE

Milhares de sorteios acontecem durante décadas.

↓

COINCIDÊNCIA

Alguns números aparecem juntos.

↓

RECONHECIMENTO DE PADRÃO

Humanos percebem imediatamente.

↓

IMPRENSA

A coincidência vira notícia.

↓

BUSCADORES E ALGORITMOS

A notícia é indexada e recomendada.

↓

CULTURA POPULAR

Novas pessoas conhecem os números.

↓

COMPORTAMENTO

Algumas passam a apostar.

↓

NOVOS SORTEIOS

Mais oportunidades.

↓

🐒🍌

E voltamos ao começo.



🔥 A verdadeira maldição dos números

Existe uma ironia maravilhosa na história de Hurley.

Na série, os números seriam amaldiçoados porque teriam atraído acontecimentos terríveis.

No mundo real existe uma “maldição” muito mais interessante.

Suponha que algum dia uma loteria compatível sorteie exatamente:

04 — 08 — 15 — 16 — 23 — 42

Você acertou.

Começa a gritar.

Abraça o cachorro.

Liga para a família.

Abre champanhe.

Já está escolhendo uma Ferrari.

Então descobre:

milhares de outras pessoas fizeram exatamente a mesma aposta.

O prêmio precisa ser dividido.

Os números não seriam amaldiçoados porque possuem menos chance de sair.

Teriam exatamente a mesma probabilidade que qualquer combinação específica.

A maldição está do outro lado:

muita gente escolheu a mesma combinação.

Hurley estaria certo pelo motivo errado.



🧮 O improvável não é necessariamente inexplicável

Existe uma frase perigosa:

“Qual era a chance disso acontecer?”

Porque normalmente estamos calculando a probabilidade depois de saber o que aconteceu.

Qual era a chance de cinco números de Lost aparecerem naquele concurso específico?

Interessante.

Mas precisamos perguntar também:

Quantas loterias existem?

Quantos sorteios aconteceram desde 2004?

Quantas sequências famosas existem na cultura popular?

Quantos filmes possuem números?

Quantos aniversários famosos?

Quantas datas históricas?

Quantos padrões estamos dispostos a reconhecer?

Quantas pessoas estão procurando?

Quantas matérias serão escritas quando alguma delas encontrar algo?

Quando multiplicamos tudo isso, nosso zoológico de chimpanzés cresce enormemente.

Eventos improváveis continuam improváveis individualmente.

Mas algum evento extraordinariamente interessante acontecer deixa de ser tão extraordinário.



🎯 O alvo pintado depois do tiro

Imagine uma parede enorme.

Disparo aleatoriamente cem tiros.

Depois desenho um círculo ao redor do grupo mais interessante e digo:

“Incrível! Olhe como acertei o alvo!”

Fazemos isso mentalmente o tempo todo.

Só que Lost oferece uma situação mais sofisticada porque o alvo já estava parcialmente pintado antes do sorteio.

Os números eram famosos antes de 2024.

Isso torna a coincidência genuinamente divertida.

Mas ainda não a torna sobrenatural.

Temos um evento previamente reconhecível ocorrendo dentro de um universo enorme de tentativas.

É exatamente o tipo de coisa que nossos chimpanzés eventualmente encontram.



🌙 E voltamos ao sonho

Agora imagine a cena.

Estou novamente dormindo.

No sonho, ganhei a Mega-Sena.

Desta vez lembro da nossa conversa.

Em vez de tentar olhar seis números de uma vez, começo um protocolo de engenharia reversa.

Primeiro número.

Olho.

Memorizo.

Olho novamente.

Segundo.

Repito.

Terceiro.

Quarto.

Quinto.

Sexto.

Consigo acordar.

Pego o bloco ao lado da cama.

Escrevo:

04 — 08 — 15 — 16 — 23 — 42

Fico dez segundos olhando.

E começo a xingar.

Porque depois de décadas em que meu cérebro se recusou terminantemente a liberar os números da loteria, quando finalmente consigo explorar a vulnerabilidade...

ele me entrega os números de Lost.



😂 O universo também conhece trolling

Talvez essa seja a conclusão mais adequada.

Não precisamos acreditar que sonhos preveem sorteios.

Não precisamos acreditar que Lost previa a Mega-Sena.

Não precisamos imaginar números amaldiçoados.

Não precisamos convocar física quântica, Nostradamus, alienígenas, Illuminati ou um programador da Dharma Initiative escondido no subsolo da Caixa Econômica Federal.

Temos ingredientes suficientes:

um cérebro viciado em padrões;

uma cultura que transforma padrões em símbolos;

milhões de pessoas repetindo esses símbolos;

sistemas aleatórios realizando milhões de tentativas;

uma imprensa especializada em destacar acontecimentos interessantes;

buscadores que não deixam as histórias morrerem;

algoritmos que as apresentam novamente;

e milhões de chimpanzés digitais trabalhando em turnos de 24 horas.

O resultado inevitável é um mundo onde coincidências começam a parecer mensagens.



☕ Epílogo — A banana, o bilhete e a quarta parede

Talvez nossa maior dificuldade com probabilidades seja aceitar uma verdade pouco cinematográfica:

coisas absurdamente improváveis acontecem todos os dias.

Não necessariamente porque o universo esteja tentando falar conosco.

Mas porque todos os dias oferecemos ao universo uma quantidade absurda de oportunidades.

Bilhões de pessoas acordam.

Sonham.

Escolhem números.

Pegam trens.

Tiram fotografias.

Jogam loteria.

Publicam textos.

Assistam séries.

Digitam buscas.

Reconhecem padrões.

Contam histórias.

E quando uma dessas histórias encaixa perfeitamente...

paramos tudo.

Apontamos.

Chamamos os amigos.

Publicamos.

A imprensa publica.

Google indexa.

Uma inteligência artificial aprende que aquilo existe.

Vinte anos depois alguém encontra novamente.

E outro chimpanzé pega a banana.

Talvez seja exatamente isso que torne a sequência de Lost tão fascinante.

Os números não precisam estar vivos.

Nós é que continuamos ressuscitando-os.

Não existe maldição matemática conhecida em:

4 — 8 — 15 — 16 — 23 — 42.

Existe memória.

Existe repetição.

Existe significado.

Existe probabilidade.

Existe imprensa.

Existe algoritmo.

E existe nossa incapacidade deliciosamente humana de ver cinco números conhecidos saírem de uma máquina e simplesmente dizer:

“Coincidência interessante.”

Não.

Precisamos contar para alguém.

E ao contar...

acabamos de garantir que os números sobrevivam por mais uma geração.

🐒🍌

E em algum lugar, dentro de algum sonho futuro, provavelmente haverá um gerente de banco segurando meu bilhete vencedor e dizendo:

— Senhor Bellacosa, realmente ganhou.

— Excelente. Posso ver os números?

— Não.

— Por quê?

— Política do sistema.

Acordo irritado.

Como sempre.

Para ir mais longe



https://eljefemidnightlunch.blogspot.com/2026/08/a-lei-seca-do-algoritmo-ou-como-comecei.html

https://eljefemidnightlunch.blogspot.com/2026/08/quando-ia-entra-na-espiral-da-formiga.html

https://eljefemidnightlunch.blogspot.com/2026/08/red-team-de-boteco-quando-o-usuario.html

https://eljefemidnightlunch.blogspot.com/2026/08/spy-vs-spy-no-tribunal-as-trapacas.html

https://eljefemidnightlunch.blogspot.com/2026/08/red-team-e-os-doze-trabalhos-de-asterix.html

https://eljefemidnightlunch.blogspot.com/2026/08/antes-do-chatgpt-tinha-biblioteca-nao.html

https://eljefemidnightlunch.blogspot.com/2026/08/o-milhao-de-chimpanzes-gutenberg-e.html

https://eljefemidnightlunch.blogspot.com/2026/08/organizacoes-tabajara-mainframe-seus.html

https://eljefemidnightlunch.blogspot.com/2025/08/o-paradoxo-da-denuncia-quando-avisar.html

https://eljefemidnightlunch.blogspot.com/2026/08/os-numeros-malditos-o-efeito-veja-e-um.html



domingo, 4 de agosto de 2024

O Sysprog Bayesiano: por que um veterano vê um S0C7 e já começa a atualizar probabilidades na cabeça

 

Bellacosa Mainframe e o sysprog bayesino

☕ Um Café no Bellacosa Mainframe

O Sysprog Bayesiano: por que um veterano vê um S0C7 e já começa a atualizar probabilidades na cabeça

🧙‍♂️ Bayes, troubleshooting, observabilidade, dumps, experiência e o estranho fenômeno pelo qual trinta anos de produção transformam “acho que é isso” numa distribuição de probabilidades ambulante

Existe um fenômeno curioso nos CPDs.

Você coloca um programador iniciante diante de uma mensagem:

ABEND S0C7

Ele olha para a tela.

A tela olha para ele.

Durante alguns segundos acontece uma negociação diplomática silenciosa.

Então vem a primeira conclusão:

— O MAINFRAME QUEBROU.

Nesse instante, vindo de algum ponto escuro da sala, aparece um veterano carregando café.

Ele nem senta.

Olha para o código.

Olha para o dump.

Pergunta:

— Em qual instrução?

— Aqui.

— Qual campo?

— WS-VALOR.

— De onde veio?

— Arquivo.

— Mudaram o layout ontem?

Silêncio.

Alguém responde:

— Talvez.

O veterano toma um gole.

— Então começa por aí.

O jovem fica perplexo.

Como aquele sujeito chegou a uma hipótese em vinte segundos?

Telepatia?

Magia?

Décadas respirando ar reciclado de CPD?

Ele nasceu com um SYS1.LOGREC dentro do cérebro?

Não.

O que aconteceu foi muito mais interessante.

Sem perceber, o veterano acabou de executar uma espécie de inferência bayesiana humana.

Ele recebeu uma evidência.

Atualizou probabilidades.

Recebeu outra.

Atualizou novamente.

Eliminou hipóteses improváveis.

Aumentou o peso das plausíveis.

E começou a procurar onde havia maior chance de encontrar o defeito.

Ele talvez nunca tenha escrito:

P(H|E)

num quadro.

Mas passou quarenta anos fazendo exatamente isso.

Pegue o café.

Hoje vamos descobrir por que todo bom profissional de troubleshooting acaba virando, em algum grau, um Bayesiano de produção.


Capítulo I — Antes de falarmos de Bayes, precisamos quebrar alguma coisa

Vamos montar nosso pequeno desastre.

Programa COBOL:

WORKING-STORAGE SECTION.

01 WS-VALOR      PIC 9(7)V99.
01 WS-QUANTIDADE PIC 9(5).

PROCEDURE DIVISION.

    COMPUTE WS-TOTAL =
        WS-VALOR * WS-QUANTIDADE.

O programa funcionava havia meses.

Numa bela terça-feira às 10h37:

SYSTEM COMPLETION CODE=0C7

Pronto.

Produção abriu chamado.

O gerente pergunta:

— O que aconteceu?

Resposta tecnicamente perfeita:

— Tivemos um S0C7.

Gerente:

— E o que significa?

— Data exception.

Gerente:

— E o que significa?

— Temos algum dado incompatível com uma operação decimal.

Gerente:

— E o que significa?

— Alguma coisa está errada.

Gerente:

— Excelente. Vou informar à diretoria.

Troubleshooting começou.


Capítulo II — O iniciante vê possibilidades; o veterano vê probabilidades

Quando recebemos apenas:

S0C7

existem várias causas possíveis.

Talvez:

  • um campo numérico tenha caracteres inválidos;

  • um layout esteja incorreto;

  • tenha ocorrido deslocamento de dados;

  • um campo packed decimal esteja corrompido;

  • uma área tenha sido sobrescrita;

  • um programa esteja utilizando definição diferente do arquivo;

  • uma alteração recente tenha introduzido inconsistência;

  • o offset esteja apontando para uma rotina específica;

  • exista problema em dados provenientes de outro sistema.

O programador iniciante pensa:

“Pode ser qualquer coisa.”

O veterano pensa:

“Pode ser muita coisa, mas algumas são muito mais prováveis que outras.”

Essa diferença é gigantesca.

O iniciante possui um conjunto:

H1 H2 H3 H4 H5 H6 H7 H8...

O veterano possui algo parecido com:

H1  45%
H2  25%
H3  12%
H4   8%
H5   5%
outros...

Esses números não estão escritos conscientemente.

Provavelmente nem são números precisos.

Mas existe uma ordenação implícita das hipóteses.

Isso é experiência.


Capítulo III — Entre Thomas Bayes carregando café

Thomas Bayes foi um matemático e ministro presbiteriano britânico do século XVIII.

Séculos depois, sem jamais imaginar CICS, COBOL, Db2 ou alguém chamando às três da manhã porque “o batch parou”, seu nome ficaria associado a uma das ideias mais poderosas da estatística:

quando recebemos nova evidência, devemos atualizar aquilo que acreditávamos anteriormente.

De maneira clássica:

P(A|B) = P(B|A) × P(A) / P(B)

Não fuja.

Vamos traduzir isso para português de CPD.

A é uma hipótese.

Por exemplo:

“O S0C7 foi causado por dado não numérico vindo do arquivo de entrada.”

B é uma evidência.

Por exemplo:

“O erro começou exatamente depois de uma alteração no layout desse arquivo.”

Bayes pergunta:

sabendo dessa nova evidência, quanto devo aumentar ou diminuir minha confiança na hipótese?

Pronto.

Você acabou de fazer estatística.

Pode guardar a calculadora.


Capítulo IV — O prior: aquilo que você acreditava antes de olhar o dump

Antes de receber qualquer evidência específica, você já possui alguma noção sobre quais causas são comuns.

Isso é chamado de prior probability, ou probabilidade a priori.

Imagine mil incidentes históricos de S0C7.

Hipoteticamente:

dados inválidos             45%
layout incompatível         25%
área sobrescrita            15%
erro de lógica               8%
outros                       7%

Esses números são apenas ilustrativos.

Mas representam algo real:

alguns defeitos aparecem mais frequentemente que outros.

O profissional experiente acumulou isso na cabeça.

Talvez nunca tenha registrado estatisticamente.

Mas lembra de vinte incidentes semelhantes.

Quando vê:

S0C7

seu cérebro imediatamente diz:

— Primeiro vou procurar dados.

Isso não é preconceito irracional.

É utilização de frequência histórica.

O nome elegante é:

prior.

No CPD chamamos:

— Já vi essa porcaria antes.


Capítulo V — Agora chega a evidência

Então descobrimos:

O programa funcionava normalmente até ontem.

Interessante.

Isso altera probabilidades.

Se fosse um erro estrutural presente no programa havia meses, por que apareceu justamente hoje?

Talvez algum dado novo tenha provocado o caminho.

Ou alguma alteração tenha ocorrido.

O veterano pergunta:

— Teve mudança?

Resposta:

— Sim. Alteraram o arquivo upstream ontem à noite.

BUM.

A hipótese:

LAYOUT INCOMPATÍVEL

ganha peso.

Outras perdem.

Nosso cérebro fez aproximadamente:

ANTES DA EVIDÊNCIA

dados inválidos       █████████
layout                █████
storage overwrite     ███
outros                 ██

Depois:

DEPOIS DA MUDANÇA CONHECIDA

layout                ██████████████
dados inválidos       ███████
storage overwrite     █
outros                 █

Não sabemos ainda a causa.

Mas reorganizamos nossa fila de investigação.


Capítulo VI — Troubleshooting não é descobrir imediatamente a resposta

Esse ponto merece um café inteiro.

Um bom diagnóstico raramente funciona assim:

ERRO
↓
EUREKA
↓
SOLUÇÃO

Normalmente funciona:

ERRO
↓
HIPÓTESES
↓
EVIDÊNCIA
↓
ATUALIZAÇÃO
↓
NOVO TESTE
↓
NOVA EVIDÊNCIA
↓
ATUALIZAÇÃO
↓
HIPÓTESE MAIS FORTE
↓
CONFIRMAÇÃO

Ou seja:

troubleshooting é um processo iterativo de redução de incerteza.

Cada pergunta deveria servir para eliminar possibilidades.

Perguntar:

— O sistema está ruim?

ajuda pouco.

Perguntar:

— Qual foi o primeiro job que falhou?

ajuda muito mais.

Perguntar:

— Qual alteração entrou imediatamente antes?

melhor ainda.

Perguntar:

— O mesmo input reproduz o problema?

agora estamos cozinhando com gás.


Capítulo VII — O dump é uma máquina de reduzir entropia

No artigo anterior falamos sobre entropia como incerteza.

Receber apenas:

SISTEMA NÃO FUNCIONA

é alta entropia.

Pode ser praticamente qualquer coisa.

Agora recebemos:

JOB ABC123
STEP STEP040
PGM COBPAY01
ABEND S0C7

Já reduzimos bastante.

Depois:

OFFSET X'03A8'

Menos incerteza.

Mapeamos para:

COMPUTE WS-TOTAL =
        WS-VALOR * WS-QTD

Menos ainda.

Inspecionamos WS-VALOR.

Encontramos:

12A45

Praticamente resolvido.

Observe o processo.

Não fomos ficando “mais inteligentes”.

Recebemos informação discriminatória.

Cada pedaço eliminou hipóteses.


Capítulo VIII — Observabilidade é infraestrutura para Bayes

É por isso que observabilidade é tão importante.

Logs.

Métricas.

Traces.

SMF.

RMF.

Mensagens.

Dumps.

SQLCODEs.

File Status.

Registros de auditoria.

Histórico de mudanças.

Todos esses elementos possuem uma finalidade profunda:

fornecer evidências que permitam distinguir hipóteses concorrentes.

Sem observabilidade:

SISTEMA ESTÁ LENTO.

Com observabilidade:

CPU NORMAL
I/O ELEVADO
DB2 GETPAGES +600%
ACCESS PATH ALTERADO
APÓS RUNSTATS

Agora nossa distribuição mental muda completamente.

Talvez CPU não seja o problema.

Talvez rede não seja.

Talvez storage físico não seja.

O access path acabou de se tornar nosso principal suspeito.

Observabilidade não resolve automaticamente o incidente.

Ela melhora brutalmente a qualidade das probabilidades.


Capítulo IX — O detetive ruim coleta dados; o bom coleta dados discriminatórios

Imagine um investigador perguntando:

— Qual foi a temperatura da sala?

Resposta:

— 22 graus.

Talvez útil.

Talvez completamente irrelevante.

Agora:

— O problema começou antes ou depois do deploy?

Isso pode dividir o universo em dois.

Uma boa pergunta de troubleshooting possui alto valor informacional.

Ela separa hipóteses.

Perguntas ruins produzem fatos interessantes.

Perguntas boas destroem possibilidades.

Isso vale para qualquer ambiente:

CICS
DB2
IMS
JES2
VSAM
z/OS
Linux
Cloud
Kubernetes
rede
aplicação

O profissional experiente pergunta pouco.

Mas pergunta aquilo que muda o mapa.


Capítulo X — Exemplo: CICS está lento

Chamado:

“CICS está lento.”

Maravilha.

Talvez sejam:

  • transações;

  • Db2;

  • MQ;

  • CPU;

  • storage;

  • locking;

  • network;

  • runaway task;

  • file control;

  • região chegando ao limite;

  • aplicação;

  • downstream;

  • usuário exagerando;

  • Mercúrio retrógrado.

Bayes entra na sala.

Pergunta número 1:

— Todas as transações?

Resposta:

— Não. Apenas PAY1.

Pronto.

Hipótese de problema generalizado do CICS cai.

Pergunta número 2:

— Quando começou?

— Depois da implantação das 14h.

Outra atualização.

Pergunta número 3:

— O que mudou no PAY1?

— Uma nova consulta Db2.

A distribuição entra em colapso.

Pergunta:

— Temos SQL elapsed?

— Sim. A consulta nova responde em 11 segundos.

Caso quase encerrado.

Não precisamos desmontar o LPAR.

Não precisamos reiniciar CICS.

Não precisamos sacrificar um estagiário ao deus do throughput.

Obtivemos evidência.


Capítulo XI — O problema da ação prematura

Agora conhecemos um personagem muito perigoso:

o técnico que age antes de atualizar probabilidades.

Sistema lento?

— Reinicia.

CICS estranho?

— Recicla região.

Db2?

— Rebind.

Servidor?

— Reboot.

Aplicação?

— Redeploy.

Esse comportamento às vezes funciona.

E justamente por funcionar ocasionalmente torna-se perigosíssimo.

Porque cria aprendizado incorreto:

PROBLEMA
+
RESTART
=
RESOLVIDO

Talvez o restart apenas tenha removido temporariamente o sintoma.

O problema real permanece.

É como encontrar uma pessoa caída no chão, trocar o tapete e declarar vitória porque agora ela está deitada numa superfície limpa.


Capítulo XII — O veterano não pergunta apenas “o que aconteceu?”

Ele pergunta:

o que seria esperado se minha hipótese estivesse correta?

Isso é crucial.

Hipótese:

“O problema é exaustão de storage.”

Então deveríamos observar determinados sinais.

Se eles não aparecem, a hipótese perde força.

Hipótese:

“O problema é lock contention no Db2.”

Então deveríamos observar waits, locks e padrões compatíveis.

Não apareceram?

Probabilidade cai.

Essa é uma diferença fundamental entre investigação e superstição.

Superstição:

“Da última vez era storage.”

Investigação:

“Se for storage, quais evidências deveriam existir agora?”


Capítulo XIII — Bayes também sabe dizer “eu estava errado”

Essa é talvez a característica mais valiosa.

O profissional ruim se apaixona pela primeira hipótese.

O profissional bom permite que evidências destruam sua teoria.

Ele começa:

— Acho que é Db2.

Nova evidência:

DB2 NORMAL

Ele responde:

— Então não é.

Fim.

Não existe crise existencial.

Não existe defesa de honra.

Não existe:

— MAS EU TENHO 30 ANOS DE EXPERIÊNCIA!

Experiência deveria melhorar seus priors.

Não tornar suas hipóteses imunes à evidência.


Capítulo XIV — Confirmation bias: o inimigo mora no mesmo cérebro

Existe um perigo.

Quando acreditamos numa hipótese, começamos naturalmente a procurar evidências que a confirmem.

Sysprog:

— É aplicação.

Programador:

— É infraestrutura.

DBA:

— É rede.

Rede:

— É DNS.

DNS:

— Como sempre, ninguém lembra de mim até alguma coisa quebrar.

Cada equipe possui seus priors.

E seus preconceitos.

É por isso que investigação disciplinada pergunta:

O QUE CONFIRMARIA MINHA HIPÓTESE?

mas também:

O QUE A REFUTARIA?

Essa segunda pergunta salva horas.

Às vezes dias.


Capítulo XV — O incidente começa às 02h37

Agora vamos ao verdadeiro laboratório bayesiano:

a madrugada.

Telefone toca.

— Produção caiu.

Você abre o olho esquerdo.

— Tudo?

— Pagamentos.

Seu cérebro já começa.

Pergunta:

— Online ou batch?

— Online.

Atualização.

— Todos os canais?

— Só mobile.

Atualização.

— Web funciona?

— Sim.

Atualização.

— Houve mudança no mobile?

— Versão nova às 23h.

A probabilidade de:

IPL DO MAINFRAME

ser necessária neste momento é aproximadamente equivalente à probabilidade de um macaco escrever Hamlet antes do café esfriar.

Mesmo assim alguém inevitavelmente pergunta:

— Não seria melhor reiniciar tudo?

Não.

Volte para a cama.


Capítulo XVI — Incident response é uma árvore de hipóteses

Podemos imaginar:

                     INCIDENTE
                         |
        --------------------------------
        |              |               |
    APLICAÇÃO       INFRA           DADOS
        |              |               |
     código          CPU            inválido
     deploy          memória        faltando
     config          rede           duplicado
        |
   -------------
   |           |
mudança      bug antigo

Cada nova evidência corta galhos.

Isso é extraordinariamente parecido com algoritmos de busca.

Uma investigação eficiente evita visitar todos os nós.

Ela usa informação para podar a árvore.

O veterano não necessariamente conhece a resposta.

Conhece a ordem inteligente de investigação.


Capítulo XVII — A intuição do veterano não é mágica

Isso merece destaque.

Quando alguém trabalha durante décadas com:

  • milhares de jobs;

  • centenas de incidentes;

  • dezenas de migrações;

  • falhas absurdas;

  • mudanças ruins;

  • dados corrompidos;

  • problemas de performance;

começa a desenvolver reconhecimento de padrões.

Em psicologia cognitiva podemos chamar parte disso de pattern recognition.

No bar do CPD chamamos:

— Esse cheiro é de arquivo.

E frequentemente é.

O cérebro compara a situação atual com milhares de padrões armazenados.

Não realiza conscientemente uma equação.

Mas produz algo semelhante a:

JÁ VI ISSO
+
CONTEXTO ATUAL
=
HIPÓTESE FORTE

Capítulo XVIII — Mas experiência sem observabilidade vira folclore

Existe um perigo enorme.

Veterano:

— Toda vez que acontece isso é rede.

Pergunta:

— Quantas vezes?

— Sempre.

— Temos registro?

— Não.

— Métricas?

— Não.

— Incident database?

— Não.

— Evidência?

— Eu lembro.

Agora entramos numa dimensão perigosa.

Memória humana sofre:

  • viés de disponibilidade;

  • recência;

  • confirmação;

  • seleção;

  • esquecimento.

Precisamos transformar experiência em dados.

Por isso pós-mortem é importante.

Por isso histórico de incidentes importa.

Por isso conhecimento operacional deve ser registrado.

O melhor dos mundos combina:

EXPERIÊNCIA HUMANA
+
TELEMETRIA
+
HISTÓRICO
+
EVIDÊNCIA

Capítulo XIX — O CMDB pode ser uma máquina bayesiana

Imagine possuir histórico:

INCIDENTE 8231
Sintoma: S0C7
Causa: layout incompatível
Mudança anterior: COPYBOOK alterado

INCIDENTE 9102
Sintoma: S0C7
Causa: dado não numérico

INCIDENTE 10221
Sintoma: S0C7
Causa: integração enviando campo inválido

Depois chega incidente novo:

S0C7
+
COPYBOOK ALTERADO HOJE

Seu sistema poderia procurar casos semelhantes.

Agora experiência organizacional começa a virar memória operacional.

Uma espécie de:

P(CAUSA | HISTÓRICO + EVIDÊNCIA ATUAL)

Isso já aponta para aplicações modernas de IA em operações.


Capítulo XX — AIOps: o sysprog bayesiano virou software?

Em certo sentido, muitas ferramentas modernas de observabilidade e AIOps tentam fazer justamente aquilo que um excelente operador humano sempre fez:

  1. observar sinais;

  2. correlacionar eventos;

  3. detectar anomalias;

  4. procurar padrões históricos;

  5. priorizar hipóteses;

  6. sugerir causas.

A diferença está na escala.

Um humano consegue acompanhar determinados sistemas.

Uma grande organização produz milhões de eventos.

Então surgem sistemas tentando responder:

“Dado este conjunto de sinais, qual causa parece mais provável?”

Soa familiar?

Nosso velho Bayes está sorrindo no fundo da sala.


Capítulo XXI — E o LLM entra novamente

Nosso artigo anterior mostrou:

P(próximo token | contexto)

Agora troubleshooting pergunta:

P(causa | sintomas e evidências)

Perceba a semelhança estrutural.

Não estamos dizendo que troubleshooting e LLM são a mesma coisa.

Não são.

Mas ambos demonstram algo profundo:

contexto transforma probabilidades.

Sem contexto:

S0C7

Com contexto:

S0C7
+
COMPUTE
+
CAMPO PACKED
+
ARQUIVO ALTERADO
+
PROBLEMA COMEÇOU HOJE

Outra história.


Capítulo XXII — O prompt perfeito para um incidente

Imagine pedir ajuda a uma IA:

Meu COBOL deu erro. Ajude.

Universo gigantesco.

Agora:

Programa Enterprise COBOL em z/OS.
Batch.
Abend S0C7.
O PSW aponta para um COMPUTE.
Campo de entrada é PIC S9(7)V99 COMP-3.
O arquivo upstream mudou ontem.
O dump mostra bytes incompatíveis com packed decimal.

Você praticamente realizou o trabalho bayesiano antes mesmo da pergunta.

Reduziu a incerteza.

Essa é uma das regras de ouro ao trabalhar com humanos ou IA:

não peça respostas melhores; forneça evidências melhores.


Capítulo XXIII — Easter egg: o Ministério das Causas Prováveis

Em algum prédio governamental britânico existe:

MINISTRY OF PROBABLE ROOT CAUSES

Você entra.

— Estou com S0C7.

Funcionário:

— Formulário?

— Qual?

— Solicitação de hipótese.

— Quero descobrir a causa.

— Antes precisa declarar a causa provável.

— Mas se soubesse a causa não estaria aqui.

— Exatamente.

— Então como preencho?

— Pode solicitar uma hipótese provisória.

— Onde?

— Departamento de Evidências.

— Onde fica?

— Só podemos fornecer essa informação mediante evidência de que você já sabe onde fica.

Thomas Bayes abandona o prédio.

Nunca mais volta.


Capítulo XXIV — Não confunda correlação com causa

Sistema caiu às 14h03.

Deploy ocorreu às 14h00.

Conclusão:

— FOI O DEPLOY!

Calma.

A proximidade temporal aumenta a probabilidade.

Não prova causalidade.

Talvez:

  • uma carga também tenha começado;

  • certificado tenha expirado;

  • algum recurso tenha atingido limite;

  • outro sistema tenha falhado.

Bayes permite:

DEPLOY RECENTE
→ HIPÓTESE SOBE

mas não:

DEPLOY RECENTE
→ CULPADO CONDENADO

Precisamos continuar coletando evidências.


Capítulo XXV — O valor negativo da evidência

Algo que não aconteceu também informa.

Se esperamos que um problema de rede provoque múltiplos serviços afetados, mas apenas uma determinada função falha, isso reduz a força dessa hipótese.

Ausência de sintomas pode ser evidência.

Exemplo:

Hipótese:

CPU SATURADA

Mas RMF mostra:

CPU 32%

Hipótese perde peso.

Hipótese:

DB2 LENTO

Mas todas as queries respondem normalmente exceto uma.

Talvez não seja “Db2 lento”.

Talvez seja:

UMA QUERY RUIM

Toda investigação deveria perguntar:

o que eu deveria estar vendo caso minha teoria fosse verdadeira?


Capítulo XXVI — O poder extraordinário da linha do tempo

Uma das ferramentas mais poderosas de qualquer incidente é extremamente simples:

13:42 deploy iniciado
13:48 deploy finalizado
13:51 primeira mensagem XYZ
13:52 erros começam
13:54 throughput cai
14:01 chamados de usuários

Uma timeline cria relações.

Sem timeline:

UM MONTE DE COISAS ACONTECEU.

Com timeline:

EVENTO A
↓
EVENTO B
↓
SINTOMA C

Não prova automaticamente causalidade.

Mas reorganiza probabilidades brutalmente.

Por isso perguntar:

“quando exatamente começou?”

é uma das armas mais poderosas da engenharia.


Capítulo XXVII — O S0C7 encontra Occam

Outra ideia útil:

quando várias hipóteses explicam os mesmos fatos, normalmente começamos pela mais simples ou pela que requer menos suposições extras.

Não porque o Universo prometa simplicidade.

Ele não promete nada.

Mas porque investigar hipóteses simples e comuns primeiro costuma ser eficiente.

S0C7 depois de alteração de layout.

Possibilidade A:

O arquivo começou a fornecer caracteres não numéricos.

Possibilidade B:

Uma partícula cósmica atravessou o processador, alterou memória exatamente naquele campo e desapareceu deixando nenhuma outra evidência.

Fisicamente talvez B não seja absolutamente impossível.

Mas começaremos por A.

O macaco infinito teria orgulho da B.

Produção não.


Capítulo XXVIII — Base rate: cavalos antes de zebras

Outro princípio importantíssimo.

Quando ouvimos cascos:

pense primeiro em cavalos.

Não zebras.

Em troubleshooting:

comece pelas causas frequentes compatíveis com as evidências.

Isso evita passar quatro horas investigando uma condição extremamente rara enquanto o arquivo possui simplesmente:

00012A45

O veterano parece rápido porque já conhece os base rates.

Sabe o que costuma quebrar.

Isso não significa ignorar coisas raras.

Significa investigar numa ordem economicamente inteligente.


Capítulo XXIX — O novato pergunta “qual é a causa?”

O veterano pergunta:

“qual é a próxima evidência mais barata que pode separar minhas hipóteses?”

Essa pergunta vale ouro.

Temos duas hipóteses:

A = DADO INVÁLIDO
B = STORAGE OVERWRITE

Qual teste é mais simples?

Talvez olhar os bytes do campo no dump.

Se estão inválidos já na entrada:

A sobe muito.

Se estavam corretos e depois aparecem corrompidos:

B sobe.

Investigue primeiro aquilo que possui:

  • baixo custo;

  • alta capacidade discriminatória;

  • baixo risco.

Isso é troubleshooting eficiente.


Capítulo XXX — Reiniciar é uma evidência terrível

Alguém reinicia.

Problema some.

Conclusão:

— Era memória.

Não necessariamente.

O restart alterou dezenas de condições simultaneamente:

  • memória;

  • conexões;

  • filas;

  • locks;

  • caches;

  • processos;

  • sessões;

  • timers.

Portanto ele possui baixo poder discriminatório.

Sabemos:

ESTADO ANTERIOR → PROBLEMA
ESTADO NOVO → SEM PROBLEMA

Mas não sabemos qual diferença foi causal.

Restart é poderoso operacionalmente.

Diagnosticar com ele é frequentemente horrível.


Capítulo XXXI — Nunca desperdice um incidente

Quando corrigimos e simplesmente fechamos:

RESOLVIDO.

perdemos aprendizado.

O fechamento deveria registrar:

SINTOMA
CAUSA
EVIDÊNCIAS
TIMELINE
MUDANÇA RELACIONADA
COMO CONFIRMAMOS
AÇÃO CORRETIVA
COMO DETECTAR MAIS RÁPIDO

Por quê?

Porque estamos construindo os priors da organização.

O incidente de hoje melhora a investigação de amanhã.

Esse é o verdadeiro valor do conhecimento operacional.


Capítulo XXXII — Runbook não deve ser livro de receitas

Runbook ruim:

SE S0C7:
1. REINICIAR
2. TENTAR NOVAMENTE
3. CHAMAR FULANO

Runbook bom:

S0C7

1. Identifique instrução e offset.
2. Determine quais operandos participam.
3. Inspecione representação dos dados.
4. Confirme origem dos campos.
5. Verifique alterações recentes.
6. Compare com layout esperado.
7. Reproduza com input específico.
8. Confirme causa antes da correção.

O segundo ensina investigação.

O primeiro ensina ritual.

Sistemas complexos precisam de raciocínio, não pajelança tecnológica.


Capítulo XXXIII — Quando experiência vira arrogância

Existe uma frase terrível:

“Eu sei o que é.”

Talvez saiba.

Mas a versão profissional é:

“Minha hipótese principal é X porque A, B e C. Vou verificar D para confirmar.”

Veja a diferença.

A primeira encerra investigação.

A segunda cria um teste.

Veteranos realmente bons possuem confiança sem abandonar falsificabilidade.

Eles sabem que experiência melhora probabilidade.

Não concede infalibilidade.


Capítulo XXXIV — O aprendiz pode acelerar décadas de experiência

Aqui existe uma boa notícia.

Você não precisa viver quarenta anos para começar a pensar assim.

Pode criar deliberadamente hábitos bayesianos.

Ao receber um incidente, escreva:

HIPÓTESE 1
HIPÓTESE 2
HIPÓTESE 3

Depois:

EVIDÊNCIA QUE CONFIRMA
EVIDÊNCIA QUE REFUTA

Em seguida pergunte:

QUAL TESTE SEPARA MELHOR ESSAS HIPÓTESES?

Faça isso repetidamente.

Após meses, começa a ficar natural.

Depois de anos:

alguém mostra S0C7.

Você pede café.

E pergunta:

— Mudaram o arquivo ontem?

A metamorfose está completa.


Capítulo XXXV — O Sysprog Bayesiano nasce

Nosso jovem programador finalmente volta ao incidente original.

Temos:

ABEND S0C7

A instrução é:

COMPUTE WS-TOTAL =
        WS-VALOR * WS-QUANTIDADE

Descobrimos:

WS-VALOR = bytes inválidos

A origem:

arquivo upstream

Alteração:

COPYBOOK MODIFICADO ONTEM

Investigação do arquivo mostra:

o produtor passou a gerar determinado campo com nova definição.

O consumidor continuou interpretando o layout antigo.

Pronto.

Causa encontrada.

Não tivemos magia.

Tivemos:

SINTOMA
+
HISTÓRICO
+
HIPÓTESES
+
EVIDÊNCIA
+
ATUALIZAÇÃO
+
CONFIRMAÇÃO

Thomas Bayes acabaria de receber acesso ao RACF.


Epílogo — O velho homem e o dump

Alguns anos depois, aquele programador iniciante está numa sala com outro novato.

O monitor mostra:

S0C7

O jovem pergunta assustado:

— O que pode ser?

Nosso antigo iniciante pega café.

Observa o horário.

Pergunta:

— Quando começou?

— Hoje.

— Mudaram alguma coisa?

— Um arquivo upstream.

Ele sorri.

— Mostra o layout.

O novato pergunta:

— Como você sabia?

Ele pensa por alguns segundos.

Poderia explicar:

prior probabilities.

Likelihood.

Posterior.

Base rate.

Conditional probability.

Entropia.

Information gain.

Pattern recognition.

Observabilidade.

Décadas de incidentes.

Mas responde apenas:

— Experiência.

No fundo da sala, Thomas Bayes derruba a cabeça sobre a mesa.

Porque aquela palavra simples esconde uma máquina extraordinariamente sofisticada.

O cérebro do veterano não possui certeza.

Possui probabilidades bem calibradas.

Ele não conhece todas as causas.

Aprendeu quais causas procurar primeiro.

Ele não lê todas as linhas do dump.

Sabe quais linhas diminuem a incerteza.

Ele não testa todas as hipóteses.

Procura a evidência que elimina mais delas.

E talvez seja essa a verdadeira evolução da nossa trilogia.

O Macaco Infinito dizia:

TENTE TUDO.

O LLM dizia:

USE O CONTEXTO PARA DESCOBRIR
O QUE É MAIS PROVÁVEL.

O Sysprog Bayesiano responde:

USE A EVIDÊNCIA PARA ATUALIZAR
O QUE VOCÊ ACREDITA.

São três formas completamente diferentes de atravessar um universo de possibilidades.

O macaco depende de tempo infinito.

O modelo depende de padrões aprendidos.

O veterano depende de experiência, contexto e observabilidade.

E produção?

Produção não possui tempo infinito.

Produção possui SLA.

Às 03h17, o telefone toca.

— Caiu de novo.

O veterano olha o dashboard.

Depois pergunta:

— Mesmo erro?

— Não.

Ele toma um gole de café.

Apaga todas as hipóteses anteriores.

E começa novamente.

Porque existe uma última regra que todo verdadeiro Sysprog Bayesiano aprende:

a evidência de ontem melhora seu prior — mas nunca substitui a evidência de hoje.

☕🧙‍♂️🖥️

No console:

INCIDENT 004217 CLOSED
ROOT CAUSE CONFIRMED

Trinta segundos depois:

NEW INCIDENT 004218 OPEN

O veterano olha para a tela.

— Interessante.

O novato pergunta:

— Você já sabe o que é?

— Não.

— Então por que está sorrindo?

Ele pega a caneca.

— Porque já sei qual é a primeira pergunta.

E, em troubleshooting, às vezes isso vale mais que saber a resposta.

quarta-feira, 12 de junho de 2024

O Macaco, Shakespeare e o PERFORM UNTIL: quando a Matemática descobriu que, com tempo infinito, até código sem documentação funciona

 
Bellacosa Mainframe e o teorema dos macacos infinitos

☕ Um Café no Bellacosa Mainframe

O Macaco, Shakespeare e o PERFORM UNTIL: quando a Matemática descobriu que, com tempo infinito, até código sem documentação funciona

🐒 Um milhão de macacos, máquinas de escrever, Hamlet, COBOL e o pequeno problema de o Universo acabar antes do processamento

Imagine a seguinte cena.

Estamos em algum CPD perdido nos anos 1980.

Ar-condicionado fazendo aquele barulho de turbina de Boeing, luz fluorescente, operador carregando formulário contínuo, impressora de linha martelando papel como se tivesse uma dívida pessoal com a celulose e, num canto da sala, alguém acaba de apresentar o mais ambicioso projeto de automação da história da informática:

um milhão de macacos diante de um milhão de máquinas de escrever.

O gerente entra.

— Qual é o objetivo do projeto?

— Produzir Shakespeare.

— Qual o prazo?

— Infinito.

— Qual o orçamento?

— Infinito.

— Quantos recursos?

— Um milhão de macacos.

O gerente pensa durante alguns segundos.

— Podemos colocar metade como terceiros?

É nesse momento que um programador COBOL sensato levanta a mão:

— Desculpe... existe SLA?

Não.

— Existe estimativa de CPU?

Não.

— Existe checkpoint/restart?

Também não.

— Então isso vai dar problema.

E assim chegamos a uma das ideias mais deliciosamente estranhas da matemática: o chamado Teorema do Macaco Infinito.

Em sua versão popular, ele diz aproximadamente o seguinte:

se um macaco pressionar aleatoriamente as teclas de uma máquina de escrever por tempo infinito, em algum momento produzirá qualquer texto finito determinado — inclusive Hamlet, de Shakespeare.

Matematicamente, sob hipóteses adequadas de independência e de probabilidades não nulas para os caracteres, a afirmação é essencialmente verdadeira: à medida que o número de tentativas independentes cresce sem limite, a probabilidade de uma sequência finita específica nunca aparecer tende a zero. (Wikipedia)

Mas existe uma pequena diferença entre:

matematicamente acontecer quase certamente

e

você ficar esperando acontecer.

Essa diferença mede aproximadamente vários universos, algumas mortes térmicas, um número ofensivo de bananas e provavelmente três reuniões de mudança em produção.

Prepare o café.

Hoje vamos descobrir como macacos digitadores nos levam de Émile Borel a Shakespeare, de probabilidade a brute force, de COBOL a inteligência artificial — e por que infinito é uma palavra que deve deixar qualquer profissional de produção imediatamente desconfiado.


🧮 Capítulo I — Antes de Shakespeare havia um francês com ideias perigosas

A associação moderna entre macacos digitando e probabilidade aparece no trabalho do matemático francês Émile Borel.

Em 1913, Borel publicou um trabalho sobre mecânica estatística e irreversibilidade no qual usou a imagem de macacos datilógrafos como comparação para acontecimentos de probabilidade extraordinariamente pequena. A metáfora reapareceria em seu livro Le Hasard, de 1914. (Wikipedia)

E aqui aparece a primeira surpresa.

A história original não era exatamente:

UM MACACO ESCREVERÁ HAMLET.

Era praticamente o contrário.

Borel queria mostrar que existem acontecimentos cuja probabilidade é tão ridiculamente pequena que, embora não sejam logicamente impossíveis, podemos tratá-los como operacionalmente impossíveis.

Em uma das formulações associadas a Borel, imagine um milhão de macacos trabalhando durante dez horas por dia diante de máquinas de escrever. Seria absurdamente improvável que produzissem exatamente os livros das grandes bibliotecas do mundo. Borel usava uma improbabilidade monstruosa como referência para discutir eventos ainda menos plausíveis na mecânica estatística. (Wikipedia)

Ou seja:

o famoso “um milhão de macacos” realmente aparece na história.

Mas o sentido original se perdeu um pouco durante o caminho.

O público guardou:

MACACO + TEMPO = SHAKESPEARE.

Borel provavelmente teria respondido:

— Monsieur, não foi exatamente isso que eu quis dizer.

Mas já era tarde.

A internet ainda não existia, porém o meme já havia escapado.


🎭 Capítulo II — Entra Shakespeare, perseguido por um macaco

No mundo anglófono, a metáfora passou a ser ligada especialmente a Shakespeare.

Isso faz enorme sentido cultural.

Se você disser:

“Uma sequência aleatória infinita eventualmente contém qualquer substring finita.”

a maior parte das pessoas procura imediatamente uma janela para escapar.

Agora diga:

“Um macaco pode escrever Hamlet.”

Pronto.

Você tem atenção.

Shakespeare tornou-se uma espécie de benchmark literário da improbabilidade.

O equivalente cultural de perguntar:

CAN IT RUN CRYSIS?

Só que em literatura:

CAN MONKEY WRITE HAMLET?

Com o tempo, a ideia ganhou diversas versões:

  • um macaco durante tempo infinito;

  • infinitos macacos durante tempo infinito;

  • milhões de macacos;

  • máquinas de escrever;

  • teclados;

  • Shakespeare inteiro;

  • apenas Hamlet;

  • uma frase específica.

A essência matemática, entretanto, é muito mais simples.

O macaco é irrelevante.

A máquina de escrever também.

Shakespeare também.

Poderíamos substituir tudo por:

GERADOR_ALEATORIO
+
ALFABETO_FINITO
+
TENTATIVAS_SEM_LIMITE
+
SEQUENCIA_ALVO_FINITA

E pronto.

Temos o problema.


☕ Capítulo III — O programa COBOL que explica o macaco

Vamos traduzir tudo para algo compreensível por um programador COBOL iniciante.

Imagine um teclado extremamente simplificado com apenas três teclas:

A
B
C

E queremos produzir:

ABC

Em cada posição existem três possibilidades.

Para acertar o primeiro caractere:

1 / 3

Para acertar dois:

1 / 3 × 1 / 3

Para acertar três:

1 / 3 × 1 / 3 × 1 / 3

Portanto:

1 / 27

Existem 27 sequências possíveis de três caracteres:

AAA
AAB
AAC
ABA
ABB
ABC
...
CCC

Uma delas é ABC.

Nada assustador.

Vamos aumentar.

Se tivermos 30 caracteres possíveis no teclado e procurarmos uma sequência de dez caracteres:

30^10

combinações.

Isso já dá aproximadamente:

590.490.000.000.000

possibilidades.

E dez caracteres não são Hamlet.

São praticamente o nome de um dataset escrito por alguém particularmente econômico.


🐍 Capítulo IV — O verdadeiro vilão chama-se crescimento exponencial

Programadores iniciantes muitas vezes olham para probabilidades assim e pensam:

— Tudo bem. Basta aumentar a quantidade de máquinas.

É neste momento que entra pela porta o crescimento exponencial, vestindo armadura medieval e carregando uma galinha.

Ele olha para você.

Você olha para ele.

Ele diz:

— Não.

Cada caractere adicional multiplica o espaço de possibilidades pelo número de teclas.

Se temos K caracteres possíveis e queremos encontrar uma determinada sequência de comprimento L, a probabilidade de acertá-la exatamente numa tentativa é:

1 / K^L

Com 30 teclas:

1 caractere   = 1 / 30
2 caracteres  = 1 / 900
3 caracteres  = 1 / 27.000
4 caracteres  = 1 / 810.000
...

A coisa cresce de forma brutal.

Em 2024, Stephen Woodcock e Jay Falletta, da University of Technology Sydney, fizeram justamente uma análise moderna dessa questão no artigo A numerical evaluation of the Finite Monkeys Theorem. Eles trabalharam com um teclado hipotético de 30 teclas e calcularam quanto trabalho aleatório seria necessário para produzir vários textos. (Universidade de Tecnologia de Sydney)

O resultado é magnífico.

Não para os macacos.

Para a matemática.


🍌 Capítulo V — Comecemos com BANANAS

Os pesquisadores calcularam que o número esperado de teclas até aparecer:

BANANAS

é aproximadamente:

30^7

ou cerca de:

21,9 bilhões

de teclas. (Opus)

Agora imagine o responsável pelo projeto entrando na reunião.

— Temos algum resultado?

— Temos.

— Shakespeare?

— Não.

— Hamlet?

— Não.

— Uma frase?

— Também não.

— O quê?

— BANANAS.

— Quantos bilhões de teclas?

— Cerca de 22.

Silêncio.

O macaco solicita promoção.


💾 Capítulo VI — O brute force dos primatas

Agora chegamos à conexão com informática.

O Teorema do Macaco Infinito é uma bela alegoria para brute force.

Imagine que precisamos descobrir uma senha:

ABC

Uma estratégia intelectualmente sofisticada poderia estudar padrões, contexto, histórico, probabilidades etc.

O brute force diz:

AAA
AAB
AAC
...
ABA
...
ABC

Achou.

Nenhuma inteligência foi necessária.

Apenas enumeração.

É praticamente o algoritmo do macaco, com a pequena vantagem de o computador não jogar fezes no teclado.

Podemos imaginar um pseudocódigo:

PERFORM UNTIL SHAKESPEARE-FOUND
    GENERATE-RANDOM-CHARACTER
    ADD CHARACTER TO BUFFER
    SEARCH BUFFER FOR HAMLET
END-PERFORM.

Existe apenas um pequeno problema.

SHAKESPEARE-FOUND talvez não aconteça antes de:

UNIVERSE-END = 'Y'

E ninguém colocou essa condição no PERFORM.

Temos então:

PERFORM UNTIL SHAKESPEARE-FOUND

quando talvez devêssemos ter escrito:

PERFORM UNTIL SHAKESPEARE-FOUND
           OR UNIVERSE-DESTROYED
           OR BUDGET-EXHAUSTED
           OR MONKEYS-UNIONIZED

Essa última condição é importantíssima.


🏭 Capítulo VII — Produção não aceita infinito

Aqui existe uma lição séria escondida atrás da banana.

Em matemática podemos tranquilamente dizer:

N → ∞

Em produção, o gerente pergunta:

— Quanto demora?

Você:

— Quando N tende ao infinito...

Gerente:

— QUANTO DEMORA?

Produção possui:

  • CPU limitada;

  • memória limitada;

  • energia limitada;

  • storage limitado;

  • orçamento limitado;

  • prazo limitado;

  • paciência humana extremamente limitada.

É por isso que existe uma diferença colossal entre um problema teoricamente solucionável e um problema computacionalmente viável.

Essa distinção aparece por toda a informática.

Você pode desenvolver um algoritmo que encontra uma solução.

Mas se ele precisar de:

10^100000

operações, parabéns:

você resolveu matematicamente o problema e operacionalmente criou decoração para a documentação.


♾️ Capítulo VIII — O infinito é um trapaceiro elegante

O ponto mais importante do Teorema do Macaco Infinito não são os macacos.

É o infinito.

Imagine um evento que tenha uma probabilidade minúscula, mas diferente de zero, de acontecer em cada tentativa independente.

Digamos:

P = 0,000000000000000000001

Uma tentativa?

Provavelmente falha.

Mil?

Provavelmente falha.

Um bilhão?

Talvez continue falhando.

Mas quando o número de tentativas caminha matematicamente para o infinito, a probabilidade de o evento nunca ocorrer tende a zero.

Daí surge o famoso:

“quase certamente”.

Em teoria da probabilidade, probabilidade 1 não deve ser confundida ingenuamente com necessidade lógica absoluta; “almost surely” é um termo técnico. No modelo clássico do macaco, contudo, qualquer sequência finita específica aparecerá quase certamente sob as hipóteses de geração aleatória independente apropriadas. (Wikipedia)

O infinito simplesmente continua tentando.

Ele não tem reunião às 17h.

Não possui mudança emergencial.

Não entra de férias.

Não tem filho para buscar.

Não precisa explicar CAPEX.

E não recebe:

IEF450I JOB MONKEY01 ABEND S0C7

🐒 Capítulo IX — Alguém resolveu experimentar com macacos reais

Evidentemente, em algum momento da história alguém disse:

— Tudo bem, mas e se colocarmos macacos de verdade diante de um teclado?

A humanidade chegou até a Lua porque fazemos perguntas assim.

Em 2002, um projeto ligado à University of Plymouth colocou um computador no recinto de seis macacos no Paignton Zoo, na Inglaterra. O trabalho tinha caráter artístico/experimental, não era uma tentativa científica séria de demonstrar o teorema. (WIRED)

Os seis macacos chamavam-se Elmo, Gum, Heather, Holly, Mistletoe e Rowan. (WIRED)

Isso já parece elenco de sitcom.

Os pesquisadores provavelmente esperavam algo como:

HFJSOIEQKMDKWO...

O universo respondeu:

SSSSSSSSSSSSSSSSSSSSSSSSSSS

Os animais produziram apenas algumas páginas de texto, predominantemente com a letra S; outras letras apareceram ocasionalmente. O macho dominante também atacou o equipamento com uma pedra, e o teclado recebeu tratamento biológico que definitivamente não fazia parte das especificações originais. (WIRED)

A experiência revelou uma falha fundamental no modelo.

O macaco matemático é:

RANDOM-GENERATOR.

O macaco verdadeiro é:

IF KEYBOARD = INTERESTING
    PERFORM INVESTIGATE
    PERFORM HIT-WITH-STONE
    PERFORM RANDOM-BEHAVIOUR
END-IF.

Macacos reais não são geradores aleatórios uniformes.

Possuem preferências, comportamentos, curiosidade, aprendizagem, hierarquia e intenção.

Mike Phillips, ligado ao projeto, destacou justamente que os animais eram mais complexos que simples geradores aleatórios e perceberam que pressionar uma tecla causava uma reação na tela. (WIRED)

Ou seja:

Borel inventou um dispositivo probabilístico.

As pessoas colocaram pelo.

Chamaram de macaco.

Depois esqueceram que era metáfora.

Clássico problema de requisitos.


🧠 Capítulo X — Random não significa inteligência

E aqui chegamos a algo extraordinariamente importante.

Suponha que o macaco produza:

TO BE OR NOT TO BE

Ele escreveu Shakespeare?

Fisicamente:

sim.

Semanticamente?

A coisa fica interessante.

Ele não sabe inglês.

Não conhece Hamlet.

Não sabe o que é existência.

Nunca sofreu uma crise existencial diante de um castelo dinamarquês.

Provavelmente está pensando:

BANANA.

A sequência possui significado para nós, porque reconhecemos o padrão.

Para o gerador, são apenas símbolos.

Isso nos leva diretamente até inteligência artificial.


🤖 Capítulo XI — “Então o ChatGPT é um macaco estatístico?”

Não.

E essa diferença é maravilhosa.

O macaco do teorema clássico possui, no modelo mais simples:

P(A) = P(B) = P(C) = ...

Cada tecla pode ser escolhida independentemente, sem conhecimento do contexto anterior.

Se ele escreveu:

TO BE OR NOT TO

a próxima letra não se torna magicamente mais provável por causa disso.

Para o gerador uniforme, poderia vir:

X

ou:

Q

ou:

Z

com probabilidades determinadas apenas pelo mecanismo aleatório.

Um modelo de linguagem funciona de maneira radicalmente diferente.

Ele trabalha com distribuições condicionais.

Simplificando brutalmente:

P(próximo token | contexto anterior)

Se temos:

IDENTIFICATION DIVISION.
PROGRAM-ID.

um modelo treinado em código COBOL sabe estatisticamente que certos tokens seguintes são muito mais compatíveis com aquele contexto que outros.

Ele não precisa testar igualmente:

BANANA
ELEPHANT
WORKING-STORAGE
PERFORM
PROCEDURE
ZXCVBN

porque aprendeu relações estruturais da linguagem.

Essa diferença é gigantesca.


🗜️ Capítulo XII — Conhecimento é redução do espaço de busca

Essa talvez seja a maior lição de toda a história.

Inteligência frequentemente significa eliminar possibilidades ruins antes de testá-las.

Imagine que existam:

30^100

sequências possíveis.

Brute force precisa considerar praticamente todo o espaço.

Conhecimento diz:

— Algumas sequências são muitíssimo mais prováveis.

É exatamente o que fazemos como seres humanos.

Se você vê:

MOVE CUSTOMER-NAME TO

você espera algo como:

WS-CUSTOMER-NAME

Não:

BANANA

Não porque banana seja fisicamente impossível.

Mas porque seu conhecimento do contexto reduziu dramaticamente a probabilidade dessa opção.

Experiência é, sob determinado ângulo, um compressor de espaço de busca.

O programador iniciante olha 500 linhas e vê 500 linhas.

O programador experiente olha e diz:

— O problema provavelmente está nesses quinze comandos.

O iniciante pergunta:

— Como você sabe?

Trinta anos de produção responderiam:

— Porque já vi esse gremlin antes.


🏰 Capítulo XIII — Sherlock Holmes e o macaco

Imagine dois sistemas investigando um erro.

Sistema A — Macaco

Testa todas as possibilidades:

CPU?
MEMÓRIA?
DISCO?
VSAM?
DB2?
CICS?
JCL?
RACF?
DNS?
CAFETEIRA?
FASE DA LUA?

Sistema B — programador experiente

Recebe:

ABEND S0C7

e pensa:

— Data exception. Vamos procurar dados não numéricos em campo tratado como numérico.

Ele reduziu instantaneamente o espaço de busca.

Não encontrou a solução por magia.

Encontrou porque possui um modelo interno do sistema.

É isso que torna conhecimento tão poderoso.

Conhecimento não apenas fornece respostas.

Conhecimento elimina bilhões de respostas idiotas.


🎲 Capítulo XIV — Aleatoriedade não é criatividade

Outra armadilha filosófica aparece aqui.

Se o macaco produzir Hamlet inteiro, nós obtivemos:

OUTPUT = HAMLET

Mas não necessariamente:

CREATIVITY = TRUE

O texto possui forma idêntica.

A origem do texto é completamente diferente.

Essa questão voltou com força na época da IA generativa. O próprio estudo de Woodcock e Falletta observa que a distinção entre uma sequência produzida intencionalmente por um criador cognoscente e uma sequência idêntica surgida sem intenção possui relevância contemporânea no debate sobre IA generativa. (Opus)

E aqui entramos numa caverna filosófica suficientemente profunda para perdermos três filósofos, dois sysprogs e um consultor Gartner.

Porque agora podemos perguntar:

o significado está no autor?

No texto?

No leitor?

Se Hamlet aparece aleatoriamente, continua sendo Hamlet?

Se ninguém sabe que apareceu, ele contém significado?

Se uma IA produz algo novo combinando estruturas aprendidas, isso é criação?

E se um humano faz exatamente isso com suas experiências?

Neste ponto o Ministério dos Macacos informa que nosso formulário filosófico foi preenchido com caneta azul quando deveria ser preta.

Processo cancelado.


🌌 Capítulo XV — O Universo pediu CANCEL

Em 2024, Woodcock e Falletta fizeram algo particularmente divertido:

retiraram o infinito.

Perguntaram:

e se tivermos um Universo finito?

Eles modelaram chimpanzés digitando uma tecla por segundo e consideraram escalas temporais cosmológicas gigantescas. Mesmo usando recursos absurdamente generosos, textos complexos continuariam praticamente inalcançáveis por digitação aleatória. (Universidade de Tecnologia de Sydney)

Para as obras completas de Shakespeare, estimadas no estudo em cerca de 884.647 palavras, o número esperado de teclas alcança uma ordem aproximadamente equivalente a 10^7.448.366. (Opus)

Observe cuidadosamente.

Não é:

7 milhões

Nem:

10 elevado a 7 milhões

por acidente tipográfico.

É uma potência cuja grandeza já entra no território onde calculadoras olham para você e pedem demissão.

A conclusão prática do estudo foi justamente que o resultado intuitivo do teorema infinito é enganoso quando tentamos transportá-lo para um Universo de recursos finitos. (Universidade de Tecnologia de Sydney)

Traduzido para mainframe:

THEORETICAL:
    JOB WILL COMPLETE.

PRODUCTION:
    MAXCC=UNIVERSE.

🧯 Capítulo XVI — Lição de produção número 1: “possível” não significa “viável”

Guarde isto.

É excelente para programação, arquitetura e engenharia:

possibilidade matemática não implica viabilidade operacional.

Um algoritmo pode encontrar a resposta.

Mas:

  • em quanto tempo?

  • usando quanta memória?

  • com qual custo?

  • com quantas tentativas?

  • com qual consumo energético?

  • dentro de qual SLA?

Essa pergunta separa frequentemente:

SOLUÇÃO ACADÊMICA

de:

SOLUÇÃO DE PRODUÇÃO.

Seu sistema pode tecnicamente processar um arquivo realizando busca sequencial milhões de vezes.

Ele funciona.

Até chegar o fechamento.

Às 23h55.

Quando alguém pergunta:

— POR QUE ESTA PORCARIA AINDA ESTÁ EXECUTANDO?

E você responde:

— Tecnicamente terminará.

Essa frase nunca salvou ninguém numa war room.


🔍 Capítulo XVII — Lição número 2: tente reduzir o universo antes de procurar

Suponha que você tenha 100 possibilidades por posição.

Uma senha de dez posições produz:

100^10

combinações.

Mas se você descobrir que:

  • começa com letra;

  • possui determinada estrutura;

  • pertence a um vocabulário;

  • segue alguma regra;

o universo encolhe.

Essa é uma ideia central em inúmeros algoritmos.

Não necessariamente devemos procurar mais rápido.

Às vezes precisamos procurar menos.

Índices fazem isso.

Estatísticas fazem isso.

Heurísticas fazem isso.

Conhecimento de domínio faz isso.

Machine learning faz isso.

Experiência humana faz isso.

Um índice Db2 é, em espírito, uma forma civilizada de dizer:

“Não seja um macaco lendo todas as linhas.”


🗃️ Capítulo XVIII — O TABLESPACE SCAN dos macacos

Imagine uma tabela contendo um bilhão de clientes.

Queremos:

SELECT *
FROM CLIENTE
WHERE CPF = :CPF;

Sem índice adequado:

PROCURA PROCURA PROCURA PROCURA PROCURA...

É o macaco estatístico.

Com índice:

ÍNDICE
   ↓
PÁGINA
   ↓
REGISTRO

Pronto.

A diferença fundamental?

Informação estrutural.

O índice possui conhecimento sobre onde procurar.

O macaco possui apenas persistência.

E persistência sem estratégia é apenas desperdício muito disciplinado.


🎬 Capítulo XIX — Easter egg nº 1: Os Simpsons

A metáfora ficou tão popular que apareceu em inúmeras obras culturais.

Um exemplo particularmente famoso está em The Simpsons: Montgomery Burns mantém macacos trabalhando em máquinas de escrever e examina um texto que começa quase como a abertura de A Tale of Two Cities, de Charles Dickens, mas contém um erro absurdo. O estudo de Woodcock e Falletta inclusive menciona a referência. (Opus)

A piada funciona porque todos entendemos intuitivamente:

quase certo não serve.

Em texto literário talvez seja engraçado.

Em:

UPDATE ACCOUNT
SET BALANCE = ...

um caractere errado pode transformar a terça-feira num documentário criminal.


🐍 Capítulo XX — Easter egg nº 2: Ministério da Digitação Aleatória

Imagine agora um departamento governamental britânico responsável pelo projeto.

MINISTRY OF RANDOM PRIMATE TEXT GENERATION

Funcionário:

— Seu macaco possui licença para Shakespeare?

— Não sabia que precisava.

— Formulário 27-B.

— Onde consigo?

— Departamento de Licenciamento de Primatas Literários.

— Onde fica?

— Segundo andar.

— Mas este prédio só tem um andar.

— Então terá que preencher o formulário solicitando a existência do segundo.

— Onde consigo esse formulário?

— Segundo andar.

Essa é provavelmente uma representação bastante fiel do infinito burocrático.

Ao contrário do infinito matemático, ele realmente existe.


🧪 Capítulo XXI — Faça você mesmo o experimento

Você não precisa comprar um macaco.

O RH provavelmente também proibiria.

Podemos construir mentalmente nosso próprio experimento.

Objetivo:

COBOL

Alfabeto:

ABCDEFGHIJKLMNOPQRSTUVWXYZ

São 26 possibilidades por posição.

A probabilidade de produzir COBOL numa tentativa específica de cinco caracteres é:

1 / 26^5

Como:

26^5 = 11.881.376

temos aproximadamente:

1 chance em 11,9 milhões

Agora experimente procurar:

HELLO

Mesma dificuldade.

Depois:

HELLO WORLD

Muito mais difícil.

Depois:

IDENTIFICATION DIVISION

Boa sorte.

Depois:

programa COBOL inteiro compilável

Aqui seu macaco provavelmente solicitará aposentadoria.


🧬 Capítulo XXII — A grande diferença entre busca cega e linguagem

Agora voltamos à IA.

Imagine que queremos completar:

O gato subiu no...

O macaco uniforme considera aproximadamente equivalentes:

telhado
submarino
IBM
parafuso
Júpiter
abacaxi

Um modelo linguístico aprendeu que algumas continuações possuem probabilidade muito maior dadas as palavras anteriores.

Portanto:

ALEATÓRIO PURO

não é:

MODELO PROBABILÍSTICO DE LINGUAGEM

Ambos podem possuir elementos probabilísticos.

Mas um possui estrutura aprendida.

Isso equivale a substituir:

TENTE TUDO

por:

TENTE PRIMEIRO AQUILO QUE FAZ SENTIDO.

Esse princípio é gigantesco.


📚 Capítulo XXIII — Então Shakespeare venceu o macaco?

Sim.

E não.

Shakespeare não precisava experimentar todas as combinações possíveis da língua inglesa até acidentalmente surgir:

HAMLET

Ele possuía:

  • linguagem;

  • repertório;

  • cultura;

  • memória;

  • intenção;

  • experiência;

  • estruturas narrativas;

  • conhecimento das pessoas;

  • capacidade de selecionar.

Criatividade humana não é uma roleta girando caracteres.

Criamos dentro de espaços altamente estruturados.

Eliminamos possibilidades.

Escolhemos outras.

Revisamos.

Associamos.

Recombinamos.

E talvez esteja aí uma ligação fascinante entre literatura, programação e inteligência:

criar é navegar inteligentemente num espaço gigantesco de possibilidades.


👴 Capítulo XXIV — O velho COBOLzeiro também é um modelo treinado

Você mostra um dump gigantesco para alguém com trinta anos de produção.

Ele olha.

Passa alguns segundos.

Aponta:

— Aqui.

O jovem pergunta:

— COMO VOCÊ DESCOBRIU?

Ele talvez responda:

— Experiência.

Mas “experiência” esconde muita coisa.

Durante décadas aquele cérebro atualizou implicitamente:

P(CAUSA | SINTOMAS)

O profissional experiente sabe que:

S0C7

aumenta a probabilidade de certos problemas.

Que:

FILE STATUS 35

aponta para determinadas categorias.

Que determinada mensagem de CICS leva a determinadas suspeitas.

Ele não testa aleatoriamente todas as causas possíveis do Universo.

Ele executa uma espécie de:

ORDER BY PROBABILIDADE DESCENDING

na cabeça.

É por isso que substituir experiência exclusivamente por procedimentos pode ser tão difícil.

Documentação registra regras.

Experiência frequentemente registra probabilidades implícitas.


🚨 Capítulo XXV — E aqui mora uma armadilha

Heurísticas reduzem brutalmente o espaço de busca.

Mas podem errar.

O especialista pensa:

— S0C7? Já sei.

E deixa de investigar uma causa nova.

Esse é o outro lado da moeda.

O macaco não possui preconceitos.

O especialista possui.

Por isso bons processos combinam:

EXPERIÊNCIA
+
EVIDÊNCIA
+
TESTE
+
OBSERVABILIDADE

Conhecimento deve guiar a procura.

Não substituir a prova.

Senão saímos do Teorema do Macaco Infinito e entramos no Teorema do Sysprog Convencido:

dado tempo suficiente, ele acabará culpando a aplicação.


🧑‍💻 Capítulo XXVI — Cinco dicas práticas do macaco para quem está começando em COBOL

A primeira é simples:

antes de escrever código, reduza o problema.

Não tente resolver o Universo inteiro.

Descubra entradas, saídas, regras e condições.

Depois, quando der erro, não procure aleatoriamente.

Pergunte:

O QUE MUDOU?
QUAL FOI A ENTRADA?
QUAL FOI A MENSAGEM?
QUAL ROTINA EXECUTOU?
QUAL ERA O ESTADO ANTERIOR?

Terceiro:

aprenda a reconhecer padrões.

ABENDs, return codes, file status, SQLCODE, mensagens do sistema: cada informação reduz possibilidades.

Quarto:

meça complexidade.

Um processamento que funciona para mil registros pode virar pesadelo com cem milhões.

Quinto:

não confunda força computacional com inteligência.

Às vezes comprar mais CPU apenas permite executar uma estratégia ruim mais rapidamente.

Um milhão de macacos ainda são macacos.


☕ Capítulo XXVII — O café finalmente chega

Depois de toda essa aventura podemos retornar ao começo.

A frase:

“Um milhão de macacos diante de máquinas de escrever acabariam produzindo Shakespeare”

é uma versão popular de uma família de ideias probabilísticas cujo uso moderno da metáfora remonta especialmente a Émile Borel, no início do século XX. Borel empregava macacos datilógrafos para tornar intuitivas probabilidades extraordinariamente pequenas; posteriormente, Shakespeare tornou-se o alvo cultural favorito da metáfora. (Wikipedia)

Matematicamente, sob as condições do modelo ideal, uma sequência finita acaba aparecendo quase certamente quando o número de tentativas independentes cresce sem limite. (Opus)

Fisicamente, contudo, temos um pequeno inconveniente:

não possuímos infinito.

Temos orçamento.

Temos prazo.

Temos CPU.

Temos memória.

Temos energia.

Temos Universo.

E aparentemente todos eles possuem limite.


🐒 Epílogo — MONKEY01 entrou em produção

No último andar do CPD, a equipe finalmente inicia o job.

//MONKEY01 JOB ...
//STEP01   EXEC PGM=SHAKESPEARE

O operador acompanha.

Cinco minutos.

Nada.

Uma hora.

Nada.

Um ano.

Nada.

Um milhão de anos.

Nada.

Bilhões de anos.

As estrelas desaparecem.

Buracos negros evaporam.

O Universo caminha lentamente para a escuridão.

Então, subitamente:

TO BE OR NOT TO BE...

O operador, que por alguma razão inexplicável ainda está de plantão, abre um chamado:

INCIDENTE:
OUTPUT INESPERADO ENCONTRADO.

SEVERIDADE:
BAIXA.

AÇÃO:
ENCAMINHAR PARA APLICAÇÃO.

O programador COBOL olha o texto.

Olha o macaco.

Olha novamente.

E percebe a verdadeira lição de Borel.

O impossível talvez não seja realmente impossível.

Mas existe uma quantidade enorme de coisas que são tão improváveis que esperar por elas é uma arquitetura extremamente ruim.

E talvez toda a história da computação seja, em certa medida, nossa tentativa de derrotar o macaco.

Índices dizem:

não procure tudo.

Algoritmos dizem:

organize a procura.

Heurísticas dizem:

comece pelo provável.

Experiência diz:

eu já vi algo parecido.

Machine learning diz:

aprendi quais caminhos costumam funcionar.

Modelos de linguagem dizem:

dado tudo que veio antes, algumas continuações fazem muito mais sentido que outras.

E o velho programador COBOL diante da máquina de café simplesmente diz:

— Antes de fazer qualquer coisa, mostra o log.

Talvez essa seja uma das formas mais puras de inteligência.

Não possuir todas as respostas.

Mas saber onde não vale a pena procurar.

No fundo, Émile Borel colocou um macaco diante de uma máquina de escrever e acabou nos ensinando algo sobre matemática, entropia, algoritmos, produção, experiência, linguagem e inteligência artificial.

O macaco jamais pediu toda essa responsabilidade.

Ele só queria uma banana.

E alguém colocou um teclado na frente dele.

☕🐒⌨️

MONKEY01 ENDED - MAXCC=0000

Finalmente.

Shakespeare foi produzido.

Tempo total:

∞

O financeiro recusou a fatura.


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...