O que é um SLO? Definição, Exemplos e Melhores Práticas

O que é um SLO?

O que e um SLO? Um objetivo de nível de serviço é a meta interna de confiabilidade que sua equipe estabelece para si mesma. Não é um contrato com clientes. Não é uma métrica bruta de sua stack de observabilidade. Um SLO responde uma pergunta: quão confiável este serviço precisa ser, e como vamos medir isso?

Um SLO completo se parece assim: 99,9% das requisições HTTP para /api/checkout retornam um status de sucesso e se completam em 300ms, medidos em uma janela contínua de 30 dias. Três componentes: a medição, a meta e a janela. Todos os três importam.

SLI, SLO, SLA: Três Siglas Que Significam Coisas Diferentes

Esses três termos aparecem constantemente. Equipes os usam indistintamente. Eles descrevem coisas diferentes.

Um SLI (Indicador de Nível de Serviço) é a medição bruta que seu sistema de monitoramento produz. Taxa de erro como percentual do total de requisições. Latência P99 em milissegundos. Percentual de escritas bem-sucedidas no banco de dados. O SLI é o número que sai de Datadog, Grafana ou qualquer stack que você esteja rodando. Ele te diz o que aconteceu.

Um SLO (Objetivo de Nível de Serviço) é a meta que você define sobre o SLI. Ele responde: de todos os valores possíveis que este SLI pode assumir, qual faixa conta como aceitável? Se seu SLI é taxa de erro e seu SLO é "taxa de erro abaixo de 0,1% para 99% das janelas de cinco minutos", então você tem um teste passa/falha, não apenas um número em um painel.

Um SLA (Acordo de Nível de Serviço) é a versão externa da mesma lógica, com consequências contratuais. Seu SLA pode dizer "99,5% de disponibilidade ou emitimos um crédito de 20% de serviço". Seu SLO deve ficar acima desse limiar, para que sua equipe saiba sobre uma degradação antes que uma violação do SLA vire uma conversa com o cliente.

A diferença entre SLO e SLA não é pano para enxugar incompetência. É uma margem planejada que converte "estamos tendendo para uma violação" em "temos tempo de consertar isso agora".

Uma distinção importante: SLIs são medidos continuamente, mas SLOs são avaliados em uma janela. A mesma taxa de erro medida em sete dias versus 30 dias produz resultados muito diferentes de passa/falha. Uma única hora ruim importa muito em uma janela de sete dias. Em uma janela de 30 dias, é aproximadamente um por cento do período. Escolher a janela certa é tão importante quanto escolher a meta certa.

Por Que "Quão Confiável?" Não É Uma Pergunta Completa

Antes de escolher um número, você precisa entender o que o usuário experimenta quando o serviço se degrada. "Precisamos de cinco noves" é uma declaração de ambição, não uma medição. Uma API de checkout em 99,999% de disponibilidade significa aproximadamente 26 segundos de erros por mês. Para um serviço processando dez transações por segundo, isso pode ser aceitável. Para um serviço tratando liquidação financeira em tempo real, pode não ser.

O SLO correto depende de dois fatores: o impacto do usuário de uma degradação, e o custo operacional de manter uma meta mais rigorosa.

Se seu serviço teve 99,3% de disponibilidade nos últimos 90 dias, começar seu primeiro SLO em 99,9% é aspiracional, não calibrado. A abordagem prática: puxe os dados de SLI dos últimos 90 dias, defina o SLO um pouco mais rigoroso que o desempenho atual, depois revise trimestralmente. Um SLO de 99,5% com uma política real de erro budget bate um SLO de 99,9% que é ignorado sempre que é violado.

Metas comuns de SLO por tipo de serviço:

• APIs viradas para o usuário (checkout, autenticação): 99,9% de disponibilidade, latência P99 abaixo de 500ms

• Serviços internos (pipelines de dados, jobs em batch): taxa de sucesso de 99,5%, medida na conclusão do job

• Ferramentas de admin: 99% de disponibilidade é frequentemente suficiente

• Workers em background: SLO no tempo de conclusão do job em vez de status HTTP

Ao escolher qual SLI medir, use os quatro sinais do livro de SRE do Google como ponto de partida: disponibilidade (a requisição teve sucesso?), latência (quanto tempo demorou?), throughput (quantas requisições o sistema está tratando?), e taxa de erro (qual fração falhou?). Nem todo serviço precisa de todos os quatro. A maioria das equipes tem sinal real de disponibilidade mais um percentil de latência. Adicionar mais SLIs antes de ter uma baseline confiável para os dois primeiros é uma forma comum de criar ruído sem ganhar visão.

O Error Budget: De Meta para Decisão Operacional

Um error budget é o inverso matemático de seu SLO. Se seu SLO de disponibilidade é 99,9%, então 0,1% das requisições na janela de medição podem falhar. Para um serviço recebendo um milhão de requisições por mês, isso significa 1.000 requisições falhadas antes que o SLO seja violado.

O error budget torna SLOs operacionalmente úteis. Sem ele, um SLO é um limiar que é violado e depois discutido. Com uma política de error budget, vira um framework de decisão.

Quando o error budget está saudável, digamos 80% restante com duas semanas faltando na janela, a equipe pode fazer deploy rápido. Novas funcionalidades, experimentos, deployments mais arriscados estão todos dentro das regras. O error budget é o sinal de que velocidade não é atualmente a restrição.

Quando o error budget está se queimando, a equipe se adapta. Mudanças não-críticas vão para espera. A política de deployment fica mais rigorosa. Fixes de confiabilidade são priorizados. O error budget tomou a decisão, não um julgamento de gerente sobre se as coisas "parecem estáveis o suficiente".

Um cenário concreto: um serviço de checkout teve uma degradação de 12 minutos numa terça à tarde, consumindo 15% do error budget mensal. Um segundo incidente na quinta consumiu outros 12%. Com 27% consumido na primeira semana do mês, a política de error budget se ativa: nenhum novo deployment de funcionalidades até que um postmortem seja completo e a causa raiz seja consertada. Essa decisão não é uma negociação produto/engenharia. É uma leitura dos dados.

O Google publicou sua política de error budget no SRE Workbook: um incidente único consumindo mais de 20% do error budget trimestral requer um postmortem. Essa é uma política concreta para adaptar.

Burn rate alerts levam isso adiante. Em vez de esperar até que o error budget esteja quase zerado, um alerta de burn rate dispara quando a taxa de consumo sugere que você vai zerar o budget antes da janela terminar. Se seu serviço está consumindo error budget a 14 vezes a taxa normal, você vai zerar um budget de 30 dias em aproximadamente 50 horas. Um alerta nessa taxa dá à equipe dois dias para responder em vez de uma notificação de postmortem após a violação. Ferramentas como Datadog e Grafana suportam alertas multi-janela e multi-burn-rate nativamente. Configurar leva uma tarde. Não ter significa descobrir violações de SLO depois que os clientes já notaram.

Configurando Seu Primeiro SLO Sem Cometer Erros Com o Número

O erro mais comum é começar com a meta antes de estabelecer a medição.

Passo 1: Defina o SLI. "Disponibilidade" não é um SLI. "Requisições HTTP retornando um status sem erro (2xx/3xx), divididas por todas as requisições HTTP" é um SLI. A medição deve ser produzível a partir de telemetria que você já tem. Prometer instrumentar algo "em breve" significa que o SLO não tem fonte de dados.

Passo 2: Puxe dados históricos. Olhe para os últimos 60 a 90 dias. Como o SLI realmente se parece? Quais foram os dois ou três piores dias? Isso te diz qual meta é alcançável hoje e quanto espaço você tem antes da primeira violação.

Passo 3: Defina a janela de medição. Janelas contínuas de 30 dias são as mais comuns e te dão dados responsivos e sempre atuais. Janelas de mês calendário criam efeitos cliff nos limites do mês. Janelas contínuas de sete dias são mais sensíveis mas podem disparar com muita frequência para equipes ainda construindo musculatura de confiabilidade.

Passo 4: Escreva a política de error budget antes de precisar dela. Em que taxa de burn do error budget a equipe pausa mudanças não-críticas? Em que taxa o on-call faz escalação? Documente isso antes do incidente, não durante.

Passo 5: Comece com um serviço. Definir SLOs para 15 serviços de uma vez produz 15 painéis que ninguém lê. Comece com o serviço mais visível para o usuário, rode um trimestre, ajuste, depois expanda.

Opções de janela de medição e seus tradeoffs:

• 7 dias contínuos: feedback rápido, mais sensível a incidentes curtos, pode criar alert fatigue

• 30 dias contínuos: mais comum, equilibra sinal e ruído

• 90 dias contínuos: útil para operações infrequentes mas críticas como jobs em batch

Um exemplo prático: para uma API de e-commerce, você pode definir seu primeiro SLO como "95% das requisições para /checkout têm sucesso e retornam em 500ms, medidos em uma janela contínua de 28 dias". Isso te dá um SLI concreto (taxa de sucesso combinada com latência), uma meta específica (95%), e uma janela definida (28 dias). Daí, você calcula o error budget: 5% do total de requisições podem falhar ou ser lento. Se você recebe 200.000 requisições por dia, seu error budget mensal é aproximadamente 280.000 requisições falhadas antes que o SLO seja violado.

Aonde Monitoramento de SLO Se Conecta ao Trabalho no Codebase

Um error budget se queimando mais rápido que o esperado é um problema de codebase com frequência maior que um de infraestrutura. Picos de latência rastreiam de volta para queries N+1 que passaram despercebidas em code review. Quedas de disponibilidade rastreiam de volta para uma exceção de null pointer em um caminho de código que só é disparado sob uma combinação específica de carga. O SLO detecta os sintomas. O codebase contém a causa.

É aqui que o tempo entre "alerta dispara" e "causa raiz identificada" vira a restrição prática. Quando o serviço de checkout está consumindo 30% do seu error budget em três dias e o engenheiro on-call tem de fazer grep em um monorepo de 150.000 linhas para encontrar a lógica de retry que está se comportando diferentemente sob carga, o SLO está fazendo seu trabalho. A ferramenta para análise de causa raiz não está.

Equipes que instrumentalizaram busca de código assistida por IA junto à sua stack de observabilidade relatam significativamente menos tempo entre alerta e diagnóstico durante incidentes. Uma consulta em linguagem natural de onde o serviço de pagamento trata retries em respostas 503 surfar a função relevante em segundos em vez dos 20 minutos que demoram a ler cinco arquivos e uma página de Confluence. A janela de 43 minutos de error budget é gasta em consertar o problema, não em ler código.

Quatro Formas Como Equipes Erram Com SLOs

Muitos SLOs. Uma equipe rastreando 12 SLOs simultaneamente vai tratar alertas como ruído de fundo em dois meses. Três a cinco SLOs focados nos comportamentos mais visíveis para o usuário é um teto viável para uma equipe de 10 engenheiros. Se você precisa de mais, organize-os em tiers: SLOs críticos que disparam políticas de error budget, e SLOs informativos que apenas geram dados.

Medindo infraestrutura, não experiência do usuário. Utilização de CPU, uso de memória, e I/O de disco são sinais úteis de debug. São SLIs ruins a menos que você possa provar que correlacionam diretamente com degradação visível para o usuário. Meça o que o usuário experimenta: taxa de sucesso de requisição, tempo de resposta em P95 ou P99, tempo até renderizar o primeiro pedaço significativo de dados.

SLOs definidos sem análise de custo operacional. Alcançar 99,99% de disponibilidade tipicamente requer redundância ativa, failover multi-região, e resposta imediata on-call em qualquer hora. Se a equipe não consegue operacionalmente funcionar assim, o SLO vai ser violado regularmente e depois ignorado. Um SLO violado-e-ignorado é pior que nenhum SLO: treina a equipe a descartar alertas de confiabilidade.

Usar dados de error budget para atribuir culpa. Se a primeira resposta a um error budget consumido é identificar quem fez deploy da mudança que o causou, o reporting vai parar de ser honesto. Error budgets são um recurso da equipe. Quando o budget fica baixo, a pergunta é "o que a gente conserta?" não "quem é responsável?".

O teste de saúde organizacional: você compartilharia seu status atual de error budget em um all-hands de engenharia sem disparar uma discussão política? Se não, a cultura em volta de SLOs precisa de mais atenção que as metas em si. Métricas de confiabilidade funcionam como ferramentas de decisão apenas quando a equipe confia que reportar um problema não cria um risco pessoal.

SLOs Precisam de Revisões Trimestrais, Não Anuais

Definir um SLO não é uma calibração única. Serviços mudam, padrões de tráfego se deslocam, e o custo de manter um nível de confiabilidade dado muda com eles.

A cada 90 dias, rode através de quatro perguntas:

1. O SLO foi mantido? Se sim, foi confortável, sugerindo que a meta pode ser mais rigorosa?

2. O error budget foi totalmente consumido? Quais incidentes fizeram isso?

3. O SLO surfar sinal útil, ou a equipe sobrescreveu a política de error budget?

4. A janela de medição ainda é apropriada para como o serviço está sendo usado?

Se a equipe sobrescreveu a política de error budget mais que duas vezes em um trimestre, o SLO provavelmente está mal calibrado. Ou a meta é muito rigorosa, ou a janela é muito curta, ou a medição não está refletindo o que usuários realmente experimentam.

SLOs são ferramentas de calibração. Eles são feitos para serem ajustados conforme confiabilidade melhora, conforme tráfego cresce, e conforme o negócio muda sua tolerância para downtime. Uma equipe que revisa e ajusta seus SLOs trimestralmente está rodando uma prática de confiabilidade. Uma equipe que os definiu uma vez e não tocou desde tem um painel com números que significam nada para ninguém.