Como calcular e respeitar error budgets sem inibir velocidade do time

1. Fundamentos do Error Budget: o que é e por que existe

Error budget é um dos conceitos mais transformadores da engenharia de confiabilidade moderna. Ele nasceu da constatação simples, porém revolucionária, do Google SRE: 100% de confiabilidade é o inimigo da inovação. Se um sistema precisa estar disponível 100% do tempo, nenhuma alteração pode ser feita — nem deploy, nem atualização de segurança, nem nova feature.

A estrutura clássica começa com três siglas:

  • SLI (Service Level Indicator): métrica real que mede o comportamento do serviço (ex: latência de requisições, taxa de erros)
  • SLO (Service Level Objective): meta definida para esse indicador (ex: 99,9% das requisições com latência < 200ms)
  • Error Budget: o "orçamento de erros" permitido = 1 - SLO

Se seu SLO é 99,9%, seu error budget é 0,1%. Esse percentual representa o quanto seu sistema pode falhar sem violar o compromisso com o usuário. O paradoxo é libertador: você não precisa buscar perfeição, apenas cumprir o prometido. O error budget vira um recurso gerenciável, como tempo ou orçamento financeiro.

2. Como definir SLOs realistas que geram error budgets úteis

A definição do SLO é o ponto mais crítico. SLOs irreais geram error budgets inúteis — ou tão pequenos que paralisam o time, ou tão frouxos que não protegem o usuário.

Passos práticos:

  1. Escolha SLIs significativos: não meça tudo. Priorize latência (p95 ou p99), disponibilidade (taxa de requisições bem-sucedidas) e throughput. Exemplo para uma API REST:
    SLI: Proporção de requisições com status HTTP < 500 e latência < 300ms

  2. Defina a janela de tempo: use rolling windows de 28 ou 30 dias. Isso suaviza picos e dá visibilidade de tendência.

  3. Envolva produto e negócio: o SLO não é decisão técnica isolada. Pergunte: "Qual nível de falha é aceitável para o cliente?" Um SaaS B2B pode tolerar 99,5%; um sistema de pagamento crítico pode exigir 99,99%.

Exemplo de definição de SLO:

Serviço: API de recomendações
SLI: Requisições com resposta em menos de 500ms e status 200
SLO: 99,5% em janela de 28 dias
Error budget: 0,5% = 0,005 * (28 * 24 * 3600 segundos) = 1209,6 segundos

3. Cálculo prático do error budget: exemplos e armadilhas comuns

Fórmula básica:

Error Budget = 1 - SLO

Exemplo 1:
SLO = 99,9%
Error Budget = 0,1% = 0,001

Conversão para tempo (janela de 30 dias):
30 dias = 2592000 segundos
Budget em segundos = 0,001 * 2592000 = 2592 segundos (~43 minutos)

Conversão para requisições (supondo 1 milhão de requisições/dia):
30 dias = 30 milhões de requisições
Budget em requisições = 0,001 * 30.000.000 = 30.000 requisições

Armadilhas comuns:

  • Budget muito pequeno: SLO de 99,99% para um serviço interno não crítico gera budget de 0,01% — qualquer variação mínima dispara alertas.
  • Janelas mal ajustadas: janela de 7 dias é curta demais para tendências; janela de 90 dias pode esconder problemas recentes.
  • Métricas não estacionárias: tráfego sazonal (Black Friday, horário comercial) distorce o cálculo se não for considerado.

4. Monitoramento contínuo e alertas inteligentes de error budget

O monitoramento deve responder a duas perguntas: "Quanto do budget já consumimos?" e "A que taxa estamos consumindo?"

Cálculo de burn rate:

Burn rate = Erros observados / (Budget total / Período total)

Se em 10 dias consumimos 40% do budget mensal:
Burn rate = 0,40 / (10/30) = 1,2
(Valor > 1 indica consumo acelerado)

Alertas multi-window:

Alerta rápido (burn rate alto em janela curta):
- Janela de 1 hora: burn rate > 10 → incidente crítico

Alerta de tendência (burn rate moderado em janela longa):
- Janela de 6 horas: burn rate > 2 → atenção
- Janela de 3 dias: burn rate > 1,2 → planejamento de ação

Dashboards recomendados:

Métrica: error_budget_remaining
Labels: service, slo_name, window
Valor: 0.0 a 1.0 (0 = budget esgotado, 1 = budget intacto)

Gráfico: Linha do tempo com limite em 0 (exaustão)
Alerta: Quando error_budget_remaining < 0.2 (20% restante)

5. Estratégias para respeitar o error budget sem parar o time

O erro mais comum é tratar o error budget como "multa" — quando acaba, o time para. A abordagem correta é tratá-lo como orçamento de risco.

Estratégias práticas:

  1. Deploys progressivos: quando o budget está acima de 50%, deploys podem ser frequentes. Entre 20% e 50%, reduza a frequência e aumente o canary. Abaixo de 20%, apenas deploys críticos (segurança, bugs críticos).

  2. Política de "freeze parcial": não pare o time, mas mude o foco. Se o budget está baixo, o time dedica 50% do tempo a melhorias de resiliência em vez de novas features.

  3. Decisões baseadas em dados: crie uma tabela de decisão:

Budget restante > 60%: deploys liberados, experimentos permitidos
Budget entre 30% e 60%: deploys com canary de 10% por 30 min
Budget entre 10% e 30%: apenas deploys de segurança e correções
Budget < 10%: apenas rollbacks e ações de mitigação

6. Cultura de engenharia: como o error budget incentiva velocidade segura

O error budget muda a dinâmica de culpa para dados. Em vez de "quem causou o incidente?", a pergunta vira "nosso SLO ainda está sendo cumprido?".

Impactos culturais observados:

  • Times mais rápidos: times com SLOs claros fazem deploys 3x mais frequentes (dados de empresas como Google e Netflix)
  • Investimento em resiliência: quando o budget acaba, o time tem justificativa objetiva para parar features e focar em confiabilidade
  • Redução de reuniões: discussões subjetivas sobre "estabilidade vs velocidade" são substituídas por métricas

Exemplo de ciclo virtuoso:

1. Time define SLO de 99,5% para API
2. Error budget = 0,5% (~21 minutos de falha/mês)
3. Time faz deploys diários sem medo
4. Budget cai para 30% → time decide: "vamos investir 2 dias em melhorias de timeout e retry"
5. Budget volta a 80% → deploys aceleram novamente

7. Ferramentas e automação para gerenciar error budgets no dia a dia

Integração com CI/CD:

Pipeline de deploy:
1. Verificar error_budget_remaining no Prometheus
2. Se < 20%:
   - Bloquear deploy automático
   - Notificar equipe no Slack
   - Exigir approval manual do SRE
3. Se > 20%:
   - Permitir deploy com canary de 5%

Exemplo de query Prometheus:

# Calcular budget restante para SLO de 99,9%
(
  1 - (
    sum(rate(http_requests_total{status=~"5.."}[28d]))
    /
    sum(rate(http_requests_total[28d]))
  )
) / (1 - 0.999)

Ferramentas recomendadas:

  • Prometheus + Alertmanager para alertas multi-window
  • VictoriaMetrics para armazenamento de longa duração
  • Grafana para dashboards de burn rate
  • Keptn ou Flagger para automação de canary baseada em SLO

8. Casos reais e lições aprendidas na prática

Caso 1: Time de busca que usou error budget para justificar melhoria técnica

Um time de busca de e-commerce tinha SLO de 99,9%. O error budget de 0,1% era consumido em 15 dias por latência alta em horário de pico. O time usou o dado para convencer o produto a liberar uma sprint de otimização de cache. Resultado: budget voltou a 80% e deploys de features aceleraram 40%.

Caso 2: SLOs muito apertados gerando fadiga

Outro time definiu SLO de 99,99% para um serviço interno de logging. O error budget de 0,01% era consumido em horas por qualquer variação de rede. Os alertas disparavam dezenas de vezes por dia, gerando fadiga e ignorância. Solução: ajustaram SLO para 99,9% e os alertas passaram a ser acionados apenas em problemas reais.

Lições aprendidas:

  • Comece com SLOs mais frouxos (99% a 99,5%) e ajuste ao longo do tempo
  • Revise SLOs a cada trimestre com o negócio
  • Error budget não é punição — é ferramenta de priorização
  • Automatize o máximo possível para evitar decisões manuais emocionais

O error budget, quando bem implementado, não inibe a velocidade do time — pelo contrário, ele dá segurança para acelerar com responsabilidade. A chave está em métricas realistas, monitoramento inteligente e uma cultura que trata confiabilidade como dado, não como opinião.

Referências