SLO e SLI: o que são, diferenças e como implementar na prática

Quando um sistema entra em degradação às 2h da manhã, a pergunta que o time de plantão precisa responder não é “o sistema está fora do ar?” — essa já está respondida pelo alerta. A pergunta real é: até onde essa falha está consumindo a confiabilidade que prometemos ao negócio? É exatamente para responder isso que existem o SLO e o SLI.

Equipes que operam sem SLOs bem definidos tomam decisões baseadas em intuição. Equipes com SLOs claros tomam decisões baseadas em dados: sabem quanto do error budget foi consumido, quando precisam agir e quando podem aceitar o risco. Essa distinção separa times reativos de times que constroem confiabilidade de forma sistemática.

Neste guia técnico, você vai entender o que são SLO e SLI, como se diferenciam do SLA, como defini-los na prática e como integrá-los à estratégia de observabilidade da sua infraestrutura.

O que é SLO (Service Level Objective)?

SLO (Service Level Objective) é uma meta interna de desempenho que define o nível de confiabilidade que um serviço deve atingir em um período determinado. É o compromisso técnico que a equipe de engenharia assume consigo mesma e com o negócio — antes de qualquer contrato formal com o cliente.

Um SLO é sempre expresso como uma porcentagem sobre uma janela de tempo. Por exemplo: “99,9% das requisições ao endpoint de checkout devem ter latência abaixo de 300ms em janelas de 30 dias consecutivos.” Esse número define a fronteira entre operação normal e operação em risco.

Na prática da OpServices, o primeiro erro que observamos em implantações de SLOs é a definição de metas por aspiração: times escolhem 99,99% porque soa bem, sem analisar o histórico real do serviço. Um SLO inatingível gera error budget permanentemente zerado, o que paralisa deploys e cria atrito constante entre engenharia e produto. O ponto de partida correto é sempre o percentil histórico dos últimos 90 dias, com uma meta ligeiramente mais agressiva para incentivar melhoria contínua.

SLO vs. SLA: qual é a diferença real?

O SLA (Service Level Agreement) é o contrato formal com o cliente, com consequências jurídicas e financeiras pelo descumprimento. O SLO é a meta interna que sustenta esse contrato.

A relação entre os dois é deliberadamente assimétrica: o SLO deve ser sempre mais rigoroso que o SLA. Se o SLA garante 99,5% de disponibilidade ao cliente, o SLO interno deve mirar 99,8% ou mais. Essa margem de segurança é o buffer que impede que falhas operacionais normais — deploys, oscilações de tráfego, incidentes menores — resultem em violação de contrato.

Em ambientes sem essa separação, qualquer incidente que degrade o serviço gera pressão imediata de SLA. Com SLOs bem calibrados, a equipe tem espaço para operar, aprender e melhorar antes de atingir o limite contratual.

O que é SLI (Service Level Indicator)?

SLI (Service Level Indicator) é a métrica quantitativa que mede diretamente o comportamento do serviço. É o número real, coletado em tempo real, que indica se o SLO está sendo cumprido ou não.

A relação é direta: o SLO define a meta e o SLI mede se essa meta está sendo atingida. Se o SLO é “99,9% das requisições com latência abaixo de 300ms”, o SLI é o percentual real de requisições que ficaram dentro desse threshold em cada período medido.

Um SLI bem definido tem três características obrigatórias: é mensurável continuamente (não apenas em relatórios mensais), está diretamente correlacionado com a experiência do usuário final, e pode ser calculado a partir dos dados de telemetria já disponíveis na infraestrutura.

Tipos de SLI mais utilizados

Os SLIs se organizam em torno dos 4 sinais de ouro do SRE: latência, tráfego, erros e saturação. Cada um responde a uma pergunta específica sobre a saúde do serviço.

SLI de disponibilidade mede a proporção de requisições bem-sucedidas sobre o total. É o tipo mais comum e o ponto de partida para qualquer estratégia de SLO. Exemplo: requisições_com_status_2xx / total_requisições.

SLI de latência mede a proporção de requisições que completaram dentro do threshold de tempo definido. Atenção: o percentil correto aqui é o P95 ou P99, não a média. Médias de latência mascaram degradações que afetam entre 1% e 5% dos usuários — exatamente o segmento mais crítico em sistemas financeiros e de e-commerce.

SLI de qualidade mede se o serviço está entregando resultados corretos, não apenas respostas rápidas. Em pipelines de dados, por exemplo, o SLI de qualidade pode ser a proporção de registros processados sem erro de validação.

SLI de saturação mede o quanto o sistema está próximo do seu limite de capacidade. É o SLI preditivo por excelência — permite detectar degradação iminente antes que ela se torne visível ao usuário.

A tríade SLI, SLO e SLA na prática

Os três conceitos formam uma hierarquia de comprometimento que vai do técnico ao contratual. Entender como cada camada se relaciona é essencial para construir uma estratégia de confiabilidade coerente.

O SLI é a realidade: o número que o sistema está entregando agora. O SLO é a meta: o número que a equipe se comprometeu a entregar. O SLA é o contrato: o número que a empresa prometeu ao cliente.

Na operação diária, o fluxo de decisão funciona assim: o SLI coleta dados continuamente. Quando o SLI se aproxima ou viola o SLO, alertas são disparados e a equipe age. O SLO é dimensionado com margem suficiente para que violações operacionais normais nunca cheguem ao SLA. O SLA funciona como último limite, raramente acionado.

Em um cliente do setor de pagamentos gerenciado pela OpServices, implementamos três camadas de SLO para o serviço de autorização de transações: SLO de disponibilidade em 99,95%, SLO de latência P99 abaixo de 180ms, e SLO de taxa de erro abaixo de 0,02%. O SLA contratual estava em 99,9% de disponibilidade. A margem de 0,05 ponto percentual entre o SLO interno e o SLA externo equivale a pouco mais de 4 minutos de downtime tolerado por mês — espaço suficiente para rollbacks de emergência sem acionar penalidades contratuais.

O que é Error Budget e como ele conecta tudo?

O error budget é a consequência prática do SLO. Se o SLO define que o serviço deve estar disponível 99,9% do tempo em 30 dias, o error budget é os 0,1% restantes — equivalente a aproximadamente 43 minutos de downtime tolerado por mês.

Esse budget não é apenas uma métrica: é um instrumento de governança técnica. Quando o error budget está alto (pouco consumido), a equipe tem liberdade para fazer deploys arriscados, experimentos e refatorações. Quando está baixo (muito consumido), o foco muda automaticamente para estabilidade e confiabilidade.

Essa dinâmica resolve o conflito histórico entre velocidade e estabilidade. Em vez de negociações subjetivas sobre “quando é seguro fazer deploy”, o error budget fornece uma resposta objetiva baseada em dados reais de confiabilidade. Times maduros de SRE usam o consumo do error budget como o principal critério para autorizar ou vetar features em produção.

Como definir SLOs e SLIs na prática

A definição de SLOs é um processo colaborativo entre engenharia e produto. O erro mais comum é fazer isso em silos — a engenharia define SLOs tecnicamente corretos que não refletem o que o usuário realmente experimenta, ou o produto define SLOs aspiracionais que a infraestrutura não consegue sustentar.

Passo 1: identifique as jornadas críticas do usuário

Antes de definir qualquer número, mapeie quais ações do usuário são mais sensíveis a falhas. Em um e-commerce, a jornada de checkout é mais crítica que a página de listagem de produtos. Em um sistema bancário, a consulta de saldo tem peso diferente de relatórios históricos. Cada jornada crítica merece um conjunto próprio de SLIs e SLOs.

Passo 2: escolha SLIs que medem experiência real

Um SLI válido deve responder à pergunta: “o usuário está tendo uma boa experiência?” — não “o servidor está respondendo?”. A diferença é sutil mas crítica. Um servidor pode responder com HTTP 200 enquanto retorna dados corrompidos. Um SLI de disponibilidade puro não detecta isso; um SLI de qualidade detecta.

Para sistemas com RUM (Real User Monitoring) implementado, os SLIs podem ser derivados diretamente da experiência do usuário real, não apenas de métricas de infraestrutura.

Passo 3: calibre os SLOs com dados históricos

Nunca defina SLOs sem consultar o histórico de desempenho real do serviço. A abordagem recomendada é: analise os últimos 90 dias de métricas, identifique o percentil P5 de pior desempenho (os 5% de dias mais problemáticos), e use esse valor como baseline. O SLO deve ser ligeiramente mais rigoroso que esse baseline para criar pressão de melhoria sem tornar as metas inatingíveis.

Passo 4: revise SLOs periodicamente

SLOs não são definições permanentes. À medida que a infraestrutura melhora, os SLOs devem ser revisados trimestralmente. Um SLO que nunca é violado por longos períodos provavelmente está mal calibrado — sendo conservador demais para gerar pressão de melhoria contínua.

SLOs, SLIs e observabilidade: a integração necessária

SLOs e SLIs só funcionam quando alimentados por dados de observabilidade estruturada. Um SLI de latência P99 requer que todas as requisições sejam instrumentadas com traces distribuídos. Um SLI de disponibilidade requer que os logs de erro sejam estruturados e indexáveis em tempo real. Um SLI de saturação requer coleta contínua de métricas de infraestrutura.

Nesse sentido, a definição de SLOs é também um exercício de auditoria de observabilidade: para medir o que você prometeu, você precisa ter a instrumentação correta. Times que tentam implementar SLOs sem observabilidade madura descobrem que seus SLIs são imprecisos ou defasados, tornando os SLOs inúteis como instrumentos de decisão.

A integração com OpenTelemetry é o padrão recomendado para instrumentação de SLIs em ambientes cloud-native. Com OpenTelemetry, os mesmos dados de telemetria que alimentam dashboards de observabilidade alimentam automaticamente o cálculo de SLIs — sem duplicação de instrumentação.

Conclusão

SLO e SLI não são burocracia de processo — são instrumentos de engenharia que transformam confiabilidade em algo mensurável, gerenciável e comunicável. Um time que opera com SLOs bem calibrados e SLIs precisos tem clareza sobre o que pode arriscar, quando precisa estabilizar e como justificar decisões técnicas para o negócio.

A implementação bem-sucedida começa pela escolha correta dos SLIs, passa pela calibração honesta dos SLOs com dados históricos e evolui com a revisão contínua das metas à medida que a infraestrutura amadurece. O error budget é o elo que conecta tudo isso à tomada de decisão diária.

Se o seu time ainda define confiabilidade de forma subjetiva ou toma decisões de deploy baseadas em intuição, o primeiro passo é estruturar os SLIs dos serviços críticos. O restante segue naturalmente. Para iniciar essa jornada com suporte especializado, fale com nossos especialistas.