Quando a gente começa a estudar SRE, Error Budget aparece como um dos conceitos mais importantes. Ele é apresentado como o mecanismo que equilibra inovação e confiabilidade. Mas, sendo bem honesto, mesmo depois de passar por empresas grandes, multinacionais, com produtos extremamente críticos, eu sempre tive dificuldade de ver o Error Budget sendo aplicado de fato, com esse nome e com essa disciplina.
Antes de discutir se ele funciona ou não, vale dar um passo atrás e alinhar: o que é, na prática, um Error Budget?
De forma simples, o Error Budget nasce do SLO.
Se um serviço tem um SLO de 99.9% de sucesso, isso significa que ele pode falhar 0.1% do tempo ou das requisições. Esse 0.1% é o chamado orçamento de erro(Aka. Error Budget).
Ele existe para responder a uma pergunta muito concreta:
Quanto de falha esse sistema pode “gastar” sem comprometer o negócio?
Ok, ok… eu sei 😅 na vida real, o negócio quer 24×7, mesmo quando ele opera 8×5.
Ninguém “aceita” falha — pelo menos no discurso.
Mas o Error Budget existe justamente para tirar a conversa do campo do desejo e trazer datapoints reais.
Um exemplo rápido (com analogia)
Pense no Error Budget como o limite do cartão de crédito.
Você não quer estourar o limite mensal.
Mas ele existe justamente porque, em algum momento, você vai usar.
Se o seu limite é R$ 1.000:
- gastar R$ 50 é tranquilo,
- gastar R$ 900 já muda completamente o seu comportamento.
Você sabe que precisa ser mais cauteloso.
Já não dá mais pra pedir uma Coca-Cola…vai ter que ir de Dolly.
O Error Budget funciona do mesmo jeito.
Ele não existe para incentivar falhas,
mas para controlar quanto risco você pode assumir antes de precisar desacelerar.
Um exemplo rápido (sem zuera agora hehe)
Imagine um serviço que processa 1.000.000 de requisições por mês.
Com um SLO de 99.9%, o sistema pode falhar em até:
- 1.000 requisições por mês
Esse número não é um alvo.
Ele é um limite de risco aceitável.
Enquanto você estiver abaixo disso, você pode:
- Fazer novos Deploys
- Aproveitar pra colocar aquela feature mais ousada
- enfim assumir mais risco. (olha só aqui esta o principio de “Embracing risk” )
Se esse número for ultrapassado, o comportamento deveria mudar:
- menos mudanças,
- mais foco em estabilidade,
- correção de causas raiz.
Na teoria, isso cria um acordo saudável entre produto e engenharia.
O que acontece na prática?
Na maioria das empresas, o nome Error Budget nunca aparece.
Mas o comportamento… sim.
É muito comum ver:
- freeze windows depois de falhas,
- bloqueios de deploy,
- semanas “só estabilizando”.
O sistema “já falhou demais, agora não pode mais falhar”.
Isso é Error Budget, porém implementado sem acordo e baseado em pressão, percepção e crise — não em datapoints como deveria ser
Qual o real valor de utilizar “error budgets”
Existe algo importante que quase nunca aparece quando falamos de Error Budget:
ele não é só um cálculo, nem um número para ser seguido religiosamente.
Na prática, o maior valor do Error Budget não é matemático — é cultural e psicológico.
Mesmo que o negócio não concorde 100%, quando você define um SLO e um Error Budget como meta para o time de TI, você cria um novo jeito de pensar o sistema.
As pessoas começam a se perguntar:
- “Como eu faço esse deploy de forma mais segura?”
- “Será que preciso mesmo de uma janela de 4 horas?”
- “Dá pra fazer isso de forma gradual?”
- “E se eu errar, quanto isso irá consumir o orçamento mensal?”
De repente, um downtime planejado de 4 horas deixa de ser algo “normal” e passa a ser visto como algo caro. Afinal, isso pode representar metade do Error Budget do mês inteiro.
E aí o comportamento muda.
Em vez de:
- updates in place,
- mudanças grandes e arriscadas,
as equipes começam a pensar em:
- deploys graduais,
- canary,
- blue/green,
- rollback rápido,
- testes melhores,
- menos impacto para o usuário.
O Error Budget não existe para travar inovação.
Ele existe para elevar o padrão de como a inovação será entregue.
Para concluir..
No fim, Error Budget não é sobre aceitar falhas.
É sobre aceitar a realidade dos sistemas complexos.
Ele não existe para dizer “quanto você pode errar”,
mas para forçar uma pergunta muito mais difícil:
como você vai mudar a forma de construir para não precisar errar tanto?
Se o seu time começa a pensar em deploys melhores, estratégias mais seguras e menos impacto para o usuário, então o Error Budget já está funcionando — mesmo que ninguém chame assim.
