 |
| Bellacosa Mainframe e o hindisight bias |
☕ Um Café no Bellacosa Mainframe
Hindsight Bias: Doctor Who, COBOL e o Dia em que Todo Mundo Sabia Depois que Aconteceu
Uma viagem pela TARDIS dos incidentes para entender por que o passado parece tão óbvio quando já conhecemos o final
14:32.
Produção parada.
Chamados chegando.
Gerente perguntando por previsão.
Operador olhando o console.
Programador olhando o operador.
DBA olhando o programador.
Todo mundo olhando o relógio.
E, como ocorre em qualquer incidente de respeitável pedigree corporativo, surge alguém que não participou das decisões anteriores e pronuncia a frase:
— Mas isso era óbvio.
Silêncio.
Uma frase simples.
Elegante.
Perigosa.
O programador COBOL iniciante olha para o colega.
— Era mesmo?
O colega dá de ombros.
— Agora parece.
VWORP.
VWORP.
VWORP.
A TARDIS surge discretamente no corredor.
A porta abre.
O Doctor sai, observa os gráficos, vê a linha vermelha atravessando a tela e pergunta:
— Quando vocês perceberam que isso iria acontecer?
Um gerente responde:
— Estava claro desde o começo.
O Doctor ergue uma sobrancelha.
— Interessante.
Olha para o relatório da manhã.
— Porque às oito horas ninguém parecia achar tão claro assim.
Eis nosso monstro da semana.
Hindsight Bias
Ou:
Viés Retrospectivo
O estranho fenômeno pelo qual o passado parece inevitável depois que já sabemos como ele terminou.
🌀 Antes de viajar, precisamos rever os dois episódios anteriores
Nossa TARDIS dos incidentes já passou por dois lugares importantes.
No primeiro episódio conhecemos o Swiss Cheese Model.
Aprendemos que sistemas complexos possuem várias barreiras.
Cada barreira possui falhas.
O desastre aparece quando os buracos se alinham.
Depois estudamos a Normalization of Deviance.
Descobrimos que organizações podem se acostumar a pequenos desvios.
Uma anomalia aparece.
Nada acontece.
Repete.
Nada acontece novamente.
Então o desvio deixa de parecer perigoso.
Agora chegamos a um terceiro problema.
Depois que o acidente acontece, nós olhamos para trás e pensamos:
“Como ninguém percebeu?”
Essa pergunta parece inteligente.
Às vezes é.
Mas frequentemente carrega uma armadilha cognitiva gigantesca.
Porque agora conhecemos o final.
As pessoas de antes não conheciam.
🧠 O que é Hindsight Bias?
Hindsight Bias é o viés cognitivo pelo qual, depois de conhecer um resultado, tendemos a acreditar que aquele resultado era mais previsível do que realmente era antes de acontecer.
Em português podemos encontrar expressões como:
A essência é:
ANTES:
“Existem várias possibilidades.”
DEPOIS:
“Era óbvio que terminaria assim.”
O conhecimento do resultado altera nossa memória sobre o que parecia provável anteriormente.
Isso é profundamente importante em investigação de incidentes.
Porque uma análise contaminada por hindsight bias pode transformar decisões razoáveis, tomadas com informação incompleta, em erros aparentemente absurdos.
🕰️ A TARDIS possui uma vantagem injusta
Imagine que o Doctor viaje para ontem.
Ele sabe que às 14:32 o sistema cairá.
Então, às 09:17, vê:
WARNING XYZ456
Para ele aquilo é imediatamente importante.
Por quê?
Porque ele conhece o futuro.
Mas o operador de ontem não conhece.
Para o operador, aquele warning pode estar entre outros cinquenta.
Talvez já tenha aparecido antes.
Talvez outros indicadores estejam normais.
Talvez haja um chamado prioritário em andamento.
Talvez não exista nenhuma ligação aparente entre aquele aviso e o incidente futuro.
Quem investiga depois possui uma vantagem extraordinária:
sabe quais pistas eram importantes.
Quem estava vivendo o evento não sabia.
Essa diferença muda tudo.
🔍 O famoso “era óbvio”
Vamos construir um incidente fictício.
09:10 — tempo de resposta aumenta 5%.
09:40 — uma fila cresce discretamente.
10:05 — operador recebe warning.
10:30 — job termina RC=04.
11:15 — volume volta ao normal.
12:20 — nova degradação.
13:50 — transações começam a falhar.
14:32 — indisponibilidade geral.
Depois do incidente, montamos a timeline.
Tudo fica maravilhoso.
A sequência parece quase cinematográfica.
09:10
↓
09:40
↓
10:05
↓
10:30
↓
12:20
↓
13:50
↓
14:32
E alguém diz:
— Está vendo? Os sinais estavam todos lá.
Sim.
Estavam.
Mas existe uma pergunta crucial:
Eles pareciam ligados naquele momento?
Talvez não.
🎯 O problema da seta vermelha
Existe uma ferramenta extremamente perigosa em post-mortems.
A seta.
Depois do evento fazemos:
WARNING
↓
FILA CRESCEU
↓
JOB LENTO
↓
ERRO
↓
INCIDENTE
Perfeito.
Só existe um problema.
Na vida real talvez houvesse cinquenta eventos simultâneos:
WARNING A
WARNING B
CPU NORMAL
REDE NORMAL
JOB X LENTO
JOB Y NORMAL
USUÁRIO RECLAMOU
USUÁRIO PAROU DE RECLAMAR
FILA CRESCEU
FILA DIMINUIU
RC=04
RC=00
ALERTA DE STORAGE
CHAMADO DE SENHA
DEPLOY EM OUTRO SISTEMA
...
Depois que sabemos o final, escolhemos os cinco eventos certos.
Criamos uma narrativa elegante.
Mas o operador real estava olhando para o caos completo.
☕ Bellacosa Mainframe e o poder enganoso do RC=04
Voltemos ao nosso velho amigo:
JOB04217 ENDED - RC=0004
Depois que descobrimos que o incidente estava ligado àquela condição, parece natural dizer:
— Era só investigar o RC=04.
Mas lembre-se do episódio anterior.
Talvez aquele RC=04 aparecesse havia meses.
Talvez centenas de vezes sem consequência.
Então o raciocínio do operador era:
RC=04 conhecido
+
nenhum efeito anterior
=
provavelmente baixo risco
Depois do incidente, nosso raciocínio muda:
RC=04
+
incidente conhecido
=
obviamente perigoso
Veja como o resultado altera a interpretação.
🧩 O quebra-cabeça depois de montado
Hindsight bias é parecido com olhar para um quebra-cabeça pronto e dizer:
— Era evidente onde cada peça deveria ficar.
Claro.
Você está olhando para a imagem completa.
Experimente receber 2.000 peças sem caixa.
Essa é a realidade operacional.
👨💻 Um exemplo COBOL
Imagine este código:
IF WS-STATUS = 'A'
PERFORM PROCESSA-CONTA
ELSE
PERFORM TRATA-EXCECAO
END-IF.
Meses depois ocorre um incidente porque apareceu:
WS-STATUS = SPACE
Após investigar, alguém comenta:
— Era óbvio que deveriam testar SPACE.
Agora parece.
Mas quando o programa foi desenvolvido talvez os requisitos dissessem:
STATUS:
A = ativo
I = inativo
Nenhum documento mencionava SPACE.
Nenhum arquivo de teste possuía SPACE.
Nenhuma interface deveria produzir SPACE.
Então precisamos perguntar:
com o conhecimento disponível naquele momento, era realmente óbvio?
Talvez sim.
Talvez não.
Essa distinção importa.
⚖️ Hindsight Bias não é desculpa para qualquer coisa
Aqui precisamos ser cuidadosos.
Evitar hindsight bias não significa dizer:
“Ninguém poderia saber de nada.”
Existem situações previsíveis.
Existem alertas claros.
Existem controles ignorados conscientemente.
Existem negligência e violação.
A ideia é outra:
julgar decisões usando as informações disponíveis quando foram tomadas, e não apenas o conhecimento adquirido depois do desastre.
Essa é uma das bases de uma investigação justa.
🧠 Outcome Bias: o primo perigoso
Existe um viés relacionado chamado outcome bias.
Ele acontece quando avaliamos a qualidade de uma decisão principalmente pelo resultado.
Imagine dois operadores.
Operador A toma uma decisão arriscada.
Nada acontece.
Resultado:
— Excelente.
Operador B toma exatamente a mesma decisão uma semana depois.
Sistema cai.
Resultado:
— Irresponsável.
Mas a decisão foi a mesma.
O resultado diferente não deveria alterar completamente nossa avaliação do processo decisório.
Isso conecta perfeitamente com a Normalization of Deviance.
Uma decisão arriscada que “funciona” repetidamente pode ganhar reputação de boa prática.
Até falhar.
🎲 Sorte mascarada de competência
Imagine:
deploy sem rollback testado.
Primeira vez funciona.
Segunda também.
Décima também.
Equipe conclui:
nosso processo funciona.
Talvez funcione.
Ou talvez tenhamos tido sorte dez vezes.
Na décima primeira ocorre problema.
Depois:
— Era irresponsável fazer deploy sem rollback.
Sim.
Mas então por que os dez deploys anteriores foram comemorados?
Esse contraste revela outcome bias.
🚀 Challenger novamente entra na TARDIS
Eventos como Challenger são frequentemente estudados justamente porque mostram como é fácil, depois do desastre, olhar sinais anteriores e julgá-los como obviamente precursores.
Mas quem estava tomando decisões naquele momento trabalhava dentro de uma estrutura de informação, pressões, experiências anteriores, modelos mentais e expectativas específicas.
Isso não absolve decisões ruins.
Mas melhora a qualidade da investigação.
Uma pergunta poderosa é:
O que fazia sentido para essas pessoas naquele momento?
Se compreendermos isso, conseguimos alterar o sistema.
Se apenas dissermos:
“Eles deveriam ter percebido.”
aprendemos muito pouco.
🧀 Swiss Cheese + Normalization + Hindsight
Agora nossos três episódios começam a se encaixar.
Episódio 1 — Swiss Cheese
Existem várias barreiras imperfeitas.
Episódio 2 — Normalization of Deviance
Alguns buracos passam a ser tolerados porque nunca produziram desastre.
Episódio 3 — Hindsight Bias
Depois que os buracos finalmente se alinham, parece óbvio que o acidente aconteceria.
Temos então uma ironia extraordinária:
ANTES DO INCIDENTE:
“Isso sempre acontece. Está tudo bem.”
DEPOIS DO INCIDENTE:
“Era óbvio que isso era perigoso.”
A mesma organização pode dizer as duas frases.
Com poucas horas de diferença.
👻 Easter Egg nº 1 — Spoilers
Em Doctor Who existe uma palavra perfeita para explicar hindsight bias:
Spoilers.
Imagine River Song analisando um incidente.
Ela possui o diário.
Sabe o que acontecerá.
Naturalmente tudo parecerá muito mais previsível.
Mas o operador não possuía o diário.
Essa talvez seja a melhor metáfora da nossa série.
Um investigador pós-incidente possui spoilers.
Quem estava na operação não.
🔎 Como investigar sem cair no Hindsight Bias
Agora vamos transformar tudo isso em prática.
Passo 1 — Congele o conhecimento no tempo
Durante a reconstrução, pergunte:
O que essa pessoa sabia exatamente às 09:17?
Não use informações descobertas às 15:00.
Se a causa raiz só foi conhecida depois, ela não pode ser usada para julgar uma decisão anterior como se já estivesse disponível.
Isso parece simples.
Na prática é difícil.
🕰️ Passo 2 — Construa uma timeline cognitiva
Não registre apenas eventos técnicos.
Registre conhecimento.
Exemplo:
09:10
CPU sobe 5%.
Informação conhecida:
ainda dentro do baseline.
09:40
Fila aumenta.
Informação conhecida:
picos semelhantes ocorreram anteriormente.
10:05
Warning XYZ.
Informação conhecida:
warning havia ocorrido 47 vezes sem impacto.
13:50
Primeiras falhas.
Informação conhecida:
agora existe correlação clara.
Isso é muito mais rico que uma simples linha do tempo.
🧠 Passo 3 — Pergunte pelas hipóteses concorrentes
Hoje sabemos:
storage causou o incidente.
Mas às 11:00 talvez existissem cinco hipóteses:
rede;
aplicação;
Db2;
storage;
volume inesperado.
Investigar hindsight bias significa preservar essas possibilidades.
Não finja que existia apenas uma.
📊 Passo 4 — Reconstrua o dashboard original
Excelente exercício.
Não mostre ao investigador apenas o gráfico onde a causa aparece.
Mostre exatamente o que o operador via.
Se havia 20 painéis, mostre 20.
Se existiam 300 alertas, considere isso.
Talvez a verdadeira causa seja:
sinal importante enterrado em ruído.
Isso é uma descoberta operacional valiosa.
👥 Passo 5 — Entrevistas sem acusação
Evite perguntas como:
“Por que você ignorou esse alerta?”
A palavra “ignorou” já contém julgamento.
Prefira:
“O que esse alerta significava para você naquele momento?”
Outra:
“Que outras informações você estava considerando?”
Outra:
“O que você esperava que acontecesse?”
Essas perguntas revelam modelo mental.
E modelos mentais são ouro em investigação de incidentes.
🧩 Passo 6 — Pergunte o que parecia normal
Isso conecta com nossa Normalization of Deviance.
Esse comportamento já havia acontecido?
Qual era a consequência histórica?
A equipe tinha motivos para considerá-lo benigno?
Talvez você descubra que o operador não negligenciou um warning.
Ele reagiu exatamente como a organização o treinou informalmente a reagir.
Essa diferença é gigantesca.
🚨 Passo 7 — Procure os sinais que eram realmente discriminantes
Nem todo sinal anterior era útil.
Depois do incidente conseguimos encontrar dezenas de anomalias.
Mas quais poderiam realisticamente indicar aquele problema?
Isso evita criar controles para qualquer variação imaginável.
Caso contrário, o resultado será:
mais alertas.
Mais ruído.
Mais alarm fatigue.
E, ironicamente, menos segurança.
🛠️ Passo 8 — Melhore o sistema, não apenas a memória das pessoas
Depois de um incidente ouvimos:
“Da próxima vez todos saberão.”
Talvez.
Por seis meses.
Depois as pessoas mudam.
Documentação envelhece.
Novos funcionários chegam.
Se o aprendizado depende exclusivamente de memória humana, não é robusto.
Transforme aprendizado em:
alertas melhores;
limites claros;
automação;
validação;
runbooks;
testes;
guardrails;
observabilidade;
design.
🔁 Passo 9 — Teste a correção contra o próximo incidente, não o anterior
Esse ponto é fantástico.
Depois de um desastre, organizações podem construir uma defesa extremamente específica contra exatamente o que aconteceu.
Exemplo:
incidente ocorreu porque arquivo veio com data 00000000.
Correção:
IF WS-DATA = ZERO
...
END-IF.
Ótimo.
Mas amanhã chega:
99999999
Ou:
20261345
A lição deveria ser:
validar datas.
Não apenas:
bloquear zeros.
Aprenda o padrão, não somente o caso.
🧪 Passo 10 — Faça pre-mortem
Existe uma técnica extraordinariamente útil chamada pre-mortem.
Antes de uma mudança importante, imagine:
“Estamos seis horas no futuro. O deploy falhou de forma espetacular. Por quê?”
Agora peça para a equipe listar possibilidades.
Isso reduz parte do efeito de excesso de confiança.
Exemplo:
Deploy falhou porque:
- volume real era maior;
- rollback não funcionou;
- dependência externa mudou;
- dataset encheu;
- certificado expirou;
- parâmetro errado foi promovido;
- tabela ficou bloqueada.
Você está usando imaginação preventiva.
Quase uma TARDIS sem TARDIS.
🕵️ O iniciante COBOL pode ser extremamente valioso
Existe uma vantagem curiosa em ser iniciante.
Você ainda faz perguntas.
Veterano:
— Sempre termina RC=04.
Iniciante:
— Por quê?
Veterano:
— Porque sempre termina.
Iniciante:
— Sim, mas por quê?
Essa segunda pergunta pode salvar produção.
Não confunda experiência com infalibilidade.
E não confunda ingenuidade com inutilidade.
Às vezes quem chegou ontem consegue enxergar uma suposição invisível para quem está há vinte anos no ambiente.
☕ A pergunta Bellacosa
Quando alguém disser:
“Era óbvio.”
Pergunte:
“Era óbvio antes ou ficou óbvio depois?”
Essa pergunta deveria entrar em todo post-mortem.
Porque obriga o grupo a separar:
previsibilidade real;
conhecimento retrospectivo.
📚 Curiosidade: nossos cérebros reescrevem narrativas
Seres humanos gostam de histórias coerentes.
Depois de saber o resultado, reorganizamos eventos anteriores em uma narrativa que faça sentido.
O problema é que sistemas complexos não acontecem como romances policiais.
A realidade possui:
ruído;
informação incompleta;
dados contraditórios;
decisões simultâneas;
prioridades conflitantes.
O post-mortem, entretanto, tende a transformar tudo em uma linha elegante.
Cuidado com narrativas elegantes demais.
A realidade costuma ser mais bagunçada.
🕸️ Sistemas complexos possuem muitos futuros possíveis
Às 09:00 talvez existissem vários futuros:
A → sistema normaliza sozinho
B → operador corrige
C → alerta desaparece
D → degradação continua
E → incidente grave
Depois que E acontece, nossa mente tende a apagar A, B, C e D.
Parece que E sempre foi destino.
Não era.
Era uma possibilidade.
Essa distinção é fundamental para entender risco.
🎯 Previsão não é retrospectiva
Existe uma diferença enorme entre dizer:
“Eu teria previsto.”
e realmente possuir uma previsão registrada antes.
Quer testar?
Antes de uma mudança, escreva riscos.
Depois compare.
Você descobrirá algo humilhante e maravilhoso:
somos muito menos profetas do que imaginamos.
📝 Diário de previsões
Uma técnica interessante para equipes maduras:
antes de grandes mudanças, registre:
riscos esperados;
sinais esperados;
probabilidades;
pontos de rollback;
critérios de abortar.
Depois do evento, compare.
Isso reduz a ilusão:
“Nós sabíamos.”
Se sabíamos, deveria existir algum registro.
👽 Easter Egg nº 2 — O Dalek pós-mortem
Imagine um Dalek participando do post-mortem.
Provavelmente sua análise seria:
EXTERMINATE!
EXTERMINATE!
OPERATOR ERROR!
EXTERMINATE!
Muito eficiente.
Pouquíssimo aprendizado.
Infelizmente, algumas organizações fazem algo semelhante.
Apenas com PowerPoint.
⚖️ Blameless Post-Mortem novamente
Nossa série está construindo uma filosofia.
Blameless não significa:
ninguém erra.
Significa:
queremos compreender por que a decisão parecia razoável naquele contexto.
Se encontramos dolo ou negligência grave, tratamos.
Mas se encontramos uma pessoa agindo de acordo com incentivos, ferramentas e conhecimento disponíveis, precisamos melhorar o sistema.
Caso contrário trocamos a pessoa.
E preservamos o incidente.
🧯 A diferença entre causa e gatilho
Muitos post-mortems confundem essas coisas.
Exemplo:
Comando errado
↓
incidente
Comando errado foi o gatilho.
Mas talvez existissem:
permissão excessiva;
interface confusa;
ausência de dupla confirmação;
pressão;
procedimento incompleto;
falta de rollback;
ambiente parecido com homologação.
A pergunta útil não é apenas:
Quem puxou o gatilho?
É:
Por que havia uma arma carregada apontada para produção?
🧠 Hindsight Bias na gestão
Imagine um projeto.
Equipe alerta:
Existe 20% de risco de atraso.
Projeto atrasa.
Diretor:
— Eu sabia que atrasaria.
Talvez.
Mas se terminasse no prazo, provavelmente ninguém diria:
— Eu sabia que havia 20% de risco.
Probabilidade desaparece depois do resultado.
Isso acontece em:
projetos;
segurança;
finanças;
medicina;
engenharia;
operações.
Nosso cérebro prefere certezas retrospectivas.
🔍 Como detectar Hindsight Bias numa reunião
Escute estas frases:
“Era óbvio.”
“Qualquer um perceberia.”
“Isso inevitavelmente aconteceria.”
“Como ninguém viu?”
“Eu sempre disse.”
“Bastava olhar.”
Pare.
Pergunte:
Qual informação estava disponível antes?
Depois:
Quem realmente identificou isso antes?
Depois:
Essa preocupação estava registrada?
Agora começamos a separar percepção real de memória reconstruída.
🧬 Regeneração organizacional
No final de cada episódio nossa organização precisa regenerar.
No caso do Hindsight Bias, regeneração significa mudar a pergunta.
Em vez de:
“Quem deveria ter sabido?”
pergunte:
“Como podemos tornar esse risco mais perceptível no futuro?”
Em vez de:
“Por que ele não viu?”
pergunte:
“Como a informação estava apresentada?”
Em vez de:
“Era óbvio.”
pergunte:
“O que tornaria isso óbvio antes?”
Essa última pergunta é maravilhosa.
Porque transforma julgamento em engenharia.
📓 Diário do Doctor
Se você lembrar apenas algumas coisas desta viagem, guarde estas:
Hindsight Bias faz o passado parecer mais previsível depois que conhecemos o resultado.
Investigadores possuem spoilers; operadores não.
Uma timeline pós-incidente pode criar uma narrativa muito mais clara do que a realidade original.
Decisões precisam ser avaliadas usando informações disponíveis naquele momento.
Resultado ruim não significa automaticamente decisão ruim.
Resultado bom não significa automaticamente decisão boa.
Pergunte quais hipóteses concorrentes existiam.
Reconstrua o que a pessoa realmente via.
Evite transformar “erro humano” em ponto final.
Transforme conhecimento retrospectivo em melhores mecanismos futuros.
E, principalmente:
Nunca confunda “agora eu entendo” com “antes era óbvio”.
🕰️ De volta às 08:17
O Doctor entra na TARDIS.
Nosso programador COBOL o acompanha.
— Podemos voltar para antes do incidente?
— Claro.
VWORP.
VWORP.
VWORP.
08:17.
Console normal.
Produção funcionando.
Na tela:
WARNING XYZ456
O programador aponta.
— Está ali!
— Sim.
— Então era óbvio!
O Doctor aponta para outra tela.
WARNING ABC122
WARNING TYU991
RC=04
QUEUE +3%
CPU +2%
STORAGE NORMAL
NETWORK NORMAL
Depois outra.
Mais dezenas de mensagens.
Chamados.
Emails.
Mudanças.
Processamentos.
O jovem fica quieto.
O Doctor pergunta:
— Ainda parece óbvio?
— Menos.
— Excelente.
— Então ninguém poderia perceber?
— Não foi isso que eu disse.
O Doctor sorri.
— Nossa tarefa é descobrir o que teria tornado aquela pista distinguível das outras.
Eles voltam para a TARDIS.
Antes de fechar a porta, o Doctor olha novamente para o console.
— Ah, e mais uma coisa.
— O quê?
— Cuidado com qualquer post-mortem em que tudo pareça fazer sentido demais.
A porta fecha.
VWORP.
VWORP.
VWORP.
🥚 Easter Egg final
Horas depois, nosso programador abre um dataset antigo chamado:
BELLACOSA.INCIDENTS.TIMELORD
Dentro existe apenas:
IF YOU ALREADY KNOW THE END
EVERYTHING LOOKS OBVIOUS
END-IF.
Ele procura quem criou o membro.
O RACF mostra:
USERID: RSONG
Estranho.
A conta não existe há anos.
No comentário final existe apenas:
* SPOILERS.
O telefone toca.
É produção.
Outro alerta apareceu.
Nosso jovem programador olha para ele.
Dessa vez não pergunta:
“Isso vai causar incidente?”
Pergunta algo muito melhor:
“O que sabemos agora, sem usar o futuro para completar a história?”
E talvez seja assim que profissionais começam realmente a aprender com falhas.
Não tentando provar que poderiam prever o passado.
Mas construindo sistemas capazes de perceber melhor o futuro.
☕🌀
Next stop: Confirmation Bias — quando começamos a investigação procurando evidências de que nossa primeira teoria estava certa… e ignoramos educadamente todo o resto.
