6 min leitura • Guide 755 of 877
Gerenciamento de Incidentes com GitScrum
Quando coisas quebram, resposta rápida importa. GitScrum ajuda times a coordenar resposta a incidentes e documentar aprendizados para prevenção futura.
Categorias de Incidentes
Níveis de Severidade
CLASSIFICAÇÃO DE SEVERIDADE DE INCIDENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEV 1 - CRÍTICO │
│ 🔴 Outage completo ou perda de dados │
│ • Todos os usuários afetados │
│ • Funcionalidade core quebrada │
│ • Violação de segurança │
│ Resposta: Todos disponíveis, escalação imediata │
│ SLA: Reconhecer < 15 min, resolver ASAP │
│ │
│ SEV 2 - ALTO │
│ 🟠 Feature principal indisponível │
│ • Muitos usuários afetados │
│ • Funcionalidade significativa quebrada │
│ • Workaround existe mas doloroso │
│ Resposta: On-call + time relevante │
│ SLA: Reconhecer < 1 hora, resolver < 4 horas │
│ │
│ SEV 3 - MÉDIO │
│ 🟡 Feature degradada │
│ • Alguns usuários afetados │
│ • Workaround existe │
│ • Feature não-crítica │
│ Resposta: On-call, escalar se necessário │
│ SLA: Reconhecer < 4 horas, resolver < 24 horas │
│ │
│ SEV 4 - BAIXO │
│ 🟢 Issue menor │
│ • Poucos usuários afetados │
│ • Workaround fácil │
│ Resposta: Processo normal de bug │
│ SLA: Triagem < 24 horas │
└─────────────────────────────────────────────────────────────┘
Resposta a Incidentes
Fluxo de Resposta
PROCESSO DE RESPOSTA A INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. DETECÇÃO │
│ ↓ │
│ • Alerta de monitoramento dispara │
│ • Usuário reporta issue │
│ • Membro do time percebe problema │
│ │
│ 2. TRIAGEM (< 15 min para SEV 1) │
│ ↓ │
│ • Avaliar severidade │
│ • Atribuir comandante de incidente │
│ • Criar tarefa de incidente no GitScrum │
│ • Notificar stakeholders │
│ │
│ 3. INVESTIGAÇÃO │
│ ↓ │
│ • Reunir time (war room se necessário) │
│ • Revisar logs, métricas, mudanças recentes │
│ • Identificar causa raiz │
│ • Documentar achados em tempo real │
│ │
│ 4. MITIGAÇÃO │
│ ↓ │
│ • Implementar fix ou workaround │
│ • Rollback se necessário │
│ • Verificar resolução │
│ • Monitorar recorrência │
│ │
│ 5. COMUNICAÇÃO │
│ ↓ │
│ • Atualizar página de status │
│ • Notificar usuários afetados │
│ • Update para stakeholders internos │
│ │
│ 6. FOLLOW-UP │
│ • Post-mortem dentro de 48 horas │
│ • Action items rastreados no GitScrum │
│ • Melhorias de processo identificadas │
└─────────────────────────────────────────────────────────────┘
Estrutura de Tarefa de Incidente
TAREFA DE INCIDENTE NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ 🔴 INC-047: Erros 503 API - Serviço de Pagamento │
├─────────────────────────────────────────────────────────────┤
│ │
│ Severidade: SEV 1 - CRÍTICO │
│ Status: 🔥 Incidente Ativo │
│ Comandante: @alex │
│ Iniciado: 2024-01-15 14:32 UTC │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ IMPACTO: │
│ • Todo processamento de pagamento falhando │
│ • ~100% das tentativas de checkout afetadas │
│ • Iniciou: 14:32 UTC │
│ • Duração: 45 minutos (em andamento) │
│ │
│ TIMELINE: │
│ 14:32 - Alerta: Taxa de erro API Pagamento > 50% │
│ 14:35 - @alex paginado, assumiu como IC │
│ 14:40 - @sarah e @mike entraram para investigar │
│ 14:45 - Identificado: Pool de conexões BD esgotado │
│ 14:50 - Fix tentado: Reiniciar serviço de pagamento │
│ 14:55 - Serviço reiniciado, monitorando │
│ 15:10 - Taxa de erro normalizada │
│ │
│ CAUSA RAIZ: │
│ Vazamento de conexão de BD no release recente │
│ Deploy de v2.3.4 na quinta introduziu o bug │
│ │
│ RESOLUÇÃO: │
│ • Imediata: Reiniciar serviço │
│ • Curto prazo: Rollback para v2.3.3 │
│ • Longo prazo: Corrigir vazamento de conexão │
└─────────────────────────────────────────────────────────────┘
Template de Post-Mortem
Estrutura do Post-Mortem
POST-MORTEM: INC-047 - Falha do Serviço de Pagamento
═══════════════════════════════════════════════════════════════
DATA DO INCIDENTE: 2024-01-15
SEVERIDADE: SEV 1
DURAÇÃO: 38 minutos
IMPACTO: 100% das transações de pagamento falharam
───────────────────────────────────────────────────────────────
SUMÁRIO EXECUTIVO:
───────────────────────────────────────────────────────────────
Um bug de vazamento de conexão de banco de dados no release
v2.3.4 causou esgotamento do pool de conexões após 6 horas,
resultando em 38 minutos de outage completo de pagamentos.
───────────────────────────────────────────────────────────────
TIMELINE:
───────────────────────────────────────────────────────────────
08:00 - v2.3.4 deployado para produção
08:00-14:30 - Sistema funcionando mas vazando conexões
14:32 - Pool de conexões esgotado, erros começaram
14:35 - Alerta disparou, IC @alex atribuído
14:45 - Causa raiz identificada
14:55 - Serviço reiniciado
15:10 - Sistema totalmente recuperado
───────────────────────────────────────────────────────────────
CAUSA RAIZ:
───────────────────────────────────────────────────────────────
Mudança de código em v2.3.4 introduziu path onde conexões
de BD não eram liberadas após tratamento de erro. Sob carga
normal, conexões vazavam ~10/hora até pool esgotar (600 max).
───────────────────────────────────────────────────────────────
ACTION ITEMS:
───────────────────────────────────────────────────────────────
| # | Item | Dono | Due |
|---|-----------------------------------|--------|--------|
| 1 | Corrigir vazamento de conexão | Sarah | Jan 16 |
| 2 | Adicionar monitoramento pool conn | Mike | Jan 18 |
| 3 | Adicionar alerta uso pool > 80% | Alex | Jan 18 |
| 4 | Review padrões de BD no code review| Jordan| Jan 20 |
| 5 | Load test com conn tracking | QA | Jan 22 |
───────────────────────────────────────────────────────────────
LIÇÕES APRENDIDAS:
───────────────────────────────────────────────────────────────
• Monitoramento de conexão de BD é crítico
• Load testing precisa incluir conn tracking
• 6 horas de detecção muito longo—precisa alertas mais cedo
Papéis no Incidente
| Papel | Responsabilidades |
|---|---|
| Comandante | Coordena resposta, toma decisões |
| Tech Lead | Lidera investigação, implementa fixes |
| Comunicação | Atualiza status, notifica usuários |
| Escriba | Documenta timeline, prepara post-mortem |