 |
| Bellacosa Mainframe e a representativeness heuristic |
☕ Um Café no Bellacosa Mainframe
Representativeness Heuristic: Doctor Who, COBOL e o Dia em que o Incidente Parecia Tanto com Db2 que Ninguém Procurou em Outro Lugar
Uma viagem pela TARDIS dos incidentes para entender por que “ter cara de alguma coisa” pode ser suficiente para convencer nosso cérebro — mesmo quando taxas-base, contexto e evidências contam outra história
08:17.
Segunda-feira.
Café quente.
War Room ainda vazia.
Nosso jovem programador COBOL abre o dashboard.
PAYMENT RESPONSE TIME: +240%
Outro indicador:
TRANSACTION TIMEOUTS: +190%
Outro:
APPLICATION WAIT TIME: HIGH
O DBA entra.
Olha rapidamente.
— Db2.
Nosso jovem pergunta:
— Já encontrou lock?
— Ainda não.
— Thread presa?
— Ainda não.
— Log cheio?
— Não.
— Então por que Db2?
O DBA aponta para o gráfico.
— Tem cara de Db2.
Cinco minutos depois, chega outro especialista.
— O que temos?
— Db2.
— Ah, sim. Tem mesmo cara de Db2.
08:25.
O gerente entra.
— Causa?
— Db2.
— Confirmado?
Silêncio.
— Ainda não.
Mas nesse ponto a palavra já havia se espalhado pela War Room.
HIPÓTESE:
DB2
virou mentalmente:
CAUSA:
DB2
Nosso programador abre mais métricas.
DB2 LOCK WAIT: NORMAL
DB2 CPU: NORMAL
DB2 THREADS: NORMAL
Enquanto isso:
DOWNSTREAM API RESPONSE:
12.4 SECONDS
Ele aponta.
— E isso?
O DBA responde:
— Deve ser efeito.
— De quê?
— Do Db2.
— Mas o Db2 está normal.
Silêncio.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se entre duas mesas.
A porta abre.
O Doctor sai.
Olha para o dashboard.
Depois para o DBA.
— Por que é Db2?
— Porque parece.
O Doctor ergue a sobrancelha.
— Excelente.
— Excelente?
— Sim.
— Por quê?
— Porque “parece” é uma das formas favoritas do cérebro humano de transformar semelhança em certeza.
Pausa.
— Um lobo pode parecer um cachorro.
Mais uma pausa.
— Isso não significa que você deveria tentar fazer carinho.
Bem-vindo ao:
Representativeness Heuristic
Ou:
Heurística da Representatividade
A tendência de julgar a probabilidade de algo com base no quanto esse algo se parece com um exemplo típico, um estereótipo, uma categoria conhecida ou um padrão mental que já possuímos.
Em linguagem Bellacosa:
“Tem cara de X, então deve ser X.”
E isso pode ser muito útil.
Até não ser.
🌀 Nossa TARDIS dos incidentes já percorreu uma galáxia inteira
Até aqui encontramos:
Swiss Cheese Model — várias barreiras imperfeitas podem falhar juntas.
Normalization of Deviance — desvios repetidos viram rotina.
Hindsight Bias — depois do incidente tudo parece óbvio.
Confirmation Bias — buscamos provas para aquilo que já acreditamos.
Anchoring Bias — a primeira explicação pesa demais.
Groupthink — grupos inteligentes podem errar juntos.
Authority Gradient — hierarquia pode transformar dúvida em silêncio.
Plan Continuation Bias — continuamos planos que já perderam sentido.
Alarm Fatigue — alertas demais viram ruído.
Automation Bias — confiamos demais na máquina.
Drift Into Failure — sistemas derivam lentamente para a borda.
Diffusion of Responsibility — todos veem e ninguém assume.
Normalcy Bias — acreditamos que tudo voltará ao normal.
Survivorship Bias — estudamos quem sobreviveu.
Base Rate Neglect — esquecemos a frequência real dos eventos.
Availability Heuristic — o que vem facilmente à memória parece mais provável.
Outcome Bias — bom resultado parece provar boa decisão.
Overconfidence Bias — acreditamos saber mais do que realmente sabemos.
Planning Fallacy — subestimamos tempo, esforço e complexidade.
Sunk Cost Fallacy — custo passado influencia demais a próxima decisão.
Status Quo Bias — o atual parece naturalmente mais seguro.
Present Bias — o conforto de hoje pesa mais que o custo de amanhã.
Optimism Bias — acreditamos que provavelmente tudo dará certo conosco.
Action Bias — agir parece melhor que esperar.
Omission Bias — não agir pode parecer menos culpável.
Loss Aversion — perder dói mais do que ganhar alegra.
Framing Effect — a forma de apresentar muda a decisão.
Recency Bias — o que aconteceu ontem recebe peso excessivo.
Agora chegamos a um mecanismo ainda mais básico:
nosso cérebro adora reconhecer padrões.
E ainda bem.
Sem isso, seria quase impossível trabalhar com sistemas complexos.
O problema aparece quando:
reconhecimento vira classificação prematura.
🧠 O que é uma heurística de representatividade?
Imagine que você vê:
um homem usando jaleco branco;
estetoscópio;
hospital.
Seu cérebro rapidamente pensa:
médico.
Faz sentido.
Você está usando:
características do exemplo
para associá-lo a uma categoria.
Isso é útil.
Muito útil.
Agora imagine:
ele é ator gravando publicidade.
O padrão parecia correto.
A categoria estava errada.
Essa é a armadilha.
☕ Bellacosa Mainframe: “tem cara de S0C7 clássico”
Você abre dump.
Programa terminou com:
S0C7
Seu cérebro pensa:
campo não numérico em operação decimal.
Excelente.
É uma hipótese forte.
Mas agora surge outro detalhe:
o erro ocorre após uma mudança de copybook.
Pode ser:
dados ruins;
layout incompatível;
offset errado;
overlay;
REDEFINES;
dados truncados.
O S0C7 “tem cara” de dado inválido.
Mas essa aparência não determina a origem do dado inválido.
🧠 Representatividade não é causalidade
Essa frase precisa ficar na parede:
Parecer com um padrão não prova que o mesmo mecanismo causou o evento.
Dois incidentes podem ter:
mesmo sintoma.
Mas causas completamente diferentes.
Exemplo:
TIMEOUT
pode ser:
Db2;
MQ;
rede;
API externa;
CPU;
thread pool;
deadlock;
aplicação.
O sintoma pertence a uma classe grande.
A heurística tende a procurar:
o membro mais prototípico.
👻 Easter Egg nº 1 — Cyberman ou funcionário de manutenção?
Companion:
— Doctor! Um Cyberman!
Doctor olha.
— Onde?
— Ali! Prateado! Capacete! Andando duro!
O Doctor observa.
— É um técnico de manutenção usando roupa térmica.
— Mas parecia tanto...
— Exatamente.
Pausa.
— O universo sobrevive porque às vezes esperamos mais cinco segundos antes de começar a gritar “Cyberman”.
🧠 Protótipos mentais
Nossa mente cria protótipos.
Por exemplo:
“incidente de Db2” pode ter:
locks;
timeouts;
transações esperando;
batch atrasado.
Então quando vemos:
timeouts;
espera;
lentidão,
pensamos:
Db2.
Mas talvez vários sistemas produzam a mesma assinatura superficial.
O problema não é possuir protótipo.
É esquecer que:
protótipo é atalho, não diagnóstico.
🧠 Representativeness Heuristic + Base Rate Neglect
Essa combinação é clássica.
Imagine:
apenas 5% dos incidentes de timeout são rede.
Mas o incidente atual possui uma característica “muito típica” de rede.
Nosso cérebro pode supervalorizar essa semelhança e esquecer:
95% historicamente vieram de outros lugares.
Base Rate Neglect diz:
esqueça a frequência.
Representativeness diz:
mas parece muito!
Resultado:
hipótese rara vira favorita.
📊 Exemplo Bellacosa
Histórico:
TIMEOUT INCIDENTS
DB2: 42%
APP: 30%
MQ: 15%
NETWORK: 8%
OTHER: 5%
Hoje:
timeouts + retransmissão.
Equipe:
rede!
Talvez.
Mas precisamos perguntar:
essa evidência é suficientemente específica para superar a taxa-base?
Se sim:
ótimo.
Se não:
a aparência está pesando demais.
🧠 Bayes volta pela porta dos fundos
Sem entrar em matemática pesada:
ANTES:
qual causa era mais provável?
DEPOIS:
o quanto essa evidência realmente favorece uma causa?
Representativeness Heuristic pula direto para:
“isso parece X.”
Pensamento melhor:
“isso parece X, mas X é comum neste contexto? E essa evidência discrimina X de Y e Z?”
☕ A diferença entre compatível e diagnóstico
Uma evidência pode ser:
compatível com Db2.
Isso não significa:
exclusiva de Db2.
Exemplo:
latência alta.
Compatível com:
quase tudo.
Então:
COMPATÍVEL
≠
DIAGNÓSTICO
Essa distinção salva War Rooms.
⚓ Representativeness + Anchoring Bias
O primeiro especialista diz:
— Parece Db2.
Pronto.
Agora temos:
representatividade criando hipótese;
anchoring prendendo investigação.
Outros dados passam a ser interpretados à luz do Db2.
🔎 Confirmation Bias entra logo depois
Agora buscamos:
lock;
SQL lenta;
thread.
Encontramos qualquer valor ligeiramente fora do normal.
— Viu?
Db2.
Enquanto:
API downstream está demorando 12 segundos.
A narrativa já foi escolhida.
👥 Groupthink transforma semelhança em consenso
Um DBA diz:
— Cara de Db2.
Outro:
— Também achei.
Aplicação:
— Realmente.
Agora:
três pessoas inteligentes concordando.
Mas talvez todas estejam usando o mesmo protótipo mental.
Groupthink não exige falta de inteligência.
Às vezes exige apenas:
modelos mentais compartilhados.
🪜 Authority Gradient
Especialista veterano:
— Já vi isso dezenas de vezes. É Db2.
Júnior observa:
MQ normal;
Db2 normal;
API ruim.
Mas pensa:
ele já viu muito mais que eu.
Silêncio.
Representatividade + experiência + autoridade.
Excelente maneira de matar uma hipótese alternativa.
🧠 Expertise é poderosa — mas também cria padrões fortes
O especialista desenvolve reconhecimento.
Isso geralmente melhora decisões.
Mas pode gerar:
pattern overreach
Quando um padrão conhecido é aplicado onde não cabe.
A pergunta útil:
“Quais elementos deste caso não combinam com o padrão anterior?”
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Tem cara de X.”
Pergunte:
“Quais características específicas fazem parecer X?”
Transforme sensação em evidência.
🎯 Pergunta Bellacosa nº 2
Depois:
“Essas características aparecem também em outras causas?”
Agora medimos poder discriminativo.
🎯 Pergunta Bellacosa nº 3
E:
“Qual evidência deveríamos ver se fosse realmente X?”
Muito útil.
🎯 Pergunta Bellacosa nº 4
Finalmente:
“Qual dado faria abandonarmos X?”
Se resposta:
nenhum,
não temos hipótese.
Temos casamento.
🧠 Representativeness Heuristic + Recency Bias
Nosso último capítulo entra imediatamente.
Último incidente:
Db2.
Novo incidente:
parece parecido.
Agora:
Recency:
aconteceu recentemente.
Representativeness:
tem a mesma cara.
Perfeito.
A primeira hipótese fica quase irresistível.
🧠 Availability Heuristic também
O caso de Db2 foi traumático.
Está fresco.
É fácil lembrar.
E o atual parece parecido.
Agora temos três vieses trabalhando juntos:
Recency;
Availability;
Representativeness.
War Room premium edition.
🧠 O problema das narrativas perfeitas
Às vezes um incidente parece “bom demais” para determinada explicação.
Sintomas encaixam.
Timeline encaixa.
Até o nome do componente parece suspeito.
Cuidado.
Histórias coerentes dão conforto.
Mas sistemas complexos podem produzir coincidências.
☕ O diagnóstico estilo House
House vê sintoma.
Hipótese.
Testa.
Falha.
Nova hipótese.
O que ele não deveria fazer?
“Tem cara de lúpus, logo é lúpus.”
Aliás, segundo a tradição:
nunca é lúpus.
Até quando é.
Esse é justamente o problema com protótipos.
🧪 Hypothesis Testing
Representatividade deveria gerar:
hipótese.
Depois:
teste.
Exemplo:
HYPOTHESIS:
DB2 LOCK CONTENTION
EXPECT:
- lock waits high
- blocking thread visible
- affected transactions share resource
Observamos.
Se não aparece:
probabilidade cai.
🧠 Falsificação é uma habilidade operacional
Não procure só:
“como provar que estou certo?”
Procure:
“como posso rapidamente provar que estou errado?”
Isso acelera investigação.
💻 COBOL: exemplo prático
S0C7.
Hipótese:
campo inválido.
Você verifica:
input.
Tudo numérico.
Então não diga:
“Mas S0C7 é campo inválido.”
Sim.
Mas talvez o programa esteja lendo campo errado.
Agora procure:
offset;
copybook;
REDEFINES;
overlay.
O protótipo estava parcialmente certo.
A explicação superficial não.
🧠 Pattern decomposition
Em vez de:
“É S0C7 clássico.”
Desmonte:
qual instrução abendou?
qual campo?
qual valor?
qual origem?
qual layout?
Quanto mais detalhes:
menos dependência de estereótipo.
🧪 Signature Matching
Compare incidentes por múltiplas dimensões:
SYMPTOM
TIMING
COMPONENT
METRIC
CHANGE
VOLUME
ERROR CODE
DEPENDENCY
Se apenas:
“timeout”
é igual,
não são necessariamente o mesmo incidente.
🧠 Similaridade superficial versus estrutural
Dois eventos podem ser superficialmente parecidos:
timeout.
Mas estruturalmente diferentes:
um por lock;
outro por retry storm.
Representativeness Heuristic frequentemente privilegia aparência superficial.
☕ Bellacosa: o job lento
Job A demorou 3 horas porque dataset cresceu.
Job B demora 3 horas.
Equipe:
dataset cresceu de novo.
Mas Job B tem mesmo volume.
CPU baixa.
I/O normal.
Na verdade espera recurso externo.
Mesmo tempo.
Outra causa.
🧠 Stereotyping tecnológico
Isso também aparece entre tecnologias.
Exemplo:
“Java consome memória.”
Então qualquer memória alta:
Java.
“Db2 é gargalo.”
Qualquer lentidão:
Db2.
“Mainframe é caro.”
Qualquer custo:
mainframe.
Esses rótulos podem virar representativeness heuristics organizacionais.
🧠 Legacy = velho = ruim?
Framing Effect já mostrou isso.
Representativeness acrescenta:
algo que possui características “de legado” pode ser classificado mentalmente como:
difícil;
caro;
obsoleto.
Mesmo sem medir.
Um sistema antigo pode ser excelente.
Um sistema novo pode ser péssimo.
Protótipo não decide.
☕ “Microserviço moderno”
Palavra moderna.
Docker.
Kubernetes.
API.
Então:
escalável.
Talvez.
Ou um monólito distribuído com Wi-Fi emocional.
Representatividade também funciona a favor do “novo”.
🧠 Shiny Object + Representativeness
Tecnologia parece com exemplos de empresas bem-sucedidas.
Logo:
se adotarmos, teremos resultados parecidos.
Não necessariamente.
Survivorship Bias entra.
Contexto importa.
🧠 Representativeness + Survivorship Bias
Você observa empresas de sucesso.
Todas usam arquitetura X.
Conclusão:
X parece “arquitetura de empresa bem-sucedida”.
Agora qualquer empresa usando X parece moderna.
Mas onde estão:
empresas usando X que falharam?
Survivorship Bias esconde.
Representativeness transforma características dos sobreviventes em receita.
🧠 Startup uniform
É quase caricatura:
cloud;
microservice;
React;
Kubernetes;
AI.
Parece startup moderna.
Mas aparência arquitetural não garante:
unit economics;
produto;
confiabilidade.
O cérebro adora pacotes reconhecíveis.
📊 Correlation ≠ category certainty
Representatividade pode exagerar correlação.
Se muitos casos de fraude possuem comportamento X:
vemos X
e pensamos:
fraude.
Mas talvez milhões de casos legítimos também tenham X.
Base Rate de novo.
🏦 Fraude bancária
Transação:
valor alto;
novo dispositivo;
horário incomum.
“Tem cara de fraude.”
Pode ser.
Mas:
quantas transações legítimas têm essas características?
Sem isso:
heurística domina.
🔐 Segurança
Login de país diferente.
Parece ataque.
Talvez VPN.
Parece credential stuffing.
Talvez cliente viajando.
Threat detection precisa combinar sinais.
Não estereótipo.
🤖 IA e Representativeness
Modelos classificadores literalmente trabalham com padrões.
Mas humanos podem interpretar score como:
“parece malware, então é malware.”
Precisamos:
precision;
recall;
base rates;
explainability.
Automation Bias pode amplificar Representativeness.
🧠 “AI says it looks like...”
Ferramenta:
SIMILARITY TO INCIDENT CLASS:
92%
Pergunta:
semelhança em quê?
Sintomas?
Logs?
Causa?
Contexto?
Similarity não é causalidade.
🔍 Embeddings e similaridade
Em sistemas de busca por embeddings:
dois incidentes podem estar próximos semanticamente.
Útil.
Mas proximidade vetorial não significa:
mesma root cause.
Representativeness automatizada ainda precisa de validação.
☕ RAG operacional
Você consulta incidentes similares.
Os top 5 eram Db2.
IA conclui:
Db2.
Talvez retrieval trouxe apenas casos semanticamente parecidos, não estatisticamente representativos.
Pergunte:
qual universo?
qual taxa-base?
quais casos alternativos?
🧠 Framing + Representativeness
Título:
“Possible database bottleneck.”
Pronto.
Toda leitura passa por frame de database.
Visual + protótipo.
Cuidado com labels prematuros.
🧠 Label Leakage
Se dashboard diz:
DATABASE INCIDENT
antes de RCA,
a classificação vira influência.
Melhor:
SYMPTOM:
TRANSACTION LATENCY
Até confirmar.
☕ Sintoma não é causa
Uma das regras principais desta série:
TIMEOUT = SINTOMA
SLOW = SINTOMA
ABEND = SINTOMA
QUEUE = SINTOMA
Causa precisa ser investigada.
🧠 Diagnostic overshadowing
Quando um rótulo conhecido domina análise, outros sinais podem ser ignorados.
Em TI:
“É problema de performance.”
Tudo passa a ser performance.
Mas talvez seja integridade.
Classificação ampla demais pode esconder detalhes.
🧪 Competing Hypotheses
Defesa poderosa:
não mantenha uma hipótese.
Mantenha algumas.
Exemplo:
H1 DB2
H2 DOWNSTREAM API
H3 MQ
Para cada:
evidência a favor;
evidência contra.
📊 Hypothesis Table
H1 DB2
FOR:
timeout
AGAINST:
lock wait normal
H2 API
FOR:
response 12s
AGAINST:
only one endpoint affected
H3 MQ
FOR:
retries
AGAINST:
queue depth normal
Agora “parece” perde poder mágico.
🧠 Representativeness + Action Bias
Algo parece Db2.
Ação:
restart pool.
Ainda nem confirmamos.
Action Bias transforma padrão mental em intervenção.
Perigoso.
🧠 Omission Bias também
Algo “não parece grave”.
Então não agimos.
Representatividade pode classificar erroneamente severidade.
Exemplo:
alerta parece falso positivo habitual.
Mas desta vez não é.
🔔 Alarm Fatigue
Alertas falsos repetidos criam protótipo:
esse alerta = ruído.
Novo alerta real chega.
Parece igual.
Representativeness + Alarm Fatigue.
Muito perigoso.
🧠 Normalcy Bias
Sintoma parece com pequenas instabilidades anteriores.
Então:
vai passar.
O protótipo “incidente leve” vence sinais de escalada.
🌀 Drift Into Failure
Mudanças graduais parecem com operação normal.
Porque cada ponto individual ainda pertence ao protótipo:
“normal.”
Mas tendência saiu da zona segura.
Representatividade pode ocultar drift ao comparar cada momento com um estereótipo fixo.
📈 Distribution Shift
Sistema mudou.
Mas nosso protótipo mental não.
Agora classificamos eventos novos usando categorias antigas.
Esse é um problema importante.
🧠 Concept Drift
Em machine learning existe ideia de concept drift:
a relação entre sinais e classes pode mudar ao longo do tempo.
Em operação:
o que significava timeout em arquitetura antiga pode ser diferente na nova.
Protótipos precisam ser atualizados.
☕ História precisa de versionamento
“Esse alerta sempre significa X.”
Sempre em qual versão?
Antes ou depois da migração?
Antes ou depois do novo fornecedor?
Contexto importa.
🎯 Pergunta Bellacosa nº 5
“Nosso padrão mental ainda representa o sistema atual?”
Excelente para veteranos.
🧠 Representatividade social
O viés também pode aparecer na avaliação de pessoas.
“Programador COBOL veterano” parece:
conservador.
“Dev jovem” parece:
inovador.
Talvez.
Talvez não.
Estereótipos são representativeness heuristics aplicadas a gente.
Em equipes:
isso pode distorcer contratação, promoção e distribuição de trabalho.
🧠 Não transforme arquétipo em pessoa
Um júnior pode perceber algo que veterano não viu.
Veterano pode dominar nova tecnologia.
Categoria não determina indivíduo.
Em incidentes:
ouça evidência.
Não crachá.
👥 Authority Gradient + Representatividade de papel
“DBA entende banco.”
Sim.
“Então opinião do DBA sobre qualquer problema de banco é automaticamente correta.”
Não.
Expertise aumenta peso da hipótese.
Não elimina validação.
☕ O título não compila código
Nem badge.
Nem cargo.
Nem barba branca.
Embora barba branca ajude bastante na aparência de sysprog lendário.
🧠 Story coherence
Representativeness Heuristic gosta de histórias coerentes.
Se:
sistema lento;
Db2 conhecido por lock;
DBA recentemente ajustou índice,
pronto:
temos novela.
Mas talvez mudança real tenha sido API externa.
Histórias plausíveis não são evidência.
📚 Sherlock Holmes operacional
O objetivo não é:
achar explicação plausível.
É:
achar explicação que sobreviva aos fatos melhor que as alternativas.
🧪 Differential Diagnosis
Medicina usa diagnóstico diferencial.
TI deveria usar mais.
Sintoma:
timeout.
Diferenciais:
Db2;
MQ;
rede;
API;
aplicação;
storage.
Depois elimina.
Isso é muito House MD.
☕ House entra na TARDIS
House olha para o monitor.
— Db2.
Doctor:
— Evidência?
— Parece.
Doctor:
— Isso não é evidência.
House:
— Todo mundo mente.
Doctor:
— Inclusive heurísticas.
Agora precisamos de outra série.
🧠 Triage versus RCA
Representatividade é ótima para:
triagem.
Preciso começar em algum lugar.
Use padrão.
Mas RCA exige:
prova mais forte.
Regra:
Heurística escolhe onde olhar primeiro. Evidência decide onde parar.
Essa talvez seja a frase do capítulo.
📊 Confidence Levels
Diga:
HYPOTHESIS:
DB2
CONFIDENCE:
40%
REASON:
symptom similarity
NEXT TEST:
lock analysis
Muito melhor que:
“É Db2.”
🧠 Language matters
Palavras:
“parece”;
“provavelmente”;
“confirmado”
precisam ser diferentes.
War Room madura usa níveis de certeza.
📝 Evidence Ladder
SUSPEITA
↓
HIPÓTESE
↓
EVIDÊNCIA FORTE
↓
CONFIRMADO
Não pule degraus.
☕ “Provavelmente” não vira “confirmado” por repetição
Se cinco pessoas repetem:
provavelmente Db2,
não temos cinco evidências.
Temos uma hipótese repetida cinco vezes.
Importante.
👥 Independent assessment
Antes de compartilhar hipótese dominante:
peça análise independente.
DBA.
Aplicação.
Middleware.
Depois compare.
Isso reduz contágio mental.
🧠 Representativeness + Groupthink contamination
Uma pessoa fala cedo:
Db2.
Agora outras análises ficam enviesadas.
Talvez faça sentido coletar primeiras impressões separadamente.
🎯 Silent Start
Primeiros cinco minutos:
cada especialista anota:
hipótese;
evidência.
Depois compartilha.
Excelente técnica.
🧪 How to combat Representativeness Heuristic
Passo 1 — Nomeie o padrão percebido
“Parece com X.”
Passo 2 — Explique por quê
Quais sinais?
Passo 3 — Verifique taxa-base
X é comum?
Passo 4 — Procure causas alternativas
Pelo menos duas.
Passo 5 — Procure evidência discriminante
O que separa X de Y?
Passo 6 — Procure evidência contrária
O que não combina?
Passo 7 — Compare contexto
Versão?
Volume?
Mudanças?
Passo 8 — Use histórico estruturado
Não apenas casos memoráveis.
Passo 9 — Atualize confiança
Com dados.
Passo 10 — Só então classifique
Sintoma primeiro.
Causa depois.
📋 Checklist anti-Representativeness Heuristic
[ ] Estou dizendo “tem cara de X”?
[ ] Quais sinais exatamente lembram X?
[ ] Esses sinais também aparecem em outras causas?
[ ] Qual é a taxa-base de X?
[ ] Tenho evidência específica ou só semelhança?
[ ] O último incidente está influenciando?
[ ] Existem dados que contradizem X?
[ ] Qual hipótese alternativa explica os mesmos sinais?
[ ] O sistema mudou desde o padrão original?
[ ] Estou confundindo sintoma com causa?
[ ] A ferramenta mostrou similaridade ou causalidade?
[ ] Estamos usando estereótipo tecnológico?
[ ] Estamos classificando pessoa pela função em vez da evidência?
[ ] Que teste poderia falsificar nossa hipótese?
🧠 Curiosidade: Linda Problem
Existe um experimento clássico da psicologia associado a Kahneman e Tversky.
Pessoas recebem descrição detalhada de uma personagem chamada Linda, com características que parecem combinar com determinado perfil.
Depois avaliam quais afirmações parecem mais prováveis.
Muitas pessoas escolhem uma opção mais específica porque ela parece mais representativa da descrição, mesmo violando regras básicas de probabilidade.
A lição:
uma história que combina muito bem com um estereótipo pode parecer mais provável que uma opção estatisticamente mais simples.
Isso é profundamente relevante para RCA.
☕ O incidente “bonito demais”
Hipótese:
ataque sofisticado.
Sintomas:
estranhos.
Narrativa:
perfeita.
Mas base rate:
quase zero.
Enquanto:
erro de configuração
é cem vezes mais comum.
O cérebro gosta da história interessante.
Produção gosta da causa real.
🧠 Narrative Bias no horizonte
Nosso cérebro ama histórias.
Talvez um futuro capítulo.
Porque histórias coerentes competem bem contra estatística.
Representativeness é um ingrediente.
🔐 Cybersecurity e “cara de APT”
Comportamento sofisticado.
Alguém:
“Parece APT.”
Talvez.
Mas ransomware comum também pode produzir sinais parecidos.
Não escale narrativa antes da evidência.
🧠 Attribution escalation
Primeiro:
anomalia.
Depois:
ataque.
Depois:
APT.
Depois:
nação-estado.
Tudo em 12 minutos.
War Room cinematográfica.
Talvez seja certificado expirado.
☕ O universo frequentemente é menos glamouroso
Você espera:
hacker internacional.
Encontra:
senha vencida.
Você espera:
corrupção de storage.
Encontra:
dataset full.
Você espera:
bug quântico.
Encontra:
campo PIC errado.
Isso é saudável.
💻 COBOL e o poder da banalidade
Muitas falhas são:
dados;
layout;
índice;
campo;
condição.
Não subestime o banal só porque o caso parece dramático.
Base rates gostam de banalidade.
🧠 Occam versus Representativeness
Navalha de Occam não significa:
“sempre escolha causa simples.”
Mas recomenda não multiplicar hipóteses desnecessariamente.
Representativeness pode levar a causa cinematográfica porque encaixa num padrão memorável.
Occam pergunta:
precisamos mesmo disso tudo?
📊 Pareto de causas
Mantenha Pareto.
Exemplo:
80% de S0C7 vêm de três classes.
Então comece por elas.
Mas não pare nelas se evidência contradiz.
🧠 Frequency + Fit
Uma forma simples de priorizar hipótese:
frequência histórica + compatibilidade atual.
Não apenas:
compatibilidade visual.
☕ Bellacosa Hypothesis Score
Brincando:
SCORE =
BASE RATE
+
CURRENT EVIDENCE
+
CONTEXT MATCH
-
CONTRARY EVIDENCE
Não precisa virar fórmula matemática literal.
Mas a mentalidade ajuda.
🤖 IA e classificações
Um agente pode dizer:
87% similar to incident DB2-2025-017.
Humano precisa perguntar:
por que?
que campos?
quais diferenças?
qual confiança histórica?
existem outras classes próximas?
Similarity score é ponto de partida.
🧠 Explainability operacional
Uma boa ferramenta deveria dizer:
SIMILAR BECAUSE:
- same error code
- same wait pattern
- same application
DIFFERENT BECAUSE:
- DB2 locks normal
- new API dependency
Isso é muito mais útil que:
“Likely DB2.”
🔎 Retrieval diversity
Se sistema RAG só traz cinco casos parecidos de Db2:
IA ficará presa.
Busque:
casos semelhantes com causas diferentes.
Contraexemplos são valiosos.
🧠 Contrastive Search
Pergunte:
“Mostre incidentes com estes mesmos sintomas que NÃO eram Db2.”
Fantástico.
Isso combate Representativeness + Confirmation.
🎯 Bellacosa AI Prompt
“Quais causas diferentes podem produzir esta mesma assinatura superficial?”
Uma das melhores perguntas para IA operacional.
🧠 False Friends dos incidentes
Como palavras parecidas em idiomas que significam coisas diferentes.
Sintomas também possuem falsos amigos.
“Timeout” parece igual.
Mas mecanismo muda.
“High CPU” parece causa.
Talvez seja consequência.
“Queue depth” parece gargalo.
Talvez seja efeito.
Nunca se apaixone pela aparência.
🧬 Regeneração organizacional
Uma organização madura contra Representativeness Heuristic aprende a:
separar sintoma de causa;
registrar taxas-base;
manter históricos comparáveis;
usar hipóteses concorrentes;
procurar contraexemplos;
exigir evidência discriminante;
controlar linguagem de certeza;
revisar padrões após mudanças de arquitetura;
e tratar similaridade de IA como auxílio, não veredito.
Principalmente:
ela aprende que:
“parece” é uma excelente maneira de começar uma investigação e uma péssima maneira de encerrá-la.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Representativeness Heuristic é a tendência de julgar probabilidade pela semelhança com um padrão conhecido.
Parecer com uma causa não prova que seja essa causa.
Sintomas semelhantes podem surgir de mecanismos diferentes.
Base Rate Neglect torna a heurística mais perigosa quando ignoramos a frequência real.
Recency e Availability podem tornar um padrão recente mais representativo mentalmente do que ele realmente é.
Anchoring transforma a primeira classificação em prisão.
Confirmation Bias começa a procurar provas para o padrão escolhido.
Especialistas também sofrem porque expertise cria protótipos muito fortes.
Similaridade de IA, embeddings ou casos passados não é causalidade.
Contraexemplos e hipóteses concorrentes são antídotos poderosos.
A heurística é ótima para triagem; RCA exige evidência.
E principalmente:
Use padrões para saber onde olhar. Use evidências para decidir o que realmente está acontecendo.
🕰️ De volta às 08:17
War Room.
Dashboard:
TIMEOUT +190%
DBA:
— Db2.
Nosso programador responde:
— Pode ser.
— Você não acha?
— Acho possível.
Ele abre uma tabela:
H1 DB2
FOR:
timeouts
AGAINST:
locks normal
CPU normal
H2 API
FOR:
response 12.4s
same timeline
AGAINST:
only some transactions
H3 MQ
FOR:
retry increase
AGAINST:
queue depth normal
O Doctor sorri.
— Agora sim.
O DBA olha para a API.
Descobrem:
um fornecedor externo havia implantado mudança às 08:00.
Resposta passou de:
300ms
para:
12 segundos.
O sistema interno estava esperando.
Db2 estava apenas acumulando transações.
Consequência.
Não causa.
O DBA ri.
— Mas parecia muito com Db2.
Nosso programador responde:
— Parecia.
O Doctor completa:
— Um bom disfarce só precisa parecer verdadeiro tempo suficiente.
🥚 Easter Egg final
Na manhã seguinte surge:
BELLACOSA.BIAS(REPRESENT)
Dentro:
IF CURRENT-CASE
LOOKS-LIKE KNOWN-PATTERN
PERFORM CHECK-BASE-RATE
PERFORM CHECK-ALTERNATIVES
END-IF.
IF SIMILARITY = HIGH
AND EVIDENCE = LOW
MOVE 'HYPOTHESIS'
TO CLASSIFICATION
END-IF.
IF CONTRARY-EVIDENCE > ZERO
PERFORM UPDATE-BELIEF
END-IF.
Comentário:
* LOOKS-LIKE IS NOT IS.
Outro:
* SIMILARITY STARTS THE SEARCH.
* EVIDENCE ENDS IT.
Mais um:
* A TIMEOUT HAS MANY PARENTS.
E naturalmente:
* BAD WOLF LOOKED VERY REPRESENTATIVE.
* THAT WAS PART OF THE PROBLEM.
Nosso jovem fecha o membro.
Pouco depois alguém chama:
— Temos S0C7. Dado inválido.
Ele responde:
— Provavelmente.
— Provavelmente?
— Qual instrução?
— Ainda não vimos.
— Então temos um S0C7.
— E?
— Primeiro descrevemos o que sabemos.
Pausa.
— Depois deixamos o sistema nos contar por quê.
Abrem o dump.
Não era input ruim.
Copybook antigo.
Offset deslocado.
O S0C7 tinha perfeitamente a aparência do padrão conhecido.
Mas a causa estava escondida um nível abaixo.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica uma última frase:
A semelhança é uma pista. A frequência dá contexto. A evidência decide.
E talvez essa seja a grande lição da Representativeness Heuristic:
não abandone seus padrões mentais — apenas impeça que eles tenham permissão para encerrar a investigação antes dos dados.
☕🌀
Next stop: Narrative Bias — quando uma história bem contada parece tão coerente que passamos a preferi-la a uma explicação mais feia, mais banal e muito melhor sustentada pelos dados.
