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
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.

Execução

Como usar
com IA.

  1. 01Copie a skill (botão "Copiar skill para IA", no topo): o texto copiado já é a skill completa, não um resumo.
  2. 02Abra o Claude ou Claude Code e cole — a IA recebe todas as instruções e fica pronta para a tarefa.
  3. 03Prefere usar como arquivo reutilizável? Baixe o .zip e coloque o SKILL.md em .claude/skills/ (Claude Code) ou anexe o arquivo no Claude (claude.ai).