← Voltar ao blog

Escalas de on-call que o time aceita: cinco decisões de design

On-call mal desenhado cobra o preço na retenção: quem acorda três noites seguidas atualiza o currículo na semana seguinte. Antes de escolher ferramenta de alerta, cinco decisões de design determinam se a escala aguenta seis meses. As decisões abaixo vêm de times de 8 a 40 pessoas com plantão próprio, e cada uma fecha com um número que o time acompanha.

Uma pessoa acorda, no máximo, por noite

Teto de páginas por semana e turno com descanso. O livro Site Reliability Engineering (Beyer et al., O'Reilly, 2016) trata fadiga de plantão como risco de projeto e prega revezamento com tempo de recuperação. Combine com limite de eventos: acima de três incidentes em sete dias, o próximo passo é estabilizar a causa em vez de rotear mais páginas. Publique o número no painel do time.

Handover escrito no fim de cada turno

Seis linhas: o que mudou, o que está instável, a quem chamar. Sem handover, o turno seguinte descobre o sistema por tentativa. O Building Secure and Reliable Systems (Google, O'Reilly, 2020) liga operação com contexto explícito à redução de erro humano e trata a troca de turno como parte do trabalho. O registro fica no canal do plantão e vira matéria-prima do postmortem.

Runbook antes do alerta

Nenhum alerta entra na escala sem ação documentada. Cada alerta aponta para um runbook de dez linhas: o que olhar, o que é grave, quem decide rollback. Alerta sem runbook treina o plantão a ligar para alguém. Comece pelos alertas que acordam o time mais de duas vezes por semana e deixe o resto fora da lista. Guarde o runbook no mesmo diretório do serviço, porque runbook em wiki fora do repositório envelhece em semanas.

Quem entra na rotação

Pleno e sênior juntos, com dupla nos primeiros três meses. O engenheiro novo roda o plantão com alguém experiente até fechar cinco turnos sem escalonar erro. Quem treina gente em plantão ganha dois turnos a menos na conta da semana, e a troca aparece no relatório.

Custo medido em sono e em retrabalho

Duas métricas: interrupções por noite e horas de estabilização. O State of DevOps Report da DORA lê estabilidade e burnout na mesma análise: time que entrega rápido e queima entrega menos no trimestre seguinte. Leve as duas métricas para a revisão de escala a cada quarter, junto com a lista de páginas por causa raiz.

Enfrentando esse desafio na sua empresa?

Ajudo CTOs e times de engenharia a resolver problemas como este.

Agendar uma conversa
Marc Reinan Gomes
Marc Reinan Gomes Staff Engineer & Consultor

14+ anos construindo produtos, liderando times e ajudando empresas a escalar com qualidade técnica.

Compartilhar no LinkedIn