☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

terça-feira, 11 de janeiro de 2011

Normalcy Bias: Doctor Who, COBOL e o Dia em que Tudo Já Estava Dando Errado — Mas Todo Mundo Achou que Ia Passar

Bellacosa Mainframe e o normalcy bias

☕ Um Café no Bellacosa Mainframe

Normalcy Bias: Doctor Who, COBOL e o Dia em que Tudo Já Estava Dando Errado — Mas Todo Mundo Achou que Ia Passar

Uma viagem pela TARDIS dos incidentes para entender por que, diante de sinais anormais, nosso cérebro insiste em acreditar que o mundo continuará funcionando como sempre funcionou

09:04.

Segunda-feira.

Café quente.

Mainframe acordado.

Usuários trabalhando.

Tudo normal.

Então aparece:

WARNING
PAYMENT RESPONSE TIME ABOVE BASELINE

O operador olha.

— Deve ser pico de volume.

09:11.

QUEUE DEPTH +40%

— Segunda-feira.

09:18.

TIMEOUT RATE +180%

— Deve estabilizar.

09:26.

Primeiras reclamações.

— Usuário sempre reclama antes de a coisa ficar normal.

09:34.

FAILED TRANSACTIONS: 417

O gerente pergunta:

— Precisamos abrir incidente?

Alguém responde:

— Vamos esperar mais dez minutos.

09:41.

Mais falhas.

09:46.

Mais reclamações.

09:49.

O sistema não está estabilizando.

Mas a mente coletiva ainda trabalha com uma convicção silenciosa:

“Provavelmente vai voltar ao normal.”

VWORP.

VWORP.

VWORP.

A TARDIS surge no corredor.

A porta abre.

O Doctor sai.

Olha para o painel.

Depois para os operadores.

— Há quanto tempo isso está piorando?

— Quarenta minutos.

— E o que vocês estão esperando?

— Que normalize.

O Doctor inclina a cabeça.

— Com base em quê?

Silêncio.

— Bem... normalmente normaliza.

Ele olha novamente para o gráfico.

— Ah.

Pausa.

— Então vocês estão usando o fato de ontem ter terminado bem como evidência de que hoje também terminará?

Mais silêncio.

— Isso é encantador.

Outra pausa.

— E profundamente perigoso.

Bem-vindo ao:



Normalcy Bias

Ou:

Viés de Normalidade

A tendência de subestimar sinais de perigo e assumir que, mesmo diante de eventos anormais, a situação provavelmente continuará parecida com aquilo que conhecemos.


🌀 Nossa TARDIS já viu muita coisa

Até aqui encontramos:

Swiss Cheese Model — várias defesas imperfeitas podem falhar juntas.

Normalization of Deviance — desvios podem virar rotina.

Hindsight Bias — depois do evento tudo parece óbvio.

Confirmation Bias — buscamos o que confirma nossas crenças.

Anchoring Bias — a primeira explicação pesa demais.

Groupthink — grupos convergem cedo demais.

Authority Gradient — hierarquia pode silenciar quem percebe risco.

Plan Continuation Bias — continuamos planos que já deveriam ser revistos.

Alarm Fatigue — alertas demais viram ruído.

Automation Bias — confiamos demais na máquina.

Drift Into Failure — pequenas decisões e perda de margem levam o sistema para a borda.

Diffusion of Responsibility — todo mundo vê e ninguém assume.

Agora o problema é diferente:

o perigo está visível, mas não parece real o bastante.


🧠 O que é Normalcy Bias?

Normalcy Bias é a tendência de acreditar que as coisas continuarão aproximadamente como sempre foram, mesmo quando surgem evidências de mudança séria.

O cérebro trabalha com modelos.

Ele aprende:

segunda-feira tem pico.

fila cresce.

depois cai.

Então, quando vê outra fila crescendo, tenta encaixar no padrão conhecido.

Isso é útil.

Sem esse mecanismo ficaríamos em pânico a cada pequena variação.

Mas em uma emergência real, essa mesma tendência pode atrasar resposta.

Representando:

SINAL ANORMAL
     ↓
“ISSO JÁ ACONTECEU”
     ↓
“DEVE PASSAR”
     ↓
ESPERA
     ↓
SINAL PIORA
     ↓
“AINDA DEVE PASSAR”
     ↓
ATRASO NA REAÇÃO

☕ Bellacosa Mainframe: “isso acontece no fechamento”

Imagine:

CPU: 91%

Operador:

— No fechamento sempre sobe.

Depois:

CPU: 95%
QUEUE: +120%

— Ainda dentro do esperado.

Depois:

CPU: 97%
QUEUE: +300%
TIMEOUTS: 870

— Deve ser o volume.

Talvez seja.

Mas a pergunta correta é:

“Em que ponto deixamos de estar dentro do comportamento conhecido?”

Normalcy Bias prospera quando não existe esse ponto definido.


📈 Baseline novamente salva o dia

Se você apenas pensa:

“isso costuma acontecer”

fica sujeito à memória.

Melhor:

BASELINE DE SEGUNDA-FEIRA

CPU normal: 72–84%
Queue normal: até 2.500
Timeout normal: < 20/min

Hoje:

CPU: 96%
Queue: 18.000
Timeout: 310/min

Agora fica difícil dizer:

“segunda-feira normal.”

Dados ajudam a quebrar o viés de normalidade.


🧠 “Já aconteceu antes” pode significar duas coisas

Frase:

“Já aconteceu antes.”

Pode significar:

  1. conhecemos esse comportamento e sabemos por que é seguro;

ou:

  1. sobrevivemos a ele antes e estamos presumindo que sobreviveremos novamente.

Essas coisas não são iguais.

A segunda se conecta diretamente com:

Normalization of Deviance.


🧩 Normalcy Bias versus Normalization of Deviance

Os nomes parecem parentes.

São.

Mas não são a mesma coisa.

Normalization of Deviance

O desvio se torna aceito ao longo do tempo.

“Esse warning é normal.”

Normalcy Bias

Diante de uma situação potencialmente grave, presumimos que ela não será tão grave e que a rotina continuará.

“Isso deve melhorar sozinho.”

Uma fala sobre:

o que aceitamos como normal.

A outra:

o que esperamos que continue normal.

As duas juntas podem ser perigosíssimas.


🚨 Exemplo

Warning diário.

Normalizamos.

Um dia o warning aparece com intensidade muito maior.

Normalcy Bias:

“É aquele warning de sempre.”

Mas não é mais o mesmo comportamento.

A familiaridade mascara mudança de escala.


👻 Easter Egg nº 1 — “Sempre volta”

Imagine uma estação espacial.

Luzes piscando.

Um técnico diz:

— A energia sempre volta.

Doctor:

— E voltou?

— Nas outras vezes.

— E desta?

— Ainda não.

— Então talvez devêssemos parar de usar as outras vezes como plano de recuperação.

Essa frase vale para produção.


🧠 Por que fazemos isso?

Porque admitir que existe emergência é caro.

Psicologicamente.

Organizacionalmente.

Operacionalmente.

Se dissermos:

“Temos incidente”

precisamos:

abrir War Room;

escalar;

interromper mudança;

avisar negócio;

talvez chamar diretor;

talvez perder SLA.

Esperar é mais confortável.

Talvez resolva sozinho.

Então Normalcy Bias pode ser reforçado por incentivos.


💰 Declarar incidente tem custo social

Imagine uma cultura onde abrir Severity 1 gera:

reuniões;

relatórios;

cobrança;

culpa;

PowerPoint para diretoria.

O que acontece?

Pessoas retardam declaração.

Não necessariamente conscientemente.

Pensam:

“Vamos esperar mais cinco minutos.”

Isso é perigoso.

A cultura tornou reconhecimento da realidade caro.


🚦 Better safe than embarrassed

Uma organização madura prefere:

falso positivo controlado;

a incidente reconhecido tarde.

Se alguém declara incidente e depois descobre que era menor:

ótimo.

Se for ridicularizado:

da próxima vez esperará.

Normalcy Bias ganha ajuda da cultura.


🧀 Swiss Cheese + Normalcy Bias

Imagine barreira:

detecção humana.

O alerta aparece.

Mas humano pensa:

“não é grave.”

Mais um buraco.

Depois barreira:

escalation.

Não escalamos porque:

“vai passar.”

Outro buraco.

Depois:

rollback.

Não rollbackamos porque:

“ainda deve estabilizar.”

Terceiro buraco.

O queijo vai alinhando.


🌀 Drift Into Failure prepara o terreno

Durante anos:

mais volume;

menos margem;

mais warning.

A operação vai se adaptando.

Então chega o dia em que sistema cruza a fronteira.

Mas todos ainda possuem modelo mental antigo:

“ele sempre aguenta.”

Isso é Normalcy Bias sustentado por memória histórica.

O sistema mudou.

O modelo mental não.


🧠 Model Drift humano

Falamos de drift em sistemas.

Mas também existe drift entre:

realidade;

modelo mental.

Exemplo:

2021:

batch aguenta 20 milhões.

2026:

processa 80 milhões.

Operador ainda pensa:

“Esse job é muito robusto.”

Talvez fosse.

Sob condições antigas.


🤖 Automation Bias piora

Dashboard:

OVERALL: GREEN

Usuários reclamam.

Normalcy Bias:

“provavelmente ruído.”

Automation Bias:

“o painel diz verde.”

Agora os dois se reforçam.

A realidade perde votação.


🔔 Alarm Fatigue também ajuda

Se alertas aparecem constantemente:

novo alerta grave parece só mais um.

Normalcy Bias diz:

“igual aos anteriores.”

Alarm Fatigue diz:

“não quero olhar.”

Excelente combinação.


👥 Groupthink cria normalidade coletiva

Uma pessoa diz:

— Não parece grave.

Outra:

— Concordo.

Terceira:

— Já vimos antes.

Agora o grupo constrói uma narrativa:

“está tudo sob controle.”

A pessoa mais preocupada começa a duvidar.

Groupthink transforma Normalcy Bias individual em percepção coletiva.


🪜 Authority Gradient silencia o desconfortável

Júnior:

— Isso está pior que o normal.

Sênior:

— Relaxa. Já vi isso várias vezes.

O júnior se cala.

Talvez esteja certo.

Authority Gradient protege o modelo mental antigo.


▶️ Plan Continuation Bias

Mudança em andamento.

Métricas pioram.

Equipe:

— Deve estabilizar depois do próximo passo.

Continua.

Normalcy Bias:

isso ainda não é emergência.

Plan Continuation Bias:

não pare.

E lá vamos nós.


👥 Diffusion of Responsibility

Todo mundo observa.

Ninguém declara incidente porque presume que:

se fosse realmente grave, alguém já teria declarado.

Perfeito.

Agora a ausência de ação das outras pessoas vira evidência de normalidade.

Esse mecanismo é assustadoramente elegante.


🧠 Social Proof em crise

Humano observa os outros.

Se ninguém corre:

talvez não haja fogo.

Isso é útil em situações ambíguas.

Mas se todos estão olhando uns para os outros:

o grupo inteiro pode ficar parado.


🔥 “Se fosse grave, alguém faria alguma coisa”

Essa frase deveria disparar alerta mental.

Porque talvez todas as pessoas estejam usando exatamente o mesmo raciocínio.


🏢 O caso do cheiro de queimado

Imagine data center.

Alguém sente cheiro de queimado.

Olha para outros.

Ninguém parece preocupado.

Pensa:

ar-condicionado.

Outro também sente.

Vê primeiro calmo.

Pensa:

deve ser normal.

Todos detectaram.

Nenhum validou.

Essa é uma versão perfeita.


💻 No COBOL: retorno estranho

Programa normalmente retorna:

REJECTS: 10–30

Hoje:

REJECTS: 490

Operador:

— Final de mês.

Depois:

REJECTS: 1.870

— Volume alto.

Pergunta:

qual limite separa explicação razoável de racionalização?

Precisa existir.


🚨 Thresholds de reconhecimento

Além de thresholds técnicos, precisamos de thresholds de decisão.

Exemplo:

IF REJECT RATE > 1%
    DECLARE DEGRADED

IF > 3%
    OPEN INCIDENT

IF > 5%
    STOP PROCESSING

Agora a mente não negocia infinitamente.


🧠 Precommitment retorna

Antes da crise:

definimos:

se X ocorrer, agimos.

Durante:

menos espaço para:

“vamos esperar.”

Precommitment combate Normalcy Bias.


🛑 Trigger Action Response Plan

Uma abordagem poderosa:

TRIGGER:
Queue > 10k por 5 min

ACTION:
abrir incidente

TRIGGER:
Timeout > 5%

ACTION:
HOLD mudança

TRIGGER:
Reconciliação != 0

ACTION:
STOP

O gatilho conecta diretamente a ação.

Reduz ambiguidade.


🧠 Não espere certeza absoluta

Outra armadilha.

Pessoas esperam:

“prova de desastre.”

Mas segurança trabalha com evidência suficiente.

Se esperar certeza total:

talvez já seja tarde.

A pergunta é:

“qual nível de incerteza aceitamos antes de agir?”


📊 Confidence Thresholds

Exemplo:

não sabemos causa.

Mas sabemos:

impacto subindo;

tendência negativa;

margem caindo.

Já pode ser suficiente para:

abrir incidente.

Você não precisa saber causa raiz para reconhecer emergência.


🔥 Incidente primeiro, explicação depois

Às vezes pessoas pensam:

“Não podemos declarar incidente porque ainda não sabemos a causa.”

Errado.

Incidente é sobre impacto e risco.

Causa vem depois.

Se prédio está queimando, não precisamos saber origem do fogo antes de evacuar.


☕ Bellacosa Mainframe: RC=00 e negócio quebrado

Job:

RC=0000

Tudo normal?

Talvez.

Mas reconciliação:

EXPECTED: 3.450.000
POSTED:   3.210.000

Normalcy Bias:

“talvez atraso de atualização.”

Investigue.

RC=00 só fala sobre o que o programa considerou sucesso.

Não sobre o universo.


🧠 Technical Normal vs Business Abnormal

Essa distinção é muito importante.

Infra:

normal.

Negócio:

anormal.

Se você escuta apenas infraestrutura, pode ignorar clientes.

Sempre valide impacto ponta a ponta.


📞 Usuário pode ser o primeiro sensor

Usuário reclama.

Dashboard verde.

Não presuma:

usuário está errado.

Ele pode estar enxergando uma camada não monitorada.

Normalcy Bias adora desqualificar sinal externo porque não cabe no painel.


🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“Deve normalizar.”

Pergunte:

“Qual evidência mostra tendência de normalização?”

Se resposta:

“normalmente acontece”

temos memória.

Não evidência atual.


🎯 Pergunta Bellacosa nº 2

Outra:

“Qual comportamento distinguiria ‘pico normal’ de ‘incidente começando’?”

Defina.


🎯 Pergunta Bellacosa nº 3

Outra:

“Quanto tempo estamos dispostos a esperar antes de agir?”

Sem isso:

espera vira infinita.


🎯 Pergunta Bellacosa nº 4

E:

“Se isso piorar duas vezes, nossa decisão muda?”

Planeje antes.


🧪 Passo a passo para combater Normalcy Bias

Passo 1 — Tenha baseline objetivo

Não dependa de sensação.


Passo 2 — Defina triggers claros

Quando deixa de ser normal?


Passo 3 — Diferencie variação de tendência

Um pico isolado pode ser ruído.

Três métricas piorando juntas contam história.


Passo 4 — Defina tempo de observação

“Esperar” precisa ter relógio.

Exemplo:

OBSERVE FOR 5 MIN
THEN REASSESS

Não:

“vamos vendo.”


Passo 5 — Use escalonamento progressivo

Warning.

Degraded.

Incident.

Critical.


Passo 6 — Permita declaração precoce

Sem punição social.


Passo 7 — Use fresh eyes

Pessoa nova pode perceber que o “normal” já mudou.


Passo 8 — Compare com cenários históricos corretos

Não apenas:

“já aconteceu.”

Pergunte:

“nas mesmas condições?”


Passo 9 — Registre decisões

Por que optamos por esperar?

Qual sinal mudaria isso?


Passo 10 — Faça retrospectiva sobre atrasos de reconhecimento

Não apenas causa raiz.

Pergunte:

quando tivemos informação suficiente para perceber que era incidente?


🕰️ Time to Declare

Podemos medir:

MTTD.

MTTR.

Mas também:

Time to Declare

Quanto tempo entre sinais suficientes e declaração formal?

Exemplo:

09:10 primeiro sinal forte
09:47 incidente declarado

37 minutos.

Talvez recuperação tenha levado 20.

Então maior problema foi reconhecimento tardio.


🧠 Recognition Latency

Atraso cognitivo importa.

Sistema pode detectar às 09:10.

Humano reconhecer às 09:40.

Organização agir às 09:50.

Três tempos diferentes.


📊 Timeline cognitiva novamente

09:04 metric abnormal
09:11 queue growing
09:18 timeouts
09:26 users report
09:34 failures
09:49 incident declared

Pergunte:

em qual ponto já tínhamos evidência suficiente?

Isso produz aprendizado.


🧠 Hindsight Bias cuidado!

Depois:

— Era claramente incidente às 09:11.

Talvez.

Ou talvez não.

Não use futuro para julgar.

Mas podemos perguntar:

quais critérios teriam permitido reconhecer antes?

Isso transforma retrospectiva em engenharia.


🏥 Normalcy Bias fora da TI

Esse viés aparece em desastres naturais, emergências e situações em que pessoas demoram a reagir porque eventos extremos parecem improváveis.

É justamente por isso que alertas públicos precisam ser:

claros;

acionáveis;

específicos.

“Pode haver risco” é diferente de:

“Evacue agora.”

Em TI também.


🚨 Mensagens vagas alimentam viés

WARNING:
SYSTEM MAY BE DEGRADED

Pessoa:

— Talvez não.

Melhor:

PAYMENT FAILURE RATE 12%
NORMAL < 0.2%
IMPACT CONFIRMED
OPEN INCIDENT NOW

Ação clara.


🧠 Linguagem importa

Evite:

“parece alguma instabilidade.”

Se dados mostram:

35% das transações falhando,

diga isso.

Eufemismo pode reforçar Normalcy Bias.


🏢 Cultura do “não dramatiza”

Algumas equipes valorizam calma.

Ótimo.

Mas calma não significa minimizar.

Você pode dizer:

“Temos impacto crítico confirmado”

sem pânico.

Precisão não é dramatização.


🧯 British calm versus denial

Aqui nosso humor britânico fica perfeito.

Existem duas atitudes:

Calma britânica:

“O prédio está pegando fogo. Vamos evacuar de forma ordenada.”

Normalcy Bias:

“Há apenas uma quantidade incomum de fumaça. Talvez seja o chá.”

Não confunda compostura com negação.


👻 Easter Egg nº 2 — chá e Daleks

Companion:

— Doctor, há Daleks na recepção.

— Quantos?

— Quatorze.

— E o segurança?

— Disse que provavelmente é uma convenção.

Doctor:

— Normalcy Bias.

— O quê?

— Depois explico. Corra.


🔁 Continuous Reassessment

Uma prática central:

reavalie.

Se decidiu:

esperar cinco minutos,

depois de cinco:

nova decisão.

Não deixe decisão temporária virar permanente.


⏰ Timer explícito

Use:

DECISION:
Observe.

EXPIRES:
09:30.

Às 09:30:

decida novamente.

Isso impede inércia.


🧠 “No decision” é uma decisão

Esperar também é ação.

Ela possui risco.

Pergunte:

qual é o custo de esperar?

Às vezes esperar é correto.

Mas deve ser escolha consciente.


📉 Cost of Delay

Se fila cresce 1.000/minuto:

esperar 10 minutos:

+10.000 backlog.

O tempo possui custo mensurável.

Isso ajuda a combater:

“vamos esperar mais.”


💻 COBOL e batches

Batch começa atrasar.

Ainda dentro da janela.

Normalcy Bias:

dá tempo.

Mas calcule:

ritmo atual.

tempo restante.

volume restante.

Agora talvez descubra matematicamente que não dá.

Projeção supera esperança.


📈 Forecast operacional

Em vez de:

“ainda está rodando.”

Use:

CURRENT RATE: 20k/min
REMAINING: 2M
ESTIMATED END: 05:12
SLA: 04:00

Agora futuro provável fica visível.


🤖 IA pode ajudar — e atrapalhar

IA pode detectar anomalias.

Ótimo.

Mas Automation Bias:

IA diz normal.

Ou Normalcy Bias:

IA não sinalizou, então não é incidente.

Use IA como mais uma fonte.

Não substituto de realidade.


🔍 Anomaly Detection não é oráculo

Se modelo treinou com histórico onde sistema já estava degradando, pode considerar degradação “normal”.

Interessante, não?

O modelo também pode normalizar desvio estatisticamente.

Por isso baseline precisa ser saudável, não apenas frequente.


🧠 “Normal” estatístico versus “normal” seguro

Esse é um ponto magnífico.

Se sistema vive 95% do tempo com warning:

estatisticamente:

warning é normal.

Operacionalmente:

talvez seja péssimo.

Não confunda frequência com segurança.


🧬 Regeneração organizacional

Como uma organização se regenera depois de identificar Normalcy Bias?

Ela:

define baseline;

define gatilhos;

mede tempo de reconhecimento;

treina escalonamento;

reduz custo social de declarar incidentes;

usa dados objetivos;

cria temporizadores;

faz reavaliação periódica;

valoriza sinais externos;

e ensina:

“Familiar não significa seguro.”


📋 Checklist anti-Normalcy Bias

Quando algo parece estranho:

[ ] Isso está realmente dentro do baseline?

[ ] A tendência está melhorando ou piorando?

[ ] Estamos usando memória ou dados?

[ ] Condições são iguais às vezes anteriores?

[ ] Existe impacto confirmado?

[ ] Quanto custa esperar?

[ ] Qual é nosso trigger de incidente?

[ ] Quando reavaliamos?

[ ] Alguém está minimizando sem evidência?

[ ] O silêncio do grupo está sendo tratado como prova?

[ ] Se isso dobrar, o que faremos?

[ ] Já deveríamos estar agindo?

📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Normalcy Bias é a tendência de presumir que a realidade continuará parecida com o normal conhecido, mesmo diante de sinais anormais.

“Já aconteceu antes” não prova que a situação atual seja segura.

Familiaridade pode atrasar reconhecimento de emergência.

Baseline objetivo é melhor que memória.

Esperar precisa ter prazo e critério.

Não é necessário conhecer causa raiz para declarar incidente.

Automation Bias e Alarm Fatigue podem reforçar Normalcy Bias.

Groupthink e Authority Gradient podem transformar minimização individual em consenso.

Normalization of Deviance muda o que chamamos de normal.

Drift Into Failure muda o sistema enquanto nosso modelo mental permanece antigo.

E principalmente:

O fato de o mundo ter voltado ao normal ontem não obriga o mundo a repetir a gentileza hoje.


🕰️ De volta às 09:04

A TARDIS retorna.

Primeiro alerta:

PAYMENT RESPONSE TIME ABOVE BASELINE

Operador:

— Deve ser pico.

Nosso programador responde:

— Pode ser. Vamos comparar com baseline.

09:08.

Fila 60% acima do normal.

09:10.

Timeout 4%.

Trigger definido:

TIMEOUT > 3%
FOR 3 MIN
→ DECLARE DEGRADED

09:13.

Ainda 4,5%.

Ele diz:

— Estamos em degraded.

O gerente pergunta:

— Já?

— Sim. O critério foi definido antes.

09:16.

Impacto aumenta.

Trigger:

FAILURE RATE > 5%
→ OPEN INCIDENT

Incidente aberto.

Owner atribuído.

MQ investigado.

Consumer degradado.

09:24.

Causa encontrada.

09:29.

Serviço restaurado.

Backlog controlado.

Nenhuma crise de duas horas.

O gerente pergunta:

— Não abrimos cedo demais?

Nosso programador olha para o gráfico.

— Talvez.

— E isso não é ruim?

O Doctor responde antes dele:

— Comparado a quê?

Silêncio.

— Ao privilégio de descobrir tarde demais que deveriam ter aberto antes?

O gerente sorri.

— Justo.


🥚 Easter Egg final

Horas depois surge:

BELLACOSA.BIAS(NORMAL)

Dentro:

       IF CURRENT-STATE NOT = BASELINE
           PERFORM INVESTIGATE
       END-IF.

       IF ONLY-REASON-TO-WAIT =
          'IT-USUALLY-GETS-BETTER'
           PERFORM SET-TIMER
       END-IF.

       IF IMPACT-CONFIRMED
           PERFORM ACT
       END-IF.

Comentário:

* FAMILIAR IS NOT THE SAME AS SAFE.

Outro:

* HOPE IS NOT A MONITORING STRATEGY.

E, naturalmente:

* BAD WOLF LEFT BEFORE THE ALARM.

Nosso jovem fecha o membro.

Pouco depois alguém diz:

— Esse erro costuma sumir sozinho.

Ele responde:

— Ótimo.

— Ótimo?

— Sim. Então sabemos o que esperar.

Abre um timer.

— Se não sumir em cinco minutos, sabemos que não estamos mais no caso normal.

Essa resposta é simples.

Mas representa uma mudança profunda.

Ele não rejeitou experiência.

Transformou experiência em critério testável.

Não entrou em pânico.

Também não negou realidade.

Em algum lugar:

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro permanece uma frase:

Calma é observar os fatos sem pânico. Normalcy Bias é observar os fatos e esperar que eles parem de ser fatos.

☕🌀

Next stop: Survivorship Bias — quando estudamos apenas os sistemas, projetos e equipes que sobreviveram e esquecemos de perguntar quantos fizeram exatamente a mesma coisa e desapareceram no caminho.

Sem comentários:

Enviar um comentário

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...