Microsoft Copilot: Muito Além do Chat. Como um Programador Júnior Pode Trabalhar 10x Melhor Integrando IA ao Dia a Dia

 

Bellacosa Mainframe e o microsoft copilot

☕ Um Café no Bellacosa Mainframe

Microsoft Copilot: Muito Além do Chat. Como um Programador Júnior Pode Trabalhar 10x Melhor Integrando IA ao Dia a Dia

"A Inteligência Artificial não substitui o conhecimento técnico. Ela potencializa quem sabe fazer as perguntas certas."

Durante muitos anos, o diferencial de um bom programador era dominar uma linguagem de programação. Depois, passou a ser conhecer frameworks, metodologias ágeis, DevOps, Cloud e arquitetura de software.

Em 2026, estamos vivendo mais uma grande transformação.

O diferencial deixou de ser apenas saber usar Inteligência Artificial.

Agora, o verdadeiro diferencial é integrar a IA ao fluxo de trabalho.

Essa é uma mudança de mentalidade que todo desenvolvedor — especialmente quem está começando sua carreira — precisa compreender.

Muita gente ainda abre o ChatGPT ou o Microsoft Copilot apenas para fazer perguntas.

Isso é útil.

Mas representa apenas uma pequena fração do potencial dessas ferramentas.

Os profissionais que mais se destacam utilizam a IA como um verdadeiro membro da equipe. Ela participa da análise, da documentação, dos testes, da comunicação, da organização e até da tomada de decisões.

É justamente sobre essa nova forma de trabalhar que vamos conversar neste Café no Bellacosa Mainframe.

---

O erro que quase todo iniciante comete

Imagine um programador COBOL recém-contratado.

Ele recebe um programa com cinco mil linhas.

A primeira reação normalmente é:

"Copilot, explique esse programa."

A resposta até pode ajudar.

Mas o profissional continua trabalhando praticamente da mesma maneira de antes.

Agora imagine outro desenvolvedor.

Ele utiliza o Copilot desde o início do processo.

Antes de abrir o código, pergunta:

• Qual o objetivo deste sistema?

• Quais módulos costumam chamar este programa?

• Quais tabelas DB2 são utilizadas?

• Existe documentação?

• Existem padrões da empresa?

• Existem riscos conhecidos?

Depois disso:

• gera documentação;

• cria diagramas;

• produz casos de teste;

• identifica possíveis melhorias;

• prepara perguntas para o desenvolvedor mais experiente.

Percebe a diferença?

O primeiro usa IA.

O segundo trabalha com IA.

---

O Copilot não é apenas um chatbot

Quando ouvimos falar em Microsoft Copilot, muitas pessoas imaginam apenas uma janela semelhante ao ChatGPT.

Na realidade, o Copilot é muito maior.

Ele está sendo integrado ao ecossistema Microsoft inteiro.

Isso significa que ele pode trabalhar dentro de aplicações que você provavelmente já utiliza diariamente.

Entre elas:

• Word

• Excel

• PowerPoint

• Outlook

• Teams

• OneNote

• SharePoint

• OneDrive

• Planner

• Loop

• Microsoft 365

Ou seja...

Em vez de abrir uma ferramenta separada para pedir ajuda, a IA passa a trabalhar dentro do ambiente onde você já executa suas tarefas.

Esse detalhe muda completamente a experiência do usuário.

---

Copilot no Word: muito além de escrever textos

Quando alguém fala em Word, normalmente pensa em documentos.

Mas um programador produz muito mais documentação do que imagina.

Durante um projeto, são criados:

• documentos técnicos;

• especificações funcionais;

• documentação de APIs;

• manuais operacionais;

• runbooks;

• procedimentos de instalação;

• planos de contingência;

• documentação para auditoria.

Tudo isso consome horas.

O Copilot consegue acelerar esse processo.

Você pode fornecer apenas alguns tópicos:

"Documente este processo Batch em COBOL."

Ou:

"Explique este programa para um desenvolvedor júnior."

Em poucos segundos surge uma primeira versão bastante consistente.

Ela não substitui sua revisão.

Mas elimina a parte mais cansativa: começar do zero.

---

Um exemplo no mundo Mainframe

Imagine um JOB JCL responsável pelo fechamento financeiro.

Normalmente, um analista experiente precisaria ler dezenas de etapas para entender seu funcionamento.

Com IA você pode solicitar:

"Explique este JOB utilizando linguagem simples."

Ou ainda:

"Transforme esta documentação em um guia para operadores."

O resultado é um material muito mais acessível para novos integrantes da equipe.

---

Excel: uma das maiores revoluções silenciosas

Existe uma brincadeira que diz:

"Metade do mundo funciona graças ao Excel."

Pode parecer exagero.

Mas basta observar quantas decisões empresariais dependem de planilhas.

No ambiente Mainframe isso também acontece.

Relatórios de CPU.

Consumo de disco.

Quantidade de transações.

Volume de processamento.

Abends.

Tempo de resposta.

Capacidade.

Tudo acaba chegando em alguma planilha.

Até pouco tempo atrás era necessário construir fórmulas complexas, tabelas dinâmicas e gráficos manualmente.

Hoje basta perguntar.

Por exemplo:

"Quais aplicações consumiram mais CPU?"

Ou:

"Existe alguma tendência de crescimento no uso deste dataset?"

O Copilot interpreta os dados, cria gráficos, identifica padrões e até sugere explicações.

Para quem ainda está aprendendo Excel, isso representa uma enorme vantagem.

---

PowerPoint: comunicação também faz parte do trabalho

Um dos maiores erros dos programadores iniciantes é acreditar que desenvolvimento de software significa apenas escrever código.

Na realidade, passamos boa parte do tempo comunicando ideias.

Precisamos explicar:

• problemas;

• soluções;

• arquiteturas;

• cronogramas;

• riscos;

• resultados.

O PowerPoint continua sendo uma das ferramentas mais utilizadas para isso.

O Copilot pode transformar um documento técnico inteiro em uma apresentação organizada.

Imagine um manual IBM de cinquenta páginas.

Em poucos minutos ele pode produzir:

• resumo executivo;

• treinamento;

• apresentação comercial;

• workshop;

• material para onboarding.

Isso economiza muitas horas.

---

Outlook: administrando o caos

Quem nunca recebeu dezenas de e-mails em um único dia?

No ambiente corporativo isso é rotina.

Especialmente em grandes bancos.

Muitos desses e-mails possuem dezenas de respostas.

Ler tudo pode consumir boa parte do expediente.

O Copilot consegue:

• resumir conversas;

• identificar decisões;

• destacar pendências;

• sugerir respostas;

• organizar prioridades.

Em vez de gastar meia hora lendo uma longa discussão, você entende rapidamente o contexto.

---

Teams: reuniões que realmente geram resultados

Reuniões fazem parte do desenvolvimento de software.

Planejamento.

Daily.

Refinamento.

Arquitetura.

Produção.

Mudanças.

Problemas.

Incidentes.

O problema é que normalmente alguém precisa registrar tudo.

Durante a reunião, o Copilot pode produzir automaticamente:

• ata;

• resumo;

• decisões;

• responsáveis;

• prazos;

• tarefas.

Imagine uma reunião envolvendo SysProg, DBA, Desenvolvedores COBOL e Operação.

Ao final, ninguém precisa perguntar:

"Quem ficou responsável por isso?"

Tudo já está registrado.

---

OneNote: construindo sua base de conhecimento

Todo programador acumula conhecimento diariamente.

Comandos.

Atalhos.

Mensagens de erro.

Links.

Procedimentos.

Tutoriais.

Anotações.

O problema é organizar tudo isso.

O Copilot consegue transformar páginas completamente bagunçadas em documentação estruturada.

É como possuir um assistente organizando seu caderno de estudos.

---

O verdadeiro cérebro do Copilot: Microsoft Graph

Existe um componente pouco conhecido, mas extremamente importante.

Chama-se Microsoft Graph.

É ele que conecta praticamente todos os serviços do Microsoft 365.

Quando o Copilot responde uma pergunta como:

"Mostre os documentos relacionados ao Projeto Alfa."

Ele pode consultar:

• SharePoint;

• Outlook;

• Teams;

• OneDrive;

• Planner;

• Calendário.

Ou seja...

Ele não responde apenas utilizando conhecimento geral.

Ele utiliza o conhecimento da própria organização.

Esse é um dos grandes diferenciais em relação a um chatbot isolado.

---

IA integrada ao fluxo de trabalho

Aqui está a maior mudança de mentalidade.

Imagine duas empresas.

A primeira possui IA.

Mas ela é utilizada apenas ocasionalmente.

Sempre que alguém lembra.

A segunda empresa integrou IA ao processo.

Cada documento passa pelo Copilot.

Cada reunião gera resumo automático.

Cada planilha recebe análise.

Cada apresentação nasce assistida por IA.

Cada procedimento é documentado automaticamente.

Qual empresa tende a produzir mais?

A resposta é evidente.

O ganho não vem apenas da tecnologia.

Vem da integração.

---

E no IBM Mainframe?

Talvez você esteja pensando:

"Tudo isso parece interessante... mas trabalho com Mainframe."

Na verdade, o impacto pode ser ainda maior.

Imagine um Copilot conectado ao ambiente corporativo.

Você pergunta:

"Explique este ABEND S0C7."

Ou:

"Quais tabelas DB2 este programa acessa?"

Ou:

"Documente este JCL."

Ou ainda:

"Explique este PROC para um operador iniciante."

Essas tarefas deixam de consumir horas.

---

IA para SysProg

Um administrador de sistemas IBM Z também pode se beneficiar enormemente.

Imagine perguntas como:

"Quais JOBs ficaram mais de vinte minutos em HOLD?"

"Mostre os datasets que cresceram acima de 15%."

"Explique este RACF Permit."

"Quais CICS apresentaram maior consumo de CPU?"

"Existe documentação deste procedimento?"

Perceba que a IA deixa de ser apenas um gerador de texto.

Ela passa a atuar como um assistente operacional.

---

O próximo passo: Agentes Inteligentes

Estamos entrando em uma nova fase da Inteligência Artificial.

Até pouco tempo atrás fazíamos perguntas.

Agora começamos a criar agentes.

Mas o que é um agente?

Pense em um funcionário digital.

Ele possui uma missão específica.

Pode consultar informações.

Executar tarefas.

Tomar pequenas decisões.

Gerar documentação.

Enviar notificações.

Tudo automaticamente.

---

Um exemplo prático

Imagine um incidente em produção.

Hoje o fluxo costuma ser:

O operador percebe o problema.

↓

Abre um chamado.

↓

Alguém analisa.

↓

Consulta documentação.

↓

Encontra a causa.

↓

Atualiza registros.

↓

Comunica a equipe.

Com agentes inteligentes, parte desse processo pode ser automatizada.

O agente identifica o evento.

Consulta a documentação.

Relaciona ocorrências semelhantes.

Sugere a causa provável.

Gera um relatório.

Atualiza o sistema de chamados.

Notifica os responsáveis.

Tudo em poucos minutos.

---

O papel do programador não desaparece

Existe um medo recorrente.

"A IA vai substituir os programadores?"

A resposta mais equilibrada é:

Ela substituirá tarefas repetitivas.

Mas continuará sendo necessário alguém capaz de:

• entender o negócio;

• validar resultados;

• definir arquitetura;

• garantir segurança;

• interpretar requisitos;

• tomar decisões.

A IA acelera.

Mas quem conduz continua sendo o profissional.

---

O que um programador júnior deve aprender agora?

Se eu pudesse orientar alguém que está iniciando sua carreira em desenvolvimento, sugeriria o seguinte roteiro:

1. Aprenda lógica de programação profundamente.

2. Domine uma linguagem de programação.

3. Aprenda Git e controle de versões.

4. Estude SQL.

5. Entenda arquitetura de software.

6. Aprenda documentação técnica.

7. Desenvolva habilidades de comunicação.

8. Utilize IA diariamente.

9. Aprenda a criar bons prompts.

10. Automatize tarefas repetitivas.

Perceba que a IA aparece como uma ferramenta complementar, e não como substituta dos fundamentos.

---

O futuro pertence aos profissionais aumentados por IA

A maior transformação da Inteligência Artificial não é tecnológica.

Ela é cultural.

Durante décadas, utilizamos computadores para executar comandos.

Agora começamos a trabalhar ao lado de sistemas capazes de compreender linguagem natural, interpretar contexto, resumir informações e auxiliar na tomada de decisões.

Isso muda completamente a forma como produzimos software.

O Microsoft Copilot representa muito bem essa nova realidade.

Ele não foi criado apenas para escrever textos ou gerar apresentações.

Seu verdadeiro objetivo é integrar a Inteligência Artificial ao cotidiano do trabalho, reduzindo tarefas repetitivas, organizando informações e permitindo que os profissionais concentrem seus esforços naquilo que realmente exige criatividade, experiência e pensamento crítico.

Para quem está começando na carreira, essa é uma oportunidade extraordinária. Nunca foi tão fácil aprender, documentar, pesquisar e acelerar o desenvolvimento de novas habilidades. Porém, é importante lembrar que nenhuma ferramenta substitui uma boa base técnica. Conhecimentos em lógica, algoritmos, arquitetura, banco de dados, redes, sistemas operacionais e boas práticas de engenharia continuam sendo os pilares de uma carreira sólida.

No universo IBM Mainframe, essa transformação também já começou. Desenvolvedores COBOL, analistas de sistemas, DBAs e SysProgs podem utilizar a IA para compreender códigos legados, documentar aplicações, analisar incidentes, automatizar processos e compartilhar conhecimento com muito mais eficiência.

A tecnologia muda rapidamente. Os fundamentos da Engenharia de Software permanecem. O profissional que combinar esses fundamentos com o uso inteligente da IA estará preparado não apenas para acompanhar a evolução do mercado, mas para liderá-la.

Porque, no fim das contas, a Inteligência Artificial não veio para pensar no lugar do desenvolvedor. Ela veio para ampliar aquilo que ele faz de melhor: resolver problemas, criar soluções e transformar conhecimento em valor. Esse continuará sendo o verdadeiro diferencial dos grandes profissionais da Engenharia de Software.

 

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.