Pular para o conteúdo

Plantão sustentável

Intermediário16 min de leiturasre

Plantão é um custo real que a empresa impõe a pessoas reais: sono interrompido, fim de semana com o celular por perto, atenção dividida. Ele se justifica quando o serviço precisa mesmo de resposta fora do horário — e só continua funcionando se for tratado como compromisso mútuo, com limite e contrapartida. Plantão ruim não pede demissão; ele produz rotatividade meses depois, e a empresa raramente liga uma coisa à outra.

  • Volume. Mais de um ou dois acionamentos noturnos por semana é sinal de defeito no sistema ou nos alertas, não de azar.
  • Escopo indefinido. Quem é acionado para “qualquer coisa que quebre” não tem como estar preparado.
  • Sem autoridade. Ser acordado para pedir autorização a outra pessoa é o pior dos mundos: acorda dois e resolve nada.
  • Sem compensação. Estar disponível é trabalho. Folga, adicional ou banco de horas — combinado por escrito e alinhado às regras trabalhistas, incluindo o sobreaviso da CLT quando aplicável.
  • Sem tempo para consertar. Se todo sprint está cheio de funcionalidade, o que causou o acionamento nunca é corrigido e você recebe o mesmo alerta no mês seguinte.

Turnos semanais funcionam melhor que diários: menos passagens de contexto. Com menos de quatro ou cinco pessoas, a frequência fica pesada — nesse caso, junte serviços parecidos em um único plantão ou aceite janela reduzida em vez de 24×7.

Regras que evitam desgaste:

  • Sempre um secundário, com escalonamento automático se o primário não confirmar em poucos minutos. Ninguém deve depender de acordar no primeiro toque.
  • Trocas fáceis e sem constrangimento, registradas na ferramenta.
  • Quem passou a noite acordado não trabalha no dia seguinte. Isso precisa ser regra explícita da liderança, ou vira favor que ninguém pede.
  • Quem escreve o serviço entra no plantão dele. É o incentivo mais eficaz que existe para confiabilidade.
  • Ninguém entra sozinho no primeiro turno: acompanhe alguém experiente antes.

Todo alerta que pagina precisa de um runbook ligado a ele pelo campo de anotação. O runbook não é documentação de arquitetura — é uma sequência executável por alguém com sono.

# CheckoutBurnRateAlta
**O que significa.** O checkout está falhando acima do orçamento de erro.
Pessoas não conseguem comprar. Sev 1 se a taxa passar de 10%.
**Verifique (2 min)**
kubectl rollout history deployment/checkout -n prod
kubectl logs -l app=checkout -n prod --since=15m | grep -i error | tail -20
Painel: https://grafana.exemplo.com/d/checkout
**Mitigue**
1. Deploy nos últimos 60 min? → `kubectl rollout undo deployment/checkout -n prod`
2. Erro do gateway de pagamento? → ligue a flag `pagamento.fila_assincrona`
3. Pool de conexões saturado? → escale para 12 réplicas e avise o time de dados
**Escale para** @time-pagamentos (Slack #pagamentos) se não normalizar em 20 min.
**Não faça** reiniciar o banco. Fale com o time de dados primeiro.

Comando pronto para copiar, caminho de escalonamento e o que não fazer. Runbook não testado é ficção: valide durante o game day e corrija quem executou pela última vez.

Quinze minutos no fim do turno, por escrito no canal: o que aconteceu, o que continua aberto, o que foi silenciado e até quando, o que provavelmente vai acionar. Sem isso, a pessoa seguinte descobre o silêncio expirando às duas da manhã.

Números, não impressões. Revise por trimestre:

# acionamentos por semana, por serviço
sum by (service) (increase(alertmanager_notifications_total{integration="pagerduty"}[7d]))
# quanto foi fora do horário comercial
sum(increase(ALERTS{severity="page"}[30d]))

Acompanhe: acionamentos por turno, quantos fora do horário, quantos exigiram ação real, tempo até mitigação e quantos alertas repetiram do turno anterior. Se um serviço domina a lista, o trabalho não é ajustar a escala — é corrigir aquele serviço, e o orçamento de erro dá o argumento para priorizar.

Uma pergunta fecha a revisão melhor que qualquer métrica: alguém aqui evitaria mudar de time por causa do plantão? Se a resposta for sim, você já tem o problema, só ainda não tem o pedido de demissão.

Próximo passo: parte dos acionamentos é falta de folga planejada. Continue em Planejamento de capacidade.