# O que é SLO? Guia prático para equipes de plataforma URL: https://upstreamapi.com/pt/journal/o-que-e-slo Type: blog Locale: pt Published: 2026-10-31 Updated: 2026-11-01 --- > O que é SLO na prática: SLI, SLO e SLA, a aritmética dos noves, error budgets, alertas por burn rate e como usar a meta para travar rollouts ruins. O que é SLO? Um service level objective (objetivo de nível de serviço) é a meta de confiabilidade de um comportamento específico, visto pelo usuário, medido em uma janela de tempo fixa. "99.9% das requisições de checkout respondem com sucesso em menos de 800 ms, em 30 dias" é um SLO. "O site deveria ser rápido" é um desejo. O número importa menos do que aquilo que ele controla: o SLO decide quando você continua entregando e quando para. São 03:12. O PagerDuty avisa que a latência do checkout está "elevada". Você abre o dashboard e vê uma linha de p99 que subiu por quarenta minutos. Ninguém consegue dizer se isso é um problema, porque ninguém nunca escreveu quanta latência é demais. A discussão que vem depois, numa chamada, com um olho no Slack, é o custo de não ter um SLO. ![Celular iluminado sobre a mesa de cabeceira à noite durante um alerta de plantão](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/da5f84-i1.webp) ## SLI, SLO e SLA: três palavras, três donos Muita gente usa esses termos como sinônimos. Não são a mesma coisa, e misturá-los é como equipes acabam com um contrato que não conseguem cumprir. - **SLI (service level indicator)** é a medição. É uma razão entre eventos bons e eventos válidos: requisições que retornaram 2xx em menos de 800 ms, divididas por todas as requisições que deveriam ter sido atendidas. - **SLO (service level objective)** é a meta para essa razão numa janela de tempo. 99.9% em 30 dias. - **SLA (service level agreement)** é o contrato com o cliente, com dinheiro envolvido se você não cumprir. Ele é sempre mais frouxo que o SLO. Se o seu SLA diz 99.9% e o seu SLO também diz 99.9%, você não tem margem para perceber um problema antes de dever créditos. O [capítulo do livro do Google SRE sobre objetivos de nível de serviço](https://sre.google/sre-book/service-level-objectives/) traça a mesma linha: o SLO é uma meta interna, mais apertada do que qualquer coisa que você prometa por fora. A engenharia é dona do SLI e do SLO. Produto e jurídico são donos do SLA. Resista ao impulso de criar uma quarta palavra para cada métrica que você já coleta. CPU, memória e profundidade de fila são úteis para depurar. Não são SLIs, porque nenhum cliente sente essas coisas diretamente. ## Como é um bom SLI na prática Um bom SLI é uma razão, é medido o mais perto possível do usuário e tem uma definição clara de "bom". Para um serviço orientado a requisições, o padrão são dois SLIs: disponibilidade (respostas sem 5xx sobre todas as requisições válidas) e latência (requisições abaixo de um limite sobre todas as requisições válidas). Use limite, não média. A média esconde a cauda, e a cauda é de onde vêm os tickets de suporte. Meça no load balancer ou na borda, não dentro do serviço. Um serviço que cai na inicialização reporta taxa de erro perfeita para as requisições que nunca chegaram a ele. Métricas do lado do servidor são cegas para essa falha, e o usuário a vive como uma indisponibilidade. Deixe explícito o que fica de fora. Health checks, sondas sintéticas do seu próprio monitoramento e respostas 4xx causadas por entrada inválida do cliente normalmente não devem contar contra você. Escreva as exclusões ao lado do SLO. Quando alguém discutir o número numa revisão de incidente, a discussão deve ser sobre a definição, não sobre o que o dashboard por acaso mostra. ## A aritmética dos noves Cada nove a mais reduz o tempo de indisponibilidade permitido em dez vezes. Esta é a tabela para manter no documento. - **99%** em 30 dias: 1% de error budget, 7.2 horas de indisponibilidade total permitida. - **99.9%**: 0.1% de budget, 43.2 minutos. - **99.95%**: 0.05% de budget, 21.6 minutos. - **99.99%**: 0.01% de budget, 4.32 minutos. Leia a última linha de novo. Com 99.99%, um deploy ruim que leva cinco minutos para ser detectado e revertido já estourou o mês. Ninguém consegue atender a um alerta, abrir o notebook e reverter em menos de quatro minutos. Isso significa que essa meta só é alcançável com automação: um gate que interrompe o rollout antes que o budget acabe. Então escolha o número que o serviço realmente precisa. A maioria das APIs internas vive bem em 99.9%. Um caminho de pagamentos pode justificar mais. Um job em lote que roda de madrugada pode ficar bem com 99%. Escolher 99.99% porque soa sério é como uma equipe se compromete com uma escala de plantão que não consegue cobrir. ![Ampulheta com quase toda a areia escoada, representando o error budget](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/a422c2-i2.webp) ## O error budget é o ponto, não o SLO Um SLO de 99.9% significa que você pode falhar 0.1% do tempo. Esses 0.1% são o seu error budget, e ele é a ideia mais útil de toda essa disciplina. O budget transforma uma discussão em número. O produto quer lançar a migração arriscada. O SRE diz que ela é arriscada. Sem budget, é opinião contra opinião, e a senioridade vence. Com budget, a pergunta passa a ser: quanto ainda resta, e quanto essa mudança plausivelmente consome? Duas regras fazem isso funcionar. - **Budget restante: pode lançar.** Você pode assumir risco, então assuma. Uma equipe que nunca gasta o budget está investindo em confiabilidade além do que os usuários pediram. - **Budget esgotado: congelar.** O trabalho de funcionalidades pausa até que o trabalho de confiabilidade traga o SLI de volta acima da meta. Isso só vale se a liderança concordou com a regra antes do primeiro incidente, e não durante ele. Se a segunda regra não foi combinada de antemão, você não tem um SLO. Tem um dashboard com uma zona verde e uma zona vermelha. ## Alertar pelo burn rate, não pelo SLI em si É aqui que a maioria das primeiras tentativas falha. Alguém configura um alerta para disparar quando a disponibilidade cai abaixo de 99.9%. O alerta dispara depois que o estrago já foi feito, ou oscila a cada pequena falha, ou as duas coisas. O sinal melhor é o **burn rate**: a velocidade com que você consome o budget em relação ao ritmo que o esgotaria exatamente no fim da janela. Um burn rate de 1 significa que você termina o mês com zero de budget. Um burn rate de 14.4 significa que, nesse ritmo, você queima o budget do mês inteiro em cerca de dois dias. O [Google SRE Workbook sobre alertas em SLOs](https://sre.google/workbook/alerting-on-slos/) recomenda combinar uma janela longa com uma curta, para que o alerta seja significativo e o problema ainda esteja acontecendo. Para um SLO de 30 dias, duas páginas são um bom ponto de partida: - Burn rate 14.4 em 1 hora, confirmado em 5 minutos: consome 2% do budget mensal. Acione uma pessoa. - Burn rate 6 em 6 horas, confirmado em 30 minutos: consome 5% do budget mensal. Acione uma pessoa. A conta é simples. Uma janela de 30 dias tem 720 horas. Queimar a 14.4x por uma hora usa 14.4 / 720 = 2% do budget. A janela curta impede que o alerta continue disparando uma hora depois de o problema já ter terminado. Aqui está a primeira regra como alerta Prometheus, supondo que você registra uma taxa de erro por janela: `groups: - name: checkout-slo-burn rules: - alert: CheckoutErrorBudgetFastBurn expr: | job:checkout_error_ratio:rate1h > (14.4 * 0.001) and job:checkout_error_ratio:rate5m > (14.4 * 0.001) labels: severity: page annotations: summary: "O checkout está queimando 2% do error budget de 30 dias por hora"`A constante 0.001 é a taxa de erro permitida para um SLO de 99.9%. Se você mudar a meta, essa constante muda junto. Mantenha-a em um único lugar, ou o alerta e o SLO vão se afastar sem que ninguém perceba. Queimas mais lentas não precisam de página. Um burn rate de 1 sustentado por três dias vai para um ticket da manhã útil seguinte. Acordar alguém por um vazamento lento é como equipes de plantão aprendem a ignorar o pager. ![Corredor de data center com racks de servidores e luzes de status](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/f23ee5-i3.webp) ## Onde calcular o SLI sem comprar outra plataforma Você não precisa de um produto de SLO dedicado para começar. Precisa de um contador de eventos bons, um contador de eventos totais e um lugar para guardá-los por 30 dias. Se as suas métricas já estão numa plataforma hospedada, o recurso de SLO costuma ser uma camada fina sobre dados pelos quais você já paga. O Datadog cobre SLOs nativamente, com alertas de burn rate, e é o caminho fácil se os seus traces e métricas já estão lá. A conta é a armadilha: métricas customizadas e tags de alta cardinalidade se multiplicam rápido, então confira o preço das séries de SLI antes de se comprometer. Se você roda Prometheus, o Grafana cobre o mesmo terreno com regras de gravação e as suas ferramentas de SLO, ao custo de mais configuração e mais do seu tempo. A comparação honesta é tempo até o primeiro alerta útil contra custo em escala. O Datadog vence no primeiro. Grafana com Prometheus costuma vencer no segundo. Escolha de acordo com aquilo em que a sua equipe está em falta. ## Ligar o SLO ao rollout, a parte que quase todo mundo pula Um SLO que só produz relatório está pela metade. O passo que muda o comportamento é conectar o budget ao caminho de deploy, para que a release pare sozinha. Um rollout progressivo com gate de SLO funciona assim. Libere para 1% do tráfego atrás de uma feature flag. Acompanhe o SLI desse grupo em comparação com a linha de base. Se o burn rate do grupo canário passar do limite, reverta automaticamente. Se ele aguentar, avance para 5%, depois 25%, depois 100%. Isso é bem diferente de um dashboard que alguém deveria estar olhando às 03:12. Às 03:12 você não quer pensar. Quer um botão, ou, melhor ainda, nenhum botão. É aqui que as feature flags se pagam, porque uma flag transforma uma reversão numa mudança de configuração que leva segundos, em vez de um redeploy que leva dez minutos. O LaunchDarkly e plataformas semelhantes oferecem o rollout percentual e o kill switch. O que a maioria deixa para você é a decisão: qual SLI ler, qual limite conta como ruim e quem pode sobrescrever. É essa lacuna que um piloto automatizado com auto-rollback baseado em SLO quer fechar, e é o ângulo que adotamos na upstreamapi. O LaunchDarkly vence em amplitude de SDKs e em controles para empresas, e dizemos isso. Aqui está o formato do gate em TypeScript. A lógica de decisão é a parte que vale escrever por conta própria, qualquer que seja o sistema de flags: `type Cohort = { good: number; total: number }; const SLO_TARGET = 0.999; const BUDGET = 1 - SLO_TARGET; // 0.001 const PAGE_BURN_RATE = 14.4; function burnRate(c: Cohort): number { if (c.total === 0) return 0; const errorRatio = 1 - c.good / c.total; return errorRatio / BUDGET; } export function rolloutDecision(canary: Cohort): "advance" | "hold" | "revert" { if (canary.total < 500) return "hold"; // amostra insuficiente para decidir return burnRate(canary) > PAGE_BURN_RATE ? "revert" : "advance"; }`Repare no ramo `hold`. Um canário de 1% de um serviço tranquilo pode ver quarenta requisições em dez minutos, e um erro em quarenta é uma taxa de erro de 2.5%. Sem uma amostra mínima, o gate reverte por ruído, e a equipe aprende a desconfiar dele. ## Erros recorrentes e por onde começar esta semana Os mesmos poucos erros aparecem em várias equipes, e quase nenhum deles é técnico. **SLOs demais.** Vinte objetivos por serviço significam que ninguém lembra de nenhum. Dois ou três por jornada do usuário bastam. **SLOs que ninguém aprovou.** Um engenheiro escreve sozinho durante um fim de semana. O produto nunca viu, então a política de budget desmorona na primeira vez que disser "não" a um lançamento. **SLOs definidos pelo desempenho atual.** Se o serviço roda hoje a 99.97%, fixar a meta em 99.97% não deixa budget e garante um descumprimento. Defina o número onde os usuários começam a ficar insatisfeitos, o que quase sempre é mais baixo. **Tratar o SLO como permanente.** Revise o número a cada trimestre. Se você nunca gasta o budget, aperte a meta ou entregue mais rápido. Se estoura todo mês, conserte o sistema ou admita que a meta era uma fantasia. **Contar o que é fácil em vez do que é sentido.** Uma resposta 200 com carrinho vazio é um sucesso nos seus logs e uma falha para o cliente. Defina "bom" do lado do usuário. Quem escreve o primeiro esta semana não precisa de um programa. Escolha a jornada que faria o CEO ligar para alguém se quebrasse. Defina um SLI de disponibilidade e um SLI de latência para ela. Fixe a meta em 99.9% no primeiro trimestre, escreva a política de congelamento em duas frases e peça ao produto uma resposta "de acordo" por escrito. Depois, adicione um alerta de burn rate e um lugar onde o time inteiro veja o budget restante. Se você precisa de um lugar leve para começar antes de se comprometer com uma plataforma completa, o Better Stack cuida do monitoramento de uptime e do acionamento de incidentes com uma configuração bem menor, embora não vá fazer a conta do budget por você. A primeira versão vai estar errada. Tudo bem. O que importa é que a próxima revisão de incidente comece de um número que você escreveu de antemão, e não de uma sensação. Pense no último incidente que a sua equipe teve. Havia algum número escrito dizendo se ele importava? Se a resposta honesta for não, esse é o seu primeiro SLO, e a revisão pós-incidente já disse o que medir. ## FAQ ### O que é um SLO? Um SLO é a meta de confiabilidade de um comportamento específico, visto pelo usuário, medido em uma janela fixa. Por exemplo: 99.9% das requisições bem-sucedidas em 30 dias. Ele diz quanta falha é aceitável e quando a equipe deve parar de lançar mudanças arriscadas. ### Qual é a diferença entre SLI, SLO e SLA? O SLI é a medição, uma razão entre eventos bons e eventos válidos. O SLO é a meta interna para essa razão numa janela de tempo. O SLA é o contrato com o cliente, com compensações financeiras, e deve ser sempre mais frouxo que o SLO. ### O que é error budget? É a fatia de falha que o SLO permite. Com 99.9%, o error budget é de 0.1% do tempo na janela, ou cerca de 43.2 minutos por mês. Enquanto houver budget, a equipe pode assumir risco. Quando ele acaba, o trabalho de funcionalidades pausa. ### O que é burn rate e por que alertar com ele? Burn rate mede a velocidade com que o budget está sendo consumido em relação ao ritmo que o esgotaria exatamente no fim da janela. Alertar por burn rate, com uma janela longa e uma curta, dispara antes que o estrago seja grande e evita alertas que oscilam a cada pequena falha. ### Quantos SLOs uma equipe deve ter? Dois ou três por jornada do usuário costumam bastar. Com vinte objetivos por serviço, ninguém lembra de nenhum deles, e a política de budget perde força. ### Como começar a usar SLOs esta semana? Escolha a jornada mais crítica, defina um SLI de disponibilidade e um de latência, fixe a meta inicial em 99.9%, escreva por escrito a regra de congelamento quando o budget acabar e adicione um alerta de burn rate. A primeira versão será imperfeita, e isso é aceitável.