O que são SLI, SLO e error budget, e como usá-los na operação?
Dizer que um sistema precisa estar sempre no ar parece razoável, mas não ajuda a decidir nada. Nenhum serviço tem 100% de disponibilidade, e perseguir esse número trava mudanças e encarece a operação. SLI, SLO e error budget, conceitos difundidos pela engenharia de confiabilidade (SRE), trocam a promessa vaga por uma meta mensurável e por uma regra clara de decisão.
SLI, SLO e SLA: três coisas diferentes
O SLI (indicador de nível de serviço) é a medida: por exemplo, a proporção de requisições respondidas com sucesso em menos de 300 milissegundos. O SLO (objetivo de nível de serviço) é a meta para esse indicador em uma janela de tempo, como 99,9% das requisições em 30 dias. O SLA é o compromisso contratual com o cliente, normalmente com penalidade se não for cumprido.
Na prática, o SLO interno costuma ser mais exigente que o SLA, para que a equipe perceba e reaja antes de descumprir o contrato. O verbete sobre SLA trata do lado contratual.
Como escolher bons SLIs
Um bom SLI reflete o que o usuário percebe, não o que é fácil medir. CPU alta não é problema se ninguém sente; uma API que responde com erro para 2% das chamadas é, mesmo com os servidores tranquilos.
Os tipos mais comuns são:
- Disponibilidade: proporção de requisições válidas atendidas com sucesso.
- Latência: proporção de requisições abaixo de um limite, analisada por percentis como p95 e p99, nunca pela média.
- Qualidade: proporção de respostas completas e corretas, como relatórios gerados sem dados faltando.
- Atualidade: em processos em lote e pipelines de dados, a proporção de execuções concluídas dentro do prazo.
Comece com poucos SLIs por serviço, medidos o mais perto possível do usuário, como no balanceador de carga ou por monitoramento sintético.
Error budget: quanta falha cabe no período
O error budget, ou orçamento de erro, é o complemento do SLO. Se a meta é 99,9% em 30 dias, o orçamento é 0,1%: em requisições, uma falha a cada mil; em tempo, o equivalente a cerca de 43 minutos de indisponibilidade total no mês. Para outras metas, na mesma janela de 30 dias:
- 99%: cerca de 7 horas e 12 minutos.
- 99,5%: cerca de 3 horas e 36 minutos.
- 99,9%: cerca de 43 minutos.
- 99,99%: cerca de 4 minutos e 19 segundos.
A mudança de mentalidade está em tratar esse orçamento como um recurso a ser gasto. Enquanto há saldo, a equipe pode lançar versões, fazer manutenções e assumir riscos calculados. Quando o saldo acaba, a prioridade passa a ser estabilidade: congelar mudanças não urgentes, corrigir as causas das falhas e reforçar testes. Essa regra, combinada antes entre operação, desenvolvimento e negócio, é a política de error budget.
Alertar pela taxa de consumo (burn rate)
Alertar sempre que o SLI fica abaixo da meta gera ruído; esperar o fim do mês para perceber o estouro é tarde demais. A solução é acompanhar o burn rate, a velocidade com que o orçamento está sendo consumido. Um burn rate de 1 gasta o orçamento exatamente no fim da janela; um burn rate de 10 o esgota em um décimo do tempo, cerca de 3 dias em uma janela de 30.
Uma prática difundida pelo material de SRE do Google é combinar janelas: acionar o plantão quando o consumo é muito rápido, como 2% do orçamento em uma hora, e abrir um chamado quando ele é moderado e persistente, como 10% em três dias. Assim, a equipe é acionada pelo que ameaça de verdade a meta.
Erros comuns
- Meta de 100%: impossível de cumprir e capaz de paralisar qualquer mudança.
- SLO de infraestrutura em vez de serviço: servidor no ar não diz se o usuário conclui a tarefa.
- Meta escolhida sem histórico: comece medindo o comportamento atual e ajuste depois de alguns ciclos.
- SLO sem política: se nada muda quando o orçamento acaba, o número vira só mais um gráfico.
- SLOs demais: poucos indicadores bem escolhidos por serviço crítico valem mais que dezenas ignorados.
SLI mede a experiência do usuário, SLO define a meta e o error budget transforma a margem de falha em recurso para decidir entre mudanças e estabilidade. Alertas pela taxa de consumo acionam a equipe só quando a meta está realmente em risco.
Este conteúdo foi útil?
Revisão técnica VIPER IT — última atualização em 10 de outubro de 2026.