SLI, SLO e error budget

Toda discussão sobre confiabilidade que não tem número vira disputa de opinião. O time de produto quer entregar, o time de operação quer estabilidade, e quem grita mais alto ganha.

SLO resolve isso transformando confiabilidade em um orçamento explícito. Não é burocracia: é o mecanismo que substitui a discussão por uma regra combinada de antemão.

Os três termos

SLI — service level indicator. A métrica que representa a experiência do usuário. Não é CPU, não é memória: é a proporção de requisições atendidas bem.

SLO — service level objective. O alvo para o SLI num período. Por exemplo, 99,9% em 30 dias.

SLA — service level agreement. O contrato com o cliente, com consequência financeira. Sempre mais frouxo que o SLO interno — você quer descobrir o problema antes de pagar multa.

O SLO é interno e serve para decidir. O SLA é externo e serve para o jurídico.

Escolhendo o SLI

A regra: meça o que o usuário sente, no ponto mais próximo possível dele.

Um serviço com CPU em 30%, memória tranquila e disco vazio pode estar completamente inútil para quem depende dele. Métrica de recurso diz que a máquina está viva; SLI diz que o serviço está funcionando.

A forma mais útil é uma razão de eventos bons sobre eventos válidos:

SLI = eventos bons / eventos válidos

Isso dá um número entre 0 e 1 que agrega naturalmente e é fácil de raciocinar.

Os tipos que cobrem quase tudo

Disponibilidade — proporção de requisições respondidas sem erro.

sum(rate(http_requests_total{code!~"5.."}[5m]))
  /
sum(rate(http_requests_total[5m]))

Latência — proporção de requisições respondidas dentro de um limite. Repare que não é “a latência média”: é uma contagem de sucessos, o que a torna combinável com a disponibilidade.

sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m]))
  /
sum(rate(http_request_duration_seconds_count[5m]))

Qualidade — proporção de respostas completas, quando o serviço degrada em vez de falhar (por exemplo, devolve resultado sem recomendações personalizadas).

Atualidade (freshness) — para pipelines de dados: proporção do tempo em que o dado estava mais novo que X.

Armadilha

Excluir erros 4xx do numerador sem pensar. Um 429 que você devolveu por rate limit agressivo demais é uma falha sua, sentida pelo usuário. Um 404 por URL digitada errada não é. Decida caso a caso e documente a decisão — senão, seis meses depois ninguém sabe o que o número significa.

Definindo o SLO

Comece pela realidade, não pelo desejo

Meça o SLI durante quatro semanas antes de escolher qualquer alvo. Se o serviço entrega 99,7% hoje e ninguém reclama, um SLO de 99,99% não vai gerar confiabilidade — vai gerar um alerta permanentemente vermelho que todo mundo aprende a ignorar.

Disponibilidades em série se multiplicam

Se a sua API depende de um banco com 99,9% e de um serviço de autenticação com 99,9%, o teto teórico dela é:

0,999 × 0,999 = 0,998  →  99,8%

Prometer 99,99% acima dessas dependências é aritmeticamente impossível sem redundância. Esse cálculo encerra muita reunião rapidamente.

Cada nove custa desproporcionalmente mais

SLO	Falha por mês	Falha por ano
99%	7,2 horas	3,65 dias
99,5%	3,6 horas	1,83 dia
99,9%	43,2 minutos	8,77 horas
99,95%	21,6 minutos	4,38 horas
99,99%	4,3 minutos	52,6 minutos
99,999%	26 segundos	5,3 minutos

Cinco noves permitem cinco minutos de indisponibilidade por ano. Isso é menos que a janela de failover de muitos bancos de dados gerenciados e menos que um deploy malsucedido costuma custar. Quem pede cinco noves quase nunca sabe o que está pedindo.

Use a calculadora de SLO para ver esses números para qualquer alvo.

O error budget

Se o SLO é 99,9%, então 0,1% de falha é permitido. Isso não é tolerância a incompetência: é orçamento.

Em 30 dias, 0,1% equivale a 43,2 minutos. Esse é o seu saldo.

A mudança de mentalidade é grande: falhar dentro do orçamento não é problema. Nem todo incidente merece um postmortem completo, nem toda queda de dois minutos merece uma reunião. O que importa é o saldo no fim do período.

A política de error budget

O orçamento só tem valor se houver uma consequência combinada antes de acabar. Escreva isso e faça as pessoas concordarem enquanto ninguém está em pânico:

Enquanto houver error budget, o time entrega funcionalidade no ritmo normal.

Com o orçamento esgotado, todo deploy que não seja correção de confiabilidade fica suspenso até o saldo se recuperar. A prioridade do time passa a ser confiabilidade.

Um estouro exige postmortem e ao menos um item de prevenção priorizado no ciclo seguinte.

É isso que faz o SLO deixar de ser um painel bonito. Sem consequência acordada, o número vira decoração.

O incentivo se inverte, de propósito

Com error budget, o time de operação passa a ter interesse em que o time de produto entregue rápido — porque orçamento sobrando é sinal de que dá para arriscar mais. E o time de produto passa a ter interesse em confiabilidade, porque orçamento estourado congela a entrega dele. O conflito estrutural some.

Alertar por taxa de consumo

O alerta tradicional — “taxa de erro acima de 5% por cinco minutos” — tem dois defeitos: o limiar é arbitrário e ele não sabe nada sobre o seu compromisso com o usuário.

Alerta por burn rate mede a velocidade com que o orçamento está sendo gasto. Uma taxa de 1× significa consumir exatamente o orçamento ao longo do período. Uma taxa de 14,4× esgota um orçamento de 30 dias em pouco mais de dois dias.

Taxa	Esgota em	Janela do alerta	O que fazer
14,4×	~2 dias	1 hora + 5 min	Acordar alguém
6×	5 dias	6 horas + 30 min	Acordar alguém
3×	10 dias	1 dia + 2 horas	Ticket
1×	30 dias	3 dias + 6 horas	Ticket

O detalhe que faz funcionar são as duas janelas: uma longa, que dá significado, e uma curta, que garante que o problema ainda está acontecendo agora. Sem a janela curta, o alerta continua tocando muito depois de o incidente ter terminado.

Um exemplo completo está no template de regras de SLO.

Erros comuns

SLO por componente, e não por jornada. O usuário não se importa se o serviço de catálogo está de pé; ele quer terminar a compra. Prefira SLI que atravesse a jornada.

SLO demais. Três a cinco por serviço, no máximo. Quinze SLOs significam que nenhum é levado a sério.

Alvo escolhido por vaidade. “99,99% porque a concorrência diz isso” é como se compra uma obrigação que ninguém consegue cumprir.

Medir no lugar errado. SLI coletado dentro da aplicação não enxerga a falha do balanceador, do ingress nem do DNS — exatamente as falhas que o usuário mais sente. Medir na borda é mais honesto.

Nunca revisar. SLO é uma hipótese sobre o que o usuário tolera. Revise a cada trimestre, olhando reclamações e comportamento real.

Leituras relacionadas

• Calculadora de SLO — os números para qualquer alvo
• A economia dos noves — quanto custa cada nove e quando parar
• Alertas que não viram ruído
• Alertar por consumo de error budget — o passo a passo
• Métricas DORA — confiabilidade como a quinta métrica