Desenhar alertas que ninguém ignora

Cada alerta que dispara sem precisar de um humano está, em silêncio, a ensinar a equipa a ignorar o próximo. Faz isso durante umas semanas e o alerta que realmente importa acaba num canal que ninguém lê, ou é descartado às 3 da manhã ao lado dos outros dezassete que não importavam. O custo caro não é a falha que escapou — é o engenheiro de on-call que aprendeu, e com razão, que os alertas são ruído de fundo.

Por isso o objectivo aqui não é 'mais monitorização'. É o contrário: um punhado de alertas em que cada um significa que alguém tem mesmo de agir agora, ligados ao ritmo a que se está a consumir o orçamento de erro, com tudo o resto encaminhado para onde não acorda ninguém. Vou deduzir as contas, dar regras de Prometheus prontas a colar, e falar do processo que mantém isto honesto.

Se um humano não tem de tomar uma decisão inteligente, não devia receber um page. Aplica-se essa única regra sem dó e a maior parte do ruído desaparece.

Ruído é, por si só, um problema de fiabilidade

Trata o on-call como qualquer outro sistema com um SLO. Um alvo razoável é não mais do que um ou dois pages accionáveis por turno, e praticamente zero pages falsos. No momento em que se passa disso, o tempo até alguém reagir dispara, as pessoas silenciam os canais e a confiança em todo o sistema de alertas desmorona — o que é muito mais perigoso do que qualquer painel a ficar vermelho.

Cada page falso gasta uma coisa difícil de recuperar: o pressuposto de que um page é a sério. Protege-se esse pressuposto como se protegem os dados de produção.

A maior parte da dor do on-call é um problema de ruído e encaminhamento: dezenas de alertas de causa reduzem-se a um punhado de pages que precisam mesmo de um humano.

Três destinos, só um acorda alguém

Antes de afinar um único limite, decide-se para onde vão os sinais. A maioria das confusões de alertas é, no fundo, uma confusão de encaminhamento — estava tudo apontado ao pager.

Page — alguém tem de agir em minutos. Reservado para dano visível ao utilizador, sustentado e a queimar orçamento depressa.
Ticket — alguém tem de agir, mas pode esperar pelo horário de trabalho: fugas lentas de orçamento, tendências de capacidade, um certificado que expira para a semana.
Dashboard / registo — apenas consciência. Ninguém é acordado; serve a vista de on-call e a revisão semanal.

O pico de erro de um segundo, que recuperou sozinho, pertence ao terceiro balde: visível num dashboard, registado contra o orçamento, revisto mais tarde. É real, custou alguma coisa, e não justifica de todo um telefonema.

Decide-se para onde vai cada sinal antes de mexer num limite. Só o page acorda alguém; o pico de um segundo que recuperou pertence a um dashboard.

Alerta nos sintomas, não nas causas

Alertas baseados em causas — 'CPU > 80%', 'disco a 90%', 'pod reiniciou' — disparam a toda a hora e raramente coincidem com um utilizador a sofrer. Os sistemas modernos andam quentes e reiniciam coisas de propósito; isso é saudável, não é um incidente. Os alertas baseados em sintomas avisam sobre o que o utilizador sente de facto:

Os pedidos estão a falhar? (rácio de erros)
Estão lentos ao ponto de o utilizador reparar? (SLI de latência)
O trabalho está a passar? (débito, idade da fila, frescura dos dados)

Alerta-se no sintoma e pode apagar-se a maioria dos alertas de causa: vais descobrir que o disco encheu porque os pedidos começaram a falhar — e descobres com um page em vez de nove. As causas pertencem aos dashboards e aos runbooks, onde ajudam a diagnosticar, não ao pager, onde só competem pela atenção.

Alerta-se no que o utilizador sente; deixam-se as causas nos dashboards e nos runbooks, onde ajudam a diagnosticar em vez de competir pela atenção.

Porque é que um único limite nunca chega

O alerta de SLO ingénuo é 'avisa-me quando estivermos a queimar orçamento'. Escolhe-se uma só janela e fica-se preso a um mau compromisso. Curta, fica nervosa — um soluço de 30 segundos acorda alguém por um problema que já se resolveu sozinho. Longa, fica lenta — podes estar 20 minutos em plena avaria antes de algo disparar.

É exactamente o problema do pico de um segundo. Um pico breve consome uma fatia do orçamento (verdade, e que vale a pena registar), mas nunca devia dar page — e um único limite não distingue 'breve e recuperado' de 'sustentado e a piorar'. São precisas duas escalas de tempo ao mesmo tempo.

Burn rate, a partir do princípio

Começa-se pelo orçamento. Um SLO de disponibilidade de 99,9% ao longo de 30 dias permite que 0,1% dos pedidos falhem — é esse o orçamento de erro, cerca de 43 minutos de avaria total equivalente no mês. Gasta-se devagar e está tudo bem; gasta-se numa tarde e tem-se um incidente.

Burn rate é a rapidez com que se gasta face a 'exactamente dentro do orçamento'. Um burn rate de 1 gasta precisamente 100% do orçamento ao longo da janela do SLO — sustentável. Um burn rate de 14,4 gasta 14,4× depressa demais: a esse ritmo torrava-se o orçamento inteiro de 30 dias em cerca de dois dias, e já se queimou 2% na última hora.

burn_rate = (erros / total) / (1 - SLO)

# SLO de 99.9%  ->  1 - SLO = 0.001
# se 1.44% dos pedidos estao a falhar agora:
#   burn_rate = 0.0144 / 0.001 = 14.4
#
# orcamento gasto numa janela = burn_rate * (janela / periodo_SLO)
#   14.4 * (1h  / 720h) =  2%   do orcamento de 30 dias, numa hora
#    6   * (6h  / 720h) =  5%   em seis horas
#    1   * (72h / 720h) = 10%   em tres dias

Estas três linhas não são arbitrárias — são os escalões de alerta. Decide-se quanto orçamento se está disposto a perder antes de envolver um humano, e o burn rate e a janela saem directamente das contas.

Cada escalão de burn rate é só uma inclinação. 14.4× esvazia um orçamento de 30 dias em cerca de dois dias, 6× em cinco, 1× chega exactamente ao dia 30 — e é daí que vêm os limites de alerta.

Multi-janela, multi-burn-rate

A solução para a armadilha do limite único é vigiar uma janela longa e uma janela curta em conjunto, com mais do que um burn rate. A janela longa confirma que o problema é real e sustentado; a janela curta — cerca de um doze avos da longa — torna o alerta rápido a disparar e, sobretudo, rápido a desligar quando se recupera. O alerta só dispara quando ambas as janelas passam o limite.

Um pico de um segundo activa a janela curta mas nunca a longa, por isso nunca dá page — uma queima sustentada activa as duas e dá. A janela curta também faz o alerta desligar minutos depois de recuperar, e é isso que acaba com o flapping.

A severidade vem do burn rate, não de empilhar janelas do mesmo tamanho. Queima rápida e acentuada = acordar alguém agora. Queima lenta e suave = um ticket para amanhã:

SEVERIDADE  BURN    JANELA-L  JANELA-C   ORCAMENTO GASTO   DESTINO
-----------------------------------------------------------------
critico     14.4x   1h        5m         2%  em 1 hora     page
alto         6x     6h        30m        5%  em 6 horas    page
aviso        1x     3d        6h         10% em 3 dias     ticket

Lê-se como se descreveria em voz alta: uma queima acentuada num horizonte curto é um page crítico; uma queima suave que só aparece ao fim de dias é um ticket de aviso para a fuga lenta que o escalão rápido deixaria passar. Correm-se os três ao mesmo tempo — não se atrapalham, cobrem formas de falha diferentes.

A janela curta é a parte que mata o ruído. Como o alerta também precisa da janela curta acesa, deixa de disparar minutos depois de se recuperar, em vez de se arrastar pelo tamanho da janela longa. É isso que acaba com o flapping — e com o page às 3 da manhã por algo que se resolveu há 90 segundos.

As queries

Calcula o SLI uma só vez

Define o sintoma uma só vez como um rácio de erros. No Prometheus pré-calcula-lo por janela com recording rules — barato, legível e reutilizado por todos os dashboards. No Datadog defines o SLI uma vez num SLO baseado em métricas e ele calcula as janelas por ti.

groups:
- name: payments-slo
  rules:
  # SLI do sintoma: fracção de pedidos maus (5xx ou demasiado lentos)
  - record: job:sli_err:ratio5m
    expr: |
      sum(rate(http_requests_total{job="payments",code=~"5.."}[5m]))
      / sum(rate(http_requests_total{job="payments"}[5m]))
  - record: job:sli_err:ratio1h
    expr: |
      sum(rate(http_requests_total{job="payments",code=~"5.."}[1h]))
      / sum(rate(http_requests_total{job="payments"}[1h]))
  # ...repete para as janelas de 30m, 6h e 3d em que alertas

# O Datadog calcula as janelas por ti: define o SLI uma vez como um
# SLO baseado em métricas (eventos bons / eventos totais). O rácio de erro cru:
100 * (
  sum:trace.http.request.errors{service:payments}.as_count()
  / sum:trace.http.request.hits{service:payments}.as_count()
)

Alert rules — multi-janela, multi-burn-rate

O SLO é 99,9%, por isso o denominador do orçamento é 0,001. Cada escalão precisa que tanto a sua janela longa como a curta excedam o burn rate antes de disparar — escrito de forma explícita no Prometheus, e um parâmetro nativo do monitor de burn rate do Datadog.

- alert: PaymentsBudgetFastBurn
  expr: |
    job:sli_err:ratio1h / 0.001 > 14.4
    and
    job:sli_err:ratio5m / 0.001 > 14.4
  labels: { severity: page }
  annotations:
    summary: "Payments a queimar orçamento a 14,4x (2%/h)"
    runbook: "https://runbooks/payments/error-budget"

- alert: PaymentsBudgetSlowBurn
  expr: |
    job:sli_err:ratio3d / 0.001 > 1
    and
    job:sli_err:ratio6h / 0.001 > 1
  labels: { severity: ticket }
  annotations:
    summary: "Payments com fuga lenta de orçamento (10%/3d)"
    runbook: "https://runbooks/payments/error-budget"

# O Datadog faz multi-janela de raiz — um monitor de burn rate sobre o SLO,
# com as janelas longa e curta como parâmetros:

# queima rápida -> page  (2% do orçamento de 30 dias em 1h)
burn_rate("payments-availability").over("30d").long_window("1h").short_window("5m") > 14.4

# queima lenta -> ticket  (10% em 3 dias)
burn_rate("payments-availability").over("30d").long_window("3d").short_window("6h") > 1

Mete o escalão de 6× / 6h / 30m pelo meio e cobres avarias rápidas, degradações médias e fugas lentas com três alertas por serviço — não trinta.

Cada page tem de merecer o seu lugar

As contas dão um sinal limpo; o processo mantém-no limpo. Sujeita-se cada page a quatro testes:

Accionável — se o on-call não puder fazer nada já, é ticket ou apaga-se.
Tem runbook — o page liga a 'o que se passa e por onde começar', não a uma busca na wiki às 3 da manhã.
Tem dono — chega a exactamente uma equipa, e essa equipa pode mudá-lo.
Traz novidade — diz algo que o page anterior não disse; juntam-se os duplicados.

Depois tornam-se baratos e regulares dois hábitos. Uma revisão semanal do orçamento de erro: quanto se gastou, em quê, vamos a tempo. E uma revisão de alertas: percorre-se cada page que disparou e, para cada um, mantém-se, corrige-se ou apaga-se. Apagar alertas é o trabalho de fiabilidade mais subestimado que há.

Anti-padrões para apagar esta semana

Limites fixos em métricas irregulares ('CPU > 80%') — disparam com carga saudável.
Pages de disco ou memória por máquina — alerta-se no sintoma visível ao utilizador; o resto planeia-se como tickets.
Pages 'informativos' — uma contradição em si; vão para um dashboard.
Alertar numa causa cujo sintoma já se alerta — levam-se dois pages pelo mesmo incidente.
Qualquer alerta sem runbook e sem dono — ninguém lhe pode pegar, logo é puro ruído.

Como lá chegar sem voar às cegas

Define-se um SLI e um SLO por percurso do utilizador (checkout, login, pagamentos) — sintomas, não máquinas.
Acrescentam-se as recording rules para as janelas em que se vai alertar.
Metem-se os três escalões de burn rate só em modo de ticket primeiro — ainda sem pages.
Observam-se duas ou três semanas; compara-se o que teria dado page com o que foi mesmo um incidente.
Promove-se o escalão rápido a page; mantém-se o lento como tickets.
Apagam-se os pages de causa que isto torna redundantes — um de cada vez, de olho no orçamento.
Põe-se de pé a revisão semanal do orçamento e a revisão de alertas, e continua-se a podar.

O objectivo nunca foi 'menos alertas' como métrica de vaidade. É que, quando o telefone toca, seja a sério, seja accionável e haja um runbook à espera — para as pessoas confiarem, atenderem, e o sistema continuar fiável porque os humanos que o defendem não estão exaustos.