SLI / SLO / SLA

"A loja é confiável o suficiente?" é uma pergunta que ninguém consegue responder sem números. A gerente de produto quer lançar um novo checkout esta semana; o engenheiro de plantão diz que o serviço de pedidos teve um mês ruim e quer congelar os deploys. Sem uma definição compartilhada de "bom o suficiente", essa discussão é opinião contra opinião. Medir a confiabilidade exige um vocabulário comum que ligue a telemetria bruta às decisões de engenharia e aos compromissos com os clientes. A prática de Site Reliability Engineering do Google introduziu um modelo de três camadas com esse objetivo¹, hoje padrão na indústria.

flowchart LR
    telemetry["Telemetria\n(logs, métricas, traces)"]
    sli["SLI\nMedição bruta"]
    slo["SLO\nMeta interna"]
    sla["SLA\nContrato externo"]
    budget["Error Budget\nAlavanca de engenharia"]

    telemetry e1@-->|agregada em| sli
    sli e2@-->|avaliado contra| slo
    slo e3@-->|embasa| sla
    slo e4@-->|o restante vira| budget

    e1@{ animate: true }
    e2@{ animate: true }
    e3@{ animate: true }
    e4@{ animate: true }

SLI — A medição bruta

Um SLI é uma métrica quantitativa extraída diretamente da instrumentação que reflete a qualidade do sistema percebida pelo usuário. Nem toda métrica é um bom SLI; só aquelas que se correlacionam com o usuário estar ou não obtendo valor do serviço.

A forma mais útil de escrever um SLI é como uma razão entre eventos, de modo que ele fique sempre entre 0% e 100%²:

Por exemplo: "a proporção de requisições GET /products que retornam um status diferente de 5xx em menos de 300 ms". "Válidos" permite excluir eventos que não devem contar, como respostas 4xx causadas pelo cliente.

Categorias canônicas de SLI

Como os SLIs são coletados

• Instrumentação na aplicação: contadores de requisições e histogramas de latência exportados via Spring Boot Actuator / Micrometer (Hands-on 6).
• Monitoramento sintético: sondas que enviam requisições reais de fora do sistema, em intervalos programados (por exemplo, o Prometheus Blackbox Exporter).
• Baseado em logs: análise dos logs de acesso para contar respostas 2xx vs 5xx.
• No cliente: medição a partir do navegador ou do app móvel, para a experiência real do usuário final.

sum(rate(http_server_requests_seconds_count{application="order", status!~"5.."}[5m]))
/
sum(rate(http_server_requests_seconds_count{application="order"}[5m]))

SLO — A meta com que você se compromete

Um SLO é uma meta específica e delimitada no tempo para um SLI. Ele responde: "Quão boa esta métrica precisa ser para considerarmos o serviço saudável?"

Formato:

SLI ≥ threshold em uma rolling window

Uma janela móvel (rolling window) cobre sempre os últimos N dias (por exemplo, de 28 dias atrás até agora), então avança a cada minuto; uma janela de calendário é reiniciada no dia 1º de cada mês.

Exemplos:

Escolhendo o SLO certo

SLOs devem ser ambiciosos, mas alcançáveis. Um SLO que nunca é violado não está impulsionando trabalho de confiabilidade — está frouxo demais. Um SLO violado o tempo todo é ruído — a equipe deixa de confiar nele.

• Comece medindo o SLI atual por 30–90 dias.
• Defina o SLO inicial no patamar observado menos uma pequena margem.
• Aperte-o com o tempo, à medida que o sistema melhora.
• Torne os SLOs públicos dentro da organização de engenharia, para que todas as equipes entendam as metas que estão perseguindo.
• Lembre-se da disponibilidade composta (visão geral): um serviço não pode prometer mais do que o produto dos serviços dos quais depende de forma síncrona.

Error Budget

O error budget (orçamento de erros) é a quantidade de não confiabilidade que o SLO permite. É a licença para assumir riscos da equipe de engenharia.

Para um SLO de disponibilidade de 99,9%, o orçamento é 0,1% — do tempo ou das requisições na janela, dependendo de como o SLI é definido.

Se o error budget está intacto, a equipe pode:

• Fazer deploys com frequência e aceitar algum risco de deploy
• Executar experimentos em sistemas de produção
• Assumir mais dívida técnica

Se o error budget está esgotado, a equipe deve:

• Congelar deploys não essenciais
• Priorizar o trabalho de confiabilidade em vez de novas funcionalidades
• Investigar e corrigir as causas-raiz que estão consumindo o orçamento

Essas regras só funcionam se forem acordadas antes: uma política de error budget é um documento curto, assinado por produto e engenharia, que diz o que acontece quando o orçamento acaba.

Burn rate

A burn rate (taxa de consumo) mede a velocidade com que o error budget está sendo consumido em relação à janela do SLO²:

Com um SLO de 99,9%, uma taxa de erros de 0,1% é uma burn rate de 1 — o orçamento dura exatamente a janela inteira. Uma taxa de erros de 1,44% é uma burn rate de 14,4. Uma burn rate de \(b\) esgota o orçamento em (janela ÷ \(b\)).

Para uma janela de 28 dias:

Os limites de 14,4× e 6× vêm do SRE Workbook: sustentada por 1 hora, uma burn rate de 14,4× consome cerca de 2% do orçamento; sustentada por 6 horas, uma de 6× consome cerca de 5%. (O Workbook os deriva para uma janela de 30 dias; com 28 dias as porcentagens são quase as mesmas.) Alertas de burn rate alta pegam cedo os incidentes rápidos, enquanto alertas de burn rate baixa pegam degradações lentas que, de outra forma, seriam invisíveis².

# Prometheus alerting rule (99.9% SLO → budget = 0.001)
- alert: OrderErrorBudgetFastBurn
  expr: |
    (
      sum(rate(http_server_requests_seconds_count{application="order", status=~"5.."}[1h]))
      /
      sum(rate(http_server_requests_seconds_count{application="order"}[1h]))
    ) > (14.4 * 0.001)
  for: 2m
  labels:
    severity: page

SLA — O compromisso contratual

Um SLA é um acordo formal entre o provedor do serviço e o cliente que define o nível de serviço esperado e as compensações (normalmente créditos de serviço) caso esse nível não seja atingido. SLAs são documentos jurídicos; descumpri-los tem consequências financeiras.

Estrutura de um SLA

1. Serviços cobertos — quais produtos e regiões estão no escopo
2. Metas de SLO — os compromissos de disponibilidade ou de latência
3. Metodologia de medição — como o uptime é calculado, quais incidentes contam
4. Exclusões — manutenção programada, força maior, indisponibilidades causadas pelo cliente
5. Compensações — tabela de créditos de serviço para cada faixa de violação

Exemplos reais de SLA

Os compromissos abaixo foram retirados das páginas públicas de SLA dos provedores³⁴; as condições exatas (tipo de implantação, região, faixas de crédito) mudam com o tempo, então sempre leia a página atual.

Repare em duas coisas. Primeiro, os números mais altos só valem quando você implanta de forma redundante (várias zonas, Multi-AZ) — a redundância é o preço do nove extra. Segundo, a compensação é um crédito na sua fatura, não uma indenização pelas suas vendas perdidas: um SLA transfere parte do risco financeiro, mas não torna o seu sistema disponível.

SLA vs SLO

SLA e SLO são frequentemente confundidos. A distinção crucial:

Boa prática: defina seu SLO mais estrito do que seu SLA. A folga entre SLO e SLA é a margem de segurança que impede que um incidente de confiabilidade dispare penalidades contratuais. Se o SLA é 99,9%, o SLO pode ser 99,95%.

Boas práticas

Pontos-chave

• Um SLI é a razão entre eventos bons e eventos válidos que reflete o que os usuários sentem; um SLO é uma meta para ele em uma janela; um SLA é um contrato com penalidades, mais frouxo que o SLO.
• O error budget é 1 − SLO, em tempo ou em requisições: 99,9% em 28 dias ≈ 40,3 minutos (≈ 43,8 minutos em um mês de 30,44 dias).
• Burn rate = taxa de erros observada ÷ orçamento; 14,4× esvazia um orçamento de 28 dias em cerca de 2 dias e deve acionar alguém.
• O orçamento transforma "lançar ou congelar?" em uma decisão baseada em dados — se houver uma política acordada.
• Sempre informe a janela e use percentis, nunca médias, para latência.