☕ 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

segunda-feira, 24 de junho de 2024

🚨 Os 12 Macacos, COBOL e o Tribunal da Timeline ARCO I — CAPÍTULO VI

 

Bellacosa Mainframe e os 12 macacos

☕ Um Café no Bellacosa Mainframe

🚨 Os 12 Macacos, COBOL e o Tribunal da Timeline

ARCO I — CAPÍTULO VI

Quando a denúncia viralizou antes de os fatos terminarem de carregar

Na Internet, às vezes o VERDICT termina de executar enquanto o READ EVIDENCE ainda está esperando I/O.



🕰️ 05:01 — THE DIGITAL TRIBUNAL IS NOW IN SESSION

No capítulo anterior, nosso COBOLzeiro descobriu uma verdade desagradável.

Não existe filtro perfeito.

Não existe IA perfeita.

Não existe moderador perfeito.

E, principalmente:

PERFECT HUMAN........ DEFINITELY NOT FOUND

Palavras viraram códigos.

Códigos viraram emojis.

Emojis viraram memes.

Memes viraram referências internas.

A plataforma aprendeu.

A comunidade adaptou.

O algoritmo observou os usuários.

Os usuários aprenderam a observar o algoritmo.

Tudo perfeitamente caótico.

Nosso herói já estava começando a aceitar que talvez o universo digital fosse simplesmente um gigantesco programa COBOL escrito por alguém que abusou de GO TO.

Até que apareceu:

TRENDING NOW

Milhares de mensagens começaram a subir.

Facebook.

Instagram.

WhatsApp.

Discord.

Reddit.

X.

Twitch.

Telegram.

Vídeos.

Screenshots.

Influenciadores.

Jornalistas.

Comentaristas.

Especialistas.

Supostos especialistas.

Pessoas que descobriram o caso sete minutos atrás.

E pessoas que, aparentemente, já sabiam exatamente quem era culpado.

O terminal perguntou:

LOAD DIGITAL TRIBUNAL? Y/N

Nosso COBOLzeiro cometeu o erro.

Y

ENTER.

A tela ficou preta.

Então surgiu:

WARNING:

EVERYONE HAS A VERDICT.

WE ARE STILL LOOKING
FOR THE EVIDENCE.

Bruce Willis colocou outra garrafa de café sobre a mesa.

— Vamos precisar.



⚡ 1. A Internet possui uma característica que o Direito não consegue acompanhar facilmente

Velocidade.

Uma denúncia pode nascer às 08:00.

Às 08:03 alguém captura um screenshot.

08:07:

POST

08:11:

REPOST

08:16:

THREAD

08:24:

HASHTAG

08:41:

INFLUENCER REACTION

09:05:

TRENDING

10:30:

NEWS PORTAL

12:00:

TELEVISION

14:00:

"ENTENDA O CASO"

Nosso programador interrompe.

— Espere.

— O quê?

— Quando aconteceu a investigação?

Bruce Willis aponta para a tela.

INVESTIGATION STATUS:
UNKNOWN

— E as provas?

PARTIAL

— Então como existe "entenda o caso"?

Bruce toma café.

— Bem-vindo à timeline.



🧠 2. O cérebro humano odeia STATUS = UNKNOWN

Existe uma coisa que seres humanos parecem detestar:

UNKNOWN

Queremos histórias.

Causa.

Culpado.

Motivo.

Começo.

Meio.

Fim.

Uma investigação real frequentemente começa assim:

WHAT HAPPENED?........ UNKNOWN
WHO DID IT?........... UNKNOWN
WHY?.................. UNKNOWN
HOW MANY PEOPLE?...... UNKNOWN
WHEN?................. PARTIAL
EVIDENCE?............. COLLECTING

Terrível para televisão.

Péssimo para uma thumbnail.

Horrível para engajamento.

Então surge uma tentação:

preencher os espaços vazios.


🧩 3. E quando faltam fatos, entram inferências

Imagine:

FACT A
FACT B
??????
FACT D

A Internet não gosta do ??????.

Então alguém publica:

"OBVIAMENTE C."

Outro responde:

"Faz sentido."

Outro:

"Eu já desconfiava."

Outro:

"Todo mundo sabe."

Pouco depois:

C = FACT

Mas C nunca foi fato.

Era hipótese.

Acabamos de testemunhar um dos processos mais perigosos da informação viral:

a solidificação da inferência.


🗃️ 4. O boato ganha tipo de dado errado

Nosso COBOLzeiro reconhece imediatamente.

Imagine:

01 INFORMATION.
   05 FACT       PIC X.
   05 RUMOR      PIC X.
   05 HYPOTHESIS PIC X.

Perfeito.

Só que a Internet faz:

MOVE HYPOTHESIS TO FACT.

Sem validação.

Sem IF.

Sem 88-LEVEL.

Sem vergonha.

Depois grava:

WRITE PUBLIC-OPINION.

Agora temos problema.


📸 5. O screenshot chega à War Room

Alguém publica uma captura de tela.

Nosso programador pergunta:

— Autêntica?

UNKNOWN

— Completa?

UNKNOWN

— Qual data?

PARTIAL

— O que veio antes?

NOT AVAILABLE

— O que veio depois?

NOT AVAILABLE

— Quem capturou?

UNKNOWN

— Então o que sabemos?

SCREENSHOT EXISTS.

Isso pode ser importante.

Mas é muito diferente de:

SCREENSHOT PROVES EVERYTHING.

🖼️ 6. A imagem tem uma autoridade psicológica impressionante

Texto:

"Fulano disse X."

Nosso cérebro talvez responda:

Será?

Agora aparece um screenshot aparentemente mostrando:

Fulano: X.

A sensação muda.

Aha!

Vimos!

Só existe um problema.

Em 2026, produzir uma imagem convincente de uma interface digital não exige acesso ao mainframe da NSA.

Editar imagens nunca foi novidade.

Mas IA generativa tornou produção e alteração de artefatos sintéticos ainda mais acessível.

Então o velho princípio fica mais importante:

SEEING
!=
VERIFYING

🤖 7. Agora existe evidência sintética

O Bellacosa Mainframe recebe:

IMAGE
AUDIO
VIDEO
SCREENSHOT
TEXT LOG

Nosso programador pergunta:

— Qual é verdadeiro?

O sistema responde:

ANALYSIS REQUIRED.

Áudio pode ser manipulado.

Imagem pode ser fabricada.

Vídeo pode ser editado.

Texto pode ser reconstruído.

Até algo verdadeiro pode ser apresentado fora de contexto.

Isso significa que precisamos pensar em:

proveniência.

De onde veio?

Quando?

Quem produziu?

Foi alterado?

Existe original?

Existem registros independentes?

A evidência digital agora precisa carregar passaporte.


📰 8. E então o jornalista recebe o material

Aqui voltamos ao paradoxo da revista do Capítulo II.

Um jornalista recebe uma denúncia.

Talvez seja gravíssima.

Ele possui duas responsabilidades que podem entrar em tensão:

PUBLIC INTEREST

e:

VERIFICATION

Publicar rápido pode alertar pessoas.

Publicar cedo demais pode espalhar informação incorreta.

Esperar pode permitir continuidade de um risco.

Não verificar pode destruir inocentes.

Não existe:

PERFORM JOURNALISM
UNTIL TRUTH

Jornalismo trabalha com tempo, fontes, evidências e incerteza.

E agora compete com milhões de pessoas que não precisam esperar editor algum.


📱 9. O cidadão com smartphone virou emissora

Em outra época, atingir milhões de pessoas exigia infraestrutura.

Gráfica.

Rádio.

Televisão.

Distribuição.

Hoje:

USER
  +
PHONE
  +
NETWORK
  =
POTENTIAL BROADCASTER

Isso democratizou comunicação de maneira extraordinária.

Denúncias que poderiam ser enterradas ganharam voz.

Abusos puderam ser documentados.

Testemunhas puderam publicar.

Mas a mesma infraestrutura permite:

  • boatos;

  • montagens;

  • acusações falsas;

  • recortes;

  • manipulações;

  • perseguições.

A ferramenta amplifica o humano.

Infelizmente ela não verifica caráter antes de instalar.


🚨 10. Denúncia pública pode ser necessária

É importante não cair no extremo oposto.

Existem situações em que denúncias públicas tiveram enorme importância social.

Jornalismo investigativo.

Movimentos de vítimas.

Whistleblowers.

Testemunhas.

Documentação de abusos.

A possibilidade de falar publicamente é parte fundamental de uma sociedade democrática.

O problema não é:

DENUNCIATION = BAD

O problema é confundir:

ALLEGATION

com:

PROVEN FACT

São registros diferentes.

Preserve o RECORD TYPE.


⚖️ 11. Presunção de inocência entra no CPD

No Brasil, a Constituição estabelece uma garantia fundamental relacionada à presunção de inocência.

Isso pertence ao sistema jurídico.

Mas existe um problema interessante:

a timeline não possui Constituição própria.

Ela possui:

LIKE
SHARE
REPOST
COMMENT
TRENDING

Não existe botão:

WAIT FOR DUE PROCESS

Nosso programador procura.

Nada.

— Está escondido nas configurações?

Bruce Willis responde:

— Não.

— Feature request?

— Talvez para a humanidade.


🔨 12. O martelo do juiz e o botão de repost não são equivalentes

Uma decisão judicial emerge de um processo institucional.

Uma conclusão viral emerge de outra arquitetura.

Compare:

EVIDENCE
   |
INVESTIGATION
   |
PROCEDURE
   |
ARGUMENT
   |
DECISION

com:

SCREENSHOT
   |
OUTRAGE
   |
REPOST
   |
TRENDING
   |
"EVERYONE KNOWS"

Ambos podem produzir crenças.

Mas apenas um deles foi construído institucionalmente para decidir responsabilidades jurídicas.

Isso não torna tribunais infalíveis.

Torna evidente que timeline não é tribunal.


🏛️ 13. O devido processo é lento por design

Nosso COBOLzeiro reclama:

— Mas isso demora.

Sim.

Investigar demora.

Verificar demora.

Ouvir partes demora.

Analisar provas demora.

Recursos demoram.

É frustrante.

Mas existe uma razão para não termos:

IF ACCUSATION > 10000 LIKES
   MOVE GUILTY TO VERDICT
END-IF

Popularidade não é padrão probatório.

Viralidade não é cadeia de custódia.

Hashtag não é sentença.


🧒 14. Então aparecem crianças e adolescentes

O terminal muda novamente:

MINORS INVOLVED: POSSIBLE

Silêncio.

Aqui o cuidado precisa aumentar.

Quando existem menores, a exposição pública pode produzir danos adicionais.

Identificação.

Constrangimento.

Revitimização.

Assédio.

Perseguição.

Curiosidade pública.

Reprodução irresponsável de material.

No Brasil, o ECA estabelece proteção especial a crianças e adolescentes.

Então "estou denunciando" não é licença para transformar vítima em conteúdo.


🛡️ 15. Proteger a vítima não exige publicar tudo

Esse conceito é fundamental.

Imagine que determinada denúncia envolva material sensível.

Uma pessoa decide:

"Vou mostrar para provar."

Pare.

Existe diferença entre:

REPORT EXISTENCE OF EVIDENCE

e:

REPUBLISH HARMFUL MATERIAL

Denunciar não exige necessariamente reproduzir.

Jornalismo responsável conhece esse princípio há décadas.

Em ambientes digitais, porém, a tentação de mostrar "a prova" pode gerar uma segunda circulação do próprio dano.

O vírus informacional sorri novamente.


🦠 16. A denúncia pode carregar o objeto denunciado

Este é um dos paradoxos mais perturbadores de toda a série.

Alguém encontra conteúdo problemático.

Fica indignado.

Captura.

Publica:

"OLHEM O ABSURDO!"

Agora o conteúdo possui uma nova cópia.

Outra pessoa reposta denunciando.

Outra salva como evidência informal.

Outra compartilha num grupo:

"Vocês viram isso?"

Temos:

ORIGINAL
   |
   v
DENUNCIATION COPY
   |
   +--> REPOST
   +--> SCREENSHOT
   +--> VIDEO REACTION
   +--> NEWS COVERAGE

Todos talvez condenando.

Mas tecnicamente:

a circulação aumentou.


📢 17. Condenação e amplificação podem coexistir

Essa frase precisa ficar gravada no terminal:

CONDEMNATION
CAN PRODUCE
AMPLIFICATION.

Isso não significa que devemos ficar em silêncio diante de problemas.

Significa que precisamos pensar como comunicar.

Podemos alertar sem transformar alerta em catálogo.

Podemos denunciar sem fornecer caminhos desnecessários.

Podemos explicar sem reproduzir material prejudicial.

Podemos informar sem transformar curiosidade em tutorial.

O Capítulo II acaba de voltar pela porta dos fundos.


💥 18. Efeito Streisand entra na sala

Existe ainda o famoso efeito Streisand.

Tentativas de esconder, remover ou suprimir determinada informação podem, em algumas circunstâncias, aumentar enormemente a atenção sobre ela.

Antes:

PEOPLE WHO KNOW = 500

Depois da tentativa pública de remoção:

"WHAT ARE THEY TRYING TO HIDE?"

Agora:

PEOPLE SEARCHING = 500000

Não é uma lei física.

Nem toda remoção gera Streisand.

Mas é um risco comunicacional real.

Principalmente quando a própria tentativa de supressão vira notícia.


🔍 19. A curiosidade é o motor de busca mais antigo

Antes do Google havia curiosidade.

Antes da Internet havia curiosidade.

Antes da escrita provavelmente alguém dizia:

"Não entre naquela caverna."

E outro humano imediatamente perguntava:

"Por quê?"

O aviso:

DO NOT SEARCH X

contém:

SEARCH TERM = X

Nosso COBOLzeiro olha para Bruce Willis.

— Isso é um bug humano?

— Feature.

— Podemos corrigir?

— Tentamos há alguns milhares de anos.


📰 20. "Não procure isso" pode ser uma query pronta

A imprensa diz:

"Autoridades alertam para o perigoso fenômeno chamado XYZ."

Milhões de pessoas:

SEARCH "XYZ"

Algumas querem entender.

Algumas são jornalistas.

Algumas são pesquisadores.

Algumas são pais.

Algumas são simplesmente curiosas.

E algumas podem estar procurando exatamente o fenômeno denunciado.

O comunicador não controla a intenção de quem recebe a informação.

Essa é uma das razões pelas quais granularidade importa tanto.


📺 21. O telejornal abre a porta da curiosidade

Imagine uma reportagem:

"Existe uma comunidade secreta chamada..."

Pausa.

Nosso COBOLzeiro levanta da cadeira.

— NÃO DIGA!

O apresentador diz.

O nome aparece em letras gigantes.

A reportagem mostra a interface.

Mostra termos.

Mostra símbolos.

Mostra onde usuários se reúnem.

Talvez tudo isso seja jornalisticamente justificável em determinado contexto.

Mas existe um efeito colateral:

DISCOVERABILITY++

A denúncia também funcionou como indexador.


🔎 22. SEO não possui consciência moral

Mecanismos de busca não perguntam necessariamente:

"Por que essa pessoa quer saber?"

Uma notícia gera buscas.

Buscas geram conteúdo.

Conteúdo gera páginas.

Páginas geram links.

Links geram indexação.

NEWS
  |
SEARCH
  |
CONTENT
  |
LINKS
  |
INDEX
  |
MORE SEARCH

A denúncia pode acabar construindo a infraestrutura semântica pela qual futuras pessoas encontrarão o assunto.

Nosso programador olha horrorizado.

— Então o índice também participa da epidemia?

Bruce responde:

— Agora você está entendendo.


🤖 23. E os recomendadores chegam

Pior.

O usuário procura uma coisa.

A plataforma aprende:

USER INTEREST = X

Então recomenda:

RELATED X1
RELATED X2
RELATED X3

O usuário não precisava saber que X2 existia.

Agora sabe.

Aqui surge uma distinção fundamental:

SEARCH

é alguém procurando algo.

RECOMMENDATION

é o sistema trazendo algo até alguém.

Essa diferença é gigantesca.


🎯 24. Da busca para a descoberta algorítmica

Na velha Internet:

I WANT X
   |
   v
I SEARCH X

Na Internet algorítmica:

I WATCH A
   |
   v
SYSTEM INFERS B
   |
   v
SYSTEM SHOWS C
   |
   v
I DISCOVER X

Você não procurou X.

X encontrou você.

Nosso COBOLzeiro olha para Bruce Willis.

— Quem autorizou isso?

— Você aceitou os termos.

— Aqueles que ninguém lê?

— Aqueles mesmos.


📈 25. O algoritmo não precisa concordar para amplificar

Este ponto é importante.

Um sistema de recomendação não precisa possuir ideologia, intenção ou opinião humana para ampliar determinado conteúdo.

Pode simplesmente otimizar alguma métrica:

  • retenção;

  • cliques;

  • visualização;

  • interação;

  • relevância prevista.

Conteúdo indignante pode gerar interação.

Conteúdo controverso pode gerar comentários.

Conteúdo chocante pode prender atenção.

Então:

OUTRAGE
   |
   v
ENGAGEMENT
   |
   v
VISIBILITY

pode surgir como efeito sistêmico.

Não porque alguém apertou:

PROMOTE EVIL

Mas porque métricas possuem consequências.


🧠 26. O algoritmo aprende que estamos indignados — e conclui que gostamos

Imagine que você odeie determinado assunto.

Toda vez que aparece:

  • abre;

  • lê;

  • comenta;

  • responde;

  • compartilha criticando.

Para o sistema:

USER INTERACTED = TRUE

A máquina pode não compreender sua indignação da mesma forma que outro humano compreenderia.

Então mostra mais.

Você fica mais indignado.

Interage mais.

OUTRAGE
   |
ENGAGEMENT
   |
RECOMMENDATION
   |
MORE OUTRAGE
   |
MORE ENGAGEMENT

Encontramos outro loop.

Os 12 Macacos abriram champanhe.


🔥 27. DO NOT FEED THE ALGORITHM

Talvez uma das frases mais úteis da Internet moderna seja:

DO NOT FEED
WHAT YOU DON'T WANT
TO AMPLIFY.

Mas isso não significa ignorar crimes, abusos ou riscos.

Significa distinguir entre:

REPORT

e:

AMPLIFY

Denunciar à plataforma ou às autoridades apropriadas pode ser necessário.

Transformar tudo em espetáculo público pode produzir consequências completamente diferentes.


🎭 28. O influenciador entra no incidente

Agora surge alguém com dois milhões de seguidores.

Ele recebe um screenshot.

Publica:

"ISSO É ABSURDO!"

Dois milhões de pessoas recebem.

Algumas denunciam.

Algumas atacam.

Algumas procuram o acusado.

Algumas procuram a comunidade.

Algumas tentam encontrar o conteúdo original.

A intenção do influenciador pode ter sido:

CONDEMN

O efeito inclui:

AMPLIFY

Intenção e efeito não são campos idênticos.

Essa é uma lição brutal.


⚠️ 29. A multidão encontra o suspeito

Alguém publica nome.

Outro encontra perfil.

Outro acha endereço antigo.

Outro encontra familiares.

Outro encontra empregador.

Outro encontra telefone.

Agora saímos de:

DISCUSSION

e entramos em território muito mais perigoso.

Assédio.

Ameaças.

Exposição indevida de dados.

Possíveis erros de identidade.

Linchamento digital.

Nosso COBOLzeiro grita:

— Parem!

Ninguém ouve.

A timeline não possui PAUSE.


👤 30. O problema do homônimo

Imagine:

SUSPECT NAME = JOÃO SILVA

Boa sorte.

Alguém encontra um João Silva.

Foto parece vagamente compatível.

Publica:

"É ESTE."

Milhares compartilham.

Só existe um pequeno detalhe.

Não é.

Agora temos uma vítima nova.

Criada pela investigação coletiva.

O sistema começou com uma denúncia sobre possível dano.

E produziu outro dano.


🧯 31. Incident Response sem Change Control

Nosso COBOLzeiro finalmente entende o que o incomoda.

A timeline é uma War Room onde:

  • todo mundo possui teclado;

  • ninguém possui coordenador;

  • hipóteses são públicas;

  • evidências são copiadas;

  • alterações são irreversíveis;

  • logs são incompletos;

  • milhões observam;

  • ninguém possui botão de rollback.

Ele escreve:

SOCIAL MEDIA INCIDENT RESPONSE

CHANGE CONTROL........ NONE
ROOT CAUSE............ UNKNOWN
COMMUNICATION......... CHAOTIC
AUDIENCE.............. MILLIONS
ROLLBACK.............. IMPOSSIBLE

Depois:

SEVERITY = OH-MY-GOD

🕵️ 32. Investigação coletiva pode ajudar — e também contaminar

Comunidades online já ajudaram a identificar lugares, objetos, datas e informações públicas.

Inteligência coletiva pode ser extraordinária.

Mas existe risco.

Pessoas podem:

  • interpretar errado;

  • pressionar testemunhas;

  • espalhar pistas falsas;

  • identificar inocentes;

  • contaminar narrativas;

  • destruir contexto.

Então:

CROWDSOURCING

não equivale automaticamente a:

INVESTIGATION

É ferramenta.

Não instituição.


🧾 33. Preservar é diferente de publicar

Uma pessoa encontra algo potencialmente relevante.

Existem dois verbos:

PRESERVE

e:

PUBLISH

Eles não são sinônimos.

Dependendo do caso, preservar informações e encaminhá-las pelos canais adequados pode ser muito mais responsável que publicar para milhares de pessoas.

Principalmente quando existem:

  • menores;

  • vítimas;

  • material sensível;

  • acusações graves;

  • investigações.

Nem toda evidência precisa virar conteúdo.


🧒 34. Quando há menores, SHARE pode ser exatamente o botão errado

Esse ponto merece letras gigantes.

PROTECT
!=
REPUBLISH

Se o objetivo é proteger criança ou adolescente, aumentar a circulação de material sensível pode contrariar o próprio objetivo.

O impulso:

"Vou compartilhar para denunciar"

precisa ser substituído por:

"Qual é a forma mais segura e eficaz de encaminhar isso sem ampliar o dano?"

Isso é maturidade digital.

E talvez seja uma das maiores diferenças entre denúncia responsável e espetáculo.


📡 35. Discord fecha o servidor

Agora imagine que a plataforma tome uma medida.

SERVER DISABLED

A timeline explode.

Grupo A:

"Prova de culpa!"

Grupo B:

"Censura!"

Grupo C:

"Tentativa de esconder!"

Nosso COBOLzeiro interrompe:

— Qual foi o motivo oficial?

Silêncio.

— A plataforma publicou?

Talvez não completamente.

Então temos novamente:

PLATFORM ACTION
!=
CRIMINAL CONVICTION

Um servidor pode ser removido por violação de políticas privadas.

Isso pode coincidir com conduta ilegal.

Ou não.

Precisamos conhecer os fatos.


🏃 36. E a comunidade migra

Lembra do Capítulo III?

Servidor fecha.

Usuários:

DISCORD
   X
   |
   +--> TELEGRAM
   |
   +--> WHATSAPP
   |
   +--> REDDIT
   |
   +--> NEW SERVER

A imprensa anuncia:

"Comunidade banida do Discord."

Milhares que nunca ouviram falar dela perguntam:

"Qual comunidade?"

Buscam.

Alguns encontram os novos endereços.

Novamente:

SUPPRESSION
+
PUBLICITY
=
POSSIBLE REDISCOVERY

Os 12 Macacos continuam migrando.


📰 37. A reportagem precisa decidir quanto mostrar

Chegamos ao dilema editorial.

Uma matéria pode dizer:

"Uma comunidade foi investigada por determinado comportamento."

Ou pode:

  • publicar nome;

  • mostrar logotipo;

  • exibir termos de busca;

  • mostrar interface;

  • reproduzir mensagens;

  • explicar códigos;

  • indicar plataformas;

  • mostrar convites.

Cada informação adicional pode possuir valor jornalístico.

Mas também pode aumentar:

DISCOVERABILITY

Não existe fórmula universal.

Existe responsabilidade editorial.


🧭 38. Informação suficiente para compreender, não necessariamente para reproduzir

Talvez possamos criar uma regra operacional útil:

INFORM
WITHOUT
UNNECESSARILY ENABLING

Explique o fenômeno.

Contextualize.

Apresente riscos.

Mostre consequências.

Indique formas seguras de denúncia.

Evite detalhes operacionais desnecessários quando eles apenas facilitariam acesso ao problema.

Isso vale para jornalismo.

Educação.

Blogs.

Vídeos.

E, sim, para Um Café no Bellacosa Mainframe.


☕ 39. O blog também faz parte do sistema

Nosso COBOLzeiro para.

Olha para a câmera.

Depois olha para nós.

— Espere.

Bruce Willis percebe.

— O quê?

— Estamos escrevendo sobre tudo isso.

Silêncio.

— Então também estamos amplificando?

Bruce responde:

— Potencialmente.

Nosso programador quase derruba o café.

É aqui que a série precisa olhar para si mesma.

Quando escrevemos sobre um fenômeno, entramos no fenômeno.

Podemos aumentar:

KNOWLEDGE

Mas também:

CURIOSITY

A responsabilidade está em como fazemos isso.


🧠 40. Educação não precisa ser tutorial de transgressão

Podemos explicar:

  • efeito Streisand;

  • migração de comunidades;

  • códigos;

  • moderação;

  • ECA;

  • liberdade;

  • algoritmos;

  • amplificação;

  • responsabilidade.

Sem fornecer:

STEP 1: GO HERE
STEP 2: SEARCH THIS
STEP 3: ENTER THIS GROUP

Existe uma diferença enorme entre:

alfabetização digital

e:

manual operacional.

Nosso veterano COBOL finalmente encontra uma especificação que gosta.


🧪 41. O teste das três perguntas

Antes de publicar informação sensível, nosso Bellacosa Mainframe cria um pequeno checklist.

01 - ESTA INFORMAÇÃO É NECESSÁRIA
     PARA COMPREENDER O FENÔMENO?

02 - ELA PODE CAUSAR DANO
     OU FACILITAR ACESSO INDEVIDO?

03 - EXISTE FORMA DE EXPLICAR
     SEM FORNECER O DETALHE OPERACIONAL?

Não é regra jurídica universal.

É uma heurística editorial.

Mas é útil.

Nosso COBOLzeiro batiza:

BELLACOSA THREE-QUESTION CHECK

Bruce Willis suspira.

— Você realmente precisa colocar seu nome em tudo?

— Branding.


🔔 42. O alerta vira propaganda involuntária

Agora voltamos à frase que iniciou tudo:

"NÃO PROCURE ISTO NA INTERNET."

Nosso sistema interpreta:

NEGATIVE COMMAND
+
SPECIFIC OBJECT
=
OBJECT DISCOVERY

É quase o clássico:

"Não pense num elefante rosa."

Pronto.

Elefante rosa.

A mente humana é irritante.

Dizer que algo existe já modifica o universo cognitivo do receptor.

Antes:

KNOWLEDGE = 0

Depois:

KNOWLEDGE = 1

Mesmo que a mensagem seja:

DO NOT ACCESS

📼 43. A velha revista retorna

Nosso COBOLzeiro abre uma gaveta.

Lá está uma revista antiga.

A matéria condenava determinado aspecto da Internet.

Alertava.

Explicava.

Mostrava.

Apresentava vocabulário.

Para o jornalista, aquilo era:

WARNING

Para um leitor curioso poderia funcionar como:

DISCOVERY GUIDE

Talvez ninguém tenha planejado isso.

Esse é justamente o ponto.

Efeitos não precisam ser intencionais para serem efeitos.

Aquela revista acaba de conectar 1990-e-alguma-coisa a Discord, IA e algoritmos de recomendação.

Os 12 Macacos fecham o círculo.


📺 44. O telejornal de ontem virou treinamento do buscador de amanhã

Antes, uma reportagem desaparecia parcialmente depois de transmitida.

Hoje ela pode:

  • ficar online;

  • ser indexada;

  • ser recortada;

  • aparecer em buscas;

  • ser transcrita;

  • ser recomendada;

  • virar vídeo de reação;

  • alimentar modelos;

  • aparecer anos depois.

O alerta não dura mais vinte minutos.

Pode durar décadas.

BROADCAST
   |
ARCHIVE
   |
INDEX
   |
SEARCH
   |
RECOMMEND
   |
AI RETRIEVAL

A mídia produz memória digital.

E memória digital é infraestrutura.


🤖 45. Agora a IA lê a velha reportagem

Aqui a coisa fica quase ficção científica.

Uma reportagem de décadas atrás é digitalizada.

Indexada.

Recuperada.

Uma IA consulta.

Resume.

Relaciona com outra fonte.

Um usuário pergunta:

"O que era aquilo?"

O sistema responde.

Informação enterrada volta à superfície.

Nosso COBOLzeiro olha para Bruce Willis.

— Então nada morre?

Bruce responde:

— Não exatamente.

— Mas pode voltar?

— Sim.

Ele olha para o terminal.

ARCHIVE != GRAVEYARD

Excelente frase para colocar numa camiseta.


🧬 46. A Internet possui memória seletiva e amnésia simultaneamente

Paradoxo delicioso.

Coisas importantes desaparecem.

Links quebram.

Sites fecham.

Serviços morrem.

Ao mesmo tempo, uma frase idiota escrita em 2009 reaparece quinze anos depois.

A Internet consegue ser simultaneamente:

FORGETFUL

e:

UNFORGIVING

É um sistema de memória projetado por um roteirista bêbado.

Perfeitamente adequado para Os 12 Macacos.


⚖️ 47. A reputação não possui ROLLBACK

Imagine acusação viral.

Depois:

CORRECTION PUBLISHED

Ótimo.

Quantas pessoas viram a acusação?

5,000,000

Quantas viram a correção?

83,000

Temos:

ORIGINAL REACH >> CORRECTION REACH

Mesmo que a informação seja corrigida, o dano reputacional pode continuar.

Nosso programador pergunta:

— Restauramos backup?

Bruce Willis responde:

— De uma reputação?

— Sim.

— Não temos.

Ele fica em silêncio.

Mainframe nunca pareceu tão confortável.


🧯 48. Comunicação de crise precisa considerar assimetria

Quando uma informação falsa viraliza, simplesmente publicar:

"Correção: não era bem assim."

pode ser insuficiente.

Organizações precisam pensar em:

  • alcance;

  • velocidade;

  • clareza;

  • evidência;

  • canais;

  • atualização;

  • transparência.

É incident response aplicado à informação.

DETECT
CONTAIN
VERIFY
COMMUNICATE
CORRECT
MONITOR
LEARN

Agora estamos falando a língua do COBOLzeiro.


🚨 49. Mas cuidado com MONITOR

Monitorar não significa vigiar toda a sociedade.

A palavra pode parecer inocente em TI.

MONITOR TRANSACTIONS

Normal.

Mas aplicada a pessoas:

MONITOR EVERYONE

entramos em outra discussão.

Privacidade.

Proporcionalidade.

Direitos.

Governança.

A solução para riscos digitais não pode simplesmente ser transformar a Internet num gigantesco panóptico.

Os valores do Capítulo IV continuam rodando em background.


🔐 50. Segurança e liberdade precisam coexistir

É tentador pensar em dois botões:

[ LIBERDADE ]
[ SEGURANÇA ]

Escolha um.

Mas sociedades democráticas precisam tentar executar ambos.

PERFORM FREEDOM
PERFORM SAFETY

com conflitos, limites e controles.

É difícil.

É imperfeito.

É frustrante.

Mas soluções simples para sistemas humanos complexos geralmente escondem custos que aparecem depois em produção.

Todo programador veterano sabe disso.


🐒 51. Finalmente encontramos os 12 Macacos?

05:42.

O terminal exibe:

SEARCH COMPLETE.

12 MONKEYS IDENTIFIED.

Nosso COBOLzeiro levanta.

— Finalmente!

Bruce Willis se aproxima.

A tela mostra:

MONKEY 01: CURIOSITY
MONKEY 02: VIRALITY
MONKEY 03: OUTRAGE
MONKEY 04: RUMOR
MONKEY 05: CONTEXT COLLAPSE
MONKEY 06: ALGORITHMIC AMPLIFICATION
MONKEY 07: SOCIAL MIGRATION
MONKEY 08: CODED LANGUAGE
MONKEY 09: AUTOMATION BIAS
MONKEY 10: FALSE CERTAINTY
MONKEY 11: PUBLIC SHAMING
MONKEY 12: UNINTENDED AMPLIFICATION

Silêncio.

Nosso programador olha para Bruce Willis.

— Então não eram pessoas?

— Nunca precisaram ser.


🧠 52. O vírus também não era uma informação específica

O terminal continua:

VIRUS IDENTIFICATION:

NOT A FILE.
NOT A POST.
NOT A PLATFORM.
NOT A USER.
NOT A WEBSITE.

— Então o que é?

Nova linha:

A SELF-REINFORCING
INFORMATION SYSTEM.

A metáfora finalmente fecha.

O vírus desta história não é um arquivo proibido.

É o sistema pelo qual:

INFORMATION
   |
CURIOSITY
   |
SEARCH
   |
DISCOVERY
   |
SHARING
   |
ALGORITHM
   |
AMPLIFICATION
   |
MEDIA
   |
MORE CURIOSITY

retroalimenta a si próprio.


🔄 53. O loop completo

Nosso COBOLzeiro escreve no quadro:

0000-INFORMATION-LOOP.

    PERFORM DISCOVERY.

    PERFORM CURIOSITY.

    PERFORM SEARCH.

    PERFORM SOCIAL-SHARING.

    PERFORM MEDIA-COVERAGE.

    PERFORM ALGORITHMIC-AMPLIFICATION.

    PERFORM MODERATION.

    PERFORM COMMUNITY-ADAPTATION.

    PERFORM PUBLIC-REACTION.

    GO TO 0000-INFORMATION-LOOP.

Bruce Willis observa.

— Você acabou de colocar a Internet num GO TO.

— Sim.

— Isso explica muita coisa.


🛑 54. Como quebrar o loop?

Nosso herói pergunta:

— Então desligamos a Internet?

NO.

— Censuramos tudo?

NO.

— Proibimos redes sociais?

NO.

— Removemos anonimato?

NO.

— Monitoramos todo mundo?

ABSOLUTELY NOT.

— Então?

O terminal responde:

REDUCE UNNECESSARY AMPLIFICATION.

VERIFY BEFORE ACCUSING.

PROTECT VICTIMS.

PRESERVE CONTEXT.

USE APPROPRIATE REPORTING CHANNELS.

DISTINGUISH POLICY FROM LAW.

DISTINGUISH ALLEGATION FROM FACT.

DESIGN SAFER SYSTEMS.

EDUCATE USERS.

KEEP HUMAN JUDGMENT.

RESPECT RIGHTS.

Nosso programador sorri.

— Isso parece trabalhoso.

Bruce Willis responde:

— Democracia também.


☕ 55. O café finalmente esfria

Pela primeira vez desde o Capítulo I, nenhuma luz vermelha pisca.

Nenhum servidor explode.

Nenhuma IA pede revisão.

Nenhum emoji aparece.

Nosso COBOLzeiro olha para sua caneca.

O café está frio.

Ele bebe mesmo assim.

Profissional de produção não desperdiça cafeína.

Bruce Willis pergunta:

— O que você aprendeu?

Ele pensa.

— Que a Internet não é um computador.

— Continue.

— É um sistema sociotécnico.

Bruce levanta a sobrancelha.

— Bonito.

— Pessoas, empresas, algoritmos, leis, comunidades, mídia, cultura, curiosidade...

— E?

Nosso programador aponta para a tela.

— E todo mundo altera o estado do sistema.


🏗️ 56. Não existe SYSADM da Internet

Essa talvez seja a maior diferença entre o universo mainframe e a sociedade digital.

No mainframe alguém possui responsabilidades relativamente definidas.

Sysprog.

Security.

DBA.

Operação.

Desenvolvimento.

Auditoria.

Na Internet global:

WHO IS SYSADM?

Resposta:

NO SINGLE SYSADM EXISTS.

Estados possuem jurisdição.

Plataformas possuem infraestrutura.

Comunidades possuem regras.

Usuários possuem escolhas.

Nenhum controla tudo.

O sistema é distribuído não apenas tecnicamente.

É distribuído institucionalmente.


🌐 57. A Internet é o maior sistema legado da humanidade

Nosso COBOLzeiro olha para Bruce Willis.

— Acho que entendi.

— O quê?

— Internet é legado.

Bruce quase engasga.

— Como?

— Protocolos antigos, tecnologias novas, compatibilidade histórica, bilhões de usuários, regras adicionadas depois, componentes que ninguém pode desligar, documentação incompleta e dependências que ninguém conhece completamente.

Silêncio.

Ele continua:

— E todo mundo quer modernizar sem parar produção.

Bruce Willis olha para a câmera.

Talvez aquele homem tenha finalmente enlouquecido.

Ou talvez tenha entendido tudo.


🐒 58. Easter egg: DELETE INTERNET

Nosso herói decide tentar uma última vez.

DELETE INTERNET

Resposta:

IKJ56700A ENTER DATA SET NAME

Ele digita:

INTERNET

Resposta:

DATA SET INTERNET NOT IN CATALOG

Bruce começa a rir.

O programador tenta:

DELETE INTERNET PURGE

Resposta:

INVALID COMMAND.

Ele pensa.

Depois:

CANCEL INTERNET
JOB INTERNET NOT FOUND.

Finalmente:

SHUTDOWN INTERNET

O terminal demora.

Então responde:

INSUFFICIENT AUTHORITY.

ALSO:

BAD IDEA.

Ele desiste.


📼 59. A fita que ninguém deveria assistir

Bruce Willis encontra uma velha fita VHS.

Na etiqueta:

DO NOT WATCH

Os dois olham.

Silêncio.

Nosso COBOLzeiro pergunta:

— Assistimos?

Bruce responde:

— Depois de seis capítulos sobre curiosidade humana?

— Justamente.

Ele coloca a fita no aparelho.

Bruce fecha os olhos.

— Nós não aprendemos nada.

A televisão acende.

Terry Gilliam provavelmente sorri em algum lugar do multiverso.


🕰️ 60. A mensagem final

Na televisão não aparece vídeo.

Apenas texto verde.

BELLACOSA INFORMATION CONTROL FACILITY
---------------------------------------

FINAL INCIDENT REPORT

SUBJECT:
THE INFORMATION OUTBREAK

ROOT CAUSE:
NOT SINGLE

CONTRIBUTING FACTORS:

HUMAN CURIOSITY
MEDIA EXPOSURE
SEARCH ENGINES
SOCIAL NETWORKS
ALGORITHMIC RECOMMENDATION
COMMUNITY MIGRATION
CODED LANGUAGE
MODERATION FEEDBACK
OUTRAGE
RUMOR
PUBLIC ACCUSATION
UNINTENDED AMPLIFICATION

---------------------------------------

IMPORTANT:

CENSORSHIP
IS NOT THE SAME AS
MODERATION.

MODERATION
IS NOT THE SAME AS
CRIMINAL LAW.

ALLEGATION
IS NOT THE SAME AS
EVIDENCE.

EVIDENCE
IS NOT THE SAME AS
CONVICTION.

PRIVACY
IS NOT THE SAME AS
IMPUNITY.

FREEDOM
IS NOT THE SAME AS
ABSENCE OF RESPONSIBILITY.

DENUNCIATION
IS NOT THE SAME AS
REPUBLICATION.

CONDEMNATION
IS NOT THE SAME AS
NON-AMPLIFICATION.

---------------------------------------

CHILDREN AND ADOLESCENTS:

PROTECT.
DO NOT EXPLOIT.
DO NOT TURN VICTIMS
INTO CONTENT.

---------------------------------------

FINAL LESSON:

BEFORE YOU SHARE,
ASK WHAT YOUR SHARE
WILL DO TO THE SYSTEM.

---------------------------------------

Nosso COBOLzeiro permanece olhando.

Depois surge uma última frase:

THE VIRUS WAS NEVER
JUST THE INFORMATION.

THE VIRUS WAS THE LOOP.

A tela apaga.


☕ 61. Epílogo — RETURN-CODE = 00?

Bruce Willis pergunta:

— Terminou?

Nosso programador verifica.

ARC-I STATUS:
COMPLETE

— Parece que sim.

— Return code?

Ele olha.

RETURN-CODE = 04

Bruce estranha.

— Warning?

— Claro.

— Por quê?

Nosso COBOLzeiro pega a caneca.

— Porque terminamos o processamento.

— E?

Ele aponta para bilhões de usuários conectados.

— Os dados continuam mudando.

Bruce sorri.

Finalmente.

Uma resposta que qualquer profissional de produção compreenderia.


🖥️ FINAL DO ARCO I

BELLACOSA MAINFRAME
INFORMATION CONTROL FACILITY
=======================================

OS 12 MACACOS, COBOL
E O VÍRUS QUE NÃO CABIA NO RACF

ARCO I
=======================================

CHAPTER I
INFORMATION OUTBREAK......... COMPLETE

CHAPTER II
DISCOVERY PARADOX............ COMPLETE

CHAPTER III
DIGITAL TRIBES............... COMPLETE

CHAPTER IV
LAW AND FREEDOM.............. COMPLETE

CHAPTER V
SEMANTIC ARMS RACE........... COMPLETE

CHAPTER VI
DIGITAL TRIBUNAL............. COMPLETE

=======================================

FINAL STATUS:

INTERNET..................... ONLINE
HUMANS....................... ONLINE
CURIOSITY.................... ONLINE
ALGORITHMS................... ONLINE
MEDIA........................ ONLINE
LAW.......................... PROCESSING
MODERATION................... PROCESSING

12 MONKEYS................... EVERYWHERE

=======================================

LESSON:

YOU CANNOT CONTROL
AN INFORMATION ECOSYSTEM
BY TREATING IT
LIKE A SINGLE FILE.

=======================================

AND REMEMBER:

A WARNING CAN INFORM.

A WARNING CAN PROTECT.

A WARNING CAN ALSO
TEACH SOMEONE
WHAT TO SEARCH FOR.

THE DIFFERENCE
MAY BE IN THE DETAILS.

=======================================

RETURN-CODE.................. 04

REASON:

THE STORY IS COMPLETE.

THE SYSTEM IS NOT.

=======================================

Nosso COBOLzeiro aperta ENTER.

Nada acontece.

Ele aperta novamente.

Nada.

Bruce Willis pergunta:

— Travou?

— Não.

— Como sabe?

O programador aponta para a última linha.

NEXT ARC NOT YET LOADED.

Bruce sorri.

— Então existe outro arco?

O COBOLzeiro serve café.

— Sempre existe outro arco.

Na tela surge rapidamente uma interferência.

Por menos de um segundo aparece:

ARCHIVE SEARCH IN PROGRESS...

QUERY:

WHO DECIDES
WHAT THE INTERNET
IS ALLOWED TO REMEMBER?

Depois desaparece.

Nosso programador encara Bruce Willis.

Bruce encara o monitor.

A cafeteira começa a funcionar sozinha.

ARC II............... AVAILABLE

FIM DO ARCO I

🐒 RETURN-CODE = 04

A história terminou. O sistema, não.

🌑 IT Key Risk Indicators — Antes do ABEND, sempre existe um sinal

 


☕ Um Café no Bellacosa Mainframe

🌑 IT Key Risk Indicators — Antes do ABEND, sempre existe um sinal

Sob a batuta de Riddick: no escuro do datacenter, sobreviver não depende de enxergar tudo. Depende de perceber aquilo que os outros ainda não conseguem ver.

Existe uma cena recorrente em praticamente toda operação de TI.

03:17 da madrugada.

O telefone toca.

O monitor começa a piscar.

O grupo de mensagens acorda.

Alguém escreve:

PRODUÇÃO FORA.

Outro pergunta:

O que mudou?

Um terceiro responde:

Nada.

E essa talvez seja uma das respostas mais assustadoras que podem aparecer durante um incidente.

Porque alguma coisa mudou.

Talvez não às 03:17.

Talvez tenha começado três meses antes.

Um patch foi adiado.

Uma configuração temporária tornou-se permanente.

Um ticket envelheceu.

Depois outro.

Uma mudança emergencial foi aprovada.

Um deployment falhou.

Um backup apresentou erro.

Um teste de recuperação foi postergado.

A latência começou a aumentar discretamente.

Separadamente, nenhuma dessas coisas parecia suficiente para abrir uma War Room.

Juntas, estavam contando uma história.

Só que ninguém estava ouvindo.

É aqui que entram os Key Risk Indicators — KRIs.

E para conversar sobre sinais escondidos, ambientes hostis, sobrevivência e a capacidade de enxergar aquilo que os demais ignoram, hoje nosso tutor não será Poirot, Sherlock Holmes ou Jack Bauer.

Apaguem as luzes do datacenter.

Nosso guia será Riddick.



🌑 1. Riddick não precisa que alguém acenda a luz

Em Pitch Black, existe uma vantagem fundamental que transforma Riddick em alguém especialmente perigoso quando todos os outros ficam vulneráveis:

ele consegue operar no escuro.

Essa é uma excelente metáfora para Risk Management.

Quando tudo está verde, qualquer um consegue dizer:

SYSTEM STATUS = OK

CPU normal.

CICS funcionando.

Db2 funcionando.

MQ funcionando.

Rede funcionando.

Jobs terminando.

Dashboard verde.

Executivos tranquilos.

Café quente.

O problema é perceber alguma coisa quando ainda não existe uma falha evidente.

Um bom KRI tenta justamente aumentar nossa capacidade de enxergar nesse escuro operacional.

Ele não precisa dizer:

INCIDENT = TRUE

Pode dizer:

RISK EXPOSURE = INCREASING

E essa diferença é gigantesca.



📊 2. Primeiro: KRI não é simplesmente uma métrica

Quem está começando em COBOL, mainframe ou operações pode encontrar centenas de números durante um único dia.

CPU.

Storage.

I/O.

Transactions per second.

Response time.

Fila.

Número de jobs.

ABENDs.

Tickets.

Disponibilidade.

Quantidade de mudanças.

Tudo isso pode ser medido.

Mas nem toda métrica é automaticamente um KRI.

Considere:

FAILED DEPLOYMENTS = 4

Temos um número.

Agora:

TOTAL DEPLOYMENTS  = 100
FAILED DEPLOYMENTS = 4

FAILURE RATE = 4%

Temos um indicador melhor.

Mas falta contexto.

Historicamente:

JAN = 0.7%
FEV = 0.9%
MAR = 1.2%
ABR = 2.1%
MAI = 3.0%
JUN = 4.0%

O valor atual ganhou uma característica importantíssima:

tendência.

Agora descobrimos que o limite de tolerância definido pela organização é 3%.

CURRENT   = 4.0%
THRESHOLD = 3.0%
TREND     = UP

E sabemos quem responde por isso:

OWNER = APPLICATION DELIVERY

Finalmente existe uma ação prevista:

IF FAILURE_RATE > 3%
   PERFORM ROOT_CAUSE_ANALYSIS
   REVIEW RELEASE_PIPELINE
   ESCALATE TO OWNER
END-IF

Agora começamos a ter algo parecido com um verdadeiro KRI.



💻 3. Pensando como um programador COBOL

Vamos traduzir isso para uma lógica extremamente simples.

       IF WS-CURRENT-RISK > WS-RISK-LIMIT
           MOVE 'ACTION' TO WS-RISK-STATUS
       ELSE
           MOVE 'NORMAL' TO WS-RISK-STATUS
       END-IF.

Parece fácil.

Mas a realidade é mais interessante.

Talvez tenhamos:

       EVALUATE TRUE
           WHEN WS-CURRENT-RISK >= WS-CRITICAL-LIMIT
               MOVE 'CRITICAL' TO WS-RISK-STATUS

           WHEN WS-CURRENT-RISK >= WS-ACTION-LIMIT
               MOVE 'ACTION' TO WS-RISK-STATUS

           WHEN WS-CURRENT-RISK >= WS-WARNING-LIMIT
               MOVE 'WATCH' TO WS-RISK-STATUS

           WHEN OTHER
               MOVE 'NORMAL' TO WS-RISK-STATUS
       END-EVALUATE.

Agora nosso KRI ganhou quatro estados:

NORMAL
  ↓
WATCH
  ↓
ACTION
  ↓
CRITICAL

Isso é muito mais útil do que simplesmente:

VERDE
VERMELHO

Porque o objetivo de Risk Management é justamente atuar antes de chegar ao vermelho.

Riddick não espera a criatura estar mordendo seu pescoço para concluir que talvez exista algum risco naquele planeta.


🧭 4. Technology Strategy & Oversight — alguns monstros demoram anos para aparecer

O primeiro domínio do infográfico apresenta:

IT Strategy Alignment Gap

Technology Decision Delay

IT Portfolio Overrun Rate

Essa seção é importante porque destrói uma ideia comum:

risco de TI é problema técnico.

Não necessariamente.

Imagine um sistema funcionando perfeitamente.

Só existe um pequeno detalhe.

Ele precisa ser modernizado.

Ano 1:

MODERNIZATION = POSTPONED

Ano 2:

MODERNIZATION = POSTPONED

Ano 3:

MODERNIZATION = POSTPONED

Nada caiu.

Então alguém conclui:

Viu? Não precisava mexer.

Só que durante esses três anos:

Specialists available        ↓
Technical documentation      ↓
Vendor support remaining     ↓

Maintenance cost             ↑
Dependencies                 ↑
Security exposure            ↑
Operational complexity       ↑

O sistema não necessariamente piorou.

A exposição ao risco piorou.

Technology Decision Delay consegue ajudar a revelar justamente esse tipo de situação.


🎫 5. Ticket Backlog Aging — os esqueletos dentro da caverna

Agora entramos em Service Management:

Major Incident Volume

SLA Breach Rate

Ticket Backlog Aging

Contar tickets é útil.

Mas considere:

Sistema A

TICKETS = 1.000
AVERAGE AGE = 3 DAYS

Sistema B

TICKETS = 300
AVERAGE AGE = 74 DAYS

Qual deles é mais perigoso?

Não temos informação suficiente para responder.

Mas o segundo desperta imediatamente minha curiosidade.

Por que esses tickets permanecem abertos?

São irrelevantes?

Não existe equipe?

Não existe solução?

Existe dependência externa?

Ou pior:

a organização simplesmente se acostumou com os problemas?

Essa última hipótese é perigosíssima.

Quando ouvimos:

Isso acontece de vez em quando.

Riddick provavelmente já estaria olhando para o teto.

Porque alguma coisa está andando lá em cima.


🖥️ 6. Capacity Threshold — CPU a 95% não significa Armageddon

O infográfico apresenta:

Critical Infrastructure Downtime

Capacity Threshold Breach Rate

Network Latency Exception Rate

Aqui precisamos tomar muito cuidado com números isolados.

Imagine:

CPU = 95%

Alguém vê isso no monitor e grita:

SOCORRO!

Não necessariamente.

Especialmente no universo IBM Z, precisamos perguntar:

Qual LPAR?

Qual workload?

Quanto tempo?

Qual horário?

Qual prioridade?

Existe degradação?

Existe fila?

Qual objetivo de serviço?

O WLM está cumprindo as metas?

Esse comportamento é esperado?

Uma máquina trabalhando intensamente não significa necessariamente uma máquina com problemas.

É como encontrar Riddick correndo.

Talvez esteja fugindo.

Talvez esteja perseguindo alguma coisa.

O número sozinho não conta a história.


🚨 7. Threshold sem contexto cria Alert Fatigue

Existe outro perigo.

Configure alarmes para absolutamente tudo.

CPU > 70%       ALERT
CPU > 75%       ALERT
QUEUE > 10      ALERT
DISK > 60%      ALERT
LATENCY > X     ALERT
MEMORY > Y      ALERT

Logo teremos:

ALERT
ALERT
ALERT
ALERT
ALERT
ALERT
ALERT

O cérebro humano faz aquilo que sempre faz quando é bombardeado continuamente pela mesma informação:

começa a ignorá-la.

Isso é alert fatigue.

Quando tudo parece urgente, nada parece urgente.

O verdadeiro desafio não é gerar sinais.

É gerar sinais relevantes.


☁️ 8. Cloud — criar alguma coisa ficou assustadoramente fácil

Na seção Cloud & Platform Operations encontramos:

Uncontrolled Cloud Resource Growth

Cloud Cost Variance Rate

Platform Configuration Drift

Cloud trouxe uma transformação maravilhosa.

Provisionamento que antigamente poderia exigir dias ou semanas agora pode acontecer em minutos.

CLICK
CLICK
CLICK

RESOURCE CREATED

Fantástico.

Agora avance seis meses.

Alguém encontra aquele recurso.

RESOURCE-ID: X92827
OWNER: ?
PURPOSE: ?
DATA: ?
EXPIRATION: ?
BUSINESS SERVICE: ?

Pergunta:

Quem criou isso?

Resposta:

Roberto.

Chama o Roberto.

Roberto saiu da empresa em fevereiro.

Temos então um pequeno animal vivendo tranquilamente no escuro.

Ele ainda não mordeu ninguém.

Mas existe.


🧬 9. Configuration Drift — "não mexe porque funciona"

Este é um dos meus favoritos.

Temos um baseline:

SERVER CONFIGURATION 1.0

Todos começam iguais.

Depois ocorre uma emergência.

Servidor C recebe uma pequena alteração.

Depois Servidor D.

Depois alguém aplica uma correção temporária no E.

Depois uma mudança manual acontece no F.

Um ano depois:

SERVER-A = STANDARD
SERVER-B = STANDARD
SERVER-C = ALMOST STANDARD
SERVER-D = CUSTOM
SERVER-E = LEGACY
SERVER-F = DON'T TOUCH

😂

E quando perguntamos por quê:

Não mexe porque funciona.

Essa frase merece atenção.

Configuration Drift mede a distância entre:

como acreditamos que o ambiente esteja

e

como ele realmente está.

Essa distância é território perfeito para risco operacional.


🚀 10. Emergency Change Rate — emergência não pode virar processo

Applications & Change apresenta:

Emergency Change Rate

Failed Deployment Rate

Application Defect Leakage

Uma emergência eventualmente acontecerá.

O problema começa quando:

EMERGENCY CHANGE

deixa de significar exceção e passa a significar:

NOSSO PROCESSO NORMAL

Imagine:

JAN  4%
FEB  5%
MAR  8%
APR  13%
MAY  21%
JUN  32%

Não tivemos necessariamente um grande incidente.

Mas alguma coisa mudou profundamente na organização.

Talvez os prazos estejam ruins.

Talvez os testes tenham sido comprimidos.

Talvez exista dívida técnica.

Talvez releases estejam chegando sem planejamento.

O KRI não responde necessariamente por quê.

Ele diz:

Riddick, tem alguma coisa se mexendo naquela direção.

Agora investigue.


🔗 11. O segredo verdadeiro está na correlação

Imagine observarmos:

Emergency Change Rate       ↑
Failed Deployment Rate      ↑
Ticket Backlog Aging        ↑
Configuration Drift         ↑
Patch Aging Exposure        ↑

Separadamente são cinco indicadores.

Juntos podem representar uma história:

PRESSÃO OPERACIONAL
        ↓
MAIS ATALHOS
        ↓
MAIS MUDANÇAS EMERGENCIAIS
        ↓
MAIS FALHAS
        ↓
MAIS TICKETS
        ↓
MENOS TEMPO PARA CORREÇÃO
        ↓
MAIS DÍVIDA
        ↓
MAIOR EXPOSIÇÃO

Agora ficamos realmente interessados.

O melhor sinal pode não ser um KRI. Pode ser a combinação de vários KRIs.


🗄️ 12. Data & Integration — tudo pode estar UP e o negócio DOWN

O infográfico mostra:

Data Pipeline Failure Rate

Integration Error Volume

Data Availability Breach Rate

Imagine uma arquitetura:

MOBILE
  │
  ▼
API
  │
  ▼
z/OS Connect
  │
  ▼
CICS
  │
  ▼
MQ
  │
  ▼
COBOL
  │
  ▼
Db2

Nos dashboards:

NETWORK     UP
CICS        UP
MQ          UP
DB2         UP
Z/OS        UP

Cliente:

Não consigo concluir a operação.

Temos então uma diferença fundamental entre:

component availability

e

business service availability.

O cliente não compra CICS.

Não compra MQ.

Não compra Db2.

Ele compra uma capacidade de negócio.

Se essa capacidade não funciona, pouco importa que seis dashboards estejam verdes.


👻 13. Unmanaged Asset Ratio — o servidor fantasma

Agora chegamos aos ativos:

Unmanaged Asset Ratio

Patch Aging Exposure

CMDB Accuracy Gap

Pergunta aparentemente simples:

Quantos servidores temos?

Resposta da CMDB:

4.821

Scanner:

5.137

Cloud:

5.028

Security:

4.934

Financeiro:

5.316

Ops.

Temos um problema.

Porque existe uma máxima brutalmente simples:

Você não consegue gerenciar adequadamente aquilo que não sabe que existe.

O servidor desconhecido talvez esteja funcionando perfeitamente.

Isso não significa ausência de risco.

Significa ausência de visibilidade.

Riddick provavelmente chamaria isso de alguma coisa respirando no escuro.


🩹 14. Patch Aging — não conte apenas patches

Patch Aging Exposure é mais interessante do que simplesmente:

PATCHES MISSING = 187

Precisamos saber:

idade
criticidade
sistema
exposição
vulnerabilidade
business impact
owner

Um patch crítico atrasado 180 dias num servidor exposto pode ser muito mais relevante do que cinquenta atualizações pequenas atrasadas dois dias.

Novamente:

contexto transforma números em informação.


💾 15. Backup verde não significa recuperação garantida

Chegamos a Continuity & Recovery:

Backup Failure Rate

Recovery Test Failure Rate

Service Restoration Delay

Aqui está uma das minhas frases favoritas:

Backup não existe para fazer backup.

Backup existe para restaurar.

Parece piada.

Não é.

Imagine:

BACKUP SUCCESS RATE = 99.98%

Champanhe!

Agora:

Restaure o ambiente.

Silêncio.

O job:

RC=0000

não prova necessariamente que o negócio conseguirá recuperar aquilo que necessita dentro dos objetivos esperados.

É por isso que Recovery Test Failure Rate merece enorme atenção executiva.


⏱️ 16. RTO e RPO entram na caverna

Dois conceitos precisam aparecer aqui.

RPO — Recovery Point Objective

Quanto de informação podemos perder?

Exemplo:

RPO = 15 MINUTES

RTO — Recovery Time Objective

Quanto tempo podemos ficar sem o serviço?

RTO = 2 HOURS

Agora imagine:

RTO acordado      = 2 horas
Recovery test     = 7 horas

O backup funcionou.

O teste funcionou.

Mesmo assim:

o objetivo falhou.

Essa é uma diferença extremamente importante.


🎯 17. Qual KRI merece mais atenção executiva?

A publicação original termina perguntando isso.

Eu responderia:

depende do negócio e do risco.

Mas se alguém colocasse uma arma fictícia na mesa da War Room e me obrigasse a escolher um dos apresentados, eu olharia com enorme atenção para:

Recovery Test Failure Rate.

Porque descobrir durante um desastre que a última camada de recuperação não funciona é especialmente cruel.

Mas ainda prefiro observar um conjunto:

UNMANAGED ASSETS        ↑
PATCH AGING             ↑
CONFIGURATION DRIFT     ↑
EMERGENCY CHANGES       ↑
FAILED DEPLOYMENTS      ↑
RECOVERY TEST FAILURES  ↑

Isso pode revelar algo maior:

perda progressiva de controle operacional.

Esse é o monstro que realmente me interessa.


👔 18. O executivo não precisa aprender JCL

Imagine apresentar ao board:

IEF450I PAYROLL STEP030
ABEND=S0C4

Silêncio.

Talvez alguém pergunte:

Isso é ruim?

😂

Não devemos exigir que o executivo traduza detalhes operacionais.

Nosso trabalho é transformar isso em risco compreensível:

TECHNICAL EVENT
      ↓
SERVICE IMPACT
      ↓
BUSINESS IMPACT
      ↓
FINANCIAL / REGULATORY EXPOSURE
      ↓
DECISION

O executivo precisa entender:

impacto, tendência, exposição, owner, decisão necessária e prazo.

Essa é a verdadeira tradução.


🚦 19. Meu dashboard não teria apenas verde e vermelho

Eu faria algo assim:

KRI                 VALUE   TREND   LIMIT   STATUS

Patch Aging          17%      ↑      15%    ACTION
Emergency Change     12%      ↑      10%    ACTION
Failed Deployment     4%      →       5%    WATCH
Recovery Failure      1%      ↓       2%    NORMAL
Ticket Aging         27d      ↑      20d    CRITICAL

E acrescentaria:

OWNER
BUSINESS IMPACT
ACTION
DUE DATE

Porque um quadrado vermelho sem responsável é decoração corporativa.


🤖 20. E então entra IA, AIOps e análise preditiva

Agora a coisa fica realmente interessante.

Imagine armazenarmos anos de histórico.

A IA encontra repetidamente:

Ticket Aging ↑
      +
Emergency Change ↑
      +
Failed Deployment ↑
      +
Latency Exception ↑

e descobre que essa combinação frequentemente antecedeu Major Incidents.

Na próxima vez que o padrão surgir, ainda não existe incidente.

Mas podemos gerar:

RISK PATTERN DETECTED

Não estamos prevendo o futuro magicamente.

Estamos dizendo:

A situação atual se parece significativamente com situações anteriores que terminaram mal.

Isso é extremamente poderoso.

Passamos de:

MONITOR
   ↓
ALERT
   ↓
INCIDENT

para:

MONITOR
   ↓
CORRELATE
   ↓
DETECT PATTERN
   ↓
ASSESS RISK
   ↓
INTERVENE
   ↓
PREVENT

Esse é o caminho de uma operação cada vez mais inteligente.


🥚 Easter egg — o monstro nunca apareceu às 03:17

Agora apague novamente as luzes.

03:17:04

P1 INCIDENT DECLARED

Todo mundo acredita que o problema começou ali.

Riddick volta alguns passos.

90 dias antes
PATCH DEFERRED

63 dias antes
TICKET OPENED

48 dias antes
CONFIGURATION CHANGED

31 dias antes
DEPLOYMENT FAILED

17 dias antes
EMERGENCY CHANGE

8 dias antes
LATENCY EXCEPTION

3 dias antes
BACKUP WARNING

03:17
SERVICE DOWN

O incidente não nasceu às 03:17.

Às 03:17 ele apenas saiu do escuro.

E essa talvez seja a melhor maneira de explicar KRI para alguém começando no universo COBOL, z/OS ou operações.

O operador vê:

ABEND

O analista pergunta:

WHAT HAPPENED?

O investigador pergunta:

WHAT HAPPENED BEFORE THAT?

O profissional de Risk Management pergunta algo ainda melhor:

WHAT WAS ALREADY CHANGING
BEFORE ANYTHING FAILED?

É aí que deixamos de simplesmente apagar incêndios.

Começamos a procurar fumaça.

Depois calor.

Depois padrões.

Depois condições que tornam o incêndio provável.

No universo de Riddick, sobreviver no escuro exige perceber movimentos antes que as criaturas estejam sobre você.

No universo de TI acontece algo muito parecido.

Major Incident Volume mostra quantos monstros chegaram até você.

KRI tenta mostrar onde eles estão se movimentando.

E quando alguém disser:

"Mas ainda não aconteceu nada..."

talvez essa seja justamente a melhor hora para investigar.

Porque às 03:17, meu caro programador COBOL, a aula acabou.

A partir dali é produção.

E produção não perdoa quem só aprendeu a enxergar depois que acenderam a luz vermelha. ☕🌑💻

domingo, 23 de junho de 2024

O Macaco Infinito encontra o LLM: por que o ChatGPT não está simplesmente sorteando palavras até aparecer Shakespeare

 

Bellacosa Mainframe o macaco infinito encontra o llm

☕ Um Café no Bellacosa Mainframe

O Macaco Infinito encontra o LLM: por que o ChatGPT não está simplesmente sorteando palavras até aparecer Shakespeare

🐒 Tokens, probabilidade, temperatura, entropia, Markov, brute force, atenção e o dia em que descobrimos que “prever a próxima palavra” esconde um monstro matemático

Existe uma frase sobre inteligência artificial que parece muito inteligente durante aproximadamente trinta segundos:

“Esses modelos só ficam escolhendo a próxima palavra provável.”

Tecnicamente, existe alguma verdade nela.

O problema começa quando o “só” entra na sala.

É como dizer:

“Um mainframe só move elétrons.”

Correto.

Absolutamente inútil.

Ou:

“Um Boeing só empurra ar para baixo.”

Também correto.

Tente explicar assim ao passageiro sentado na poltrona 17A durante uma turbulência.

Depois da nossa aventura com Émile Borel, os macacos infinitos e Shakespeare, surge uma pergunta irresistível:

Se o macaco ficava apertando teclas aleatoriamente até eventualmente produzir Hamlet…

…um modelo de linguagem não estaria fazendo aproximadamente a mesma coisa, só muito mais rápido?

Resposta curta:

não.

Resposta longa:

Pegue café.

Muito café.

Porque vamos precisar atravessar tokens, distribuições de probabilidade, temperatura, entropia, cadeias de Markov, contexto, atenção, brute force e aquele estranho fenômeno no qual um sistema treinado para prever sequências começa a produzir código COBOL, explicar filosofia e discutir por que alguém esqueceu de fechar um IF.


Capítulo I — O macaco não sabe o que acabou de escrever

Voltemos ao nosso funcionário mais improvável do Bellacosa Mainframe.

Na sala 327-B encontramos:

FUNCIONÁRIO: MACACO-01
FUNÇÃO: DIGITAÇÃO ALEATÓRIA
SALÁRIO: BANANAS
SLA: INFINITO

O macaco recebe um teclado contendo:

ABCDEFGHIJKLMNOPQRSTUVWXYZ

Cada vez que pressiona uma tecla, suponhamos que escolha uma delas aleatoriamente.

Ele produz:

XQJHABZP...

Depois:

BANANA

Depois:

TOBEORNOTTOBE

Fantástico.

Mas aconteceu algo importante?

Para nós, sim.

Reconhecemos Shakespeare.

Para o macaco?

Nada.

A tecla anterior não influencia necessariamente a próxima.

Ele não sabe que escreveu:

TO BE OR NOT TO

Portanto a próxima letra continua sendo apenas mais uma escolha no conjunto disponível.

Ele pode produzir:

TO BE OR NOT TO X

com a mesma tranquilidade com que poderia produzir:

TO BE OR NOT TO B

O gerador aleatório clássico não possui uma ideia operacional de contexto.

Um modelo de linguagem possui.

E essa diferença muda praticamente tudo.


Capítulo II — O LLM não pergunta “qual palavra existe?”

Ele pergunta algo muito mais interessante:

dado tudo o que apareceu antes, o que provavelmente vem agora?

Simplificando brutalmente, podemos imaginar:

P(próximo token | contexto anterior)

Esse pequeno símbolo:

|

é quase o personagem principal da história.

Significa:

condicionado a.

Não estamos perguntando:

Qual é a probabilidade da palavra PERFORM?

Estamos perguntando:

Qual é a probabilidade de PERFORM
dado tudo que apareceu antes?

Veja:

IDENTIFICATION DIVISION.
PROGRAM-ID. TESTE.
PROCEDURE DIVISION.

Agora imagine as possibilidades seguintes:

PERFORM
BANANA
TARDIS
DIVORCE
WORKING-STORAGE
DISPLAY

Todas essas sequências de caracteres são fisicamente possíveis.

Mas não são igualmente plausíveis naquele contexto.

Um modelo treinado em COBOL aprendeu relações estatísticas que tornam algumas alternativas muito mais prováveis.

O macaco pensa:

QUALQUER COISA SERVE.

O modelo pensa aproximadamente:

ALGUMAS COISAS FAZEM MUITO MAIS SENTIDO AQUI.

E isso já é uma revolução.


Capítulo III — Primeiro problema: modelos não enxergam exatamente palavras

Aqui entra uma pequena criatura chamada:

TOKEN.

Quando falamos informalmente:

“o modelo prevê a próxima palavra”

estamos simplificando.

Modelos de linguagem modernos geralmente trabalham com tokens, que podem representar:

  • uma palavra inteira;

  • parte de uma palavra;

  • pontuação;

  • espaços ou combinações;

  • sequências frequentes de caracteres.

Por exemplo, dependendo do tokenizer, algo semelhante a:

programador

pode ser uma unidade ou ser dividido em pedaços.

E:

WORKING-STORAGE

pode virar vários tokens.

Pense nos tokens como peças de LEGO linguísticas.

O modelo não recebe necessariamente:

PALAVRA 1
PALAVRA 2
PALAVRA 3

Ele recebe algo mais parecido com:

PEÇA 593
PEÇA 18271
PEÇA 44
PEÇA 905

Durante treinamento, aprende como essas peças aparecem juntas.

O macaco aperta teclas.

O LLM navega num espaço de peças linguísticas.


Capítulo IV — Uma distribuição, não uma resposta pronta

Imagine esta frase:

O programador entrou no CPD e pediu um...

O modelo não necessariamente possui apenas uma resposta.

Ele poderia atribuir algo conceitualmente parecido com:

café        0,36
acesso      0,18
terminal    0,12
relatório   0,08
dump        0,06
abacaxi     0,00001
dinossauro  0,000001

Os números aqui são apenas ilustrativos.

O ponto é a estrutura:

há uma distribuição de probabilidades.

Isso é fundamental.

O modelo não pensa simplesmente:

RESPOSTA = CAFÉ

Ele produz algo mais próximo de:

POSSIBILIDADES ORDENADAS POR PLAUSIBILIDADE.

Depois algum mecanismo de seleção determina qual token será efetivamente escolhido.

E aí entra uma palavra que parece saída de previsão meteorológica:

temperatura.


Capítulo V — Temperatura: aumentando a dose de caos

Temperatura controla, de forma simplificada, quão concentrada ou espalhada fica a distribuição usada durante a geração.

Temperatura baixa:

ESCOLHA O MAIS PROVÁVEL.

Temperatura mais alta:

DÊ MAIS CHANCE PARA ALTERNATIVAS MENOS ÓBVIAS.

Imagine:

O gato subiu no...

Distribuição hipotética:

telhado      45%
muro         20%
sofá         10%
armário       8%
mainframe     0,01%
Saturno       0,0001%

Com temperatura baixa, provavelmente teremos:

telhado

Com temperatura mais alta:

armário

pode aparecer com maior frequência.

Subindo absurdamente:

mainframe

entra na reunião.

Aumentando ainda mais:

O gato subiu no checksum metafísico das quintas-feiras.

Nesse ponto talvez seja prudente desligar alguma coisa.


Capítulo VI — Então existe aleatoriedade?

Sim.

Mas isso não transforma o modelo no macaco de Borel.

Existe uma enorme diferença entre:

ESCOLHER ALEATORIAMENTE ENTRE TODOS OS SÍMBOLOS

e:

ESCOLHER A PARTIR DE UMA DISTRIBUIÇÃO
APRENDIDA SOBRE O QUE FAZ SENTIDO
DADO O CONTEXTO.

O segundo processo carrega informação.

Esse detalhe é gigantesco.

Nosso macaco poderia escrever:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "HELLO WORLD".
STOP RUN.

Mas teria chegado lá por acidente.

Um LLM treinado em código percebe padrões como:

IDENTIFICATION DIVISION
→ PROGRAM-ID

ou:

DISPLAY
→ literal ou variável

Ele não precisa experimentar todas as combinações até encontrar uma compilável.

Aprendeu um relevo estatístico do território.


Capítulo VII — Imagine uma montanha de probabilidades

Pense em todas as sequências possíveis como uma paisagem gigantesca.

O macaco possui um mapa completamente plano.

Para ele:

AAABBB

e:

TO BE

são apenas coordenadas diferentes.

Já o modelo aprendeu montanhas e vales.

Algumas sequências possuem caminhos naturalmente elevados:

Era uma vez...

tende a levar para narrativa.

SELECT *
FROM

tende a levar para SQL.

IDENTIFICATION DIVISION.

tende a levar para COBOL.

Você forneceu contexto.

O espaço de possibilidades foi drasticamente reorganizado.

Essa talvez seja uma das melhores maneiras de imaginar aprendizado:

o modelo transforma um universo plano de combinações numa geografia de plausibilidades.


Capítulo VIII — E aqui encontramos Claude Shannon

Agora precisamos falar de entropia.

Calma.

Ninguém precisará usar capacete de física.

Em teoria da informação, entropia mede aproximadamente o grau de incerteza existente numa distribuição.

Se você tem:

A = 25%
B = 25%
C = 25%
D = 25%

há bastante incerteza.

Mas:

A = 99,9%
B = 0,05%
C = 0,03%
D = 0,02%

há muito menos.

O contexto reduz entropia.

Considere:

O Sol nasce no...

Existe forte expectativa de:

leste

Agora:

Ele abriu a porta e viu...

Existem muito mais continuações possíveis.

Um cachorro.

Uma pessoa.

A chuva.

Um quarto vazio.

Um macaco digitando Hamlet.

Um fiscal do Ministério de Caminhadas Bobas.

A distribuição fica mais espalhada.

Mais incerteza.

Mais entropia.


Capítulo IX — Conhecimento é redução de entropia

Esse conceito conecta maravilhosamente com programação.

Você recebe:

O SISTEMA ESTÁ COM PROBLEMA.

Entropia enorme.

Pode ser:

  • CPU;

  • memória;

  • rede;

  • banco;

  • aplicação;

  • segurança;

  • storage;

  • configuração;

  • JCL;

  • CICS;

  • Db2;

  • VSAM;

  • operador;

  • mudança;

  • dados.

Agora alguém informa:

ABEND S0C7

BUM.

O espaço reduz.

Depois:

OCORRE NA ROTINA CALC-TOTAL

reduz mais.

Depois:

CAMPO WS-VALOR RECEBEU '12A45'

Praticamente acabou o mistério.

Diagnóstico é essencialmente um processo de:

redução progressiva de incerteza.

Você não precisa investigar o Universo.

Precisa descobrir qual informação diminui mais rapidamente o espaço de possibilidades.


Capítulo X — O velho programador é uma máquina anti-entropia

Um iniciante vê:

S0C7

e pensa:

— MEU DEUS O MAINFRAME QUEBROU.

O veterano responde:

— Mostra o campo.

Por quê?

Porque sua experiência acumulou relações.

Ele sabe quais evidências são informativas.

De certa forma, cada mensagem recebida modifica sua distribuição mental:

P(causa | evidências)

Parece familiar?

Sim.

Porque agora estamos novamente perto do nosso LLM.


Capítulo XI — Antes dos Transformers havia Markov

Outra palavra importante:

Markov.

Uma cadeia de Markov trabalha, de forma simplificada, com probabilidades de transição entre estados.

Por exemplo, examinando textos poderíamos aprender:

depois de "bom" →
dia      60%
trabalho 10%
café      8%

Um modelo simples poderia olhar apenas uma ou algumas palavras anteriores.

Isso permite gerar textos surpreendentemente convincentes por pequenos trechos.

Imagine treinarmos uma cadeia de Markov com documentação COBOL.

Ela poderia aprender:

IDENTIFICATION
→ DIVISION

PROGRAM-ID
→ nome

PROCEDURE
→ DIVISION

Já seria muito superior ao macaco.

Por quê?

Porque existe memória estatística local.

Mas existe um problema.

Contexto distante importa.

Muito.


Capítulo XII — Hamlet não cabe numa janela de duas palavras

Veja:

Maria colocou o livro sobre a mesa porque precisava
consultá-lo depois da reunião.

Para saber a que:

lo

se refere, talvez precisemos relacioná-lo com algo ocorrido várias palavras antes.

Agora imagine:

  • um romance;

  • um programa;

  • documentação;

  • uma conversa;

  • código contendo funções espalhadas;

  • uma história com personagens.

Dependências podem existir a centenas ou milhares de tokens de distância.

Modelos baseados apenas em relações locais possuem dificuldade crescente nisso.

E então chegaram os Transformers.

Com eles aparece um conceito que mudou profundamente o jogo:

atenção.


Capítulo XIII — Attention, please

A ideia central de atenção é quase deliciosamente intuitiva:

para entender o elemento atual, quais partes do contexto anterior são especialmente relevantes?

Imagine:

O arquivo CUSTOMER foi aberto no início do programa.
Depois de diversas operações, o programa tentou lê-lo,
mas recebeu FILE STATUS 47.

Para entender o problema, talvez algumas palavras sejam muito mais relevantes:

arquivo
CUSTOMER
aberto
ler
FILE STATUS 47

Outras são menos importantes.

O mecanismo de atenção calcula relações entre representações dos tokens para determinar quais partes devem exercer mais influência umas sobre as outras.

Não é uma busca literal por palavra-chave.

É uma relação aprendida em espaços matemáticos de representação.


Capítulo XIV — Query, Key e Value entram num bar

No mecanismo clássico de attention aparecem três conceitos:

QUERY
KEY
VALUE

Isso parece suspeitosamente familiar para alguém que vive de sistemas.

Podemos criar uma analogia grosseira.

Cada token produz algo como:

QUERY = o que estou procurando?
KEY   = que tipo de informação eu represento?
VALUE = qual informação posso fornecer?

A Query de um token é comparada às Keys dos outros tokens.

Correspondências fortes recebem maior peso.

Depois os Values relacionados são combinados.

É muito mais complexo matematicamente, mas a intuição funciona.

Imagine uma reunião.

Você pergunta:

— Quem sabe sobre RACF?

Cinquenta pessoas estão na sala.

Um DBA levanta levemente a sobrancelha.

O sysprog RACF começa imediatamente a falar.

O estagiário continua olhando para o celular.

Sua Query:

RACF

encontrou uma Key altamente compatível.

Atenção alocada.


Capítulo XV — O macaco procura tudo; a atenção decide onde olhar

Agora nossa comparação fica bonita.

Macaco:

TODAS AS TECLAS
TODAS AS VEZES
SEM CONTEXTO

Brute force:

TODAS AS POSSIBILIDADES
ATÉ ACHAR.

Heurística:

TENTE AS MAIS PROMISSORAS.

LLM:

USE O CONTEXTO
PARA PRODUZIR UMA DISTRIBUIÇÃO
SOBRE CONTINUAÇÕES PLAUSÍVEIS.

Atenção:

DESCUBRA QUAIS PARTES DO CONTEXTO
SÃO MAIS RELEVANTES AGORA.

Estamos muito longe do macaco original.


Capítulo XVI — “Mas ele continua apenas prevendo o próximo token!”

Sim.

E seu programa COBOL continua apenas executando instruções.

O ponto não é qual operação elementar acontece.

O ponto é qual estrutura emerge da combinação de bilhões dessas operações.

Um processador faz basicamente operações muito simples.

Ainda assim executa:

  • CICS;

  • Db2;

  • compiladores;

  • criptografia;

  • sistemas bancários;

  • inteligência artificial.

Dizer:

“LLM só prevê token”

é semelhante a explicar um banco dizendo:

“O computador só altera bits.”

Não está errado.

Só deixou de explicar praticamente tudo que é interessante.


Capítulo XVII — O poder está na distribuição condicionada

Observe a diferença.

Macaco:

P(X) = aproximadamente constante

simplificando nosso modelo ideal.

Modelo:

P(X | CONTEXTO)

O contexto pode incluir:

  • palavras;

  • frases;

  • código;

  • instruções;

  • relações;

  • exemplos;

  • estilo;

  • estrutura.

Logo:

PERFORM UNTIL

faz determinadas continuações subirem de probabilidade.

E:

Era uma noite escura e tempestuosa...

faz outras subirem.

O mesmo mecanismo básico consegue trabalhar em domínios completamente diferentes porque aprendeu regularidades estatísticas extremamente amplas.


Capítulo XVIII — O treinamento é onde o mapa nasce

Durante treinamento, o modelo vê enormes quantidades de sequências.

Ele tenta prever partes seguintes.

Erra.

Os parâmetros internos são ajustados.

Tenta novamente.

Erra menos.

Repete isso incontáveis vezes.

De forma caricata:

INPUT:
IDENTIFICATION

MODELO:
BANANA

SISTEMA:
ERRADO.

AJUSTA PESOS.

INPUT:
IDENTIFICATION

MODELO:
DIVISION

SISTEMA:
MELHOR.

Claro que treinamento real é incomparavelmente mais complexo.

Mas a ideia fundamental permanece:

o modelo internaliza regularidades por otimização.

Ao final, ele não guarda simplesmente uma gigantesca tabela:

SE INPUT = X
THEN OUTPUT = Y

Existe um conjunto enorme de parâmetros representando padrões distribuídos.


Capítulo XIX — Pesos: memória sem ficha catalográfica

Isso costuma causar confusão.

As pessoas imaginam que um modelo possui algo parecido com:

DATABASE
--------
PERGUNTA 1 → RESPOSTA 1
PERGUNTA 2 → RESPOSTA 2
PERGUNTA 3 → RESPOSTA 3

Não funciona assim.

Grande parte do conhecimento aprendido está distribuída nos pesos da rede.

Podemos usar uma analogia humana.

Você sabe falar português.

Onde está armazenada a regra completa para usar:

por que
porque
por quê
porquê

no seu cérebro?

Provavelmente não existe uma gaveta física etiquetada:

PORTUGUÊS/PORQUES.DAT

Seu conhecimento está distribuído.

No modelo acontece algo matematicamente diferente, porém conceitualmente podemos dizer:

o conhecimento não está organizado como páginas numa enciclopédia interna.


Capítulo XX — E o brute force?

Aqui chegamos novamente ao macaco.

Se quiséssemos gerar uma resposta testando todas as sequências possíveis de tokens, teríamos algo monstruoso.

Suponha um vocabulário de:

50.000 tokens

Para uma sequência de apenas 10 tokens:

50.000^10

possibilidades.

Isso é:

aproximadamente 10^47

combinações.

Dez tokens!

Uma resposta real pode conter centenas ou milhares.

Brute force é simplesmente inviável.

O modelo precisa navegar inteligentemente pelas regiões de maior probabilidade.

De novo:

conhecimento reduz espaço de busca.


Capítulo XXI — Beam Search entra carregando uma lanterna

Existem estratégias de geração que ilustram esse princípio.

Uma delas, tradicional em vários sistemas de geração, é beam search.

Em vez de seguir apenas uma alternativa, mantemos algumas das melhores candidatas.

Imagine:

O café está...

Possibilidades:

quente      40%
pronto      30%
frio        20%
cantando     0,001%

Podemos manter:

quente
pronto
frio

e expandir cada caminho.

Depois descartamos alternativas cada vez menos promissoras.

Não exploramos o universo inteiro.

Mantemos uma pequena fronteira de possibilidades.

Novamente:

não seja o macaco.


Capítulo XXII — Top-k e top-p: expulsando possibilidades absurdas da reunião

Outra família de técnicas limita candidatos.

Top-k:

considere apenas os K tokens mais prováveis.

Se K = 5:

ignore todo o resto.

Top-p, ou nucleus sampling:

considere o menor conjunto de tokens
cuja probabilidade acumulada atinja determinado limite.

Essas estratégias evitam gastar probabilidade com opções extremamente improváveis.

Nosso macaco aceita tudo.

O modelo diz:

— Desculpe, ornitorrinco possui probabilidade baixa demais nesta frase.

O ornitorrinco protesta.

A reunião continua.


Capítulo XXIII — Temperatura baixa demais também causa problemas

Agora vem uma sutileza.

Se sempre escolhermos o token mais provável, podemos obter textos:

  • previsíveis;

  • repetitivos;

  • conservadores;

  • pouco variados.

Imagine um escritor que sempre escolhe a continuação estatisticamente mais comum.

Teríamos o romance:

Era uma vez um homem.
O homem foi para casa.
Na casa havia uma casa.
A casa era uma casa.
Fim.

Parabéns.

Produzimos documentação de fornecedor.

Um pouco de aleatoriedade permite diversidade.

A criatividade computacional prática vive parcialmente no equilíbrio entre:

PREVISIBILIDADE

e:

EXPLORAÇÃO.

Capítulo XXIV — Isso lembra exploração versus exploitation

Machine learning possui um dilema clássico:

EXPLOITATION

usar aquilo que já sabemos funcionar.

versus:

EXPLORATION

tentar possibilidades novas.

Temperatura baixa favorece exploitation.

Temperatura mais alta aumenta exploration.

A vida profissional possui exatamente isso.

O programador experiente pode resolver tudo sempre do mesmo jeito.

Seguro.

Previsível.

Até chegar um problema novo.

O jovem tenta vinte coisas absurdas.

Dezenove falham.

Uma revela algo que ninguém percebeu.

Uma boa equipe mistura ambos.


Capítulo XXV — LLM não possui uma “frase escondida” esperando ser revelada

Outra ideia errada:

“A resposta já está dentro do modelo.”

Não exatamente.

A geração é sequencial.

Cada token produzido passa a fazer parte do contexto para os tokens seguintes.

Assim:

TOKEN 1
↓
modifica contexto

TOKEN 2
↓
modifica contexto

TOKEN 3
↓
...

A resposta vai sendo construída.

Isso significa que uma escolha inicial pode alterar profundamente o caminho posterior.

Quase como uma execução de programa.

Só que probabilística.


Capítulo XXVI — Um pequeno desvio pode criar outro universo

Imagine que o modelo começa:

Existem três causas principais...

Agora provavelmente continuará estruturando três causas.

Mas se começar:

A causa principal é...

criou outra trajetória textual.

Cada token não é apenas output.

Ele também vira input subsequente.

Temos feedback.

Não exatamente no sentido de treinamento, mas no sentido de condicionamento da próxima geração.

Uma espécie de:

MOVE OUTPUT-TOKEN TO NEXT-INPUT-CONTEXT

Isso explica por que pequenas diferenças iniciais podem produzir respostas bastante diferentes.


Capítulo XXVII — E aqui mora a alucinação

Um modelo produz aquilo que parece provável linguisticamente.

Isso não garante que seja verdadeiro.

Essa distinção é fundamental.

Imagine:

FORMA PLAUSÍVEL
≠
FATO VERIFICADO

O modelo pode gerar uma referência com aparência perfeita:

Autor,
ano,
título,
revista,
volume,
página.

Tudo linguisticamente impecável.

E inexistente.

Por quê?

Porque o objetivo básico da geração não é:

EXECUTE FACT-CHECK

antes de cada token.

É produzir uma continuação plausível segundo o contexto e os mecanismos adicionais do sistema.

É por isso que ferramentas externas, recuperação de documentos, pesquisa e verificação são tão importantes em tarefas factuais.


Capítulo XXVIII — O macaco erra de forma idiota; o LLM pode errar de forma elegante

O macaco produz:

XJSQWERTYZZZZ

Você olha e diz:

— Errado.

Fim.

O modelo pode produzir:

“Segundo o estudo realizado pela Universidade Real de Copenhagen em 1987…”

Você pensa:

— Parece plausível.

Esse erro é muito mais perigoso.

Fluência gera confiança.

Portanto existe uma regra prática maravilhosa:

quanto mais importante o fato, menos você deve confundir boa escrita com prova.

No mainframe isso já era conhecido há décadas.

Um job pode terminar com:

RC=0000

e ainda produzir resultado logicamente errado.

Compilar não significa estar correto.

Soar convincente também não.


Capítulo XXIX — O LLM encontrou Shakespeare sem digitar infinitamente

Aqui finalmente fechamos o círculo.

O macaco precisa de:

TENTATIVAS ABSURDAMENTE NUMEROSAS

porque não possui conhecimento.

O LLM aprendeu estrutura.

Por isso consegue navegar diretamente para regiões onde texto coerente vive.

Em vez de procurar Hamlet em:

TODAS AS SEQUÊNCIAS POSSÍVEIS

ele aprendeu:

  • sintaxe;

  • relações semânticas;

  • estilos;

  • formas narrativas;

  • convenções;

  • padrões estatísticos.

Shakespeare deixa de ser uma agulha completamente escondida num universo plano.

O modelo possui um mapa imperfeito de onde “coisas parecidas com linguagem humana” costumam existir.


Capítulo XXX — Mas isso é inteligência?

Excelente pergunta.

O Ministério das Perguntas Filosóficas informa que sua senha é:

8.391.274

Atendimento atual:

12

Existe debate enorme sobre o que constitui inteligência, compreensão, raciocínio e significado.

Mas uma coisa podemos afirmar operacionalmente:

o comportamento de um LLM não é equivalente ao de um gerador uniforme de caracteres aleatórios.

Existe estrutura aprendida.

Existe condicionamento pelo contexto.

Existem representações internas complexas.

Existe atenção.

Existe uma distribuição de probabilidades profundamente moldada pelo treinamento.

Compará-lo ao macaco infinito é uma metáfora divertida.

Como explicação técnica, porém, ela desaba rapidamente.


Capítulo XXXI — O programador COBOL iniciante pode aprender muito com isso

Primeira lição:

contexto vale ouro.

Se você pedir:

me explique esse erro

existe enorme incerteza.

Mas:

Tenho um programa COBOL rodando em z/OS,
recebendo S0C7 após um COMPUTE.
O campo WS-AMOUNT é PIC 9(7)V99
e recebeu dados vindos deste arquivo.

Você reduziu brutalmente o espaço de possibilidades.

Para humanos e para modelos.

Segunda:

forneça evidências, não apenas conclusões.

Em vez de:

DB2 está lento.

forneça:

query
access path
elapsed
CPU
getpages
locks

Informação reduz entropia.

Terceira:

não aceite fluência como confirmação.

Sempre valide:

  • comandos;

  • versões;

  • parâmetros;

  • comportamento;

  • fatos importantes.

Quarta:

aprenda padrões.

Quanto mais padrões você conhece, menor fica seu espaço de busca.

Quinta:

quando tudo parece possível, procure a informação que mais elimina hipóteses.

Essa talvez seja uma das melhores técnicas de troubleshooting que existem.


Capítulo XXXII — A atenção no dia a dia do mainframe

Imagine um dump com milhares de linhas.

O iniciante lê:

LINHA 1
LINHA 2
LINHA 3
...
LINHA 9000

O experiente procura:

ABEND CODE
PSW
OFFSET
MODULE
REGISTER
FILE STATUS
SQLCODE
MESSAGE ID

Isso é uma espécie de attention humana.

Não no sentido matemático do Transformer, claro.

Mas no sentido cognitivo:

algumas partes do contexto merecem muito mais peso.

A habilidade de investigar sistemas complexos depende enormemente disso.

Você nunca consegue observar tudo.

Precisa saber onde olhar.


Capítulo XXXIII — O macaco recebeu atenção e pediu aumento

Nosso macaco original finalmente descobre o conceito.

Ele chama o gerente.

— Durante cem anos eu digitei aleatoriamente.

— Sim.

— Agora descobri que existe um sistema que usa contexto.

— Sim.

— E vocês sabiam disso?

— É complicado.

— Quantas bananas eu desperdicei?

Silêncio.

O macaco abre sindicato.

O projeto entra em negociação coletiva.


Capítulo XXXIV — Easter egg: Monty Python entra no laboratório

Um funcionário do Ministério da Inteligência Artificial entra carregando uma pasta.

— Precisamos determinar se esta máquina pensa.

O cientista pergunta:

— Como?

— Se ela responder corretamente, pensa.

— E qual a pergunta?

— Ainda estamos decidindo.

— Quem decide?

— O Comitê para Definir Perguntas que Determinam Pensamento.

— Onde fica?

— Dentro do Departamento de Definições Indefinidas.

— E eles pensam?

— Isso ainda está sendo avaliado.

Enquanto isso, o macaco já foi embora com a máquina de escrever.

Provavelmente tomou a decisão mais inteligente da sala.


Capítulo XXXV — Existe ainda um fantasma chamado determinismo

Se definirmos determinados parâmetros e mecanismos de seleção, podemos tornar a geração mais determinística.

Em outros cenários, sampling introduz variação.

Isso explica por que o mesmo prompt pode produzir respostas diferentes.

Não significa que o modelo:

MUDOU DE OPINIÃO

como um humano necessariamente faria.

O processo de geração percorreu outra trajetória probabilística.

Pense numa bifurcação:

           CONTEXTO
              |
      -----------------
      |       |       |
    TOKEN A TOKEN B TOKEN C
      |       |       |
    ...      ...      ...

Cada escolha abre um caminho diferente.

A linguagem é uma árvore gigantesca de possibilidades.


Capítulo XXXVI — Do macaco para a árvore

Essa talvez seja a imagem definitiva.

O macaco olha para uma árvore contendo bilhões de bilhões de galhos e escolhe aleatoriamente qualquer um.

O LLM possui um mapa dizendo:

ESSE GALHO PARECE PROMISSOR.
ESSE TAMBÉM.
AQUELE É ESTRANHO.
AQUELE OUTRO PROVAVELMENTE TERMINA NUM ORNITORRINCO.

Não possui certeza absoluta.

Mas possui orientação.

E orientação muda completamente a complexidade prática do problema.


Capítulo XXXVII — O segredo não é prever; é prever muito bem

Agora podemos reinterpretar aquela frase:

“O modelo apenas prevê o próximo token.”

Sim.

Mas para prever bem o próximo token em linguagem humana, precisa capturar enormes quantidades de estrutura.

Considere:

Se João colocou o copo sobre a mesa
e Maria esbarrou na mesa...

Qual consequência é provável?

Talvez o copo caia.

Para prever continuações plausíveis, o modelo precisa representar relações sobre:

  • objetos;

  • ações;

  • linguagem;

  • física cotidiana;

  • causalidade;

  • convenções narrativas.

Não significa necessariamente possuir compreensão humana.

Mas mostra por que o problema de previsão pode forçar a aprendizagem de estruturas surpreendentemente profundas.


Capítulo XXXVIII — Previsão como compressão

Existe outra forma fascinante de olhar para isso.

Um sistema que prevê bem encontrou regularidades.

Se você sabe que:

IDENTIFICATION

quase sempre é seguido por:

DIVISION

não precisa tratar cada ocorrência como informação completamente nova.

Você capturou uma regularidade.

Nesse sentido, modelar é parcialmente comprimir padrões.

Quanto melhor entendemos a estrutura, menos surpresa existe.

Isso conecta:

  • probabilidade;

  • entropia;

  • compressão;

  • aprendizado.

Claude Shannon provavelmente pediria café neste ponto.


Capítulo XXXIX — Quando a surpresa é útil

Um texto em que cada próxima palavra é totalmente previsível é entediante.

Um texto em que cada palavra é completamente imprevisível é ruído.

Boa linguagem vive entre ambos.

Compare:

O gato é um gato que é gato e gato.

Entropia baixa demais.

Agora:

XQZ RTM PFJK WLLZ.

Entropia inútil.

Agora:

O gato dormia sobre o terminal 3270 enquanto o operador tentava explicar ao auditor por que aquilo constava no inventário como dispositivo biométrico.

Surpresa.

Mas coerência.

Esse equilíbrio é uma parte importante da produção de linguagem interessante.


Capítulo XL — E criatividade talvez more nessa fronteira

Talvez criatividade não seja:

ALEATORIEDADE PURA

nem:

PREVISIBILIDADE ABSOLUTA.

Talvez esteja em algo como:

ESTRUTURA
+
VARIAÇÃO
+
CONTEXTO
+
SELEÇÃO

Humanos fazem isso.

Modelos fazem algo matematicamente diferente, mas também exploram uma região entre ordem e surpresa.

O macaco infinito possui surpresa demais.

Um autocomplete rígido possui surpresa de menos.

O desafio interessante mora no meio.


Epílogo — O macaco pede acesso ao Transformer

Depois de cem anos no Bellacosa Mainframe, MONKEY01 finalmente encontra o novo sistema.

Na tela:

PROMPT:
Escreva uma frase no estilo de Shakespeare.

Resposta:

A noite pesa sobre a torre,
e cada sino parece contar
os segundos que restam ao rei.

O macaco olha.

Olha para sua máquina de escrever.

Olha novamente para a tela.

Depois chama o sysprog.

— Quanto tempo isso levou?

— Alguns segundos.

— Quantos macacos?

— Nenhum.

— Quantas tentativas?

— Não funciona exatamente assim.

O macaco permanece em silêncio.

Depois pergunta:

— Então durante todos esses anos vocês estavam esperando que eu encontrasse Shakespeare no espaço completo de possibilidades...

— Sim.

— ...quando poderiam aprender quais sequências parecem linguagem?

— Tecnicamente...

O macaco vira a mesa.

E está certo.

Porque essa é a grande mudança entre o Macaco Infinito e o Modelo de Linguagem.

O primeiro depende de:

TEMPO
+
ALEATORIEDADE
+
SORTE.

O segundo depende de:

TREINAMENTO
+
ESTRUTURA
+
CONTEXTO
+
PROBABILIDADE
+
ATENÇÃO.

O macaco explora um universo indiferenciado.

O modelo aprendeu que algumas regiões desse universo são muito mais interessantes que outras.

Brute force diz:

Tente tudo.

Probabilidade diz:

Algumas coisas são mais prováveis.

Entropia pergunta:

Quanto ainda não sabemos?

Contexto responde:

Agora sabemos um pouco mais.

Markov diz:

O passado recente ajuda.

Attention acrescenta:

Nem todo passado é igualmente importante.

O Transformer junta tudo numa arquitetura capaz de manipular relações em escala gigantesca.

E o velho programador COBOL, que assistiu a toda a discussão enquanto tomava café, finalmente fecha o dump e comenta:

— Interessante.

— O quê?

— Passamos cem anos tentando criar máquinas que procurassem respostas.

Ele aponta para o terminal.

— Agora estamos criando máquinas que aprendem onde vale a pena procurar.

Silêncio.

O macaco olha para o programador.

O programador olha para o macaco.

Ambos olham para o gerente.

O gerente pergunta:

— Isso reduz headcount?

O macaco imediatamente volta para a máquina de escrever.

Era melhor lidar com o infinito.

☕🐒🤖

No console aparece:

MONKEY01   ENDED
LLM0001    STARTED

O operador verifica.

MAXCC=0000

Cinco segundos depois:

WARNING:
OUTPUT PLAUSIBLE.
FACT CHECK REQUIRED.

O velho COBOLzeiro sorri.

Finalmente uma máquina que aprendeu uma das regras fundamentais de produção:

parecer correto nunca foi a mesma coisa que estar correto.

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