SLI / SLO / SLA

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.

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.
• 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.

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 ≥ limite em uma janela móvel

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.

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% em 28 dias:

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

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. Uma burn rate de 1 significa que o orçamento se esgota exatamente no fim da janela. Uma burn rate de 2 significa que o orçamento acaba na metade da janela.

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².

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

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