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.

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

“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.

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.

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”.

Translate

quarta-feira, 9 de novembro de 2011