Error Budget: equilibrando velocidade e confiabilidade

Times de engenharia vivem um conflito constante: entregar features rápido vs manter o sistema estável. Error budget é um conceito que transforma esse conflito em colaboração, dando uma resposta clara à pergunta: "Quanto risco podemos assumir?"

Este artigo explora o que é error budget, como calculá-lo, e como usá-lo para tomar decisões melhores.

Error budget não é permissão para falhar. É clareza sobre quanto você pode experimentar.

O que é Error Budget

Error budget é a quantidade de "falha permitida" antes de violar um SLO.

Cálculo:

Error Budget = 100% - SLO

Se SLO = 99.9% disponibilidade
Error Budget = 0.1% de indisponibilidade permitida

Em tempo:

0.1% de 30 dias = 43.2 minutos de downtime permitido por mês

Por que Error Budget Importa

1. Transforma abstrato em concreto

Vago: "Precisamos ser mais confiáveis"
Concreto: "Temos 20 minutos de error budget restantes este mês"

2. Cria linguagem comum

Produto, Engenharia e Operações podem concordar em quanto risco assumir:

• Budget sobrando → podemos lançar features arriscadas
• Budget esgotando → foco em estabilidade

3. Elimina debates subjetivos

Sem error budget:
"Deveríamos lançar?" → "Talvez... parece arriscado... não sei..."

Com error budget:
"Deveríamos lançar?" → "Temos 80% de budget, risco estimado é 5%. Sim."

Calculando Error Budget

Fórmula básica

Error Budget Total = (1 - SLO) × janela de tempo

Para SLO de 99.9% em 30 dias:
Budget = 0.001 × 30 × 24 × 60 = 43.2 minutos

Budget consumido

Budget Consumido = tempo total de violação de SLO

Se houve 15 minutos de indisponibilidade:
Consumido = 15 minutos
Restante = 43.2 - 15 = 28.2 minutos

Múltiplos SLIs

Quando você tem múltiplos SLOs, cada um tem seu próprio budget:

Disponibilidade: 0.1% budget = 43 min/mês
Latência: 1% budget = 7.2 horas/mês de requisições lentas
Erros: 0.5% budget = 3.6 horas/mês de requisições com erro

Usando Error Budget na Prática

Política de Error Budget

Defina regras claras baseadas no estado do budget:

Budget > 50%: 🟢
- Releases normais
- Experimentos permitidos
- Foco em features

Budget 20-50%: 🟡
- Releases com mais cautela
- Rollback rápido pronto
- Atenção extra em monitoramento

Budget < 20%: 🔴
- Freeze de features
- Apenas fixes críticos
- Time focado em estabilidade

Budget = 0%: ⛔
- Sem releases
- Postmortem obrigatório
- Trabalho exclusivo em confiabilidade

Decisões de release

Feature nova estimada para consumir 5% de error budget.
Budget atual: 60%

Decisão:
60% - 5% = 55% restante > 50% threshold
→ ✅ Pode lançar

Budget atual: 25%
25% - 5% = 20% restante = threshold
→ ⚠️ Pode lançar, mas com cautela extra

Budget atual: 10%
10% - 5% = 5% restante < 20% threshold
→ ❌ Não lança, foco em estabilidade

Alocação de tempo do time

Budget > 75%:
- 80% features, 20% confiabilidade

Budget 25-75%:
- 50% features, 50% confiabilidade

Budget < 25%:
- 20% features, 80% confiabilidade

Burn Rate

Burn rate mede quão rápido você está consumindo error budget.

Cálculo

Burn Rate = (Budget consumido / Tempo decorrido) / (Budget total / Janela total)

Exemplo:
- Budget total: 43 minutos/mês
- Tempo decorrido: 10 dias
- Budget consumido: 20 minutos

Taxa esperada em 10 dias: 43 × (10/30) = 14.3 min
Taxa real: 20 min
Burn rate = 20 / 14.3 = 1.4x

→ Consumindo budget 40% mais rápido que sustentável

Alertas baseados em burn rate

Burn Rate	Interpretação	Ação
< 1x	Sustentável	Continuar normal
1-2x	Atenção	Monitorar de perto
2-5x	Alerta	Investigar causa
> 5x	Crítico	Ação imediata

# Prometheus alert
- alert: HighErrorBudgetBurnRate
  expr: |
    (
      1 - (sum(rate(http_requests_total{status=~"2.."}[1h]))
           / sum(rate(http_requests_total[1h])))
    ) / (1 - 0.999) > 2
  for: 5m
  annotations:
    summary: "Error budget burning 2x faster than sustainable"

Error Budget e Cultura

Mudança de mentalidade

Antes:

• Confiabilidade é responsabilidade do ops
• Features são prioridade
• Estabilidade é custo

Depois:

• Confiabilidade é responsabilidade compartilhada
• Error budget equilibra features e estabilidade
• Estabilidade é investimento

Postmortems

Quando error budget é consumido, postmortems devem responder:

1. O que causou o consumo de budget?
2. Era previsível?
3. O que podemos fazer para reduzir consumo futuro?
4. Vale o trade-off (feature vs estabilidade)?

Negociação saudável

Produto: "Precisamos lançar essa feature"
Engenharia: "Temos apenas 15% de error budget"

Opções:
1. Lançar para % pequeno de usuários (menos risco)
2. Adiar até próximo ciclo de budget
3. Investir em hardening antes de lançar
4. Aceitar risco e lançar (decisão consciente)

Armadilhas Comuns

1. Tratar budget como meta a gastar

❌ "Temos 40% de budget, vamos usar tudo em experimentos arriscados"
✅ "Temos 40% de budget, podemos assumir riscos calculados"

2. Ignorar budget quando conveniente

❌ "Essa feature é muito importante, lança mesmo sem budget"
✅ "Sem budget, precisamos escolher: adiar feature ou aceitar degradação de SLO"

3. SLOs desconectados da realidade

❌ SLO de 99.99%, budget de 4 min/mês, impossível de cumprir
✅ SLO baseado em capacidade real, budget utilizável

Conclusão

Error budget é uma ferramenta poderosa para:

1. Quantificar risco de forma objetiva
2. Alinhar times em torno de objetivos comuns
3. Tomar decisões baseadas em dados
4. Balancear velocidade e confiabilidade

Para implementar:

1. Defina SLOs claros e realistas
2. Calcule error budget para cada SLO
3. Estabeleça políticas baseadas no estado do budget
4. Monitore burn rate continuamente
5. Respeite o sistema — budget não é sugestão

Error budget é democracia aplicada a engenharia: todos têm voz, mas as regras são claras e respeitadas.