Artigos

Error budgets e alertas por burn rate: acionar pelos motivos certos

Como transformar um SLO em alertas que disparam rápido em quedas reais, ficam em silêncio diante de ruído e param de acionar quando o problema é resolvido.

Os exemplos são genéricos e ilustrativos. Não vêm do ambiente de nenhum cliente: ajuste limites e configurações ao seu próprio sistema.

Comece pelo que o usuário vive

A maior parte dos alertas ruidosos vem de alertar sobre causas — CPU, memória, um pod reiniciado — em vez de sobre o que o usuário sente. Um indicador de nível de serviço (SLI) mede isso diretamente: a fração de requisições válidas que foram boas. Boa pode significar uma resposta sem erro de servidor, uma resposta mais rápida que um limite, ou as duas coisas.

Um objetivo de nível de serviço (SLO) define uma meta para essa fração em uma janela — por exemplo, 99,9% das requisições bem-sucedidas em 30 dias. A diferença até 100% é o error budget: aqui, 0,1% das requisições, ou cerca de 43 minutos de indisponibilidade total no mês.

Por que alertas de limite fixo falham

Um alerta como “taxa de erro acima de 1% por 5 minutos” é sensível demais e lento demais ao mesmo tempo. Ele aciona por um pico curto que consumiu uma fração mínima do budget e nunca dispara para uma taxa de erro de 0,5% que, silenciosamente, queima o budget inteiro em uma semana.

O burn rate resolve isso. É a velocidade com que o budget é consumido em relação ao SLO: um burn rate de 1 gasta exatamente o budget ao longo da janela; um burn rate de 14,4 gasta um budget de 30 dias em pouco mais de dois dias.

Alertas multijanela e com múltiplos burn rates

A abordagem descrita no SRE Workbook do Google combina cada limite de burn rate com uma janela longa, que prova que o problema é relevante, e uma janela curta, que prova que ele ainda está acontecendo. Para um SLO de 99,9% em 30 dias, um ponto de partida comum é:

Acionar: burn rate acima de 14,4 em 1 hora e em 5 minutos — 2% do budget gastos em uma hora.
Acionar: burn rate acima de 6 em 6 horas e em 30 minutos — 5% do budget gastos.
Abrir ticket: burn rate acima de 1 em 3 dias e em 6 horas — 10% do budget gastos.

# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
    / sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
    / sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)

A janela curta importa tanto quanto a longa: assim que a correção entra, a fração de 5 minutos cai e o alerta se resolve, em vez de continuar disparando pelo resto da hora.

Detalhes que decidem se funciona

Recording rules: pré-calcule a taxa de erro de cada janela, para que as expressões de alerta continuem baratas e legíveis.
Pouco tráfego: com poucas requisições por minuto, uma única falha é uma fração grande. Exija um número mínimo de requisições ou meça com sondas sintéticas.
SLOs de latência: conte como eventos ruins as requisições mais lentas que o limite, com buckets de histograma que incluam o valor do limite.
Exclusões: decida de antemão se erros do cliente e health checks contam, e registre isso junto ao SLO.

Para que serve o budget

O budget é uma ferramenta de decisão, não só um pager. Enquanto está saudável, a equipe pode publicar mais rápido e assumir mudanças mais arriscadas. Quando se esgota, o trabalho de confiabilidade passa à frente das funcionalidades até a tendência se recuperar. Combine essa política com os responsáveis pelo produto antes da primeira violação, não durante ela.