 |
| Bellacosa Mainframe e o fundamental attribution error |
☕ Um Café no Bellacosa Mainframe
Fundamental Attribution Error: Doctor Who, COBOL e o Dia em que “Fulano Errou” Virou a Explicação para Tudo
Uma viagem pela TARDIS dos incidentes para entender por que culpamos pessoas por falhas que também nasceram de contexto, pressão, ferramentas, processos, incentivos e sistemas mal desenhados
03:41.
Madrugada.
Produção parcialmente indisponível.
Café frio.
War Room lotada.
Na tela:
INCIDENTE SEV-1
IMPACTO:
37% DAS TRANSAÇÕES REJEITADAS
INÍCIO:
03:12
AÇÃO ANTERIOR:
ALTERAÇÃO MANUAL DE PARÂMETRO
OPERADOR:
CARLOS
O gerente olha para a timeline.
— Quem alterou o parâmetro?
Silêncio.
O operador levanta a mão.
— Eu.
— Você sabia que podia derrubar produção?
— Não.
— Mas o valor estava errado.
— Sim.
Outro gerente entra:
— Então encontramos a causa.
Nosso jovem programador COBOL pergunta:
— Encontramos?
— Claro.
O gerente aponta para Carlos.
— Ele digitou o valor errado.
Parece simples.
Humano.
Confortável.
Uma pessoa.
Uma ação.
Uma consequência.
Narrative Bias fica satisfeito.
03:48.
Alguém já escreve no chat:
ROOT CAUSE:
HUMAN ERROR
Nosso programador olha para a tela de mudança.
O campo era:
MAXTHD:
_____
Sem descrição.
Sem range.
Sem warning.
Sem validação.
Ele pergunta:
— Qual era o valor correto?
— 250.
— E o que foi digitado?
— 2500.
— O sistema aceitou?
— Sim.
— Não havia confirmação?
— Não.
— Peer review?
— A mudança era urgente.
— Ambiente de teste?
— Não reproduzia esse parâmetro.
— Runbook?
— Desatualizado.
— Carlos estava há quanto tempo no plantão?
Silêncio.
Alguém consulta.
— Onze horas.
Nosso programador olha para o gerente.
— Ainda é só “Carlos errou”?
Antes que alguém responda:
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado do projetor.
A porta abre.
O Doctor sai.
Olha para Carlos.
Depois para o formulário.
Depois para o runbook.
Depois para o relógio.
— Quem digitou o número?
— Carlos.
— Então Carlos participou do incidente.
O gerente sorri.
— Exatamente.
O Doctor continua:
— Quem desenhou uma interface que aceita valor dez vezes maior sem perguntar nada?
Silêncio.
— Quem definiu que uma mudança crítica poderia ser feita sem segundo par de olhos?
Silêncio.
— Quem permitiu onze horas contínuas de plantão?
Mais silêncio.
— Quem deixou o runbook ficar desatualizado?
Agora ninguém parece tão interessado em responder.
O Doctor sorri.
— Ah.
Pausa.
— Humanos adoram descobrir que uma pessoa errou.
Aponta para todo o resto.
— É muito menos confortável descobrir que o sistema inteiro estava esperando uma pessoa errar.
Bem-vindo ao:
Fundamental Attribution Error
Ou:
Erro Fundamental de Atribuição
A tendência de explicar o comportamento ou os erros de outras pessoas principalmente por características pessoais — descuido, incompetência, irresponsabilidade, preguiça, falta de atenção — enquanto subestimamos o contexto, as pressões, os incentivos, as ferramentas e as condições em que aquela pessoa estava operando.
Em linguagem Bellacosa:
“Fulano fez besteira” parece uma explicação muito mais fácil do que “o sistema tornou essa besteira provável e perigosa”.
🌀 Nossa TARDIS dos incidentes já encontrou muitos monstros
Até aqui vimos:
Swiss Cheese Model — várias barreiras podem falhar juntas.
Normalization of Deviance — desvios podem virar rotina.
Hindsight Bias — depois do incidente tudo parece óbvio.
Confirmation Bias — buscamos evidências para aquilo que já acreditamos.
Anchoring Bias — a primeira explicação pesa demais.
Groupthink — grupos inteligentes podem errar juntos.
Authority Gradient — hierarquia pode silenciar quem percebe o problema.
Plan Continuation Bias — continuamos mesmo quando o plano deixou de fazer sentido.
Alarm Fatigue — excesso de alertas destrói atenção.
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 — olhamos apenas para quem sobreviveu.
Base Rate Neglect — ignoramos frequências reais.
Availability Heuristic — o que lembramos facilmente parece mais provável.
Outcome Bias — bom resultado parece provar boa decisão.
Overconfidence Bias — confiança excessiva reduz revisão.
Planning Fallacy — subestimamos esforço e complexidade.
Sunk Cost Fallacy — custos passados prendem decisões futuras.
Status Quo Bias — o atual recebe privilégio psicológico.
Present Bias — o conforto de hoje pesa mais que o custo de amanhã.
Optimism Bias — acreditamos que o futuro será mais gentil conosco.
Action Bias — sentimos necessidade de agir.
Omission Bias — não agir pode parecer menos culpável.
Loss Aversion — perder pesa mais que ganhar.
Framing Effect — a moldura altera a decisão.
Recency Bias — o recente parece mais representativo.
Representativeness Heuristic — “tem cara de X” vira “deve ser X”.
Narrative Bias — uma boa história pode parecer mais verdadeira do que os dados permitem.
Agora surge o personagem perfeito para essa história:
o culpado.
🧠 O que é Fundamental Attribution Error?
Imagine:
você está dirigindo.
Um carro corta sua frente.
Você pensa:
“Que idiota.”
Essa explicação atribui o comportamento à personalidade.
Talvez o motorista seja realmente imprudente.
Mas talvez:
esteja levando alguém ao hospital;
não tenha visto você;
tenha recebido indicação errada;
esteja desviando de outro carro.
Não sabemos.
Quando outra pessoa faz algo errado, tendemos a explicar com:
“ela é assim.”
Quando nós fazemos:
“a situação me obrigou.”
Esse contraste é fascinante.
☕ Bellacosa Mainframe: “O operador foi desatento”
Imagine:
COMMAND:
PURGE QUEUE ABC
Operador executa na queue errada.
Incidente.
Post-mortem ruim:
“Operador deve prestar mais atenção.”
Ação preventiva:
TREINAR OPERADOR
Pronto.
Ticket fechado.
Problema resolvido?
Talvez não.
Pergunte:
por que era possível purgar fila crítica sem confirmação?
Por que nomes eram parecidos?
PAY.PRD.IN
PAY.PRD.INT
Por que acesso permitia?
Por que não havia preview?
Por que processo dependia de digitação manual?
Por que ele precisava trabalhar sob pressão?
Agora temos engenharia.
🧠 Pessoa versus sistema
Isso não significa:
“ninguém é responsável por nada.”
Muito importante.
Pessoas possuem responsabilidade.
Negligência real existe.
Violações conscientes existem.
Fraude existe.
Mas:
atribuir rapidamente tudo à pessoa pode impedir descobrir por que o erro:
era possível;
era provável;
teve impacto tão grande.
Uma cultura madura consegue manter duas ideias ao mesmo tempo:
pessoas respondem por escolhas
e:
sistemas precisam ser projetados considerando que humanos erram.
👻 Easter Egg nº 1 — O Doctor e o botão errado
Companion aperta botão.
Alarme.
Doctor:
— Por que apertou?
— Achei que abria a porta.
— E por que achou?
— Porque está escrito “OPEN”.
Doctor olha.
— Ah.
— O quê?
— Aparentemente “OPEN” significa “abrir o núcleo do reator”.
Pausa.
— Talvez o problema não seja só seu dedo.
Interface ruim é um vilão subestimado.
🧠 Human Error não é Root Cause
Essa é uma das frases mais importantes deste artigo:
“Human error” normalmente é o começo da investigação, não o fim.
Se alguém digitou errado:
por quê?
Se esqueceu:
por quê?
Se escolheu ação errada:
que informação tinha?
Que pressão existia?
Que alternativas eram visíveis?
O erro humano frequentemente é:
o ponto onde o sistema manifestou sua fragilidade.
🧀 Swiss Cheese volta imediatamente
Carlos digitou 2500.
Mas imagine as barreiras:
documentação correta;
validação de campo;
range check;
peer review;
teste;
monitoramento;
rollback.
Se todas falharam:
por que escolher apenas Carlos como causa?
O Swiss Cheese Model nos lembra:
o erro humano pode ser apenas um dos buracos.
🧠 Local Rationality
Em Safety Science existe uma ideia extremamente útil:
pessoas fazem escolhas que parecem razoáveis dentro do contexto que possuem naquele momento.
Isso é chamado frequentemente de:
local rationality
Você olha depois e pensa:
“Como ele pôde fazer isso?”
Mas pergunte:
“Por que aquilo fazia sentido para ele naquele instante?”
Essa pergunta muda tudo.
☕ Carlos às 03:10
O runbook dizia:
INCREASE MAXTHD IF QUEUE > 80%
Não dizia quanto.
Última ocorrência:
alguém usou 2500 num ambiente de teste.
Carlos encontrou mensagem antiga no chat:
“Use 2500.”
Produção usava 250.
Pressão:
clientes reclamando.
Gerente:
“precisamos resolver agora.”
Então 2500 talvez não tenha parecido absurdo.
Agora compreendemos.
Não significa que valor estava certo.
Significa que erro deixa de parecer inexplicável.
E quando erro é explicável:
podemos projetar defesa.
🧠 “Como alguém poderia fazer isso?”
Essa pergunta costuma conter julgamento.
Melhor:
“Que informação e condições tornaram essa ação plausível?”
Ela produz conhecimento.
🔎 Fundamental Attribution Error + Hindsight Bias
Depois do incidente:
valor correto parece óbvio.
250 versus 2500.
Mas antes:
sem range;
sem descrição;
sob pressão,
talvez não.
Hindsight Bias transforma contexto incerto em:
“qualquer pessoa deveria saber.”
Fundamental Attribution Error transforma isso em:
“então Carlos é incompetente.”
Combo perigoso.
🧠 Narrative Bias cria personagem
No capítulo anterior:
narrativa quer começo, meio e fim.
Agora precisa de protagonista.
“Carlos digitou errado.”
Pronto.
Temos causa.
É uma história elegante.
Muito mais simples do que:
interface;
documentação;
pressão;
plantão;
treinamento;
governança.
🎬 O problema do vilão único
Filmes funcionam melhor com vilão.
Sistemas complexos raramente.
Se seu RCA termina com:
“Fulano errou”
desconfie.
Talvez seja verdade.
Mas pergunte:
por que um erro individual conseguia causar um incidente sistêmico?
🧠 Blame is cognitively cheap
Culpa é barata.
Você não precisa:
alterar software;
melhorar processo;
investir em automação.
Basta:
treinar;
advertir;
mandar e-mail.
Isso dá sensação de ação.
Action Bias agradece.
☕ “Reforçar atenção”
Uma ação preventiva clássica:
AÇÃO:
REFORÇAR ATENÇÃO DA EQUIPE
Traduzindo:
esperamos que humanos deixem de ser humanos.
É uma defesa fraca.
🧠 Hierarquia de controles
Pense em formas de reduzir erro.
Mais fraco:
lembre-se.
Melhor:
checklist.
Melhor:
validação automática.
Melhor:
remover possibilidade de valor inválido.
Exemplo:
em vez de campo livre:
MAXTHD: ______
use:
MAXTHD:
[100] [250] [500]
ou range validado:
MIN 100
MAX 500
A interface trabalha junto com humano.
💻 COBOL iniciante: validação importa
Imagine:
ACCEPT WS-THREADS
MOVE WS-THREADS TO CFG-THREADS
Sem validação.
Usuário digita:
2500
Programa aceita.
Depois incidente.
Quem errou?
Usuário?
Ou código que confiou cegamente?
Defensive programming responde:
IF WS-THREADS < 100
OR WS-THREADS > 500
DISPLAY 'VALOR FORA DO LIMITE'
ELSE
MOVE WS-THREADS TO CFG-THREADS
END-IF
Agora sistema ajuda.
🧠 Poka-Yoke
Na qualidade industrial existe o conceito japonês:
Poka-Yoke
À prova de erro ou error-proofing.
A ideia:
projetar processos de modo que erros sejam:
impossíveis;
difíceis;
detectados cedo.
Exemplo simples:
conectores que só encaixam de uma maneira.
Em TI:
validação;
defaults seguros;
confirmações;
permissões;
automação.
Excelente antídoto para cultura de culpa.
☕ “Treinar mais” versus “errar menos”
Treinamento é importante.
Mas se 100 pessoas diferentes cometem o mesmo erro:
talvez não precisemos de 101º treinamento.
Talvez precisemos mudar o sistema.
🧠 Fundamental Attribution Error + Authority Gradient
Gerente olha para júnior:
“Ele não teve coragem de falar.”
Talvez.
Mas e se cultura pune discordância?
O comportamento individual foi moldado por autoridade.
Culpamos silêncio.
Ignoramos sistema social que o produziu.
👥 Groupthink
Pessoa concordou com todos.
Depois:
“Ela deveria ter questionado.”
Mas talvez:
cinco especialistas;
um diretor;
pressão de prazo.
O contexto importa.
Isso não remove responsabilidade.
Explica comportamento.
🧠 Omission Bias
Alguém não interrompeu mudança.
Depois:
“faltou iniciativa.”
Talvez.
Mas:
tinha autoridade formal?
Existia stop criterion?
O chefe dizia para continuar?
A omissão pode ter sido consequência do desenho organizacional.
🧠 Action Bias
Outro operador reinicia serviço cedo demais.
Post-mortem:
“impulsivo.”
Mas gerente estava gritando:
“faça alguma coisa!”
A organização recompensa ação visível.
Depois culpa quem agiu.
Interessante.
☕ Incentives matter
Se KPI é:
MTTR baixo,
operador aprende:
restart rápido.
Depois RCA reclama:
“reiniciou cedo demais.”
Talvez o comportamento tenha sido exatamente aquilo que o sistema de incentivos ensinou.
🧠 Goodhart entra pela janela
Se medimos:
tempo até recuperação,
as pessoas otimizam isso.
Talvez sacrificando diagnóstico.
Métrica também cria comportamento.
Não atribua tudo à personalidade.
🌀 Drift Into Failure
Por anos:
atalhos;
pressão;
redução de equipe;
workarounds.
Tudo funciona.
Até alguém erra.
Agora:
“Fulano causou outage.”
Não.
Talvez Fulano tenha sido:
a última peça de uma deriva longa.
Drift Into Failure torna culpa individual particularmente enganosa.
🧠 Normalization of Deviance
Carlos fez mudança manual.
Pergunta:
era exceção?
— Não.
Todo mundo fazia.
Então:
por que quando falha vira:
“Carlos foi imprudente”?
A organização normalizou a prática.
Outcome ruim mudou julgamento.
Outcome Bias aparece.
🧠 Outcome Bias + attribution
Mesma ação.
Operador A faz.
Funciona.
Herói.
Operador B faz.
Falha.
Imprudente.
Mesmo processo.
Resultados diferentes.
Outcome Bias muda julgamento da pessoa.
☕ Sorte e culpa
Às vezes:
o “bom operador” teve sorte.
O “ruim” encontrou condição adversa.
Não significa que competência não exista.
Significa:
avalie processo também.
🧠 Overconfidence do observador
Nós olhamos de fora e pensamos:
“Eu jamais faria isso.”
Tem certeza?
Com:
03:00;
onze horas de plantão;
telefone tocando;
cliente pressionando;
runbook ruim?
Overconfidence pode fazer julgador superestimar seu próprio comportamento hipotético.
👻 Easter Egg nº 2 — Dalek no turno da madrugada
Doctor:
— Você teria apertado o botão errado?
Companion:
— Nunca.
— Mesmo com três Daleks perseguindo você?
— Bem...
— Alarme tocando?
— Talvez...
— Sem dormir há onze horas?
— Certo.
Doctor:
— É extraordinário como nossa personalidade melhora quando imaginamos o passado dos outros.
🧠 Actor-Observer Asymmetry
Um conceito relacionado:
quando avaliamos nosso próprio comportamento, percebemos contexto.
Quando avaliamos o outro, percebemos personalidade.
Eu:
“Atrasei porque trânsito estava horrível.”
Outro:
“Atrasou porque é irresponsável.”
Na War Room:
eu reiniciei cedo porque:
“pressão.”
Ele reiniciou cedo porque:
“é afoito.”
Isso precisa de atenção.
🧠 Self-Serving Bias também pode aparecer
Sucesso:
competência minha.
Falha:
contexto.
Para os outros, podemos inverter.
Esses vieses merecem capítulos próprios.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Fulano errou.”
Pergunte:
“Que condições tornaram esse erro possível?”
🎯 Pergunta Bellacosa nº 2
“Outra pessoa razoável poderia cometer o mesmo erro nessa interface?”
Se sim:
temos problema sistêmico.
🎯 Pergunta Bellacosa nº 3
“Que barreira deveria ter impedido esse erro de virar incidente?”
Excelente conexão com Swiss Cheese.
🎯 Pergunta Bellacosa nº 4
“O comportamento foi realmente excepcional ou era prática comum?”
Normalization of Deviance.
🧠 Error-producing conditions
Uma investigação madura procura condições que aumentam probabilidade de erro:
fadiga;
interrupções;
ambiguidade;
excesso de carga;
treinamento insuficiente;
documentação ruim;
ferramentas confusas;
pressão temporal;
handoff ruim.
Isso não é desculpa.
É engenharia de fatores humanos.
☕ Fadiga não compila, mas derruba produção
Humano após 12 horas não é o mesmo após 2.
Atenção cai.
Memória de trabalho piora.
Decisão muda.
Se operação depende de perfeição humana em plantões enormes:
o sistema está mal desenhado.
🧠 Shift handover
Incidente atravessa turnos.
Informação se perde.
Novo operador toma decisão errada.
Post-mortem:
“não leu direito.”
Mas handoff era:
chat com 800 mensagens.
Quem desenhou isso?
🧠 Interface design
Botões:
RESTART
RESET
RESTORE
Todos iguais.
Usuário aperta errado.
Culpa?
Talvez interface seja uma máquina de produzir confusão.
🔥 Dangerous defaults
Campo vem pré-selecionado com produção.
Usuário queria homologação.
Clique.
Pronto.
Não diga só:
“faltou atenção.”
Default também escolheu.
🧠 Error-tolerant systems
Sistemas robustos assumem:
humanos:
clicam errado;
digitam errado;
esquecem;
interpretam ambiguamente.
Então criam:
confirmação;
preview;
undo;
rollback.
Resiliência inclui tolerância a erro humano.
☕ Ctrl+Z é civilização
Quanto mais reversível uma ação:
menos erro vira desastre.
O problema não é apenas prevenir todo erro.
Também limitar impacto.
🧠 Blast radius
Por que um operador conseguia:
afetar 100%?
Talvez acesso pudesse limitar por:
região;
partição;
canary.
Se erro individual possui blast radius global:
arquitetura precisa responder.
🔐 Least Privilege
Segurança novamente.
Operador só deveria possuir permissão necessária.
Não para “não confiar”.
Mas para limitar consequência.
Least privilege é uma defesa contra:
erro;
abuso;
comprometimento.
🧠 Two-Person Rule
Mudança irreversível?
Second pair of eyes.
Não porque duas pessoas nunca erram.
Mas porque erros não são perfeitamente correlacionados.
Barreira adicional.
Swiss Cheese.
💻 Code Review
Programador introduziu bug.
“Fulano programou errado.”
Mas:
review passou?
testes passaram?
pipeline?
lint?
unit test?
integration?
Se um bug humano atravessa tudo:
o processo também participa.
🧠 Testing is institutionalized distrust
De forma bem-humorada:
testes existem porque não confiamos nem em nós mesmos.
E isso é ótimo.
Programador profissional sabe:
“Meu código pode estar errado.”
Então automatiza verificação.
☕ Se humanos fossem perfeitos, não precisaríamos de IF
Talvez nem de abend.
Mas infelizmente também perderíamos metade da profissão.
🧠 Fundamental Attribution Error na segurança
Usuário clica phishing.
Post-mortem:
“Usuário não deveria clicar.”
Sim.
Mas:
email passou pelo filtro;
MFA era fraco;
credencial permitia acesso amplo;
monitoramento não detectou.
Treinar usuário ajuda.
Mas não pode ser única camada.
🔐 “Usuário é o elo mais fraco”
Frase comum.
Talvez preguiçosa.
Humano é parte do sistema.
Se sistema depende de nunca clicar em phishing convincente:
design é frágil.
🧠 Just Culture
Uma abordagem madura tenta distinguir:
erro humano;
comportamento de risco;
comportamento deliberadamente imprudente.
Isso evita tratar tudo igualmente.
Erro simples:
melhore sistema.
Comportamento arriscado normalizado:
mude incentivos e processo.
Violação consciente grave:
accountability adequada.
Sem caça às bruxas.
Sem ausência de responsabilidade.
☕ Blameless não significa consequence-less
Outro ponto importante.
Blameless post-mortem significa:
investigar sem assumir culpa como explicação causal.
Não significa:
ninguém responde por violações deliberadas.
Precisamos nuance.
🧠 Safety-II
Uma linha interessante da engenharia de resiliência pergunta não apenas:
“Por que deu errado?”
Mas:
“Como as pessoas conseguem fazer o sistema funcionar normalmente apesar das dificuldades?”
Isso é poderoso.
Porque muitas vezes o mesmo operador chamado de “culpado” estava salvando o sistema todos os dias.
☕ O operador que errou uma vez e salvou mil
Carlos talvez tenha:
feito 5.000 mudanças corretas.
Uma falhou.
Survivorship Bias ao contrário?
Não vemos as milhares de adaptações bem-sucedidas porque viraram rotina.
Só enxergamos uma falha.
🧠 Work-as-Imagined vs Work-as-Done
Procedimento diz:
A → B → C.
Realidade:
A → workaround → B → telefonema → C.
Gestão conhece:
Work-as-Imagined.
Operador vive:
Work-as-Done.
Quando falha:
gestão pergunta:
“Por que não seguiu o processo?”
Talvez porque o processo não descrevia o trabalho real.
🌀 Normalization of Deviance encontra Work-as-Done
Se procedimento oficial é impossível:
equipe adapta.
Adaptação vira normal.
Depois incidente.
Culpa individual.
Muito comum.
🎯 Pergunta Bellacosa nº 5
“O procedimento oficial era realmente executável nas condições reais?”
Excelente.
🧠 Framing Effect
Título do post-mortem:
“Operador derruba produção.”
Pronto.
Frame criado.
Outro:
“Mudança crítica permitia valor fora de faixa sem validação.”
Mesmo fato central.
Outro aprendizado.
🧠 Narrative Bias + framing + attribution
Temos cadeia:
evento.
Narrativa.
Personagem.
culpa.
Agora todas as ações focam:
treinamento do personagem.
Sistemas permanecem iguais.
Próxima pessoa comete mesmo erro.
🔁 Blame Cycle
ERRO
↓
CULPADO
↓
TREINAMENTO
↓
MESMO SISTEMA
↓
OUTRA PESSOA ERRA
↓
NOVO CULPADO
Isso não é melhoria contínua.
É casting.
☕ O departamento de RH não é um sistema de observabilidade
Talvez valha colocar no quadro.
🧠 Root Cause Analysis mais madura
Em vez de:
“Carlos digitou errado.”
Escreva:
TRIGGER:
valor 2500 inserido em MAXTHD
CONTRIBUTING CONDITIONS:
- interface sem range
- runbook ambíguo
- peer review omitido por urgência
- fadiga
- ambiente de teste diferente
FAILED DEFENSES:
- nenhuma validação
- nenhum confirmation gate
- monitoramento tardio
Muito melhor.
🧠 Causal layers
Podemos pensar:
Ação proximal
Valor digitado.
Condições locais
Interface, pressão, documentação.
Condições organizacionais
staffing, governança, incentivos.
Barreiras técnicas
validação, limites, rollback.
Agora temos profundidade.
🧪 Five Whys — com cuidado
Pergunte:
por que valor errado?
Porque operador digitou 2500.
Por quê?
Porque mensagem anterior dizia 2500.
Por quê?
Porque ambiente de teste usava outra escala.
Por quê?
Porque documentação não distinguia ambientes.
Agora chegamos a sistema.
Mas cuidado:
Five Whys pode produzir narrativa linear artificial.
Use como exploração, não verdade absoluta.
🧠 STAMP, FRAM e outros modelos
Existem abordagens sistêmicas mais sofisticadas para incidentes que tratam acidentes como resultado de interações e controles, não apenas falha linear.
Para nosso COBOL iniciante, a ideia importante é:
quanto mais complexo o sistema, menos provável que “uma pessoa errou” seja explicação suficiente.
☕ Não precisamos de PhD para fazer pergunta melhor
Só:
“E o que tornou isso possível?”
Já melhora muito.
🤖 IA e Fundamental Attribution Error
Imagine IA resumindo incidente:
“O operador configurou incorretamente o parâmetro, causando indisponibilidade.”
Tecnicamente pode estar correto.
Mas narrativa automatizada pode apagar contexto.
Se prompt pedir:
“Quem causou?”
a resposta buscará pessoa.
Se pedir:
“Quais condições permitiram o incidente?”
frame muda.
🧠 Prompt para post-mortem assistido por IA
Uma boa pergunta:
“Separe ação humana, condições contribuintes, barreiras ausentes, fatores organizacionais e evidências.”
Isso reduz blame frame.
🤖 Automation Bias + blame
Se ferramenta RCA aponta:
CAUSE: OPERATOR ERROR
usuários podem aceitar.
Mas classificação automática também possui frame.
Pergunte:
quais evidências?
Que condições foram consideradas?
🧠 Bias in incident taxonomy
Se sua ferramenta só possui categorias:
HUMAN ERROR
SOFTWARE
HARDWARE
NETWORK
você força incidentes para caixas simples.
Talvez precise:
contributing factors múltiplos.
Taxonomia influencia pensamento.
☕ Sistemas complexos odeiam dropdowns pequenos
Incidente:
rede + timeout + interface + workload + fadiga.
Dropdown:
“Human Error.”
Pronto.
Conhecimento destruído em 2 bytes.
🧠 Fundamental Attribution Error na carreira
Programador erra produção uma vez.
Rótulo:
“não é confiável.”
Outro acerta várias vezes.
“excelente sob pressão.”
Talvez contexto tenha sido diferente.
Recency Bias + attribution pode afetar carreira.
Isso é sério.
🧠 Performance evaluation
Avalie:
padrões;
contexto;
comportamentos;
aprendizado.
Não transforme um evento em identidade.
👨💻 Para o COBOL iniciante
Você vai errar.
Todos erram.
O objetivo profissional não é:
“Nunca errar.”
É:
testar;
revisar;
tornar erro detectável;
limitar impacto;
aprender rápido.
Um sistema que só funciona se ninguém errar não é robusto.
☕ Senioridade não é imunidade
Sênior também erra.
Às vezes mais perigosamente porque possui mais acesso.
Por isso controles precisam valer para todos.
🧠 Overconfidence + seniority
“Eu não preciso de review.”
Perigoso.
Quanto maior blast radius:
mais valor em barreiras independentes.
🪜 Autoridade também afeta accountability
Chefe manda:
“faça agora.”
Operador executa.
Falha.
Depois:
“você deveria ter recusado.”
Isso é injusto e operacionalmente tóxico.
Decisões precisam ter ownership claro.
🪡 A agulha da seringa novamente
Pedido verbal.
Depois incidente.
Ninguém lembra.
Documentar decisão ajuda não apenas juridicamente.
Ajuda causalidade.
Quem sabia?
Quem decidiu?
Com quais dados?
Isso reduz narrativa posterior conveniente.
📝 Decision Log
03:05
DECISION:
Increase MAXTHD
REQUESTED BY:
Incident Commander
EXECUTED BY:
Carlos
RATIONALE:
Queue saturation
TARGET:
2500 based on test note
Agora post-mortem vê sistema decisório.
Não apenas dedo no teclado.
🧠 Responsibility distribution
Executar não é igual a decidir.
Decidir não é igual a desenhar controle.
Precisamos distinguir.
🔐 Segregation of Duties
Também ajuda.
Quem pede.
Quem aprova.
Quem executa.
Quem valida.
Isso cria barreiras e auditabilidade.
🎯 Pergunta Bellacosa nº 6
“Quem executou a ação e quem criou as condições para que ela fosse escolhida?”
Frequentemente pessoas diferentes.
🧪 Como combater Fundamental Attribution Error
Passo 1 — Descreva comportamento, não personalidade
Não:
“Carlos foi descuidado.”
Use:
“Carlos inseriu 2500 num campo cujo valor esperado era 250.”
Passo 2 — Reconstrua contexto
O que ele sabia?
Passo 3 — Procure pressões
Tempo?
SLA?
Hierarquia?
Passo 4 — Examine interface e ferramentas
Facilitavam erro?
Passo 5 — Procure barreiras
Quais deveriam bloquear?
Passo 6 — Compare com prática real
Era exceção ou rotina?
Passo 7 — Verifique incentivos
O comportamento era recompensado?
Passo 8 — Limite blast radius
Não dependa de perfeição.
Passo 9 — Diferencie erro, risco e violação deliberada
Accountability justa.
Passo 10 — Pergunte como tornar a próxima pessoa mais segura
Essa é a melhoria.
📋 Checklist anti-Fundamental Attribution Error
[ ] Estou descrevendo comportamento ou personalidade?
[ ] O que a pessoa sabia naquele momento?
[ ] Que pressão existia?
[ ] O procedimento era claro?
[ ] A interface favorecia o erro?
[ ] Existia validação automática?
[ ] Existia peer review?
[ ] O comportamento era comum?
[ ] O sistema já havia tolerado isso antes?
[ ] Quais barreiras falharam?
[ ] Quem decidiu e quem executou?
[ ] A pessoa estava fatigada?
[ ] Os incentivos empurravam nessa direção?
[ ] Outra pessoa poderia cometer o mesmo erro?
[ ] Estamos usando “human error” como ponto final?
🧠 Substitution Test
Uma técnica excelente:
substitua a pessoa.
Pergunte:
“Se colocássemos outro profissional competente nas mesmas condições, esse erro ainda seria plausível?”
Se sim:
problema sistêmico forte.
Se não:
investigue diferenças individuais.
☕ Carlos Test
Troque Carlos por:
Maria.
João.
Você.
Se interface continua enganosa:
não era apenas Carlos.
🧠 Counterfactual design
Pergunte:
“Que pequena mudança no sistema teria impedido esse erro?”
Range validation?
Confirm?
Dropdown?
Peer review?
Essa pergunta gera ação concreta.
💡 Strong fix versus weak fix
Fraca
Treinar.
Média
Checklist.
Forte
Validação automática.
Mais forte
Tornar erro impossível.
Nem sempre podemos chegar ao último.
Mas direção importa.
🧠 Human-in-the-loop com design
Não basta dizer:
“tem humano revisando.”
Se humano recebe:
500 alertas;
30 segundos;
informação ruim,
não é controle robusto.
Contexto importa.
🔔 Alarm Fatigue novamente
Operador ignorou alerta.
“Negligente.”
Mas havia:
400 alertas/dia.
O sistema treinou o operador a ignorar.
Alarm Fatigue + attribution.
🧠 Diffusion of Responsibility
Todos receberam alerta.
Ninguém agiu.
Depois:
“ninguém teve iniciativa.”
Mas ownership era ambíguo.
Responsabilidade diluída cria comportamento.
🧠 Status Quo Bias organizacional
Processo ruim existe há anos.
Alguém finalmente falha nele.
A organização culpa indivíduo.
Mais fácil que mudar processo.
Status Quo Bias protege sistema.
💰 Sunk Cost organizacional
Ferramenta ruim custou milhões.
Operadores erram.
Em vez de substituir ferramenta:
“precisamos treinar melhor.”
Talvez sunk cost esteja defendendo design ruim.
🧠 Present Bias
Melhorar interface leva meses.
Treinamento leva duas horas.
Escolhem treinamento.
Custo imediato menor.
Present Bias.
Depois erro reaparece.
🧠 Loss Aversion
Trocar processo pode perder:
produtividade temporária.
Então mantemos.
Mesmo sabendo que produz erro.
Loss Aversion protege falha sistêmica.
🧠 Framing Effect no RCA
Compare:
“Erro do operador causou indisponibilidade.”
versus:
“Ausência de validação permitiu que uma entrada humana incorreta propagasse impacto.”
Ambos reconhecem ação humana.
Mas segundo gera engenharia.
🧠 Narrative Bias novamente
Uma história centrada em pessoa:
simples.
Uma explicação sistêmica:
menos elegante.
Mas frequentemente mais verdadeira.
🧬 Regeneração organizacional
Uma organização madura contra Fundamental Attribution Error:
para de usar “human error” como RCA final;
reconstrói contexto;
distingue execução de decisão;
analisa interfaces;
automatiza validações;
limita privilégios;
usa peer review;
considera fadiga;
revisa incentivos;
melhora work-as-done;
e pratica Just Culture.
Principalmente:
ela troca:
“Quem fez isso?”
por duas perguntas:
“O que aconteceu?”
e:
“Por que esse comportamento fazia sentido naquele contexto?”
Depois vem:
“Como impedimos que um erro parecido tenha o mesmo impacto?”
Isso é melhoria contínua.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Fundamental Attribution Error é a tendência de explicar erros dos outros pela personalidade e subestimar contexto e situação.
“Human error” raramente é uma root cause suficiente.
Entender contexto não elimina accountability.
Swiss Cheese mostra que um erro individual costuma atravessar várias barreiras ausentes ou falhas.
Hindsight Bias faz o erro parecer mais óbvio depois do resultado.
Narrative Bias procura um personagem para simplificar a história.
Normalization of Deviance pode transformar uma prática comum em “imprudência individual” apenas depois que dá errado.
Outcome Bias pode chamar a mesma ação de heroísmo quando funciona e incompetência quando falha.
Interfaces, processos, fadiga, pressão, incentivos e hierarquia moldam comportamento.
Poka-Yoke, validação, reversibilidade e blast radius menor são defesas melhores que “preste mais atenção”.
Just Culture distingue erro humano, comportamento arriscado e violação deliberada.
E principalmente:
Não pergunte apenas por que uma pessoa errou. Pergunte por que o sistema precisava que ela fosse perfeita para continuar seguro.
🕰️ De volta às 03:41
Post-mortem.
Primeira versão:
ROOT CAUSE:
OPERATOR ERROR
Nosso programador apaga.
Escreve:
TRIGGER:
MAXTHD changed from 250 to 2500.
CONTRIBUTING CONDITIONS:
- no range validation
- ambiguous runbook
- stale test-environment note
- no peer review during emergency change
- 11-hour shift
- pressure to restore service
FAILED DEFENSES:
- interface accepted unsafe value
- no confirmation
- monitoring detected impact late
Carlos olha.
— Então não foi culpa minha?
O Doctor responde:
— Você digitou o valor.
Carlos baixa os olhos.
— Então foi.
— Você participou.
Pausa.
— Mas uma investigação útil não termina aí.
O gerente pergunta:
— Qual a diferença?
Nosso programador responde:
— Se dissermos só “Carlos errou”, a próxima pessoa pode errar de novo.
— E se mudarmos tudo isso?
— A próxima pessoa pode continuar humana sem derrubar produção.
O Doctor sorri.
— Exatamente.
🔧 Um mês depois
A tela de configuração mudou.
Agora:
MAXTHD
CURRENT:
250
ALLOWED:
100–500
NEW VALUE:
____
CHANGE > 25% REQUIRES:
SECOND APPROVER
Carlos digita:
2500
Mensagem:
VALUE OUTSIDE SAFE RANGE.
CHANGE REJECTED.
Nada acontece.
Nenhuma War Room.
Nenhum diretor acordado.
Nenhum culpado.
Apenas um erro humano normal...
interrompido por um sistema que finalmente decidiu ajudar.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(ATTRIBUTION)
Dentro:
IF PERSON-MADE-ERROR
PERFORM CHECK-CONTEXT
PERFORM CHECK-FAILED-BARRIERS
END-IF.
IF RCA = 'HUMAN-ERROR'
PERFORM ASK-WHY-AGAIN
END-IF.
IF SAME-ERROR
COULD-HAPPEN-TO-ANOTHER-PERSON
PERFORM FIX-THE-SYSTEM
END-IF.
Comentário:
* PEOPLE MAKE MISTAKES.
* SYSTEMS DECIDE
* HOW EXPENSIVE THEY BECOME.
Outro:
* "BE MORE CAREFUL"
* IS NOT HIGH AVAILABILITY.
Mais um:
* BLAME FINDS A PERSON.
* ENGINEERING FINDS A CONTROL.
E naturalmente:
* BAD WOLF WAS NOT
* A TRAINING ISSUE.
Nosso jovem fecha o membro.
Horas depois chega outro incidente.
Um analista pergunta:
— Quem fez essa alteração?
Ele responde:
— Vamos descobrir.
— Para responsabilizar?
— Também precisamos saber quem executou.
— Então?
Ele abre o change record.
— Mas primeiro quero entender o que tornou essa alteração possível, razoável e perigosa.
O colega olha.
— Isso dá mais trabalho.
Ele sorri.
— Dá.
Pausa.
— Culpar alguém é muito mais rápido.
— Então por que não fazemos isso?
Ele aponta para produção.
— Porque queremos que o próximo incidente seja menos provável, não apenas que o próximo relatório tenha um nome.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica:
Pessoas cometem erros. Sistemas resilientes impedem que um erro comum precise de uma pessoa extraordinária para ser evitado.
E talvez essa seja uma das lições mais importantes de toda a nossa viagem:
o objetivo de um post-mortem não é descobrir quem merece carregar o incidente. É descobrir o que precisa mudar para que ninguém precise carregá-lo novamente.
☕🌀
Next stop: Self-Serving Bias — quando o sucesso é “mérito da nossa competência”, mas o fracasso vira culpa do fornecedor, do prazo, do usuário, da rede, da lua cheia ou de qualquer outra coisa que preserve nossa autoimagem.
