☕ 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

Mostrar mensagens com a etiqueta failover. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta failover. Mostrar todas as mensagens

domingo, 3 de maio de 2026

⚡💣 LAB CICS — MEM CRÍTICO 🚨 “QUANDO A MEMÓRIA ACABA… O CICS PEDE SOCORRO” 🚨

 

Bellacosa Mainframe memoria critica no CICS

⚡💣 LAB CICS — MEM CRÍTICO

🚨 “QUANDO A MEMÓRIA ACABA… O CICS PEDE SOCORRO” 🚨

👉 Tema: SOS (Short on Storage) + degradação + decisão de failover


🎬 🎯 CENÁRIO

Você está operando uma região do
IBM CICS

🕐 14:32 — horário crítico
📍 Região: CICSPRD1
📍 Ambiente: Produção


💥 ALERTAS INICIAIS

  • Tempo de resposta subindo
  • Tasks WAITING
  • CPU irregular
  • Storage aumentando rápido

💣 LOGS (CSMT)

DFHSM0133 Short on storage condition detected
DFHSM0606 Storage violation detected

👉 Tradução Bellacosa:

“O CICS está ficando sem memória — e isso escala rápido.”


🧠🔥 FASE 1 — DIAGNÓSTICO INICIAL

🔎 Comando:

CEMT I SYS

🔥 Resultado típico:

  • Storage > 90%
  • Tasks acumulando
  • Sistema degradando

❓ O que você faz?

A) Reinicia CICS
B) Ignora
C) Analisa storage
D) Derruba tudo


✅ RESPOSTA: C

👉 Reiniciar agora pode piorar
👉 Você precisa entender quem está consumindo storage


🔍 FASE 2 — INVESTIGAÇÃO DE STORAGE

🔎 Ver tasks:

CEMT I TASK

👉 Procure:

  • Tasks longas
  • Muitas instâncias
  • Status WAITING

💡 Padrão clássico:

  • Programa não liberando storage
  • Loop com GETMAIN
  • Leak de memória

📊 FASE 3 — IDENTIFICAR VILÃO

🔎 Filtro:

CEMT I TASK TRA(ORDR)

👉 Resultado:

  • Muitas tasks
  • Alto consumo
  • Crescendo continuamente

❓ Diagnóstico provável:

A) CPU
B) Storage leak
C) Rede
D) MQ


✅ RESPOSTA: B

🔥 Você está vendo um memory leak em CICS


☠️💣 FASE 4 — CONTENÇÃO IMEDIATA

Agora vem decisão crítica.

🎯 Objetivo:

  • parar consumo
  • evitar colapso

💥 Ações:

1. Derrubar tasks críticas:

CEMT SET TASK(501) PURGE

Se necessário:

CEMT SET TASK(501) FORCEPURGE

2. Bloquear transação:

CEMT SET TRAN(ORDR) DISABLED

👉 Isso é essencial.


🧬 FASE 5 — SITUAÇÃO PIORA 😈

Mesmo após purge:

  • Storage não libera totalmente
  • Região continua degradando

👉 Isso acontece porque:

  • Fragmentação
  • Storage preso
  • Controle interno comprometido

🚨 FASE 6 — DECISÃO CRÍTICA (NÍVEL SYSPROG)

❓ O que fazer agora?

A) Continuar purge
B) Reiniciar região
C) Acionar failover
D) Ignorar


✅ RESPOSTA IDEAL: C

👉 Você entra no modo resiliência


🌍⚡ FAILOVER COM GDPS

Utilizando:

IBM GDPS


💥 Ação:

  • Transferir workload
  • Ativar região standby
  • Redirecionar usuários

🎯 Resultado esperado:

  • Continuidade de serviço
  • Zero downtime perceptível (ou mínimo)

🧯 FASE 7 — ESTABILIZAÇÃO

Após failover:

  • Região secundária assume
  • Sistema normaliza
  • Usuários voltam

🔬 FASE 8 — ANÁLISE PROFUNDA

Agora você investiga a causa real.

🔎 Ferramentas:

  • IBM IPCS
  • IBM Fault Analyzer

💣 Descoberta:

  • Programa COBOL com loop de GETMAIN
  • Sem FREEMAIN
  • Leak progressivo

🔧 FASE 9 — CORREÇÃO DEFINITIVA

📋 Ações:

  • Corrigir código
  • Garantir FREEMAIN
  • Revisar uso de storage
  • Testar em QA

🧠💡 LIÇÕES DE OURO

👉 SOS nunca é “só performance”
👉 É risco de colapso total

👉 Sempre:

  • monitore storage
  • detecte crescimento anormal
  • tenha failover preparado

🧩😄 EASTER EGGS

  • “SOS não avisa duas vezes”
  • “Se chegou no SOS… alguém esqueceu FREEMAIN”
  • “Memory leak em CICS é assassino silencioso”

🏁 SCORE FINAL

CritérioResultado
Diagnóstico🧠 Excelente
Tempo de reação⚡ Crítico
Contenção🎯 Precisa
Resiliência🛡️ Nível enterprise

🎯💬 FECHAMENTO

Esse lab é o divisor de águas.

👉 Aqui você deixa de ser operador
👉 e vira engenheiro de sobrevivência do mainframe



quarta-feira, 8 de abril de 2026

💥 APERTA O ENTER E DERRUBA O DATA CENTER: SOBREVIVA AO LAB DE RESILIÊNCIA IBM Z

 

Bellacosa Mainframe experimentos reisiliencia em IBM Z

💥 APERTA O ENTER E DERRUBA O DATA CENTER: SOBREVIVA AO LAB DE RESILIÊNCIA IBM Z

🧪 Laboratório prático — do ABEND ao FAILOVER sem perder um byte


🎯 OBJETIVO DO LAB

Você vai simular:

  • 💣 Falha de aplicação (ABEND)
  • ⚙️ Restart automático (ARM)
  • 🧩 Continuidade (Sysplex mental model)
  • 🌍 Disaster Recovery (simulado estilo GDPS)
  • 📊 Validação de RPO/RTO

👉 Resultado esperado:
Sistema continua — usuário nem percebe


🧠 CENÁRIO (VIDA REAL)

Você é dev COBOL em um banco:

  • Batch crítico processa pagamentos
  • Roda em z/OS
  • Usa Db2
  • Integra com CICS

💥 E claro… algo vai dar errado.


🧪 LAB 1 — “PROVOQUE O CAOS” (ABEND CONTROLADO)

🎯 Objetivo:

Gerar uma falha real


📄 Passo 1 — Programa COBOL com erro

IDENTIFICATION DIVISION.
PROGRAM-ID. LABFAIL.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NUM PIC 9(3) VALUE ZEROS.
01 WS-VAL PIC 9(3).

PROCEDURE DIVISION.
MOVE 100 TO WS-VAL
DIVIDE WS-VAL BY WS-NUM GIVING WS-VAL
DISPLAY 'PROCESSO FINALIZADO'
STOP RUN.

👉 Resultado esperado:

S0C7 ou S0CB (divisão por zero)

💡 Comentário Bellacosa

“Se você nunca causou um ABEND de propósito… você ainda não domina o sistema.”


⚙️ LAB 2 — “DEIXA O SISTEMA SE VIRAR” (ARM)

🎯 Objetivo:

Simular restart automático


🧠 Conceito

ARM = Automatic Restart Manager

👉 Ele reinicia automaticamente o que caiu


📄 Passo 2 — Simulação lógica

JOB FAIL → ABEND
ARM detecta → restart automático
JOB reinicia → continua fluxo

🧪 Teste

  1. Execute o programa com erro
  2. Corrija o erro (WS-NUM ≠ 0)
  3. Reexecute

👉 Agora imagine:

  • ARM faria isso sozinho
  • Sem operador

💡 Insight

“ARM é o operador que nunca dorme.”


🧩 LAB 3 — “NÃO PARE O SISTEMA” (MENTALIDADE SYSPLEX)

🎯 Objetivo:

Entender continuidade


🧠 Simulação conceitual

Imagine:

  • LPAR A → falha
  • LPAR B → assume

📄 Fluxo

Transação → LPAR A
Falha → redireciona → LPAR B
Usuário continua

💡 Easter Egg 🔥

“Sysplex não é cluster…
é cluster que não te deixa na mão.”


🌍 LAB 4 — “PERDEMOS O DATA CENTER” (DR SIMULADO)

🎯 Objetivo:

Simular desastre total


🧠 Cenário

  • Site A caiu 💥
  • Site B assume

📄 Exercício

  1. Imagine seu sistema rodando
  2. “Desligue” mentalmente o ambiente
  3. Suba outro ambiente

👉 Perguntas:

  • Quanto tempo levou? (RTO)
  • Perdeu dados? (RPO)

💡 Resposta ideal

  • RTO → segundos/minutos
  • RPO → zero

🔥 Insight

“Se você precisa pensar muito no DR… ele já falhou.”


🧨 LAB 5 — “DESCUBRA SEU SPOF”

🎯 Objetivo:

Encontrar ponto único de falha


📄 Checklist

  • Um único job crítico?
  • Um único DB?
  • Um único operador? 😅

💡 Easter Egg

SPOF mais comum:
👉 Interface Teclado-Cadeira


🤖 LAB 6 — “AUTOMA OU MORRE”

🎯 Objetivo:

Entender automação


📄 Cenário

Sem automação:

  • detectar
  • analisar
  • agir

👉 minutos ou horas


Com automação:

  • detectar
  • agir

👉 segundos


💡 Insight brutal

“Sem automação, seu RTO é humano.”


🧪 LAB 7 — DR TEST (O GRANDE FINAL)

🎯 Objetivo:

Validar tudo


📄 Simulação

  1. Derrube o “ambiente”
  2. Ative backup
  3. Valide sistema

📊 Checklist

  • Sistema subiu?
  • Dados íntegros?
  • Tempo aceitável?

💡 Regra de ouro

“DR não testado = DR inexistente”


🧠 CONSOLIDAÇÃO FINAL


🔗 RELAÇÃO DOS CONCEITOS

  • RAS → evita impacto
  • Models → define arquitetura
  • Planning → garante execução

💥 Fluxo completo

Falha pequena → ARM resolve
Falha média → Sysplex resolve
Desastre total → DR/GDPS resolve

🏁 MISSÃO FINAL DO LAB

👉 Você não está testando sistema
👉 Você está testando sobrevivência do negócio


🔥 FRASE FINAL

“No mainframe, o erro não é falhar…
é deixar o usuário perceber.”

 

segunda-feira, 16 de março de 2020

A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade : Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas

 

Bellacosa Mainframe e a sociedade do mainframe rumo a alta disponibilidade

☕ Um Café no Bellacosa Mainframe

A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade

Quando um Programador COBOL Padawan Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas

"Nem todos os sistemas que caem estão perdidos. Alguns apenas aguardam que outra região assuma sua missão."


Introdução

Existe um momento na carreira de todo programador COBOL em que ele deixa de pensar apenas no programa que escreveu.

Até então, seu universo era relativamente pequeno.

Recebia uma especificação.

Criava um programa COBOL.

Compilava.

Executava.

Corrigia alguns ABENDs.

Consultava um VSAM.

Executava um SQL.

Colocava em produção.

Fim da história.

Mas então surge uma pergunta aparentemente simples.

"O que acontece quando o programa está funcionando e o servidor onde ele está executando simplesmente desaparece?"

Silêncio.

Essa pergunta muda completamente a forma de enxergar um sistema corporativo.

É exatamente neste ponto que começa nossa jornada.

Como em O Senhor dos Anéis – A Sociedade do Anel, descobrimos que existe um mundo muito maior além do Condado.

O COBOL é apenas Frodo.

O CICS é Rivendell.

O z/OS é a Terra Média.

E a Alta Disponibilidade é a Sociedade que mantém o Um Anel longe das forças do caos.

Hoje atravessaremos essa Terra Média tecnológica.

Pegue seu café.

Afivele o cinto do terminal 3270.

Nossa aventura apenas começou.


Capítulo I

O Condado: Onde Todo Programador COBOL Começa

Todo iniciante acredita que um sistema funciona assim:

Cliente

↓

Programa COBOL

↓

Banco de Dados

↓

Resposta

Simples.

Bonito.

Organizado.

Funciona perfeitamente...

até acontecer a primeira falha.

Imagine um banco.

São nove horas da manhã.

Milhares de pessoas fazem PIX.

Empresas pagam fornecedores.

Cartões de crédito autorizam compras.

Caixas eletrônicos funcionam.

Aplicativos móveis recebem milhões de acessos.

De repente...

A máquina que executa aquele programa simplesmente para.

Não trava.

Não fica lenta.

Ela desaparece.

Agora faça uma pergunta.

Quanto dinheiro um banco perde por minuto parado?

Algumas instituições estimam milhões de reais por hora.

Em bolsas de valores...

alguns segundos podem representar perdas gigantescas.

Foi por isso que nasceu um dos conceitos mais importantes da computação corporativa:

High Availability.


Capítulo II

Mordor Existe

No universo da fantasia existe Sauron.

No Mainframe existem as falhas.

Elas sempre existirão.

Não importa a qualidade do hardware.

Não importa quanto custa o servidor.

Tudo pode falhar.

Discos quebram.

Fontes queimam.

Cabos são desconectados.

Switches morrem.

Processadores apresentam defeitos.

LPARs reiniciam.

Operadores cometem erros.

Programadores também.

O objetivo nunca foi impedir isso.

O objetivo sempre foi impedir que o cliente perceba.

Essa mudança de mentalidade separa iniciantes dos arquitetos de sistemas.


Capítulo III

A Sociedade do Mainframe

Assim como Frodo jamais chegaria sozinho a Mordor, um ambiente CICS nunca depende de um único componente.

A Sociedade é formada por personagens extraordinários.

Frodo — O Programa COBOL

É quem realmente executa a missão.

Ele processa contas.

Calcula juros.

Autoriza cartões.

Move dinheiro.

Mas sozinho ele não sobreviveria.


Gandalf — O WLM

O Workload Manager é um verdadeiro mago.

Ele conhece toda a Terra Média do z/OS.

Sabe onde há CPU disponível.

Onde existe memória.

Onde há menos filas.

Onde o tempo de resposta está melhor.

Enquanto os usuários apenas enviam solicitações...

Gandalf decide para onde cada missão será enviada.

Sem ele...

o reino mergulharia no caos.


Aragorn — O CICS

O verdadeiro líder da batalha.

Cada Região CICS representa um comandante.

Ela recebe transações.

Executa programas.

Coordena recursos.

Mantém a ordem.

Mas, assim como Aragorn, nenhuma região governa sozinha.

Existem várias espalhadas pelo reino.


Legolas — O Monitoramento

Legolas enxerga longe.

Muito longe.

Ele percebe um problema antes dos outros.

O monitoramento faz exatamente isso.

Analisa:

  • CPU

  • Storage

  • SOS

  • Locks

  • SQL lento

  • Esperas

  • MQ

  • Threads

  • Tempo de resposta

Antes mesmo dos usuários reclamarem.


Gimli — O Hardware IBM Z

Robusto.

Pesado.

Quase indestrutível.

Mas nem Gimli é imortal.

Até o melhor hardware pode falhar.

Por isso existem outros anões prontos para assumir.


Sam — O Db2

Frodo jamais teria chegado ao fim sem Sam.

O COBOL também não.

O Db2 acompanha todas as transações.

Protege os dados.

Mantém consistência.

Recupera informações.

Suporta milhões de acessos simultâneos.


Capítulo IV

O Portal de Rivendell

Observe o caminho percorrido por uma simples transação.

Usuário

↓

Aplicativo

↓

Rede

↓

Load Balancer

↓

WLM

↓

Região CICS

↓

COBOL

↓

DB2

↓

Resposta

O usuário nunca conversa diretamente com o COBOL.

Há diversos guardiões protegendo o caminho.

Isso é proposital.

Cada camada adiciona inteligência.

Cada camada aumenta a disponibilidade.

Cada camada reduz riscos.


Capítulo V

O Conselho de Elrond

Imagine que existem quatro Regiões CICS.

CICSA

CICSB

CICSC

CICSD

Durante um dia comum...

todas trabalham juntas.

Cada uma atende milhares de usuários.

Agora imagine que CICSB falhou.

O que acontece?

Nada.

Ou melhor...

quase nada.

O WLM simplesmente deixa de enviar novas transações para ela.

As demais assumem a carga.

Os clientes continuam utilizando o sistema.

É exatamente como retirar Boromir da Sociedade.

A missão continua.


Capítulo VI

O Um Anel da Alta Disponibilidade

Existe um erro comum entre iniciantes.

Pensar que redundância significa desperdício.

Não.

Redundância significa sobrevivência.

Ter apenas uma região é barato.

Mas extremamente perigoso.

Ter quatro regiões parece mais caro.

Até o dia da primeira falha.

Nesse instante...

descobre-se que o investimento pagou décadas de tranquilidade.


Capítulo VII

O Caminho para Mordor

Toda transação percorre diversos desafios.

Primeiro o balanceamento.

Depois o processamento.

Depois acesso ao banco.

Depois gravação em logs.

Depois confirmação.

Se qualquer etapa falhar...

existem mecanismos de recuperação.

Algumas transações reiniciam.

Outras utilizam Syncpoint.

Outras fazem rollback.

Outras repetem a operação.

Tudo pensado para preservar integridade.


Capítulo VIII

O Olho de Sauron Nunca Dorme

Monitoramento contínuo.

Esse é um conceito que muitos desenvolvedores ignoram.

Eles imaginam que basta a região responder.

Mas responder não significa estar saudável.

Uma região pode:

  • consumir 100% da CPU;

  • estar sem armazenamento (SOS);

  • aguardar locks;

  • enfrentar lentidão no Db2;

  • acumular filas no MQ.

Ela ainda responde.

Mas lentamente.

O monitoramento detecta esses sinais antes que o usuário perceba.

Ferramentas como OMEGAMON, RMF, SMF, CICS Explorer e soluções de observabilidade modernas funcionam como os sentinelas de Gondor: vigiam continuamente o horizonte em busca de qualquer ameaça.


Capítulo IX

A Fortaleza Invisível: Shared Db2 e VSAM

Uma pergunta importante surge.

Se existem várias regiões...

como todas enxergam os mesmos dados?

A resposta está no compartilhamento.

O Db2, utilizando Data Sharing, permite que diferentes regiões CICS acessem o mesmo conjunto de informações com consistência.

O VSAM, quando configurado com Record Level Sharing (RLS), também possibilita acesso concorrente seguro.

Imagine uma conta bancária.

Saldo:

R$ 1.000

Se uma região enxergasse R$ 1.000 e outra R$ 950, o caos seria inevitável.

É por isso que a consistência dos dados é tão importante quanto a disponibilidade da aplicação.


Capítulo X

O Reino Além do Reino: Parallel Sysplex

Aqui chegamos ao verdadeiro ápice da engenharia IBM.

O Parallel Sysplex.

Imagine várias fortalezas espalhadas pela Terra Média.

Cada uma possui seus soldados.

Cada uma possui seus recursos.

Entretanto...

todas trabalham como se fossem uma única cidade.

É exatamente isso que acontece.

Diversos sistemas IBM Z compartilham recursos através do Coupling Facility, coordenando locks, caches e estruturas compartilhadas.

O resultado?

Escalabilidade quase linear.

Disponibilidade extraordinária.

Capacidade de crescimento contínuo.

É uma das arquiteturas mais elegantes já construídas na história da computação.


Capítulo XI

Alta Disponibilidade não é Disaster Recovery

Esse tema costuma aparecer em entrevistas técnicas.

E muitos candidatos confundem os conceitos.

High Availability (HA) trata de falhas locais.

Uma região caiu?

Outra assume.

Um processador apresentou defeito?

Outro continua executando.

Disaster Recovery (DR) lida com eventos muito maiores.

Incêndios.

Enchentes.

Falhas elétricas generalizadas.

Ataques físicos.

Perda completa de um Data Center.

Nesses casos, outro ambiente — muitas vezes localizado em outra cidade ou país — assume as operações.

Uma boa analogia é imaginar um castelo.

Se uma torre desmorona, os soldados continuam defendendo a fortaleza.

Isso é HA.

Mas se o castelo inteiro é destruído por um dragão...

é necessário recuar para outra fortaleza.

Isso é DR.


Curiosidades que Pouca Gente Conhece

🏰 Curiosidade 1

Grandes bancos frequentemente operam com dezenas de Regiões CICS simultaneamente.


🏰 Curiosidade 2

Alguns ambientes processam dezenas de milhares de transações por segundo.


🏰 Curiosidade 3

É comum realizar manutenção em hardware IBM Z sem desligar aplicações críticas.


🏰 Curiosidade 4

Muitos clientes nunca percebem que uma região inteira foi reiniciada durante o expediente.


🏰 Curiosidade 5

Grande parte da confiabilidade do Mainframe vem da combinação entre hardware, sistema operacional, middleware e processos operacionais — não de um único componente.


Passo a Passo para o Padawan COBOL Entender HA

Se você está começando agora, siga esta trilha de estudos:

  1. Aprenda a arquitetura básica do z/OS.

  2. Entenda o papel do CICS.

  3. Estude a diferença entre TOR, AOR e FOR.

  4. Aprenda como funciona o WLM.

  5. Conheça o Db2 Data Sharing.

  6. Estude VSAM RLS.

  7. Entenda Syncpoint e Commit.

  8. Aprenda conceitos de rollback e recuperação.

  9. Descubra como funciona o Parallel Sysplex.

  10. Explore ferramentas de monitoramento como RMF, SMF e OMEGAMON.

Essa sequência fará muito mais sentido do que tentar estudar todos os componentes isoladamente.


Easter Egg Bellacosa Mainframe ☕

Existe uma antiga lenda entre os Sysprogs.

Ela diz que, em algum lugar escondido dentro do Coupling Facility, existe um Palantír Digital.

Apenas os arquitetos mais experientes conseguem enxergar através dele o fluxo de todas as transações da Terra Média do Mainframe. Enquanto um programador iniciante vê apenas um programa COBOL executando um EXEC CICS LINK, o velho mago observa regiões inteiras assumindo cargas, WLM redistribuindo trabalho, Db2 sincronizando dados e o Sysplex mantendo o reino unido.

Dizem ainda que Gandalf jamais utilizou magia para derrotar Sauron.

Na verdade...

ele apenas configurou corretamente o WLM, distribuiu as transações entre múltiplas regiões CICS e deixou que a Alta Disponibilidade fizesse o restante.

Claro... nenhum manual da IBM confirma essa história.

Mas todo bom Sysprog sorri discretamente quando alguém menciona que "o sistema simplesmente não pode parar".


Conclusão

Assim como A Sociedade do Anel não era formada por heróis isolados, a Alta Disponibilidade em um ambiente CICS também é resultado da cooperação entre diversos componentes. O COBOL executa a lógica de negócio, o CICS coordena as transações, o WLM distribui inteligentemente a carga, o Db2 e o VSAM garantem a consistência dos dados, o monitoramento identifica problemas antes que eles afetem os usuários e o Parallel Sysplex transforma múltiplos sistemas em uma infraestrutura única e resiliente.

Para o programador COBOL iniciante, compreender esses conceitos representa uma mudança profunda de perspectiva. Você deixa de enxergar apenas linhas de código e passa a entender o ecossistema que mantém bancos, companhias aéreas, seguradoras, bolsas de valores e governos funcionando ininterruptamente.

No fim da jornada, a maior lição não é aprender a escrever um programa perfeito, mas compreender que, em computação corporativa, a verdadeira excelência está em construir sistemas capazes de continuar servindo milhões de pessoas mesmo quando partes da infraestrutura falham. Esse é o espírito do Mainframe: transformar redundância em confiança, engenharia em continuidade de negócios e tecnologia em um serviço tão confiável que a maioria das pessoas sequer percebe que ele existe.

Porque, como diria um velho mago da Terra Média adaptado ao universo IBM Z:

"Um grande sistema não é aquele que nunca enfrenta falhas. É aquele cuja missão continua, mesmo quando uma parte da Sociedade precisa ficar para trás."

sexta-feira, 10 de junho de 2016

Normalcy Bias: Doctor Who, COBOL e o Dia em que Tudo Já Estava Pegando Fogo — Mas a Gente Ainda Achava que Era Só um Pico

  

Bellacosa Mainframe e a normalcy bias

☕ Um Café no Bellacosa Mainframe

Normalcy Bias: Doctor Who, COBOL e o Dia em que Tudo Já Estava Pegando Fogo — Mas a Gente Ainda Achava que Era Só um Pico

Uma viagem pela TARDIS dos incidentes para entender por que, diante de sinais anormais, nosso cérebro prefere acreditar que tudo continuará funcionando como sempre — e como essa tendência pode atrasar escaladas, evacuações, failovers, DR, decisões críticas e até a simples coragem de admitir que a realidade mudou

02:13.

War Room ainda:

não existe.

Esse detalhe importa.

Na sala de operações:

um monitor começa a piscar.

PAYMENT LATENCY:
NORMAL = 180ms
NOW    = 950ms

Operador:

— Subiu bastante.

Colega:

— Deve ser pico.

02:15.

PAYMENT LATENCY:
1.800ms

— Está subindo.

— Final de lote talvez.

02:17.

ERROR RATE:
2.1%

— Erro também.

— Às vezes acontece.

02:20.

MQ QUEUE DEPTH:
NORMAL = 80
NOW    = 2.400

Nosso jovem programador COBOL pergunta:

— Isso ainda é normal?

Operador:

— Normal, normal não.

— Então?

— Vamos observar mais cinco minutos.

Ah.

Os cinco minutos mais famosos:

da tecnologia.

02:25.

Queue:

5.800.

Timeout:

subindo.

Cliente:

ligando.

Ainda assim:

— Talvez estabilize.

VWORP.

VWORP.

VWORP.

A TARDIS aparece ao lado do console.

A porta abre.

O Doctor sai.

Olha:

para os gráficos.

Depois:

para a equipe.

— Há quanto tempo isso está acontecendo?

— Uns doze minutos.

— E o que fizeram?

— Estamos monitorando.

Doctor:

— Por quê?

— Pode voltar ao normal.

Ele olha novamente para:

a curva vertical.

— Claro.

Pausa.

— E se não voltar?

Silêncio.

Nosso jovem responde:

— Aí escalamos.

Doctor:

— Quando?

— Quando ficar realmente grave.

Doctor aponta:

para 5.800 mensagens.

“E como exatamente vocês definirão ‘realmente grave’ sem usar a definição de cinco minutos atrás?”

Bem-vindo ao:



Normalcy Bias

ou:

Viés da Normalidade.

Em linguagem Bellacosa:

é quando o cérebro vê sinais de que o mundo mudou, mas continua executando o runbook mental do mundo antigo porque aceitar a ruptura parece mais difícil do que esperar mais um pouco.


🧠 O que é Normalcy Bias?

Normalcy Bias é a tendência de:

subestimar;

minimizar;

ou demorar a aceitar

uma ameaça ou ruptura porque:

esperamos que as coisas continuem funcionando aproximadamente como sempre funcionaram.

É especialmente discutido em:

desastres;

emergências;

evacuações;

crises.

Mas em TI:

cabe perfeitamente.

Porque incidentes começam frequentemente:

não com:

explosão.

Mas com:

anomalias.


☕ O cérebro adora continuidade

Ontem:

funcionou.

Hoje cedo:

funcionou.

Nos últimos:

100 dias,

funcionou.

Então, quando algo estranho aparece:

a primeira aposta mental é:

“vai voltar.”

Isso não é irracional por definição.

Muitos picos:

realmente voltam.

O problema está:

quando a evidência muda

e a crença:

não.


💻 COBOL cognitivo

Imagine:

       IF SYSTEM-STATUS = 'DEGRADED'
           MOVE 'TEMPORARY'
             TO INTERPRETATION
       END-IF.

Depois:

       IF SYSTEM-STATUS = 'WORSE'
           MOVE 'STILL-TEMPORARY'
             TO INTERPRETATION
       END-IF.

Depois:

       IF CUSTOMER-IMPACT = 'HIGH'
           MOVE 'PROBABLY-RECOVER'
             TO INTERPRETATION
       END-IF.

E finalmente:

       IF PRODUCTION = 'DOWN'
           PERFORM OPEN-WAR-ROOM
       END-IF.

Um pouco tarde.


🧠 Normalcy Bias não significa covardia

Importante.

Não é:

“pessoa fraca.”

É uma forma de:

modelo mental.

Nosso cérebro usa:

experiência passada

para prever:

próximo minuto.

Na maior parte do tempo:

isso funciona.

É exatamente por isso que:

o viés existe.


☕ O problema não é:

esperar estabilidade.

É:

continuar esperando estabilidade

depois que os sinais começaram a negar essa hipótese.


👻 Easter Egg nº 1 — Dalek tranquilo

Companion:

— Doctor, existem três Daleks no corredor.

Doctor:

— Interessante.

— Não vamos correr?

— Talvez sejam turistas.

— Eles estão gritando “EXTERMINATE”.

— Um pouco agressivos.

— Agora dispararam.

— Talvez seja demonstração cultural.

Companion:

— Normalcy Bias?

Doctor:

— Sim. E provavelmente meu último.


🧠 Normalcy Bias e incident response

Pense no começo clássico:

CPU +10%
LATENCY +20%
ERROR +1%
QUEUE +300%

Nada isoladamente:

apocalíptico.

Então:

ninguém quer apertar:

P1.

Porque:

P1 custa.

War Room.

Escalation.

Exec.

Vendor.

Possível impacto reputacional.

A tendência:

esperar confirmação.

Mas a confirmação pode chegar:

como incidente grande.


🎯 Pergunta Bellacosa nº 1

“Estamos esperando evidência suficiente — ou estamos esperando uma evidência tão grande que já venha acompanhada do desastre?”


🧠 Thresholds ajudam

Se definição de severidade:

é subjetiva,

Normalcy Bias cresce.

“Está feio?”

“Mais ou menos.”

“Já escalamos?”

“Talvez daqui a pouco.”

Use:

thresholds.


🧠 Exemplo

IF ERROR RATE > 2%
AND QUEUE > 2000
AND CUSTOMER IMPACT > 5 MIN
THEN OPEN MAJOR INCIDENT

Agora:

menos debate emocional.


☕ Regra escrita em tempo calmo

protege do cérebro:

em tempo ruim.


🧠 Mas cuidado com Metric Fixation

Threshold não:

vira universo.

Se realidade:

claramente ruim,

não espere:

2.00%

porque está:

1.98%.

Need judgment.


🎯 Pergunta Bellacosa nº 2

“O threshold é um gatilho mínimo ou uma desculpa para não agir antes?”


🧠 Normalcy Bias e Status Quo Bias

Status Quo Bias prefere:

estado atual.

Normalcy Bias presume:

estado familiar vai continuar.

São próximos.

Mas Normalcy Bias:

especialmente útil em crise.


🧠 Anchoring também entra

Baseline:

normal.

Ele vira:

âncora.

Quando sistema sai:

ajustamos devagar.

“É só 20% pior.”

Depois:

50%.

Depois:

100%.

Ainda pensamos:

a partir do normal.


☕ O normal vira:

gravidade.

Mesmo quando:

sistema já escapou da órbita.


🧠 Hindsight Bias depois vai ser cruel

Durante:

— Vamos esperar.

Depois do incidente:

— Era óbvio que deveríamos ter escalado.

Hindsight.

Veja a ironia:

Normalcy Bias antes.

Hindsight depois.


🎯 Pergunta Bellacosa nº 3

“Estamos dando à equipe um critério claro para agir antes, ou vamos julgá-la depois com informação retrospectiva?”


🧠 Outcome Bias também participa

A equipe esperou.

Sistema recuperou sozinho.

Resultado:

bom.

Conclusão:

“esperar foi certo.”

Talvez:

sorte.

Outcome Bias.

Agora:

próximo incidente,

esperam.

Dessa vez:

não recupera.


☕ Sucesso anterior

pode treinar:

lentidão futura.


🧠 Risk Compensation

“Das outras vezes voltou.”

Confiança.

Less urgency.

Pode:

aumentar exposição.


🧠 Confirmation Bias

A hipótese é:

“é transitório.”

Então buscamos:

sinais de recuperação.

Um gráfico melhora:

2%.

— Está voltando!

Outro piora:

50%.

— Ainda oscilando.

Perfeito.


🎯 Pergunta Bellacosa nº 4

“Estamos procurando sinais de estabilização porque eles existem ou porque queremos muito que a situação seja temporária?”


🧠 Narrative Bias

Criamos:

história tranquilizadora.

“Fim de lote.”

“Pico comercial.”

“Network jitter.”

“GC.”

Essas histórias podem:

ser plausíveis.

Problema:

viram anestesia.


☕ Uma boa explicação temporária

pode atrasar:

a busca por uma explicação real.


🧠 Search Satisfaction

Encontramos:

“pico de CPU.”

Pronto.

Explica.

Não escalamos.

Maybe:

not.


🧠 Premature Closure

“É pico normal.”

Close.

Incident keeps growing.


🧠 Diagnosis Momentum

Handoff:

“transient spike.”

Next shift:

receives.

Now:

momentum da normalidade.


🎯 Pergunta Bellacosa nº 5

“O próximo turno recebeu fatos ou recebeu a interpretação tranquilizadora do turno anterior?”


🧠 Normalcy Bias e “isso sempre acontece”

Frase clássica.

Mas:

quão parecido?

Baseline.

Duration.

Magnitude.

Scope.


🧠 Compare quantitatively

Hoje:

queue 5.800.

Normal peaks:

Não diga:

“sempre sobe.”

Escala importa.


☕ Uma vela

e um incêndio florestal

ambos têm:

fogo.

Não são:

o mesmo evento.


🎯 Pergunta Bellacosa nº 6

“Isto é do mesmo tipo de fenômeno normal, mas em uma magnitude que já mudou o significado?”


🧠 Normalcy Bias e slow-moving incidents

Alguns incidentes:

crescem devagar.

Memory leak.

Queue backlog.

Storage exhaustion.

Certificate expiry.

Trend:

lento.

Perigoso porque:

cada minuto parece:

ligeiramente pior.

Não há:

momento teatral.


☕ Sapos e água quente?

A metáfora popular do sapo é biologicamente ruim.

Então:

vamos deixar o pobre sapo em paz.

Use:

drift.


🧠 Drift Into Failure

Sistema vai:

perdendo margem.

Tudo ainda:

funciona.

Até:

não.

Normalcy Bias ajuda:

aceitar drift.


🎯 Pergunta Bellacosa nº 7

“Estamos olhando apenas o estado atual ou também a velocidade com que estamos perdendo margem?”


🧠 Trend matters

CPU:

80%

not necessarily critical.

But:

70 → 75 → 80 → 85

every minute.

That:

is different.


☕ Um número é:

foto.

Trend:

filme.

Em crise:

filme importa.


🧠 Normalcy Bias e observability

Dashboard built:

green/yellow/red.

Yellow:

often ignored.

Because:

not red.

But:

yellow may be:

early warning.


🎯 Pergunta Bellacosa nº 8

“Nosso sistema de alerta trata degradação como informação ou apenas queda como informação?”


🧠 Alert fatigue piora

Se yellow fires:

todo dia,

people learn:

ignore.

Then:

real event.

Normalcy Bias supported by:

tooling.

Not only brain.


☕ Se tudo alerta

nada alerta.


🧠 Signal-to-noise again

Improve:

quality.

Otherwise:

“já vimos isso.”


🧠 Normalcy Bias e Black Swan

Careful.

Not every unexpected event:

Black Swan.

But rare events:

challenge expectation.

The key:

past frequency not proof of future impossibility.


🎯 Pergunta Bellacosa nº 9

“Estamos tratando ‘nunca aconteceu’ como evidência de baixa probabilidade ou como prova de impossibilidade?”


🧠 Mainframe reliability paradox

Systems highly reliable:

create confidence.

Good.

But:

long stability can make teams:

less psychologically ready

for real rupture.


☕ Quanto mais tempo sem incêndio

mais estranho parece:

alarme verdadeiro.


🧠 Normalcy Bias em DR

No disaster:

for years.

DR:

seen as ceremony.

Then:

actual.

People may initially:

try normal operations.

Delay:

declaration.


🧠 Declare disaster threshold

Need:

clear.


🎯 Pergunta Bellacosa nº 10

“O que exatamente precisa acontecer para declararmos DR — e todos sabem isso?”


🧠 DR activation

If criteria vague:

fear of overreaction.

Delay.

Normalcy.


☕ Declarar cedo parece:

exagero.

Declarar tarde parece:

óbvio erro.

É por isso que:

precommitment ajuda.


🧠 Normalcy Bias e failover

Primary degrading.

Team:

waits.

Because failover:

risky.

Makes sense.

But waiting too long:

may reduce failover success.

Need:

decision thresholds.


🎯 Pergunta Bellacosa nº 11

“Estamos preservando opcionalidade ou consumindo a janela em que a opção de failover ainda é segura?”


🧠 Option value

Act before:

state deteriorates too much.

Huge.


🧠 Normalcy Bias e backups

Data corruption detected.

First reaction:

maybe localized.

Continue processing.

Corruption spreads.

Need:

containment.


☕ Às vezes o primeiro passo não é:

consertar.

É:

parar de piorar.


🧠 Containment mindset

Normalcy says:

keep business.

Resilience says:

maybe isolate.


🎯 Pergunta Bellacosa nº 12

“Continuar operando está preservando serviço ou ampliando o dano?”


🧠 Normalcy Bias em security

One suspicious login.

Maybe noise.

Then:

more.

Analyst:

wait.

Because declaring:

incident

costly.

Attack:

moves.

Need:

containment threshold.


🧠 Security normalcy

Users have anomalies.

Most:

benign.

That makes:

real intrusion hard.


🎯 Pergunta Bellacosa nº 13

“Quais sinais combinados transformam um evento comum em uma hipótese de comprometimento real?”


🧠 Correlation helps

One:

weak.

Several aligned:

strong.


🧠 Normalcy Bias em fraude

One anomalous transaction:

maybe.

50:

not.

But if each individually:

reviewed,

normalization occurs.

Need aggregate.


☕ Incidentes distribuídos

podem parecer:

normais localmente

e anormais:

globalmente.


🎯 Pergunta Bellacosa nº 14

“Estamos vendo eventos isolados ou o padrão agregado?”


🧠 Normalcy Bias e silos

Each team:

sees own metrics:

slightly weird.

No one:

sees global.

Thus:

each says:

“normal enough.”

War Room starts late.


🧠 End-to-end observability

Antidote.


☕ Cinco equipes com:

5% de anomalia

podem formar:

100% de desastre.


🧠 Normalcy Bias e Principal-Agent

A team may delay escalation:

because escalation impacts:

KPI.

SLA.

reputation.

Now normalcy gets:

incentive.


🧠 Campbell / Goodhart

If P1 count:

punishes team,

teams may:

wait.

Reclassify.

Danger.


🎯 Pergunta Bellacosa nº 15

“Nosso sistema de incentivos torna psicologicamente ou politicamente caro declarar que a situação deixou de ser normal?”


🧠 This is huge

If saying:

“P1”

makes manager look bad,

then bias:

institutional.


☕ A organização pode:

treinar Normalcy Bias.


🧠 Normalcy Bias e leadership

Leader:

“não quero alarmismo.”

Team:

underreacts.

Or leader:

“escalem cedo.”

Culture:

different.


🎯 Pergunta Bellacosa nº 16

“A liderança penaliza falsos alarmes mais do que atrasos de escalada?”


🧠 False positive trade-off

Need balance.

Too many escalations:

fatigue.

Too late:

impact.

Calibrate.


🧠 Normalcy Bias e “wait and see”

Wait-and-see can be:

valid strategy.

But only if:

explicit.

Define:

wait 5 minutes;

monitor X;

if Y:

escalate.

Not:

indefinite.


☕ “Vamos observar”

só é plano

se tiver:

condição de saída.


🎯 Pergunta Bellacosa nº 17

“O que precisa acontecer para encerrarmos o ‘vamos observar’?”


🧠 Time-box uncertainty

Great technique.

OBSERVE UNTIL 02:25
IF QUEUE > 3000 OR ERR > 2%
THEN ESCALATE

Now:

controlled.


🧠 Normalcy Bias e Need for Control

Accepting crisis:

means admitting:

loss of control.

Uncomfortable.

So:

we keep:

normal procedures.


☕ “Ainda está sob controle”

às vezes significa:

“ainda não aceitamos que não está.”


🧠 Illusion of Control

Console available.

Commands.

So:

feels:

manageable.

Maybe:

not.


🎯 Pergunta Bellacosa nº 18

“Estamos dizendo que está sob controle porque temos ações disponíveis ou porque os indicadores realmente respondem às ações?”


🧠 Normalcy Bias e Action Bias

Interesting contrast.

Normalcy:

delay action.

Action Bias:

act too quickly.

How reconcile?

Different people/times.

At start:

normalcy.

Later panic:

action bias.

Classic incident curve:

underreact early, overreact late.


☕ Primeiro:

“espera.”

Depois:

“restart tudo.”

Maravilhoso.


🧠 This is key

Good incident management seeks:

measured early action

to avoid:

desperate late action.


🎯 Pergunta Bellacosa nº 19

“Estamos usando a hesitação inicial para criar exatamente a emergência que depois justificará ações brutais?”


🧠 Normalcy Bias e Risk Compensation

Past recoveries:

build belief:

system self-heals.

Then:

delay.


🧠 “It always recovers”

Until:

doesn't.


🎯 Pergunta Bellacosa nº 20

“Quantas recuperações anteriores foram realmente autocorreção do sistema e quantas foram sorte ou intervenção invisível?”


🧠 Normalcy Bias e technical debt

Known warning.

System works.

Years.

So:

“not urgent.”

Debt grows.

Then:

failure.

This is Normalcy Bias in slow motion.


☕ “Nunca deu problema”

é:

argumento fraco

contra:

risco estrutural.


🧠 Cultural Debt

A decision:

still feels normal

because:

identity built.

Changing means:

admit world changed.

Normalcy Bias + Cultural Debt.


🎯 Pergunta Bellacosa nº 21

“Estamos preservando essa prática porque ainda funciona ou porque admitir que o contexto mudou ameaça nossa identidade operacional?”


🧠 Normalcy Bias e legacy modernization

System:

reliable.

But skills:

shrinking.

Dependencies:

aging.

No outage.

Management:

“fine.”

Normalcy.

Risk:

future.


☕ Ausência de incidente

não é:

ausência de tendência.


🧠 Leading indicators

Track:

staffing;

supportability;

vendor EOL;

recovery time;

test coverage.

Not:

only outages.


🎯 Pergunta Bellacosa nº 22

“Quais indicadores antecipam perda de resiliência antes que ela apareça como incidente?”


🧠 Normalcy Bias e capacity planning

Peak grows:

month by month.

Still below:

limit.

So:

fine.

Then:

cross.

Need forecast.


🧠 Trend beats status

Again.


☕ Capacidade não falha:

quando chega a 100%.

Falha:

quando margem desaparece.


🎯 Pergunta Bellacosa nº 23

“Estamos monitorando utilização ou tempo restante até perdermos margem?”


🧠 Normalcy Bias e certificates

Perfect example.

Certificate:

expires in:

30 days.

Then:

Then:

Still works.

So:

normal.

Until:

00:00.

No gradual degradation.

Cliff.


☕ O sistema pode:

parecer perfeitamente normal

um segundo antes:

de parar.


🧠 Deadline risks

Certificates.

Licenses.

Disk.

Password expiry.

Contract.

Calendar events.

Need:

proactive.


🎯 Pergunta Bellacosa nº 24

“Existe algum risco binário que não dá sinais graduais antes da ruptura?”


🧠 Normalcy Bias e exponential growth

Queues.

Retries.

Virus spread.

Incidents.

Early:

small.

Then:

explosive.

Human intuition:

linear.

Danger.


🧠 Example

100
200
400
800
1600
3200

At 200:

looks small.

But trend:

terrifying.


☕ Exponencial é:

educado no começo.

Depois:

cobra juros.


🎯 Pergunta Bellacosa nº 25

“Estamos interpretando crescimento exponencial com intuição linear?”


🧠 Normalcy Bias e retry storms

One failure:

retry.

More load.

More failure.

Loop.

If early anomaly treated:

normal,

cascade.


🧠 Feedback loops

Important.


🎯 Pergunta Bellacosa nº 26

“Esse desvio possui mecanismo de autoamplificação?”

If yes:

act earlier.


🧠 Normalcy Bias e cascading failure

Initial:

minor.

Secondary:

major.

Early containment:

cheap.

Late:

hard.


☕ Pequena anomalia

pode:

não ser pequeno risco.


🧠 Normalcy Bias e SRE error budgets

Error budget:

helps quantify.

If burn rate:

spikes,

trigger.

Great anti-normalcy.


🧠 Burn rate

Not only:

current error.

Trajectory.


🎯 Pergunta Bellacosa nº 27

“Qual é a velocidade de consumo da nossa margem de erro?”


🧠 Normalcy Bias e AI monitoring

AI says:

“anomaly score 0.62.”

Human:

meh.

Need:

context.

AI can:

help detect pattern earlier.

But:

Automation Bias also.


🧠 Don't outsource escalation blindly

Model:

may miss.

Human:

may normalize.

Need:

combined.


🎯 Pergunta Bellacosa nº 28

“A IA está detectando mudança de regime ou apenas variação dentro do regime histórico?”


🧠 Change-point detection

Technical term useful.

When system shifts:

new regime.

Not just:

noise.


☕ Talvez devêssemos pensar:

“isso ainda pertence à mesma distribuição?”

Senior question.


🧠 Normalcy Bias e AI assistants

Prompt:

“Is this normal?”

Danger.

Model may compare:

past.

Better:

“what evidence suggests regime change?”


🎯 Pergunta Bellacosa nº 29

“Estamos pedindo à IA para tranquilizar ou para desafiar a hipótese de normalidade?”


🧠 Confirmation again

Normalcy hypothesis:

“temporary.”

Ask AI:

“why might this be transient?”

Gets:

reasons.

Don't.


🧠 Scenario generation

Ask:

what severe scenarios fit?

What signs discriminate?


☕ Não use IA

como:

calmante corporativo.


🧠 Normalcy Bias e incident severity review

Severity should:

update.

Not:

anchor.


🧠 Dynamic escalation

P3 → P2 → P1

Need:

rules.


🎯 Pergunta Bellacosa nº 30

“Se este incidente começasse agora com os dados atuais, ainda o classificaríamos da mesma forma?”


🧠 Normalcy Bias e communication

Early communication:

“We are investigating elevated latency.”

Good.

Not:

“everything fine.”

Avoid:

premature reassurance.


🧠 Transparency

Can say:

impact uncertain.


☕ “Ainda não sabemos”

é melhor que:

“não é nada”

sem evidência.


🧠 Normalcy Bias e public incidents

Organizations sometimes:

delay communication

because:

hope recovery.

Then:

trust loss.

Need:

criteria.


🎯 Pergunta Bellacosa nº 31

“Estamos adiando comunicar porque o impacto é realmente pequeno ou porque ainda esperamos que desapareça antes de precisarmos admitir?”


🧠 Normalcy Bias e vendor incidents

Vendor says:

“intermittent.”

We believe.

Maybe:

because convenient.

Need:

own evidence.


🧠 Independent telemetry

Again.


☕ “Fornecedor disse normal”

não:

restaura cliente.


🧠 Normalcy Bias e testing

Test environment shows:

occasional failure.

Team:

flaky test.

Maybe.

But flaky can:

signal race.

If repeatedly dismissed:

incident later.


🎯 Pergunta Bellacosa nº 32

“Chamamos de flakiness porque demonstramos ruído ou porque investigar seria caro?”


🧠 Flaky tests

Great example.

Sometimes:

bad test.

Sometimes:

real nondeterminism.

Don't normalize.


🧠 Normalcy Bias e warnings

Compiler warning.

Runtime warning.

Repeated.

People:

ignore.

Then:

failure.

Warning fatigue.


☕ Warning que nunca dói

vira:

papel de parede.


🎯 Pergunta Bellacosa nº 33

“Este warning continua sem consequência ou apenas não vimos ainda a consequência?”


🧠 Normalcy Bias e memory leaks

System restarts weekly.

Everyone:

normal.

Why?

Because:

always restart.

But:

that's workaround.

Cultural Debt.


🧠 Workaround becomes normal

Again.


🎯 Pergunta Bellacosa nº 34

“Estamos chamando de operação normal algo que já depende de intervenção recorrente para continuar funcionando?”


🧠 This is big

Normality can:

include hidden heroics.

If person leaves:

“normal” collapses.


☕ Normal não é:

aquilo que parece estável.

É:

aquilo que é sustentável.


🧠 Normalcy Bias e human staffing

On-call person:

always fixes.

No incidents visible.

Management:

fine.

Single point.

Normalcy.


🎯 Pergunta Bellacosa nº 35

“Quanta intervenção humana invisível é necessária para manter o que chamamos de normal?”


🧠 Normalcy Bias and Cultural Debt again

Heroic routines:

become:

identity.

“É assim mesmo.”

Risk.


🧠 Normalcy Bias e compliance

Control exceptions:

rare.

Then:

routine.

“Tem aprovação informal.”

Normalizes.

Eventually:

audit/security issue.


🎯 Pergunta Bellacosa nº 36

“Quando uma exceção repetida deixou de ser exceção e virou processo real?”


🧠 Normalization of Deviance teaser

This leads naturally to:

Normalization of Deviance.

Normalcy Bias:

denies abnormal event.

Normalization of Deviance:

turns abnormal behavior into normal practice.

Close relatives.


☕ Normalcy Bias:

“isso não é crise.”

Normalization of Deviance:

“isso nem é desvio.”

Beautiful distinction.


🧠 Normalcy Bias e Change Blindness?

Different concept.

But metaphorically:

gradual change less noticed.

Still:

not same.

Don't confuse.


🧠 Normalcy Bias e cognitive load

Under stress:

people may:

stick to familiar routine.

Procedures:

help.

But if procedure assumes:

normal operation,

problem.

Need:

emergency mode.


🎯 Pergunta Bellacosa nº 37

“Temos um ponto explícito em que deixamos o modo ‘operação normal’ e entramos no modo ‘incidente’?”


🧠 Mode switch

Important.

NORMAL OPS
↓
DEGRADED OPS
↓
MAJOR INCIDENT
↓
DR

Define:

entry/exit.


☕ Estado intermediário

evita:

tudo ou nada.


🧠 Normalcy Bias e workflow states

If system only:

OPEN/CLOSED,

bad.

Need:

degraded.

mitigating.

watch.


🧠 State model helps cognition

Exactly.


🎯 Pergunta Bellacosa nº 38

“Nosso workflow consegue representar ‘isso não caiu, mas já não está normal’?”


🧠 Normalcy Bias e SLOs

SLO:

objective.

If burn:

high,

trigger.

Good.

But:

don't overfit.


🧠 Error budget as reality check

Stops:

“seems fine.”


☕ Opinião:

“parece estável.”

SLO:

“acabamos de gastar 30% do mês em 20 minutos.”

Conversa muda.


🧠 Normalcy Bias e Black Start / DR exercises

Practice:

declaration.

People hesitate less.

Muscle memory.


🧠 Tabletop scenarios

Reveal:

escalating signals.

Ask:

when act?

Compare.


🎯 Pergunta Bellacosa nº 39

“Treinamos a equipe para reconhecer o momento de declarar crise ou apenas para operar quando a crise já foi declarada?”


🧠 Normalcy Bias e organizational storytelling

Past incidents:

“came out of nowhere.”

Maybe:

because early signals normalized.

Postmortem:

look.


☕ “Do nada”

às vezes significa:

“dos sinais que ninguém tratou como mudança de regime.”


🧠 Hindsight caution

Don't say:

“obvious.”

Instead:

which early signal could:

be made actionable?


🎯 Pergunta Bellacosa nº 40

“Qual sinal precoce podemos tornar mais distinguível sem criar mil falsos alarmes?”


🧠 Normalcy Bias e probability

Past:

99.9% uptime.

Doesn't mean:

next minute 99.9?

Roughly maybe.

But conditional evidence matters.

Once anomalies:

observed,

update.

Bayesian thinking.


🧠 Prior versus evidence

Prior:

system healthy.

New evidence:

errors.

Update.

Normalcy Bias:

under-updates.


☕ Anchoring in Bayesian clothing.


🎯 Pergunta Bellacosa nº 41

“Estamos atualizando nossa crença proporcionalmente à nova evidência ou ainda vivendo no prior de ontem?”


🧠 Normalcy Bias e confidence

At 02:13:

transient 80%.

At 02:20:

maybe 50%.

At 02:25:

10%.

If still:

80,

bias.


🧠 Explicit probability can help

Not precise.

But:

forces update.


☕ Crença também:

precisa de monitoring.


🧠 Normalcy Bias e counterfactual

If this is:

real major incident,

what would we expect next?

Queue doubling?

Error rising?

Observe.


🎯 Pergunta Bellacosa nº 42

“Se isso não for um pico normal, qual será o próximo sinal — e em quanto tempo?”

Great.


🧠 Predictive branching

Write:

Scenario A transient.

Scenario B cascade.

Expected:

signals.

Then:

monitor.


🧠 This turns waiting into experiment

Not:

hope.


☕ “Vamos observar”

vira:

ciência

quando:

você sabe o que está observando.


🧠 Bellacosa Two-Scenario Test

H0: TRANSIENT
EXPECT:
latency falling within 5 min
queue stable

H1: CASCADE
EXPECT:
queue doubling
error rising
retries rising

At 5 min:

decide.


🎯 Pergunta Bellacosa nº 43

“O que distinguirá a hipótese de normalidade da hipótese de crise?”


🧠 Normalcy Bias e blast radius

Act early:

maybe small.

Wait:

blast grows.

Need:

cost comparison.


🧠 False alarm cost vs missed incident cost

Explicit.


🎯 Pergunta Bellacosa nº 44

“Qual é o custo de escalar cedo demais versus o custo de escalar tarde demais?”


🧠 Often asymmetric

War Room false alarm:

cost maybe 1h.

Late P1:

millions.

Then:

early bias.


☕ Nem todo erro de decisão

tem:

mesmo preço.


🧠 Normalcy Bias e option preservation

Earlier:

more options.

Later:

fewer.

Failover window.

Rollback.

Containment.


🎯 Pergunta Bellacosa nº 45

“Esperar mais cinco minutos aumenta informação mais rápido do que reduz nossas opções?”

Essa é excelente.


🧠 Value of information vs cost of delay

Senior-level.

Wait can:

gain info.

But:

cost.

Balance.


🧠 Normalcy Bias in change rollback

Change causes:

some errors.

Team:

waits.

Maybe:

stabilize.

Rollback window:

closes.

Then:

data migration irreversible.

Danger.


☕ Às vezes:

reversibilidade expira.


🎯 Pergunta Bellacosa nº 46

“Até quando o rollback continua realmente disponível?”


🧠 Normalcy Bias e database corruption

Critical.

If suspect corruption:

stop writes?

Hard.

Waiting:

could amplify.

Need:

runbook.


🧠 Data integrity > availability sometimes

Trade-off.


🎯 Pergunta Bellacosa nº 47

“Qual é o custo de manter disponibilidade se os dados podem estar se deteriorando?”


🧠 Normalcy Bias e cyber ransomware

Odd files.

Slow shares.

Users report.

Maybe:

storage.

Delay.

Encryption spreads.

Early isolation:

critical.

Again.


☕ Em alguns incidentes

“esperar confirmar”

é:

dar tempo ao problema.


🧠 Normalcy Bias e human factors

People seek:

social cues.

If nobody panics:

assume okay.

In real emergencies too.

In War Room:

if senior calm,

juniors:

don't escalate.


🎯 Pergunta Bellacosa nº 48

“Estamos avaliando os sinais ou observando a reação das pessoas para decidir se os sinais são graves?”


🧠 Social proof

Related.

Everyone calm:

normal.

But maybe:

everyone waiting.

Collective delay.


☕ Cinco pessoas esperando

não tornam:

espera correta.


🧠 Authority Bias

Senior:

“já vi pior.”

Anchor.

Could:

suppress.

Need:

data.


🎯 Pergunta Bellacosa nº 49

“‘Já vi pior’ é contexto útil ou está virando motivo para ignorar a tendência atual?”


🧠 Normalcy Bias e expertise

Expert can:

correctly recognize benign spikes.

Great.

But:

pattern recognition needs:

falsification.

“What is different?”


🧠 Expert intuition + check

Best.


☕ Sexto sentido é ótimo.

Mas:

deixe o SMF confirmar.


🧠 Bellacosa Anti-Normalcy Protocol

Passo 1 — Defina baseline

O que é normal?

Passo 2 — Defina desvio

Magnitude.

Trend.

Duration.

Passo 3 — Liste hipóteses

Transient vs regime change.

Passo 4 — Defina sinais discriminantes

What would each predict?

Passo 5 — Time-box observation

No indefinite wait.

Passo 6 — Define escalation triggers

Before crisis.

Passo 7 — Monitor trend and margin

Not only current state.

Passo 8 — Preserve options

Rollback/failover/containment.

Passo 9 — Challenge reassurance

Why do we think it will normalize?

Passo 10 — Review false alarms and misses

Calibrate.


📋 Checklist Bellacosa anti-Normalcy Bias

[ ] Qual é o baseline real?

[ ] O desvio está crescendo?

[ ] Quanto tempo já dura?

[ ] A magnitude ainda cabe no histórico?

[ ] Estamos perdendo margem?

[ ] Existe mecanismo de autoamplificação?

[ ] Há cliente afetado?

[ ] O que nos faria escalar?

[ ] Quando termina o "vamos observar"?

[ ] O rollback ainda está disponível?

[ ] O failover fica mais difícil com o tempo?

[ ] Estamos esperando recuperação porque há evidência?

[ ] A liderança desestimula escaladas?

[ ] O próximo turno herdou fatos ou tranquilização?

[ ] O custo de atraso é maior que o custo de falso alarme?

🧠 Bellacosa Normalcy Card

BASELINE:
_________________________

CURRENT STATE:
_________________________

TREND:
STABLE / WORSENING / IMPROVING

H0 - TRANSIENT:
_________________________

H1 - REGIME CHANGE:
_________________________

ESCALATE IF:
_________________________

OBSERVE UNTIL:
_________________________

OPTIONS AT RISK:
_________________________

👻 Easter Egg nº 2 — BELLACOSA.BIAS(NORMALCY)

       IF CURRENT-STATE NOT = BASELINE
           PERFORM MEASURE-DEVIATION
       END-IF.

       IF DEVIATION > THRESHOLD
          OR TREND = 'WORSENING'
           PERFORM EVALUATE-ESCALATION
       END-IF.

       IF TEAM-SAYS 'WAIT-FIVE-MINUTES'
           PERFORM SET-EXIT-CONDITION
       END-IF.

       IF OPTIONS-EXPIRING = 'Y'
           DISPLAY
           'WARNING: DELAY HAS A COST'
       END-IF.

Comentários:

* NORMAL YESTERDAY
* DOES NOT MEAN
* NORMAL NOW.

Outro:

* WAITING
* IS A DECISION.

Outro:

* "LET'S OBSERVE"
* REQUIRES
* AN EXIT CONDITION.

Outro:

* DO NOT WAIT
* FOR THE INCIDENT
* TO PROVE
* IT IS AN INCIDENT.

E naturalmente:

* DALEKS:
* 1 -> 2 -> 4 -> 8
*
* TEAM:
* "PROBABLY TEMPORARY."

🕰️ De volta ao console

02:20.

Queue:

2.400.

Nosso jovem pergunta:

— Qual é a condição para escalar?

Silêncio.

Doctor olha:

para operador.

— Vocês não definiram?

— Não.

Nosso jovem escreve:

IF QUEUE > 3000
OR ERROR > 2.5%
OR LATENCY > 2s FOR 5 MIN
THEN P1

02:22.

Queue:

3.100.

Error:

2.8%.

Ninguém diz:

“vamos esperar.”

P1.

War Room.

Vendor.

Failover team:

ready.


🔧 02:27

Descobrem:

retry loop.

Containment:

implemented.

Queue:

stops growing.

Service:

degraded but stable.

Sem:

total outage.


☕ O gerente pergunta:

— Talvez tivesse normalizado sozinho.

Nosso jovem:

— Talvez.

Doctor:

— E talvez não.

— Então como sabemos se escalar foi certo?

Doctor olha:

para os critérios.

“Porque a decisão foi tomada com base no risco e nos sinais disponíveis, não na esperança de que o futuro seria parecido com ontem.”


🧠 Isso é o ponto

Não queremos:

panic bias.

Nem:

false alarm mania.

Queremos:

early recognition.


🧠 Normalcy Bias não é resolvido com paranoia

Importantíssimo.

Se tudo:

crise,

nothing:

crise.

Need:

calibration.


🎯 Pergunta Bellacosa nº 50

“Como reagir cedo sem transformar toda anomalia em apocalipse?”

Resposta:

baseline;

threshold;

trend;

time-box;

decision rules;

reversibility;

cost asymmetry.


🧬 Regeneração organizacional

Uma organização madura entende:

que normalidade é:

hipótese.

Não:

direito adquirido.

Ela:

mede baseline;

observa trends;

define escalation;

treina mudança de modo;

preserva opções;

não pune false alarms razoáveis;

e não espera:

produção morrer

para admitir:

que produção estava doente.

Principalmente:

ela sabe que a frase:

“vamos observar mais cinco minutos”

não é inocente.

Pode ser:

boa decisão.

Mas precisa:

de hipótese;

de métrica;

de limite;

de saída.

Sem isso:

é apenas:

esperança com relógio.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Normalcy Bias é a tendência de subestimar ou atrasar a aceitação de uma ameaça porque esperamos que as condições normais continuem.

Ele é especialmente perigoso em eventos que começam com sinais graduais ou ambíguos.

O fato de um sistema ter se recuperado sozinho anteriormente não prova que o evento atual também se recuperará.

Anchoring pode prender a equipe ao baseline antigo.

Confirmation Bias pode fazer a equipe procurar sinais de estabilização e minimizar sinais de deterioração.

Narrative Bias produz explicações tranquilizadoras como “é só pico”.

Search Satisfaction pode fazer um primeiro achado benigno encerrar a exploração cedo demais.

Premature Closure pode transformar “parece transitório” em diagnóstico.

Diagnosis Momentum pode transmitir “é apenas um pico” para os turnos seguintes.

Outcome Bias pode validar atrasos anteriores que terminaram bem por sorte.

Hindsight Bias depois fará o atraso parecer obviamente errado caso o incidente exploda.

Need for Control pode fazer a equipe resistir a admitir que perdeu o regime normal de operação.

Action Bias pode aparecer depois, produzindo o padrão clássico de hesitação cedo demais e ação desesperada tarde demais.

Trend, duração e margem são tão importantes quanto o valor instantâneo de uma métrica.

“Vamos observar” precisa de duração e condição de saída.

A organização deve diferenciar operação normal, degradação, major incident e DR.

O custo de esperar pode incluir perda de rollback, failover, contenção e opcionalidade.

A ausência de queda ainda não prova que o sistema está normal.

E principalmente:

normalidade não é aquilo que esperamos que continue acontecendo; é aquilo que as evidências atuais ainda justificam chamar de normal.


🥚 Easter Egg final

Antes de entrar na TARDIS, o Doctor escreve:

IF THINGS-ARE-WEIRD
   DO NOT AUTOMATICALLY
   MOVE 'NORMAL'
   TO EXPLANATION.

Nosso jovem:

— Isso não é COBOL.

Doctor:

— Você tem esse problema com tudo que eu escrevo.

Ele corrige:

       IF CURRENT-STATE NOT = BASELINE
           PERFORM EVALUATE-CHANGE-OF-REGIME
       END-IF.

Doctor sorri.

— Melhor.

Nosso jovem pergunta:

— E se for realmente só um pico?

— Excelente.

— Então escalamos à toa?

— Talvez.

— Isso não é ruim?

O Doctor abre a porta da TARDIS.

“Um falso alarme razoável pode custar uma hora. Uma falsa sensação de normalidade pode custar o sistema inteiro.”

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No console:

INCIDENT:
MITIGATED EARLY

TOTAL OUTAGE:
AVOIDED

Nosso jovem olha:

para a queue.

Depois:

para o relógio.

E escreve no quadro:

“Esperar também é uma decisão — e deve ser justificada com a mesma disciplina que agir.”

Talvez essa seja toda a essência do Normalcy Bias no Bellacosa Mainframe:

o perigo não começa quando tudo cai; muitas vezes começa minutos antes, quando tudo já mudou e nós ainda estamos negociando com a ideia de que talvez continue normal.

☕🌀

Próxima parada: Normalization of Deviance — o dia em que uma gambiarra que “funcionou só desta vez” funcionou tantas vezes que deixou de ser gambiarra, virou processo oficial e ninguém mais lembrava qual regra estava sendo violada.

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