 |
| Bellacosa Mainframe e a action bias |
☕ Um Café no Bellacosa Mainframe
Action Bias: Doctor Who, COBOL e o Dia em que Reiniciamos Tudo Antes de Descobrir o que Estava Errado
Uma viagem pela TARDIS dos incidentes para entender por que, diante da pressão, fazer alguma coisa parece melhor do que esperar — mesmo quando agir cedo demais pode destruir exatamente as evidências de que precisamos
03:07.
Produção.
Madrugada.
Café número quatro.
O telefone toca.
O monitoramento dispara:
ALERT
PAYMENT RESPONSE TIME
ABOVE THRESHOLD
O operador olha.
03:08.
Outro alerta:
QUEUE DEPTH +180%
03:09.
Um usuário reclama.
03:10.
O gerente entra na War Room.
— O que aconteceu?
Nosso jovem programador COBOL responde:
— Ainda estamos levantando.
O gerente pergunta:
— Já reiniciaram?
Silêncio.
— Não.
— Por quê?
— Ainda não sabemos o que está acontecendo.
O especialista olha para CICS.
— Podemos restartar a região.
O DBA:
— Talvez reciclar uma conexão.
Middleware:
— Posso reiniciar o consumer.
Outro analista:
— Vamos limpar a fila.
De repente todo mundo possui uma ação.
Ninguém possui ainda uma explicação.
03:12.
O gerente pergunta novamente:
— Então vamos fazer o quê?
Nosso programador responde:
— Eu queria observar mais dois minutos.
A frase cai na sala como se ele tivesse sugerido sacrificar um servidor aos deuses antigos.
— Observar?
— Sim.
— Produção está degradada!
— Eu sei.
— Então precisamos fazer alguma coisa.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado do console.
A porta abre.
O Doctor sai.
Olha para a fila.
Olha para CICS.
Olha para o gerente.
Depois pergunta:
— Por que vocês querem reiniciar alguma coisa?
O gerente responde:
— Porque precisamos agir.
— Isso responde por que precisam agir.
Pausa.
— Não responde por que precisam reiniciar.
Silêncio.
O Doctor sorri.
— Excelente.
— Excelente o quê?
— Vocês acabaram de demonstrar uma das armadilhas mais humanas da operação.
Bem-vindo ao:
Action Bias
Ou:
Viés da Ação
A tendência de preferir fazer alguma coisa em vez de não agir, especialmente em situações de incerteza, pressão ou medo — mesmo quando esperar, observar, coletar dados ou simplesmente não interferir ainda seria a melhor decisão.
🌀 Nossa TARDIS dos incidentes continua ficando mais perigosa
Até aqui já encontramos uma coleção respeitável:
Swiss Cheese Model — várias barreiras podem falhar juntas.
Normalization of Deviance — desvios viram rotina.
Hindsight Bias — o passado parece óbvio depois.
Confirmation Bias — buscamos provas daquilo 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á deixaram de fazer sentido.
Alarm Fatigue — alertas demais viram ruído.
Automation Bias — confiamos demais na máquina.
Drift Into Failure — pequenas adaptações empurram o sistema 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 — esquecemos a frequência real dos eventos.
Availability Heuristic — o que lembramos facilmente parece mais provável.
Outcome Bias — bom resultado parece provar boa decisão.
Overconfidence Bias — acreditamos que sabemos mais do que realmente sabemos.
Planning Fallacy — subestimamos tempo e complexidade.
Sunk Cost Fallacy — investimentos passados influenciam demais as decisões futuras.
Status Quo Bias — preferimos o estado atual porque já existe.
Present Bias — o conforto de hoje vence o custo de amanhã.
Optimism Bias — acreditamos que o pior provavelmente acontecerá com os outros.
Agora encontramos um viés especialmente perigoso durante incidentes:
agir só para sentir que estamos fazendo alguma coisa.
🧠 O que é Action Bias?
Imagine:
problema apareceu.
Você ainda não conhece a causa.
Existem duas opções:
A
Observar.
Coletar dados.
Esperar mais dois minutos.
B
Executar uma ação.
Restart.
Kill.
Clear.
Flush.
Rollback.
Reboot.
Disable.
A opção B parece mais confortável porque cria sensação de:
controle;
movimento;
progresso.
Mesmo que ainda não saibamos se ela ajuda.
Representando:
INCERTEZA
↓
DESCONFORTO
↓
“PRECISO FAZER ALGO”
↓
AÇÃO
↓
SENSAÇÃO DE CONTROLE
O problema é que:
sensação de controle não é evidência de controle.
☕ Bellacosa Mainframe: o restart mágico
Existe uma terapia universal na informática:
restart.
Aplicação lenta?
Restart.
CICS estranho?
Restart.
MQ consumer parado?
Restart.
Servidor respondeu torto?
Restart.
Notebook?
Restart.
Pessoa?
Café.
Restart funciona muitas vezes.
E justamente por funcionar, pode virar ritual.
🧙 “Desliga e liga novamente”
É quase um feitiço.
Em muitos casos:
resolver estado inconsistente;
limpar recursos;
recriar conexões;
liberar memória;
recarregar configuração
realmente ajuda.
O problema não é restartar.
O problema é:
restartar antes de entender o suficiente para saber o que estamos destruindo.
🧠 Reiniciar também apaga evidências
Imagine um problema transitório.
Antes do restart temos:
threads;
locks;
queues;
dumps;
memory state;
connection state;
logs correlacionados.
Depois do restart:
parte disso desaparece.
O sistema volta.
Ótimo.
Pergunta:
“Qual era a causa?”
Resposta:
“Não sabemos. Restart resolveu.”
Agora o incidente morreu.
Mas o conhecimento também.
💀 Fix by reboot
Na próxima semana:
mesmo problema.
Restart.
No mês seguinte:
restart.
Depois vira runbook:
IF SYSTEM-SLOW
RESTART
Parabéns.
Transformamos Action Bias em procedimento operacional.
👻 Easter Egg nº 1 — Sonic Screwdriver
Companion:
— Doctor, a porta não abre.
Doctor pega sonic screwdriver.
Companion:
— Você sabe o que está errado?
— Não.
— Então por que está usando isso?
— Porque segurar uma ferramenta me faz parecer ocupado.
Pausa.
— Ah.
Action Bias explicado com excelente merchandising.
🧠 A pressão social para parecer ativo
Durante incidentes existe um elemento poderoso:
visibilidade.
Se você está olhando gráficos:
parece que não está fazendo nada.
Se digita comando:
parece ação.
Se reinicia:
ação.
Se altera parâmetro:
ação.
Se diz:
“Vamos observar dois minutos”
pode parecer passividade.
Esse incentivo social é perigoso.
🪜 Authority Gradient entra imediatamente
Gerente:
— Faça alguma coisa.
Especialista sabe:
mais dados ajudariam.
Mas gerente está pressionando.
Então:
F CICS,RESTART
Não porque evidência apontou.
Porque autoridade exigiu movimento.
Action Bias + Authority Gradient.
👥 Groupthink também gosta de ação
Sala inteira nervosa.
Uma pessoa sugere restart.
Outra:
— Boa.
Terceira:
— Vamos.
Agora consenso se forma em torno de algo concreto.
Agir une o grupo.
Observar parece indecisão.
🧠 “At least we tried something”
Depois, se falhar:
“Pelo menos fizemos alguma coisa.”
Isso é emocionalmente reconfortante.
Mas sistemas não recompensam intenção.
Precisamos perguntar:
a ação tinha fundamento?
🎯 O custo invisível da ação
Toda ação em produção possui custo potencial.
Restart pode:
derrubar sessões;
perder transações em voo;
gerar backlog;
alterar timing;
mascarar causa.
Rollback pode:
introduzir incompatibilidade.
Kill pode:
deixar dados parciais.
Flush pode:
perder cache útil.
Logo:
“fazer alguma coisa” não é neutro.
🧠 Inação também pode ser ação
Importante:
Action Bias não significa:
“nunca faça nada.”
Às vezes agir rápido é essencial.
Disco enchendo.
Fraude em andamento.
Dado sendo corrompido.
Incêndio.
Você precisa agir.
O ponto é:
não confundir velocidade com qualidade.
☕ Emergência real: STOP primeiro
Imagine:
processamento duplicando pagamento.
Nesse caso:
STOP
pode ser a melhor ação mesmo sem saber causa.
Porque custo de continuar é alto.
Ou seja:
às vezes agir antes do RCA é correto.
Mas a ação precisa estar ligada a:
impacto;
contenção;
critério.
Não ansiedade.
🧠 Containment versus Random Action
Essa distinção é excelente.
Contenção
Sabemos:
processamento está causando dano.
Então interrompemos.
Action Bias
Não sabemos o que ocorre.
Mas reiniciamos algo porque precisamos sentir progresso.
Uma é gestão de risco.
Outra pode ser reflexo.
🧀 Swiss Cheese + Action Bias
Pense em uma barreira:
diagnóstico antes da mudança.
Action Bias fura.
Outra:
preservar evidência.
Fura.
Outra:
change control.
Fura.
De repente, um incidente original pequeno ganha um segundo incidente:
causado pela resposta.
🔥 Incidente secundário
Essa é uma das coisas mais interessantes.
Primeiro problema:
latência.
Equipe reinicia Db2.
Agora:
indisponibilidade.
O primeiro incidente talvez fosse pequeno.
A resposta criou o maior.
Em aviação, medicina e operações complexas isso é um princípio conhecido:
intervenções podem introduzir novos riscos.
TI não é diferente.
🧠 Iatrogenia operacional
Na medicina, existe a ideia de dano causado pelo próprio tratamento.
Podemos brincar com:
iatrogenia operacional.
O sistema tinha um problema.
Nós tentamos corrigir.
Criamos outro.
Perfeito tema Bellacosa.
💻 Exemplo COBOL
Job está lento.
Operador cancela.
Depois percebe:
estava em fase de commit.
Agora restart precisa:
reconciliation;
cleanup;
rollback de dados.
Talvez esperar mais dois minutos fosse melhor.
A ação antecipada aumentou trabalho.
⏱️ “Está parado” talvez não esteja parado
Batch pode parecer:
sem output.
Mas pode estar:
sort;
checkpoint;
commit;
I/O pesado;
lock wait temporário.
Antes de cancelar:
observe.
SDSF.
SMF.
DB2 thread.
CPU.
I/O.
Joblog.
Evidence first.
☕ O CANCEL que vira aventura
03:00.
— Job está há 20 minutos sem mensagem.
— Cancela.
03:01.
JOB CANCELLED
03:02.
— Como restartamos?
Silêncio.
Clássico.
🧠 Planning Fallacy pode alimentar Action Bias
Planejamos mudança em 40 minutos.
Já passou uma hora.
Pressão aumenta.
Agora qualquer problema produz:
“faz alguma coisa!”
O cronograma irreal reduz paciência diagnóstica.
Planning Fallacy cria pressão.
Action Bias produz intervenção prematura.
▶️ Plan Continuation Bias também entra
Plano está dando errado.
Ao invés de parar e reavaliar:
fazemos mais uma ação para manter plano vivo.
Ajusta parâmetro.
Restart.
Mais CPU.
Mais threads.
Mais retries.
Tudo para continuar.
Action Bias pode virar braço operacional do Plan Continuation Bias.
🧠 Sunk Cost também
Já gastamos três horas.
Então:
“Vamos tentar mais um restart.”
Mais 30 minutos.
Depois outro.
Porque parar agora faria esforço anterior parecer perdido.
Sunk Cost + Action Bias:
loop infinito.
🔁 O loop do “mais uma tentativa”
AÇÃO
↓
NÃO RESOLVEU
↓
MAIS AÇÃO
↓
NÃO RESOLVEU
↓
AÇÃO MAIS AGRESSIVA
Em algum momento:
ninguém mais lembra qual era o estado inicial.
Excelente maneira de destruir observabilidade.
🔍 Confirmation Bias
Hipótese:
CICS.
Fazemos restart de CICS.
Sistema melhora por acaso.
Conclusão:
“Era CICS.”
Talvez não.
Pode ter coincidido com:
fila drenando;
lock expirando;
dependência voltando.
Outcome Bias entra depois e transforma ação aleatória em “solução comprovada”.
🧠 Action Bias + Outcome Bias
Esse é um casamento perigoso.
Ação não fundamentada.
Resultado melhora.
Outcome Bias:
ação foi correta.
Agora ela entra no runbook.
Próximo incidente:
fazemos automaticamente.
É assim que superstição vira operação.
🧙 Ritual operacional
Pode existir:
1. Restart CICS
2. Clear MQ
3. Bounce JVM
4. Pray
Ninguém sabe exatamente por quê.
Mas:
“Funciona.”
Talvez às vezes.
Sem causalidade demonstrada, temos ritual.
👻 Easter Egg nº 2 — o botão vermelho
Doctor:
— O que esse botão faz?
Operador:
— Não sabemos.
— Então por que apertam?
— Porque da última vez o sistema voltou.
— E apertaram antes ou depois de o sistema começar a voltar?
Silêncio.
Correlação manda lembranças.
🧠 Automation Bias pode produzir Action Bias automatizado
Sistema detecta anomalia.
Runbook automático:
restart.
Ótimo até o dia em que:
anomalia é sintoma de sobrecarga;
restart multiplica demanda;
todos os nodes reiniciam;
thundering herd.
Agora automatizamos o impulso.
Action Bias em velocidade de máquina.
🤖 Auto-remediation
Auto-remediation pode ser excelente.
Mas precisa:
detecção confiável;
scope limitado;
guardrails;
cooldown;
observabilidade;
rollback;
escalation.
Não:
IF ALERT
RESTART EVERYTHING
Mesmo que seja tentador.
🚨 Alarm Fatigue + Action Bias
Muitos alertas.
Finalmente um vermelho forte.
Operador reage agressivamente porque quer “resolver logo”.
Fadiga reduz qualidade do diagnóstico.
Action Bias oferece saída psicológica:
faça algo e o alerta cala.
🧠 Normalcy Bias parece oposto — mas não é
Normalcy Bias:
espere, vai normalizar.
Action Bias:
faça algo agora.
Parecem opostos.
E são em parte.
Mas podem ocorrer em sequência:
primeiro esperamos demais.
Depois percebemos gravidade.
Entramos em pânico.
Agora fazemos coisas demais.
Isso acontece muito.
🌀 Do nothing → do everything
Primeiros 20 minutos:
“vai passar.”
Minuto 21:
“reinicia tudo!”
Uma bela oscilação entre Normalcy Bias e Action Bias.
Maturidade mora no meio:
monitorar;
usar triggers;
agir proporcionalmente.
🧠 Optimism Bias também pode inverter
Antes:
“não vai dar problema.”
Depois:
problema aparece.
Agora surpresa aumenta ansiedade.
Action Bias.
Quem não preparou contingência tende a improvisar.
Otimismo excessivo ontem vira hiperatividade hoje.
🔐 Segurança cibernética
Alerta de possível ataque.
Alguém:
— Bloqueia todos os acessos externos!
Talvez correto.
Talvez derrube negócio inteiro.
Ação de contenção precisa considerar:
escopo;
evidência;
impacto.
Não pode ser simplesmente:
“faz alguma coisa.”
🏦 Fraude
Transação suspeita.
Bloquear conta imediatamente?
Talvez.
Mas false positive pode prejudicar cliente.
Base Rate Neglect volta.
Action Bias pode reagir a um evento raro sem considerar probabilidade.
🧠 Base Rate + Action Bias
Quanto menos entendemos a taxa real de ameaça, mais fácil reagir exageradamente.
Evento dramático.
Disponibilidade mental alta.
Action Bias:
aja agora.
Base Rate Neglect:
esquece frequência.
Availability Heuristic:
lembra do incidente recente.
Combo poderoso.
🧪 Observe, Orient, Decide, Act
Uma estrutura útil é pensar no ciclo:
OODA
Observe.
Orient.
Decide.
Act.
Action Bias tenta pular:
Observe.
Orient.
Decide.
E ir diretamente para:
ACT.
A famosa metodologia:
AODA
ACT
OH NO
DO SOMETHING ELSE
AGAIN
Talvez menos recomendada.
☕ OODA Bellacosa
Observe
O que realmente está acontecendo?
Orient
Que contexto temos?
Decide
Qual ação tem melhor relação risco/benefício?
Act
Execute.
Depois:
observe novamente.
Isso é ação disciplinada.
🧠 Tempo diagnóstico não é tempo perdido
Se dois minutos de observação evitam restart de uma hora:
foram extremamente produtivos.
Mas precisamos culturalmente reconhecer isso.
Pensar também é trabalho.
⏱️ Diagnostic Budget
Em incidentes podemos definir:
temos cinco minutos para levantar dados antes de ação X.
Isso evita tanto:
paralisia;
quanto ação impulsiva.
Exemplo:
IF DATA CORRUPTION CONFIRMED
STOP IMMEDIATELY
ELSE
OBSERVE 5 MIN
REASSESS
Agora existe critério.
🧠 Action Threshold
Defina previamente:
qual sinal exige ação?
Exemplo:
FAILURE RATE > 5%
AND TREND RISING
→ STOP PROCESSING
Isso reduz necessidade de improvisar.
🎯 Pergunta Bellacosa nº 1
Quando alguém disser:
“Precisamos fazer alguma coisa.”
Pergunte:
“Qual problema específico essa ação pretende resolver?”
Se resposta for vaga:
cuidado.
🎯 Pergunta Bellacosa nº 2
Outra:
“Que evidência esperamos ver se essa ação funcionar?”
Isso transforma ação em teste.
🎯 Pergunta Bellacosa nº 3
Outra:
“O que perdemos se fizermos isso agora?”
Estado?
Logs?
Sessões?
Dados?
Tempo?
🎯 Pergunta Bellacosa nº 4
E:
“Quanto custa esperar dois minutos?”
Talvez muito.
Talvez quase nada.
Precisamos saber.
🧪 Ação como experimento
Uma ação pode ser ótima se planejada como experimento.
Exemplo:
hipótese:
consumer X está bloqueado.
Ação:
restart apenas X.
Previsão:
queue depth começa a cair em 2 min.
Se cair:
hipótese ganha suporte.
Se não:
reavalie.
Muito melhor que:
restartar tudo.
🧠 Falsifiability
Ação madura precisa produzir informação.
Se:
“vamos restartar e ver”
mas qualquer resultado será interpretado como sucesso,
não temos teste.
Temos ritual.
📊 Before/After
Antes da ação:
registre:
QUEUE: 12.000
RATE IN: 500/s
RATE OUT: 200/s
TIMEOUT: 8%
Depois:
compare.
Sem baseline:
não sabemos se ação melhorou.
📝 Decision Log
03:14
HYPOTHESIS: MQ CONSUMER STALLED
ACTION:
Restart consumer 02 only
EXPECTED:
outflow > inflow within 3 min
OWNER:
Carlos
ROLLBACK:
N/A
RESULT:
No improvement
Excelente.
Agora próximo passo possui evidência.
🧠 Diffusion of Responsibility
Curiosamente, Action Bias pode surgir quando ninguém possui coordenação.
Cada especialista faz algo.
DBA altera.
Middleware reinicia.
Sysprog mexe.
Aplicação testa.
Cinco ações simultâneas.
Agora:
se melhora, qual resolveu?
Ninguém sabe.
Ownership ajuda a controlar ação.
👥 War Room sem Incident Commander
É uma jam session.
Todo mundo toca.
Nenhuma partitura.
Action Bias cria “ação paralela”.
Às vezes poderosa.
Às vezes destrói causalidade.
🧭 Incident Commander como scheduler
Já brincamos:
Incident Commander é o JES humano.
Agora novamente.
Ele controla:
qual ação;
quem;
quando;
dependências.
Sem isso:
dez jobs mexendo na mesma região.
💻 Parallel Changes são inferno diagnóstico
Se você:
restarta CICS;
aumenta threads;
limpa fila;
altera DB2
ao mesmo tempo,
e sistema melhora:
qual era a causa?
Não sabe.
Melhor:
ações controladas quando possível.
🧠 One Change at a Time
Não é regra absoluta.
Emergência pode exigir paralelismo.
Mas quando diagnóstico importa:
uma mudança de cada vez reduz confusão.
🔥 Tempo crítico muda tudo
Se clientes estão sendo debitados duas vezes:
não espere laboratório perfeito.
Contain.
Depois diagnostique.
Action Bias não significa ser lento.
Significa:
agir proporcionalmente à urgência e à evidência.
🧠 Reversibilidade
Quanto menos reversível uma ação:
mais cuidado.
Restart simples?
Talvez baixo risco.
Delete de fila?
Alto.
ALTER de dados?
Muito alto.
Defina escala.
📊 Action Risk Matrix
AÇÃO REVERSÍVEL? IMPACTO
Restart worker SIM BAIXO
Restart CICS PARCIAL MÉDIO
Clear queue NÃO ALTO
Delete data NÃO CRÍTICO
Quanto maior impacto:
mais evidência e aprovação.
🧠 Irreversible Action Gate
Uma regra útil:
para ação irreversível:
pause.
Second pair of eyes.
Confirm.
Isso reduz impulsividade.
🔐 “rm -rf” filosófico
Qualquer comando equivalente a:
DELETE
PURGE
CLEAR
DROP
merece um microsegundo adicional de humildade.
Às vezes muitos.
👨💻 COBOL iniciante: não mexa em tudo ao mesmo tempo
Bug.
Você altera cinco trechos.
Compila.
Funciona.
Qual mudança resolveu?
Não sabe.
O mesmo princípio.
Debugging científico:
hipótese;
uma mudança;
teste;
resultado.
🧪 Scientific Method em produção
Observe.
Hipótese.
Experimento.
Resultado.
Atualize.
Action Bias quer:
ação;
ação;
ação.
Método científico quer:
informação.
🧠 Curiosity beats panic
A pergunta:
“O que isso está tentando nos dizer?”
é melhor que:
“O que podemos reiniciar?”
Curiosidade reduz reflexo.
☕ Bellacosa Mainframe: logs antes de reboot
Antes de qualquer restart:
capture:
SDSF;
dumps;
queue depths;
threads;
locks;
CPU;
I/O;
timestamps.
Crie snapshot.
Cinco minutos depois, você pode agradecer.
📸 Preserve Evidence
Checklist:
[ ] Logs
[ ] Metrics
[ ] Dump
[ ] Queue state
[ ] Thread state
[ ] Recent changes
[ ] Timestamp
[ ] Correlation IDs
Depois aja.
Quando houver tempo.
🧠 Forensic Readiness
Isso não vale só segurança.
Operação também.
Você quer capacidade de reconstruir estado antes da intervenção.
Senão:
“restart resolveu”
vira RCA.
😄 RCA mais triste do mundo
ROOT CAUSE:
UNKNOWN
RESOLUTION:
RESTART
PREVENTIVE ACTION:
RESTART FASTER NEXT TIME
Quase arte contemporânea.
🔁 Action Bias institucional
Algumas organizações premiam:
velocidade de reação.
Bom.
Mas se única métrica é:
“tempo até primeira ação”,
talvez pessoas façam qualquer ação cedo.
Melhor medir:
tempo até contenção útil;
tempo até hipótese;
tempo até recuperação.
🧠 Metric Design matters
Se você recompensa movimento:
receberá movimento.
Se recompensa redução de risco:
talvez receba decisões melhores.
Goodhart aparece de novo.
🏆 Hero Culture
Pessoa reinicia tudo e salva o dia.
Aplausos.
Pessoa observa 90 segundos, identifica causa e evita outage:
menos drama.
Outcome Bias faz primeiro parecer herói.
Mas segunda resposta pode ser superior.
🧠 Action Bias + Heroism
Cultura de heróis adora ação visível.
Botões.
Comandos.
Telefonemas.
Não gosta tanto de:
hipótese;
pausa;
análise.
Isso precisa ser corrigido.
🌀 Drift Into Failure
Ao longo do tempo:
runbooks ganham mais ações rápidas.
Menos diagnóstico.
Sistema fica dependente de intervenções.
Workarounds acumulam.
Action Bias vira Drift.
🧠 Present Bias
Resolver sintoma agora:
restart.
Root cause amanhã.
Amanhã nunca chega.
Present Bias protege Action Bias.
Então:
restart vira processo permanente.
🧠 Status Quo Bias
“É assim que tratamos.”
Mesmo sem saber por quê.
Ação antiga vira status quo.
Ninguém questiona.
💸 Cost of Action
Precisamos contabilizar:
downtime;
perda de contexto;
trabalho;
risco;
reprocessamento.
Uma intervenção possui custo.
Isso ajuda a tornar a decisão menos emocional.
📋 Checklist anti-Action Bias
[ ] Qual problema estamos tentando resolver?
[ ] Qual é nossa hipótese?
[ ] Qual evidência suporta essa ação?
[ ] Qual impacto se esperarmos?
[ ] Quanto tempo podemos observar?
[ ] A ação é reversível?
[ ] O que ela pode destruir?
[ ] Preservamos evidências?
[ ] Qual resultado esperamos após agir?
[ ] Como saberemos se funcionou?
[ ] Estamos agindo por evidência ou pressão?
[ ] Existem várias mudanças acontecendo ao mesmo tempo?
[ ] Quem coordena?
[ ] Existe alternativa menos invasiva?
[ ] Precisamos conter ou diagnosticar primeiro?
🧪 Passo a passo para combater Action Bias
Passo 1 — Nomeie o problema
Não:
“Produção ruim.”
Mas:
“Failure rate de pagamento subiu de 0,2% para 8%.”
Passo 2 — Defina urgência
Está causando dano agora?
Sim?
Contain.
Não?
Talvez observe.
Passo 3 — Preserve estado
Colete evidência.
Passo 4 — Formule hipótese
O que acreditamos?
Passo 5 — Escolha ação mínima
A menor mudança capaz de testar ou conter.
Passo 6 — Defina resultado esperado
Como saberemos?
Passo 7 — Execute
Owner claro.
Passo 8 — Observe
Não saia fazendo próxima coisa instantaneamente.
Passo 9 — Atualize hipótese
Funcionou?
Não?
Passo 10 — Documente
Para não transformar coincidência em ritual.
🧠 Minimum Effective Intervention
Uma ideia útil:
mínima intervenção efetiva.
Não mude cinco componentes se um basta.
Quanto menor o blast radius:
melhor.
💥 Blast Radius
Toda ação possui área de impacto.
Reiniciar worker:
pequeno.
Reiniciar cluster:
maior.
IPL?
Bem...
Talvez queira café antes.
☕ O IPL como martelo de Thor
Se alguém sugere:
“Faz IPL.”
Logo no início da investigação...
Talvez seja hora de perguntar gentilmente:
“Qual é nossa hipótese mesmo?”
🧠 Escalation Ladder
Crie sequência:
1. Observe
2. Ajuste componente isolado
3. Restart worker
4. Restart serviço
5. Restart região
6. Failover
7. Medidas maiores
Suba conforme evidência e impacto.
Não comece no apocalipse.
🧪 Timeboxed Observation
Uma defesa contra parecer passivo:
“Vamos observar por três minutos, com critérios X e Y.”
Isso não é inação.
É decisão explícita.
⏰ Reassessment Timer
DECISION:
Observe
UNTIL:
03:18
ACT IF:
Failure > 10%
Queue > 20k
Data loss detected
Agora todos sabem que há plano.
🧠 “Wait” sem critério é Normalcy Bias
Importantíssimo.
Não transforme defesa contra Action Bias em:
“espera para ver.”
Sem timer.
Sem threshold.
Isso vira Normalcy Bias.
Precisamos:
observação ativa.
👀 Active Observation
Observe:
tendência;
correlação;
impacto;
novos sinais.
Não:
ficar tomando café olhando luzes piscarem.
Embora café continue permitido.
🧠 Action versus Reaction
Engenharia madura:
ação deliberada.
Action Bias:
reação.
A diferença é pequena na velocidade.
Enorme na qualidade.
🔄 OODA novamente
OBSERVE
↓
ORIENT
↓
DECIDE
↓
ACT
↓
OBSERVE
A última seta é crítica.
Toda ação produz novo estado.
Você precisa olhar.
🧠 Feedback Loop
Sem feedback:
ação vira disparo no escuro.
Com feedback:
controle.
Isso é teoria básica de sistemas aplicada à War Room.
🎛️ Controle sem sensor é chute
Se você altera parâmetro sem medir resultado:
não está controlando.
Está torcendo.
Otimism Bias manda lembranças.
🧬 Regeneração organizacional
Como uma organização se recupera de Action Bias?
Ela:
define critérios de contenção;
treina diagnóstico;
cria timers;
preserva evidência;
usa ações mínimas;
reduz mudanças simultâneas;
fortalece Incident Command;
documenta resultados;
faz drills;
recompensa decisões boas, não apenas ações rápidas.
Principalmente:
ensina uma frase:
“Não agir por dois minutos pode ser uma ação deliberada.”
📓 Diário do Doctor
Se guardar apenas algumas ideias desta viagem, guarde estas:
Action Bias é a tendência de agir simplesmente porque agir parece melhor que esperar.
Ação visível não é sinônimo de progresso.
Restart pode resolver o sintoma e destruir evidência.
Containment e ação impulsiva não são a mesma coisa.
Ações podem criar incidentes secundários.
Outcome Bias transforma ações sortudas em rituais.
Authority Gradient e pressão social podem empurrar equipes para agir cedo demais.
Observation time pode ser investimento diagnóstico.
Toda ação precisa de hipótese, resultado esperado e feedback.
Quanto mais irreversível a ação, maior o rigor.
O melhor primeiro passo costuma ser a menor intervenção que preserve informação e reduza risco.
E principalmente:
Em uma War Room, a pergunta não é “o que podemos fazer agora?”. É “qual ação melhora nossa situação com o menor risco e a melhor evidência disponível?”.
🕰️ De volta às 03:10
A TARDIS retorna.
O gerente pergunta:
— Já reiniciaram?
Nosso programador responde:
— Ainda não.
— Por quê?
— Estamos comparando entrada e saída da fila.
03:11.
INPUT RATE: 700/s
OUTPUT RATE: 680/s
03:12.
INPUT RATE: 500/s
OUTPUT RATE: 690/s
Fila começa a cair.
O DBA observa:
— Lock wait também caiu.
03:13.
Failure rate:
8% → 4% → 1.2%
O gerente pergunta:
— Então se tivéssemos reiniciado?
O especialista responde:
— Teríamos criado downtime num sistema que já estava se recuperando.
Silêncio.
O Doctor sorri.
— Fascinante.
— O quê?
— Vocês acabaram de resolver um incidente sem tocar no sistema.
O gerente:
— Mas não fizemos nada.
Nosso programador aponta para a timeline.
— Fizemos.
— O quê?
— Observamos, medimos e decidimos não interferir enquanto a tendência melhorava.
O Doctor concorda.
Não confunda ausência de comando com ausência de decisão.
🥚 Easter Egg final
Na manhã seguinte surge:
BELLACOSA.BIAS(ACTION)
Dentro:
IF SOMEONE-SAYS
'DO-SOMETHING'
PERFORM ASK-WHAT-PROBLEM
END-IF.
IF ACTION-IS-IRREVERSIBLE
PERFORM SECOND-PAIR-OF-EYES
END-IF.
IF OBSERVATION-HAS-VALUE
PERFORM WAIT-AND-MEASURE
END-IF.
Comentário:
* MOTION IS NOT PROGRESS.
Outro:
* RESTART IS A TOOL.
* NOT A DIAGNOSIS.
Outro:
* IF YOU CHANGE EVERYTHING,
* YOU LEARN NOTHING.
E naturalmente:
* BAD WOLF PRESSED THE BUTTON.
Nosso jovem fecha o membro.
Horas depois chega mensagem:
“Sistema está lento. Reinicio?”
Ele responde:
“Talvez.”
— Talvez?
“Primeiro me diga o que está lento, desde quando e qual tendência.”
Cinco minutos depois:
consumer identificado.
Uma única instância travada.
Restart localizado.
Fila recupera.
Nenhuma região inteira reciclada.
Nenhuma evidência perdida.
Nenhuma magia.
Apenas uma mudança importante de comportamento:
antes, o desconforto produzia ação.
Agora, o desconforto produz pergunta.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica:
Às vezes coragem é apertar o botão. Às vezes coragem é manter a mão longe dele por tempo suficiente para entender o que está acontecendo.
☕🌀
Next stop: Omission Bias — quando fazer algo parece moralmente mais perigoso do que deixar acontecer, e a organização começa a preferir o risco da inação porque ele parece menos “culpável”.
