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. A falha que sai cara não é a 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-te 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 essa única regra sem dó e a maior parte do ruído desaparece.

O 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 esse pressuposto como protegerias 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 limiar, decide 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 para onde vai cada sinal antes de mexer num limiar. Só o page acorda alguém; o pico de um segundo que recuperou pertence a um dashboard.

Alerta nos sintomas, não nas causas

Os 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, actualidade dos dados)

Alerta no sintoma e podes apagar a maioria dos alertas de causa: vais descobrir que o disco encheu porque os pedidos começaram a falhar - e descobre-lo 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 no que o utilizador sente; deixa as causas nos dashboards e nos runbooks, onde ajudam a diagnosticar em vez de competir pela atenção.

Porque é que um único limiar nunca chega

O alerta de SLO ingénuo é 'avisa-me quando estivermos a queimar orçamento'. Escolhes uma só janela e ficas 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 limiar 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 tens um incidente.

O 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 torravas o orçamento inteiro de 30 dias em cerca de dois dias, e já queimaste 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. Decides quanto orçamento estás 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 limiares de alerta.

Multi-janela, multi-burn-rate

A solução para a armadilha do limiar ú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 limiar.

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 o descreverias 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. Corres 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-te um sinal limpo; o processo mantém-no limpo. Sujeita cada page a quatro testes:

Accionável - se o on-call não puder fazer nada de imediato, é 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; junta os duplicados.

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

Anti-padrões para apagar esta semana

Limiares fixos em métricas irregulares ('CPU > 80%') - disparam com carga saudável.
Pages de disco ou memória por máquina - alerta 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á alertas - levas 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 andar às cegas

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