SLA, SLO e SLI — Dev Helper Biblioteca

Intenção

SLI, SLO e SLA formam uma hierarquia para transformar "o sistema deve ser confiável" em métricas mensuráveis, metas defensáveis e contratos exigíveis. Cada camada tem um público diferente e consequências diferentes em caso de violação.

O framework foi popularizado pelo modelo de Site Reliability Engineering (SRE) do Google e hoje é padrão em times que operam sistemas em produção com on-call. O conceito central é que confiabilidade precisa ser definida antes de ser medida, e medida antes de ser negociada. Sem essa cadeia, discussões sobre disponibilidade são subjetivas e decisões de engenharia carecem de critério objetivo.

Problema

Times de engenharia enfrentam decisões constantes sobre o que priorizar: novos recursos ou estabilidade? Deploy agora ou aguardar mais testes? Escalar o banco ou aceitar degradação? Sem uma definição clara de quanta falha é aceitável, essas decisões dependem de intuição, política interna ou pressão do momento:

Sem SLI: não há consenso sobre o que medir. "O sistema está up" pode significar que o servidor está respondendo ping enquanto 30% das requisições retornam erro 500. Métricas de infraestrutura não refletem a experiência real do usuário.
Sem SLO: não há meta para defender. Qualquer nível de falha é implicitamente aceitável, o que leva a sistemas progressivamente mais instáveis sem que ninguém formalize o problema.
Sem SLA: não há consequências formais para o provedor do serviço. Usuários e clientes não têm base para exigir compensação ou escalar problemas de confiabilidade.
Sem Error Budget: a decisão de fazer ou não um deploy arriscado é tomada com base em "parece ok" em vez de "temos X% de budget restante neste mês". O conceito de budget transforma a confiabilidade em recurso gerenciável.

Como funciona

SLI — Service Level Indicator

O SLI é a métrica real medida: um número que quantifica um aspecto do comportamento do sistema do ponto de vista do usuário. É a base de tudo — SLO e SLA são expressões de SLIs.

Disponibilidade: proporção de requisições bem-sucedidas / total de requisições.
Latência: proporção de requisições respondidas em menos de X ms.
Taxa de erros: proporção de respostas 5xx / total de respostas.
Throughput: volume de operações processadas por unidade de tempo.

A escolha do SLI é crítica: ele deve refletir a experiência do usuário, não a saúde da infraestrutura. O servidor pode estar "up" (CPU 5%, memória ok) enquanto o serviço retorna timeout para os usuários. O SLI correto captura o que o usuário experimenta, não o que o dashboard de infraestrutura mostra.

SLO — Service Level Objective

O SLO é a meta interna para o SLI: o alvo que a equipe de engenharia se compromete a atingir e defende operacionalmente. É definido como um valor alvo do SLI em uma janela de tempo.

Exemplos:

99,9% das requisições com latência abaixo de 200ms nos últimos 30 dias.
Disponibilidade de 99,95% medida como proporção de requisições bem-sucedidas no mês calendário.
Taxa de erros abaixo de 0,1% em qualquer janela de 1 hora.

O SLO é uma meta interna — não é o contrato com o cliente, mas é o que a engenharia trata como limite. Quando o SLO está sendo violado, é o sinal para acionar on-call, paralisar deploys e priorizar estabilidade sobre funcionalidades.

SLA — Service Level Agreement

O SLA é o contrato externo com o cliente ou usuário. É baseado nos SLOs, mas com margem de segurança: o SLA é menos restritivo que o SLO interno, porque a equipe precisa de espaço para falhar no SLO sem imediatamente violar o contrato.

A violação do SLA tem consequências formais: créditos na fatura, penalidades contratuais, direito de rescisão. Por isso o SLA é sempre mais permissivo: se o SLO interno é 99,9%, o SLA externo pode ser 99,5%.

Hierarquia e margens

  SLI (medida real)
  ──────────────────────────────────────────────────────────────────
  │  O que o sistema está fazendo: proporção de requisições
  │  bem-sucedidas medida nos últimos 30 dias = 99,94%
  ▼

  SLO (meta interna — o que a engenharia defende)
  ──────────────────────────────────────────────────────────────────
  │  Meta: SLI ≥ 99,9%
  │  Status: OK (99,94% > 99,9%)
  │  Se violado → alerta de on-call, freeze de deploys arriscados
  ▼

  SLA (contrato externo — o que o cliente pode exigir)
  ──────────────────────────────────────────────────────────────────
  │  Contrato: disponibilidade ≥ 99,5%
  │  Status: OK (99,94% >> 99,5%)
  │  Se violado → créditos, penalidades, direito de rescisão

  Margem de segurança: SLO (99,9%) - SLA (99,5%) = 0,4%
  Permite que o SLO seja violado sem violar imediatamente o contrato.

Error Budget

O Error Budget é derivado diretamente do SLO: Error Budget = 1 - SLO. Se o SLO é 99,9%, o error budget mensal é 0,1% do tempo — aproximadamente 43 minutos de downtime (ou proporção equivalente de requisições com falha). É o quanto o sistema pode falhar dentro do período sem violar o SLO.

O budget funciona como recurso: quando está cheio, o time tem liberdade para deployar features novas com risco controlado. Quando está próximo de zero ou esgotado, a política é paralisar deploys arriscados e focar em estabilidade até o orçamento se renovar. Isso torna a decisão técnica — "fazemos o deploy agora?" — dependente de um dado objetivo em vez de uma discussão subjetiva.

Tabela de "noves" de disponibilidade

  Disponibilidade │ Downtime/ano    │ Downtime/mês   │ Downtime/semana
  ────────────────┼─────────────────┼────────────────┼─────────────────
  99%             │ ~87,6 horas     │ ~7,3 horas     │ ~1,7 horas
  99,9%           │ ~8,7 horas      │ ~43,8 minutos  │ ~10,1 minutos
  99,99%          │ ~52,6 minutos   │ ~4,4 minutos   │ ~1,0 minuto
  99,999%         │ ~5,3 minutos    │ ~26,3 segundos │ ~6,1 segundos
  99,9999%        │ ~31,5 segundos  │ ~2,6 segundos  │ ~0,6 segundo

  Cada "nove" adicional reduz o downtime permitido por ~10x e tipicamente
  exige arquitetura mais complexa e cara para ser atingido de forma consistente.

Quando usar

Qualquer serviço com usuários externos ou internos com dependência real: APIs consumidas por outros times, produtos B2B, plataformas com SLA contratual. Sem SLI/SLO definidos, não há critério para saber se o sistema está bom o suficiente.
Times com on-call: o SLO é o critério objetivo que define quando acionar o on-call e quando a situação está normalizada. Sem ele, cada engenheiro tem sua própria definição de "problema".
Times que precisam balancear velocidade e estabilidade: o Error Budget é o árbitro técnico. Quando o budget está cheio, o time pode ser mais agressivo em deploys. Quando está esgotado, o foco muda para confiabilidade.
Contratos B2B com penalidades: o SLA formal com consequências requer SLO interno mais restritivo e SLI bem definido para monitorar continuamente.

Quando evitar

Sistemas internos de dev/teste sem impacto em produção: ambientes de desenvolvimento, pipelines de CI, ferramentas internas de baixo criticidade. O overhead de definir e monitorar SLOs não se paga.
MVPs em fase de descoberta: quando o produto ainda está sendo validado e a prioridade é aprender rápido, definir SLOs formais pode criar rigidez desnecessária. Introduza SLOs quando o produto começar a ter usuários com expectativas reais de confiabilidade.

Prós e contras

Prós

Linguagem comum: SLI/SLO/SLA criam vocabulário compartilhado entre engenharia, produto e negócio para falar de confiabilidade com precisão.
Decisões baseadas em dados: o Error Budget transforma "fazemos o deploy?" em uma questão com resposta objetiva baseada em métricas reais.
Alinhamento de expectativas: o SLA explicita o que o cliente pode esperar e o que acontece se a expectativa não for atendida.
Priorização clara: quando o Error Budget está esgotado, toda a organização sabe que a prioridade é estabilidade — sem negociação caso a caso.
Detecta problemas invisíveis: um SLI bem escolhido captura degradação que os dashboards de infraestrutura não mostram.

Contras

Custo de setup: definir SLIs relevantes, implementar a instrumentação e criar os dashboards de SLO requer investimento inicial não trivial.
SLI difícil de escolher: medir a métrica certa que reflete a experiência do usuário é mais complexo do que parece. SLIs ruins levam a SLOs que não protegem ninguém.
Falsa precisão: SLOs de 99,95% sugerem precisão que pode não existir se a medição do SLI tiver erros ou lacunas.
Burocracia se mal aplicado: times pequenos com SLOs rígidos e processos de freeze de deploy excessivos perdem agilidade sem ganho proporcional em confiabilidade.

Armadilhas comuns

1. SLO igual ao SLA

Quando o SLO interno e o SLA externo são idênticos, não há margem de segurança. Qualquer incidente que viola o SLO viola imediatamente o contrato com o cliente. O SLO interno deve ser mais restritivo que o SLA externo para absorver incidentes antes que cheguem ao nível de penalidade contratual.

2. SLI que não reflete a experiência do usuário

Medir uptime do servidor (ping responde?) em vez de disponibilidade do serviço (requisições bem-sucedidas?) é o erro mais comum. O servidor pode estar "up" retornando código 200 com corpo de erro para todas as requisições. O SLI deve medir o que o usuário experimenta, não o que a infraestrutura reporta.

Regra prática: se um usuário consegue perceber a degradação mas o SLI não indica problema, o SLI está errado. A pergunta é: "o usuário consegue fazer o que precisa?" — e o SLI deve responder isso.

3. Error Budget ignorado na prática

Muitos times definem SLO e calculam o Error Budget mas não mudam o comportamento quando o budget se esgota. Deploys arriscados continuam, features novas continuam em produção e o SLO vira uma métrica decorativa. O valor do Error Budget é comportamental: ele precisa mudar decisões reais, ou não existe para nada.

4. SLO muito agressivo logo no início

Definir 99,999% de disponibilidade como SLO para um serviço novo exige arquitetura de alta disponibilidade cara e complexa — redundância em múltiplos data centers, failover automático, testes de caos, etc. Comece com 99,9%, meça o SLI real por alguns meses e ajuste o SLO com base nos dados. SLOs devem ser calibrados com a realidade do sistema, não com aspirações.

Arquiteturas e padrões relacionados

Circuit Breaker e SLO operam em camadas diferentes do mesmo objetivo. O SLO define o nível de confiabilidade que o sistema deve atingir (ex.: 99,9% de requisições com sucesso). O Circuit Breaker é um mecanismo que ajuda a atingir esse objetivo ao prevenir cascata de falhas e degradar o serviço graciosamente em vez de falhar completamente. O estado do circuito — quantas vezes ele abriu, por quanto tempo — é um dado direto para o SLI de disponibilidade.

Load Balancing e Escalabilidade Horizontal são mecanismos operacionais que aumentam a capacidade de manter o SLO. Escalar horizontalmente distribui a carga, reduzindo o risco de sobrecarga que degrada o SLI. O Load Balancer detecta instâncias com falha e remove do pool, mantendo a disponibilidade medida pelo SLI mesmo quando instâncias individuais falham.