7 min leitura • Guide 756 of 877
Gestão de On-Call com GitScrum
On-call não deveria esgotar seu time. GitScrum ajuda a gerenciar tarefas de on-call, rastrear incidentes e garantir rotação justa de responsabilidades.
Fundamentos de On-Call
Por que On-Call Existe
PROPÓSITO E OBJETIVOS DE ON-CALL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROPÓSITO: │
│ Garantir que alguém está sempre disponível para responder │
│ a problemas de produção que afetam usuários. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ON-CALL SAUDÁVEL: │
│ │
│ ✅ Rotação justa entre time │
│ ✅ Expectativas claras e runbooks │
│ ✅ Compensação apropriada │
│ ✅ Baixa taxa de falsos alarmes │
│ ✅ Carga de trabalho sustentável │
│ ✅ Aprendizado de incidentes │
│ │
│ ON-CALL NÃO SAUDÁVEL: │
│ │
│ ❌ Mesmas pessoas sempre on-call │
│ ❌ Falsos alarmes constantes (alert fatigue) │
│ ❌ Sem documentação ou runbooks │
│ ❌ Espera-se resolver tudo sozinho │
│ ❌ Sem compensação de tempo │
│ ❌ Burnout e turnover │
│ │
│ PRINCÍPIO DE ON-CALL: │
│ Se você constrói, você opera │
│ Time possui seus serviços end-to-end │
│ Cria accountability e melhor design │
└─────────────────────────────────────────────────────────────┘
Configuração de Rotação
Construindo a Escala
DESIGN DE ROTAÇÃO DE ON-CALL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OPÇÕES DE ROTAÇÃO: │
│ │
│ ROTAÇÃO SEMANAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Semana 1: @alex (primário) / @maria (secundário) ││
│ │ Semana 2: @maria (primário) / @jordan (secundário) ││
│ │ Semana 3: @jordan (primário) / @chen (secundário) ││
│ │ Semana 4: @chen (primário) / @alex (secundário) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Melhor para: Times maiores, menor volume de páginas │
│ │
│ ROTAÇÃO DIÁRIA: │
│ Cada pessoa on-call por 1-2 dias │
│ Melhor para: Alto volume de páginas, mais pessoas │
│ │
│ FOLLOW-THE-SUN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 00:00-08:00 UTC: Time APAC ││
│ │ 08:00-16:00 UTC: Time EMEA ││
│ │ 16:00-00:00 UTC: Time Americas ││
│ └─────────────────────────────────────────────────────────┘│
│ Melhor para: Times globais, sem turnos noturnos │
│ │
│ REGRAS DE JUSTIÇA: │
│ │
│ • Rotacionar igualmente (rastrear em planilha) │
│ • Sem turnos consecutivos sem consentimento │
│ • Feriado/fim de semana = consideração extra │
│ • Permitir trocas de turno │
│ • Novos membros fazem shadow antes de solo │
│ • Compensar apropriadamente │
└─────────────────────────────────────────────────────────────┘
Caminho de Escalação
ESTRUTURA DE ESCALAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NÍVEL 1: On-Call Primário │
│ ↓ (se sem resposta em 15 min) │
│ │
│ NÍVEL 2: On-Call Secundário │
│ ↓ (se sem resposta em 15 min) │
│ │
│ NÍVEL 3: Tech Lead / Manager │
│ ↓ (se SEV 1 ou impacto de negócio) │
│ │
│ NÍVEL 4: VP Engineering / Executivo │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REGRAS DE ESCALAÇÃO: │
│ │
│ AUTO-ESCALAR QUANDO: │
│ • Sem acknowledgment em 15 minutos │
│ • Duração do incidente > 30 minutos │
│ • SEV 1 (sempre notificar liderança) │
│ • Issue reportado por cliente │
│ │
│ PRIMÁRIO DEVE ESCALAR QUANDO: │
│ • Não consegue resolver sozinho │
│ • Precisa de acesso que não tem │
│ • Decisão de negócio necessária │
│ • Impacto maior que esperado │
│ │
└─────────────────────────────────────────────────────────────┘
Documentação
Runbooks
ESTRUTURA DE RUNBOOK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RUNBOOK: [Nome do Alerta] │
│ ────────────────────────── │
│ │
│ SEVERIDADE: SEV 2 │
│ TEMPO ESPERADO: 15-30 min │
│ │
│ O QUE SIGNIFICA: │
│ [Explicação clara do que disparou o alerta] │
│ │
│ IMPACTO: │
│ [Quem é afetado e como] │
│ │
│ DIAGNÓSTICO: │
│ 1. Verificar [dashboard link] │
│ 2. Checar logs: [comando ou link] │
│ 3. Verificar dependências │
│ │
│ REMEDIAÇÃO: │
│ Opção A: [Passos para fix mais comum] │
│ Opção B: [Passos para segundo fix comum] │
│ Opção C: Escalar para [pessoa/time] │
│ │
│ ESCALAÇÃO: │
│ Se não resolvido em 30 min → @secondary │
│ Se SEV 1 ou impacto de cliente → @manager │
│ │
│ LINKS ÚTEIS: │
│ • Dashboard: [link] │
│ • Logs: [link] │
│ • Incidentes anteriores: [link] │
│ │
└─────────────────────────────────────────────────────────────┘
Rastreamento no GitScrum
Tarefas de On-Call
GESTÃO DE TAREFAS ON-CALL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFA DE ON-CALL: │
│ ─────────────────── │
│ │
│ Título: [ON-CALL] Turno 15-21 Jan - @alex │
│ │
│ Descrição: │
│ Turno de on-call semanal │
│ │
│ CHECKLIST INÍCIO: │
│ ☐ Acesso a PagerDuty verificado │
│ ☐ VPN funcionando │
│ ☐ Runbooks revisados │
│ ☐ Contato do secundário confirmado │
│ │
│ INCIDENTES DURANTE TURNO: │
│ • 16 Jan 03:00 - Database latency (resolvido 03:45) │
│ • 18 Jan 14:00 - Deploy falhou (resolvido 14:30) │
│ │
│ HANDOFF: │
│ ☐ Incidentes documentados │
│ ☐ Issues pendentes comunicados │
│ ☐ Próximo on-call notificado │
│ │
│ Labels: on-call, sprint-12 │
│ │
└─────────────────────────────────────────────────────────────┘
Ajuste de Capacidade
CAPACIDADE DE SPRINT COM ON-CALL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEM ON-CALL: │
│ ───────────── │
│ @alex: 10 pontos disponíveis │
│ │
│ COM ON-CALL: │
│ ───────────── │
│ @alex: 6 pontos disponíveis (-40%) │
│ │
│ REDUÇÃO RECOMENDADA: │
│ ────────────────────── │
│ On-call primário: -30% a -50% │
│ On-call secundário: -10% a -20% │
│ │
│ RAZÃO: │
│ ──────── │
│ • Interrupções imprevisíveis │
│ • Context switching │
│ • Recuperação de incidentes noturnos │
│ • Documentação pós-incidente │
│ │
│ PLANEJAMENTO: │
│ ───────────── │
│ • Não atribuir trabalho crítico de deadline │
│ • Tarefas menores e interrompíveis │
│ • Trabalho de melhoria de on-call (runbooks) │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE ON-CALL
════════════════════
ROTAÇÃO:
☐ Escala justa e documentada
☐ Primário e secundário definidos
☐ Processo de troca de turno
☐ Compensação definida
DOCUMENTAÇÃO:
☐ Runbooks para alertas principais
☐ Caminhos de escalação claros
☐ Contatos de emergência atualizados
☐ Acesso a ferramentas verificado
TOOLING:
☐ Sistema de alerting configurado
☐ Dashboards de monitoramento
☐ Canais de comunicação
☐ Acesso remoto funcionando
SUSTENTABILIDADE:
☐ Capacidade de sprint ajustada
☐ Post-mortems realizados
☐ Melhoria contínua de alertas
☐ Feedback do time coletado
On-call sustentável protege produção sem queimar o time.