A leitura lenta isolada que interrompeu a equipe inteira

Ler o original em inglês

alertingmonitoringfalse-positiveincident-response

Imagem de capa: A leitura lenta isolada que interrompeu a equipe inteira

Um sistema de monitoramento acionou a equipe inteira porque uma única verificação voltou um pouco mais lenta do que o limite (Ler em inglês) permitia. A verificação seguinte estava totalmente normal. Nada tinha caído de verdade. O alerta transformou um momento levemente lento em uma interrupção completa.

O que resolveu foi perceber que um possível problema e um problema confirmado são tipos diferentes de evidência. A gente vinha respondendo aos dois do mesmo jeito.

O alerta estava correto, e mesmo assim era ruído

O sistema tinha uma linha para “lento”, e uma leitura passou dela, então ele relatou um problema e acionou a equipe. Do ponto de vista do sistema, não havia nada de errado. Ele fez exatamente o que mandaram.

Para as pessoas que foram interrompidas, era puro ruído. Nada estava quebrado. Havia uma medição fora da linha, seguida logo depois por uma normal.

Uma resposta lenta pode acontecer por motivos inofensivos, como um atraso breve ou um gargalo momentâneo em algum ponto anterior, sem que aquilo que está sendo monitorado fique indisponível. Um sistema que aciona a equipe a cada leitura no limite ensina as pessoas a deixarem de levar seus avisos a sério. Quando isso acontece, ele deixou de cumprir a função para a qual foi criado.

Dois tipos de más notícias, duas reações diferentes

Tornamos a resposta desigual de propósito. Uma falha total, algo que não responde de jeito nenhum, ainda dispara um alerta imediato. Se algo parou de funcionar, essa é a situação que exige a resposta mais rápida possível. Esperar uma segunda verificação só para ter mais certeza acrescentaria atraso justamente ao tipo de falha que menos pode se dar a esse luxo.

Um sinal de alerta leve, como uma resposta lenta mas ainda funcionando, é tratado de outra forma. Ele inicia uma sequência em vez de acionar a equipe na hora. Só quando acontece duas vezes seguidas ele vira um alerta de verdade, e uma leitura normal no meio zera a sequência. Com a nova regra, o momento lento isolado que causou a interrupção original teria sido apenas uma medição que veio e passou.

A resposta mais simples seria deixar o limite de “lento” mais tolerante e não mexer em mais nada. Isso ajuda um pouco. Mas uma leitura azarada acima de qualquer limite, por mais generoso que seja, ainda pode causar a mesma interrupção inútil. Isso só muda a linha de lugar sem resolver o problema.

Aplicar a mesma regra de duas ocorrências a todo tipo de sinal ruim, inclusive as falhas totais, seria coerente, mas errado. Algo que está de fato fora do ar não deveria ter que esperar por uma segunda verificação só porque outro tipo de alerta andou incomodando as pessoas.

Uma regra geral que silencia ou atrasa todos os alertas por um tempo depois que um deles dispara também teria deixado tudo mais quieto. O custo é que ela poderia esconder um problema real e separado que surgisse logo depois de outro que já tinha se resolvido sozinho.

O que conferir na sua própria configuração

Veja se o seu monitoramento aciona uma pessoa por causa de uma única leitura no limite. Uma falha total ainda deve alertar na hora. Um sinal leve, como uma resposta lenta isolada, deve precisar de duas seguidas antes de interromper alguém. E uma leitura normal no meio deve zerar a contagem.

Receba a próxima história de IA no dia a dia

Histórias em linguagem simples sobre usar IA para facilitar o trabalho do dia a dia. Um e-mail curto quando sair uma nova, sem jargão.