SLO: metas de confiabilidade para aplicações profissionais

O que são SLOs e como diferem de SLAs

Objetivos internos versus compromissos contratuais externos

SLO (Service Level Objective) é uma meta interna de confiabilidade que a equipe de engenharia define para si mesma: "nosso serviço de pagamentos deve ter 99,95% de availability medida pelo SLI de requisições bem-sucedidas, calculada em janela de 30 dias". Diferente do SLA (Service Level Agreement), que é um contrato formal com o cliente com penalidades financeiras em caso de violação, o SLO é um compromisso interno — uma bússola técnica para priorizar trabalho. Times maduros definem SLOs mais rigorosos do que os SLAs para criar margem de segurança: se o SLA garante 99,9%, o SLO interno pode ser 99,95%, garantindo que violações do SLO disparem ação corretiva antes que o SLA seja violado. Essa separação entre objetivo interno e comprometimento externo é central para o modelo de SRE do Google.

Como definir SLOs realistas para seu sistema

O equilíbrio entre ambição e realidade operacional

Definir SLOs realistas exige dados históricos — qual a availability real do sistema nos últimos 90 dias? SLOs definidos sem dados históricos tendem a ser aspiracionais demais (100% de availability) ou conservadores demais (90%, que qualquer sistema mediano atinge). O processo recomendado pelo Google SRE começa medindo o estado atual, depois definindo um SLO ligeiramente acima do atual para criar pressão por melhoria sem ser inalcançável. Além de dados históricos, é necessário considerar as expectativas dos usuários: serviços internos B2B toleram mais downtime do que aplicativos de consumo com milhões de usuários. Revise os SLOs a cada trimestre, ajustando com base na maturidade do sistema e nas expectativas dos stakeholders.

Error budget — o orçamento de falhas

Como transformar o SLO em ferramenta de priorização

Error budget é a quantidade de "falhas permitidas" que deriva matematicamente do SLO: se o SLO é 99,9% em 30 dias, o error budget é 0,1% de requisições com falha — ou aproximadamente 43 minutos de downtime total no mês. O conceito poderoso do error budget é que ele transforma a confiabilidade de uma meta vaga em um recurso finito e compartilhado. Enquanto há error budget disponível, a equipe pode fazer deploys frequentes, experimentar novas features e aceitar riscos de regressão. Quando o error budget está quase esgotado, a equipe congela deploys de novas features e foca exclusivamente em estabilidade — uma decisão técnica objetiva baseada em dados, não em sentimentos. Essa mecânica elimina o conflito eterno entre velocidade de desenvolvimento e estabilidade de produção.

Como usar o error budget para priorizar trabalho

Decisões técnicas objetivas baseadas em dados reais

O error budget como ferramenta de priorização funciona da seguinte forma: se o sistema está consumindo o budget muito rapidamente (burn rate alto), o time de engenharia deve pausar novas features e investir em confiabilidade — reduzir o número de deploys por dia, aumentar cobertura de testes, melhorar rollback automático. Se o budget raramente é consumido — o sistema está muito mais estável do que o SLO exige — pode haver sub-investimento em velocidade de desenvolvimento: o time poderia estar entregando mais features, fazendo deploys mais frequentes, ou revisando o SLO para cima. O error budget é também uma linguagem comum entre produto e engenharia: o gerente de produto entende "não podemos fazer esse deploy porque o error budget deste mês está em 20%" sem precisar de explicações técnicas sobre bancos de dados e deploys.

SLOs para latência, disponibilidade e error rate

Definindo metas concretas para cada dimensão de qualidade

Cada tipo de SLI precisa de um SLO correspondente com threshold específico. Para availability: "99,9% das requisições ao endpoint /api/checkout devem retornar 2xx em janela de 30 dias". Para latência: "95% das requisições ao endpoint /api/search devem ser respondidas em menos de 500ms, medido em janela de 1 hora". Para error rate: "o error rate de requisições 5xx no path /api/payments não deve exceder 0,1% em janela de 10 minutos". A granularidade importa: SLOs por endpoint crítico são mais úteis do que SLOs globais que mascaram problemas em fluxos específicos. A janela de tempo também importa: janelas curtas (1 hora) detectam problemas mais rapidamente mas são mais ruidosas; janelas longas (30 dias) são mais estáveis mas atrasam a detecção de degradação gradual.

Revisando e ajustando SLOs com o tempo

SLOs como documentos vivos que evoluem com o sistema

SLOs não são contratos permanentes — devem ser revisados periodicamente à medida que o sistema amadurece, a base de usuários cresce e as expectativas mudam. Um sistema que atingiu consistentemente 99,95% de availability por seis meses pode ter seu SLO revisado para 99,99%, criando nova pressão por melhorias de confiabilidade. Ao contrário, se um SLO está sendo violado repetidamente e a equipe não tem capacidade de investir na melhoria, é melhor reduzir o SLO para um nível alcançável do que criar uma cultura de violações ignoradas. Revisões trimestrais de SLO com dados históricos, análise de incidentes e feedback de usuários são a prática recomendada. Documente o raciocínio por trás de cada ajuste para preservar o contexto para futuras revisões.

SLOs em microsserviços — dependências e cascata

Como calcular o SLO end-to-end quando múltiplos serviços cooperam

Em arquiteturas de microsserviços, o SLO de um serviço é limitado pela confiabilidade dos serviços dos quais ele depende. Se o serviço A depende dos serviços B, C e D, e cada um tem SLO de 99,9%, o SLO máximo alcançável por A é aproximadamente 99,7% (multiplicação das disponibilidades individuais). Isso significa que SLOs agressivos em serviços que dependem de muitos outros são matematicamente difíceis de atingir sem investimento em circuit breakers, fallbacks e degradação graciosa. Times de SRE documentam as dependências de cada serviço e calculam o "dependency budget" — quanto da confiabilidade do serviço está em risco por conta de dependências externas. Serviços com muitas dependências externas frequentemente implementam cache de resultados e comportamentos degradados para não propagar falhas de dependência para o usuário final.

Documentando e comunicando SLOs para stakeholders

Tornando a confiabilidade visível para toda a organização

SLOs têm valor real apenas quando são conhecidos e respeitados por toda a organização — não apenas pela equipe técnica. Um documento de SLO eficaz contém: a definição precisa do SLI medido, o SLO percentual e a janela de tempo, o error budget calculado, as consequências quando o budget é consumido (freeze de deploys, postmortem obrigatório), e o histórico de performance dos últimos ciclos. Dashboards públicos de SLO — exibidos em monitores nas áreas de produto e engenharia — transformam a confiabilidade em métrica compartilhada e criam pressão positiva para manutenção. Postmortems blameless (sem culpa) para cada violação de SLO são a prática que transforma incidentes em aprendizado sistemático e reduz reincidências.

Ferramentas para monitorar SLOs automaticamente

Automação que elimina o monitoramento manual de percentuais

Calcular e monitorar SLOs manualmente não é viável — a automação é obrigatória. Sloth é uma ferramenta open source que gera regras de alertas Prometheus baseadas em SLOs declarativos, calculando burn rate automaticamente. O Grafana SLO plugin permite definir e visualizar SLOs diretamente no Grafana sem código adicional. Datadog e New Relic têm funcionalidades nativas de SLO com dashboards automáticos, alertas de burn rate e histórico de compliance. Para equipes que já usam Prometheus e Grafana, a combinação de recording rules para pré-calcular o SLI e alertas de burn rate multi-window (curto e longo prazo simultaneamente) é a abordagem mais robusta. O importante é que a violação de SLO gere um alerta acionável com severidade proporcional ao burn rate, não apenas uma notificação de log que ninguém lê.

Conclusão — SLOs como contrato social dentro da equipe técnica

Clareza, objetividade e foco no que realmente importa

SLOs são mais do que metas técnicas — são um contrato social dentro da equipe e entre engenharia e produto que define o que "bom o suficiente" significa para cada serviço. Com SLOs bem definidos e error budgets monitorados, as decisões sobre quando priorizar confiabilidade versus velocidade de entrega deixam de ser subjetivas e passam a ser orientadas por dados reais. Times que operam com SLOs maduros têm menos conflitos internos sobre prioridades, menos incidentes repetidos e maior confiança para fazer deploys frequentes — porque sabem exatamente quanto risco ainda têm disponível. Continue em: Fundamentos obrigatórios antes de produção.