O que são SLOs e por que “confiabilidade percebida” importa
SLO (Service Level Objective) é um objetivo mensurável para o nível de serviço que um sistema deve entregar. Ele transforma a ideia genérica de “ser confiável” em um alvo operacional com números, janela de tempo e método de medição. Quando o SLO é bem definido, ele orienta decisões de engenharia, priorização de backlog, gestão de incidentes e até negociações com áreas de negócio.
O ponto central deste capítulo é que confiabilidade não é apenas “o sistema não cair”. Para o usuário, confiabilidade é percebida como a capacidade de completar uma tarefa com sucesso, no tempo esperado, sem erros e com comportamento consistente. Um serviço pode estar “no ar” (uptime alto) e ainda assim ser percebido como ruim se estiver lento, se falhar em fluxos críticos (login, pagamento, busca), se apresentar erros intermitentes ou se degradar em horários de pico.
Por isso, SLOs modernos evitam métricas puramente internas (CPU, memória, filas) como objetivo final. Elas continuam úteis para diagnóstico, mas o SLO deve se ancorar em sinais que representem a experiência real do usuário: sucesso de requisições, latência percebida, taxa de erro em jornadas críticas e disponibilidade de funcionalidades essenciais.
SLI, SLO e SLA: termos que não podem se confundir
SLI (Service Level Indicator)
SLI é o indicador medido. Exemplos: “percentual de requisições HTTP 2xx/3xx”, “p95 de latência do endpoint /checkout”, “taxa de sucesso do fluxo de login”, “tempo para renderizar a página inicial no navegador”. O SLI precisa de uma definição exata: fonte de dados, filtro, agregação e janela.
SLO (Service Level Objective)
SLO é o alvo para um SLI em uma janela de tempo. Exemplo: “99,9% de sucesso no checkout em 28 dias” ou “p95 de latência < 400 ms para /search em 7 dias”. O SLO deve ser realista e alinhado ao impacto do serviço.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
SLA (Service Level Agreement)
SLA é um acordo formal (geralmente com implicações contratuais) que pode incluir multas, créditos ou cláusulas. Um erro comum é definir SLOs como se fossem SLAs: isso tende a gerar metas rígidas demais, que não deixam margem para evolução e aprendizado. Em geral, equipes usam SLOs internamente para operar e melhorar; SLAs são uma camada externa, mais conservadora.
Confiabilidade percebida pelo usuário: como traduzir experiência em números
“Percepção” parece subjetiva, mas pode ser aproximada por sinais observáveis do que o usuário tenta fazer. A pergunta prática é: quais interações representam valor e onde o usuário sente falha?
Dimensões comuns da confiabilidade percebida
Disponibilidade funcional: o usuário consegue executar a função? Ex.: “conseguir pagar”, “conseguir autenticar”, “conseguir buscar”.
Correção: o resultado está correto? Ex.: preço calculado corretamente, carrinho consistente, dados atualizados.
Desempenho percebido: o tempo de resposta é aceitável. Latência alta é percebida como falha, mesmo sem erro explícito.
Consistência: falhas intermitentes geram desconfiança. Um fluxo que funciona 9 vezes e falha 1 vez pode ser pior, na percepção, do que um fluxo que falha sempre (porque o usuário não sabe quando confiar).
Degradação graciosa: quando algo falha, o sistema mantém o essencial? Ex.: permitir navegação e salvar carrinho mesmo se recomendações estiverem fora.
Indicadores que aproximam a experiência do usuário
Taxa de sucesso de jornada (task success rate): percentual de sessões que completam um objetivo (ex.: finalizar compra) sem erro.
Apdex: mede satisfação com base em limites de latência (satisfeito/tolerável/frustrado). Útil quando a percepção de “rápido” é mais importante do que um percentil específico.
Web Vitals / métricas de front-end: LCP, INP, CLS (para aplicações web). Representam o que o usuário vê e sente, não apenas o tempo do backend.
Erros no cliente: falhas JavaScript, crashes em mobile, timeouts no navegador, falhas de renderização.
Disponibilidade por recurso crítico: em vez de “site disponível”, medir “checkout disponível”, “login disponível”, “API de catálogo disponível”.
Escolhendo SLOs: o que medir primeiro (e o que evitar)
Um SLO bom é aquele que direciona comportamento. Se a meta não muda decisões, ela vira burocracia. Para confiabilidade percebida, priorize SLOs que representem fluxos críticos e que tenham relação direta com impacto no usuário.
Comece pelos “user journeys” críticos
Liste as 3 a 7 jornadas que sustentam o valor do produto. Exemplos para um e-commerce:
Carregar página inicial e navegar categorias
Buscar produto
Adicionar ao carrinho
Login/cadastro
Checkout/pagamento
Para cada jornada, identifique o ponto de falha mais comum e o ponto de maior impacto. Nem tudo precisa de SLO no início; escolha o que mais afeta receita, retenção ou confiança.
Evite SLOs baseados apenas em infraestrutura
“CPU abaixo de 70%” ou “fila com menos de 1000 mensagens” pode ser útil como alerta, mas não é SLO de confiabilidade percebida. O usuário não se importa com CPU; ele se importa se a compra conclui e se a página responde rápido.
Evite metas que incentivem manipulação
Exemplos de armadilhas:
Excluir tráfego difícil: medir apenas clientes “premium” ou apenas uma região para “melhorar” o número.
Ignorar erros no cliente: backend 99,99% mas front-end quebrando em navegadores específicos.
Definir janela curta demais: “99,9% por hora” pode gerar ruído e decisões reativas; janelas de 7, 14 ou 28 dias costumam ser mais úteis para SLO.
Passo a passo prático para definir SLOs de confiabilidade percebida
Passo 1: Defina o “serviço” e o escopo do SLO
Especifique claramente o que está sendo medido. Exemplo: “Fluxo de checkout do site web (front-end + APIs de pagamento + cálculo de frete)”. Se o escopo for amplo demais, o SLO vira difícil de diagnosticar; se for estreito demais, perde relação com a experiência.
Passo 2: Escolha o SLI mais próximo da tarefa do usuário
Para confiabilidade percebida, SLIs típicos:
Taxa de sucesso: sucesso/total de tentativas do fluxo.
Latência: p95 ou p99 do tempo de resposta (ou tempo total de jornada).
Apdex: proporção de sessões satisfeitas/toleráveis.
Exemplo de SLI de checkout (taxa de sucesso): “Percentual de tentativas de finalizar compra que resultam em pedido criado com status ‘pago’ ou ‘aprovado’”.
Passo 3: Defina “bom” vs “ruim” com critérios objetivos
Escreva regras de inclusão/exclusão:
O que conta como tentativa? (ex.: clique no botão “Finalizar” com carrinho válido)
O que conta como sucesso? (ex.: pedido criado e confirmação exibida ao usuário)
O que conta como falha? (ex.: timeout, erro 5xx, erro de validação inesperado, falha no gateway)
Como tratar cancelamentos voluntários? (ex.: usuário fecha a aba)
Sem isso, o SLI vira discutível e perde credibilidade.
Passo 4: Escolha a janela de medição
Janelas comuns: 7, 14 ou 28 dias. Para confiabilidade percebida, 28 dias costuma equilibrar estabilidade e sensibilidade. Se o produto tem picos semanais (ex.: promoções), 28 dias captura melhor a variabilidade.
Passo 5: Defina o alvo (SLO) com base em impacto e capacidade
O alvo deve refletir o quanto de falha é aceitável sem comprometer a confiança do usuário. Um fluxo de pagamento geralmente exige um SLO mais alto do que uma área de recomendações.
Exemplos:
Checkout: 99,9% de sucesso em 28 dias
Busca: 99,5% de sucesso em 28 dias e p95 < 500 ms
Página inicial: Apdex ≥ 0,90 em 28 dias
Evite “100%”. Além de irrealista, impede a gestão saudável de trade-offs.
Passo 6: Calcule e comunique o orçamento de erro (error budget)
O orçamento de erro é a quantidade de falha permitida pela meta. Ele torna o SLO acionável: se o orçamento está sendo consumido rápido, a prioridade muda.
Exemplo: SLO de 99,9% em 28 dias permite 0,1% de falhas. Se houver 2.000.000 tentativas de checkout no período, o orçamento é 2.000 falhas.
total_tentativas = 2_000_000
slo = 0.999
falhas_permitidas = total_tentativas * (1 - slo)
# falhas_permitidas = 2000Para latência, o orçamento pode ser “percentual de requisições acima do limite”. Ex.: “p95 < 500 ms” pode ser traduzido em “no máximo 5% acima de 500 ms” (dependendo do método de medição), mas é importante definir exatamente como será calculado.
Passo 7: Instrumente a coleta com foco no usuário
Fontes típicas:
RUM (Real User Monitoring): mede experiência real no navegador/app (tempos de carregamento, erros no cliente, interações).
Sintéticos: robôs que executam fluxos (login, busca, checkout) em intervalos regulares. Útil para detectar indisponibilidade mesmo com baixo tráfego real.
Logs e traces: para medir sucesso/erro e latência no backend, correlacionando com IDs de sessão ou de jornada.
Uma prática eficaz é criar um “evento de jornada” no front-end (ex.: checkout_started, payment_submitted, order_confirmed) e correlacionar com eventos do backend. Assim, o SLI reflete o que o usuário tentou fazer, não apenas o que a API respondeu.
Passo 8: Defina alertas orientados a SLO (não apenas a picos)
Alertas baseados em SLO reduzem ruído e focam no risco real de violar a meta. Em vez de alertar “erro 5xx > 1% por 5 minutos” para tudo, você pode alertar quando a taxa de consumo do orçamento de erro indica que o SLO será estourado se continuar.
Exemplo conceitual: “se a queima do orçamento nas últimas 2 horas for alta o suficiente para consumir o orçamento mensal em poucos dias, alertar”. Isso prioriza incidentes que ameaçam a experiência de forma relevante.
Passo 9: Use o orçamento de erro para governar mudanças
O orçamento de erro conecta confiabilidade a decisões de entrega. Um modelo simples:
Se o orçamento está saudável: manter ritmo normal de releases e experimentos.
Se o orçamento está se esgotando: reduzir mudanças arriscadas, aumentar revisão, focar em correções e estabilização.
Se o orçamento estourou: pausar mudanças não essenciais e executar plano de recuperação (correções, capacidade, mitigação).
O objetivo não é punir times, e sim tornar explícito o trade-off entre velocidade e confiabilidade percebida.
Exemplos completos de SLOs orientados ao usuário
Exemplo 1: SLO de sucesso de checkout (jornada)
Serviço: Jornada de checkout web (do clique em “Finalizar” até a confirmação do pedido).
SLI: Taxa de sucesso de checkout = pedidos confirmados / tentativas de checkout.
Janela: 28 dias.
SLO: ≥ 99,9%.
Definições operacionais:
Tentativa: evento checkout_started com carrinho válido.
Sucesso: evento order_confirmed exibido ao usuário + pedido em estado aprovado.
Falha: timeout, erro 5xx, erro de integração com pagamento, inconsistência de estoque após submissão.
Observação de percepção: se o backend cria o pedido, mas o front-end não exibe confirmação por erro de renderização, o usuário percebe falha. Por isso, o sucesso deve incluir o sinal do cliente (RUM/evento).
Exemplo 2: SLO de latência percebida na busca
Serviço: Busca de produtos no site.
SLI: p95 do tempo “digitar e ver resultados” (medido no navegador).
Janela: 14 dias.
SLO: p95 ≤ 700 ms.
Como medir:
Início: evento de submissão da busca (enter/click).
Fim: primeiro render dos resultados (DOM atualizado).
Segmentação: por tipo de dispositivo e região (sem excluir segmentos problemáticos; use segmentação para diagnóstico).
Por que p95: o usuário lembra dos casos ruins. p50 pode parecer ótimo enquanto uma parcela relevante sofre lentidão.
Exemplo 3: SLO de estabilidade do app mobile (crash-free sessions)
Serviço: Aplicativo mobile (iOS/Android).
SLI: Percentual de sessões sem crash.
Janela: 28 dias.
SLO: ≥ 99,8% crash-free sessions.
Detalhes:
Separar por versão do app: um release ruim pode degradar a percepção rapidamente.
Correlacionar com fluxos: crashes em “pagamento” têm peso maior do que em “perfil”. Você pode criar SLOs adicionais por fluxo crítico.
Como lidar com segmentação sem “maquiar” a experiência
Usuários diferentes têm experiências diferentes: regiões com latência maior, dispositivos antigos, redes móveis instáveis. A segmentação é essencial para entender percepção, mas pode ser usada de forma indevida para esconder problemas.
Boas práticas
SLO global + painéis segmentados: mantenha um SLO principal que represente a experiência geral e use segmentação para diagnóstico.
SLOs por tier de criticidade: se há clientes enterprise com requisitos específicos, defina SLOs separados e explícitos, em vez de “filtrar” o SLI.
Defina população medida: por exemplo, “todas as sessões autenticadas” ou “todas as requisições do endpoint X”. Seja transparente.
Erros comuns ao implementar SLOs de confiabilidade percebida
1) Medir apenas disponibilidade (uptime) e chamar de confiabilidade
Um site pode responder 200 OK e ainda assim estar inutilizável (página em branco, erro de script, conteúdo não carregando). Inclua sinais do cliente e sucesso de jornada.
2) Definir SLO sem capacidade de medir corretamente
Se você não consegue medir tentativas e sucessos de forma consistente, o SLO vira disputa. Antes de publicar o SLO, valide a instrumentação com testes e amostras de logs.
3) Misturar falhas esperadas com falhas do sistema
Exemplo: “pagamento recusado” pode ser um resultado válido (cartão sem limite) e não necessariamente falha de confiabilidade. Diferencie “erro de negócio esperado” de “erro técnico”. Caso contrário, o SLI fica distorcido e a equipe corre atrás do que não controla.
4) SLOs demais, sem hierarquia
Muitos SLOs geram confusão e alertas excessivos. Comece com poucos, ligados a jornadas críticas, e expanda conforme maturidade.
5) Não conectar SLO a ações
Se violar o SLO não muda priorização, ele vira um número decorativo. Defina antecipadamente o que acontece quando o orçamento de erro está em risco: revisão de mudanças, foco em correções, ajustes de capacidade, mitigação de dependências.
Checklist prático para publicar um SLO orientado ao usuário
O SLI representa uma tarefa do usuário (jornada) ou um resultado percebido (latência, sucesso, crash-free)?
As definições de tentativa, sucesso e falha estão escritas e testadas?
A fonte de dados é confiável (RUM/sintético/logs) e tem cobertura suficiente?
A janela (7/14/28 dias) faz sentido para o padrão de uso e sazonalidade?
O SLO tem alvo realista e alinhado ao impacto?
O orçamento de erro foi calculado e está visível em dashboard?
Existem alertas orientados a consumo do orçamento (e não apenas thresholds arbitrários)?
Há um acordo explícito sobre ações quando o orçamento está saudável vs em risco?
