Error Budget: o que é, como calcular e usar no SRE

Toda decisão de implantar software em produção carrega um risco de falha. O problema não é eliminar esse risco — isso é impossível — mas decidir quanto risco é aceitável antes que o serviço viole os compromissos de confiabilidade com os usuários. É exatamente para isso que existe o error budget.

Error budget é o conceito central da prática de SRE (Site Reliability Engineering) criada pelo Google para equilibrar velocidade de entrega e confiabilidade de sistemas. Ele define matematicamente quanto tempo de indisponibilidade ou degradação um serviço pode acumular em um período sem violar seu SLO (Service Level Objective). Enquanto o saldo de error budget estiver positivo, o time pode deployar com frequência. Quando o budget se esgota, a velocidade de entrega precisa ser reduzida para proteger os usuários.

Neste guia técnico, você vai entender o que é error budget, como calcular, como usá-lo para governar decisões de deploy e qual a relação com SLIs, SLOs e as métricas DORA.

O que é error budget?

Error budget é o orçamento de erros ou indisponibilidade que um serviço pode acumular em um período de tempo sem violar o SLO definido. É a diferença entre a perfeição (100% de disponibilidade) e o SLO acordado.

A fórmula é direta: se o SLO de um serviço é de 99,9% de disponibilidade mensal, o error budget é de 0,1% do tempo total do mês — o que corresponde a aproximadamente 43,8 minutos de indisponibilidade acumulada por mês.

O conceito resolve um conflito estrutural em organizações de engenharia: times de desenvolvimento querem deployar frequentemente (velocidade), enquanto times de operações querem estabilidade (confiabilidade). O error budget torna esse conflito explícito e mensurável. Em vez de discussões subjetivas sobre “estamos deployando rápido demais?”, o time responde à pergunta “quanto do nosso error budget já consumimos este mês?”

Como calcular o error budget

O cálculo parte do SLO definido para o serviço. Há dois modelos principais dependendo do tipo de SLI (Service Level Indicator) adotado.

Error budget baseado em disponibilidade (tempo)

Este é o modelo mais comum para serviços que medem disponibilidade por tempo de uptime.

Fórmula:
Error budget = (1 - SLO) × período de tempo

Exemplos práticos para um período de 30 dias (43.200 minutos):

SLO de 99,9% → error budget de 43,2 minutos/mês
SLO de 99,5% → error budget de 216 minutos/mês (3,6 horas)
SLO de 99,0% → error budget de 432 minutos/mês (7,2 horas)

Error budget baseado em requisições (taxa de sucesso)

Para serviços que medem confiabilidade pela proporção de requisições bem-sucedidas, o error budget é calculado sobre o volume total de requisições.

Fórmula:
Error budget = (1 - SLO) × total de requisições no período

Se o serviço processa 1.000.000 de requisições por mês e o SLO é de 99,9%, o error budget é de 1.000 requisições com falha permitidas no mês.

Esse modelo é mais preciso para APIs e serviços transacionais porque reflete a experiência real dos usuários — uma hora de indisponibilidade às 3h da manhã tem impacto muito menor do que 1 minuto de falha no pico de acesso.

Como o error budget governa decisões de engenharia

A principal utilidade do error budget não é medir falhas — é criar uma política objetiva de como o time deve se comportar dependendo do saldo restante.

Times de SRE maduros definem uma política de error budget com regras explícitas atreladas ao consumo do orçamento.

Budget positivo — modo de velocidade

Quando o saldo de error budget está confortável (acima de 50% do período, por exemplo), o time tem liberdade para: deployar novas funcionalidades com frequência, executar experimentos e testes de carga em produção, conduzir exercícios de chaos engineering para validar resiliência e adotar tecnologias ou mudanças de arquitetura mais arriscadas.

Budget no limite — modo de atenção

Quando o consumo está acelerado ou o saldo cai abaixo de um threshold definido (por exemplo, 25% restante na metade do período), o time entra em modo de atenção: foco em qualidade antes de velocidade, revisão dos deployments recentes para identificar a causa do consumo elevado e priorização de melhorias de confiabilidade sobre novas features.

Budget esgotado — modo de freeze

Quando o error budget é totalmente consumido antes do fim do período, a política padrão é congelar novos deploys até o reset do período ou até que melhorias de confiabilidade sejam implementadas. Nesse momento, o time de produto e o time de engenharia precisam renegociar prioridades com dados concretos — não com opiniões.

Esse mecanismo é o que diferencia SRE de ITIL ou gestão tradicional de operações: a decisão de pausar deploys é automática e baseada em dados, não em julgamento político.

Error budget e as métricas DORA

O error budget complementa as DORA Metrics de forma direta. Enquanto as DORA Metrics medem a saúde do processo de entrega (Deployment Frequency, Lead Time, Change Failure Rate, Recovery Time), o error budget mede o impacto desse processo sobre a experiência do usuário em produção.

A conexão mais direta é com a Change Failure Rate: uma Change Failure Rate elevada se traduz em consumo acelerado do error budget. Times que observam o budget se esgotando consistentemente antes do fim do período devem investigar primeiro a qualidade do pipeline de CI/CD e os processos de revisão de código.

O error budget também informa o Failed Deployment Recovery Time: incidentes que consomem budget significativo devem ter postmortems com foco em reduzir o tempo de detecção e recuperação.

Erros comuns na implementação de error budget

O erro mais frequente é definir SLOs aspiracionais em vez de SLOs baseados em dados históricos reais. Um SLO de 99,99% para um serviço que historicamente opera em 99,5% gera um error budget de apenas 4,3 minutos/mês — tão restritivo que qualquer deploy não trivial o esgota imediatamente, tornando o mecanismo inútil.

O segundo erro é não conectar o error budget a uma política explícita. Medir o consumo sem definir o que acontece quando o budget se esgota transforma o conceito em um dashboard decorativo.

O terceiro erro é ignorar o error budget de componentes downstream. Um serviço com SLO de 99,9% que depende de três dependências externas com o mesmo SLO individualmente tem disponibilidade real bem menor — a análise de causa raiz precisa considerar o stack completo.

O error budget é um dos pilares da prática de observabilidade e confiabilidade em times de SRE — ele conecta diretamente as métricas de disponibilidade às decisões de engenharia.

Conclusão

O error budget é o mecanismo que transforma SLOs de documentos aspiracionais em ferramentas operacionais. Ele cria uma linguagem comum entre times de produto e engenharia, elimina discussões subjetivas sobre velocidade versus confiabilidade e fundamenta decisões de deploy em dados mensuráveis.

A implementação eficaz começa pela definição de SLOs realistas com base em histórico real, avança com a criação de uma política explícita de resposta ao consumo do budget e amadurece com a integração dos dados de error budget nos rituais de planejamento de sprint e revisão de incidentes. Para referência técnica aprofundada, o capítulo sobre Error Budgets do Google SRE Book é a fonte primária do conceito.

Para estruturar sua estratégia de SLOs e error budget, fale com nossos especialistas.