Se o seu time já tem dashboard, alerta e pager tocando, mas ainda discute confiabilidade no feeling, o problema não é falta de dado. É falta de critério. Quando a conversa chega em como definir SLI e SLO, muita empresa SaaS erra no ponto central: mede o que é fácil, não o que representa a experiência real do usuário.
SLI e SLO não servem para enfeitar postmortem nem para satisfazer auditoria interna. Servem para guiar decisão operacional. Servem para dizer, com objetividade, quando o sistema está saudável o suficiente e quando engenharia precisa parar de acelerar feature para pagar dívida de confiabilidade.
O que realmente muda quando você define SLI e SLO direito
SLI é indicador. SLO é meta. A diferença parece simples, mas o impacto prático é grande. O SLI mede um comportamento observável do sistema, como taxa de sucesso de requisições, latência p95 de um endpoint crítico ou tempo de processamento de um job essencial. O SLO define o alvo aceitável para esse indicador em um período.
O erro comum é tratar isso como exercício de observabilidade. Não é. SLI e SLO ficam no cruzamento entre arquitetura, produto e operação. Se o seu checkout responde em 400 ms no p50, mas explode no p99 em horário de pico, o problema de confiabilidade não aparece no número bonito da média. Se a API responde com 200, mas entrega payload quebrado ou atrasado demais para o caso de uso, o indicador também está mentindo.
Por isso, SLI bom é SLI que representa experiência real. E SLO bom é SLO que o time consegue sustentar sem entrar em guerra permanente com o próprio backlog.
Como definir SLI e SLO a partir da jornada crítica
O caminho mais seguro para entender como definir SLI e SLO começa fora da stack. Começa na jornada que gera valor para o negócio. Em SaaS, isso normalmente passa por login, navegação de tela principal, criação ou leitura de dados, integrações e rotinas assíncronas que o usuário espera ver refletidas no produto.
Se você começa pela ferramenta, vai escolher métrica errada. Se começa pela jornada, a chance de acerto sobe muito.
Primeiro, identifique as operações que realmente importam. Não todas. As críticas. Aquilo que, se falhar, gera ticket, churn, queda de conversão, atraso operacional ou perda de confiança. Em um produto B2B, por exemplo, salvar uma transação pode ser mais importante do que carregar um widget secundário no dashboard. Em uma plataforma orientada por API, latência de autenticação e taxa de sucesso em endpoints transacionais pesam mais do que uptime do serviço isolado.
Depois, traduza essas operações em sinais mensuráveis. Para cada jornada crítica, pergunte: o que define sucesso aqui? Pode ser disponibilidade, pode ser latência, pode ser corretude, pode ser atraso de processamento. Em muitos cenários, o SLI mais útil não é infraestrutura pura. É aplicação. Taxa de requests 2xx e 3xx em um endpoint chave, tempo até consistência de uma fila ou percentual de jobs concluídos dentro de uma janela aceitável dizem mais do que CPU, memória ou status de pod.
Só então faz sentido colocar uma meta. E aqui entra maturidade. SLO não é desejo. É compromisso operacional baseado em baseline real, impacto de negócio e capacidade do time.
O que vale medir, e o que quase sempre vira ruído
Latência, disponibilidade, taxa de erro e throughput continuam relevantes. Mas o problema está em como essas métricas são escolhidas e agregadas.
Média de latência quase sempre mascara problema. Prefira percentis, especialmente p95 e p99, quando o comportamento da cauda afeta usuário ou operação. Taxa de erro genérica também engana. Um 500 em endpoint administrativo tem peso diferente de erro em fluxo de pagamento, login ou emissão de documento.
Outro ponto crítico é não confundir sintoma técnico com resultado percebido. CPU alta não é SLI. Saturação de conexão em banco não é SLI. Isso é insumo para diagnóstico. O SLI precisa refletir aquilo que o usuário ou processo de negócio sente. Se a fila está crescendo, o indicador útil pode ser tempo até processamento efetivo, não o tamanho da fila em si.
Em sistemas distribuídos, vale evitar SLI que depende de um serviço isolado sem contexto. O usuário não consome microserviço. Consome jornada. Às vezes faz mais sentido medir o sucesso ponta a ponta de um fluxo via telemetria de aplicação do que tentar compor saúde a partir de dez serviços com comportamentos diferentes.
Como definir metas sem prometer o que a arquitetura não entrega
Aqui mora boa parte do fracasso. Time novo em SRE ou observabilidade costuma querer começar com 99,99%. Parece sofisticado. Na prática, pode ser irresponsável.
SLO precisa considerar quatro coisas ao mesmo tempo: expectativa do usuário, impacto de falha, baseline histórico e custo para sustentar o alvo. Se o sistema hoje opera em 99,2% de sucesso em horário comercial, declarar 99,95% sem investimento em arquitetura, instrumentação, runbooks, capacidade e regime de resposta é criar ficção.
Também existe o erro oposto. Metas folgadas demais normalizam experiência ruim. Se o seu produto depende de resposta rápida para operação do cliente, aceitar p95 de 3 segundos porque a média ficou boa não é pragmatismo. É tolerância com gargalo.
Um caminho melhor é definir metas por criticidade. Fluxos core merecem SLO mais agressivo. Funcionalidades acessórias podem operar com margem maior. Jobs assíncronos aceitam janela diferente de APIs síncronas. Backoffice não precisa ter o mesmo rigor de checkout. Nem todo componente merece o mesmo budget de confiabilidade.
Error budget não é jargão. É mecanismo de decisão.
Sem error budget, SLO vira número passivo em dashboard. Com error budget, ele passa a regular o ritmo entre estabilidade e entrega.
A lógica é simples. Se o SLO define o nível aceitável de falha, o error budget representa quanto de degradação ainda cabe no período. Quando o consumo acelera, o time tem sinal claro para reduzir risco: segurar deploy, revisar feature flag, atacar gargalo de banco, corrigir regressão, reavaliar autoscaling, endurecer teste de carga.
Isso muda a qualidade da conversa entre produto e engenharia. Em vez de debate abstrato sobre prudência, existe um indicador concreto dizendo se ainda há espaço para correr ou se a operação já entrou em zona de risco.
Mas isso só funciona se o SLO for crível. Budget baseado em meta arbitrária não ajuda ninguém.
Erros comuns ao definir SLI e SLO
O primeiro erro é medir disponibilidade só por uptime de infraestrutura. O load balancer pode estar de pé e o usuário continuar falhando por timeout, lock em banco, fila atrasada ou dependência externa degradada.
O segundo é criar indicadores demais. Quando tudo é prioridade, nada é prioridade. Comece com poucos SLIs de alto valor e expanda depois.
O terceiro é ignorar recortes. Um SLI agregado pode esconder desastre regional, problema em tenant grande ou degradação em operação mobile. Dependendo do produto, vale segmentar por rota crítica, região, plano ou operação.
O quarto é definir SLO sem observar histórico suficiente. Se você não conhece sazonalidade, picos e comportamento de cauda, a meta nasce torta.
O quinto é separar definição de meta da capacidade de reação. Não adianta ter SLO se não existe observabilidade decente, alertas acionáveis, ownership claro e processo para responder quando o número piora.
Uma abordagem prática para times SaaS
Em ambiente SaaS, a forma mais útil de começar costuma ser simples. Escolha de três a cinco jornadas críticas. Para cada uma, defina um SLI que represente sucesso percebido. Depois, use dados históricos para propor um SLO inicial conservador, mas honesto. Rode isso por algumas semanas. Observe consumo de budget, falsos positivos, pontos cegos e desalinhamento com suporte ou produto.
A partir daí, refine.
Talvez o endpoint certo não seja o mais chamado, e sim o que concentra receita. Talvez a latência relevante não esteja no gateway, e sim no tempo total entre evento recebido e dado disponível na tela. Talvez o seu grande problema não seja erro 5xx, e sim degradação silenciosa por retry excessivo e timeout em cascata.
Esse ajuste fino é o que separa um programa de confiabilidade útil de uma coleção de painéis bonitos. Na prática, como definir SLI e SLO bem feito exige convivência com a operação real. Exige olhar para incidentes, comportamento em pico, limites do banco, estratégia de cache, dependências terceiras e padrão de uso dos clientes.
É por isso que o trabalho sério aqui é menos sobre framework e mais sobre engenharia. A MGM Tech costuma ver o mesmo filme em empresas em crescimento: monitoramento existe, mas não há contrato claro de confiabilidade entre sistema, time e negócio. O resultado é previsível. Muito alerta, pouca clareza.
Se você quiser começar certo, não tente modelar o sistema inteiro de uma vez. Pegue o fluxo que acorda alguém de madrugada quando quebra. Meça o que o usuário sente. Defina uma meta que o time consiga defender em produção. E use esse número para tomar decisão de verdade. Quando SLI e SLO saem do PowerPoint e entram no deploy, a operação amadurece rápido.