7 min leitura • Guide 107 of 877
Configurando Rotações On-Call Efetivas
Rotações on-call distribuem a responsabilidade de responder a incidentes de produção entre membros do time, garantindo que sistemas sejam monitorados 24 horas enquanto previnem que uma única pessoa carregue todo o fardo. As features de gestão de equipe do GitScrum, documentação NoteVault, e atribuição de tarefas ajudam times a organizar rotações justas, manter runbooks acessíveis, rastrear carga de incidentes, e melhorar continuamente processos on-call baseados em experiência real.
Design de Rotação
Padrões de Schedule
OPÇÕES SCHEDULE ON-CALL:
┌─────────────────────────────────────────────────────────────┐
│ PADRÕES DE ROTAÇÃO │
├─────────────────────────────────────────────────────────────┤
│ │
│ ROTAÇÃO SEMANAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Semana 1: @maria (primário), @carlos (secundário) ││
│ │ Semana 2: @carlos (primário), @ana (secundário) ││
│ │ Semana 3: @ana (primário), @pedro (secundário) ││
│ │ Semana 4: @pedro (primário), @maria (secundário) ││
│ │ ││
│ │ Handoff: Segunda 9am ││
│ │ ││
│ │ Prós: Tempo suficiente para contexto, menos handoffs ││
│ │ Contras: Semana inteira pode esgotar se ocupado ││
│ │ ││
│ │ Melhor para: Times menores, baixo volume incidentes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ROTAÇÃO DIÁRIA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Seg: @maria → Ter: @carlos → Qua: @ana → ││
│ │ Qui: @pedro → Sex: @maria → Finde: @carlos ││
│ │ ││
│ │ Handoff: 9am cada dia ││
│ │ ││
│ │ Prós: Menor carga, mais balanceado ││
│ │ Contras: Muitos handoffs, troca contexto ││
│ │ ││
│ │ Melhor para: Ambientes com muitos incidentes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FOLLOW-THE-SUN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Américas (9am-5pm EST): @maria, @carlos ││
│ │ Europa (9am-5pm CET): @ana, @pedro ││
│ │ Ásia (9am-5pm JST): @yuki, @lei ││
│ │ ││
│ │ Handoff: Na mudança de região ││
│ │ ││
│ │ Prós: Sem pages noturnos, só horário trabalho ││
│ │ Contras: Requer time distribuído ││
│ │ ││
│ │ Melhor para: Times globais ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Considerações do Time
DESIGN ROTAÇÃO JUSTA:
┌─────────────────────────────────────────────────────────────┐
│ CONSTRUINDO SCHEDULES SUSTENTÁVEIS │
├─────────────────────────────────────────────────────────────┤
│ │
│ TAMANHO MÍNIMO TIME: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Para cobertura 24/7 sem burnout: ││
│ │ ││
│ │ • 4 pessoas mínimo: 1 semana por mês cada ││
│ │ • 6 pessoas melhor: ~6 dias por mês cada ││
│ │ • 8 pessoas ideal: 1 semana a cada 2 meses ││
│ │ ││
│ │ Regra: Ninguém on-call > 25% do tempo ││
│ │ ││
│ │ Se time muito pequeno: ││
│ │ • Compartilhar rotação entre times ││
│ │ • Considerar on-call como hora extra paga ││
│ │ • Investir em reduzir incidentes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DISTRIBUIÇÃO EXPERIÊNCIA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pareando junior + senior: ││
│ │ ││
│ │ Sem 1: @senior-maria (primário), @junior-tom (shadow) ││
│ │ Sem 2: @junior-tom (primário), @senior-carlos (backup) ││
│ │ ││
│ │ Caminho progressão: ││
│ │ 1. Shadow (observar, aprender) ││
│ │ 2. Primário com backup senior ││
│ │ 3. Primário completo ││
│ │ ││
│ │ Nunca: Junior sozinho sem caminho escalonamento ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ACOMODAÇÕES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Suportar diferentes necessidades: ││
│ │ ││
│ │ • Pais com filhos pequenos: Evitar turnos noturnos ││
│ │ • Restrições timezone: Combinar com horas trabalho ││
│ │ • Férias/feriados: Planejar trocas antecipadamente ││
│ │ • Saúde/mental: Opt-out sem estigma ││
│ │ ││
│ │ Rastrear no GitScrum: ││
│ │ • Anotar restrições disponibilidade em settings ││
│ │ • Usar calendário time para visibilidade ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Rastreamento no GitScrum
Gestão Schedule
ORGANIZANDO ON-CALL NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ RASTREANDO ROTAÇÕES │
├─────────────────────────────────────────────────────────────┤
│ │
│ VISIBILIDADE ON-CALL ATUAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ NoteVault: "Schedule On-Call" ││
│ │ ││
│ │ # On-Call Atual ││
│ │ ││
│ │ **Esta Semana (Dez 16-22):** ││
│ │ - Primário: @maria ││
│ │ - Secundário: @carlos ││
│ │ ││
│ │ **Próxima Semana (Dez 23-29):** ││
│ │ - Primário: @carlos ││
│ │ - Secundário: @ana ││
│ │ ││
│ │ ## Rotação Completa ││
│ │ | Semana | Primário | Secundário | ││
│ │ |-------------|----------|------------| ││
│ │ | Dez 16-22 | Maria | Carlos | ││
│ │ | Dez 23-29 | Carlos | Ana | ││
│ │ | Dez 30-Jan 5| Ana | Pedro | ││
│ │ ││
│ │ Fixar esta nota no projeto para acesso fácil ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CHECKLIST HANDOFF TURNO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Criar tarefa recorrente: "Handoff On-Call" ││
│ │ Toda segunda às 9am ││
│ │ ││
│ │ Checklist: ││
│ │ ☐ Saindo: Postar resumo handoff em Discussions ││
│ │ ☐ Saindo: Anotar issues em andamento ││
│ │ ☐ Entrando: Confirmar que pager/telefone funciona ││
│ │ ☐ Entrando: Revisar incidentes recentes ││
│ │ ☐ Entrando: Verificar janelas manutenção agendada ││
│ │ ☐ Ambos: Confirmar handoff no canal #on-call ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Gestão Runbooks
Estrutura Documentação
ORGANIZAÇÃO RUNBOOKS:
┌─────────────────────────────────────────────────────────────┐
│ RUNBOOKS ON-CALL NO NOTEVAULT │
├─────────────────────────────────────────────────────────────┤
│ │
│ ESTRUTURA PASTAS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Runbooks/ ││
│ │ ├── Começando.md ││
│ │ ├── Referência Alertas/ ││
│ │ │ ├── Alertas Banco Dados.md ││
│ │ │ ├── Alertas API.md ││
│ │ │ ├── Alertas Pagamentos.md ││
│ │ │ └── Alertas Infraestrutura.md ││
│ │ ├── Procedimentos Comuns/ ││
│ │ │ ├── Reiniciar Serviços.md ││
│ │ │ ├── Failover Banco Dados.md ││
│ │ │ ├── Rollback Deployment.md ││
│ │ │ └── Guia Escalonamento.md ││
│ │ └── Pós-Incidente/ ││
│ │ ├── Template.md ││
│ │ └── [relatórios incidentes...] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TEMPLATE RUNBOOK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ # Runbook [Nome Alerta] ││
│ │ ││
│ │ ## O que é este alerta? ││
│ │ Explicação breve do que o disparou. ││
│ │ ││
│ │ ## Quem é paginado? ││
│ │ On-call primário, escalar para [time] se não resolvido. ││
│ │ ││
│ │ ## Severidade ││
│ │ P2 - Serviço degradado mas funcional ││
│ │ ││
│ │ ## Verificação rápida ││
│ │ 1. É falso positivo? Verificar [dashboard] ││
│ │ 2. Deploy em progresso? Verificar [status deploy] ││
│ │ ││
│ │ ## Passos resolução ││
│ │ 1. Passo um com exemplos comandos ││
│ │ 2. Passo dois com o que verificar ││
│ │ 3. Se X, fazer Y. Se Z, escalar. ││
│ │ ││
│ │ *Última atualização: Dez 16, 2024 por @maria* ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘