 |
| 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:
O que ele detecta?
Quem deve agir?
Qual ação deve acontecer?
Em quanto tempo?
Qual risco reduz?
Quantas vezes dispara?
Quantas vezes é falso?
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.
Sem comentários:
Enviar um comentário