 |
| Bellacosa Mainframe e a recency bias |
☕ Um Café no Bellacosa Mainframe
Recency Bias: Doctor Who, COBOL e o Dia em que o Incidente de Ontem Virou a Verdade de Hoje
Uma viagem pela TARDIS dos incidentes para entender por que acontecimentos recentes podem pesar mais que todo o histórico — e como isso distorce diagnósticos, prioridades e decisões em sistemas críticos
07:58.
Segunda-feira.
Primeiro café.
Produção aparentemente tranquila.
Na sexta-feira anterior, porém, o mundo quase acabara.
Ou pelo menos parecia.
Uma região CICS havia apresentado lentidão.
A fila MQ crescera.
Clientes reclamaram.
A War Room ficara aberta por quatro horas.
Finalmente descobriram:
ROOT CAUSE:
MQ CONSUMER STALLED
O incidente foi resolvido.
Post-mortem marcado.
Fim de semana.
Segunda-feira.
08:03.
Novo alerta:
PAYMENT RESPONSE TIME
ABOVE BASELINE
O operador olha.
— MQ.
Nosso jovem programador COBOL pergunta:
— Já verificou?
— Não precisa.
— Como assim?
— É igual sexta.
08:05.
Outro alerta:
TRANSACTION TIMEOUT RATE: +180%
DBA entra.
— O que temos?
— MQ de novo.
08:07.
Middleware é acionado.
08:09.
Alguém sugere reiniciar consumer.
Nosso jovem programador olha para o dashboard:
MQ QUEUE DEPTH: NORMAL
Mas encontra:
DB2 LOCK WAIT: +720%
Ele pergunta:
— E esses locks?
O operador responde:
— Deve ser consequência.
— De quê?
— Do MQ.
— Mas o MQ está normal.
Silêncio.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado da impressora.
A porta abre.
O Doctor sai.
Olha para o gráfico.
Depois para o operador.
— Qual foi a causa do incidente anterior?
— MQ.
— Quando?
— Sexta.
— E quantos incidentes semelhantes vocês tiveram no último ano?
Silêncio.
Alguém abre o histórico.
ULTIMOS 120 INCIDENTES DE LENTIDÃO
DB2: 46
APLICAÇÃO: 31
REDE: 17
MQ: 14
STORAGE: 8
OUTROS: 4
O Doctor aponta.
— Então MQ representa 14 casos.
— Sim.
— E porque aconteceu sexta-feira...
Pausa.
— hoje vocês decidiram tratá-lo como se representasse cento e vinte?
Silêncio.
Nosso programador sorri.
O Doctor continua:
— O passado recente tem uma habilidade curiosa.
— Qual?
Fingir que é o passado inteiro.
Bem-vindo ao:
Recency Bias
Ou:
Viés de Recência
A tendência de dar peso excessivo a informações, eventos ou experiências recentes ao tomar decisões, subestimando dados mais antigos — mesmo quando o histórico completo é mais representativo.
Em linguagem Bellacosa:
“Aconteceu ontem, então deve estar acontecendo de novo.”
🌀 A TARDIS dos incidentes já tem um bestiário respeitável
Nossa viagem até aqui encontrou:
Swiss Cheese Model — várias barreiras podem falhar juntas.
Normalization of Deviance — desvios viram rotina.
Hindsight Bias — depois do incidente tudo parece óbvio.
Confirmation Bias — buscamos evidências para aquilo em que já acreditamos.
Anchoring Bias — a primeira informação pesa demais.
Groupthink — grupos convergem cedo demais.
Authority Gradient — hierarquia pode transformar dúvida em silêncio.
Plan Continuation Bias — continuamos mesmo quando deveríamos parar.
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 — esperamos que tudo volte ao normal.
Survivorship Bias — estudamos apenas quem sobreviveu.
Base Rate Neglect — ignoramos a frequência real dos eventos.
Availability Heuristic — aquilo que lembramos facilmente parece mais provável.
Outcome Bias — resultado bom parece provar boa decisão.
Overconfidence Bias — acreditamos que sabemos mais do que realmente sabemos.
Planning Fallacy — subestimamos tempo, esforço e complexidade.
Sunk Cost Fallacy — custos passados influenciam decisões futuras.
Status Quo Bias — manter parece naturalmente mais seguro.
Present Bias — o conforto de hoje pesa mais que o custo de amanhã.
Optimism Bias — acreditamos que o resultado provavelmente será favorável.
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 maneira de apresentar a informação muda a decisão.
Agora o cérebro faz outro truque:
ele pega o que aconteceu recentemente e aumenta artificialmente sua importância.
🧠 O que é Recency Bias?
Imagine dez eventos.
A B C D E F G H I J
O evento J aconteceu ontem.
Nossa mente tende a lembrar melhor dele.
Quando pergunta:
“O que costuma acontecer?”
podemos responder usando:
J.
Mesmo que:
A até I
contem história diferente.
Recency Bias é essencialmente um problema de peso temporal.
Eventos recentes recebem peso maior que sua representatividade real.
☕ Bellacosa Mainframe: “foi DB2 da última vez”
Incidente de ontem:
Db2 lock.
Hoje:
timeout.
Especialista:
— É Db2.
Por quê?
— Ontem foi.
Isso é hipótese razoável para começar?
Sim.
É diagnóstico?
Não.
Recency Bias aparece quando:
a proximidade temporal é tratada como evidência causal.
🧠 Recency Bias versus Availability Heuristic
Os dois são próximos.
Mas não exatamente iguais.
Availability Heuristic
Algo parece mais provável porque vem facilmente à memória.
Pode ser recente, dramático, famoso ou emocional.
Recency Bias
Algo recebe peso extra especificamente porque aconteceu recentemente.
Todo Recency Bias pode tornar algo cognitivamente disponível.
Mas nem toda Availability Heuristic é recência.
Exemplo:
um acidente aéreo famoso de vinte anos atrás pode ser muito disponível sem ser recente.
👻 Easter Egg nº 1 — o Dalek de ontem
Companion:
— Doctor, há um barulho metálico atrás daquela porta.
— O que acha que é?
— Dalek.
— Por quê?
— Vimos um ontem.
— E antes de ontem?
— Cybermen.
— E na semana passada?
— Uma máquina de venda automática.
Doctor:
— Talvez devêssemos abrir a porta antes de declarar guerra interplanetária.
Recency Bias.
🧠 O cérebro gosta de atualizar rapidamente
Isso não é inteiramente ruim.
Se o ambiente mudou ontem, dados recentes podem ser mais relevantes.
Exemplo:
nova versão implantada.
Novo comportamento aparece.
Nesse caso:
últimas horas podem dizer mais que últimos cinco anos.
Ou seja:
recência pode ser sinal legítimo.
O problema é usar recência automaticamente.
Precisamos perguntar:
o sistema mudou de regime?
📊 Regime Change
Imagine histórico:
2024–2025:
DB2 causa 40% dos incidentes
Após migração de 2026:
MQ causa 55%
Agora histórico antigo talvez seja menos útil.
Recency Bias seria:
usar os últimos dois casos apenas.
Mas usar dados recentes após mudança estrutural pode ser correto.
A pergunta:
houve mudança que torna o passado menos representativo?
☕ Versão nova muda base rate
Deploy de nova arquitetura na semana passada.
Desde então:
quatro falhas de MQ.
Talvez isso seja sinal.
Não porque são recentes apenas.
Mas porque:
compartilham uma mudança causal recente.
Essa distinção é importante.
🧠 Recência precisa de contexto
Pergunte:
versão mudou?
volume mudou?
configuração mudou?
fornecedor mudou?
tráfego mudou?
arquitetura mudou?
Se sim:
recent data ganha relevância racional.
Se não:
talvez estejamos só impressionados pelo último incidente.
📈 Base Rate Neglect volta imediatamente
Último incidente:
rede.
Histórico:
rede em 5%.
Recency Bias:
“é rede de novo.”
Base Rate Neglect:
esquece os 5%.
Os dois juntos transformam:
um evento recente
em:
probabilidade imaginária.
🧠 Bayesian update bem feito
O correto não é ignorar o evento recente.
É atualizar.
Antes:
rede 5%.
Novo evento recente de rede após mudança de firewall:
isso pode aumentar probabilidade.
Mas precisa haver conexão.
Em linguagem Bellacosa:
HISTÓRICO
+
MUDANÇA RECENTE
+
EVIDÊNCIA ATUAL
=
HIPÓTESE ATUALIZADA
Não:
ACONTECEU ONTEM
=
É ISSO HOJE
⚓ Recency Bias + Anchoring Bias
Segunda-feira.
Primeiro comentário:
“Igual sexta.”
Agora temos âncora.
A recência fornece conteúdo.
Anchoring prende investigação.
🔎 Confirmation Bias entra depois
Equipe procura:
timeouts;
retries;
qualquer mensagem MQ.
Ignora:
DB2 lock wait.
Agora a história recente começou a recriar a si mesma.
👥 Groupthink
Todos participaram do incidente de sexta.
Todos lembram.
Uma memória coletiva forte surge.
Um fala:
— MQ.
Outro:
— Também acho.
Terceiro:
— Parece mesmo.
Agora a sala inteira está investigando sexta-feira em plena segunda-feira.
🪜 Authority Gradient
O veterano que resolveu sexta diz:
— É MQ.
A frase possui força adicional porque:
ele estava certo recentemente.
O júnior pensa:
“Ele acabou de resolver exatamente isso.”
E cala.
Recency Bias amplifica autoridade recente.
🏆 Hot Hand Effect
Existe um conceito relacionado:
Hot Hand Fallacy.
A ideia de acreditar que alguém em sequência de sucessos continuará acertando porque está “quente”.
Em operação:
especialista acertou últimos três RCA.
Então:
“Se ele disse storage, deve ser storage.”
Talvez.
Mas acertos recentes podem gerar confiança excessiva.
Overconfidence entra.
🧠 Outcome Bias + Recency
Última ação funcionou.
Restart MQ.
Resultado bom.
Agora novo incidente:
restart MQ.
O resultado recente pesa.
Outcome Bias interpreta ação como correta.
Recency Bias traz essa solução para o topo da mente.
Action Bias executa.
Excelente combo.
☕ Runbook escrito pelo último incidente
Isso acontece muito.
Incidente A.
Pós-mortem.
Criamos dez controles específicos para A.
Incidente B vem de outro lugar.
Mas nossa organização está preparada brilhantemente para repetir A.
Isso é:
fighting the last war.
🧠 Fighting the Last War
Expressão usada para descrever organizações que se preparam excessivamente para o conflito anterior.
Em TI:
último incidente foi certificado.
De repente:
todos os checks são de certificado.
Próximo:
storage.
Depois storage vira obsessão.
Precisamos aprender:
classes de falha, não apenas instâncias.
🧩 Instance versus Pattern
Incidente recente:
MQ consumer parou.
Instance.
Pattern maior:
dependência downstream sem capacidade de auto-recovery.
Se aprendermos só:
“monitorar consumer X”
protegemos um caso.
Se aprendermos:
“detectar perda de consumo em qualquer downstream”
protegemos uma classe.
Isso reduz Recency Bias.
🧠 Availability Heuristic novamente
Incidentes recentes também são mais fáceis de lembrar porque:
estão emocionalmente vivos.
Logo Recency Bias e Availability frequentemente se misturam.
A defesa:
histórico estruturado.
💾 Mainframe adora histórico
Temos ferramentas excelentes:
SMF.
RMF.
Db2 statistics.
CICS statistics.
MQ metrics.
Scheduler history.
Syslog.
Use.
A memória humana não deveria competir sozinha contra SMF.
☕ O SMF não tem memória afetiva
Operador:
— Tenho certeza que isso começou depois da última mudança.
SMF:
“Começou três semanas antes.”
Obrigado, SMF.
📊 Rolling Windows
Uma boa prática:
compare janelas.
Última hora.
24h.
7 dias.
30 dias.
90 dias.
Isso mostra se evento recente é:
anomalia;
tendência;
padrão.
🧠 Uma janela só cria uma narrativa
Se dashboard mostra apenas:
15 minutos,
você vê ruído.
Se mostra:
1 ano,
pode esconder incidente atual.
Então:
use múltiplas escalas temporais.
📈 Short-term versus Long-term View
Exemplo:
LAST 30 MIN:
CPU +20%
Parece grave.
LAST 30 DAYS:
same pattern every Monday 08:00
Talvez normal.
Ou inverso:
TODAY:
CPU 82%
Parece normal.
6 MONTH TREND:
55 → 82%
Drift.
A escala temporal muda conclusão.
🌀 Drift Into Failure e Recency Bias
Drift é lento.
Recency Bias olha recente.
Isso pode fazer equipe perder tendência longa.
Exemplo:
última semana estável.
Conclusão:
tudo bem.
Mas seis meses:
margem caiu 40%.
Recência pode esconder deterioração estrutural.
🧠 Normalcy Bias
Últimos dias foram tranquilos.
Então:
sistema está saudável.
Mas tranquilidade recente não apaga sinais estruturais.
Normalcy Bias usa recência favorável para reforçar expectativa de continuidade.
🔔 Alarm Fatigue
Últimos cem alertas eram falsos positivos.
Hoje alerta real.
Recency Bias:
os últimos eram falsos, este também deve ser.
Alarm Fatigue + Recency.
Perigoso.
🧠 Automation Bias
Ferramenta de RCA foi correta nos últimos cinco incidentes.
Equipe aumenta confiança.
Novo caso:
ferramenta erra.
A sequência recente criou confiança excessiva.
Automation Bias + Hot Hand + Recency.
💻 COBOL e o último bug
Você corrigiu três S0C7 causados por campo packed inválido.
Quarto S0C7 aparece.
Você pensa:
packed inválido.
Excelente hipótese inicial.
Mas dump mostra:
overlay.
Se insiste no padrão recente:
Recency Bias.
🧠 Pattern Recognition é bom
Precisamos ser justos.
Especialistas sobrevivem graças a reconhecimento de padrões.
A meta não é ignorar experiência recente.
É:
tratar experiência recente como hipótese prioritária, não como exclusão das outras.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“É igual ao último incidente.”
Pergunte:
“O que exatamente é igual?”
Sintoma?
Métrica?
Causa?
Contexto?
🎯 Pergunta Bellacosa nº 2
Outra:
“O histórico de 100 casos concorda com os últimos dois?”
🎯 Pergunta Bellacosa nº 3
Outra:
“O ambiente mudou recentemente a ponto de justificar dar mais peso aos dados novos?”
Excelente.
🎯 Pergunta Bellacosa nº 4
E:
“Estamos vendo tendência ou apenas uma sequência curta?”
🧪 Como combater Recency Bias
Passo 1 — Consulte histórico antes de concluir
Não apenas memória.
Passo 2 — Use múltiplas janelas temporais
Agora.
Dia.
Semana.
Mês.
Ano.
Passo 3 — Separe incidente recente de padrão histórico
Documente.
Passo 4 — Verifique mudanças de regime
Versão?
Volume?
Arquitetura?
Passo 5 — Use base rates
Sempre.
Passo 6 — Compare assinatura técnica
Não sensação.
Passo 7 — Procure contraexemplos
Casos recentes diferentes.
Passo 8 — Evite alterar controles apenas pelo último incidente
Generalize.
Passo 9 — Use revisão periódica
Não apenas post-mortem imediato.
Passo 10 — Deixe a evidência nova atualizar, não apagar, o histórico
Essa é a chave.
📊 Incident Distribution Board
Em uma War Room:
SYMPTOM:
Timeout
LAST INCIDENT:
MQ
LAST 30:
DB2 12
APP 8
MQ 4
NETWORK 3
OTHER 3
CURRENT EVIDENCE:
DB2 lock ↑
MQ normal
Excelente.
A recência ficou visível.
Mas não dominante.
🧠 Weighted History
Nem sempre todos os dados históricos devem ter peso igual.
Dados de cinco anos atrás podem ser pouco relevantes.
Podemos dar mais peso a dados recentes de forma controlada.
O problema é dar:
100% ao último caso.
☕ Uma espécie de média móvel cognitiva
Pense:
histórico inteiro.
Mais peso recente.
Mas não zero para passado.
Quase como uma média móvel.
O cérebro faz isso intuitivamente.
Engenharia precisa calibrar.
📉 Exponential Decay — conceito útil
Em alguns modelos, dados antigos recebem peso progressivamente menor.
Isso pode ser válido.
Mas o fator de decaimento deve refletir quanto sistema muda.
Se arquitetura é estável:
histórico antigo ainda importa.
Se mudou drasticamente:
recente pesa mais.
🧠 Change Rate determines Memory Length
Regra interessante:
quanto mais rápido o sistema muda, menor pode ser a meia-vida do histórico.
Em uma aplicação COBOL estável há 20 anos:
dados antigos podem continuar relevantes.
Em serviço recém-reescrito:
últimos meses importam muito.
🧪 Post-change Baseline
Após grande mudança:
crie novo baseline.
Não misture cegamente histórico pré e pós mudança.
Isso reduz confusão.
🧠 Base Rate precisa ter versão
Taxa-base de:
v1.
Pode não ser taxa-base de:
v2.
Mantenha contexto de release.
☕ Bellacosa Mainframe: antes e depois do upgrade
Antes:
DB2 CONTENTION: 5%
Depois de upgrade/configuração:
DB2 CONTENTION: 22%
Agora os casos recentes realmente sinalizam mudança.
Recency Bias?
Não necessariamente.
Talvez novo regime.
Investigue.
🧠 Statistical Process Control
Uma ideia útil da qualidade:
distinguir:
variação comum
de:
mudança de processo.
Se últimos pontos saem do comportamento esperado:
talvez houve mudança real.
Isso é melhor que:
“parece diferente.”
📈 Control Charts no espírito
Você não precisa aplicar controle estatístico formal em tudo.
Mas pense:
o novo valor está dentro da distribuição histórica?
Se não:
talvez recente seja importante.
🧠 Framing Effect temporal
Nosso capítulo anterior retorna.
Escolher:
última semana
ou:
último ano
é framing.
Quem escolhe a janela pode alterar a narrativa.
Dashboard temporal também enquadra.
🎯 Pergunta Bellacosa nº 5
“Por que estamos olhando justamente este período?”
Se resposta:
porque mostra o que queremos,
temos problema.
👥 Gestão e performance
Recency Bias aparece fortemente em avaliações de pessoas.
Funcionário teve ótimo ano.
Errou último mês.
Avaliação:
desempenho ruim.
Ou inverso.
Últimos acontecimentos pesam demais.
Isso pode distorcer gestão.
🧠 Performance Review
Use registros ao longo do período.
Não memória de dezembro.
A mesma lógica da War Room.
💰 Investimentos e mercados
Investidor vê mercado subir últimos meses.
Pensa:
continuará.
Ou queda recente:
tudo está ruim.
Recency Bias influencia finanças há muito tempo.
Sistemas complexos têm a mesma psicologia.
🧠 Forecasting
Últimos dois projetos atrasaram.
Gestor aumenta todas estimativas dramaticamente.
Talvez correto.
Mas precisamos verificar:
foi nova realidade?
Ou eventos específicos?
Recency não deveria substituir reference class.
📊 Planning Fallacy + Recency
Curiosamente podem apontar em sentidos diferentes.
Último projeto foi rápido.
Equipe:
próximo também.
Planning Fallacy.
Recency reforça otimismo.
Último projeto foi terrível.
Equipe infla tudo.
Pode supercorrigir.
🧠 Overreaction
Recency Bias pode gerar:
overcorrection.
Um incidente ocorre.
Criamos quarenta controles.
Depois outro tipo de falha aparece porque processo ficou pesado demais.
Aprenda proporcionalmente.
🔐 Segurança: depois do ransomware
Empresa sofre ransomware.
Agora todo orçamento vai para ransomware.
Mas:
IAM;
fraude interna;
supply chain;
backup
também existem.
Evento recente extremamente traumático pode dominar risco corporativo.
Availability + Recency.
🧠 Risk Portfolio
Gestão de risco precisa olhar:
portfólio.
Não apenas último desastre.
☕ “Security by headline”
Sai notícia de ataque X.
Segunda-feira:
— Precisamos comprar ferramenta X!
Talvez.
Mas compare com threat model real.
Notícia recente não é automaticamente prioridade local.
🤖 IA e Recency Bias de contexto
Há uma analogia interessante.
Se você alimenta um sistema de IA com os últimos cinco incidentes e pergunta:
“Qual causa provável?”
o contexto recente pode dominar resposta.
Se histórico completo não foi recuperado:
a ferramenta pode reforçar recência.
🧠 RAG e temporal bias
Busca sem equilíbrio pode recuperar documentos recentes por relevância ou popularidade.
Talvez correto.
Mas pode esconder casos antigos importantes.
Um bom sistema de RCA deve considerar:
similaridade;
recência;
frequência;
mudança de versão.
🎯 IA: pergunta Bellacosa
“Essa hipótese está alta porque os dados recentes justificam ou porque o contexto fornecido só contém casos recentes?”
Excelente.
🧠 Freshness versus Representativeness
Duas propriedades diferentes:
freshness — quão novo é.
representativeness — quão bem representa a população.
Novo não significa representativo.
Antigo não significa irrelevante.
📚 História operacional é memória externa
Organizações precisam externalizar memória.
Senão dependem de:
quem estava no último incidente.
Isso aumenta recency.
Uma base histórica bem catalogada reduz.
🧠 Post-mortems estruturados
Classifique:
sintoma;
causa;
versão;
sistema;
impacto;
timestamp;
fix.
Agora comparação objetiva fica possível.
💾 Knowledge Graph dos incidentes
Imagine grafo:
TIMEOUT
├─ DB2 LOCK
├─ MQ
├─ NETWORK
└─ APP
Cada causa com:
frequência;
recência;
versão.
Isso é quase uma vacina tecnológica contra Recency Bias.
🧠 Recency-aware, not recency-blind
A meta não é remover recência.
É incorporá-la de forma explícita.
Exemplo:
HISTORICAL FREQUENCY: 12%
LAST 30 DAYS: 35%
POST-RELEASE: 48%
Agora sabemos:
algo mudou.
☕ Isso é muito melhor que:
“Ultimamente parece que MQ está dando mais problema.”
Transforme “parece” em série temporal.
📊 Trend Detection
Métrica:
12% → 15% → 25% → 35%.
Agora temos tendência.
Recência ganhou suporte.
🧠 Seasonality
Outro detalhe.
Problemas podem ser sazonais.
Fim do mês.
Black Friday.
Fechamento.
Se incidente recente ocorreu no fechamento:
talvez não represente semana normal.
Contexto temporal importa.
📅 Day-of-week effect
Segunda 08:00 pode ter padrão diferente de domingo 03:00.
Base rates temporais.
Recency sem segmentação engana.
🧠 Contextual History
Compare:
mesma hora;
mesmo volume;
mesmo ciclo;
mesma versão.
Isso melhora investigação.
🎯 Pergunta Bellacosa nº 6
“Estamos comparando com qualquer histórico ou com histórico realmente comparável?”
Boa.
🧪 War Room anti-Recency Bias
Um procedimento simples:
anote última causa conhecida;
anote top causas históricas;
anote mudanças recentes;
compare sinais atuais;
mantenha ao menos 3 hipóteses.
Isso reduz fixação.
🧠 Three-Hypothesis Rule
Durante os primeiros minutos:
não tenha uma hipótese.
Tenha três.
Exemplo:
H1 DB2
H2 MQ
H3 APPLICATION
Com evidências.
Isso combate:
Recency;
Anchoring;
Confirmation.
🔬 Hypothesis Scoreboard
DB2
BASE: HIGH
CURRENT EVIDENCE: STRONG
MQ
RECENT INCIDENT: YES
CURRENT EVIDENCE: WEAK
APP
BASE: MEDIUM
CURRENT EVIDENCE: MEDIUM
Agora MQ não ganha só porque está fresco na memória.
🧠 Decision checkpoints
A cada 10 minutos:
reordene.
Não preserve ranking antigo por orgulho.
🧠 Recency Bias em post-mortem
Último incidente grave domina backlog.
Todas ações priorizadas nele.
Mas talvez problemas recorrentes menores causem mais impacto anual.
Faça análise periódica agregada.
📊 Pareto de incidentes
Uma vez por mês:
causas.
horas perdidas.
clientes.
custos.
Talvez descubra:
incidente épico = 4h.
Problema banal recorrente = 200h/ano.
Recency faz épico parecer prioridade.
Dados mostram outra coisa.
☕ Drama versus impacto acumulado
O incidente com diretor na War Room é memorável.
O job que atrasa 10 minutos todo dia não.
Mas:
10 min × 250 dias = 41 horas.
Memória gosta de drama.
Operação precisa gostar de soma.
🧠 Present Bias + Recency
O recente também é temporalmente próximo.
Isso pode amplificar foco curto prazo.
Long-term improvement perde espaço.
🌀 Drift e incidentes pequenos
Pequenos problemas recentes podem parecer irrelevantes.
Mas série longa mostra crescimento.
Ou um grande incidente recente pode desviar atenção do drift.
Por isso análise de tendência é essencial.
🧠 Loss Aversion
Uma perda recente dói.
Então organização pode reagir exageradamente para impedir repetição.
Isso é compreensível.
Mas talvez crie investimento desproporcional.
💥 Scar Tissue Architecture
Existe um fenômeno divertido de chamar:
arquitetura de tecido cicatricial.
Cada incidente deixa um remendo.
Depois de vinte:
sistema virou coleção de traumas históricos.
Alguns controles são necessários.
Outros são cicatrizes do último susto.
☕ “Por que existe esse IF?”
— Incidente de 2004.
Outro:
— E esse?
— Incidente de 2007.
Outro:
— E isso aqui?
— Ninguém sabe.
Recency desaparece com o tempo, mas o código fica.
Por isso documente racional.
🧠 Institutional Memory precisa de meia-vida inteligente
Não esquecer rápido demais.
Nem preservar tudo para sempre.
Revise controles.
Ainda são necessários?
Condição mudou?
🧪 Sunset Review
Controle criado após incidente:
revisar em 6 meses.
Pergunte:
ainda necessário?
Funcionou?
Criou side effect?
Isso evita reação recente virar complexidade eterna.
📋 Checklist anti-Recency Bias
[ ] Estou dando peso demais ao último incidente?
[ ] Qual é o histórico completo?
[ ] Qual é a taxa-base?
[ ] O sistema mudou recentemente?
[ ] Os eventos recentes formam uma tendência real?
[ ] Estamos comparando o mesmo contexto?
[ ] Qual é a assinatura técnica atual?
[ ] Quais sinais contradizem o caso anterior?
[ ] O dashboard mostra mais de uma janela temporal?
[ ] Estamos supercorrigindo pelo último desastre?
[ ] Existe impacto acumulado maior que o incidente recente?
[ ] O controle criado para o último caso generaliza?
[ ] Dados antigos ainda representam o sistema atual?
[ ] Estamos confundindo freshness com representatividade?
🧪 Passo a passo para combater Recency Bias
Passo 1 — Pare de confiar apenas na memória
Use histórico.
Passo 2 — Compare janelas
Curta.
Média.
Longa.
Passo 3 — Verifique mudanças estruturais
Release.
Configuração.
Volume.
Passo 4 — Use base rates
Antes do caso recente.
Passo 5 — Segmente histórico
Contexto semelhante.
Passo 6 — Tenha hipóteses alternativas
Pelo menos três.
Passo 7 — Compare assinatura
Sinais, não sensação.
Passo 8 — Procure tendências
Não sequências pequenas.
Passo 9 — Revise controles após o trauma passar
Evite overreaction.
Passo 10 — Atualize crença proporcionalmente à evidência
Nem ignore recente.
Nem esqueça o passado.
🧬 Regeneração organizacional
Uma organização madura contra Recency Bias:
mantém histórico estruturado;
usa tendências;
versiona baselines;
compara períodos;
registra mudanças de regime;
analisa Pareto mensal;
evita hiperreagir ao último incidente;
e revisa medidas tomadas no calor da crise.
Principalmente:
ela aprende a perguntar:
“Isso está acontecendo mais agora ou apenas aconteceu há pouco?”
Essa diferença parece pequena.
É enorme.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Recency Bias é a tendência de dar peso excessivo a acontecimentos recentes.
O último incidente não representa automaticamente a distribuição inteira.
Recency Bias e Availability Heuristic frequentemente trabalham juntos.
Base rates ajudam a impedir que dois casos recentes virem uma falsa regra geral.
Mudanças de arquitetura podem tornar dados recentes realmente mais importantes — mas isso precisa ser demonstrado.
Múltiplas janelas temporais ajudam a distinguir ruído, sazonalidade, tendência e mudança de regime.
Anchoring e Confirmation Bias podem transformar o último incidente na causa do próximo antes mesmo da investigação começar.
Um grande incidente recente pode esconder problemas menores, recorrentes e mais caros no longo prazo.
Controles criados após um incidente devem atacar classes de falha, não apenas reproduzir a cicatriz daquele caso.
E principalmente:
O acontecimento mais recente merece atenção. Não merece automaticamente o cargo de representante oficial de toda a história.
🕰️ De volta às 08:03
Primeiro alerta.
PAYMENT RESPONSE TIME ABOVE BASELINE
Operador:
— MQ de novo.
Nosso programador responde:
— Pode ser.
Abre o histórico.
DB2: 38%
APP: 26%
MQ: 12%
NETWORK: 14%
OTHER: 10%
Depois:
LAST INCIDENT:
MQ
Depois:
CURRENT:
MQ DEPTH NORMAL
DB2 LOCK WAIT +720%
Ele diz:
— MQ entra na lista porque foi recente.
— Mas?
— Os dados atuais não combinam.
DBA investiga.
Encontra uma transação longa segurando locks.
Resolve.
08:31.
Serviço normal.
O operador olha.
— Se tivéssemos reiniciado MQ...
— Teríamos perdido tempo.
— Então nunca devemos usar o incidente anterior?
O Doctor responde:
— Claro que devem.
— Então qual é a regra?
— O passado recente pode fazer uma pergunta.
Pausa.
— Não pode responder sozinho.
Boa.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(RECENCY)
Dentro:
IF LAST-INCIDENT = CURRENT-HYPOTHESIS
PERFORM CHECK-HISTORY
END-IF.
IF RECENT-EVENTS > EXPECTED
PERFORM CHECK-REGIME-CHANGE
END-IF.
IF MEMORY-SAYS 'IT-IS-THE-SAME'
PERFORM COMPARE-SIGNATURE
END-IF.
Comentário:
* RECENT IS NOT THE SAME AS REPRESENTATIVE.
Outro:
* THE LAST INCIDENT GETS A VOTE.
* NOT A VETO.
Outro:
* HISTORY NEEDS VERSION CONTROL TOO.
E naturalmente:
* BAD WOLF HAPPENED RECENTLY.
* THAT DID NOT MAKE EVERYTHING BAD WOLF.
Nosso jovem fecha o membro.
Pouco depois alguém diz:
— Os últimos dois jobs falharam por espaço. Aposto que este também.
Ele pergunta:
— Dataset usage?
— 42%.
— Storage alerts?
— Nenhum.
— Então talvez os dois últimos estejam gritando mais alto do que os dados atuais.
Abre o joblog.
S0C7.
Dado inválido.
Nenhum espaço.
Nenhum storage.
Apenas o cérebro tentando usar ontem para economizar pensamento hoje.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica uma última frase:
O passado recente é excelente para levantar hipóteses. O histórico completo é melhor para dar proporção. E o presente, no fim, ainda precisa fornecer evidência.
☕🌀
Next stop: Representativeness Heuristic — quando algo “tem cara” de um padrão conhecido e começamos a tratá-lo como pertencente àquele padrão, mesmo quando os números contam outra história.
Sem comentários:
Enviar um comentário