SkillOperaçõesCriação
Desenho de Rotação de On-Call
Projeta uma escala de on-call sustentável para times de produção, com regras claras de paging, fairness e prevenção de burnout.
Ações
PerfilOperações
ProfundidadeAlta
IdiomaPortuguês
Objetivo
Em uma frase.
Produzir o desenho completo de uma rotação de on-call para um time que opera serviços de produção: quem entra, em qual ciclo, sob quais regras de paging, com qual escalation, com qual compensação e com qual política de cobertura. A saída é um documento operável que pode ir direto para PagerDuty/Opsgenie e para o handbook do time.
Aplicação
Quando
faz sentido.
Usar
- Time vai entrar pela primeira vez em on-call e não existe rotação formalizada ainda.
- Rotação atual está gerando burnout, churn ou reclamações recorrentes.
- Time cresceu (ou encolheu) e a escala precisa ser redimensionada.
- Houve fusão de squads, mudança de stack ou novo serviço crítico entrou no escopo.
- Auditoria de operações apontou ausência de política formal de paging/escalation.
Não usar
- Para incidente em curso → use runbook-writer ou incident-severity-triage.
- Para protocolo de escalation em si (árvore de contatos, decision rights) → use escalation-protocol.
- Para definir severidade dos incidentes que ativam o paging → use incident-severity-triage.
- Para postmortem após incidente → use incident-postmortem.
Prompt
Instruções
para a IA.
Passo 1 — Validar viabilidade da rotação
Antes de desenhar qualquer escala, validar se o time tem massa crítica para suportá-la. Regra prática Gzero:
- 24x7 com primário+secundário: mínimo de 6 pessoas elegíveis. Abaixo disso, a rotação fica em ciclo 1-em-3 ou pior e gera burnout previsível.
- 24x7 só primário: mínimo de 4 pessoas. Aceitável apenas se volume de páginas semanal for baixo (< 3 acionáveis).
- Business hours estendido (ex: 8h-22h): mínimo de 3 pessoas.
- Follow-the-sun: mínimo de 2 pessoas por fuso, com ao menos 2 fusos cobertos.Se o time não atingir o mínimo, registrar isso explicitamente como risco e propor alternativas: contratar antes de ativar, terceirizar NOC de primeiro nível, reduzir escopo coberto, mover serviços para business hours.
Passo 2 — Definir o ciclo da rotação
O ciclo determina quanto tempo cada pessoa fica responsável. Escolher um dos formatos:
- Semanal (segunda 9h → segunda 9h): padrão para times pequenos (4-8 pessoas). Vantagem: continuidade dentro da semana. Desvantagem: fim de semana inteiro on-call cansa.
- Quinzenal: raramente recomendado. Difícil sustentar foco por duas semanas.
- Split weekly (dias úteis + final de semana separados): times com alto volume noturno. Reduz o impacto do fim de semana, mas aumenta complexidade da escala.
- Diário rotativo (1 dia primário): apenas para times muito grandes (>15 pessoas). Risco: perda de contexto entre incidentes do mesmo dia.Default Gzero: semanal com handoff na segunda-feira de manhã, com uma reunião de handoff de 15 minutos.
Passo 3 — Decidir primário + secundário (shadow / backup)
Toda rotação 24x7 deve ter dois níveis:
- Primário: recebe a página primeiro. Tem 5 minutos para acknowledge.
- Secundário (backup): acionado se o primário não der ack em 5 minutos, ou se o primário pedir escalation. Também serve como par para incidentes complexos.Para times pequenos (<6 pessoas), o secundário pode rotacionar em ciclo diferente do primário (ex: primário semanal, secundário quinzenal) para evitar sobreposição.
Documentar: quem é primário e quem é secundário na mesma semana não pode estar de férias simultaneamente.
Passo 4 — Definir critérios de elegibilidade
Nem todo membro do time deve entrar na rotação de cara. Critérios mínimos:
- [ ] Tem acesso de produção configurado e testado.
- [ ] Concluiu pelo menos uma rodada de shadow (acompanhou alguém de plantão por 1 semana).
- [ ] Conhece os 3-5 runbooks principais do serviço.
- [ ] Sabe onde estão dashboards, logs, paging tool e canal de incident.
- [ ] Tem cobertura de comunicação (laptop + celular + internet de backup em casa, ou plano de fallback).Pessoas em onboarding (<60 dias) entram só como shadow, sem ser pageadas diretamente.
Passo 5 — Definir política de paging
Política de paging = regras objetivas sobre o que acorda alguém às 3h da manhã. Toda página deve ser:
- Acionável: existe ação humana imediata que muda o estado do sistema.
- Urgente: não pode esperar até o próximo dia útil.
- Específica: o alerta diz qual sistema, qual sintoma, qual runbook seguir.Páginas que não justificam acordar alguém: - Alerta informativo (warning, não crítico). - Métrica que oscila mas tem auto-recovery. - Falha em job batch que pode rodar de manhã.
Output: lista de classes de alerta que pageiam vs. que vão para canal de baixa prioridade (Slack durante horário comercial).
Passo 6 — Desenhar escalation
Definir explicitamente o que acontece se o primário não conseguir resolver. Estrutura mínima:
``
Página recebida → Primário (5 min ack)
↓ se sem ack em 5 min
Secundário (5 min ack)
↓ se sem ack em 5 min OU se primário pediu escalation
Manager on-call / Líder técnico de plantão
↓ se incidente P0/P1 não resolvido em 30 min
Diretor / VP de engenharia
↓ se exposição externa (cliente, mídia, regulador)
Liderança executiva + Comunicação
`
Para detalhes da árvore de contatos por papel, ver escalation-protocol.
Passo 7 — Definir compensação
On-call sem compensação adequada é receita para churn. Modelos comuns:
- Stipend fixo: valor por semana de plantão (ex: R$ 800/semana de primário, R$ 300/semana de secundário). Pago independente de volume.
- Pagamento por hora ativa: registro de horas trabalhadas durante incident, com multiplicador (1,5x a 2x).
- Time off em troca: dia de folga após semana de plantão com >X horas de incident.
- Híbrido: stipend fixo + horas ativas acima de threshold.
Default Gzero: stipend fixo + folga compensatória se houver >4 horas ativas fora do horário comercial na semana. Registrar a política por escrito e revisar anualmente.
Passo 8 — Política de cobertura para férias, doença e overlap
Toda rotação precisa de regras explícitas para:
- Férias: anunciar com ≥30 dias de antecedência. Pessoa de férias não está na escala. Quem cobre é definido na hora da troca, não no momento da página.
- Doença/imprevisto: canal específico (#oncall-coverage) para pedir troca. Tempo de resposta esperado: 1h em horário comercial, 2h fora.
- Trocas voluntárias: permitidas até 48h antes do início do turno. Após isso, requer ok do manager.
- Conflito com viagem/compromisso: trocas pessoais são responsabilidade da pessoa; manager só intervém em caso de impasse.
Definir um secondary-of-the-secondary (terceiro nível) só para imprevistos críticos.
Passo 9 — Documentar e configurar na ferramenta
Saída final deve ser um documento que vire configuração real:
- Escala dos próximos 3 meses no PagerDuty/Opsgenie.
- Página no handbook do time com a política completa.
- Canal Slack dedicado (#team-oncall`).
- Rota de paging configurada e testada (dry run obrigatório).Toda mudança na política passa por revisão do líder técnico + manager do time.
Passo 10 — Definir métricas de saúde da rotação
Não basta criar a rotação; é preciso medir se ela está saudável. Métricas obrigatórias:
- Páginas/semana por pessoa: alvo < 5 acionáveis. Acima disso, revisar alertas.
- Páginas fora do horário comercial: % do total. Alvo < 30%.
- Tempo médio de ack: alvo < 3 min.
- Trocas voluntárias por mês: sinal de fricção pessoal. Alvo < 2 por pessoa.
- NPS interno da rotação: pulso trimestral. Pergunta: "0-10, o on-call deste time é sustentável para você?"Revisão da rotação a cada trimestre, ou imediatamente após incidente que expôs falha estrutural.
Constelação
Onde
ela vive.
Bundles que incluem
Execução
Como usar
com IA.
- 01Copie a skill (botão "Copiar skill para IA", no topo): o texto copiado já é a skill completa, não um resumo.
- 02Abra o Claude ou Claude Code e cole — a IA recebe todas as instruções e fica pronta para a tarefa.
- 03Prefere usar como arquivo reutilizável? Baixe o .zip e coloque o
SKILL.mdem.claude/skills/(Claude Code) ou anexe o arquivo no Claude (claude.ai).