☕ 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

terça-feira, 13 de março de 2012

Narrative Bias: Doctor Who, COBOL e o Dia em que uma Boa História Quase Virou Root Cause

Bellacosa Mainframe apresenta a narrative bias

☕ Um Café no Bellacosa Mainframe

Narrative Bias: Doctor Who, COBOL e o Dia em que uma Boa História Quase Virou Root Cause

Uma viagem pela TARDIS dos incidentes para entender por que narrativas coerentes parecem mais verdadeiras do que explicações fragmentadas — e como isso pode transformar coincidência em causa dentro de uma War Room

08:26.

Terça-feira.

War Room.

Café já na segunda rodada.

Na tela:

08:00 DEPLOY
08:07 LATENCY ↑
08:12 TIMEOUTS ↑
08:15 CUSTOMER COMPLAINTS

O gerente olha.

— Está claro.

Nosso jovem programador COBOL pergunta:

— O quê?

— O deploy causou o incidente.

Silêncio.

A timeline parece perfeita.

Mudança.

Depois lentidão.

Depois timeout.

Depois cliente.

Começo.

Meio.

Fim.

Bonito.

Quase cinematográfico.

O especialista concorda:

— Faz sentido.

Outro:

— Deve ter sido a nova rotina.

O programador pergunta:

— Já encontramos evidência?

— A evidência está aí.

Apontam para:

08:00 DEPLOY
08:07 LATENCY

Nosso jovem olha de novo.

— Isso mostra sequência.

— Exatamente.

— Mas mostra causa?

Silêncio.

Um DBA abre as métricas.

Db2 normal.

MQ normal.

CPU normal.

A nova rotina é executada apenas em 4% das transações.

Mas 82% dos timeouts aparecem em um fluxo que nem passa pelo código alterado.

A história começa a ficar menos elegante.

Então surge outro dado:

07:54
EXTERNAL API LATENCY ↑

Seis minutos antes do deploy.

O gerente observa.

— Então talvez não tenha sido a mudança.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se ao lado do flip chart.

A porta abre.

O Doctor sai.

Olha para a timeline.

Depois para a equipe.

— Qual era a história?

O gerente responde:

— Deploy causou lentidão.

— Era uma boa história?

— Muito boa.

— Tinha começo?

— Sim.

— Meio?

— Sim.

— Final?

— Sim.

O Doctor sorri.

— Então naturalmente vocês quase acreditaram nela.

Pausa.

— O cérebro humano adora histórias bem mais do que adora logs.

Bem-vindo ao:



Narrative Bias

Ou:

Viés Narrativo

A tendência de organizar fatos, eventos e dados em histórias coerentes e, depois, atribuir a essas histórias mais verdade, causalidade e previsibilidade do que as evidências realmente permitem.

Em linguagem Bellacosa:

“Se a história faz sentido, começamos a achar que ela aconteceu exatamente assim.”


🌀 Onde estamos na nossa TARDIS dos incidentes?

Nossa jornada já encontrou uma longa coleção de criaturas cognitivas:

Swiss Cheese Model mostrou que várias defesas podem falhar juntas.

Normalization of Deviance mostrou como desvios viram rotina.

Hindsight Bias mostrou como tudo parece óbvio depois do final.

Confirmation Bias mostrou como buscamos provas para aquilo em que acreditamos.

Anchoring Bias mostrou como a primeira informação prende a investigação.

Groupthink mostrou como consenso pode aparecer cedo demais.

Authority Gradient mostrou como hierarquia pode silenciar dúvida.

Plan Continuation Bias mostrou como continuamos planos que já perderam sentido.

Alarm Fatigue mostrou como alertas demais viram ruído.

Automation Bias mostrou como confiamos demais em ferramentas.

Drift Into Failure mostrou como sistemas derivam lentamente para a borda.

Diffusion of Responsibility mostrou como todos podem ver e ninguém agir.

Normalcy Bias mostrou como esperamos que tudo volte ao normal.

Survivorship Bias mostrou como estudamos apenas os sobreviventes.

Base Rate Neglect mostrou como esquecemos frequências reais.

Availability Heuristic mostrou como o memorável parece mais provável.

Outcome Bias mostrou como confundimos bom resultado com boa decisão.

Overconfidence Bias mostrou como confiança excessiva pode reduzir verificação.

Planning Fallacy mostrou como subestimamos tempo e complexidade.

Sunk Cost Fallacy mostrou como o passado prende o futuro.

Status Quo Bias mostrou como o atual recebe privilégio psicológico.

Present Bias mostrou como o agora pesa mais que o depois.

Optimism Bias mostrou como esperamos resultados favoráveis.

Action Bias mostrou como agir pode parecer melhor que observar.

Omission Bias mostrou como não agir pode parecer menos culpável.

Loss Aversion mostrou como perder dói mais que ganhar alegra.

Framing Effect mostrou como a moldura altera a decisão.

Recency Bias mostrou como o recente recebe peso exagerado.

Representativeness Heuristic mostrou como algo que “parece X” vira rapidamente “deve ser X”.

Agora pegamos todos esses ingredientes...

e colocamos dentro de uma história.


🧠 O que é Narrative Bias?

Seres humanos não gostam muito de eventos soltos.

Gostamos de:

causas;

motivos;

sequências;

personagens;

explicações.

Imagine:

A aconteceu.
Depois B.
Depois C.

Nosso cérebro rapidamente começa:

“A causou B, que causou C.”

Talvez.

Mas também pode ser:

X causou A.
X causou B.
X causou C.

Ou:

A foi irrelevante.
B e C vieram de X.

Ou simplesmente:

alguns eventos coincidiram no tempo.

Narrativa organiza.

Mas organização não é automaticamente causalidade.


☕ O programador e a timeline sedutora

Deploy:

08:00.

Falha:

08:07.

É natural pensar:

deploy causou falha.

E frequentemente causa mesmo.

Mudanças recentes merecem investigação.

Mas a timeline produz um poder narrativo enorme:

post hoc ergo propter hoc

“Depois disso, portanto por causa disso.”

É uma falácia clássica.

Sequência temporal é evidência.

Mas não prova suficiente.


🧠 Correlação temporal ≠ causalidade

Uma mudança acontece.

Logo depois, problema.

Perguntas:

  • o componente alterado participa do fluxo?

  • a falha aparece em transações não afetadas?

  • existe mecanismo plausível?

  • o problema já havia começado antes?

  • rollback altera comportamento?

  • existe mudança externa concomitante?

Sem isso:

temos história.

Não necessariamente RCA.


👻 Easter Egg nº 1 — “Foi a TARDIS”

A TARDIS materializa.

Cinco segundos depois, luzes piscam.

Companion:

— A TARDIS causou isso.

Doctor:

— Como sabe?

— Ela apareceu e depois as luzes começaram.

— Então se chover depois que você abrir um guarda-chuva...

Pausa.

— você controla o clima?

A narrativa precisa de mecanismo.


🧠 O cérebro odeia “não sabemos”

Essa talvez seja uma das raízes do problema.

“Não sabemos” é desconfortável.

Uma história preenche o vazio.

Exemplo:

“Foi a mudança.”

Pronto.

Ansiedade cai.

Agora temos culpado.

Plano.

Sentido.

Uma boa narrativa reduz incerteza psicológica.

Mesmo sem reduzir incerteza técnica.


☕ Bellacosa Mainframe: RCA de cinco minutos

Incidente abre às 08:10.

Às 08:15:

— Já sabemos a causa.

Isso pode acontecer.

Mas às vezes é apenas narrativa prematura.

O sistema complexo ainda nem terminou de produzir evidência.


🧠 Narrative Bias + Hindsight Bias

Depois do incidente:

eventos são reorganizados numa sequência limpa.

Antes:

caos.

Depois:

CHANGE
↓
ERROR
↓
ALERT
↓
OUTAGE
↓
FIX

Parece inevitável.

Hindsight Bias diz:

“Era óbvio.”

Narrative Bias diz:

“E aconteceu exatamente por essa cadeia.”

Talvez a realidade tivesse:

três causas concorrentes;

tentativas inúteis;

efeitos paralelos;

sorte.

A história pós-incidente tende a limpar bagunça.


🧠 Post-mortems precisam de cuidado

Post-mortem precisa contar história.

É impossível documentar sem narrativa.

Mas uma boa análise distingue:

Timeline factual

de:

interpretação causal.

Exemplo:

FACT:
08:00 deploy

FACT:
08:07 latency increased

HYPOTHESIS:
deploy contributed

EVIDENCE:
...

Muito melhor que:

08:00 deploy caused latency

quando ainda não foi demonstrado.


🔎 Narrative Bias + Confirmation Bias

Uma vez criada a história:

“deploy quebrou sistema”

começamos a buscar tudo que cabe nela.

Log novo?

— consequência do deploy.

Métrica anterior?

— provavelmente ruído.

API externa lenta?

— efeito indireto.

A narrativa começa a absorver fatos.

Confirmation Bias a protege.


⚓ Anchoring Bias

Primeira história apresentada:

“mudança causou.”

Agora tudo gira em torno dela.

Uma narrativa é uma âncora especialmente poderosa porque não é apenas uma informação.

É uma estrutura inteira.


👥 Groupthink

Gerente conta história convincente.

Equipe inteira entende.

Isso importa.

Histórias compartilhadas criam consenso rápido.

Um técnico que traz uma explicação feia:

“Talvez sejam três fatores independentes”

tem desvantagem.

A história simples vence.


🪜 Authority Gradient

Se a narrativa vem do especialista:

“Já sei exatamente o que aconteceu.”

o júnior pode abandonar dados contraditórios.

Narrative Bias + Authority Gradient transforma storytelling em causalidade oficial.


🧠 Representativeness Heuristic entra perfeitamente

O incidente:

tem cara de Db2.

Então criamos história:

“Db2 começou a segurar lock, fila aumentou e sistema caiu.”

Agora narrativa conecta o padrão.

Mesmo se os locks forem normais.

Representativeness escolhe personagem.

Narrative Bias escreve roteiro.


🧠 Recency Bias fornece roteiro recente

Sexta:

MQ.

Segunda:

latência.

História:

“MQ voltou.”

O incidente recente fornece estrutura narrativa pronta.

Não precisamos sequer inventar outra.


🧠 Availability fornece histórias memoráveis

Histórias dramáticas são fáceis de lembrar.

“Uma vez storage corrompeu tudo.”

Então novo sintoma estranho:

“Pode ser storage de novo.”

Narrative Bias adora histórias vivas.


🧠 Framing Effect decide quem é herói e vilão

Mesmo timeline pode ser contada de formas diferentes.

Frame A:

“Operador errou comando.”

Frame B:

“Sistema permitia comando crítico sem validação.”

Frame C:

“Equipe trabalhava sob pressão e runbook estava incorreto.”

Todos descrevem partes reais.

Mas cada história produz ações diferentes.


☕ O vilão conveniente

Narrativas gostam de personagens.

Em post-mortem:

o operador;

o fornecedor;

o deploy;

o DBA;

o “legacy”.

Um vilão deixa história simples.

Mas sistemas críticos frequentemente falham por interações.

O Swiss Cheese Model não gosta de vilões únicos.


🧀 Swiss Cheese versus Narrative Bias

Narrative Bias quer:

“A causa.”

Swiss Cheese pergunta:

“Quais condições e barreiras se alinharam?”

Essa diferença é enorme.

Exemplo:

não foi apenas:

desenvolvedor cometeu erro.

Pode haver:

teste ausente;

review incompleto;

deadline;

monitoramento fraco;

rollback ruim;

permissão excessiva.

Uma história mono-causal pode destruir aprendizado.


🌀 Drift Into Failure também é péssimo para narrativas simples

Drift não tem um vilão.

Não tem momento épico.

Só:

pequenas decisões razoáveis.

Por isso é difícil contar.

Depois do acidente, inventamos:

“Tudo começou quando Fulano mudou X.”

Talvez não.

Talvez a organização estivesse derivando há anos.


🧠 Histórias adoram pontos de início

Sistemas complexos não necessariamente têm.

Quando começou o incidente?

08:07?

Ou:

quando margem caiu há seis meses?

Ou:

quando workaround virou processo há três anos?

Narrativa escolhe início.

A escolha influencia causalidade.


🎯 Pergunta Bellacosa nº 1

Quando alguém contar a história do incidente:

“Por que começamos a timeline justamente aqui?”

Excelente.

Talvez o problema tenha começado antes.


🎯 Pergunta Bellacosa nº 2

“Quais fatos não cabem confortavelmente nessa história?”

Esses fatos são especialmente valiosos.


🎯 Pergunta Bellacosa nº 3

“Que outra narrativa explica os mesmos dados?”

Agora criamos competição.


🎯 Pergunta Bellacosa nº 4

“Que mecanismo liga A a B?”

Não basta:

A veio antes.


🧠 Coherence ≠ truth

Uma história pode ser:

coerente;

elegante;

memorável;

errada.

Enquanto a explicação verdadeira pode ser:

feia;

fragmentada;

sem clímax.

Produção não precisa de literatura.

Precisa da explicação que melhor suporta os dados.


☕ Embora literatura ajude no blog

Claro.

Aqui podemos usar TARDIS.

Na War Room:

logs primeiro.

Daleks depois.


🧠 Narrative Bias na segurança

Incidente:

login estranho;

dados exportados;

conta privilegiada.

Narrativa:

“Atacante externo comprometeu credencial.”

Talvez.

Outra:

funcionário legítimo;

automação;

erro de integração.

A narrativa de ataque é emocionalmente forte.

Threat investigation precisa confirmar.


🔐 Attribution Bias

Em cyber, atribuir ataque a grupo ou país cedo demais é um perigo enorme.

Porque padrões podem ser copiados.

Ferramentas reutilizadas.

Infra compartilhada.

Narrativa geopolítica pode surgir antes da evidência.


🧠 Narrative Bias + Representativeness

Malware parece com APT X.

Então:

“É APT X.”

Depois história cresce:

motivo;

objetivo;

país.

Uma cadeia enorme construída sobre similaridade inicial.

Cuidado.


🏦 Fraude financeira

Cliente faz cinco transações incomuns.

Narrativa:

“Conta tomada.”

Mas talvez:

viagem;

mudança de aparelho;

compra legítima.

Fraude detection precisa dados.

Não novela.


🧠 Base Rate Neglect

História específica e rica pode vencer estatística.

“Esse comportamento parece exatamente um ataque sofisticado.”

Taxa-base:

ataques sofisticados são raríssimos.

A narrativa específica parece mais verdadeira porque é detalhada.

Base rate desaparece.


📚 A força dos detalhes

Quanto mais detalhes plausíveis uma história possui, mais convincente ela pode parecer.

Mas adicionar detalhes não aumenta necessariamente probabilidade.

Às vezes diminui.

Mais afirmações precisam ser verdadeiras.


🧠 Linda Problem novamente

A famosa questão da Linda é um belo exemplo de como uma descrição narrativa rica pode fazer uma opção mais específica parecer mais provável que uma categoria mais ampla.

Isso se conecta à Representativeness Heuristic e à Conjunction Fallacy.

Nosso cérebro prefere:

história que encaixa

à:

probabilidade abstrata.


☕ Conjunction Fallacy no mainframe

Imagine:

Opção A:

“O timeout é causado por problema de aplicação.”

Opção B:

“O timeout é causado por aplicação após deploy, combinado com retry MQ e lock Db2.”

B parece muito mais sofisticada.

Talvez até mais convincente.

Mas exige várias condições simultâneas.

Não deveria automaticamente ser mais provável.

Detalhe não é probabilidade.


🧠 Narrative complexity

Quanto mais rica a história:

mais pontos possíveis de falha.

Mas psicologicamente:

mais real.

Isso é fascinante.


💻 COBOL e o bug com roteiro perfeito

Programa começou a falhar depois de novo copybook.

História:

copybook mudou offset, corrompeu campo packed e causou S0C7.

Linda.

Você verifica dump.

Campo que abendou nem pertence ao copybook alterado.

A história morreu.

Ótimo.

Mate narrativas cedo quando dados discordam.


🧠 Apegamo-nos à narrativa porque investimos nela

Agora Sunk Cost aparece.

Equipe gastou duas horas construindo explicação.

Novos dados contradizem.

Abandonar significa:

admitir que tempo foi perdido.

Então tentamos salvar história.

Sunk Cost + Narrative Bias.


▶️ Plan Continuation Bias

A investigação possui plano:

“Vamos provar que foi Db2.”

Já começou.

Agora continua.

Mesmo quando evidência piora.

A narrativa dá direção ao plano.


🧠 Overconfidence Bias

Especialista conta história fluida.

Fluência parece domínio.

Quanto mais facilmente explica:

mais confiança os outros sentem.

Mas eloquência não mede causalidade.


🤖 IA e Narrative Bias

Aqui o tema fica especialmente importante.

Modelos de linguagem são muito bons em construir narrativas coerentes.

Você fornece:

cinco logs incompletos.

Pergunta:

“O que aconteceu?”

A IA pode construir uma sequência plausível.

Talvez esteja certa.

Talvez esteja preenchendo lacunas.

Usuário pode confundir:

coerência textual

com:

evidência operacional.

Automation Bias amplifica.


🧠 Fluent answer ≠ verified answer

Uma resposta pode ser:

bonita;

organizada;

confiante;

errada.

Por isso, em RCA assistida por IA:

exija:

fatos;

fontes;

nível de confiança;

alternativas;

lacunas.


☕ Prompt perigoso

“Explique como o deploy causou o incidente.”

Esse prompt já colocou causa no frame.

A IA provavelmente ajuda a construir narrativa.

Melhor:

“Avalie se existe evidência de que o deploy contribuiu e liste explicações alternativas.”

Framing + Narrative Bias.


🧠 AI hallucination e narrative completion

Quando dados faltam, um modelo pode completar padrões plausíveis.

Humano faz algo parecido.

Narrative Bias é quase nossa “alucinação explicativa” natural.

Diferença:

precisamos marcar o que é:

fato;

inferência;

hipótese.


📋 Fato, inferência, hipótese

Uma estrutura excelente:

FACT:
API latency increased at 07:54.

INFERENCE:
This could explain application waits.

HYPOTHESIS:
External API degradation contributed to outage.

Não misture.


🧠 Epistemic tagging

Rotule afirmações.

Fato confirmado.

Provável.

Possível.

Desconhecido.

Isso reduz história endurecendo cedo demais.


☕ O “sabemos” corporativo

War Room:

— Sabemos que foi rede.

Pergunta:

— Sabemos ou suspeitamos?

Essa distinção deveria virar hábito.


🧠 Narrative Bias em dashboards

Dashboard mostra indicadores numa ordem.

Você vê:

CPU ↑

depois timeouts ↑.

Mentalmente:

CPU causou timeouts.

Mas talvez ambos sejam efeitos de terceiro fator.

Layout também cria narrativa.


📊 Correlation panels

Colocar métricas lado a lado sugere relação.

Mesmo quando não existe.

Visualização também conta história.

Framing Effect retorna.


🧠 Temporal precedence é necessária, mas não suficiente

Para A causar B:

A normalmente precisa vir antes de B.

Mas isso não basta.

Sol nasce antes de eu tomar café.

Não significa que o sol preparou meu café.

Embora seria excelente serviço.


🧪 Causal mechanism

Procure mecanismo.

Se:

API externa lenta

causa:

threads esperando,

que causam:

pool esgotado,

que causa:

timeouts,

podemos testar cada elo.

Agora temos uma narrativa causal testável.


🧠 Causal graph

Represente:

API LATENCY
   ↓
THREAD WAIT
   ↓
POOL SATURATION
   ↓
TIMEOUT

Para cada seta:

evidência.

Isso é muito mais robusto que prosa.


☕ Narrativa vira grafo

Excelente ideia Bellacosa.

Transforme história em grafo causal.

Se uma seta não tem evidência:

marque.

Agora vemos buracos.


🧠 Causal DAGs

Em análise mais formal, grafos causais podem ajudar a estruturar hipóteses.

Não precisa virar doutorado estatístico.

O princípio:

cada ligação da história precisa ser justificável.


🔎 Counterfactual

Pergunta:

“Se o deploy não tivesse acontecido, esperaríamos ver o mesmo problema?”

Difícil responder, mas útil.

Outra:

“Após rollback, o problema desapareceu?”

Se não:

a narrativa deploy→falha enfraquece.


🧪 A/B natural

Algumas transações passaram pelo código novo.

Outras não.

Se ambas falham igual:

a hipótese cai.

Perfeito.

Use variações naturais para testar causalidade.


🧠 Narrative Bias e Success Stories

Não apenas incidentes.

Projetos bem-sucedidos também.

História:

“Empresa adotou microserviços e cresceu.”

Talvez.

Mas crescimento pode ter vindo de produto, mercado, equipe.

Narrativa de sucesso simplifica causalidade.

Survivorship Bias entra.


☕ Case study é história, não experimento controlado

Case studies são úteis.

Mas não prove:

“Faça igual e terá igual resultado.”

Contexto importa.


🧠 Strategy narratives

Executivos precisam histórias para comunicar estratégia.

Isso é normal.

Mas decisões técnicas precisam manter separação entre:

storytelling;

evidência.


📈 Narrative Bias em performance

Funcionário erra uma entrega recente.

Gerente cria história:

“Ele não lida bem com pressão.”

Talvez.

Ou foi evento isolado.

Recency + Narrative Bias cria identidade a partir de episódio.

Perigoso.


🧠 Fundamental Attribution Error no horizonte

Outro viés relacionado.

Tendemos a explicar comportamento dos outros por personalidade e subestimar contexto.

Excelente futuro capítulo.


👥 “Fulano é descuidado”

Post-mortem:

operador digitou comando.

História:

“Fulano é descuidado.”

Mas contexto:

12 horas de plantão;

interface ambígua;

sem validação.

Uma narrativa de personagem pode esconder sistema.


🧠 Just Culture versus narrativa moral

Histórias gostam de:

herói;

vilão;

erro;

redenção.

Just Culture tenta:

contexto;

incentivos;

barreiras;

decisão local.

Menos cinematográfico.

Mais útil.


☕ Não faça CSI da War Room

Música dramática.

Zoom no log.

— Achei!

Produção real raramente fecha episódio em 42 minutos.

Embora seria conveniente.


🧠 Narrative Bias e Outcome Bias

Resultado bom.

História:

“Nossa estratégia funcionou.”

Talvez.

Outcome Bias já vimos.

Narrative Bias cria explicação pós-hoc.

Agora sorte ganha roteiro.


🎲 Luck gets edited out

Depois do sucesso:

história remove:

acaso;

timing;

intervenção inesperada.

Fica:

competência.

Depois do fracasso:

história remove incerteza.

Fica:

erro.

Cuidado.


🧠 Decision Journal contra Narrative Bias

Registre antes:

hipóteses;

confiança;

dados.

Depois compare.

Isso impede reconstruir história perfeita.


📝 Raw timeline

Preserve logs brutos.

Depois você pode contar narrativa.

Mas não destrua:

ordem real;

dados contraditórios;

tentativas fracassadas.

O caos também é evidência.


🧠 Failed hypotheses matter

No post-mortem:

não registre apenas causa final.

Registre:

hipóteses descartadas.

Isso mostra:

por que eram plausíveis;

qual dado as derrubou.

Treina pensamento.


☕ O caminho errado também ensina

DB2 investigado por 20 min.

Descartado porque locks normais.

Ótimo.

Não apague.

Isso ajuda próximo incidente.


🧠 Narrative compression

Toda história comprime.

Problema é comprimir demais.

De:

20 eventos

para:

“deploy quebrou tudo.”

Perdemos nuance.

Use níveis:

resumo executivo;

timeline detalhada;

evidências.


📊 Executive summary sem ficção

Boa síntese:

“O incidente correlacionou-se temporalmente com o deploy, mas a investigação mostrou degradação da API externa iniciando seis minutos antes. O código novo aumentou o impacto em um subconjunto das transações, mas não foi a causa inicial.”

Muito melhor.

Reconhece múltiplos fatores.


🧠 Multi-causality

Sistemas complexos frequentemente falham com:

causa inicial;

condições contribuintes;

amplificadores;

barreiras ausentes.

Narrativa de causa única empobrece.


🧀 Swiss Cheese novamente

Uma boa história de incidente pode usar camadas:

trigger;

contributing conditions;

failed defenses;

recovery.

Isso continua sendo narrativa.

Mas é narrativa disciplinada por modelo sistêmico.


🎯 Pergunta Bellacosa nº 5

“Estamos contando uma causa ou uma cadeia de condições?”

Muitas vezes a segunda é melhor.


🧠 Narrative Bias não significa abandonar histórias

Importante.

Histórias são excelentes para:

ensinar;

lembrar;

comunicar.

Bellacosa Mainframe existe graças a isso.

A defesa não é:

“sem narrativa.”

É:

narrativa com rastreabilidade para evidência.


☕ Storytelling com checksum

Podemos brincar:

história precisa ter checksum.

Cada afirmação relevante:

volta para um log;

métrica;

testemunho;

change record.

Se não:

marque como hipótese.


🧠 Facts survive reframing

Outra técnica.

Conte duas histórias diferentes.

Quais fatos permanecem?

Esses fatos têm maior valor.

Framing Effect encontra Narrative Bias.


🧪 Competing Narratives

Narrativa A:

deploy causou.

Narrativa B:

API externa causou.

Narrativa C:

ambos contribuíram.

Teste cada.

Não escolha pela elegância.


📊 Evidence Matrix

                 DEPLOY   API   BOTH

Latency before 08:00       ✗     ✓     ✓
Only new flow affected?    ?     ✗     ?
Rollback fixed issue?      ✗     ✓     ✓
API response 12s           ✗     ✓     ✓

Agora narrativa perde monopólio.


🧠 Abduction

Na filosofia da ciência, inferência para a melhor explicação busca a hipótese que melhor explica evidências.

Mas:

“melhor”

não significa:

“mais bonita.”

Significa:

mais suporte;

menos contradições;

mais poder explicativo;

mais testabilidade.


☕ Sherlock Holmes de verdade

Não:

“A história parece brilhante.”

Mas:

“Qual hipótese sobrevive melhor aos fatos?”

Muito menos dramático.

Muito mais eficaz.


🤖 IA como adversarial storyteller

Uma aplicação ótima:

peça à IA:

“Construa três explicações alternativas para estes mesmos dados e diga que evidência distinguiria cada uma.”

Agora capacidade narrativa trabalha a favor do diagnóstico.


🧠 Use o viés contra o viés

Se humanos adoram narrativas:

crie narrativas concorrentes.

Isso reduz monopólio da primeira história.


🎯 Bellacosa AI Prompt

“Liste os fatos confirmados, depois três histórias causais plausíveis e, para cada uma, o teste mais barato que poderia derrubá-la.”

Excelente.


📋 Checklist anti-Narrative Bias

[ ] Quais fatos são realmente confirmados?

[ ] Quais partes da história são inferências?

[ ] Estamos confundindo sequência temporal com causa?

[ ] Existe mecanismo ligando os eventos?

[ ] Quais fatos não cabem na narrativa?

[ ] Qual história alternativa explica os mesmos dados?

[ ] Estamos procurando um único vilão?

[ ] A timeline começou cedo o suficiente?

[ ] O problema já existia antes do evento que culpamos?

[ ] Estamos apagando hipóteses descartadas?

[ ] Existe evidência para cada elo causal?

[ ] A narrativa mudou depois de conhecermos o resultado?

[ ] Uma IA está preenchendo lacunas com plausibilidade?

[ ] Estamos preferindo coerência à probabilidade?

🧪 Passo a passo para combater Narrative Bias

Passo 1 — Separe fatos e interpretação

Primeiro bloco.


Passo 2 — Monte timeline crua

Sem causalidade.


Passo 3 — Formule mais de uma narrativa

Competição.


Passo 4 — Exija mecanismo

A → B como?


Passo 5 — Procure fatos inconvenientes

Eles valem ouro.


Passo 6 — Use base rates

A história é provável?


Passo 7 — Faça testes discriminantes

Qual hipótese cai primeiro?


Passo 8 — Preserve hipóteses rejeitadas

Aprendizado.


Passo 9 — Evite linguagem de certeza precoce

“Pode ter contribuído.”


Passo 10 — Só depois escreva a história final

E mantenha nuance.


🧠 A timeline é arqueologia

Primeiro escave.

Depois interprete.

Não invente civilização inteira porque encontrou uma moeda.

Indiana Jones aprovaria.

Ou talvez explodisse alguma coisa primeiro.

Mas essa é outra questão.


☕ Bellacosa Archaeological Debugging

Camada 1:

logs.

Camada 2:

metrics.

Camada 3:

change.

Camada 4:

dependencies.

Camada 5:

human decisions.

A causa pode estar enterrada.

Não escreva roteiro antes de terminar escavação.


🧠 Narrative Bias e observabilidade

Observabilidade ruim aumenta dependência de histórias.

Se não temos dados:

preenchemos lacunas.

Logo, logs bons não servem apenas para diagnóstico.

Servem também para combater nossos próprios vieses.


📊 Telemetry as anti-fiction

Quanto melhor telemetria:

menos espaço para narrativa especulativa.

Não elimina interpretação.

Mas limita ficção.


🧠 Missing data invites storytelling

Falha entre 08:02 e 08:12 sem métricas.

Equipe:

“Provavelmente foi X.”

Talvez.

Melhore instrumentação.


🔍 Unknown deve permanecer unknown

Não transforme:

“não sabemos”

em:

“provavelmente foi”

só para fechar relatório.

Unknown é categoria válida.


☕ O RCA mais honesto do mundo

ROOT CAUSE:
NOT CONFIRMED

MOST LIKELY CONTRIBUTOR:
X

CONFIDENCE:
60%

GAPS:
missing telemetry 08:02-08:12

Muito melhor que certeza inventada.


🧠 Organizational storytelling

Com o tempo, incidentes viram lendas.

“Aquele dia que Db2 caiu.”

Talvez Db2 nem tenha caído.

Mas história sobrevive.

Depois influencia novos incidentes.

Narrative Bias vira memória institucional.


🧠 Myth propagation

História repetida ganha certeza.

Após cinco anos:

“Todo mundo sabe que isso aconteceu por causa do Db2.”

Onde está RCA?

— Não sabemos.

Perfeito.

Mito tecnológico.


📚 Document source

Sempre mantenha:

link para post-mortem;

dados;

evidência.

Memória oral é maravilhosa para café.

Menos para causalidade.


👻 Easter Egg nº 2 — UNIT Files

Doctor abre arquivo antigo.

INCIDENT 2012
CAUSE: PROBABLY ALIENS

— Quem escreveu isso?

— Não sabemos.

— Evidência?

— Nenhuma.

— E por que continuamos dizendo que foram aliens?

— Porque é uma história melhor que DNS.

Doctor suspira.


🧠 Porque DNS quase sempre perde para alienígenas no roteiro

Mas não necessariamente em produção.


🧬 Regeneração organizacional

Uma organização madura contra Narrative Bias:

preserva timelines cruas;

separa fato de inferência;

mantém hipóteses concorrentes;

valoriza dados contraditórios;

documenta incerteza;

evita culpado único;

usa modelos sistêmicos;

faz causal graphs;

mantém links para evidência;

e deixa “não sabemos” existir.

Principalmente:

ela aprende que:

uma história é boa quando organiza os fatos sem obrigar os fatos a obedecê-la.


📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Narrative Bias é a tendência de transformar eventos em histórias coerentes e depois superestimar a verdade dessa narrativa.

Sequência temporal não prova causalidade.

Histórias reduzem desconforto da incerteza e por isso são sedutoras.

Hindsight Bias torna narrativas pós-incidente mais limpas do que a realidade original.

Confirmation Bias protege a primeira história plausível.

Representativeness escolhe padrões e Narrative Bias conecta os pontos.

Framing Effect decide quais personagens e fatos entram em destaque.

Sistemas complexos frequentemente possuem múltiplas condições contribuintes, não um único vilão.

IA também pode construir narrativas muito convincentes a partir de dados incompletos.

Fato, inferência e hipótese precisam ser explicitamente separados.

Contra-narrativas e evidências discriminantes ajudam a testar causalidade.

E principalmente:

Uma explicação não fica verdadeira porque é elegante. Fica forte quando continua de pé depois que tentamos derrubá-la com os dados.


🕰️ De volta às 08:26

A primeira história:

DEPLOY
↓
LATENCY
↓
TIMEOUT

Nosso programador adiciona:

07:54
API LATENCY STARTED

Agora timeline:

07:54 API LATENCY ↑
08:00 DEPLOY
08:07 APP LATENCY ↑
08:12 TIMEOUTS ↑

Outra informação:

82% das falhas ocorrem fora do caminho alterado.

Outra:

rollback do deploy não muda o problema.

Agora a narrativa deploy→incidente quebra.

Mas há nuance.

O código novo possuía menos tolerância a timeout e ampliava impacto em 18% das transações.

Conclusão:

API externa iniciou degradação.

Mudança recente amplificou uma parte.

Dois fatores.

Sem vilão único.

O gerente pergunta:

— Então o deploy causou ou não?

O Doctor responde:

— Essa pergunta é pequena demais.

— Como assim?

— Vocês querem um sim ou não porque isso dá uma história simples.

Pausa.

— O universo às vezes responde com “contribuiu”.

Boa resposta.


🥚 Easter Egg final

Na manhã seguinte aparece:

BELLACOSA.BIAS(NARRATIVE)

Dentro:

       IF EVENT-A < EVENT-B
           DO NOT
              MOVE 'CAUSE'
                TO RELATIONSHIP
       END-IF.

       IF STORY = 'TOO-CLEAN'
           PERFORM FIND-MISSING-FACTS
       END-IF.

       IF EVIDENCE-CONTRADICTS-STORY
           PERFORM CHANGE-STORY
           NOT CHANGE-EVIDENCE
       END-IF.

Comentário:

* A GOOD STORY IS NOT A LOG FILE.

Outro:

* CORRELATION HAS GREAT SCREEN PRESENCE.
* CAUSALITY NEEDS EVIDENCE.

Outro:

* UNKNOWN IS A VALID VALUE.

E naturalmente:

* BAD WOLF WAS A GREAT NARRATIVE.
* THAT DID NOT MAKE EVERY CLUE CAUSAL.

Nosso jovem fecha o membro.

Horas depois alguém diz:

— Temos uma explicação perfeita para o novo incidente.

Ele pergunta:

— Quantos fatos contradizem?

— Dois.

— Então não é perfeita.

— Mas é muito convincente.

Ele sorri.

— Isso me preocupa mais.

Abrem os dados.

A história original cai.

Uma explicação mais feia aparece:

duas dependências;

uma configuração antiga;

um retry excessivo.

Nada cinematográfico.

Mas tudo sustentado pelos logs.

Nenhum monólogo épico.

Nenhum culpado conveniente.

Apenas causalidade suficiente para corrigir o sistema.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica uma última frase:

Histórias ajudam humanos a lembrar. Evidências ajudam engenheiros a decidir. Nunca obrigue uma a fazer o trabalho da outra.

☕🌀

Next stop: Fundamental Attribution Error — quando um incidente complexo termina reduzido a “fulano foi descuidado”, enquanto contexto, pressão, interface, processo e arquitetura desaparecem da narrativa.

☕ Gostou deste café?
Siga o Bellacosa Mainframe e acompanhe os próximos artigos.
SEGUIR O BLOG

Sem comentários:

Enviar um comentário

De Fã para Fã. Conteúdo não oficial produzido como homenagem, comentário, análise ou paródia. Personagens, marcas e obras eventualmente mencionados pertencem aos seus respectivos titulares.
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...