☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta Confirmation Bias. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Confirmation Bias. Mostrar todas as mensagens

quinta-feira, 15 de maio de 2014

Confirmation Bias: Doctor Who, COBOL e o Dia em que a War Room Encontrou Provas Demais para a Hipótese Errada

 

Bellacosa Mainframe e o confirmation bias

☕ Um Café no Bellacosa Mainframe

Confirmation Bias: Doctor Who, COBOL e o Dia em que a War Room Encontrou Provas Demais para a Hipótese Errada

Uma viagem pela TARDIS dos incidentes para entender por que nosso cérebro adora encontrar evidências que confirmem aquilo em que já acreditamos — e por que essa habilidade, tão útil para construir narrativas coerentes, pode ser absolutamente desastrosa quando estamos tentando descobrir o que realmente aconteceu

02:47.

War Room.

Na parede:

INCIDENTE P1

APLICAÇÃO:
PAYMENTS-X

SINTOMA:
LATÊNCIA INTERMITENTE

INÍCIO:
02:21

STATUS:
INVESTIGANDO

Primeiro comentário da madrugada:

— Isso está com cara de Db2.

Nosso jovem programador COBOL já aprendeu alguma coisa nas últimas noites.

Ele olha para a frase.

Não para o Db2.

Para a frase.

Porque sabe:

a primeira hipótese pode virar âncora.

Anchoring Bias.

Mas agora acontece algo novo.

O DBA abre o monitor.

— Lock.

Gerente:

— Aí.

Outro analista:

— Tem SQL acima da média.

Gerente:

— Mais uma.

Operação:

— Buffer pool também subiu.

Gerente:

— Está ficando claro.

Nosso jovem pergunta:

— E os timeouts externos?

Silêncio.

— Começaram antes do lock.

Resposta:

— Talvez sejam consequência.

Ele continua:

— Algumas chamadas que não usam Db2 ficaram lentas.

— Pode ser coincidência.

Interessante.

Lock:

causa.

Timeout:

consequência.

SQL:

prova.

API:

coincidência.

CPU Db2:

importante.

Network latency:

ruído.

Todos os dados existem.

Ninguém está:

inventando.

Mas as evidências estão recebendo:

pesos diferentes dependendo da direção para a qual apontam.

VWORP.

VWORP.

VWORP.

A TARDIS surge atrás do quadro.

Doctor sai.

Olha para a lista:

EVIDÊNCIAS A FAVOR DE DB2

✔ LOCKS
✔ SQL ELAPSED
✔ BUFFERPOOL
✔ CPU

Depois pergunta:

— Onde estão as evidências contra?

Gerente:

— Contra?

— Sim.

— Nós estamos investigando Db2.

Doctor:

— Percebi.

— Então por que procuraríamos evidência contra?

Doctor sorri.

— Porque vocês disseram que estão investigando.

Pausa.

— Não que estão preparando a acusação.

Bem-vindo ao:



Confirmation Bias

ou:

Viés de Confirmação.


🧠 O que é Confirmation Bias?

Em linguagem simples:

é nossa tendência de procurar, perceber, interpretar e lembrar informações de maneira que favoreça aquilo em que já acreditamos.

Isso significa que o viés não atua:

num único ponto.

Ele pode atuar:

quando escolhemos onde procurar;

quando decidimos quais dados são importantes;

quando interpretamos dados ambíguos;

quando lembramos de incidentes anteriores;

quando contamos a história depois.

Ou seja:

não é apenas:

“ver só o que queremos ver.”

É mais amplo:

organizar a própria investigação de maneira que aumente a chance de encontrar aquilo que esperamos encontrar.


☕ Definição Bellacosa

Confirmation Bias é quando o investigador contrata o próprio cérebro como advogado da hipótese e depois se surpreende quando o julgamento termina em condenação.


💻 COBOL cognitivo

Imagine este maravilhoso programa:

       IF EVIDENCE-SUPPORTS-HYPOTHESIS = 'Y'
           ADD 1 TO CONFIDENCE
       END-IF.

       IF EVIDENCE-CONTRADICTS-HYPOTHESIS = 'Y'
           MOVE 'NOISE'
             TO EVIDENCE-STATUS
       END-IF.

Compila.

Provavelmente.

Mas epistemologicamente:

ABEND S0BIAS.

O correto seria algo mais parecido com:

       EVALUATE EVIDENCE-TYPE
           WHEN 'SUPPORT'
                ADD 1 TO SUPPORT-COUNT

           WHEN 'CONTRADICT'
                ADD 1 TO CONTRADICT-COUNT

           WHEN OTHER
                ADD 1 TO UNKNOWN-COUNT
       END-EVALUATE.

E depois:

pensar.


🧠 O cérebro não falsifica necessariamente os dados

Isso é importante.

Quando falamos em Confirmation Bias, algumas pessoas imaginam:

“Ah, então alguém está manipulando informação.”

Não necessariamente.

Pode ser um profissional:

honesto;

competente;

experiente.

O viés acontece:

antes.

Na atenção.

Na busca.

Na interpretação.


☕ Você não precisa apagar log

para cair no viés.

Basta:

abrir apenas o log que espera que tenha a resposta.


🧠 Exemplo clássico na War Room

Hipótese:

Db2.

Você procura:

Db2.

Encontra:

warning.

Agora:

confidence sobe.

Mas sistemas complexos têm:

milhares de warnings.

A pergunta certa não é:

“Existe warning?”

É:

“Esse warning é anormal, temporalmente relevante e causalmente consistente com o incidente?”

Isso muda:

tudo.


🎯 Pergunta Bellacosa nº 1

“Essa evidência seria interessante para mim se eu não tivesse essa hipótese?”

Excelente.


🧠 Baseline, o inimigo do drama

Imagine:

DB2 LOCKS:
25

Parece ruim?

Talvez.

Historical baseline:

NORMAL:
20–30

Então:

normal.

Agora outro:

API LATENCY:
NORMAL 150 ms
INCIDENT 2400 ms

Muito mais relevante.

Mas se nossa hipótese é:

Db2,

podemos passar:

vinte minutos

discutindo 25 locks

e três segundos:

na API.


☕ Um número grande não é automaticamente anormal

E um número pequeno não é automaticamente irrelevante.

Contexto.

Sempre.


🧠 Anchoring abre a porta

Lembra?

Primeiro alguém diz:

“Tem cara de Db2.”

Anchoring Bias.

Agora Confirmation Bias entra:

“Vamos procurar sinais de Db2.”

Uma relação quase:

pai e filho.


🌀 Pipeline cognitivo

PRIMEIRO PALPITE
      ↓
ANCHORING
      ↓
BUSCA SELETIVA
      ↓
CONFIRMATION BIAS
      ↓
MAIOR CONFIANÇA

Mas ainda não acabou.


🧠 Streetlight Effect ajuda a confirmar

Temos:

ótimos logs Db2.

Ótimo dashboard Db2.

DBA presente.

Então:

procuramos Db2.

Quanto mais procuramos:

mais encontramos.

Isso não significa:

Db2 mais culpado.

Significa:

Db2 mais observado.

Streetlight Effect.


☕ Se você apontar 20 lanternas para um componente

e nenhuma para outro,

adivinhe:

qual vai produzir mais evidência.


🧠 Search Satisfaction entra depois

Encontramos:

um lock interessante.

Pronto.

Achei!

Search Satisfaction.

Agora:

a busca perde força.


🧠 Premature Closure chega

Lock:

real.

Latency:

real.

Então:

“Db2 é root cause.”

Premature Closure.


🧠 Diagnosis Momentum termina o serviço

Ticket:

POSSIBLE DB2

vira:

DB2 ISSUE

Depois:

ROOT CAUSE DB2

Diagnosis Momentum.

Veja o arco:

ANCHOR
  ↓
CONFIRM
  ↓
FIND
  ↓
STOP
  ↓
CLOSE
  ↓
PROPAGATE

É praticamente:

pipeline CI/CD de erro cognitivo.


👻 Easter Egg nº 1 — Doctor e o Dalek Promotor

Dalek:

— DB2 IS GUILTY.

Doctor:

— Por quê?

— LOCK FOUND.

— Existe alguma evidência de API failure?

— YES.

— Então?

— IRRELEVANT.

— Por quê?

— IT DOES NOT SUPPORT DB2 THEORY.

Doctor:

— Você não é investigador.

Dalek:

— CORRECT.

— O que é?

— PROSECUTION.

Doctor:

— Finalmente honestidade.


🧠 Confirmation Bias não acontece apenas na busca

Ele atua em:

1. Busca

Procuramos:

o que confirma.

2. Atenção

Notamos:

o que confirma.

3. Interpretação

Ambiguidade vira:

suporte.

4. Memória

Lembramos:

de casos favoráveis.

5. Comunicação

Contamos:

história favorável.

Uma criatura:

multifuncional.


🧠 Memória seletiva

Alguém diz:

— Toda vez que Db2 sobe CPU, temos incidente.

Será?

Talvez ele lembre:

dos três incidentes.

Mas não dos:

200 dias

em que CPU subiu

e nada aconteceu.

Base Rate Neglect.

Confirmation Bias.


🎯 Pergunta Bellacosa nº 2

“Quantas vezes esse mesmo sinal apareceu sem o incidente?”

Uma pergunta brutalmente importante.


🧠 O normal que não lembramos

Incidentes:

memoráveis.

Operação saudável:

esquecível.

Então:

correlações parecem:

fortes.


☕ Ninguém abre War Room para:

“mais uma terça-feira onde tudo funcionou.”

Isso distorce memória.


🧠 Confirmation Bias e Availability Heuristic

Você se lembra:

do incidente Db2.

Porque:

dramático.

Disponível na memória.

Então:

essa hipótese surge rápido.

Depois:

Confirmation Bias procura provas.


🧠 Recency Bias

Se aconteceu:

ontem,

pior ainda.

“Deve ser de novo.”


🧠 Representativeness

“Tem o mesmo cheiro.”

Parecido:

não significa:

igual.


🎯 Pergunta Bellacosa nº 3

“Quais diferenças entre este caso e o caso anterior estamos deixando de considerar?”


🧠 A arte de procurar contra você mesmo

Esse talvez seja:

o principal antídoto.

Se hipótese:

Db2,

não pergunte apenas:

“Que evidência prova Db2?”

Pergunte:

“Que evidência provaria que Db2 NÃO é o gatilho?”

Essa mudança:

é enorme.


🧠 Falsification mindset

Imagine:

HYPOTHESIS:
DB2 causes payment latency.

Teste:

Clientes que não tocam Db2 também estão lentos?

Se sim:

problema.

Outro:

Latency begins before Db2 anomaly?

Se sim:

problema.

Outro:

Remove Db2 contention and latency remains?

Problema.


☕ Hipótese boa precisa:

correr risco de morrer.

Caso contrário:

é decoração.


🧠 House MD entra

Equipe:

— Achamos pneumonia.

House:

— O que contradiz?

— Nada.

— Procuraram?

— Não.

— Então vocês não têm “nada que contradiz”.

Pausa.

— Vocês têm “nada que procuramos para contradizer”.

Essa diferença é:

fantástica.


🎯 Pergunta Bellacosa nº 4

“Ausência de contradição ou ausência de busca por contradição?”


🧠 Confirmation Bias em debugging COBOL

Programa:

resultado incorreto.

Programador pensa:

“é o COMPUTE.”

Então abre:

COMPUTE WS-TOTAL =
        WS-PRICE * WS-QUANTITY.

Lê.

Relê.

Encontra:

arredondamento estranho.

Corrige.

Teste melhora.

Pronto?

Talvez não.

O campo:

WS-PRICE

já estava:

errado.

Então:

o problema no COMPUTE era:

real?

Talvez.

Mas talvez:

secundário.


🧠 Trace backwards

Pergunta senior:

“Onde aparece o primeiro valor errado?”

Não:

onde encontramos:

um cálculo suspeito.


☕ O primeiro lugar onde percebemos o erro

não é necessariamente:

o primeiro lugar onde ele existe.


🧠 Exemplo de lineage

INPUT
  OK
   ↓
COPYBOOK MAPPING
  WRONG
   ↓
MOVE
  WRONG
   ↓
COMPUTE
  WRONG
   ↓
REPORT
  WRONG

Se você ama a hipótese:

COMPUTE,

talvez fique:

no quarto andar.

Causa:

segundo.


🎯 Pergunta Bellacosa nº 5

“Estou investigando a origem do valor ou apenas o ponto onde ele finalmente ficou visível?”


🧠 Confirmation Bias e testes

Desenvolvedor escreve:

testes.

Se quer:

confirmar código,

faz:

happy path.

Tudo passa.

Excelente.

Mas:

boundary?

negative?

invalid?

concurrency?


☕ Testar só o que espera funcionar

é quase:

pedir elogio ao compilador.


🧠 Mutation Testing como filosofia anti-confirmação

Interessante.

Pergunta:

“Se o código estivesse errado, meus testes perceberiam?”

Isso é mais poderoso do que:

“meu código passa?”

Porque:

passar não garante:

qualidade.


🧠 Negative Testing

Ideal:

tente destruir.


🎯 Pergunta Bellacosa nº 6

“Qual teste eu escreveria se estivesse tentando provar que minha implementação está errada?”


🧠 Confirmation Bias em code review

Autor:

“simple change.”

Reviewer:

já ancorado.

Procura:

pequeno ajuste.

Talvez:

copybook global.

Danger.


☕ “Mudança simples”

é um dos comentários mais perigosos:

do software corporativo.


🧠 Neutral review

Better:

“change modifies X.”

Then:

review.

Avoid:

framing.


🧠 Confirmation Bias em RCA

Postmortem começa:

— O deploy causou.

Agora:

todo mundo procura:

deploy.

Mas talvez:

deploy coincidiu.

Post hoc.


🎯 Pergunta Bellacosa nº 7

“Estamos investigando o evento porque ocorreu antes ou porque demonstramos mecanismo causal?”


🧠 Timeline limpa

Uma ferramenta maravilhosa:

escreva:

02:51 API latency
02:52 retries
02:55 queue
03:01 DB2 lock

Sem:

“cause”.

Sem:

“because”.

Só fatos.

Depois:

analise.

Isso reduz:

narrativa prematura.


☕ Timeline sem opinião

é:

testemunha interessante.


🧠 Confirmation Bias e Narrative Bias

Depois que temos hipótese,

montamos:

história.

O cérebro ama:

coerência.

Então fatos ambíguos:

ganham significado.

Narrative Bias.


🧠 Exemplo

DB2 warning
+
customer latency
+
old Db2 incident

Story:

Db2 again.

Mas:

talvez sejam:

três fatos não causais.


🎯 Pergunta Bellacosa nº 8

“Essa história explica os fatos ou os fatos foram escolhidos porque deixam a história bonita?”


🧠 Confirmation Bias e Metric Fixation

Leadership acredita:

service healthy.

Dashboard:

green.

Evidence:

green.

Customer complaints:

“anecdotal.”

Observe.

A crença:

“dashboard = reality”

é confirmada:

pelos próprios dashboards.

Circular.


☕ Se seu termômetro mede só a sala de reunião

não use:

para provar que cozinha não está pegando fogo.


🧠 McNamara Fallacy

Hard-to-measure:

ignored.

Quantitative evidence favorable:

dominates.


🎯 Pergunta Bellacosa nº 9

“Estamos descartando evidência porque é fraca ou porque é qualitativa?”


🧠 Confirmation Bias e Goodhart

Manager believes:

team improved.

KPI:

tickets closed +40%.

Great.

But:

reopens +80%.

Ignore.

Why?

Contradiz:

belief.


🧠 Counter-metric

Always ask:

what metric would:

tell opposite story?


🎯 Pergunta Bellacosa nº 10

“Qual indicador eu não gostaria de mostrar se minha narrativa estivesse errada?”

Boa.


🧠 Confirmation Bias e Goal Gradient

Projeto:

97%.

Queremos lançar.

Pass test:

“ótimo.”

Fail test:

“edge case.”

Percebe?

O mesmo evidence quality:

não.

Goal Gradient creates:

desired outcome.

Confirmation Bias:

selects supportive facts.


☕ “Edge case”

às vezes significa:

“evidência que estraga nosso cronograma.”


🧠 Confirmation Bias e Sunk Cost

Investimos:

18 meses.

Queremos:

continuar.

Então:

market signal positive:

important.

Negative:

temporary.

Sunk Cost + Confirmation.


🧠 Escalation of Commitment

Cada novo investimento:

aumenta desejo:

de estar certo.

Então:

evidência contrária:

fica psicologicamente cara.


🎯 Pergunta Bellacosa nº 11

“A evidência mudou ou apenas ficou mais difícil admitir que estamos errados?”


🧠 Confirmation Bias e Cultural Debt

Uma decisão antiga:

“centralizar tudo.”

Funcionou.

Hoje:

custos.

Mas organização lembra:

sucessos.

Fracassos alternativos:

superestimados.

Cultura confirma:

decisão.

Cultural Debt permanece.


☕ Uma cultura pode:

selecionar memória.


🧠 Confirmation Bias e arquitetura

Time cloud:

procura:

cloud success stories.

Time mainframe:

procura:

mainframe reliability stories.

Ambos:

podem estar certos.

Ambos:

podem estar incompletos.


🎯 Pergunta Bellacosa nº 12

“Estou comparando alternativas ou reunindo munição para a alternativa que já prefiro?”


🧠 Confirmation Bias e pessoas

Manager acha:

analista fraco.

Agora:

erros:

memorizados.

Acertos:

esperados.

Label:

strengthens.

This is dangerous.

Fundamental Attribution.

Halo/Horn.


☕ A pessoa vira:

query filter.


🧠 Confirmation Bias e AI

Agora:

zona moderna.

Prompt:

“Explique por que Db2 provavelmente causou o incidente.”

A IA:

faz exatamente isso.

E talvez faça:

muito bem.

O problema:

não é IA.

É:

pergunta.


🤖 LLMs são excelentes em construir argumentos plausíveis

Portanto:

não use apenas como:

advogado.

Use como:

adversário.


🧠 Prompt melhor

Avalie as hipóteses:
- Db2
- API externa
- MQ
- rede

Para cada uma, liste:
- evidências a favor
- evidências contra
- fatos não explicados
- teste que poderia refutá-la

Agora:

muito mais interessante.


🎯 Pergunta Bellacosa nº 13

“Estou pedindo análise ou justificativa?”


🧠 Confirmation Bias e RAG

Search query:

DB2 incident payment latency

Results:

Db2.

Surprise.

Se busca:

payment latency retries queue growth

espaço:

mais aberto.


☕ Query contém:

viés.

Banco de dados não:

reclama.


🧠 Confirmation Bias e AIOps

Classifier:

Db2 82%.

Operator:

opens Db2.

Finds:

warnings.

Confidence:

increases.

Mas:

machine and human

may use:

same source.

This is not:

independent confirmation.


🎯 Pergunta Bellacosa nº 14

“Essas confirmações são independentes ou todas derivam do mesmo dado?”

Importantíssima.


🧠 Três dashboards, uma fonte

RMF → dashboard A.

RMF → dashboard B.

RMF → AI model.

Three outputs.

One sensor.

Don't count:


COUNT(DASHBOARDS)

não é:

COUNT(INDEPENDENT_SOURCES).


🧠 Confirmation Bias e histórico

Historical RCA says:

Db2.

Current incident resembles.

Search old tickets tagged Db2.

Finds:

Db2.

But old labels may:

already be biased.

Circular confirmation.


🎯 Pergunta Bellacosa nº 15

“O histórico que usamos para confirmar esta hipótese foi classificado usando o mesmo raciocínio?”


🧠 Feedback loop em IA

OLD RCA LABEL
↓
TRAINING DATA
↓
MODEL PREDICTS SAME LABEL
↓
HUMAN ACCEPTS
↓
NEW RCA LABEL
↓
MORE TRAINING DATA

Isso é:

Confirmation Bias industrializado.


☕ Um erro histórico pode:

ganhar GPU.


🧠 Confirmation Bias e segurança

Analista acredita:

APT.

Procura:

PowerShell.

Encontra.

But PowerShell:

common.

Need:

base rate.

Context.


🧠 Base rate

Se signal:

common in healthy population,

weak evidence.


🎯 Pergunta Bellacosa nº 16

“Quão raro esse sinal realmente é?”


🧠 Security example

Alert:

failed logins.

Could mean:

attack.

Could mean:

password expired.

Need:

alternative hypotheses.


🧠 Confirmation Bias e fraude

Fraud analyst:

transaction suspicious.

Then every unusual action:

supports fraud.

Maybe:

traveling customer.

Again.


🧠 The hypothesis matrix

One of best tools.

EVIDENCE           DB2   API   MQ

Lock               +     0     0
Early timeout      -     +     0
Queue growth       0     +     +
Non-DB2 affected   -     +     0

Now:

explicit comparison.


☕ Uma hipótese sozinha

vence sempre.

Dê:

concorrentes.


🧠 Differential diagnosis

Medicine understands.

IT should:

steal shamelessly.


🎯 Pergunta Bellacosa nº 17

“Quais outras causas explicariam esses mesmos sintomas?”


🧠 Confirmation Bias e stop criteria

If we keep searching until:

find confirmation,

we will:

find.

Need:

predefined criteria.


🧠 Before test

Write:

If H1 true:

expect X.

If false:

expect Y.

Then:

test.


☕ Predeclare expected result

before:

seeing result.

Reduces:

rationalization.


🎯 Pergunta Bellacosa nº 18

“Antes do teste, registramos o que nos faria abandonar a hipótese?”


🧠 Interpretation elasticity

Danger:

whatever happens:

fits.

CPU up?

Db2.

CPU normal?

Db2 waiting.

Network normal?

Db2.

Network bad?

Db2 causing retries.

If everything:

supports,

nothing tests.


☕ Hipótese de borracha

esticando para caber:

em qualquer evidência.


🧠 Confirmation Bias e statistical cherry-picking

No need:

academic.

Simple:

choose:

time window;

metric;

customer segment;

baseline

that supports.

Sometimes:

unconscious.


🎯 Pergunta Bellacosa nº 19

“Por que escolhemos exatamente esse período, essa métrica e essa amostra?”


🧠 Confirmation Bias e visualization

Y-axis zoomed.

Spike:

dramatic.

Full scale:

small.

Charts can:

persuade.

Not lie exactly.

Frame.


☕ Gráfico também:

conta histórias.


🧠 Confirmation Bias e postmortem

After outcome known:

look back.

Pick events:

support final cause.

Hindsight Bias.

Narrative Bias.

Need:

preserve decision timeline.


🧠 What we believed when

Important:

02:30 H1 Db2 40%
02:40 API evidence found
02:45 H1 Db2 20%

Then:

learning.


🎯 Pergunta Bellacosa nº 20

“Estamos reconstruindo o raciocínio real ou escrevendo uma história elegante depois de saber o final?”


🧠 Confirmation Bias e Outcome Bias

Next chapter perhaps.

If risky change works:

we say:

“see? safe.”

One success:

confirms.

If fails:

opponents:

“see? dangerous.”

Outcome Bias + Confirmation.


☕ Um único resultado

pode alimentar:

duas religiões diferentes.


🧠 Confirmation Bias e Self-Serving

Success:

skill.

Failure:

context.

Then:

memory selects.


🧠 Confirmation Bias e Risk Compensation

Control introduced.

No incidents:

confirmation.

Team takes more risk.

Maybe risk hidden.


🎯 Pergunta Bellacosa nº 21

“Estamos confirmando que o controle funciona ou apenas observando que ainda não falhou?”


🧠 Confirmation Bias e backup

Backup:

green 365 days.

Belief:

safe.

Restore?

Never.

Logs:

confirm backup.

But objective:

recover.

Classic.


☕ Backup report confirma:

backup.

Não:

restore.


🧠 Confirmation Bias e DR

Tabletop exactly follows:

runbook.

Pass.

Confirms.

But real disaster:

different.

Need:

variation.

Challenge assumptions.


🎯 Pergunta Bellacosa nº 22

“Nosso teste foi construído para validar o plano ou para desafiar o plano?”


🧠 Confirmation Bias e training

Employee believes:

knows COBOL.

Course score:

95%.

Confirms.

Production challenge:

different.

Need:

labs.


🧠 Certification as evidence

Useful.

Not complete.

Metric Fixation.


☕ Badge diz:

“passou.”

Não:

“já viu todos os gremlins.”


🧠 Confirmation Bias em benchmark de IA

Model:

great benchmark.

We believe:

excellent.

Ignore:

real domain failures.

Again:

proxy.


🎯 Pergunta Bellacosa nº 23

“Estamos escolhendo avaliações que favorecem o modelo que já queríamos selecionar?”


🧠 Confirmation Bias e leadership

Leader says:

Db2.

Team wants:

please.

Evidence:

aligned.

Authority Bias.

Potential:

groupthink.


🧠 Speak-last rule

Leader:

listen first.

Then:

opinion.

Great.


☕ Quem tem mais autoridade

deveria ter:

mais cuidado

com a primeira frase.


🎯 Pergunta Bellacosa nº 24

“A equipe concorda porque viu a mesma evidência ou porque ouviu a mesma autoridade?”


🧠 Confirmation Bias e psychological safety

If challenging senior:

costly,

contra-evidence:

stays silent.

Now:

confirmation appears:

stronger.

Not because:

no contradiction.

Because:

contradiction suppressed.


☕ Silêncio não é:

consenso.

Às vezes:

é organograma.


🧠 Confirmation Bias e vendor

Client believes:

vendor fault.

Vendor believes:

client.

Both:

collect evidence.

Need:

shared timeline.

Independent instrumentation.


🎯 Pergunta Bellacosa nº 25

“Quem se beneficia se esta hipótese for aceita?”

Not automatic guilt.

But:

context.


🧠 Confirmation Bias e Principal-Agent

Incentives:

shape search.

Important.


🧠 Confirmation Bias e Campbell

If metric rewards:

certain root category,

pressure.


🧠 Confirmation Bias e Goodhart

If KPI:

low change failure,

teams classify:

incidents unrelated.

Now:

data confirms:

good changes.

Circular.


☕ Classificação também pode:

ser gaming.


🧠 Confirmation Bias em produção real

Imagine:

change 23:00.

Incident 23:15.

Everyone:

change.

Rollback.

Incident stays.

Now:

what?

If attached:

change,

may say rollback incomplete.

Maybe:

unrelated.

Need:

reopen.


🎯 Pergunta Bellacosa nº 26

“Qual evidência faria aceitarmos coincidência?”


🧠 Correlation vs causation

Still.

Important.


🧠 Confirmation Bias e code comments

Comment:

* FIX FOR DB2 ISSUE

Future developer:

assumes.

Maybe:

not.

Comments can:

anchor + confirm.


☕ Comentário velho

é:

opinião com fossilização.


🧠 Git history as evidence

Check:

why change?

Ticket?

Test?

Useful.


🧠 Confirmation Bias e documentation

Documentation may:

encode old theory.

Question.


🎯 Pergunta Bellacosa nº 27

“Esse documento descreve comportamento observado ou uma explicação histórica nunca revalidada?”


🧠 Confirmation Bias e Cultural Debt novamente

“Nunca altere esse módulo.”

Why?

Old outage.

Maybe:

cause wrong.

Fear:

confirmed by every avoided change.

No new evidence because:

nobody tests.

Self-sealing belief.


☕ Não mexemos porque:

é perigoso.

Como sabemos?

Porque:

nunca mexemos.

Maravilhoso circuito lógico.


🧠 Self-sealing beliefs

A belief structured so:

lack of challenge

becomes evidence.

Danger.


🎯 Pergunta Bellacosa nº 28

“Nossa crença impede justamente o experimento que poderia testá-la?”


🧠 Confirmation Bias e observability design

We instrument:

what we think important.

Then data says:

those things matter.

Why?

Because:

that's what measured.

McNamara.

Streetlight.


☕ Telemetria também:

herda hipótese.


🧠 Confirmation Bias e incident dashboards

If dashboard built:

Db2-centric,

incident appears:

Db2-centric.

Design:

matters.


🧠 End-to-end tracing

Better:

follow transaction.

Not:

component belief.


🎯 Pergunta Bellacosa nº 29

“Nossa observabilidade foi desenhada para o sistema real ou para a arquitetura mental que tínhamos quando o dashboard foi criado?”


🧠 Confirmation Bias e AI agents

Agent hypothesis:

Db2.

Then tool calls:

Db2.

Returns:

Db2 info.

Agent confidence:

rises.

This is:

tool-use feedback loop.

Need:

exploration policy.


🤖 Agent anti-confirmation

Require:

at least one disconfirming tool query.

At least:

one alternative hypothesis.

Very good.


🧠 Human-in-the-loop

Ask human:

what unexplained?

Useful.


🎯 Pergunta Bellacosa nº 30

“O agente possui um mecanismo para procurar deliberadamente evidência contra sua própria hipótese?”


🧠 Confirmation Bias e search engines

Search:

“why mainframes are obsolete”

Find:

arguments.

Search:

“why mainframes are essential”

Find:

arguments.

Search query:

decides:

universe.


☕ Internet é grande o suficiente

para confirmar:

quase qualquer coisa.


🧠 Better research query

“What are strengths, weaknesses and current use cases of mainframes?”

Neutraler.


🧠 Confirmation Bias e news

Same.

But let's stay:

mainframe.


🧠 Confirmation Bias e DBA vs app team

DBA:

“app.”

App:

“DB.”

Each:

protects domain.

Self-serving.

Need:

cross-team.


🎯 Pergunta Bellacosa nº 31

“Estamos procurando causa ou procurando inocência da nossa própria camada?”


🧠 Confirmation Bias e RCA blame

A person:

mistake.

Search:

their past mistakes.

Now:

“pattern.”

Maybe:

not.

Fundamental Attribution.


🧠 Blameless approach

Focus:

system.


☕ Você não precisa absolver pessoa

para:

entender contexto.


🧠 Confirmation Bias e hiring

Candidate with famous company.

We expect:

good.

Interpret answers:

favorably.

Halo.

Opposite too.

Not technical incident, but same mechanism.


🧠 Confirmation Bias e estimates

We believe:

project simple.

Then:

count only known tasks.

Unknowns:

ignored.

Planning fallacy.


🎯 Pergunta Bellacosa nº 32

“Nossa estimativa inclui aquilo que pode provar que o projeto é mais complexo do que gostaríamos?”


🧠 Confirmation Bias e No-Go

Team wants launch.

Evidence:

pass.

Fail:

exception.

Need:

predefined no-go.

This is:

cognitive forcing.


🧠 Precommitment

Define:

before:

emotion.


☕ Regra escrita ontem

pode proteger:

do cérebro de hoje.


🧠 Confirmation Bias e checklists

Checklist ensures:

look at:

contrary dimensions.

But beware:

box-ticking.

Need:

meaning.


🧠 Two-column checklist

SUPPORTS | CONTRADICTS

Simple.


🎯 Pergunta Bellacosa nº 33

“Qual é nossa melhor evidência contra a hipótese principal?”

If answer:

none,

ask:

why.


🧠 Confirmation Bias e confidence calibration

Use:

percentage maybe.

But avoid fake precision.

Maybe:

Low/Medium/High.

Update:

when new evidence.


🧠 Confidence should move both ways

Not only:

up.


☕ Hipótese também precisa:

saber perder.


🧠 Confirmation Bias e decision hygiene

A few excellent habits:

  • facts first

  • hypotheses later

  • independent opinions

  • contrary evidence

  • source provenance

  • baseline

  • timeline

  • re-estimation


🧠 Bellacosa Anti-Confirmation Protocol

Passo 1

Declare:

what you believe.

H1: Db2.

Passo 2

Declare:

why.


Passo 3

List:

at least two alternatives.


Passo 4

Write:

what would falsify H1.


Passo 5

Search:

contrary evidence first.


Passo 6

Compare:

baseline.


Passo 7

Check:

independent sources.


Passo 8

Ask:

someone unanchored.


Passo 9

Update:

confidence.


Passo 10

Reward:

being disproved early.


☕ Regra central

Ser refutado às 03:10 é muito mais barato que ser refutado às 07:30 por produção.


📋 Checklist Bellacosa anti-Confirmation Bias

[ ] Qual é nossa hipótese?

[ ] Que evidência a favor existe?

[ ] Que evidência contra existe?

[ ] Procuramos ativamente contradições?

[ ] Temos hipóteses concorrentes?

[ ] A evidência é independente?

[ ] Comparámos com baseline?

[ ] A timeline é consistente?

[ ] Há fatos não explicados?

[ ] O título do ticket nos ancorou?

[ ] O senior falou primeiro?

[ ] A IA recebeu a hipótese como fato?

[ ] O fix testou causalidade?

[ ] Existe incentivo para essa causa ser verdadeira?

[ ] Sabemos o que nos faria mudar de ideia?

🧠 Bellacosa Evidence Card

HYPOTHESIS:
_____________________________

SUPPORT:
_____________________________

CONTRADICTIONS:
_____________________________

ALTERNATIVES:
_____________________________

BASELINE:
_____________________________

INDEPENDENT SOURCES:
_____________________________

WOULD FALSIFY:
_____________________________

CONFIDENCE:
LOW / MEDIUM / HIGH

👻 Easter Egg nº 2 — o SQL do viés

Nosso jovem encontra:

SELECT *
  FROM EVIDENCE
 WHERE SUPPORTS_DB2 = 'Y';

Doctor:

— Problema?

— Sim.

Ele altera:

SELECT *
  FROM EVIDENCE
 ORDER BY EVENT_TIMESTAMP;

Doctor sorri.

— Agora?

Nosso jovem:

— Agora deixamos os dados falar antes da hipótese.

— Excelente.


🧠 O Teste do Inimigo

Imagine que:

você precisa provar:

sua própria hipótese errada.

Que evidência usaria?

Esse exercício:

é fantástico.


🧠 O Teste do Outro Time

Dê:

facts only.

Pergunte:

root hypothesis.

Compare.


🧠 O Teste do Dado Feio

Qual evidência:

mais atrapalha sua história?

Comece:

por ela.


🎯 Pergunta Bellacosa nº 34

“Qual fato eu gostaria secretamente que não existisse?”

Essa pergunta:

vale ouro.


🧠 Confirmation Bias e curiosity

Curiosidade genuína:

antídoto.

Instead:

“What confirms?”

Ask:

“What surprises?”


☕ O dado que surpreende

talvez seja:

o mais valioso.


🧠 Surprise is information

If model predicted:

A.

Observed:

B.

Don't rationalize.

Update:

model.


🧠 Engineer maturity

Junior:

tries to prove:

first guess.

Senior:

tries to break:

first guess.

Master:

enjoys when evidence:

forces new model.


☕ Porque:

estar certo

é bom.

Aprender algo novo:

melhor.


🕰️ De volta à War Room

03:44.

Nosso jovem escreve:

H1 DB2
H2 API
H3 MQ
H4 NETWORK

Then:

SUPPORT / CONTRADICT

DBA:

— Lock real.

Support Db2.

App:

— Timeout began 9 minutes earlier.

Contradict Db2 trigger.

Network:

— normal.

Contradict network.

MQ:

— queue increase after retries.

Supports API/retry.

Now:

investigation changes.


🔧 Resultado

External API latency:

trigger.

Retry mechanism:

amplifier.

Db2 lock:

secondary consequence.

All evidence:

real.

But meaning:

different.


☕ Essa é a parte importante

Confirmation Bias não necessariamente cria dados falsos. Ele pode criar interpretação falsa usando dados completamente verdadeiros.

Essa frase merece:

placa.


🧠 Data versus meaning

Logs:

fact.

Causal role:

interpretation.

Separate.


🎯 Pergunta Bellacosa nº 35

“O que é dado e o que é inferência nesta conclusão?”


👻 Easter Egg final — BELLACOSA.BIAS

No member:

BELLACOSA.BIAS(CONFIRMATION)

Código:

       IF HYPOTHESIS-EXISTS = 'Y'
           PERFORM SEARCH-SUPPORT
           PERFORM SEARCH-CONTRADICTION
           PERFORM GENERATE-ALTERNATIVES
       END-IF.

       IF CONTRADICTING-EVIDENCE > ZERO
           DISPLAY
           'DO NOT MOVE TO NOISE WITHOUT REVIEW'
       END-IF.

       IF TEAM-SAYS 'ISSO CONFIRMA'
           PERFORM ASK-WHAT-WOULD-REFUTE
       END-IF.

       IF ONLY-SUPPORT-WAS-SEARCHED = 'Y'
           MOVE 'BIASED'
             TO INVESTIGATION-STATUS
       END-IF.

Comentários:

* DO NOT ASK ONLY:
* WHY AM I RIGHT?

Outro:

* ASK:
* HOW COULD I BE WRONG?

Outro:

* TRUE DATA
* CAN SUPPORT
* WRONG STORIES.

Outro:

* THREE DASHBOARDS
* FED BY ONE SENSOR
* ARE STILL
* ONE SOURCE.

E naturalmente:

* DALEK THEORY:
* THE DOCTOR IS WRONG.
*
* DATASET:
* ONLY EVIDENCE
* SELECTED BY DALEKS.

Nosso jovem fecha:

o member.

Ri.


🧬 Regeneração organizacional

Uma organização madura não:

tenta eliminar Confirmation Bias.

Impossível.

Ela cria:

sistemas que dificultam:

sua vitória.

Facts first.

Independent review.

Alternative hypotheses.

Contradiction fields.

Base rates.

Timelines.

Fresh eyes.

Predefined criteria.

Blameless challenge.

Ela permite que alguém diga:

“Nossa hipótese favorita está errada.”

Sem:

drama.

Sem:

perda de status.

Sem:

“quem errou?”

Porque entende:

mudar de hipótese diante de evidência nova não é falha da investigação. É exatamente o comportamento que uma boa investigação deveria produzir.


📓 Diário do Doctor

Se guardar algumas coisas desta viagem:

Confirmation Bias é a tendência de procurar, lembrar e interpretar evidências de maneira consistente com crenças já existentes.

Ele pode afetar busca, atenção, memória, interpretação e comunicação.

Anchoring frequentemente cria a primeira hipótese que Confirmation Bias passa a proteger.

Recency Bias, Availability e Representativeness ajudam certas hipóteses a parecerem mais naturais.

Streetlight Effect determina onde procuramos.

Search Satisfaction faz um achado favorável reduzir a vontade de continuar.

Premature Closure transforma hipótese plausível em conclusão cedo demais.

Diagnosis Momentum distribui a conclusão pela organização.

Narrative Bias monta uma história coerente usando os findings favoráveis.

Metric Fixation pode fazer indicadores favoráveis parecerem mais confiáveis do que evidências qualitativas contrárias.

McNamara Fallacy pode excluir justamente aquilo que não é fácil de medir.

Goodhart e Campbell podem criar incentivos para selecionar classificações ou dados convenientes.

Sunk Cost e Escalation of Commitment tornam evidências contrárias psicologicamente caras.

A IA pode ser ancorada e induzida a confirmar a hipótese contida no prompt.

Múltiplas evidências derivadas da mesma fonte não são independentes.

Um finding verdadeiro pode sustentar uma interpretação causal errada.

E principalmente:

uma boa investigação não mede sua qualidade pela quantidade de evidências que conseguiu reunir a favor da hipótese; mede pela capacidade dessa hipótese de sobreviver às melhores evidências encontradas contra ela.


🥚 Último Easter Egg

Antes de entrar na TARDIS, o Doctor pergunta:

— Você quer estar certo?

Nosso jovem responde:

— Claro.

Doctor:

— Péssima prioridade.

— Como assim?

— Queira descobrir o que aconteceu.

— E se eu estiver errado?

Doctor abre a porta.

— Melhor ainda.

— Melhor?

“Significa que a realidade acabou de lhe ensinar algo que sua hipótese ainda não sabia.”

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro fica:

“Não procure provas de que está certo. Procure boas oportunidades de descobrir que está errado.”

E talvez essa seja a essência do Confirmation Bias no Bellacosa Mainframe:

a investigação começa com uma hipótese, mas só se torna engenharia quando essa hipótese recebe permissão real para morrer.

☕🌀

Próxima parada: Outcome Bias — quando uma decisão ruim termina bem, todo mundo passa a chamá-la de genial; e quando uma decisão boa termina mal por azar, todos juram que ela sempre foi irresponsável.

sábado, 3 de abril de 2010

Confirmation Bias: Doctor Who, COBOL e o Dia em que Todas as Evidências Começaram a Concordar Demais

Bellacosa Mainframe e o confirmation bias

☕ Um Café no Bellacosa Mainframe

Confirmation Bias: Doctor Who, COBOL e o Dia em que Todas as Evidências Começaram a Concordar Demais

Uma viagem pela TARDIS dos incidentes para entender por que nossa primeira teoria costuma parecer melhor quanto mais procuramos provas para ela

09:12.

Produção instável.

Dois usuários reclamando.

Um job terminou com RC=04.

A fila do CICS cresceu.

CPU normal.

Db2 aparentemente normal.

Rede aparentemente normal.

O programador COBOL olha para a tela e diz:

— Aposto que é banco.

O DBA escuta e responde:

— Não é banco.

O analista de rede aparece:

— Parece aplicação.

O time de aplicação responde:

— Rede.

O operador, experiente, observa tudo em silêncio e sentencia:

— Sempre é aquela interface.

E nesse exato momento...

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se no corredor.

O Doctor sai.

Olha para as telas.

Escuta cinco minutos de discussão.

E pergunta:

— Quem aqui está tentando descobrir a causa?

Todos levantam a mão.

Ele sorri.

— Excelente.

Pausa.

— E quem está tentando provar que já sabe qual é a causa?

Silêncio.

O Doctor olha para nosso programador COBOL iniciante.

— Muito bem. Hoje encontramos algo realmente perigoso.

Aponta para todos.

— Vocês mesmos.


Bem-vindo ao Confirmation Bias.

Ou:

Viés de Confirmação

O fenômeno pelo qual tendemos a procurar, interpretar, lembrar e valorizar informações que confirmem aquilo que já acreditamos — enquanto evidências contrárias recebem um tratamento muito menos entusiasmado.


🌀 A TARDIS já passou por três monstros

Antes de chegarmos aqui, nossa jornada passou por três ideias fundamentais.

Primeiro, o Swiss Cheese Model.

Aprendemos que sistemas complexos possuem várias barreiras, todas imperfeitas.

Depois veio a Normalization of Deviance.

Descobrimos que um desvio repetido sem consequência pode se transformar em normalidade.

No terceiro episódio conhecemos o Hindsight Bias.

Depois que o incidente acontece, tudo parece mais previsível do que realmente era.

Agora avançamos para o momento mais perigoso da investigação:

o instante em que alguém formula a primeira hipótese.

Porque formular hipótese é necessário.

Apaixonar-se por ela é opcional.


🧠 O que é Confirmation Bias?

Confirmation Bias é a tendência de favorecer informações que apoiem crenças, expectativas ou hipóteses já existentes.

Na prática:

EU ACHO QUE É REDE
        ↓
PROCuro sinais de rede
        ↓
ENCONTRO um timeout
        ↓
“EU SABIA”

O problema é tudo aquilo que não entra no desenho:

DB2 response time alterado
queue depth subindo
storage pressionado
erro funcional novo
mudança recente

Essas informações podem ser ignoradas, reinterpretadas ou tratadas como “ruído”.

Não necessariamente por má-fé.

Na maioria das vezes, nosso cérebro está apenas tentando criar coerência.


🔎 O cérebro não gosta de caos

Imagine uma War Room real.

Há:

  • dez telas;

  • várias equipes;

  • dezenas de métricas;

  • mensagens no Teams;

  • emails;

  • operadores;

  • usuários;

  • pressão;

  • gerente perguntando previsão.

O cérebro humano quer reduzir essa complexidade.

Então aparece uma hipótese:

“É rede.”

Pronto.

Agora o caos ganhou forma.

Tudo que confirma rede parece relevante.

Tudo que contraria rede passa a exigir esforço adicional.

É confortável.

E perigoso.


☕ Exemplo Bellacosa Mainframe: “É o Db2”

Nosso jovem programador COBOL vê uma transação lenta.

Sabe que houve problema semelhante no mês passado.

Naquela ocasião era Db2.

Então pensa:

“De novo.”

Olha para:

SQLCODE = -911

Pronto.

Caso encerrado.

“É banco.”

Só existe um detalhe.

O -911 aconteceu em uma transação secundária.

A verdadeira falha está sendo causada por contenção de fila em outro componente.

Mas agora toda a investigação está puxada para Db2.

Por quê?

Porque a primeira teoria ganhou um pedaço de evidência compatível.


🎯 Evidência compatível não é evidência exclusiva

Esse ponto é crucial.

Imagine:

Sistema lento.

Possíveis causas:

  • Db2;

  • CPU;

  • I/O;

  • rede;

  • lock;

  • aplicação;

  • fila;

  • volume;

  • dependência externa.

Você encontra CPU alta.

Isso prova que CPU é causa?

Não.

CPU alta é compatível com vários cenários.

Talvez seja consequência.

Talvez seja sintoma.

Talvez seja completamente incidental.

Um investigador maduro pergunta:

“O que mais poderia produzir este mesmo sinal?”

Essa pergunta é uma vacina contra Confirmation Bias.


🛸 Doctor Who e a armadilha do monstro conhecido

Imagine o Doctor chegando a uma estação espacial.

Luzes piscando.

Pessoas desaparecendo.

Ruído estranho.

O companion diz:

— Daleks!

Por quê?

Porque já viu Daleks antes.

Depois encontra uma marca circular na parede.

— Viu? Daleks!

O Doctor pergunta:

— Ou Cybermen?

— Não.

— Por quê?

— Porque eu acho que são Daleks.

Esse raciocínio é exatamente nosso problema.

Quanto mais cedo escolhemos o monstro, mais fácil reinterpretar tudo como evidência daquele monstro.


👻 Easter Egg nº 1 — “É sempre DNS”

Existe uma famosa brincadeira entre profissionais de infraestrutura:

“É sempre DNS.”

Muitas vezes é.

Mas o dia em que você decidir que sempre é DNS será provavelmente o dia em que não será.

A piada é engraçada justamente porque explora um padrão real.

Padrões ajudam.

Dogmas atrapalham.


🧩 Hipótese não é conclusão

Em investigação técnica, hipótese é ferramenta.

Exemplo:

HIPÓTESE A:
Problema em Db2.

Excelente.

Mas escreva também:

O QUE CONFIRMARIA?
- lock time elevado
- wait classes compatíveis
- queries degradadas

E principalmente:

O QUE REFUTARIA?
- tempos Db2 normais
- problema independente de SQL
- mesma falha em componente sem Db2

A parte “o que refutaria?” é frequentemente esquecida.

E é justamente a parte mais valiosa.


⚖️ Procure falsificar sua própria teoria

Aqui podemos emprestar uma ideia poderosa da ciência.

Não pergunte apenas:

“Como posso provar que estou certo?”

Pergunte:

“Como eu poderia demonstrar que estou errado?”

Se a hipótese for:

“O problema é rede.”

Teste algo que deveria estar necessariamente errado se fosse rede.

Se esse comportamento estiver normal, sua hipótese perde força.

Isso é investigação de verdade.


🧠 Confirmation Bias e memória

O viés não afeta apenas aquilo que procuramos.

Afeta também o que lembramos.

Depois de vários incidentes, um analista pode dizer:

“Sempre que acontece isso é storage.”

Talvez ele lembre fortemente dos quatro casos em que foi storage.

E esqueça os sete em que não foi.

Nosso cérebro não mantém estatística perfeita.

Ele mantém narrativas.


📊 Dados vencem memória

Se alguém disser:

“Esse erro quase sempre acontece por X.”

Pergunte:

“Temos histórico?”

Talvez exista:

20 incidentes similares

Storage: 4
Rede: 3
Aplicação: 7
Db2: 2
Outros: 4

A percepção “quase sempre storage” não sobrevive.

Isso é uma razão enorme para manter histórico de incidentes estruturado.

Memória institucional não deve depender apenas de lembrança humana.


🧀 Swiss Cheese encontra Confirmation Bias

Agora conectamos com nosso primeiro episódio.

Imagine várias barreiras.

Uma delas é:

monitoramento.

Outra:

análise humana.

Se a análise humana estiver contaminada por Confirmation Bias, essa barreira ganha um buraco.

Exemplo:

alerta aponta rede.

Equipe acredita em rede.

Todos passam duas horas investigando rede.

Enquanto isso o verdadeiro problema cresce em storage.

O viés cognitivo transformou-se em falha operacional.

Isso é importante:

Viés cognitivo também pode ser um buraco no queijo suíço.


🚨 Normalization of Deviance + Confirmation Bias

A combinação pode ser ainda pior.

Imagine:

RC=04 aparece diariamente.

A organização normalizou.

Um dia há incidente.

Alguém diz:

“Não pode ser esse RC=04. Ele sempre aparece.”

Isso é primeiro:

normalização do desvio.

Mas também pode virar:

viés de confirmação.

Como acreditamos que RC=04 é benigno, buscamos evidências que sustentem essa crença.

Mesmo quando o cenário mudou.


🕰️ Hindsight Bias + Confirmation Bias

Antes do incidente:

“Tenho certeza que é rede.”

Depois descobrem que era rede.

Agora surge:

“Era óbvio.”

Pronto.

Confirmation Bias escolheu a narrativa.

Hindsight Bias reconstruiu a história.

E todo mundo sai da reunião acreditando que a equipe “sempre soube”.

Esse encadeamento é perigosíssimo.


🔬 Como nasce o Confirmation Bias numa War Room

Um incidente ocorre.

Primeiro especialista fala:

“Parece aplicação.”

Segundo olha dashboard já pensando em aplicação.

Encontra GC alto.

— Aplicação.

Terceiro pergunta:

— Houve mudança?

— Sim, deploy ontem.

Pronto.

A sala inteira converge.

Mas o deploy pode ser irrelevante.

Mudanças recentes são suspeitos naturais.

Mas suspeito não é culpado.


👮 O problema do suspeito conveniente

Toda investigação tem um suspeito favorito.

Em TI:

  • “foi deploy”;

  • “foi rede”;

  • “foi banco”;

  • “foi storage”;

  • “foi usuário”;

  • “foi fornecedor”;

  • “foi mainframe”;

  • “foi cloud”.

Quanto mais historicamente culpado esse componente foi, mais rápido vira suspeito novamente.

Pense num seriado policial.

Se o detetive decidir nos primeiros cinco minutos quem é o assassino e passar o restante do episódio tentando provar, provavelmente teremos problema.


🧠 Anchoring: o primo que chega cedo

Confirmation Bias frequentemente trabalha ao lado de outro viés:

Anchoring Bias.

Ancoragem.

A primeira informação recebida influencia fortemente nosso julgamento.

Exemplo:

chamado chega:

“Problema de banco.”

Pronto.

A investigação já começa com um enquadramento.

Talvez o usuário não saiba absolutamente nada sobre banco.

Mas escreveu isso porque viu mensagem SQL.

Agora toda a equipe começa ancorada.

Essa é uma dica operacional importante:

descrição inicial do incidente não é diagnóstico.


📞 “Usuário disse que é lento”

Outro exemplo.

Usuário:

“Sistema está lento.”

Pergunta:

o que exatamente significa lento?

Login?

Consulta?

Gravação?

Somente uma tela?

Somente um cliente?

Somente certo horário?

“Lento” é interpretação.

Precisamos transformar percepção em observação.


🧪 Passo a passo para combater Confirmation Bias

Agora nossa TARDIS entra no modo operacional.

Passo 1 — Declare hipóteses explicitamente

Não deixe teorias circularem como fatos.

Em vez de:

“É rede.”

Use:

“Hipótese A: possível degradação de rede.”

Parece detalhe semântico.

Não é.

A palavra “hipótese” lembra ao cérebro que a conclusão ainda não existe.


Passo 2 — Tenha pelo menos duas hipóteses

Se possível:

A — aplicação
B — infraestrutura
C — banco

Mesmo que uma pareça muito mais provável.

A existência de alternativas reduz fixação.


Passo 3 — Liste evidências pró e contra

Quadro simples:

HIPÓTESE: DB2

A FAVOR
- SQLCODE observado
- aumento de wait

CONTRA
- transação sem SQL também falha
- CPU DB2 normal

A coluna contra é essencial.

Sem ela temos propaganda, não investigação.


Passo 4 — Procure uma evidência discriminante

Isso significa algo que diferencie duas hipóteses.

Por exemplo:

se for rede, determinada chamada remota deve estar lenta.

Se for aplicação, chamada local também ficará lenta.

Teste.

Agora estamos aprendendo.


Passo 5 — Separe sintoma de causa

CPU alta pode ser:

causa;

consequência;

coincidência.

RC=04 também.

Timeout também.

Não transforme automaticamente primeiro sintoma observado em causa raiz.


Passo 6 — Faça alguém defender a hipótese oposta

Em incidentes grandes, pode ser útil uma espécie de devil’s advocate.

Alguém pergunta:

“E se não for rede?”

Não precisa ser hostil.

A função é proteger a equipe contra convergência prematura.


Passo 7 — Reavalie em intervalos

A cada 20 ou 30 minutos:

“Nossa hipótese principal ainda faz sentido?”

“O que aprendemos?”

“Qual evidência a enfraqueceu?”

Isso evita passar três horas em uma teoria morta.


Passo 8 — Registre quando uma hipótese caiu

Não apague.

Exemplo:

10:20
Hipótese: Db2

10:43
Descartada porque transações sem SQL apresentam mesma degradação.

Isso evita alguém reabrir a mesma investigação vinte minutos depois.


Passo 9 — Cuidado com especialistas

Especialistas são valiosíssimos.

Mas existe uma armadilha.

Para quem possui um martelo, muitos problemas parecem pregos.

DBA vê banco.

Network engineer vê rede.

Programador vê código.

Security vê ataque.

Cada pessoa enxerga o mundo através de seu domínio.

Por isso incidentes complexos precisam de visão sistêmica.


🏥 Um exemplo fora da informática

Imagine medicina.

Paciente chega com tosse.

Médico pensa:

gripe.

Começa a valorizar:

febre;

dor;

cansaço.

Talvez ignore um sinal incompatível com gripe.

É exatamente por isso que diagnóstico diferencial existe.

TI precisa de algo semelhante.

Podemos chamar de:

diagnóstico diferencial de incidentes.


🧾 Diagnóstico diferencial Bellacosa

Sintoma:

batch 40% mais lento

Possibilidades:

  • volume maior;

  • CPU;

  • I/O;

  • Db2;

  • lock;

  • dataset fragmented;

  • rede;

  • mudança de código;

  • concorrência;

  • storage.

Agora investigue.

Não case com o primeiro item.


🧠 Curiosidade: inteligência não imuniza contra viés

Ser muito experiente não elimina Confirmation Bias.

Às vezes aumenta.

Por quê?

Porque pessoas experientes possuem muito mais conhecimento para construir argumentos convincentes em favor da própria hipótese.

Isso é assustador.

Você pode estar errado com enorme sofisticação.


👨‍💻 O programador COBOL iniciante possui uma vantagem

Nosso iniciante às vezes pergunta:

“Mas por que sabemos que é banco?”

O veterano responde:

“Experiência.”

Pergunta seguinte:

“Que evidência mostraria que não é?”

Essa é uma pergunta excelente.

Não agressiva.

Não desrespeitosa.

Mas cientificamente poderosa.


🧭 O papel do Incident Commander

Em uma War Room madura, alguém precisa coordenar investigação.

Não necessariamente resolver tecnicamente.

Esse papel pode perguntar:

  • quais hipóteses existem?

  • quais evidências temos?

  • o que já foi descartado?

  • qual próximo teste?

  • quem está investigando o quê?

  • que informação contradiz nossa teoria?

Essa estrutura reduz caos cognitivo.


🗂️ Hipothesis Board

Uma ferramenta simples:

HIPÓTESE  STATUS      EVIDÊNCIA
A         provável    3 pró / 1 contra
B         aberta      1 pró
C         descartada  teste X negativo

Parece básico.

Mas força explicitação.

E aquilo que está explícito pode ser contestado.


⚠️ A frase “eu tenho certeza”

Durante investigação, certeza prematura merece atenção.

Troque:

“Tenho certeza que é aplicação.”

por:

“Minha hipótese principal é aplicação porque A e B.”

Agora temos algo testável.

Certeza encerra conversa.

Hipótese abre investigação.


📉 Confirmation Bias em dashboards

Até dashboards podem reforçar viés.

Se a equipe acredita que problema é CPU, começa a abrir apenas gráficos de CPU.

Naturalmente encontrará alguma anomalia.

Qualquer sistema grande possui alguma métrica estranha em algum momento.

A pergunta correta é:

Essa anomalia possui correlação temporal e causal com o incidente?


🔗 Correlação não é causalidade

Dois eventos aconteceram juntos.

Isso não significa que um causou outro.

Exemplo:

CPU subiu exatamente quando transações falharam.

Talvez CPU causou falha.

Talvez falhas causaram retries.

Retries elevaram CPU.

A direção causal pode ser oposta.

Sempre pergunte:

Qual mecanismo conecta A a B?


🕳️ Easter Egg nº 2 — O buraco que queremos encontrar

Na primeira viagem procurávamos buracos no queijo.

Agora existe um risco diferente.

Se acreditamos que o buraco está na terceira fatia, podemos ficar olhando apenas para ela.

Enquanto o verdadeiro caminho atravessa a quinta.

O queijo suíço também sofre com Confirmation Bias.


🧯 Near Miss e viés de confirmação

Imagine um near miss.

Equipe acredita:

“Foi usuário.”

Usuário recebe treinamento.

Caso encerrado.

Três semanas depois ocorre incidente igual.

Descobrem que interface permitia seleção ambígua.

A investigação anterior estava presa à hipótese “erro humano”.

Perdemos uma oportunidade gratuita de corrigir o sistema.

É por isso que near miss mal investigado é oportunidade desperdiçada.


🔄 Melhoria contínua exige aprender a estar errado

Existe algo culturalmente difícil aqui.

Equipes precisam conseguir dizer:

“Nossa hipótese estava errada.”

Sem vergonha.

Isso deveria ser celebrado.

Porque descartar uma hipótese reduz espaço de busca.

Em ciência:

resultado negativo também informa.

Em incidentes:

também.


🏆 Quem muda de ideia mais rápido ganha

War Room não é debate acadêmico.

Objetivo não é provar que você estava certo.

Objetivo é restaurar serviço e aprender.

A pessoa que muda de hipótese diante de nova evidência não “perdeu”.

Ela está fazendo investigação corretamente.


🧬 Regeneração organizacional

Como uma organização se regenera depois de reconhecer Confirmation Bias?

Ela muda práticas.

Por exemplo:

hipóteses explícitas;

registro de evidências;

colunas pró/contra;

revisões periódicas;

devil’s advocate;

post-mortem blameless;

dados históricos;

diagnóstico diferencial.

Com o tempo isso cria uma cultura onde:

“Eu acho que é X”

significa:

“Vamos testar X.”

E não:

“Agora vamos provar X.”


🧠 Confirmation Bias em segurança

Em cybersecurity isso é extremamente perigoso.

Imagine alerta suspeito.

Analista acredita que é malware.

Tudo vira evidência de malware.

Mas talvez seja insider.

Ou configuração.

Ou comportamento legítimo raro.

O contrário também ocorre:

“Esse usuário é confiável.”

Então sinais suspeitos recebem explicações benevolentes.

Viés funciona nos dois sentidos.


💰 Em sistemas financeiros

Imagine reconciliação com diferença.

Analista acredita que foi arredondamento.

Encontra centavos divergentes.

Conclui:

arredondamento.

Mas existe fraude ou duplicidade.

Primeira explicação plausível pode impedir investigação posterior.

Sistemas financeiros não podem depender de:

“parece ser.”

Precisamos reconciliar.


📋 Checklist anti-Confirmation Bias

Antes de encerrar uma investigação, pergunte:

[ ] Qual era nossa hipótese inicial?

[ ] Quais alternativas consideramos?

[ ] Que evidência contrária apareceu?

[ ] Tentamos refutar nossa teoria?

[ ] Diferenciamos sintoma de causa?

[ ] Existe mecanismo causal claro?

[ ] A causa explica todos os sintomas relevantes?

[ ] Conseguimos reproduzir?

[ ] A correção eliminou o comportamento?

[ ] Existe evidência de que não foi apenas coincidência?

Se várias respostas forem “não”...

Talvez você tenha encontrado explicação.

Mas ainda não causa.


👽 Doctor Who e o investigador que quer estar errado

Nosso Doctor possui uma qualidade excelente.

Ele cria teorias.

Muitas.

E muda rapidamente quando novas informações aparecem.

Essa é a mentalidade ideal.

Curiosidade acima do ego.

Imagine:

— São Daleks.

Nova evidência.

— Não são Daleks.

Não existe reunião de duas horas tentando preservar a hipótese original apenas porque estava no primeiro PowerPoint.

A aventura continua.


📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Confirmation Bias nos faz favorecer evidências que confirmam aquilo em que já acreditamos.

Hipótese não é conclusão.

Procure ativamente evidências contrárias.

Pergunte o que provaria que você está errado.

Tenha hipóteses concorrentes.

Sintoma não é automaticamente causa.

Correlação não garante causalidade.

Especialistas também possuem vieses.

Dados históricos são melhores que memória seletiva.

Mudar de hipótese diante de evidência nova é competência, não fraqueza.

E principalmente:

Uma investigação não existe para demonstrar que nossa primeira teoria estava certa. Existe para descobrir o que realmente aconteceu.


🕰️ De volta à War Room

11:37.

A equipe já passou quase duas horas investigando Db2.

Tudo parece razoavelmente normal.

Nosso jovem programador COBOL pergunta:

— E se não for banco?

Silêncio.

DBA olha.

Analista de aplicação olha.

Operador olha.

Alguém responde:

— Mas encontramos aquele SQLCODE.

O jovem pergunta:

— Ele explica as transações que não usam Db2?

Silêncio novamente.

O Doctor sorri.

— Agora estamos chegando a algum lugar.

Eles abrem outro dashboard.

A fila MQ está crescendo.

Devagar.

Desde 08:53.

Uma aplicação downstream está respondendo lentamente.

O SQLCODE era consequência de timeouts e retries.

Não causa.

O DBA cruza os braços.

— Então eu estava errado.

O Doctor responde:

— Excelente.

O DBA estranha.

— Excelente?

— Claro.

— Passamos duas horas errados.

— Sim.

— Isso não é excelente.

O Doctor aponta para a tela.

— Seria muito pior passar mais duas tentando continuar certos.

A fila é investigada.

Um consumer ficou parcialmente degradado após uma mudança noturna.

Serviço restaurado.

Incidente encerrado.

Nosso jovem programador olha para o quadro.

Apaga:

CAUSA: DB2

e escreve:

HIPÓTESE DESCARTADA: DB2

Depois:

CAUSA: AINDA EM INVESTIGAÇÃO

O operador comenta:

— Isso parece menos elegante.

O Doctor coloca o casaco.

— A verdade frequentemente é.

VWORP.

VWORP.

VWORP.

A TARDIS começa a desaparecer.


🥚 Easter Egg final

Horas depois, o programador encontra no spool um job estranho:

JOBNAME: SHERLOCK

O conteúdo possui apenas:

IF EVIDENCE SUPPORTS MY THEORY
    CONTINUE
ELSE
    RECONSIDER-THEORY
END-IF.

Abaixo existe um comentário:

* THE GAME IS AFOOT.

Ele sorri.

Mas logo percebe outra linha:

* BEWARE OF THE FIRST STORY THAT FEELS COMPLETE.

Fecha o spool.

Na tela aparece novo alerta.

Dessa vez ele não diz:

“Já sei o que é.”

Ele pega o café.

Abre os dados.

E pergunta:

“Quais explicações ainda são possíveis?”

Talvez esse seja o momento em que alguém deixa de ser simplesmente um programador que resolve erros...

e começa a se tornar um verdadeiro investigador de sistemas.

☕🌀

Next stop: Anchoring Bias — quando a primeira explicação lançada na War Room gruda na investigação como chiclete em sapato britânico e todo mundo passa horas tentando andar com aquilo.


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