Alerting

Limiares, SLOs, SLIs, on-call, alert fatigue, escalonamento e como projetar um sistema de alertas eficaz.

Por que o alerting importa?

Ter métricas e dashboards é inútil se ninguém os observa quando algo falha. O alerting é o mecanismo que transforma dados de observabilidade em ações: notifica as pessoas certas quando algo requer atenção, antes que os usuários sejam afetados.

Mas um sistema de alertas mal projetado pode ser pior do que não ter alertas. Se a equipe recebe 50 alertas diários que não exigem ação, mais cedo ou mais tarde vai ignorar todos eles — incluindo os críticos.

SLIs, SLOs e SLAs

SLI (Service Level Indicator)

Um SLI é uma métrica quantitativa que mede um aspecto do serviço a partir da perspectiva do usuário:

Disponibilidade: Porcentagem de requests bem-sucedidas.
Latência: Porcentagem de requests concluídas em menos de X ms.
Throughput: Requests processadas por segundo.
Corretude: Porcentagem de respostas com dados corretos.

SLO (Service Level Objective)

Um SLO é um objetivo interno sobre um SLI. Define qual nível de serviço a equipe se compromete a manter:

“99,9% das requests devem ser concluídas em menos de 500ms.”
“A disponibilidade mensal deve ser de pelo menos 99,95%.”
“99% dos pagamentos devem ser processados em menos de 3 segundos.”

SLA (Service Level Agreement)

Um SLA é um contrato formal com consequências (geralmente financeiras) caso não seja cumprido. Os SLAs costumam ser menos rigorosos que os SLOs internos, para haver uma margem de segurança.

Error Budget

O error budget é a diferença entre 100% e o SLO. Se o seu SLO de disponibilidade é 99,9%, o seu error budget mensal é 0,1% — aproximadamente 43 minutos de downtime permitido.

O error budget permite tomar decisões embasadas:

Se sobra bastante budget: você pode priorizar features e velocidade de desenvolvimento.
Se o budget está se esgotando: priorize estabilidade e reduza riscos.

Design de alertas

Alertas baseados em sintomas vs causas

Alertas por sintomas (recomendado): “A taxa de erros 5xx ultrapassa 1%”. Detectam o impacto ao usuário.
Alertas por causas: “O uso de CPU ultrapassa 90%”. Podem gerar falsos positivos — CPU alta nem sempre significa problemas.

Priorize alertas por sintomas. Use alertas por causas apenas como complemento para diagnóstico.

Limiares estáticos vs dinâmicos

Limiares estáticos: Valores fixos definidos manualmente.

Vantagem: Simples de entender e configurar.
Desvantagem: Não se adaptam a padrões de tráfego variáveis.

Limiares dinâmicos: Calculados automaticamente com base em padrões históricos.

Vantagem: Adaptam-se a variações normais (mais tráfego em horário comercial).
Desvantagem: Mais complexos de implementar e podem gerar falsos positivos durante mudanças legítimas.

Severidades

Defina níveis claros de severidade com ações associadas:

Severidade	Significado	Ação	Exemplo
Critical	Impacto direto ao usuário	Notificação imediata, on-call	Serviço fora do ar, erros > 5%
Warning	Degradação potencial	Notificação em horário comercial	Latência elevada, disco em 80%
Info	Situação a monitorar	Registro no canal da equipe	Deploy concluído, scaling event

Janelas de avaliação

Não alerte sobre picos instantâneos. Use janelas de tempo para evitar falsos positivos:

for: 5m — A condição deve se manter por 5 minutos antes de disparar o alerta.
Janelas mais longas para métricas ruidosas, mais curtas para métricas críticas.

Alert fatigue

O que é?

O alert fatigue ocorre quando a equipe recebe tantos alertas que deixa de prestar atenção neles. É um dos problemas mais comuns e perigosos em operações.

Sinais de alert fatigue

A equipe silencia alertas sem investigá-los.
Os alertas se acumulam sem serem atendidos.
Incidentes reais são detectados por reclamações de usuários, e não por alertas.
A equipe on-call está esgotada e desmotivada.

Como combatê-la

Cada alerta deve ser acionável: Se não exige ação humana, não é um alerta — é um log ou uma métrica.
Revisão periódica: Revise os alertas mensalmente. Elimine os que não geraram ação útil.
Agrupamento: Agrupe alertas relacionados para evitar cascatas de notificações.
Deduplicação: Se o mesmo alerta dispara 10 vezes em 5 minutos, envie uma única notificação.
Runbooks: Cada alerta deve ter um runbook associado que explique o que fazer.

On-call

Rotações

Um sistema de on-call eficaz inclui:

Rotações semanais: Distribuir a carga entre toda a equipe.
Escalonamento: Se o on-call primário não responde em X minutos, escalar para o secundário.
Compensação: O on-call deve ser compensado — é trabalho fora do horário.

Escalonamento

Defina uma cadeia de escalonamento clara:

Nível 1: Engenheiro on-call da equipe dona do serviço.
Nível 2: Tech lead ou engenheiro sênior da equipe.
Nível 3: Incident commander / management.

Os tempos de escalonamento dependem da severidade:

Critical: Escalar após 15 minutos sem resposta.
Warning: Escalar após 1 hora sem resposta.

Ferramentas de on-call

PagerDuty: Plataforma líder de gerenciamento de incidentes e on-call.
OpsGenie (Atlassian): Alternativa com boa integração com o Jira.
Grafana OnCall: Solução open-source integrada com o Grafana.

Runbooks

Um runbook é um documento que descreve os passos a seguir quando um alerta específico dispara.

Estrutura de um runbook

Descrição: O que este alerta significa.
Impacto: O que o usuário vivencia.
Diagnóstico: Passos para investigar a causa raiz.
Mitigação: Ações imediatas para restaurar o serviço.
Resolução: Passos para resolver a causa raiz.
Contatos: Para quem escalar caso não seja possível resolver.

Automação de runbooks

Quando um runbook tem passos repetitivos e bem definidos, considere automatizá-los:

Scripts de diagnóstico que coletam informações automaticamente.
Ações de mitigação automáticas (restart de serviço, scaling).
Bots que executam os primeiros passos do runbook e notificam o resultado.

Boas práticas

Comece simples

Não tente alertar sobre tudo desde o primeiro dia. Comece com as métricas RED de cada serviço crítico e expanda gradualmente.

Teste seus alertas

Alertas são código — devem ser testados:

Verifique se disparam quando a condição é atendida.
Verifique se não disparam com variações normais.
Simule falhas periodicamente para validar a cadeia completa.

Post-mortems

Depois de cada incidente significativo, faça um post-mortem:

O alerta disparou a tempo?
O runbook foi útil?
O que pode ser melhorado?

Use os post-mortems para melhorar continuamente o sistema de alertas.

Resumo

Um sistema de alertas eficaz é a ponte entre a observabilidade e a ação. Baseie seus alertas em SLOs, priorize sintomas em vez de causas, combata ativamente o alert fatigue e garanta que cada alerta tenha um runbook associado. O objetivo não é ter mais alertas, e sim ter os alertas certos que permitam à equipe manter o serviço saudável.