"Nosso uptime é 99,9%." Essa frase, sozinha, não informa nada. Noventa e nove vírgula nove por cento medido onde? Contando o que como falha? Numa janela de qual tamanho? É perfeitamente possível ter um painel verde exibindo 99,9% enquanto metade dos clientes não consegue finalizar uma compra — basta medir a coisa errada, no lugar errado. SLO bem feito serve para decidir; SLO mal feito é decoração com aparência de rigor.

Os três conceitos, sem mistério

SLI é o indicador: uma medição da qualidade do serviço do ponto de vista de quem usa. Não é uso de CPU nem memória livre — é "proporção de requisições atendidas com sucesso" ou "proporção de requisições respondidas abaixo de 300 ms".

SLO é a meta para aquele indicador em uma janela de tempo. Por exemplo: 99,9% das requisições com sucesso, medido em 30 dias corridos.

Error budget é o complemento da meta. Se o objetivo é 99,9%, você tem 0,1% de falhas permitidas na janela. Isso não é uma tolerância a ser escondida: é um orçamento a ser gasto, deliberadamente, em mudança e risco.

Esse terceiro conceito é o que transforma o exercício em ferramenta de decisão. Sem ele, SLO é só um número num painel.

O SLI tem que medir a experiência, não o componente

O erro fundador da maioria das implantações é medir o que é fácil em vez do que importa. "O servidor responde" é fácil de medir e diz pouco. Um servidor que responde erro 500 rapidamente está "no ar" e completamente inútil.

Perguntas que levam a bons indicadores:

• A requisição foi atendida com sucesso? Proporção de respostas boas sobre o total. Cuidado ao classificar: erro causado pelo cliente normalmente não conta contra você, mas erro do servidor conta sempre.
• Foi rápido o suficiente? Proporção de requisições abaixo de um limite definido.
• O dado está atualizado? Para processamento assíncrono, atraso da fila importa mais que disponibilidade.
• O resultado está correto? Para relatórios e cálculos, resposta rápida e errada é pior que lenta e certa.

E, principalmente, meça por jornada de usuário, não por microsserviço. "Concluir checkout" é um SLI útil. "Disponibilidade do serviço de autenticação" é diagnóstico — importante, mas não é a meta.

Percentil, nunca média

Latência média é a métrica mais enganosa em uso. Se noventa requisições respondem em 50 ms e dez em 5 segundos, a média fica em torno de 545 ms — um número que não descreve a experiência de ninguém. As noventa foram rápidas, as dez foram inaceitáveis, e a média esconde as duas realidades.

Use percentis. O percentil 95 e o 99 mostram o que a cauda de usuários sente, e é a cauda que abre chamado e cancela contrato.

Melhor ainda é abandonar a pergunta "qual é a latência?" e adotar a formulação de proporção: "qual percentual de requisições respondeu abaixo de 300 ms?". Isso se combina naturalmente com error budget e com disponibilidade, porque as duas passam a ser contagens de eventos bons sobre eventos totais.

Onde medir muda o resultado

O mesmo serviço apresenta números bem diferentes conforme o ponto de medição:

• Dentro da aplicação você não vê o que nunca chegou. Se o balanceador está fora, a aplicação registra 100% de sucesso das requisições que recebeu — que são zero.
• No balanceador ou no gateway é o melhor ponto para a maioria dos casos: vê tudo que entrou, inclusive o que a aplicação recusou.
• No cliente, com telemetria do navegador ou do aplicativo, é o mais fiel à experiência real, incluindo rede e carregamento.

A regra prática: meça o mais próximo possível do usuário que você conseguir sustentar. E some monitoramento sintético — uma verificação externa que executa a jornada principal periodicamente — para não depender apenas de tráfego real na hora de detectar uma indisponibilidade total.

Escolha a meta pelo custo, não pela vaidade

Cada casa decimal a mais custa desproporcionalmente mais. Ir de 99,9% para 99,99% não é 10% de esforço adicional: costuma exigir redundância em todas as camadas, implantação sem parada e automação de recuperação — um projeto de arquitetura, não um ajuste.

Duas consequências práticas. Primeiro: 99,99% em serviço que depende de um único banco de dados é promessa impossível, e vale dizer isso antes de assinar. Segundo: a meta certa é a mais baixa que os clientes não reclamam. Confiabilidade acima disso é dinheiro gasto sem retorno percebido, que poderia estar em funcionalidade.

Meta interna mais rígida que a contratual

SLA é compromisso contratual, com consequência financeira. SLO é meta interna de engenharia. Eles não devem ser iguais.

Mantenha o SLO mais rígido que o SLA. Se o contrato promete 99,5%, opere com meta interna de 99,9%. A diferença é a margem que permite descobrir a degradação e agir antes de descumprir o contrato. Metas idênticas significam que, no instante em que você percebe o problema, já está em multa.

Gastar o error budget é o objetivo

Aqui está a parte que a maioria das implantações não faz, e sem ela nada muda na prática.

Error budget é orçamento. Se sobrou muito no fim do mês, você foi conservador demais: podia ter entregado mais, implantado com mais frequência, assumido mais risco. Se acabou antes do fim, o sinal é claro na direção oposta.

Isso exige uma política acordada antes, que responda: o que acontece quando o orçamento acaba? A resposta que funciona é concreta — prioridade passa para trabalho de confiabilidade até o orçamento se recompor, com novas funcionalidades pausadas. Sem essa combinação prévia, o orçamento estourado gera uma conversa desconfortável e nenhuma mudança de comportamento, e o SLO perde autoridade para sempre.

O ganho maior é político: a discussão entre "entregar mais rápido" e "estabilizar" deixa de ser uma disputa de opinião entre produto e engenharia e passa a ser consulta a um número que ambos aceitaram antes.

Alerte pela taxa de consumo

Alertar a cada violação pontual do SLI produz ruído. Alertar só quando o orçamento acabou produz aviso tarde demais.

O caminho é alertar pela velocidade de consumo do orçamento. Duas janelas resolvem bem: uma curta e agressiva, que dispara quando o consumo está muito acelerado — algo que consumiria o mês em poucas horas — e uma longa e mais tolerante, que detecta a degradação lenta e persistente que ninguém nota.

Esse esquema tem uma propriedade valiosa: ele ignora falhas irrelevantes e reage a problemas reais, o que devolve credibilidade ao canal de alertas.

Comece com um, não com trinta

Painel com quarenta SLOs é teatro. Ninguém olha, ninguém age, e todos ganham a impressão de que confiabilidade está sendo cuidada.

Um começo honesto:

1. Escolha a jornada de usuário mais importante — a que, se falhar, gera perda de receita ou de confiança.
2. Defina dois SLIs para ela: sucesso e latência.
3. Estabeleça metas baseadas no comportamento atual, não no desejado. Meça um mês antes de prometer.
4. Combine a política de error budget com produto e engenharia, por escrito.
5. Implante alerta por taxa de consumo e desligue os alertas antigos que ninguém atende.
6. Só depois acrescente a segunda jornada.

Erros comuns

• Medir "o servidor responde" em vez da experiência do usuário.
• Usar latência média em vez de percentil ou proporção.
• Medir dentro da aplicação e não ver o que nunca chegou.
• Meta de 100%, que não deixa orçamento para mudança nenhuma.
• SLO idêntico ao SLA, sem margem para agir antes da multa.
• Prometer 99,99% com um único banco de dados no caminho.
• Nenhuma política sobre o que fazer quando o orçamento acaba.
• Alertar a cada violação pontual, treinando a equipe a ignorar.
• Dezenas de SLOs, nenhum com dono.

Onde a Solvefy/Cloud entra

Em consultoria DevOps, ajudamos a sair do painel decorativo para um número que decide. Definimos as jornadas que importam, escolhemos os indicadores e o ponto de medição, calibramos as metas a partir do comportamento real do seu sistema e implantamos o alerta por taxa de consumo. E facilitamos a conversa que sustenta tudo: a política de error budget acordada entre produto e engenharia — sem ela, o resto é gráfico bonito.

Quer medir confiabilidade de um jeito que gere decisão? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.