☕ 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 Alertas. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Alertas. Mostrar todas as mensagens

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.

sábado, 11 de dezembro de 2010

Diffusion of Responsibility: Doctor Who, COBOL e o Dia em que Todo Mundo Viu o Alerta — Mas Ninguém Era o Responsável

Bellacosa Mainframe e a diffusion of responsibility

☕ Um Café no Bellacosa Mainframe

Diffusion of Responsibility: Doctor Who, COBOL e o Dia em que Todo Mundo Viu o Alerta — Mas Ninguém Era o Responsável

Uma viagem pela TARDIS dos incidentes para entender por que quanto mais pessoas recebem um problema, mais fácil pode ser acreditar que outra pessoa já está cuidando dele

08:57.

Segunda-feira.

Café quente.

Produção funcionando.

O Teams tranquilo.

Uma manhã suspeitosamente agradável.

Até que surge:

09:01:17

WARNING
PAYMENT QUEUE DEPTH > THRESHOLD

O monitoramento envia automaticamente a mensagem para:

Operações.

Aplicação.

Middleware.

CICS.

DBA.

Infraestrutura.

Gestão.

Suporte.

Vinte e três pessoas recebem.

Excelente.

Um sistema moderno.

Comunicação perfeita.

Visibilidade ampla.

09:04.

A fila continua crescendo.

QUEUE DEPTH: 4.312

João, da aplicação, vê.

Pensa:

“Operação certamente está olhando.”

Maria, de operações, vê.

Pensa:

“Isso parece problema da aplicação.”

Carlos, de middleware, recebe.

Pensa:

“Se for MQ de verdade, alguém vai me chamar.”

O gerente recebe no celular.

Pensa:

“A equipe técnica já está atuando.”

Nosso jovem programador COBOL vê a mensagem.

Olha a quantidade de pessoas no canal.

Vinte e três.

Pensa:

“Não vou atrapalhar. Certamente alguém mais experiente está cuidando.”

09:12.

QUEUE DEPTH: 12.891

Ninguém está cuidando.

09:17.

TIMEOUT RATE: +320%

09:19.

Usuários começam a reclamar.

09:22.

Alguém pergunta no Teams:

“Pessoal, alguém olhando isso?”

Silêncio.

Então...

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se no corredor.

A porta abre.

O Doctor sai.

Olha para o painel.

Olha para o Teams.

Conta os participantes.

— Vinte e três pessoas receberam o alerta?

— Sim.

— Quantas estão investigando?

Silêncio.

— Interessante.

Nosso programador responde:

— Achei que alguém estivesse.

O Doctor aponta para os demais.

— Eles também.

Pausa.

— Vocês construíram uma equipe tão grande que conseguiram criar uma pessoa imaginária chamada “alguém”.

Bem-vindo ao:



Diffusion of Responsibility

Ou:

Difusão de Responsabilidade

O fenômeno pelo qual a presença de várias pessoas pode reduzir a sensação individual de responsabilidade para agir.

Quanto mais fácil pensar:

“Outra pessoa fará”

mais perigoso fica descobrir que todas as outras pessoas pensaram exatamente a mesma coisa.


🌀 A TARDIS já colecionou muitos monstros

Nossa jornada está ficando perigosamente parecida com um bestiário de sistemas complexos.

Começamos pelo Swiss Cheese Model.

Aprendemos que barreiras imperfeitas podem falhar simultaneamente.

Depois:

Normalization of Deviance — aquilo que estava errado vai ficando familiar.

Hindsight Bias — depois do desastre todo mundo acredita que deveria ter percebido.

Confirmation Bias — encontramos aquilo que procuramos.

Anchoring Bias — a primeira explicação prende nossa atenção.

Groupthink — pessoas concordam porque as outras concordam.

Authority Gradient — alguém percebe, mas não consegue confrontar autoridade.

Plan Continuation Bias — continuamos porque já começamos.

Alarm Fatigue — recebemos tantos alertas que deixamos de ouvi-los.

Automation Bias — acreditamos demais na máquina.

Drift Into Failure — pequenas adaptações empurram todo o sistema lentamente para condições perigosas.

Agora encontramos outra peça.

O alerta funciona.

Não existe necessariamente fadiga.

A máquina detectou corretamente.

As pessoas viram.

O problema foi distribuído para tanta gente que a responsabilidade ficou...

distribuída também.


🧠 O que é Diffusion of Responsibility?

A ideia é bastante simples.

Imagine que você esteja sozinho numa sala.

Um alarme começa.

Você pensa:

“Preciso fazer alguma coisa.”

Agora imagine vinte pessoas.

O mesmo alarme aparece.

Você pode pensar:

“Alguém mais qualificado vai cuidar.”

Cada pessoa individualmente sente uma fração menor da responsabilidade.

Não precisamos literalmente calcular:

RESPONSABILIDADE / NÚMERO DE PESSOAS

A psicologia não funciona como COBOL.

Mas a sensação pode se comportar aproximadamente dessa maneira.

Uma responsabilidade claramente individual:

“Vagner, investigue este alerta.”

é muito diferente de:

“Pessoal, alguém consegue olhar?”

A segunda frase acabou de criar um funcionário imaginário chamado:

Alguém.


👥 O famoso Bystander Effect

Diffusion of Responsibility é fortemente relacionada ao chamado Bystander Effect, ou efeito espectador.

Estudos clássicos da psicologia social associados a John Darley e Bibb Latané investigaram por que indivíduos podem ter menor probabilidade de ajudar em certas situações quando outras pessoas também estão presentes.

A lógica psicológica inclui elementos como:

“Outra pessoa deve agir.”

ou:

“Se ninguém está reagindo, talvez não seja grave.”

Isso é fascinante porque se conecta imediatamente aos incidentes.

Uma War Room possui muitos espectadores.

Todos tecnicamente capazes.

Todos informados.

Mas capacidade coletiva não garante ação individual.


🚨 O alerta para “todos”

Existe uma frase operacional que deveria causar desconforto:

“Mandamos para todo mundo.”

Parece robusto.

Mas quem é o responsável?

Resposta:

“Todo mundo.”

Então talvez tenhamos um problema.

Porque:

Responsabilidade de todos pode virar responsabilidade de ninguém.


☕ Bellacosa Mainframe: o job que ninguém assumiu

Imagine:

JOB ABC123 ABENDED S0C7

Scheduler envia:

Aplicação.

Produção.

Suporte.

DBA.

Operador.

Email de distribuição.

Teams.

Telefone automático.

Fantástico.

Agora:

Operação pensa:

aplicação está vendo.

Aplicação pensa:

operador deve ter iniciado restart.

DBA pensa:

não parece Db2.

Gestão pensa:

equipes técnicas receberam.

Resultado:

35 minutos.

Nenhuma ação.

O problema não foi falta de notificação.

Foi falta de:

ownership.


🏷️ Ownership muda tudo

Compare:

ALERT:
ABC123 S0C7

RECIPIENTS:
OPERATIONS@EMPRESA

com:

ALERT:
ABC123 S0C7

OWNER:
BATCH PAYMENTS TEAM

ON-CALL:
MARIA

ACK REQUIRED: 5 MIN

ESCALATE AFTER: 10 MIN

A segunda versão responde à pergunta:

Quem precisa agir agora?

Isso vale ouro.


🧠 Informação e responsabilidade são coisas diferentes

Enviar informação não significa atribuir responsabilidade.

Você pode informar 200 pessoas.

Ainda precisa existir alguém dizendo:

“Eu tenho este incidente.”

Isso é uma distinção maravilhosa para quem começa em TI.

Broadcast

“Todos precisam saber.”

Assignment

“Você precisa agir.”

Não confunda.


👻 Easter Egg nº 1 — O companion imaginário

O Doctor pergunta:

— Quem deveria apertar o botão?

Companion A:

— Achei que fosse B.

Companion B:

— Eu achei que fosse o Doctor.

Doctor:

— E eu estava ocupado impedindo a destruição do espaço-tempo.

Pausa.

— Talvez devêssemos começar a colocar nomes nos botões.

TI aprendeu a mesma lição.

Ou deveria.


📣 “Alguém pode verificar?”

Essa frase aparece muito em chats operacionais:

“Alguém consegue verificar CICS?”

Cinco pessoas leem.

Ninguém responde.

Melhor:

“Carlos, consegue verificar CICS e retornar em 10 minutos?”

Agora temos:

responsável;

atividade;

expectativa.

Se Carlos não puder:

— Não consigo. Maria assume?

Responsabilidade transferida explicitamente.


🏃 O bastão precisa ser entregue

Imagine corrida de revezamento.

Não basta:

“Acho que o próximo corredor sabe que deve correr.”

Existe entrega do bastão.

Em incidentes deveria ser semelhante:

OWNER: CARLOS
        ↓
HANDOFF
        ↓
OWNER: MARIA

Nunca:

CARLOS
   ↓
“PESSOAL”
   ↓
???

O ??? é onde incidentes moram.


🔁 Handoff é uma transação

Para um programador COBOL, pense como uma transação.

Transferência de responsabilidade deveria possuir confirmação.

CARLOS:
“Maria, transfiro análise de MQ para você.”

MARIA:
“Recebido. Assumo MQ.”

Commit.

Sem confirmação:

rollback psicológico.

Ninguém sabe quem possui.


🧠 Two Generals Problem corporativo

Em sistemas distribuídos existe toda uma discussão sobre confirmação e coordenação.

Na organização temos versão humana:

Pessoa A:

“Mandei mensagem.”

Pessoa B:

“Não vi.”

Pessoa A:

“Mas mandei.”

Tecnicamente:

mensagem transmitida.

Operacionalmente:

responsabilidade não assumida.

Por isso acknowledgement importa.


✅ ACK novamente

No capítulo de Alarm Fatigue aprendemos:

ACK ≠ RESOLVED

Agora adicionamos:

DELIVERED ≠ OWNED

E:

READ ≠ ACTION

Essas três inequações deveriam estar na parede da War Room.


🧀 Diffusion of Responsibility encontra o Swiss Cheese

Uma fatia importante de segurança é:

resposta humana.

Monitor detecta.

Equipe recebe.

Parece barreira robusta.

Mas:

ninguém possui ownership.

Temos um buraco.

Pior.

Todos acreditam que a barreira existe.

Isso produz falsa confiança.


🚨 Alarm Fatigue + Diffusion of Responsibility

Agora os dois monstros se encontram.

Quatro mil alertas.

Todos enviados para vinte pessoas.

Cada pessoa pensa:

alguém pegará os importantes.

Perfeito.

Temos ruído distribuído para responsabilidade distribuída.

O verdadeiro alerta entra.

E desaparece.


🤖 Automation Bias + Diffusion of Responsibility

Sistema automático cria ticket.

Ótimo.

Ticket entra numa fila geral.

Todos confiam:

sistema direcionará corretamente.

Mas regra de roteamento está errada.

Ticket permanece sem owner.

Como foi criado automaticamente, todos assumem que o processo automático também garantiu tratamento.

Não garantiu.

Automação aumentou sensação de segurança.

Ownership continuou vazio.


👥 Groupthink também aparece

Equipe inteira vê ninguém reagindo.

Cada pessoa interpreta silêncio como:

provavelmente não é grave.

Esse mecanismo é próximo daquilo que psicólogos chamam de pluralistic ignorance.

Cada pessoa observa a ausência de reação das outras e usa isso como informação.

Internamente:

“Estou preocupado.”

Externamente:

ninguém age.

Então todos concluem:

“Talvez eu esteja exagerando.”

Agora o silêncio se autoalimenta.


😐 Pluralistic Ignorance

Imagine oito pessoas numa sala.

Todas sentem cheiro estranho.

Cada uma olha para as outras.

Ninguém reage.

Cada uma pensa:

“Se fosse perigoso, alguém estaria preocupado.”

Mas todos estão preocupados.

Fantástico.

Agora troque cheiro por:

QUEUE DEPTH +400%

War Room:

ninguém fala.

Mesmo mecanismo.


⚓ Anchoring Bias pode definir o dono errado

Primeiro chamado diz:

“Problema de rede.”

Todos:

— Network team cuidará.

A rede pensa:

— Não é nossa.

Mas ninguém realoca formalmente.

Agora incidente fica órfão.

O título inicial ancorou não apenas diagnóstico.

Ancorou ownership.


🪜 Authority Gradient e responsabilidade

Júnior percebe:

— Ninguém está olhando isso.

Mas pensa:

“O gerente certamente sabe.”

Ou:

“O Incident Commander já deve ter atribuído.”

Não pergunta.

Authority Gradient transforma dúvida em silêncio.


▶️ Plan Continuation Bias

Mudança em andamento.

Alerta surge.

Todos assumem que “alguém da validação” está analisando.

Ninguém interrompe plano.

Continua.

Mais um exemplo de como nossos monstros cooperam.


🌀 Drift Into Failure

Difusão de responsabilidade também pode se tornar estrutural ao longo do tempo.

Equipe pequena:

ownership claro.

Empresa cresce.

Mais times.

Mais fornecedores.

Mais camadas.

Agora:

Aplicação.

Plataforma.

Infra.

Cloud.

Mainframe.

Middleware.

Rede.

Segurança.

Fornecedor A.

Fornecedor B.

Quem é dono do fluxo ponta a ponta?

Resposta:

depende.

Essa resposta merece investigação.


🕸️ Complexidade organizacional cria fronteiras

Muitos incidentes vivem nas interfaces.

Time A:

meu componente está verde.

Time B:

o meu também.

Time C:

idem.

Usuário:

não funciona.

Cada equipe possui parte.

Ninguém possui jornada completa.

Isso é perigoso.


🗺️ Component Ownership versus Service Ownership

Você pode possuir:

CICS.

Db2.

MQ.

API.

Mas quem possui:

Pagamento do cliente?

Isso é diferente.

Serviços ponta a ponta precisam de responsabilidade além de componentes.

Caso contrário:

todos os componentes verdes.

Cliente vermelho.


💻 O COBOL está funcionando!

Programador:

— Meu programa retornou RC=00.

DBA:

— Db2 normal.

MQ:

— Mensagem entregue.

API:

— HTTP 200.

Cliente:

— Dinheiro não chegou.

Cada profissional está correto localmente.

O sistema está errado globalmente.

Drift Into Failure nos ensinou sobre racionalidade local.

Diffusion of Responsibility acrescenta:

ninguém pode estar olhando o todo.


🧠 O problema dos silos

Silos organizacionais não são apenas problema burocrático.

São risco técnico.

Quanto mais fragmentado:

mais handoffs;

mais fronteiras;

mais possibilidade de:

“não é comigo.”

Essa frase deveria ser tratada como evento operacional.


🚪 “Not my problem”

Às vezes realmente não é responsabilidade daquele time.

Tudo bem.

Mas resposta madura não é:

“Não é nosso.”

É:

“Não é nosso componente. Estou transferindo para X e confirmando que assumiram.”

O incidente precisa sair de uma mão e chegar a outra.

Não cair no chão.


🏷️ Incident Commander

É exatamente por isso que o papel de Incident Commander pode ser tão útil.

Não precisa ser o maior especialista técnico.

Sua função é garantir:

quem investiga o quê;

quem possui a próxima ação;

qual prazo;

qual hipótese;

qual decisão;

qual escalonamento.

Ou seja:

o Incident Commander combate difusão de responsabilidade.


🎬 War Room sem direção

Imagine:

15 especialistas falando.

Cada um executa alguma coisa.

Mas ninguém sabe:

quem decide;

quem registra;

quem atualiza;

quem comunica;

quem acompanha ação.

Isso não é equipe.

É multiplayer sem party leader.

E o boss está batendo.


🎮 Easter Egg nº 2 — Raid de RPG

Imagine uma raid.

Tank pensa:

healer vai puxar.

Healer pensa:

tank vai puxar.

DPS já começou.

Boss acorda.

Raid wipe.

No post-mortem:

“Quem puxou?”

Resposta:

“Ninguém.”

TI às vezes consegue reproduzir MMORPG com orçamento corporativo.


🧪 RACI pode ajudar — mas não salvar sozinho

Uma ferramenta conhecida:

RACI

Responsible.

Accountable.

Consulted.

Informed.

Pode ser útil para esclarecer funções.

Exemplo:

INCIDENTE DE PAGAMENTO

Responsible:
Payments Operations

Accountable:
Payments Manager

Consulted:
DB2, MQ, CICS

Informed:
Business, Service Desk

Muito melhor que:

todos envolvidos.

Mas cuidado.

Matriz no SharePoint não resolve automaticamente cultura.

Precisa refletir trabalho real.


🧠 Responsible versus Accountable

Uma distinção útil:

Responsible

faz o trabalho.

Accountable

responde pelo resultado e garante que exista dono.

Em incidentes críticos, alguém precisa possuir accountability.

Não necessariamente executar tudo.


📝 Single Threaded Owner

Outra ideia muito útil:

uma pessoa claramente responsável pela coordenação do problema.

Mesmo com dezenas de especialistas.

Não significa centralizar conhecimento.

Significa centralizar ownership.


🎯 Pergunta Bellacosa nº 1

Quando surgir incidente:

“Quem é o dono?”

Se resposta:

“A equipe.”

Pergunte novamente.

“Qual pessoa está coordenando?”

Nome.


🎯 Pergunta Bellacosa nº 2

Para cada atividade:

“Quem vai fazer e quando retorna?”

Não:

“Precisamos verificar MQ.”

Mas:

“Carlos verifica MQ e retorna às 09:30.”

Agora existe ação.


🎯 Pergunta Bellacosa nº 3

Depois de handoff:

“A outra pessoa confirmou que assumiu?”

Se não:

a responsabilidade ainda é sua.

Essa regra pode evitar muita coisa.


🎯 Pergunta Bellacosa nº 4

Quando dez pessoas recebem alerta:

“Quem precisa acordar por causa dele?”

Se ninguém:

talvez o alerta seja informativo.

Se alguém:

roteie diretamente.


🔔 Notifications devem refletir papéis

Nem todo mundo precisa pager.

Talvez:

Owner:

pager.

Especialistas:

Teams.

Gestão:

status periódico.

Usuários:

comunicação de impacto.

Um sistema que manda a mesma mensagem para todos não está necessariamente comunicando bem.


🧠 Broadcast cria espectadores

Quanto mais amplo o broadcast:

mais pessoas informadas.

Mas também pode criar:

mais espectadores passivos.

Se precisar de ação:

atribua.


🔥 Incêndio corporativo

Imagine prédio pegando fogo.

Mensagem:

“Pessoal, alguém chama os bombeiros?”

Você ficaria tranquilo?

Melhor:

“Maria, ligue para emergência. Carlos, evacue o andar. João, confirme.”

Incidentes precisam dessa clareza.


🛑 Role Assignment nos primeiros minutos

Uma War Room madura deveria rapidamente definir algo como:

INCIDENT COMMANDER: ANA

TECH LEAD: CARLOS

COMMS: JULIANA

SCRIBE: PEDRO

DB2: MARIA

MQ: ROBERTO

APPLICATION: LUCAS

Agora ninguém pergunta:

“Achei que alguém estava anotando.”

Temos Pedro.

Pobre Pedro.

Mas necessário.


✍️ O Scribe é mais importante do que parece

Durante crise:

ações acontecem rápido.

Sem registro:

hipóteses repetidas;

decisões esquecidas;

comandos duplicados;

handoffs confusos.

Scribe preserva memória coletiva.

Isso reduz difusão cognitiva.


📜 Decision Log novamente

09:13
Carlos assume MQ.

09:16
MQ channel healthy.

09:18
Maria verifica DB2 waits.

09:22
DB2 normal.

09:24
Hipótese muda para consumer.

Agora todo mundo sabe.


🚧 Evite investigação duplicada

Difusão de responsabilidade tem um primo estranho:

às vezes ninguém faz.

Outras vezes cinco pessoas fazem a mesma coisa.

Porque ninguém coordenou.

Resultado:

DBA investigado cinco vezes.

MQ ninguém olhou.

Ownership também evita duplicação.


🧮 Paralelismo precisa ser controlado

Mainframeiro entende paralelismo.

Você quer tarefas independentes.

THREAD A → DB2
THREAD B → MQ
THREAD C → APPLICATION

Não:

THREAD A → DB2
THREAD B → DB2
THREAD C → DB2
MQ → NINGUÉM

War Room também precisa scheduling.


📊 Action Board

Uma ferramenta incrivelmente simples:

AÇÃO             OWNER      PRAZO    STATUS
MQ consumer      Carlos     09:30    RUNNING
DB2 wait         Maria      09:28    DONE
App logs         João       09:32    RUNNING
Comms negócio    Ana        09:35    OPEN

Acaba com boa parte da ambiguidade.


🧠 “Eu achei que...”

Uma frase favorita dos post-mortems:

“Eu achei que fulano estava fazendo.”

Alarmes.

Backups.

Validação.

Rollback.

Comunicação.

Esses “achei” são ouro investigativo.

Pergunte:

Por que o sistema permitiu que uma atividade crítica dependesse de suposição?


💾 Backup: o clássico

Todo mundo acredita:

infraestrutura faz backup.

Infra acredita:

aplicação valida restore.

Aplicação acredita:

backup é responsabilidade da infra.

Incidente.

Backup existe.

Restore nunca testado.

Diffusion of Responsibility mora feliz.


🔐 Segurança

Alerta de vulnerabilidade.

Security envia para aplicação.

Aplicação pensa:

plataforma corrigirá.

Plataforma:

código é aplicação.

90 dias depois:

continua aberto.

CVSS não liga para organograma.


🏦 Reconciliação financeira

Operação:

negócio valida valores.

Negócio:

TI valida processamento.

TI:

reconciliação é automática.

Automação:

erro.

Quem percebe?

Talvez o cliente.

Nunca faça do cliente seu mecanismo de observabilidade.


🧠 Customer as Monitor

Existe um anti-pattern terrível:

“Se der problema, usuário reclama.”

Isso significa:

cliente virou sistema de alerta.

Alarm Fatigue agradece.

Automation Bias agradece.

Diffusion of Responsibility também.


🤖 Agentes de IA e responsabilidade

Agora fica interessante.

Imagine múltiplos agentes:

Agent A analisa.

Agent B executa.

Agent C valida.

Quem é responsável pelo resultado?

Não diga:

“o agente.”

Responsabilidade organizacional continua humana.

Precisamos saber:

quem configurou;

quem autorizou;

quem monitora;

quem pode interromper;

quem responde por exceção.


🤖 Multi-Agent Diffusion

Agentes também podem criar versão tecnológica:

Agent A:

deleguei para B.

B:

classifiquei como responsabilidade de C.

C:

aguardando entrada de A.

Loop.

Nenhum humano percebe.

Então sistemas multiagentes precisam:

ownership;

state;

timeouts;

escalation;

orchestrator.

Viu como nossa teoria volta aos agentes?


🧭 Orchestrator como Incident Commander

Num sistema agentic:

orquestrador precisa saber:

quem está fazendo;

qual status;

quando expira;

quando escalar.

Exatamente como War Room.

Tecnologia muda.

Coordenação continua sendo coordenação.


⏰ Timeout de responsabilidade

Uma tarefa não deveria ficar eternamente:

STATUS: ASSIGNED

Sem resposta.

Defina timeout.

ACK REQUIRED: 5 MIN
ACTION UPDATE: 15 MIN
ESCALATE: 20 MIN

Responsabilidade precisa de relógio.


🧠 Escalation não é punição

Escalar significa:

a condição exige mais atenção.

Não:

alguém falhou moralmente.

Se escalonamento vira punição, pessoas escondem atraso.

Just Culture novamente.


🧪 Passo a passo para combater Diffusion of Responsibility

Passo 1 — Todo incidente precisa de owner

Uma pessoa.

Nome.

Não “time”.


Passo 2 — Toda ação precisa de owner

“Verificar banco”

não é ação completa.

Use:

“Maria verifica Db2 até 09:30.”

Passo 3 — Exija ACK

Assignment sem confirmação não terminou.


Passo 4 — Defina tempo

Responsabilidade sem deadline pode evaporar.


Passo 5 — Crie escalation path

Se owner não responde:

quem recebe?


Passo 6 — Separe FYI de ACTION REQUIRED

No assunto.

Na ferramenta.

Na cultura.


Passo 7 — Use Incident Commander

Principalmente em incidentes grandes.


Passo 8 — Registre handoffs

Não confie em memória.


Passo 9 — Audite filas sem owner

Tickets.

Alertas.

Vulnerabilidades.

Problemas.

Tudo que não possui dono é dívida operacional.


Passo 10 — Investigue “achei que alguém”

Toda vez que essa frase aparece no post-mortem, existe oportunidade de melhorar processo.


📬 FYI versus ACTION REQUIRED

Uma disciplina simples.

FYI:
Informação.

ACTION:
Pessoa específica precisa fazer algo.

Não misture.

Se tudo pede ação:

Alarm Fatigue.

Se nada especifica ação:

Diffusion of Responsibility.


🎯 O equilíbrio

Boa operação precisa de:

informação suficiente;

responsabilidade específica.

VISIBILIDADE AMPLA
+
OWNERSHIP CLARO
=
COORDENAÇÃO

Não precisamos esconder informação.

Precisamos evitar ambiguidade.


🧠 Dunbar não salva a War Room

Adicionar pessoas não aumenta indefinidamente capacidade.

Às vezes mais gente significa:

mais canais;

mais conversas;

mais suposições;

mais handoffs.

Existe custo de coordenação.

Um incidente com 50 pessoas pode ser mais difícil que com 10 especialistas bem organizados.


🚪 War Room precisa de porta

Nem todo mundo precisa falar.

Alguns podem acompanhar.

Roles:

core responders;

SMEs sob demanda;

stakeholders informados.

Isso reduz ruído.


🧠 Incident Command System

Estruturas de comando em emergência existem por uma razão:

quando tudo fica caótico, funções precisam ficar mais claras, não menos.

Tecnologia às vezes tenta resolver crise colocando cinquenta especialistas numa call.

Não é necessariamente coordenação.

Pode ser apenas Zoom cheio.


👻 Easter Egg nº 3 — 50 pessoas no Teams

War Room:

“Participants: 57”

Doctor:

— Quem está coordenando?

— Não sei.

— Quem está investigando MQ?

— Acho que alguém.

— Quem comunica usuários?

— Deve ter alguém.

Doctor:

— Então por que temos 57 pessoas?

Silêncio.

— Ah.

— O quê?

— Vocês estão usando quantidade como substituto de estrutura.


🧩 Diffusion of Responsibility no code review

PR com 12 reviewers.

Cada um pensa:

alguém fará review profundo.

Resultado:

12 approvals superficiais.

Compare com:

PRIMARY REVIEWER: Maria
SECURITY REVIEWER: Carlos
DB REVIEWER: Ana

Funções claras.


🧪 Testes

“Equipe é responsável pelos testes.”

Quem escreve?

Quem valida?

Quem dá sign-off?

Se ninguém sabe:

todo mundo pode acreditar que outra pessoa cobriu determinado cenário.


📚 Documentação

“Precisamos documentar.”

Todo mundo concorda.

Seis meses depois:

nenhum documento.

Por quê?

Porque tarefas coletivas abstratas não executam a si mesmas.

OWNER: João
DUE: sexta

A mágica administrativa.


🧠 Shared Responsibility precisa de fronteiras claras

Cloud popularizou expressão:

shared responsibility.

Importante.

Mas responsabilidade compartilhada não significa responsabilidade ambígua.

Precisamos saber:

provedor faz X.

cliente faz Y.

integração faz Z.

Toda fronteira precisa estar explícita.


☁️ “Achei que a cloud fazia backup”

Clássico.

Serviço fornece mecanismo.

Cliente precisa configurar.

Cliente pensa:

provider faz.

Incidente.

Surpresa.

Shared Responsibility mal compreendida vira Diffusion of Responsibility contratual.


🧠 Psychological Ownership

Quando alguém diz:

“Esse serviço é meu.”

normalmente presta mais atenção.

Isso é ownership psicológico.

Organizações maduras desenvolvem isso sem criar feudos.

Você quer:

“Eu cuido.”

Não:

“Só eu mexo.”


🚧 Ownership não pode virar silo

Cuidado.

Combater Diffusion of Responsibility não significa criar:

“Esse problema é seu, me deixa fora.”

Owner coordena.

Especialistas colaboram.

Responsabilidade clara + conhecimento distribuído.

Essa é a meta.


👨‍💻 Dica Bellacosa para o COBOL iniciante

Você encontra problema.

Manda no grupo:

“Pessoal, achei algo estranho.”

Não pare aí.

Se ninguém responder:

follow-up.

“Maria, você é owner dessa rotina? Posso abrir incidente e acompanhar?”

Ou assuma temporariamente:

“Vou iniciar análise e preciso de alguém de Db2.”

Não deixe descoberta importante evaporar em chat.


📢 Speak Up + Take Ownership

No Authority Gradient aprendemos a falar.

Agora precisamos aprender o próximo passo:

“Eu vi.”

não basta.

Talvez seja necessário:

“Eu assumo até transferir formalmente.”

Essa é uma poderosa mentalidade operacional.


🧠 Mas cuidado com heroísmo

Não queremos que uma pessoa assuma tudo.

Isso nos leva ao problema de heróis.

Owner não significa:

executar 27 tarefas.

Significa garantir que 27 tarefas possuam donos.

Essa diferença protege pessoas e sistemas.


🦸 Incident Commander não é Superman

Ele não resolve tudo.

Ele impede:

coisas esquecidas;

duplicação;

contradição;

responsabilidade órfã.

Orquestra.

Como JES para humanos.


😄 JES humano

Agora temos talvez um conceito digno do Bellacosa Mainframe:

Incident Commander é o JES da War Room.

Jobs chegam.

Prioridades.

Owners.

Estados.

Dependências.

O JES não executa o COBOL.

Coordena processamento.

Incident Commander também.

Há um Easter Egg mainframeiro que merecia existir.


🔄 Handoff de turno

Diffusion of Responsibility fica especialmente perigosa em mudança de turno.

Turno A:

turno B continuará.

Turno B:

achei que A tivesse encerrado.

Portanto handover precisa ser formal.


📋 Handover mínimo

INCIDENT:
INC-1234

CURRENT OWNER:
Ana

CURRENT STATE:
Queue stabilized, root cause open.

OPEN ACTIONS:
Carlos → consumer logs
Maria → reconciliation

NEXT DECISION:
10:30

RISKS:
Backlog remains.

Agora turno seguinte entra com contexto.


🕰️ Temporal Diffusion of Responsibility

Existe até uma versão temporal interessante:

“Amanhã resolvemos.”

Quem é amanhã?

Pessoas mudam.

Prioridades mudam.

Se tarefa futura não possui owner e deadline:

pode nunca existir.


🗃️ Backlog é cemitério de responsabilidades?

Pode ser.

Ações de post-mortem:

Improve monitoring.
Review process.
Update documentation.

Quem?

Quando?

Sem owner:

são desejos.

Não ações.


🔁 Melhoria contínua exige owner

Todo action item deveria ter:

ACTION
OWNER
DATE
SUCCESS CRITERIA
EVIDENCE

Caso contrário:

post-mortem produz PowerPoint.

Não melhoria.


🧠 Accountability sem blame

Precisamos distinguir.

Accountability:

responsabilidade clara pelo acompanhamento.

Blame:

busca simplista de culpado.

Você pode ter cultura blameless e ownership forte.

Aliás, deveria.

Blameless não significa:

ninguém é responsável.

Significa:

responsabilidade serve para coordenar e aprender, não para simplificar causas sistêmicas.


🧀 A fatia “ownership”

Vamos adicionar ao Swiss Cheese:

FATIA:
CLEAR OWNERSHIP

Buracos:

responsável desconhecido;

handoff incompleto;

alerta genérico;

on-call desatualizado;

equipe errada;

escalation inexistente.

Agora podemos fortalecer essa barreira.


🔍 Métricas interessantes

Meça:

alertas sem ACK;

tickets sem owner;

tempo até ownership;

handoffs falhos;

ações vencidas;

incidentes sem Incident Commander;

vulnerabilidades órfãs.

São indicadores organizacionais.


⏱️ Time to Ownership

Todo mundo mede:

MTTD — Mean Time to Detect.

MTTR — Mean Time to Restore.

Talvez devêssemos observar:

Time to Ownership

Quanto tempo entre:

problema detectado;

alguém claramente assumir?

Esse intervalo pode ser crítico.


📊 Exemplo

09:01 Alert
09:23 Owner assigned

22 minutos.

Talvez investigação técnica tenha durado apenas 10.

Então metade do incidente foi:

ninguém assumindo.

Descoberta valiosa.


🎯 Pergunta pós-incidente

Não pergunte apenas:

“Quando detectamos?”

Pergunte:

“Quando alguém assumiu responsabilidade explícita?”

Às vezes as respostas são muito diferentes.


🔬 RCA organizacional

Timeline:

09:01 alert generated
09:02 sent to distribution list
09:05 seen by operations
09:07 seen by application
09:12 second alert
09:19 user impact
09:22 someone asks who is checking
09:25 owner assigned

Root cause técnico:

consumer failed.

Contributing factor:

22 minutos sem owner.

Isso produz ação concreta:

melhorar roteamento e ownership.


🧠 Hindsight Bias retorna

Depois:

— Como ninguém fez nada?

Cuidado.

Talvez cada pessoa racionalmente acreditasse que outra era responsável.

Não basta dizer:

“Todos deveriam agir.”

Isso perpetua ambiguidade.

Melhor:

“Nosso design de ownership permitiu que todos acreditassem que outro agiria.”

Agora podemos corrigir.


🌀 Drift Into Failure retorna

Talvez antigamente houvesse um operador claramente responsável.

Depois reorganizações.

Outsourcing.

Novo fornecedor.

Cloud.

Novos times.

Responsabilidade ficou fragmentada.

Não houve decisão:

“Vamos perder ownership.”

A organização derivou.

Lembra?

Nossos monstros estão cada vez mais interligados.


🧬 Regeneração organizacional

Como regenerar após encontrar Diffusion of Responsibility?

Primeiro:

identifique serviços críticos.

Depois:

owner explícito.

On-call.

Escalation.

ACK.

Incident Commander.

Action board.

Handoffs formais.

Post-mortem actions com dono.

E principalmente:

ensine uma regra simples:

uma responsabilidade não foi transferida até que a próxima pessoa tenha aceitado.

Isso muda muita coisa.


📋 Checklist anti-Diffusion

Durante incidente:

[ ] Existe Incident Commander?

[ ] Existe owner técnico?

[ ] Cada ação possui uma pessoa?

[ ] Cada ação possui prazo?

[ ] Handoffs foram confirmados?

[ ] Alertas têm owner definido?

[ ] Existe escalation path?

[ ] FYI está separado de ACTION?

[ ] Alguém está registrando decisões?

[ ] Existe alguma tarefa que “todo mundo” deveria fazer?

[ ] Algum item está sem nome ao lado?

Se aparecer:

OWNER: ALL

talvez devêssemos conversar.


📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Diffusion of Responsibility acontece quando várias pessoas presentes reduzem a sensação individual de responsabilidade para agir.

Informar não é atribuir responsabilidade.

Entregue não significa assumido.

Lido não significa tratado.

Todo incidente precisa de owner claro.

Toda ação precisa de pessoa e prazo.

Handoffs precisam de confirmação.

Broadcast amplo pode produzir espectadores.

Incident Commander reduz ambiguidade.

Responsabilidade clara é compatível com cultura blameless.

Silos tornam incidentes ponta a ponta especialmente vulneráveis.

E principalmente:

Se a resposta para “quem está cuidando?” é “alguém”, existe uma chance perigosamente grande de que a resposta real seja “ninguém”.


🕰️ De volta às 09:01

A TARDIS retorna.

VWORP.

O alerta acaba de chegar:

PAYMENT QUEUE DEPTH > THRESHOLD

Vinte e três pessoas recebem.

Nosso programador olha.

Desta vez não pensa:

“Alguém vai olhar.”

Escreve:

“Estou assumindo triagem inicial do alerta de PAYMENT QUEUE. Preciso de suporte MQ.”

Carlos responde:

“Assumo MQ.”

Maria:

“Fico com consumer.”

Incident Commander entra:

OWNER: JOÃO

MQ: CARLOS

CONSUMER: MARIA

NEXT UPDATE: 09:10

09:05.

Consumer parado.

09:07.

Causa identificada.

09:09.

Serviço restaurado.

Fila começa a cair.

Nenhum cliente percebe.

O gerente pergunta:

— Foi grave?

Nosso programador responde:

— Poderia ter sido.

— O que mudou?

Ele olha para o quadro.

Cada atividade possui um nome.

— Dessa vez ninguém ficou esperando “alguém”.

O Doctor sorri.

— Excelente.

— Isso foi tudo?

— Quase.

— O que falta?

O Doctor aponta para o post-mortem.

— Descobrir por que vocês precisaram de sorte nas vezes anteriores.

Naturalmente.


🥚 Easter Egg final

Horas depois aparece um dataset:

BELLACOSA.INCIDENTS(WHO)

Dentro:

       IF OWNER = SPACES
           MOVE 'DANGER' TO SYSTEM-STATUS
       END-IF.

       IF OWNER = 'EVERYONE'
           MOVE 'NO-ONE' TO EFFECTIVE-OWNER
       END-IF.

       IF RESPONSIBILITY-TRANSFERRED
           PERFORM WAIT-FOR-ACK
       END-IF.

Comentário:

* SOMEBODY IS NOT A VALID USERID.

Nosso programador ri.

Outra linha:

* ASSIGN THE COMPANION.

Depois:

* BAD WOLF ACKNOWLEDGED.

E finalmente:

* DON'T ASK WHO COULD DO IT.
* ASK WHO WILL.

Ele fecha o membro.

Pouco depois chega um email:

“Pessoal, precisamos atualizar a documentação até sexta. Alguém consegue cuidar?”

Nosso programador olha.

Quarenta destinatários.

Sorri.

Responde:

“Posso assumir. Entrego uma primeira versão quinta às 15h. Carlos, consegue revisar depois?”

Carlos:

“Confirmado.”

Nada explodiu.

Nenhuma fila cresceu.

Nenhum pagamento falhou.

Mas alguma coisa mudou.

A responsabilidade deixou de ser uma nuvem.

Virou nome.

Prazo.

Confirmação.

Em algum lugar do espaço-tempo:

VWORP.

VWORP.

VWORP.

Porque o Doctor talvez tenha finalmente descoberto o maior inimigo de “alguém”:

uma pessoa claramente responsável.

☕🌀

Next stop: Normalcy Bias — quando o desastre já começou, os sinais estão diante de nós, mas nosso cérebro continua insistindo que provavelmente tudo voltará ao normal sozinho.

 

terça-feira, 7 de setembro de 2010

Alarm Fatigue: Doctor Who, COBOL e o Dia em que o Sistema Gritou Tanto que Ninguém Mais Escutou

Bellacosa Mainframe e o alarm fatigue

☕ Um Café no Bellacosa Mainframe

Alarm Fatigue: Doctor Who, COBOL e o Dia em que o Sistema Gritou Tanto que Ninguém Mais Escutou

Uma viagem pela TARDIS dos incidentes para entender como excesso de alertas transforma monitoramento em ruído e prepara o caminho para falhas reais

07:58.

Sala de operação.

Café recém-passado.

SDSF aberto.

Painéis verdes.

Tudo parece tranquilo.

Até que começam as mensagens.

WARNING STORAGE 78%
WARNING QUEUE DEPTH HIGH
WARNING JOB DELAYED
WARNING RETRY DETECTED
WARNING DB2 WAIT
WARNING MQ CHANNEL
WARNING CPU THRESHOLD
WARNING TIMEOUT
WARNING DATASET USAGE
WARNING APPLICATION RESPONSE

Nosso programador COBOL iniciante olha para a tela.

— Tem bastante alerta.

O operador veterano responde:

— Normal.

09:11.

Mais alertas.

WARNING STORAGE 81%
WARNING JOB ABC123 RC=04
WARNING MQ RETRY
WARNING TIMEOUT
WARNING CPU SPIKE

O jovem pergunta:

— Precisamos investigar?

— Esses aí aparecem sempre.

11:42.

O alarme soa novamente.

O operador fecha.

13:07.

Outro.

Fecha.

14:18.

Outro.

Fecha.

14:37.

Mais um.

Fecha.

14:52.

Produção começa a falhar.

O operador olha para o painel.

Há uma mensagem piscando há 23 minutos.

CRITICAL:
QUEUE DEPTH RISING RAPIDLY
CONSUMER NOT RESPONDING

Ele não viu.

Na verdade, viu.

Mas seu cérebro decidiu que era apenas mais uma mensagem entre centenas.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se entre dois consoles.

A porta abre.

O Doctor sai.

Olha para os alarmes.

Olha para o operador.

Olha para a tela.

— Por que ninguém respondeu?

O operador suspira.

— Porque isso apita o tempo todo.

O Doctor observa uma sequência de warnings.

— Então vocês construíram um sistema para avisar quando algo está errado...

Pausa.

— ...e depois ensinaram as pessoas a ignorá-lo.

Silêncio.

O Doctor sorri daquela maneira pouco tranquilizadora.

— Fascinante.

Bem-vindo ao:



Alarm Fatigue

Ou:

Fadiga de Alarmes

O fenômeno pelo qual exposição excessiva a alertas, avisos e notificações reduz progressivamente nossa capacidade de perceber quais realmente importam.


🌀 Onde estamos na nossa jornada?

Até agora nossa TARDIS dos incidentes encontrou:

Swiss Cheese Model — várias barreiras podem falhar.

Normalization of Deviance — desvios repetidos deixam de parecer anormais.

Hindsight Bias — depois do incidente, tudo parece óbvio.

Confirmation Bias — procuramos evidências que confirmem nossas crenças.

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

Groupthink — o grupo converge rápido demais.

Authority Gradient — alguém percebe o risco, mas não sente liberdade para desafiar autoridade.

Plan Continuation Bias — mesmo quando o plano deveria parar, continuamos.

Agora encontramos uma falha diferente.

O sistema possui sensores.

Possui alertas.

Possui monitoramento.

Possui dashboards.

Mas existe informação demais.

E quando tudo grita:

nada grita.


🚨 O que é Alarm Fatigue?

Alarm Fatigue acontece quando uma pessoa é exposta a tantos alertas que começa a:

ignorar;

silenciar;

filtrar;

postergar;

automatizar respostas;

ou perder sensibilidade a eles.

O processo pode ser representado assim:

ALERTA
  ↓
ATENÇÃO
  ↓
OUTRO ALERTA
  ↓
OUTRO
  ↓
OUTRO
  ↓
REPETIÇÃO
  ↓
HABITUAÇÃO
  ↓
ALERTA VIRA RUÍDO

Então chega um alerta realmente importante.

Mas ele parece igual aos anteriores.

O sistema avisou.

O humano não reagiu.

No post-mortem alguém pergunta:

“Mas o alerta estava lá. Como ninguém viu?”

Resposta:

porque havia outros 847.


🧠 Nosso cérebro não foi projetado para viver dentro de um dashboard

Humanos são excelentes em detectar novidade.

Um barulho inesperado chama atenção.

Um barulho constante desaparece mentalmente.

Imagine morar perto de uma estrada.

Na primeira noite:

cada caminhão incomoda.

Depois de semanas:

você quase não percebe.

Isso é habituação.

Agora aplique a um ambiente operacional.

Primeiro warning:

atenção.

Centésimo warning:

rotina.

Milésimo:

paisagem.


☕ O RC=04 retorna outra vez

Nosso velho amigo:

JOB04217 ENDED - RC=0004

Primeira ocorrência:

— Vamos investigar.

Segunda:

— De novo?

Décima:

— Esse é conhecido.

Centésima:

ninguém olha.

Um dia o mesmo RC=04 representa condição diferente.

Ninguém percebe.

Alarm Fatigue acabou de se misturar com:

Normalization of Deviance.

A mensagem perdeu poder porque se tornou familiar.


🧀 Swiss Cheese + Alarm Fatigue

No Swiss Cheese Model, uma das barreiras pode ser:

monitoramento.

A ideia é:

falha acontece;

monitoramento detecta;

humano reage;

incidente é interrompido.

Mas se o monitoramento produz ruído demais:

FALHA
 ↓
ALERTA
 ↓
ALERTA IGNORADO
 ↓
PROPAGAÇÃO

A fatia existe.

Formalmente.

Tecnicamente.

Mas possui um buraco enorme.


📟 Monitoramento que ninguém usa não é defesa

Uma organização pode dizer:

“Temos alertas para isso.”

Ótimo.

Pergunta seguinte:

“Alguém consegue identificar esse alerta no meio dos outros?”

Se resposta for não, temos uma defesa teórica.

É como possuir extintor enterrado atrás de cinquenta caixas.

Está lá.

Mas talvez não sirva quando o fogo começar.


👻 Easter Egg nº 1 — Daleks demais

Imagine Doctor Who.

Um Dalek aparece.

Todos correm.

Dois Daleks.

Pânico.

Agora imagine mil Daleks entrando na sala diariamente apenas para dizer:

“Bom dia.”

Depois de seis meses, talvez alguém comece a ignorá-los.

Até o dia em que um diz:

EXTERMINATE.

E ninguém levanta os olhos.

Esse é Alarm Fatigue.


📢 Warning, Critical, Info, Error… tudo vermelho

Outro problema comum:

todos os alertas parecem igualmente importantes.

Exemplo:

WARNING: TEMP FILE CREATED

WARNING: CPU 72%

WARNING: USER RETRY

WARNING: CORE BANKING DOWN

Se visualmente todos usam:

vermelho;

sirene;

email;

SMS;

pager;

Teams;

então prioridade desaparece.

Hierarquia de severidade precisa ser real.


🎨 Semântica visual importa

Pense:

INFO
algo útil.

NOTICE
observe.

WARNING
há risco.

CRITICAL
ação imediata.

Se tudo vira CRITICAL:

CRITICAL deixa de significar crítico.

O mesmo acontece quando todo ticket é:

URGENTE.

Depois de algum tempo:

urgente significa normal.


🧠 Alarm Fatigue não é preguiça

É importante entender isso.

Quando alguém ignora alarmes repetidos, pode parecer negligência.

Mas frequentemente existe um problema de design.

Se o sistema dispara centenas de falsos positivos, humanos naturalmente criam atalhos.

Começam a:

fechar automaticamente;

silenciar canais;

criar filtros;

reconhecer sem investigar.

A organização treinou esse comportamento.

Então dizer:

“Operador deveria prestar mais atenção”

pode ser uma correção muito pobre.


🔔 False Positive é caro

Imagine um alerta que dispara 100 vezes.

99 são irrelevantes.

1 é real.

O sistema parece ter sensibilidade alta.

Mas operacionalmente pode ser ruim.

Porque cada falso positivo consome:

atenção;

tempo;

credibilidade.

Existe um recurso invisível em operação:

confiança no alerta.

Se o alerta perde credibilidade, perde função.


📉 Precisão operacional

Um bom alerta deveria fazer alguém pensar:

“Quando isso aparece, vale a pena olhar.”

Se operador pensa:

“Ah, esse de novo.”

Temos problema.

Não basta medir:

quantos alertas existem.

Precisamos medir:

quantos são acionáveis.


🎯 Actionable Alert

Um alerta bom responde algumas perguntas.

O que aconteceu?

MQ QUEUE DEPTH > 20.000

Onde?

QUEUE: PAYMENT.REQUEST

Desde quando?

SINCE: 14:31

Por que importa?

CONSUMER RATE < PRODUCER RATE

O que fazer?

CHECK CONSUMER PAYMENT01

Isso é melhor que:

WARNING MQ

Obrigado, sistema.

Muito esclarecedor.


🧙 Easter Egg nº 2 — “Something went wrong”

Todo profissional já encontrou uma mensagem maravilhosa:

AN ERROR OCCURRED.

Ou:

SOMETHING WENT WRONG.

Excelente.

Algo.

Em algum lugar.

Fez alguma coisa.

Observabilidade nível oráculo grego.

Mensagens precisam ajudar investigação.

Não apenas comunicar tristeza.


💻 Alarm Fatigue no mundo COBOL

Nosso programador iniciante pode encontrar alertas em:

JCL;

SDSF;

CICS;

Db2;

MQ;

storage;

WLM;

SMF;

monitoramento corporativo;

scheduler;

APM;

scripts;

emails;

tickets.

Imagine uma operação com milhares de jobs.

Se cada RC=04 gerar incidente:

ninguém sobreviverá.

Então precisamos distinguir:

RC=04 esperado;

RC=04 inesperado;

RC=04 crescente;

RC=04 em job crítico;

RC=04 correlacionado com outro sintoma.

Contexto importa.


🧠 O mesmo valor pode ter significados diferentes

Exemplo:

CPU 80%

Isso é alerta?

Depende.

Em determinado LPAR:

normal.

Em outro:

anormal.

Durante fechamento:

esperado.

Às 04:00:

talvez estranho.

Logo, threshold fixo pode gerar ruído.

Baseline contextual é melhor.


📈 Alertar tendência pode ser melhor que limite

Exemplo:

dataset:

segunda: 72%

terça: 74%

quarta: 77%

quinta: 81%

sexta: 86%

Talvez o mais importante não seja:

USAGE > 90%

Mas:

GROWTH RATE ABNORMAL

Porque sinais fracos vivem em tendência.


🔍 O sistema não deveria apenas perguntar “quebrou?”

Deveria perguntar:

“Está se comportando diferente?”

Essa distinção é fundamental.

Um job ainda RC=00 pode estar:

20% mais lento;

consumindo dobro de I/O;

gerando mais retries;

rejeitando mais registros.

Ainda não falhou.

Mas está falando conosco.


📊 Baseline retorna à TARDIS

Nos capítulos anteriores vimos baseline.

Agora ele vira arma contra Alarm Fatigue.

Se um comportamento é normal:

não alerte desnecessariamente.

Se mudou significativamente:

alerte.

Isso reduz ruído.


🚨 Alertas estáticos versus inteligentes

Alerta estático:

QUEUE > 1000

Alerta contextual:

QUEUE > NORMAL_BASELINE
AND
GROWTH RATE > X
AND
CONSUMER RATE FALLING

O segundo pode ser muito mais valioso.

Porque tenta detectar situação.

Não apenas número.


🧠 Correlation Engine

Em ambientes grandes, vários alertas podem representar uma única causa.

Exemplo:

TIMEOUT
CPU HIGH
QUEUE HIGH
DB2 WAIT
APPLICATION ERROR

Cinco alertas.

Mas talvez tudo venha de:

consumer downstream degradado.

Se ferramenta correlaciona:

POSSIBLE ROOT INCIDENT:
DOWNSTREAM CONSUMER DEGRADED

reduz ruído.


🧩 Event Storm

Quando um componente falha, pode gerar tempestade de eventos.

Primeiro:

MQ consumer para.

Depois:

fila cresce.

Depois:

timeouts.

Depois:

retries.

Depois:

CPU aumenta.

Depois:

Db2 recebe carga.

Depois:

usuários reclamam.

Se cada consequência gera alerta separado, War Room recebe uma avalanche.

O verdadeiro trabalho é identificar:

qual foi o primeiro dominó.


🕰️ Timeline ajuda novamente

Construa:

14:31 CONSUMER DEGRADED
14:32 QUEUE +20%
14:34 TIMEOUTS
14:35 RETRIES
14:37 CPU +30%
14:40 USER ERRORS

Agora a história aparece.

Sem timeline:

cinco alarmes independentes.

Com timeline:

uma cadeia.


🔊 Alarm Flooding

Durante incidente sério, quantidade de alarmes pode aumentar justamente quando atenção é mais necessária.

Isso cria paradoxo:

quanto pior a situação,

mais informação chega,

menos capacidade temos de processá-la.

Por isso ferramentas e processos precisam filtrar.


🚦 Severity precisa representar ação

Uma classificação útil deveria ter consequência.

Por exemplo:

SEV4
informativo.

SEV3
investigar em horário normal.

SEV2
ação rápida.

SEV1
resposta imediata / incidente.

Se SEV1 acontece quarenta vezes por dia, sua severidade não significa nada.


📱 Notificação é interrupção

Todo alerta possui custo cognitivo.

Email.

SMS.

Pager.

Teams.

Telefone.

Cada interrupção quebra foco.

Logo:

mais alertas não significam automaticamente mais segurança.

Às vezes significam menos.


🔕 Silenciar não é necessariamente ruim

À primeira vista parece perigoso.

Mas eliminar alerta inútil pode aumentar segurança.

Se comprovadamente não é acionável:

remova;

reclassifique;

agruppe;

corrija.

A pior solução é mantê-lo eternamente porque:

“Talvez um dia seja útil.”

Você está cobrando atenção todos os dias.


🧪 Como saber se um alerta merece existir?

Pergunte:

  1. O que ele detecta?

  2. Quem deve agir?

  3. Qual ação deve acontecer?

  4. Em quanto tempo?

  5. Qual risco reduz?

  6. Quantas vezes dispara?

  7. Quantas vezes é falso?

  8. Quantas vezes resultou em ação útil?

Se ninguém sabe responder:

talvez seja apenas ruído institucional.


📝 Alert Ownership

Todo alerta importante deveria ter dono.

Não necessariamente uma pessoa específica, mas equipe.

Exemplo:

ALERT:
CICS RESPONSE > 3S

OWNER:
CICS OPERATIONS

RUNBOOK:
CICS-RESP-001

Sem ownership:

todos recebem.

Ninguém assume.


👥 “Todo mundo recebeu” = “ninguém recebeu”

Esse fenômeno é clássico.

Mensagem enviada para vinte pessoas.

Cada uma pensa:

“Alguém vai olhar.”

Resultado:

ninguém olha.

Melhor:

alerta roteado claramente.

Responsabilidade explícita.


🧠 Diffusion of Responsibility

Aqui entramos em outro fenômeno psicológico:

difusão de responsabilidade.

Quanto mais pessoas recebem um alerta sem dono claro, menor pode ser a sensação individual de responsabilidade.

Alarm Fatigue encontra psicologia social.

Mais um monstro esperando episódio.


📚 Runbook

Alerta sem ação conhecida causa hesitação.

Alerta com runbook:

1. Check queue depth.
2. Check consumer status.
3. Compare producer/consumer rate.
4. Restart only if condition X.
5. Escalate if Y.

Isso reduz esforço cognitivo.

Especialmente às três da manhã.


💤 Alarm Fatigue + fadiga humana

Às 14:00:

cem alertas já cansam.

Às 03:00:

pior.

Cansaço aumenta chance de:

ignorar;

clicar errado;

confundir severidade;

esquecer follow-up.

Por isso turno, handover e descanso são controles de segurança.


☕ O operador e o botão ACK

Existe um botão extremamente perigoso em sistemas de monitoramento:

ACKNOWLEDGE

Reconhecer não significa resolver.

Mas psicologicamente:

alerta desaparece.

Sensação de tarefa concluída.

Então precisamos distinguir:

ACKNOWLEDGED

de:

RESOLVED

Muito importante.


✅ O prazer do check verde

Nosso cérebro gosta de fechar coisas.

Ticket.

Alerta.

Checklist.

Se botão ACK remove incômodo, existe incentivo para usá-lo cedo demais.

Design de ferramenta influencia comportamento.


🧠 Confirmation Bias + Alarm Fatigue

Equipe acha que problema é rede.

Recebe cinquenta alertas.

Filtra mentalmente apenas os de rede.

Os demais parecem ruído.

Confirmation Bias seleciona dentro da tempestade.

Você pode ignorar exatamente o alerta correto porque não combina com a teoria atual.


⚓ Anchoring + Alarm Fatigue

Primeiro alerta:

DB2 WARNING

Vira âncora.

Depois chegam outros cinquenta.

Equipe continua olhando Db2.

O alerta realmente importante de MQ aparece no meio.

Ignorado.


👥 Groupthink + Alarm Fatigue

Sala inteira decide:

“Esses warnings são conhecidos.”

Pronto.

Consenso normalizou ruído.

Agora pessoa nova que pergunta:

— Mas esse é diferente...

pode ser silenciada.

Groupthink protege a fadiga.


🪜 Authority Gradient + Alarm Fatigue

Júnior:

— Esse alerta mudou de comportamento.

Sênior:

— Pode ignorar.

Júnior:

— Ok.

Esse “ok” pode custar caro.

Authority Gradient fecha mais um buraco.


▶️ Plan Continuation Bias + Alarm Fatigue

Mudança em andamento.

Alertas começam.

Equipe diz:

— Deve ser efeito temporário da implantação.

Continua.

Mais alertas.

— Quando terminar estabiliza.

Continua.

Até não estabilizar.

Plan Continuation Bias usa Alarm Fatigue como combustível.


🧠 Alarm Fatigue e Normalization of Deviance são parentes próximos

A diferença é sutil.

Normalization of Deviance:

comportamento anormal vira aceitável.

Alarm Fatigue:

sinalização repetida perde capacidade de chamar atenção.

Frequentemente caminham juntos.

Exemplo:

warning aparece todo dia.

Normalizamos a condição.

Depois cansamos do alerta.

Resultado:

silenciamos.

Agora o sistema perdeu uma barreira.


🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“Esse alerta pode ignorar.”

Pergunte:

“Então por que ele ainda existe?”

Talvez haja ótima resposta.

Se não houver:

investigue.


🎯 Pergunta Bellacosa nº 2

Quando um alerta dispara frequentemente:

“Qual porcentagem dessas ocorrências exige ação?”

Se for muito baixa:

tuning.


🎯 Pergunta Bellacosa nº 3

Pergunte:

“Se esse alerta aparecesse sozinho às 03:00, eu acordaria alguém?”

Se não:

talvez não deveria pager.


🧪 Passo a passo para combater Alarm Fatigue

Passo 1 — Inventarie alertas

Liste:

nome;

fonte;

severidade;

frequência;

owner;

ação.

Você pode descobrir coisas assustadoras.


Passo 2 — Meça volume

Quantos alertas:

por hora;

por turno;

por serviço;

por severidade?

Sem medir, ruído parece normal.


Passo 3 — Identifique top talkers

Quais cinco alertas geram mais notificações?

Talvez 80% do ruído venha de poucos itens.

Corrija primeiro.


Passo 4 — Analise false positives

Quantos alertas não exigem ação?

Esses estão gastando confiança.


Passo 5 — Elimine duplicação

O mesmo problema dispara:

email;

SMS;

Teams;

PagerDuty;

ticket?

Talvez esteja criando quatro interrupções para um evento.


Passo 6 — Agrupe eventos correlacionados

Uma causa.

Um incidente.

Não vinte alarmes.


Passo 7 — Ajuste thresholds

Use baseline real.

Evite números arbitrários herdados de 2009.


Passo 8 — Melhore mensagens

Inclua:

o que;

onde;

quando;

impacto;

próximo passo.


Passo 9 — Defina ownership

Quem age?

Sem dono, alerta vira decoração.


Passo 10 — Revise periodicamente

Sistema muda.

Carga muda.

Arquitetura muda.

Alerta que fazia sentido dois anos atrás pode hoje ser ruído.


🔁 Alarm Review

Uma boa prática operacional:

reunião periódica apenas para alertas.

Pergunte:

  • quais dispararam mais?

  • quais foram úteis?

  • quais foram ignorados?

  • quais chegaram tarde?

  • quais faltaram?

Observabilidade também precisa de melhoria contínua.


📊 Uma métrica maravilhosa: alert-to-action ratio

Imagine:

1.000 alertas.

20 ações reais.

Temos problema.

Agora:

50 alertas.

40 ações reais.

Muito melhor.

Meta não é “monitorar tudo”.

É criar informação operacionalmente útil.


🧠 Precision versus Recall

Existe trade-off.

Se alertarmos qualquer suspeita:

alta sensibilidade;

muitos falsos positivos.

Se alertarmos só quando certeza é enorme:

podemos perder sinais precoces.

Não existe configuração perfeita.

Precisamos equilibrar.

Isso depende do risco.

Sistema nuclear não usa mesma tolerância de blog pessoal.


🏦 Em sistemas bancários

Alguns alertas precisam ser extremamente sensíveis.

Exemplo:

duplicidade financeira.

fraude.

reconciliação.

Mas mesmo aí:

agrupamento;

priorização;

contexto;

ownership

continuam essenciais.


🔐 Em cybersecurity

SOC conhece Alarm Fatigue profundamente.

Ferramentas podem gerar milhares de eventos.

Se analistas recebem sinal demais:

ameaça verdadeira pode se esconder.

Então segurança moderna investe em:

correlation;

enrichment;

risk scoring;

priorização.

Mesmo problema.

Outra roupa.


🏥 Medicina novamente ensina informática

Alarm Fatigue também é estudada fortemente em ambientes de saúde.

Monitores podem produzir muitos alarmes.

Profissionais expostos repetidamente podem perder sensibilidade.

A lição para TI é clara:

um alarme não é seguro apenas porque existe.

Ele precisa ser percebido, interpretado e gerar ação adequada.


🚨 Designing for Humans

Aqui está o ponto central.

Observabilidade não é apenas engenharia de métricas.

É também engenharia humana.

Precisamos perguntar:

O operador consegue usar isso?

Não:

Conseguimos tecnicamente gerar alerta?

Essa diferença é enorme.


🧠 Alertas também precisam de UX

Interface importa.

Agrupamento.

Cor.

Som.

Prioridade.

Contexto.

Ordenação.

Tudo influencia percepção.

Um painel pode tecnicamente conter toda informação necessária e ainda ser péssimo.


📺 Christmas Tree Dashboard

Existe aquele dashboard maravilhoso:

verde;

amarelo;

vermelho;

azul;

roxo;

piscando;

vinte gráficos.

Parece árvore de Natal.

Impressiona em apresentação.

Durante incidente:

talvez inútil.

Observabilidade boa não é a que possui mais gráficos.

É a que reduz tempo para compreender situação.


🧯 Menos pode ser mais seguro

Isso parece contraintuitivo.

Remover alertas pode aumentar segurança.

Porque aumenta signal-to-noise ratio.

Você não quer silêncio.

Quer sinal claro.


📡 Signal-to-Noise Ratio

Pense:

SINAL ÚTIL
-----------
RUÍDO

Quanto maior:

melhor.

Se dobramos quantidade de alertas sem aumentar informação útil:

ratio piora.


🧠 O alerta perfeito não existe

Alertas precisam evoluir.

Incidente novo ensina:

faltou alerta.

Criamos.

Depois observamos:

dispara demais.

Ajustamos.

Esse é loop de melhoria:

DETECTAR
↓
USAR
↓
MEDIR
↓
AJUSTAR
↓
VALIDAR

Observabilidade é produto vivo.


🧬 Regeneração organizacional

Como regenerar depois de encontrar Alarm Fatigue?

Primeiro:

pare de culpar exclusivamente o operador.

Depois:

meça ruído.

Remova falsos positivos.

Agrupe eventos.

Ajuste thresholds.

Melhore mensagens.

Defina owner.

Crie runbooks.

Revise severidade.

Treine resposta.

E acompanhe:

qual alerta realmente produz ação?


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Alarm Fatigue acontece quando alertas demais reduzem nossa sensibilidade aos alertas importantes.

Um alerta ignorado repetidamente está ensinando comportamento.

False positive consome confiança.

Se tudo é crítico, nada é crítico.

Monitoramento sem ação clara é decoração.

Alertas precisam de ownership.

ACK não significa resolução.

Contexto é melhor que threshold cego.

Agrupar causas reduz tempestade de eventos.

Signal-to-noise ratio importa tanto quanto cobertura.

E principalmente:

Um sistema que grita o tempo inteiro não é necessariamente mais seguro. Talvez apenas esteja ensinando todos a não ouvir.


🕰️ De volta às 14:29

A TARDIS desaparece.

Nosso programador continua olhando para o painel.

Ele resolve pesquisar alertas das últimas 24 horas.

Resultado:

TOTAL ALERTS: 4.812
ACTIONABLE: 37

Ele arregala os olhos.

— Quatro mil?

O operador responde:

— Dia tranquilo.

O jovem começa a separar.

Descobre que três tipos de warning representam 71% de todas as mensagens.

Um deles vem de uma configuração antiga.

Outro dispara em comportamento normal.

O terceiro possui threshold inadequado.

A equipe corrige.

Na semana seguinte:

TOTAL ALERTS: 684
ACTIONABLE: 41

Menos alertas.

Mais ações úteis.

Curioso.

Então aparece:

CRITICAL:
PAYMENT QUEUE GROWTH ABNORMAL

O operador olha imediatamente.

— Esse é novo.

Abre.

Consumer degradado.

Equipe age.

Fila estabilizada.

Nenhum incidente.

Nosso programador sorri.

O operador pega o café.

— Gostei desse alerta.

Essa frase parece banal.

Mas é enorme.

Porque significa:

o alerta recuperou credibilidade.


🥚 Easter Egg final

Mais tarde, aparece um estranho membro:

BELLACOSA.ALERTS(SILENCE)

Dentro:

       IF ALERT-COUNT > HUMAN-CAPACITY
           PERFORM REDUCE-NOISE
       END-IF.

       IF EVERYTHING = 'CRITICAL'
           MOVE 'NOTHING' TO CRITICAL-MEANING
       END-IF.

Abaixo:

* SIGNALS SHOULD INFORM.
* NOT PUNISH.

Outro comentário:

* DON'T BLINK.
* BUT ALSO DON'T BEEP 4,000 TIMES.

Nosso programador ri.

Então encontra a última linha:

* BAD WOLF ACKNOWLEDGED THIS ALERT.

Status:

ACKNOWLEDGED: YES
RESOLVED: NO

Ele imediatamente reabre.

Aprendeu rápido.

O telefone toca.

Novo warning.

Ele não pergunta:

“Posso ignorar?”

Pergunta:

“Esse alerta exige alguma ação?”

Se sim:

age.

Se não:

abre uma tarefa para corrigir o alerta.

Porque finalmente entendeu que manter monitoramento saudável também é trabalho de produção.

E talvez esse seja o grande segredo:

não basta construir sensores.

Precisamos cuidar da capacidade humana de acreditar neles.

VWORP.

VWORP.

VWORP.

Ao longe, a TARDIS desaparece.

No quadro da operação fica uma frase:

Sinais fracos precisam ser audíveis antes de virarem incidentes fortes.

☕🌀

Next stop: Automation Bias — quando a máquina diz “está tudo certo” e nós paramos de acreditar nos próprios olhos.

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