 |
| 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.
Sem comentários:
Enviar um comentário