SLI, SLO e SLA: diferenças, exemplos e como definir metas de confiabilidade

SLI, SLO e SLA descrevem partes diferentes da confiabilidade de um serviço. SLI é a medição do que os usuários recebem; SLO é a meta interna para essa medição; SLA é o compromisso formal assumido com clientes. Uma API pode medir a proporção de respostas corretas em até 400 milissegundos, definir uma meta mensal de 99,9% e oferecer em contrato um nível menor, com regras e compensações próprias.

Separar os três conceitos evita metas impossíveis e alertas sem utilidade. Também permite decidir quando investir em disponibilidade, quando desacelerar mudanças e quando a operação está perto de descumprir um compromisso externo.

Diferença entre SLI, SLO e SLA

O SLI precisa existir antes que o SLO possa ser acompanhado. O SLA pode usar medidas semelhantes, mas inclui escopo, exclusões, responsabilidades, suporte, método de cálculo e consequências comerciais ou jurídicas. Por isso, copiar o percentual de um SLA de nuvem e adotá-lo como meta interna não descreve a confiabilidade do sistema completo.

A orientação de confiabilidade da Microsoft distingue o SLO como objetivo da carga de trabalho e o SLA como contrato formal. O SLA do provedor é uma entrada para o desenho, não a meta automática do produto que depende dele.

O SLI deve representar a experiência do usuário

Um indicador útil mede eventos bons em relação ao total de eventos válidos. Na disponibilidade de uma API, o numerador pode ser o número de requisições concluídas corretamente e o denominador, todas as requisições elegíveis. Na latência, o numerador pode contar chamadas abaixo do limite e o denominador continuar sendo o total.

O Google SRE Workbook recomenda partir das interações importantes para os usuários. Os tipos comuns incluem:

• disponibilidade: requisições que terminaram com resultado válido;
• latência: requisições concluídas abaixo de um limite;
• qualidade: respostas entregues sem degradação;
• atualização: dados mais recentes que uma idade máxima;
• correção: resultados que correspondem ao comportamento esperado;
• cobertura: registros ou tarefas processados dentro do escopo;
• durabilidade: dados gravados que continuam recuperáveis.

Métricas de infraestrutura ajudam a diagnosticar problemas, mas raramente são SLIs completos. CPU em 80%, fila com mil itens ou uso de memória não dizem, sozinhos, se o usuário concluiu a tarefa. O post sobre observabilidade para APIs pequenas explica como métricas, logs e rastros apoiam essa investigação sem substituir o resultado percebido.

Especificação e implementação são decisões separadas

A especificação do SLI declara o que significa serviço bom. A implementação define como isso será medido. Para uma página, a especificação pode ser “carregar em menos de dois segundos”. A implementação pode usar logs do servidor, um teste externo ou instrumentação no navegador.

Cada fonte enxerga uma parte. O servidor não registra pedidos que não chegaram até ele. Um teste externo cobre a rota escolhida, mas pode não representar todos os usuários. A instrumentação do cliente observa a experiência real, porém depende de código e coleta próprios. A decisão deve registrar cobertura, precisão, custo e lacunas.

Também é preciso definir quais eventos entram no denominador. Requisições canceladas pelo cliente, tráfego de robôs, rotas administrativas e erros causados por entrada inválida podem exigir tratamento específico. Excluir eventos depois de um incidente para melhorar o percentual destrói a comparabilidade; a política deve existir antes da apuração.

O SLO combina indicador, meta e período

Um SLO completo informa qual SLI será usado, qual percentual deve ser atingido e em qual período. “A API precisa ser rápida” não é um objetivo verificável. “Em uma janela móvel de 30 dias, 99% das requisições válidas devem terminar abaixo de 400 ms” pode ser medido.

A documentação do Google Cloud diferencia SLOs baseados em requisições e em janelas. No primeiro caso, cada chamada conta como evento bom ou ruim. No segundo, cada intervalo de tempo é classificado, por exemplo, como dez minutos bons quando ao menos 95% das chamadas ficaram abaixo do limite.

O período pode seguir o calendário ou uma janela móvel. Um mês de calendário combina com ciclos de faturamento e relatórios fechados. Uma janela móvel mostra continuamente os últimos dias, mas pode entrar e sair de conformidade quando eventos antigos deixam a amostra.

Uma meta de 100% elimina o orçamento de erro

Se o SLO for 99,9%, o orçamento de erro é 0,1% dos eventos elegíveis ou do tempo medido. Com dez milhões de requisições no período, até dez mil podem ficar fora do critério antes da violação. Em um SLO estritamente baseado em tempo, 99,9% de 30 dias deixa cerca de 43 minutos e 12 segundos fora da meta.

Os dois cálculos não são intercambiáveis. Uma interrupção em horário de pouco tráfego pesa pouco em um SLO por requisição e o mesmo que qualquer minuto em um SLO por tempo. A escolha depende de como os usuários sofrem o impacto.

O Google SRE desaconselha 100% como alvo padrão porque qualquer falha consome todo o orçamento e toda mudança adiciona risco. Quanto mais “noves” forem exigidos, maior tende a ser o custo de redundância, teste, operação e resposta. O objetivo deve ficar no nível que protege a experiência relevante, não no maior número que cabe em uma apresentação.

O orçamento de erro orienta decisões

O orçamento restante transforma confiabilidade em uma restrição operacional. Quando o serviço permanece dentro do SLO, a equipe pode lançar mudanças assumindo risco controlado. Quando o orçamento cai rapidamente, reduzir implantações, corrigir a causa e melhorar proteção passa a ter prioridade.

A taxa de consumo, ou burn rate, mostra quão depressa o orçamento está sendo gasto em relação ao ritmo sustentável. Alertas de consumo rápido detectam incidentes intensos; alertas lentos identificam degradação acumulada. Alertar apenas quando o SLO já foi violado chega tarde para evitar o problema.

Essa política precisa ser acordada por engenharia e produto. Um painel sem consequências vira apenas outro KPI. A organização deve definir quem pode pausar lançamentos, quais exceções são aceitas e quando o objetivo será revisto.

SLA inclui mais que um percentual

Um SLA normalmente descreve o serviço coberto, o período de medição, os dados usados, as exclusões, o processo de solicitação e as consequências do descumprimento. Manutenção programada, erro do cliente ou componentes fora do controle contratado podem aparecer como exclusões.

O percentual contratado deve ser interpretado com sua fórmula. Um provedor pode calcular disponibilidade por recurso, região ou mês, enquanto o produto depende de vários serviços em série. Se qualquer dependência crítica falhar, a disponibilidade percebida pelo usuário pode ser menor que o número individual de cada fornecedor.

O SLO interno costuma ser mais exigente que o compromisso externo. Essa margem permite reagir antes que uma degradação se transforme em violação contratual. A diferença não deve ser tão grande a ponto de consumir recursos sem benefício observável.

Dependências mudam a meta do serviço completo

Um produto raramente depende de um único componente. Aplicação, banco de dados, provedor de identidade, fila, rede e serviço externo formam uma cadeia. Mesmo que cada parte anuncie alta disponibilidade, o conjunto não herda automaticamente o melhor percentual.

Em uma dependência em série, a jornada falha quando qualquer peça crítica fica indisponível. Duas dependências com 99,9% de disponibilidade, se independentes e necessárias ao mesmo tempo, resultam em aproximadamente 99,8% para a combinação. A conta real pode ser diferente porque falhas são correlacionadas, existem redundâncias e nem toda indisponibilidade afeta a mesma jornada.

Por isso, o SLI deve medir o resultado do produto na fronteira do usuário. SLAs dos fornecedores ajudam a modelar risco e contratos, mas não substituem a medição ponta a ponta. Quando uma dependência não consegue sustentar o objetivo, as opções incluem redundância, degradação controlada, cache, fila, mudança do fluxo ou renegociação da meta.

O desenho também precisa separar jornadas. Autenticar, concluir pagamento e abrir uma página de ajuda podem ter dependências e impactos distintos. Um único percentual agregado permite que grande volume de operações simples esconda a falha de uma função crítica com pouco tráfego.

Exemplo para uma API de pedidos

Considere uma API usada para criar e consultar pedidos. As jornadas críticas são registrar o pedido sem duplicidade e recuperar seu estado. A equipe escolhe dois SLIs:

1. disponibilidade: pedidos válidos processados corretamente divididos pelo total de pedidos válidos;
2. latência: consultas válidas concluídas em até 500 ms divididas pelo total de consultas válidas.

Os SLOs podem ser 99,95% de disponibilidade e 99% de latência em 30 dias. A disponibilidade recebe meta maior porque perder a criação de um pedido tem impacto mais grave que uma consulta ocasionalmente lenta. Um SLA comercial pode assumir 99,9% de disponibilidade, medido por mês, com regras específicas de crédito.

Os alertas operacionais acompanham consumo do orçamento, não apenas CPU ou média de latência. Uma falha curta que rejeita muitos pedidos pode consumir mais orçamento que horas de resposta um pouco mais lenta. O painel deve permitir chegar dos eventos ruins aos logs e rastros correspondentes.

Como definir o primeiro conjunto de objetivos

Comece com um serviço e poucas jornadas críticas. O Google SRE recomenda um conjunto pequeno de tipos de SLI, normalmente até cinco, que represente as funções mais importantes. Um caminho inicial é:

1. identificar usuários e tarefas críticas;
2. definir o que torna cada evento bom ou ruim;
3. escolher a fonte de medição mais próxima do usuário disponível agora;
4. estabelecer meta e período com produto e operação;
5. registrar a política de orçamento de erro e revisar os dados periodicamente.

O primeiro SLO pode ser imperfeito. A equipe deve conseguir explicar a lacuna e manter um processo de melhoria. Começar com logs existentes pode ser melhor que esperar meses por instrumentação ideal, desde que a limitação fique registrada.

Antes de formalizar um número, observe desempenho histórico, impacto para o usuário, custo de melhoria e dependências. Usar apenas a média atual pode criar um objetivo rígido demais; ignorar o histórico pode definir uma meta que o sistema nunca atingiu.

Erros comuns ao trabalhar com níveis de serviço

Medir somente disponibilidade pode esconder respostas incorretas, dados antigos e degradação severa. Usar média de latência esconde a cauda; percentis ou proporção abaixo de um limite representam melhor os casos lentos. Somar métricas sem relação com a jornada produz um painel amplo, mas não um SLI.

Outro erro é criar SLO sem responsável ou consequência. Quando o orçamento acaba e nada muda, o objetivo não orienta decisão. Alertas por cada falha individual também geram ruído; o sistema precisa detectar risco para o objetivo antes que a equipe ignore as notificações.

Por fim, SLO não substitui diagnóstico. Ele informa que a experiência saiu da meta. Logs, rastros, métricas de componentes e testes ajudam a localizar a causa. O artigo sobre Kubernetes, Docker e observabilidade mostra como esses sinais se complementam em APIs.

Checklist para revisar um objetivo

Antes de adotar um SLO, confirme que o documento identifica usuário, jornada, SLI, fonte dos dados, eventos excluídos, percentual, período e responsável. A fórmula deve produzir o mesmo resultado quando executada por pessoas diferentes.

Verifique também se existe histórico suficiente para comparar a meta, se alertas acompanham consumo rápido e lento do orçamento e se há uma ação definida quando o limite se aproxima. Para um SLA, acrescente escopo contratual, método de apuração, exceções, evidências aceitas e consequências.

Revise os objetivos depois de mudanças relevantes de arquitetura ou produto. Uma nova dependência, uma função crítica ou outro padrão de tráfego pode tornar o SLI antigo incompleto mesmo quando o painel continua calculando normalmente.

Um conjunto útil de SLI, SLO e SLA liga medição, decisão e compromisso. O SLI observa o serviço entregue, o SLO define a meta que orienta a operação e o SLA formaliza obrigações externas. A implementação deve começar pelas jornadas do usuário, manter poucos indicadores verificáveis e associar o orçamento de erro a ações previamente acordadas.