A velocidade de entrega deve obedecer ao error budget
Nem lançar sempre, nem congelar sempre. Uma equipa madura decide quanto risco de fiabilidade pode consumir e muda de comportamento quando o serviço ultrapassa esse limite.
- Natureza
- Perspetiva Velqory baseada em práticas públicas de SRE e DORA
- Decisão
- Quando acelerar, limitar ou redirecionar mudanças de produção
- Publicado e verificado
- 4 de agosto de 2026
- Limite
- SLO e política de budget devem refletir utilizadores, risco e arquitetura reais
Em resumo
A posição da Velqory é que velocidade e fiabilidade não são objetivos que equipas diferentes devem negociar por opinião. Um SLO útil define a experiência que importa; o error budget traduz a tolerância restante num limite mensurável. A prática de SRE liga esse limite a decisões de lançamento. DORA, por sua vez, mede throughput e instabilidade para evitar otimizar apenas uma dimensão. O error budget não deve ser uma desculpa automática para parar toda a mudança: precisa de janelas, exceções, fontes de consumo e políticas proporcionais. Quando bem desenhado, permite lançar mais depressa enquanto há margem e desloca capacidade para recuperação quando o produto prova que a margem acabou.
- Defina SLO a partir da jornada do utilizador, não da métrica mais fácil de recolher.
- Converta o SLO num orçamento finito e associe estados de consumo a decisões previamente acordadas.
- Separe mudança que aumenta risco de mudança que reduz risco; um congelamento cego pode impedir a recuperação.
- Leia métricas DORA em conjunto: velocidade sem estabilidade e estabilidade sem fluxo podem esconder problemas diferentes.
Fiabilidade é uma decisão de produto antes de ser uma métrica
Cem por cento de disponibilidade é normalmente um alvo caro, rígido e por vezes impossível. Um objetivo demasiado baixo normaliza uma experiência inaceitável. O SLO obriga produto, engenharia e operação a declarar qual nível de serviço é realmente necessário e em que janela será medido.
O error budget é a distância entre o objetivo e a perfeição durante essa janela. Se o SLO for cumprido com margem, existe capacidade para aceitar mudança e experimentação. Se a margem é consumida, a evidência diz que o sistema está a impor custo aos utilizadores e que parte da capacidade deve regressar à fiabilidade.
O ciclo de uma política executável
- 1. DefinirEscolher jornada e indicador
Identificar quem usa, que pedido importa, o que conta como sucesso e que exclusões são legítimas.
- 2. CalibrarFixar objetivo e janela
Comparar expectativa, baseline, custo, dependências e consequência de falha.
- 3. ConsumirObservar origem do erro
Distinguir deploy, capacidade, fornecedor, dados, operação manual e medição defeituosa.
- 4. DecidirAplicar o estado acordado
Acelerar, manter, limitar risco ou priorizar recuperação consoante a margem restante.
- 5. AprenderRever produto e política
Usar incidentes, utilização e custo para ajustar arquitetura, SLO ou resposta, sem apagar o histórico.
O budget deve travar risco, não toda a mudança
Um freeze absoluto pode impedir patches, correções de capacidade e remoção do próprio defeito que consome o orçamento. Classifique mudanças pelo efeito esperado e reversibilidade. A regra deve ser mais exigente com uma experiência nova de grande blast radius do que com um rollback ensaiado ou uma correção pequena que reduz erro observado.
Também evite atribuir todo o consumo ao último deploy. Dependências, tráfego, dados, operações manuais e dívida de capacidade podem degradar o serviço. A política serve para direcionar investigação e investimento, não para procurar uma equipa culpada.
Estados de consumo e decisões de entrega
| Estado | Leitura | Decisão de mudança |
|---|---|---|
| Saudável | Consumo abaixo da trajetória e tendência estável | Fluxo normal, experiências controladas e investimento preventivo |
| A observar | Consumo acelera ou aproxima-se da trajetória | Rever causas, reduzir blast radius e reforçar canary e rollback |
| Em risco | Margem pequena para o resto da janela | Admitir apenas valor urgente, segurança e redução comprovável de risco |
| Esgotado | SLO já não é atingível na janela | Priorizar recuperação; exceções explícitas com dono, prazo e risco aceite |
| Crónico | Várias janelas falham ou o objetivo nunca influencia decisões | Rever arquitetura, capacidade, produto e validade do próprio SLO |
Não use uma única métrica para declarar uma equipa rápida
DORA organiza desempenho de entrega em métricas que cobrem throughput e instabilidade. Lead time e frequência mostram fluxo; taxa de falha de mudança e tempo de recuperação mostram consequência e resposta. A interpretação deve considerar contexto, tendência e unidade do serviço, não transformar benchmarks em metas locais cegas.
Combine estes sinais com o error budget. Uma equipa pode lançar frequentemente e manter o SLO porque usa lotes pequenos, automação e rollback rápido. Outra pode lançar raramente e ainda causar grande instabilidade. O objetivo é criar feedback curto e reversível, não maximizar o contador de deployments.
- Publicar SLO, erro restante, trajetória e principais fontes de consumo.
- Definir classes de mudança permitidas em cada estado antes do incidente.
- Medir qualidade da deteção e do rollback, não só tempo até encerrar o ticket.
- Rever se o indicador representa a experiência real e não apenas saúde interna.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01Embracing Risk, error budgetsGoogle Site Reliability Engineering · SYS-GOOGLESRE
- 02Service Level ObjectivesGoogle Site Reliability Engineering · SYS-GOOGLESRE
- 03Product-focused reliability for SREGoogle Site Reliability Engineering · SYS-GOOGLESRE
- 04DORA software delivery performance metricsDORA · SYS-DORA
- 05SLO adoption and usageGoogle Site Reliability Engineering · SYS-GOOGLESRE
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.