 |
| 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:
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:
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:
observar sinais;
correlacionar eventos;
detectar anomalias;
procurar padrões históricos;
priorizar hipóteses;
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:
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.
