SLO: guia de implementação por vertical de serviço

Times que tentam implementar SLOs pela primeira vez quase sempre cometem o mesmo erro: definem o objetivo antes de entender o serviço. O resultado são SLOs de 99,99% que consomem o error budget em horas, ou SLOs de 90% que nunca disparam nenhum alerta porque o serviço já opera melhor que isso naturalmente.

Um SLO (Service Level Objective) é um objetivo de confiabilidade expresso como threshold de um SLI ao longo de uma janela de tempo. Definido corretamente, ele se torna a âncora das decisões operacionais do time: quando o error budget está cheio, o time pode acelerar. Quando está consumido, a confiabilidade vira prioridade. Como parte de uma estratégia de observabilidade, o SLO conecta dados de telemetria com decisões de negócio.

Neste guia, você encontra o processo de implementação de SLOs por vertical de serviço — com thresholds de referência, janelas de tempo recomendadas e os erros mais comuns a evitar em cada contexto.

Como definir o SLO certo: o processo antes dos números

O ponto de partida não é escolher um número — é responder a três perguntas. Qual é o comportamento mínimo aceitável para o usuário? Qual é o comportamento que o serviço entrega historicamente? Qual é o custo de ultrapassar esse limite?

A resposta à primeira pergunta vem de dados de suporte e de negócio. A resposta à segunda vem do histórico de métricas dos últimos 30 a 90 dias. A terceira é uma decisão de produto e engenharia.

A prática recomendada pelo SRE do Google é: defina o SLO ligeiramente abaixo do desempenho histórico real para ter margem operacional. Um serviço que historicamente atinge 99,8% de disponibilidade deve ter um SLO de 99,5% — não de 99,99%, que seria inatingível sem investimento significativo.

SLOs para APIs e serviços web transacionais

Disponibilidade

A janela de tempo padrão para APIs é 30 dias com cálculo rolling (não calendário). O threshold típico varia por criticidade do serviço: APIs de missão crítica (pagamento, autenticação): 99,9%. APIs de funcionalidades secundárias (relatórios, notificações): 99,5%. APIs internas de suporte: 99,0%.

O cálculo do error budget correspondente: 99,9% em 30 dias = 43,2 minutos de downtime aceitável. 99,5% = 3,6 horas. 99,0% = 7,3 horas.

Latência

O SLO de latência deve definir tanto o percentil quanto o threshold: “95% das requisições devem responder em menos de 300ms“. Evitar médias — elas mascaram degradação de P99.

Referências por tipo: APIs síncronas de dados críticos: P95 < 300ms. APIs de consulta com joins complexos: P95 < 1s. APIs de geração de relatórios: P95 < 5s (com feedback assíncrono ao usuário).

SLOs para plataformas de e-commerce

Em e-commerce, o SLO deve ser orientado ao funil de conversão, não apenas à disponibilidade técnica. Os endpoints mais críticos — busca de produtos, adição ao carrinho e checkout — devem ter SLOs mais restritivos que o restante da aplicação.

Estrutura recomendada: SLO de disponibilidade do checkout: 99,95% em 30 dias. SLO de latência do checkout: P95 < 500ms. SLO de disponibilidade de busca: 99,9%. SLO de latência de busca: P95 < 800ms.

A separação por endpoint crítico versus não-crítico permite alocar o error budget de forma assimétrica: degradações em páginas de FAQ consomem menos budget do que degradações no fluxo de pagamento.

SLOs para sistemas de dados e pipelines

Pipelines de dados têm perfil diferente: a latência de uma requisição individual não é a métrica relevante. Os SLOs mais importantes são de frescor e completude.

SLO de frescor: "95% dos jobs de ETL devem completar em até 30 minutos do horário agendado." SLO de completude: "99% dos registros esperados devem estar presentes na tabela de destino após a execução."

A janela de tempo para pipelines geralmente é medida por ciclo de execução, não em dias corridos. Um pipeline que executa a cada hora tem seu SLO calculado por ciclo: quantos ciclos dos últimos 720 (30 dias) completaram dentro do threshold.

SLOs para infraestrutura e redes

Em infraestrutura, os SLOs mais relevantes são de disponibilidade de componentes críticos (load balancers, DNS, gateways) e de latência de rede.

Para monitoramento de redes, o SLO de disponibilidade de uplink é tipicamente 99,9%, com alertas para latência acima de thresholds definidos por tipo de tráfego. A referência técnica do NIST para métricas de disponibilidade de infraestrutura está em nist.gov.

Janelas de tempo: rolling vs. calendário

A escolha da janela de tempo afeta diretamente o comportamento operacional do SLO. Janelas de calendário (mês corrido) criam um efeito de "reinicialização" no primeiro dia do mês — o time pode ser mais agressivo no início do período. Janelas rolling (últimos 30 dias) mantêm pressão constante e são a recomendação padrão do SRE.

Para serviços com sazonalidade marcada (picos de Black Friday, por exemplo), janelas multi-período ajudam a contextualizar o desempenho: SLO padrão para dias normais e SLO de contingência para janelas de pico declaradas.

Conclusão

Implementar SLOs por vertical de serviço é o que transforma metas genéricas de disponibilidade em instrumentos operacionais precisos. A distinção entre o SLO de checkout e o SLO de relatórios, entre o SLO de API síncrona e o SLO de pipeline assíncrono, é o que permite alocar error budget de forma estratégica.

O próximo passo após definir os SLOs é instrumentar os SLIs correspondentes com dados reais de produção e conectar os alertas ao fluxo de resolução de incidentes. Para implementar SLOs calibrados para o seu ambiente com suporte técnico especializado, fale com nossos especialistas.