Quanto de disponibilidade é "bom o suficiente"? Qual latência é "aceitável"? Sem definições claras, essas perguntas viram debates subjetivos. SLI, SLO e SLA são frameworks para transformar expectativas vagas em compromissos mensuráveis.
Este artigo explica cada conceito, como eles se relacionam, e como implementá-los na prática.
Sem metas claras, tudo é urgente e nada é prioridade.
Os Três Conceitos
SLI (Service Level Indicator)
O que é: uma métrica que quantifica algum aspecto do serviço.
Exemplos:
- Proporção de requisições com latência < 200ms
- Proporção de requisições com sucesso (status 2xx)
- Proporção de tempo que o serviço está disponível
Fórmula típica:
SLI = (eventos bons) / (eventos totais) × 100%
Latência SLI = (requisições < 200ms) / (total requisições) × 100%
SLO (Service Level Objective)
O que é: a meta que você define para um SLI.
Exemplos:
- 99% das requisições devem ter latência < 200ms
- 99.9% das requisições devem ter sucesso
- O serviço deve estar disponível 99.95% do tempo
Formato:
SLO = SLI [operador] [threshold] durante [período]
"99% das requisições < 200ms em uma janela de 28 dias"
SLA (Service Level Agreement)
O que é: um contrato formal com consequências se o SLO não for atingido.
Exemplos:
- "Garantimos 99.9% de disponibilidade. Se não atingirmos, você recebe crédito de 10%."
- "Latência máxima de 500ms. Violações resultam em multa contratual."
Relação:
SLA é um contrato baseado em um SLO
SLO é uma meta baseada em um SLI
SLI é uma medição do sistema
Por que SLOs Importam
1. Definem "bom o suficiente"
Sem SLO:
- "O sistema está lento"
- "Precisamos melhorar"
- "Não é bom o bastante"
Com SLO:
- "Estamos em 98.5% vs meta de 99%"
- "Faltam 0.5% para atingir o objetivo"
- "Precisamos reduzir erros em 50%"
2. Permitem trade-offs conscientes
100% de disponibilidade é impossível. 99.999% é extremamente caro. Qual é o nível certo?
| Disponibilidade | Downtime/mês | Custo relativo |
|---|---|---|
| 99% | 7.2 horas | $ |
| 99.9% | 43 minutos | $$ |
| 99.99% | 4.3 minutos | $$$$ |
| 99.999% | 26 segundos | $$$$$$ |
3. Balanceiam velocidade e confiabilidade
Se você está sempre cumprindo seus SLOs, talvez esteja sendo conservador demais. Se está sempre violando, está sendo irresponsável.
O ponto ideal é ocasionalmente usar seu error budget em novos recursos.
Escolhendo Bons SLIs
Características de um bom SLI
- Reflete experiência do usuário: mede o que o usuário vê
- É mensurável: pode ser coletado de forma confiável
- É acionável: você pode fazer algo quando está ruim
- É simples: fácil de entender e explicar
SLIs recomendados por tipo de serviço
Serviços de request/response:
- Disponibilidade: % de requisições com sucesso
- Latência: % de requisições abaixo de threshold
- Qualidade: % de respostas corretas
Serviços de processamento de dados:
- Freshness: % do tempo que dados estão atualizados
- Correctness: % de dados processados corretamente
- Throughput: % de jobs completados no prazo
Serviços de armazenamento:
- Durabilidade: % de dados preservados
- Disponibilidade: % de tempo acessível
- Latência: % de operações abaixo de threshold
Definindo SLOs
O processo
- Escolha SLIs relevantes para o serviço
- Analise dados históricos: qual é o comportamento atual?
- Consulte stakeholders: qual nível é aceitável?
- Defina targets baseados em dados e expectativas
- Itere: SLOs não são estáticos
Exemplo prático
Serviço: API de checkout
Passo 1 - SLIs:
- Latência: % requisições < 500ms
- Disponibilidade: % requisições com sucesso
- Erros: % requisições sem erro 5xx
Passo 2 - Dados históricos:
- Latência: 95% das requisições < 500ms atualmente
- Disponibilidade: 99.7% atualmente
- Erros: 0.3% de erros 5xx
Passo 3 - Stakeholders:
- Produto: "Checkout precisa ser rápido, é crítico para conversão"
- Financeiro: "Cada falha de checkout é venda perdida"
- Engenharia: "Podemos melhorar, mas 100% é impossível"
Passo 4 - SLOs definidos:
- Latência: 99% < 500ms (melhor que atual, desafiador mas alcançável)
- Disponibilidade: 99.9% (muito crítico, precisamos investir)
- Erros: < 0.1% de 5xx
Passo 5 - Janela:
- Rolling window de 28 dias
Implementando SLOs
Monitoramento
# Prometheus alerting rule
- alert: CheckoutLatencySLOBreach
expr: |
(
sum(rate(checkout_request_duration_seconds_bucket{le="0.5"}[5m]))
/
sum(rate(checkout_request_duration_seconds_count[5m]))
) < 0.99
for: 5m
labels:
severity: warning
annotations:
summary: "Checkout latency SLO at risk"
Dashboard
┌────────────────────────────────────────┐
│ SLO Status: Checkout API │
├────────────────────────────────────────┤
│ Latência (<500ms) │
│ ████████████████████░░░ 98.5% / 99% │
│ Error budget: 30% remaining │
├────────────────────────────────────────┤
│ Disponibilidade │
│ █████████████████████░░ 99.85% / 99.9% │
│ Error budget: 50% remaining │
└────────────────────────────────────────┘
Alertas em camadas
- Burn rate alto: SLO vai ser violado em breve → page on-call
- Burn rate médio: SLO em risco → notificação no Slack
- Tendência negativa: pode virar problema → ticket para revisão
Erros Comuns
1. SLOs muito agressivos
Meta: 99.999% disponibilidade
Realidade: 99.9%
Resultado: Sempre violando, time desmotivado, SLO ignorado
2. SLOs muito frouxos
Meta: 95% disponibilidade
Realidade: 99.5%
Resultado: Nunca preocupa, não impulsiona melhoria
3. Muitos SLOs
15 SLOs diferentes
Time não sabe qual priorizar
Nenhum recebe atenção adequada
Recomendação: 3-5 SLOs por serviço.
4. SLOs desconectados do usuário
SLO: CPU < 80%
Usuário: não se importa com CPU, se importa com latência
Resultado: Otimiza métrica errada
Conclusão
SLI, SLO e SLA formam uma hierarquia de compromissos:
| Nível | Pergunta que responde |
|---|---|
| SLI | Como medimos a qualidade? |
| SLO | Qual nível de qualidade buscamos? |
| SLA | Qual é a consequência de não atingir? |
Para implementar com sucesso:
- Comece simples: poucos SLOs bem definidos
- Baseie-se em dados: use histórico para definir metas realistas
- Envolva stakeholders: SLOs são acordos, não imposições
- Monitore e alerte: SLOs sem monitoramento são apenas wishful thinking
- Itere: revise e ajuste conforme aprende
SLOs não são sobre perfeição. São sobre definir o que é "bom o suficiente" e garantir que você entrega isso.