Bellacosa Mainframe e o anchoring bias

☕ Um Café no Bellacosa Mainframe

Anchoring Bias: Doctor Who, COBOL e o Dia em que a Primeira Explicação Prendeu Toda a War Room

Uma viagem pela TARDIS dos incidentes para entender por que a primeira informação costuma pesar demais — mesmo quando está errada

09:03.

O telefone toca.

Usuário:

— O sistema está lento.

Analista:

— Desde quando?

Usuário:

— Depois da mudança de ontem.

Pronto.

Duas frases.

Nenhum gráfico.

Nenhum log.

Nenhuma métrica.

Nenhum teste.

Nenhuma correlação comprovada.

Mas a War Room ainda nem começou e já temos nosso primeiro suspeito:

a mudança de ontem.

Às 09:08 alguém escreve no chat:

“Provável problema no deploy.”

Às 09:11 o gerente pergunta:

— Conseguimos fazer rollback?

Às 09:14 o programador abre o código alterado.

Às 09:19 alguém encontra uma instrução diferente.

Às 09:22:

— Deve ser isso.

Às 09:30 metade da equipe está investigando aplicação.

Enquanto isso, em outra tela, uma fila MQ cresce silenciosamente.

VWORP.

A TARDIS materializa-se ao lado do quadro branco.

O Doctor sai.

Lê:

HIPÓTESE PRINCIPAL:
ERRO NO DEPLOY

Pergunta:

— Que evidência temos?

Um analista responde:

— O problema começou depois da mudança.

— Isso é evidência de causalidade?

Silêncio.

— Bem... aconteceu depois.

O Doctor sorri.

— Ah.

Pausa.

— Então se chover depois do almoço, devemos investigar o sanduíche?

Eis nosso monstro da semana:

Anchoring Bias

Ou:

Viés de Ancoragem

A tendência de dar peso excessivo à primeira informação recebida, usando-a como referência para todas as avaliações seguintes.

🌀 Onde estamos na nossa viagem?

Até aqui já passamos por quatro monstros.

Primeiro, o Swiss Cheese Model.

Aprendemos que barreiras falham.

Depois veio a Normalization of Deviance.

Aprendemos que desvios podem virar rotina.

Depois encontramos o Hindsight Bias.

Descobrimos que o passado parece muito mais óbvio depois que conhecemos o final.

Então veio o Confirmation Bias.

Aprendemos que, depois de escolher uma teoria, nosso cérebro adora procurar provas que concordem com ela.

Agora finalmente encontramos o mecanismo que muitas vezes escolhe essa primeira teoria:

a âncora.

⚓ O que é Anchoring Bias?

Anchoring Bias acontece quando uma informação inicial influencia desproporcionalmente julgamentos posteriores.

Essa primeira informação funciona como uma âncora.

Mesmo quando recebemos novos dados, nossa avaliação tende a permanecer próxima daquele ponto inicial.

Em forma simples:

PRIMEIRA INFORMAÇÃO
        ↓
FORMA UMA ÂNCORA
        ↓
NOVOS DADOS SÃO INTERPRETADOS
A PARTIR DAQUELA REFERÊNCIA

Não significa que nunca mudamos de ideia.

Significa que começamos a investigação puxados por uma força invisível.

🧠 Um exemplo fora da informática

Imagine que alguém pergunte:

— Um produto custa mais ou menos de R$ 10.000?

Depois pergunta:

— Quanto você acha que ele custa?

Mesmo que R$ 10.000 tenha sido escolhido arbitrariamente, ele pode influenciar sua estimativa.

Agora troque preço por incidente.

Primeira frase do chamado:

“Problema de banco de dados.”

A equipe começa de um ponto.

Mesmo antes de validar.

☕ Bellacosa Mainframe: o poder destrutivo do assunto do chamado

Ticket:

ASSUNTO:
LENTIDÃO DB2

Talvez o usuário tenha colocado “Db2” porque viu uma mensagem SQL.

Agora chegam:

DBA;

analista COBOL;

infraestrutura;

suporte.

Primeira reação:

— Vamos olhar Db2.

Essa é uma âncora.

Mas talvez o banco esteja apenas esperando uma aplicação downstream.

Talvez seja rede.

Talvez seja MQ.

Talvez seja storage.

Talvez o SQLCODE seja consequência.

O nome do ticket não deveria determinar a investigação.

Mas frequentemente determina.

🧲 A primeira hipótese gruda

Anchoring Bias é particularmente perigoso porque opera antes mesmo do Confirmation Bias.

Observe:

1. ALGUÉM DIZ:
“É REDE.”

2. A EQUIPE ANCORA EM REDE.

3. COMEÇA A BUSCAR PROVAS.

4. CONFIRMATION BIAS ENTRA.

5. TODO TIMEOUT VIRA
“EVIDÊNCIA DE REDE”.

Então temos uma dupla dinâmica:

Anchoring escolhe o suspeito.

Confirmation Bias tenta condená-lo.

Maravilhoso.

Para o incidente.

👻 Easter Egg nº 1 — O primeiro monstro visto

Imagine Doctor Who.

A equipe entra numa nave.

Encontra marcas metálicas na parede.

Alguém grita:

— Cybermen!

A partir daí:

qualquer ruído metálico vira Cyberman.

Qualquer interferência vira Cyberman.

Qualquer porta automática vira Cyberman.

Até que o Doctor pergunta:

— Por que Cybermen?

Resposta:

— Porque foi a primeira coisa que pensamos.

Parabéns.

Encontramos a âncora.

🚨 A War Room começa antes da War Room

Esse é um ponto importantíssimo.

A investigação muitas vezes já chega contaminada.

Antes da primeira reunião, alguém escreveu:

“erro de aplicação”.

Ou:

“falha de infraestrutura”.

Ou:

“problema após deploy”.

Ou:

“usuário informou falha de banco”.

Essas frases parecem inocentes.

Mas moldam atenção.

Por isso linguagem importa.

Compare:

INCIDENTE:
Falha causada por deploy.

com:

OBSERVAÇÃO:
Sintomas começaram após o deploy.
Causalidade ainda não confirmada.

A segunda formulação é muito melhor.

🧠 A diferença entre cronologia e causalidade

Uma das âncoras mais comuns é:

“Começou depois de X.”

Isso é útil.

Mas não prova:

“Foi causado por X.”

Existe um velho problema lógico:

post hoc ergo propter hoc

“Depois disso, portanto por causa disso.”

Em incidentes:

deploy às 02:00.

erro às 02:15.

Logo:

deploy causou erro.

Talvez.

Mas também poderia haver:

certificado expirando;

pico de volume;

job concorrente;

manutenção externa;

timeout de fornecedor;

fila acumulada;

problema de storage.

A proximidade temporal faz do deploy um suspeito forte.

Não necessariamente culpado.

💻 Exemplo COBOL: o campo que parecia culpado

Programa novo entra em produção.

Após algumas horas:

SOC7

O primeiro dump mostra:

WS-VALOR

Alguém conclui:

— Campo numérico inválido.

Agora toda investigação vai para dados.

Só que o campo inválido é consequência de corrupção anterior em memória.

O problema real está em um índice incorreto.

Mas a primeira pista ancorou a equipe.

Isso acontece muito em debugging.

O ponto onde o programa quebra nem sempre é o ponto onde o erro nasceu.

🎯 Abend location não é necessariamente root cause

Essa frase vale ouro para iniciante COBOL.

O programa abenda na linha 500.

Você pensa:

problema na linha 500.

Talvez.

Ou talvez a linha 500 seja apenas onde a inconsistência finalmente ficou visível.

A origem pode estar:

linha 80;

arquivo de entrada;

copybook;

chamada externa;

campo redefinido;

índice;

memória;

retorno de programa anterior.

Não deixe o dump se transformar numa âncora absoluta.

Ele mostra onde morreu.

Não necessariamente onde ficou doente.

🧩 Anchoring Bias e debugging

Imagine:

IF WS-CODIGO = 'A'
    PERFORM PROCESSA-A
END-IF

Programa falha em PROCESSA-A.

Naturalmente você investiga PROCESSA-A.

Depois de uma hora, descobre:

WS-CODIGO nunca deveria ter recebido A.

A causa está numa leitura anterior.

A primeira falha observável ancorou sua investigação.

Esse é um ótimo exemplo.

📞 O perigo da frase do usuário

Usuários relatam sintomas usando o próprio modelo mental.

Exemplo:

“Banco não atualizou.”

Isso pode significar:

tela ainda mostra valor antigo;
cache;
mensagem atrasada;
processamento batch ainda não terminou;
integração não retornou;
transação rollbackou;
leitura está usando réplica;
problema visual.

O usuário não está mentindo.

Ele está descrevendo o mundo como enxerga.

Transformar sua interpretação em diagnóstico técnico cria âncora.

🔎 Descrição não é diagnóstico

Essa regra deveria estar em toda central de suporte:

“Relato inicial descreve percepção, não causa.”

Ticket bom:

Usuário informa que saldo exibido não mudou após operação realizada às 10:17.

Ticket ruim:

Banco não atualiza saldo.

O primeiro preserva observação.

O segundo injeta teoria.

🧠 Autoridade amplifica a âncora

Agora adicionemos outro ingrediente.

Gerente diz:

— Deve ser aplicação.

Pronto.

A âncora agora pesa o dobro.

Por quê?

Porque autoridade aumenta influência.

Isso começa a tocar em outro tema que veremos depois:

Authority Gradient.

Se uma pessoa de maior hierarquia lança a primeira hipótese, a equipe pode ter dificuldade de questionar.

Assim:

GERENTE:
“É APLICAÇÃO.”

ANALISTA:
“Talvez...”

PENSAMENTO:
“Tenho dados dizendo rede,
mas talvez eu esteja errado.”

Perigoso.

🧱 A primeira métrica também pode virar âncora

Não apenas pessoas criam âncoras.

Dashboards também.

Imagine o primeiro painel aberto:

CPU 92%.

Pronto.

“CPU.”

Depois descobrimos que CPU subiu porque milhares de retries foram disparados devido a um problema externo.

CPU era consequência.

Mas como foi o primeiro número vermelho, virou o centro da narrativa.

🔴 Vermelho atrai atenção

Interfaces operacionais também influenciam julgamento.

Um indicador vermelho parece importante.

Talvez seja.

Mas um indicador verde pode esconder problema.

Exemplo:

CPU: 95%    RED
MQ QUEUE: 47000   YELLOW
DB2: NORMAL   GREEN

Todo mundo olha CPU.

Mas a fila crescente pode ser muito mais relevante.

Design de observabilidade também pode criar âncoras.

🧀 Swiss Cheese + Anchoring

Vamos conectar com nosso primeiro episódio.

Uma das camadas de defesa é:

diagnóstico humano.

Se a equipe ancora numa hipótese errada, essa camada cria um buraco.

Exemplo:

real problema:

storage.

âncora:

rede.

Duas horas investigando rede.

Enquanto storage degrada.

O viés cognitivo torna-se mecanismo de propagação do incidente.

🌀 Normalization of Deviance + Anchoring

Imagine que um alerta aparece diariamente.

A equipe já o normalizou.

Então ocorre incidente.

Primeira hipótese:

“Não é esse alerta; ele sempre aparece.”

Essa própria normalização vira uma âncora.

Passamos a investigação inteira partindo do pressuposto:

esse sinal é irrelevante.

Mas talvez hoje o contexto seja diferente.

🕰️ Hindsight Bias + Anchoring

Depois do incidente, olhamos para trás.

Descobrimos que a primeira pista verdadeira apareceu às 08:15.

Agora pensamos:

“Essa deveria ter sido a âncora!”

Mas cuidado.

Hindsight Bias novamente.

Naquele momento existiam dezenas de outros sinais.

A grande pergunta continua:

o que tornaria aquele sinal distinguível antes?

🔍 Confirmation Bias + Anchoring

Essa combinação merece um quadro:

ANCHORING BIAS
“ACHO QUE É REDE.”
       ↓
CONFIRMATION BIAS
“VAMOS PROCURAR PROVAS DE REDE.”
       ↓
HINDSIGHT BIAS
“DEPOIS FICOU ÓBVIO QUE ERA REDE.”

Se ainda houver Normalization of Deviance no meio...

Temos quase um episódio especial de Natal.

🧪 Como combater Anchoring Bias

Agora vamos para prática.

Passo 1 — Separe fatos de interpretações

Quadro:

FATOS
- usuários relatam lentidão
- começou aproximadamente 09:00
- fila MQ cresceu 30%
- houve deploy às 02:00

INTERPRETAÇÕES
- deploy causou
- MQ é causa
- aplicação está lenta

Nunca misture.

📝 Passo 2 — Reescreva o incidente sem diagnóstico

Evite:

“Incidente de Db2.”

Use:

“Aumento de tempo de resposta em transações X e Y desde 09:00.”

Agora você preserva espaço de investigação.

🧠 Passo 3 — Pergunte: “Qual foi nossa primeira informação?”

Durante War Room:

Qual foi a primeira coisa que ouvimos?

Isso está influenciando demais?

Essa pergunta simples pode libertar a equipe.

🔀 Passo 4 — Gere hipóteses antes de discutir

Uma técnica excelente:

cada pessoa escreve hipóteses independentemente.

Depois compartham.

Por quê?

Se a primeira pessoa fala antes, ela pode ancorar as demais.

Exemplo:

cinco especialistas.

Cada um anota:

A — aplicação
B — rede
C — banco
D — MQ
E — volume

Depois comparam.

Isso reduz influência inicial.

🧭 Passo 5 — Estabeleça baseline

Âncoras frequentemente aparecem porque não sabemos o que é normal.

CPU 80%.

É alto?

Depende.

Se normalmente é 75%, talvez não.

Se normalmente é 20%, sim.

Conheça baseline.

Sem baseline, o primeiro número visto vira referência psicológica.

📊 Passo 6 — Use múltiplas referências

Não compare apenas:

agora versus imediatamente antes.

Compare:

mesma hora ontem;
média semanal;
período equivalente;
baseline histórico;
outros componentes.

Isso evita que um único ponto temporal se torne âncora.

🧪 Passo 7 — Teste hipótese independente da sequência

Pergunte:

Se eu não soubesse que houve deploy, o que os dados me fariam suspeitar?

Essa pergunta é poderosa.

Remove artificialmente a âncora.

Outra:

Se esse chamado tivesse chegado sem título, qual seria meu diagnóstico inicial?

Excelente exercício.

🧑‍🔬 Passo 8 — Faça blind analysis quando possível

Em alguns casos, alguém pode analisar métricas sem saber qual teoria está sendo defendida.

Isso reduz influência.

Exemplo:

— Veja esse gráfico e diga o que observa.

Em vez de:

— Veja se encontra evidência de problema de rede.

A segunda pergunta já ancora.

🎯 Passo 9 — Defina critérios de descarte

Hipótese:

rede.

Escreva:

DESCARTAR SE:
- latência externa normal
- packet loss normal
- componentes locais também afetados

Isso evita permanecer preso à teoria indefinidamente.

⏱️ Passo 10 — Coloque tempo máximo por hipótese

Exemplo:

20 minutos para validar rede.

Se não aparecer evidência forte:

reavaliar.

Isso previne “tunnel vision”.

🚇 Tunnel Vision

Anchoring Bias frequentemente leva a tunnel vision.

A equipe passa a olhar uma parte estreita do sistema.

Tudo fora daquele túnel desaparece.

Em sistemas distribuídos isso é extremamente perigoso.

Porque incidentes atravessam camadas.

Mainframe.

MQ.

API.

Cloud.

Rede.

Parceiro.

Banco.

Um problema pode nascer longe de onde aparece.

🛰️ O mapa inteiro importa

Imagine:

USUÁRIO
  ↓
FRONT-END
  ↓
API
  ↓
MQ
  ↓
CICS
  ↓
COBOL
  ↓
DB2

Erro aparece no CICS.

Âncora:

CICS.

Mas talvez MQ esteja entregando mensagens duplicadas.

Ou API esteja gerando retries.

Ou usuário esteja repetindo ação por lentidão.

Sistemas modernos e híbridos exigem visão ponta a ponta.

🧠 Curiosidade: números aleatórios também podem influenciar

O fenômeno de ancoragem é tão forte que estudos clássicos mostraram que até números inicialmente irrelevantes podem influenciar estimativas posteriores.

Isso ensina algo desconfortável:

nosso cérebro busca referências mesmo quando a referência não deveria importar.

Em incidentes, a primeira estimativa de impacto pode fazer isso.

Alguém diz:

“Acho que afetou 10%.”

Mesmo sem dados.

Mais tarde todas as estimativas começam próximas de 10%.

Cuidado.

💰 Anchoring Bias em impacto financeiro

Primeira estimativa:

R$ 1 milhão.

Depois surgem novos dados.

Talvez impacto seja R$ 5 milhões.

Mas gestores podem resistir a abandonar o primeiro número.

Por isso estimativas iniciais devem ser claramente marcadas:

ESTIMATIVA PRELIMINAR
BAIXA CONFIANÇA

Linguagem reduz risco cognitivo.

🧯 Em segurança cibernética

Alerta:

“Possível phishing.”

A equipe ancora em phishing.

Mas talvez seja:

account takeover;

malware;

token roubado;

insider;

configuração.

Novamente:

classificação inicial ajuda triagem.

Não deveria encerrar diagnóstico.

🏦 Em sistemas financeiros

Diferença contábil aparece.

Primeira hipótese:

arredondamento.

Porque ocorreu antes.

Essa âncora pode atrasar descoberta de:

duplicidade;

integração parcial;

fraude;

problema de data;

regra nova.

A primeira explicação plausível é uma das coisas mais perigosas em reconciliação.

👨‍💻 O COBOL iniciante e o poder de perguntar

Nosso programador iniciante tem uma arma poderosa:

não conhece todas as histórias antigas.

Pergunta:

— Por que estamos investigando Db2?

Veterano:

— Porque o ticket veio como Db2.

Silêncio.

Essa frase deveria soar estranha.

O iniciante pergunta:

— E se o ticket estiver errado?

Excelente.

Inocência metodológica.

☕ Pergunta Bellacosa

Quando perceber que todo mundo está olhando para o mesmo lugar, pergunte:

“Se ninguém tivesse sugerido essa hipótese primeiro, para onde olharíamos?”

Essa pergunta pode salvar horas.

👥 Groupthink começa a aparecer

Aqui enxergamos outro monstro no horizonte.

Se uma pessoa cria a âncora e o grupo converge rapidamente, podemos entrar em:

Groupthink.

Todos concordam.

Não necessariamente porque a evidência é forte.

Mas porque o consenso já nasceu.

Esse será outro episódio delicioso.

E perigosíssimo.

⚠️ Senioridade não elimina ancoragem

Um veterano pode ter mais referências.

Isso ajuda.

Mas também pode ancorá-lo em experiências anteriores.

“Vi isso em 2003. Era VSAM.”

Talvez.

Mas 2026 não é 2003.

Experiência cria atalhos mentais.

Atalhos são úteis.

Até pegarmos a saída errada.

🧠 Recognition-Primed Decision

Profissionais experientes frequentemente reconhecem padrões rapidamente.

Isso é valioso.

Mas existe diferença entre:

“Esse padrão se parece com X.”

“É X.”

A primeira é hipótese baseada em experiência.

A segunda pode virar âncora rígida.

A maturidade está em usar experiência sem casar com ela.

📋 Checklist anti-Anchoring

Antes de seguir uma hipótese, pergunte:

[ ] Qual foi nossa primeira informação?

[ ] Ela é fato ou interpretação?

[ ] Quem forneceu essa informação?

[ ] Existe viés de autoridade?

[ ] Houve mudança recente?

[ ] Estamos confundindo “depois” com “por causa de”?

[ ] Quais hipóteses teríamos sem essa informação?

[ ] Qual dado contradiz nossa âncora?

[ ] Estamos olhando o sistema inteiro?

[ ] Existe critério claro para abandonar essa hipótese?

Se você não consegue abandonar sua teoria...

Talvez já esteja ancorado.

🧬 Regeneração organizacional

Como a organização se regenera?

Primeiro:

padroniza descrição neutra de incidentes.

Depois:

separa observação de diagnóstico.

Cria hipótese board.

Evita títulos acusatórios.

Usa múltiplas hipóteses.

Registra nível de confiança.

Reavalia periodicamente.

Incentiva contestação respeitosa.

E principalmente:

transforma:

“É isso.”

em:

“Nossa hipótese principal agora é isso.”

Duas palavras mudam tudo:

“agora”

“hipótese”.

🛸 Doctor Who e a âncora temporal

Talvez Doctor Who seja a metáfora perfeita para Anchoring Bias porque o Doctor sempre possui algo que nós não temos:

capacidade de mudar de perspectiva temporal.

Nós enxergamos:

agora.

Ele pode ver:

antes;

depois;

outra linha temporal.

A melhor defesa contra ancoragem é justamente mudar de perspectiva.

Pergunte:

O que eu veria se estivesse em outro time?

O que eu concluiria sem conhecer o deploy?

O que eu pensaria se isso acontecesse ontem?

O que um iniciante observaria?

Mude o ponto de vista.

📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Anchoring Bias faz a primeira informação pesar demais.

Descrição inicial não é diagnóstico.

Ordem dos acontecimentos não prova causalidade.

O ponto onde o sistema falha pode não ser o ponto onde o erro nasceu.

A primeira métrica vermelha pode ser sintoma, não causa.

Autoridade torna âncoras mais fortes.

Gere hipóteses independentes antes de convergir.

Separe fatos de interpretações.

Defina critérios para abandonar hipóteses.

Experiência ajuda, mas também pode ancorar.

E principalmente:

A primeira explicação merece ser investigada — não obedecida.

🕰️ De volta à War Room

10:17.

A equipe continua investigando o deploy.

Rollback já está sendo preparado.

Nosso programador iniciante olha para a fila MQ.

QUEUE DEPTH: 18432

Pergunta:

— Isso é normal?

Alguém responde:

— Não sei. Estamos olhando aplicação.

Ele insiste:

— Mas começou quando?

Abrem histórico.

08:41.

O deploy havia terminado às 02:00.

Fila cresce desde 08:41.

Nenhuma alteração de aplicação nesse horário.

O Doctor se aproxima.

— Interessante.

A equipe olha.

Descobrem que um consumer downstream começou a responder lentamente depois de uma alteração de infraestrutura externa.

O deploy era inocente.

O rollback teria introduzido outro risco sem resolver nada.

O gerente olha para o quadro:

CAUSA PROVÁVEL:
DEPLOY

Apaga.

Escreve:

HIPÓTESE DESCARTADA:
DEPLOY

Depois:

CAUSA:
CONSUMER DOWNSTREAM DEGRADADO

Nosso programador pergunta:

— Então perdemos uma hora?

O Doctor responde:

— Não necessariamente.

— Como assim?

— Se vocês aprenderem por que perderam.

Ele aponta para o primeiro ticket:

PROBLEMA APÓS DEPLOY

Depois pega uma caneta e reescreve:

LENTIDÃO REPORTADA ÀS 09:03.
HOUVE DEPLOY ÀS 02:00.
CAUSALIDADE NÃO ESTABELECIDA.

— Melhor?

O iniciante sorri.

— Muito melhor.

VWORP.

A TARDIS começa a desaparecer.

🥚 Easter Egg final

Horas depois, nosso programador encontra um membro estranho:

BELLACOSA.BIAS(MORIARTY)

Dentro:

       IF FIRST-IDEA = TRUE
           MOVE 'SUSPECT' TO WS-STATUS
       END-IF.

       IF FIRST-IDEA = 'CERTA'
           DISPLAY 'PROVE IT'
       END-IF.

No comentário:

* THE FIRST CLUE IS NOT ALWAYS THE BEST CLUE.

Logo abaixo:

* 221B

Ele olha para o corredor.

Por um segundo acha que ouve um violino.

Talvez seja apenas o ar-condicionado.

Ou talvez seja outra âncora.

O telefone toca.

Novo incidente.

Chamado:

“Erro de rede.”

Nosso programador não chama imediatamente a equipe de rede.

Primeiro pergunta:

— O que exatamente foi observado?

Do outro lado:

— Timeout.

— Em qual etapa?

— Depois de clicar em confirmar.

— Todas as transações?

— Só algumas.

Ele abre o mapa do fluxo.

E sorri.

Ainda não sabe a causa.

Mas já aprendeu algo extremamente importante:

não saber ainda é muito melhor do que estar errado cedo demais.

☕🌀

Next stop: Groupthink — quando sete profissionais inteligentes entram numa War Room e, misteriosamente, saem com uma única opinião.

Translate

sexta-feira, 14 de maio de 2010