SLIs, SLOs e Error Budgets

"O BoxOffice é confiável o bastante?" Ninguém responde a isso sem números. O gerente de produto quer lançar um novo mapa de lugares na semana anterior a uma abertura de vendas no estádio; a engenheira de plantão diz que o caminho de compra teve um mês ruim e quer congelar os deploys. Sem uma definição compartilhada de "bom o bastante", essa discussão é opinião contra opinião. A prática de Site Reliability Engineering (SRE) do Google introduziu um vocabulário que transforma a discussão em aritmética¹, e hoje ele é padrão no mercado:

flowchart LR
    tel["Telemetria<br/>(métricas, logs, traces)"] -->|"agregada em"| sli["SLI<br/>eventos bons / válidos"]
    sli -->|"comparado com"| slo["SLO<br/>meta interna"]
    slo -->|"a diferença é"| budget["Error budget<br/>licença para correr risco"]
    slo -->|"versão mais folgada"| sla["SLA<br/>contrato externo"]
    budget -->|"orienta"| decisions["Lançar ou congelar?<br/>Acionar ou abrir chamado?"]

Comece pelas jornadas do usuário

Um SLO só é útil se mede o que importa para os usuários. Comece listando as jornadas críticas de usuário (CUJs, critical user journeys) do BoxOffice — as poucas interações que precisam funcionar — e depois decida como medir cada uma.

Nem toda jornada precisa da mesma meta. A navegação tolera uma página lenta de vez em quando; um pagamento que falha perde uma venda e a confiança de um fã.

SLI — medindo o que os usuários sentem

Um SLI é melhor escrito como uma razão de eventos, para ficar sempre entre 0% e 100%²:

As duas palavras importam. Bom define sucesso do ponto de vista do usuário — "o status não é 5xx e a latência é menor que 500 ms". Válido exclui o que não deve contar — respostas 4xx causadas pelo cliente, requisições de health check, testes de carga sintéticos.

Onde medir

Uma escolha comum é calcular os SLIs no gateway (perto do usuário, mas sob seu controle) e complementá-los com probes sintéticos da jornada de compra. Com métricas OpenTelemetry exportadas para o Prometheus (veja Sinais), o SLI de disponibilidade da rota de reserva em 5 minutos é:

sum(rate(http_server_request_duration_seconds_count{service_name="gateway", http_route="/holds", http_response_status_code!~"5.."}[5m]))
/
sum(rate(http_server_request_duration_seconds_count{service_name="gateway", http_route="/holds"}[5m]))

SLO — a meta

Um SLO é uma meta para um SLI em uma janela:

SLI ≥ meta em uma janela

Use uma janela móvel (os últimos 28 dias, avançando a cada minuto) em vez de um mês de calendário: 28 dias sempre contêm quatro de cada dia da semana, e o orçamento não "zera" magicamente no dia 1º.

Como escolher o número:

• Meça primeiro. Olhe o SLI dos últimos 30–90 dias e defina o SLO um pouco abaixo do que você já alcança. Uma meta que você já perde toda semana é ruído.
• Respeite a matemática das dependências. O order não pode prometer mais que o produto do que ele chama de forma síncrona (Confiabilidade — disponibilidade composta). Se o provedor de pagamento oferece 99,9%, um SLO de compra de 99,99% é ficção.
• Pergunte o que os usuários percebem. Ir de 99,9% para 99,99% custa muito (veja a tabela de noves); se os fãs não perceberiam, o dinheiro rende mais em funcionalidades.
• Nunca 100%. Não deixa espaço para deploys, manutenção ou o inevitável, e todas as suas dependências estão abaixo disso de qualquer forma.

Error budget

O error budget é a quantidade de não confiabilidade que o SLO permite — a licença do time para correr riscos:

Burn rate

O burn rate diz com que velocidade o orçamento está sendo gasto em relação à janela²:

Com um SLO de 99,9%, uma taxa de erros de 0,1% é um burn rate de 1 — o orçamento dura exatamente os 28 dias. Uma taxa de erros de 1,44% é um burn rate de 14,4, que esgota o orçamento em \(28 / 14.4 \approx 1.9\) dia.

A simulação abaixo acompanha o orçamento do caminho de compra em uma janela de 28 dias com números ilustrativos: um fundo tranquilo de 0,01% de erros, um deploy ruim no dia 9 (5% de erros por 3 horas) e uma degradação lenta a partir do dia 16 (0,2% de erros — um burn rate de apenas 2).

Os dois incidentes ensinam lições diferentes:

• O deploy ruim tem um burn rate enorme (50×) por pouco tempo. Ele precisa acionar alguém em minutos, e o orçamento mostra quanto custou: cerca de um quinto do mês.
• A degradação lenta nunca parece dramática — 0,2% de erros não assustaria ninguém num dashboard — mas a 2× ela esgota o orçamento por volta do dia 26. Só um alerta de queima lenta, em uma janela longa, a pega.

Alertando pelo burn rate

Alerte pelo orçamento, não por taxas de erro brutas ou CPU. O SRE Workbook recomenda alertas multijanela e multi-burn-rate²: uma janela longa para medir a relevância e uma janela curta para encerrar o alerta logo que o problema for corrigido.

# Prometheus alerting rule: purchase path, SLO 99.9% (budget = 0.001)
- alert: PurchaseErrorBudgetFastBurn
  expr: |
    (
      sum(rate(http_server_request_duration_seconds_count{service_name="gateway", http_route=~"/holds|/orders", http_response_status_code=~"5.."}[1h]))
      / sum(rate(http_server_request_duration_seconds_count{service_name="gateway", http_route=~"/holds|/orders"}[1h]))
    ) > (14.4 * 0.001)
    and
    (
      sum(rate(http_server_request_duration_seconds_count{service_name="gateway", http_route=~"/holds|/orders", http_response_status_code=~"5.."}[5m]))
      / sum(rate(http_server_request_duration_seconds_count{service_name="gateway", http_route=~"/holds|/orders"}[5m]))
    ) > (14.4 * 0.001)
  labels:
    severity: page
  annotations:
    summary: "Purchase path burning the 28-day error budget 14.4x faster than allowed"

Os detalhes do projeto de alertas, do roteamento e do plantão estão em Observabilidade — alertas.

- uid: order-availability-fast-burn
  title: "order availability SLO: fast burn"
  condition: C
  data:
    - refId: A          # burn rate over the long window (1 h)
      relativeTimeRange: { from: 3600, to: 0 }
      datasourceUid: prometheus
      model:
        refId: A
        instant: true
        expr: |
          (
            sum(rate(http_server_request_duration_seconds_count{service_name="order", http_route!~"/actuator.*", http_response_status_code=~"5.."}[1h]))
            / sum(rate(http_server_request_duration_seconds_count{service_name="order", http_route!~"/actuator.*"}[1h]))
          ) / 0.005
    - refId: C
      datasourceUid: __expr__
      model:
        refId: C
        type: math
        expression: "$A > 14.4 && $B > 14.4"
  for: 1m
  noDataState: OK
  execErrState: Error
  labels:
    severity: page
    slo: order-availability
  annotations:
    summary: "order is burning its 28-day error budget 14.4x too fast"
    description: 'Burn rate {{ printf "%.1f" $values.A.Value }} (1 h) and {{ printf "%.1f" $values.B.Value }} (5 min): at this pace about 2% of the 28-day budget is gone in one hour.'

A política de error budget

Um error budget é só um número num dashboard, a menos que produto e engenharia combinem de antemão o que acontece à medida que ele é gasto. Esse acordo é a política de error budget:

SLA — o contrato

Um SLA é um acordo formal com clientes que define o serviço esperado e as compensações (em geral créditos) se ele não for cumprido. É um documento jurídico: descumpri-lo custa dinheiro.

Um SLA tipicamente define: serviços e regiões cobertos; o compromisso (por exemplo, 99,9% de uptime mensal); como ele é medido; exclusões (manutenção programada, problemas causados pelo cliente, força maior); e a tabela de créditos.

Os compromissos abaixo vêm das páginas públicas de SLA dos provedores³; as condições mudam com o tempo, então sempre leia a página atual.

Duas lições se escondem nessa tabela. Primeiro, os números mais altos só valem se você implantar com redundância — a redundância é o preço do nove extra. Segundo, a compensação é um crédito na sua fatura, não uma indenização pelos ingressos que você deixou de vender: um SLA transfere um pouco de risco financeiro; ele não torna seu sistema disponível.

Mantenha o SLO mais rígido que o SLA (por exemplo, SLO de 99,95%, SLA de 99,9%): a diferença é uma margem de segurança que avisa muito antes de o contrato estar em risco.

Como se conecta

flowchart LR
    CUJ["jornadas críticas do usuário"] --> SLI["SLI = eventos bons / válidos"]
    TEL["telemetria no gateway<br/>→ Observabilidade"] --> SLI
    SLI --> SLO["SLO em uma janela<br/>móvel de 28 dias"]
    DEP["matemática das dependências<br/>→ disponibilidade composta"] --> SLO
    SLO --> EB["orçamento de erros = 1 − SLO"]
    SLO --> SLA["SLA: um contrato<br/>externo mais frouxo"]
    EB --> BR["alertas de burn rate multijanela<br/>→ Observabilidade — alertas"]
    EB --> POL["política de orçamento:<br/>entregar ou congelar?"]
    POL --> DEL["canário, congelamento de deploys<br/>→ Cloud-native — entrega"]
    POL --> PM["postmortem acima de 20% do orçamento<br/>→ Resposta a incidentes"]

Componentes da paleta: metrics (o SLI é uma razão de contadores de requisições) · alerting (regras de burn rate multijanela) · apigw (onde o BoxOffice mede o SLI da compra) · kafka (o consumer lag, alerta antecipado do SLI de frescor da entrega de ingressos) · payment (seus 99,9% limitam o SLO da compra). Cenários: observability-stack, flash-sale (o SLO por evento de abertura de vendas). Continua em: Observabilidade — alertas, Observabilidade — resposta a incidentes, Estimativas — matemática da disponibilidade, Cloud-native — entrega, Hands-on 8 — SLO e alerta de burn rate.