SLO e Error Budget: Guia para Empresas

Aprenda a definir SLO, SLI e error budget com métricas centradas no usuário, política de confiabilidade, alertas de burn rate e revisão contínua.

O que são SLO e error budget?

SLO e error budget são mecanismos para transformar “o sistema precisa ser confiável” em uma meta mensurável e em regras de decisão. O SLO define o nível de serviço que a equipe pretende entregar durante uma janela. O error budget representa a parcela de falhas compatível com essa meta.

Se um serviço possui SLO de 99,9% de requisições bem-sucedidas, o orçamento de erro é 0,1% das requisições elegíveis. Esse orçamento não autoriza falhas deliberadas. Ele cria uma referência para equilibrar lançamentos, manutenção e trabalho de confiabilidade antes que a experiência do usuário se deteriore.

Um SLO útil precisa refletir uma jornada real, ser medido por um indicador confiável e acionar uma política acordada. Sem essas três partes, ele vira apenas um número em um dashboard.

SLI, SLO e SLA: qual é a diferença?

Os termos têm funções diferentes:

Termo	Função	Exemplo
SLI	indicador quantitativo do serviço observado	proporção de pagamentos válidos concluídos em até 3 segundos
SLO	objetivo interno para o SLI em uma janela	99,9% em 28 dias
SLA	compromisso com consequências definidas	crédito contratual quando a disponibilidade acordada não é cumprida
Error budget	quantidade de resultado ruim ainda compatível com o SLO	0,1% dos pagamentos elegíveis

O capítulo de objetivos de nível de serviço do Google SRE define SLI como uma medida quantitativa, SLO como o alvo associado e SLA como um acordo que inclui consequências. A separação evita transformar toda meta operacional em promessa contratual.

CPU, memória e tamanho de fila são sinais importantes, mas normalmente descrevem componentes, não a experiência. Podem explicar uma degradação, porém raramente devem ser o único SLI de uma jornada. O artigo sobre observabilidade de sistemas detalha como correlacionar métricas, logs e traces para investigar as causas.

Comece pelo que o usuário considera bom

A pergunta inicial não é “quais métricas a ferramenta oferece?”, e sim “qual resultado o usuário espera?”. O usuário pode ser um cliente, colaborador, sistema parceiro ou equipe interna.

Escolha uma jornada delimitada, como:

concluir uma compra;
autenticar no aplicativo;
consultar saldo;
emitir uma nota;
processar uma mensagem;
atualizar um painel de negócio;
recuperar um arquivo sem perda.

Depois, descreva um evento bom e um evento elegível. Em pagamentos, por exemplo:

SLI de sucesso = pagamentos elegíveis concluídos corretamente ÷ total de pagamentos elegíveis

A definição precisa esclarecer quais respostas contam como corretas. Uma recusa por saldo insuficiente pode ser um resultado válido, enquanto timeout, duplicidade ou resposta tecnicamente bem-sucedida com conteúdo incorreto são resultados ruins.

Também registre o ponto de medição. Uma API pode responder 200 enquanto o navegador não exibe a confirmação ou o pedido não chega ao ERP. Medir próximo do usuário costuma representar melhor a experiência, embora exija instrumentação adequada.

Como escolher o alvo do SLO

Não copie “três noves” de outro serviço. O alvo deve considerar:

expectativa e impacto para o usuário;
baseline observado em período representativo;
obrigações contratuais e regulatórias;
confiabilidade das dependências;
horários e segmentos críticos;
custo para evitar, detectar e recuperar falhas;
capacidade real de operação e suporte;
velocidade de mudança necessária ao produto.

Um objetivo de 100% tende a ser inadequado: não deixa espaço para manutenção, mudança ou falhas inevitáveis e pode incentivar investimento desproporcional. No outro extremo, um SLO que aceita impacto relevante antes de produzir qualquer ação não protege o usuário.

A recomendação do Google SRE Workbook para implementação de SLOs é começar com um alvo defensável e refiná-lo à medida que a equipe aprende. Produto, desenvolvimento e operação precisam concordar que o objetivo representa a experiência desejada e pode ser sustentado sem esforço permanente ou desgaste.

Como calcular o error budget

Para um SLO baseado em eventos:

orçamento de erro = eventos elegíveis × (1 − alvo do SLO)

Com 1.000.000 de requisições elegíveis e SLO de 99,9%, o orçamento corresponde a 1.000 resultados ruins na janela. Se um incidente produzir 400 falhas, consumiu 40% desse orçamento.

Para um objetivo baseado em tempo, uma aproximação é:

tempo de indisponibilidade permitido = duração da janela × (1 − alvo do SLO)

Essa conversão só é válida quando o SLI realmente usa tempo. Serviços com tráfego variável costumam ser mais bem representados por eventos: cinco minutos no pico e cinco minutos de madrugada não afetam a mesma quantidade de usuários.

Não misture denominadores. Mudanças na filtragem de bots, testes, clientes internos ou respostas inválidas alteram o resultado. A definição deve dizer o que entra, o que fica fora e por quê.

Error budget restante também não significa que uma grande mudança esteja automaticamente aprovada. Segurança, privacidade, integridade de dados e obrigações legais continuam sendo limites independentes.

Janela móvel ou período de calendário?

A janela determina quando o desempenho é agregado e quando o orçamento se recompõe.

Uma janela móvel, como os últimos 28 dias, muda continuamente e mostra a experiência recente. Ela evita uma virada abrupta no início do mês, mas pode ser menos intuitiva para relatórios financeiros.

Um período de calendário, como mês ou trimestre, alinha-se a ciclos de gestão. Porém, uma falha no último dia e outra no primeiro podem aparecer separadas, mesmo fazendo parte do mesmo problema.

Escolha conforme a decisão que o SLO precisa orientar e mantenha a regra estável. Para serviços sazonais, examine também segmentos e períodos críticos. Um resultado mensal saudável pode esconder falha total durante uma campanha.

Exclusões de manutenção exigem governança. Não remova automaticamente toda janela planejada: para o usuário, uma indisponibilidade anunciada ainda pode representar impacto. Se houver exclusões, documente escopo, justificativa, aprovação e tratamento no SLA.

Burn rate: alertar antes de acabar o orçamento

Esperar o SLO ser perdido para agir é tarde. A burn rate compara a taxa de erro observada com a taxa sustentável pelo objetivo.

burn rate igual a 0: nenhum orçamento está sendo consumido;
burn rate igual a 1: o consumo segue exatamente o ritmo sustentável;
burn rate maior que 1: se o ritmo continuar, o serviço terminará a janela fora do SLO.

A documentação do Google Cloud sobre alertas de burn rate orienta combinar sinais de consumo rápido e lento. Uma janela curta detecta incidentes intensos; uma janela longa identifica degradação persistente e reduz reação a picos breves.

Defina canais diferentes conforme urgência:

fast burn: aciona plantão quando há impacto relevante e ação imediata possível;
slow burn: cria investigação priorizada no horário adequado;
tendência de orçamento: orienta revisão de roadmap e risco de releases.

Cada alerta deve indicar SLO afetado, janela, orçamento consumido, jornadas impactadas, mudanças recentes, dashboard e runbook. O Amazon CloudWatch também permite associar alarmes e limiares de aviso aos SLOs do Application Signals, mostrando que o padrão pode ser aplicado em diferentes plataformas.

Crie uma política de error budget

O orçamento só influencia prioridades quando existe uma política. Ela deve ser aprovada por produto, engenharia e operação antes da crise.

A política responde:

quem é responsável pelo SLO;
quando uma tendência exige investigação;
quais lançamentos podem continuar;
quando mudanças de risco devem ser suspensas;
quais exceções permanecem permitidas, como correções de segurança;
quando um incidente exige post-mortem;
quem decide em caso de divergência;
como e quando o SLO será revisado.

A política de exemplo do Google SRE deixa explícito que restringir mudanças não deve ser punição. A finalidade é permitir que a equipe priorize confiabilidade quando os dados mostram risco elevado.

Evite a regra simplista “zerou, congela tudo”. Uma correção pode reduzir risco, uma atualização de segurança pode ser obrigatória e uma alteração de configuração pode restaurar capacidade. Classifique mudanças por impacto e defina quem aprova exceções.

Conecte a política ao pipeline CI/CD seguro. O estado do orçamento pode informar aprovações, canary, ritmo de promoção e critérios de rollback, sem transformar um indicador imperfeito em bloqueio automático e opaco.

SLO deve orientar incidentes e prioridades

Durante um incidente, o SLO ajuda a dimensionar impacto com uma linguagem comum. A equipe consegue comparar eventos pela parcela de orçamento consumida e priorizar ações que protegem as jornadas mais importantes.

Depois da recuperação, relacione o incidente ao SLI:

o evento foi detectado?
a mensuração refletiu o usuário?
houve segmentos afetados que a média ocultou?
o alerta chegou cedo e à equipe certa?
o runbook permitiu mitigar?
a mudança corretiva reduz consumo futuro?

Se incidentes relevantes não aparecem no SLO, falta cobertura. Se o orçamento é consumido sem impacto percebido, o indicador ou a classificação de eventos pode estar errado. O plano de resposta a incidentes complementa esse processo com papéis, comunicação, contenção e aprendizado.

SLOs também ajudam a comparar trabalho de confiabilidade. Automatizar rollback, remover um ponto único de falha ou reduzir uma dependência rígida pode ser priorizado pelo impacto esperado sobre eventos ruins, não apenas por preferência técnica.

Governe o SLO como um produto

Documente cada objetivo com:

serviço e jornada cobertos;
usuários e segmentos incluídos;
definição do SLI, consulta e fonte;
alvo e janela;
proprietário técnico e de negócio;
política de error budget;
dashboards, alertas e runbooks;
baseline e justificativa;
versão, aprovadores e data de revisão;
limitações conhecidas.

A especificação OpenSLO propõe descrever objetivos e indicadores de forma declarativa e independente de fornecedor. Mesmo sem adotar o padrão, versionar definições reduz configurações órfãs e aproxima SLO, observabilidade, infraestrutura como código e governança.

Uma frente de governança e compliance de TI pode definir proprietários, critérios de exceção, retenção de evidências e cadência de revisão para serviços críticos.

Roteiro de adoção em sete etapas

Escolha uma jornada crítica e um responsável.
Defina eventos bons, ruins e elegíveis.
Valide fonte, cobertura e qualidade dos dados.
Calcule o baseline em período representativo.
Negocie alvo, janela e limitações.
Publique dashboard, alertas, runbook e política.
Execute por alguns ciclos e refine com incidentes reais.

Comece com um ou dois objetivos por serviço. Muitos SLOs fragmentam atenção e tornam a política impraticável. Disponibilidade ou sucesso costuma ser o primeiro; latência, atualidade ou durabilidade entram quando representam decisões distintas.

Em uma migração para cloud, defina SLIs antes da transição e compare origem, período de mudança e ambiente alvo. Assim, a equipe valida a experiência, não apenas se os recursos foram criados.

Erros frequentes

Usar disponibilidade de servidor como experiência. O host pode estar ativo enquanto pagamento, login ou integração falha.

Escolher o alvo por aparência. Mais noves aumentam custo e esforço; menos noves podem não proteger o negócio.

Medir média de latência. Médias escondem a cauda. Defina a proporção de eventos abaixo de um limite significativo.

Criar SLO sem política. Um indicador que não altera decisão é apenas relatório.

Alertar a cada erro. O plantão recebe ruído e perde capacidade de responder ao impacto real.

Excluir toda manutenção. A métrica deixa de representar indisponibilidade percebida.

Punir a equipe pelo orçamento. Pessoas passam a negociar números ou esconder falhas em vez de melhorar o sistema.

Nunca revisar a definição. Usuários, tráfego, arquitetura e instrumentação mudam.

Checklist de SLO e error budget

A jornada representa valor para o usuário?
Eventos bons e elegíveis estão definidos?
O ponto de medição está próximo da experiência?
O alvo possui justificativa e baseline?
A janela corresponde à decisão?
Dependências e segmentos críticos estão visíveis?
O cálculo do orçamento é verificável?
Fast burn e slow burn têm rotas adequadas?
Alertas possuem responsável e runbook?
A política diferencia risco e tipo de mudança?
Produto, engenharia e operação aprovaram a regra?
Incidentes são comparados com o SLO?
Definições e alterações são versionadas?
Existe data para revisar cobertura e utilidade?

Conclusão

SLO e error budget funcionam quando ligam a experiência do usuário a decisões reais. O SLI define o que será observado, o SLO estabelece o alvo, a burn rate antecipa risco e a política determina como equilibrar mudança e confiabilidade.

Comece por uma jornada, com uma definição simples e verificável. Observe alguns ciclos, confronte o indicador com incidentes e ajuste a cobertura sem maquiar o histórico. Se sua empresa precisa definir metas, instrumentar serviços e conectar confiabilidade ao processo de entrega, converse com a Mattos Tech Solutions.