8 min leitura • Guide 95 of 877
Lidando com Problemas Urgentes de Produção
Incidentes de produção demandam resposta imediata e coordenada. As capacidades de gestão de incidentes do GitScrum ajudam times a responder rapidamente através de workflows de escalação dedicados, integração de comunicação em tempo real, e rastreamento estruturado de incidentes. A chave é ter playbooks ensaiados para que times ajam instintivamente ao invés de descobrir coisas sob pressão, depois conduzir post-mortems completos para prevenir recorrência.
Framework Resposta Incidentes
Classificação Severidade
NÍVEIS SEVERIDADE INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ DEFININDO SEVERIDADE │
├─────────────────────────────────────────────────────────────┤
│ │
│ SEV-1: CRÍTICO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Definição: ││
│ │ • Serviço core completamente fora ││
│ │ • Perda dados ou brecha segurança ││
│ │ • Todos clientes afetados ││
│ │ ││
│ │ Exemplos: ││
│ │ • Banco dados produção offline ││
│ │ • Processamento pagamentos falhou ││
│ │ • Sistema autenticação fora ││
│ │ ││
│ │ Resposta: ││
│ │ • Todos a postos imediatamente ││
│ │ • Liderança notificada em 5 minutos ││
│ │ • Comunicação cliente em 15 minutos ││
│ │ • Updates contínuos até resolver ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SEV-2: ALTO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Definição: ││
│ │ • Feature importante indisponível ││
│ │ • Degradação performance significativa ││
│ │ • Muitos clientes afetados ││
│ │ ││
│ │ Resposta: ││
│ │ • Time on-call ativo em 15 minutos ││
│ │ • Horário comercial: team lead informado ││
│ │ • Updates a cada 30 minutos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SEV-3: MÉDIO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Definição: ││
│ │ • Problemas feature menor ││
│ │ • Workaround disponível ││
│ │ • Alguns clientes afetados ││
│ │ ││
│ │ Resposta: ││
│ │ • Atender dentro do dia útil ││
│ │ • Rastrear no workflow normal ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Papéis Incidente
ESTRUTURA TIME RESPOSTA:
┌─────────────────────────────────────────────────────────────┐
│ ATRIBUIÇÃO PAPÉIS │
├─────────────────────────────────────────────────────────────┤
│ │
│ COMANDANTE INCIDENTE (IC): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUEM: Engenheiro on-call ou líder designado ││
│ │ ││
│ │ RESPONSABILIDADES: ││
│ │ • Coordena todas atividades resposta ││
│ │ • Toma decisões de escalação ││
│ │ • Atribui tarefas aos membros do time ││
│ │ • Decide quando declarar "resolvido" ││
│ │ ││
│ │ NÃO RESPONSÁVEL POR: ││
│ │ • Debugar código (delega a outros) ││
│ │ • Escrever comunicações cliente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LÍDER TÉCNICO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUEM: Engenheiro mais experiente disponível ││
│ │ ││
│ │ RESPONSABILIDADES: ││
│ │ • Investiga causa raiz ││
│ │ • Implementa fixes ││
│ │ • Aconselha IC em decisões técnicas ││
│ │ • Coordena com outros engenheiros ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LÍDER COMUNICAÇÕES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUEM: PM, líder suporte, ou comunicador designado ││
│ │ ││
│ │ RESPONSABILIDADES: ││
│ │ • Atualiza página status ││
│ │ • Notifica stakeholders ││
│ │ • Responde consultas clientes ││
│ │ • Mantém timeline incidente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ESCRIBA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUEM: Qualquer membro time disponível ││
│ │ ││
│ │ RESPONSABILIDADES: ││
│ │ • Documenta tudo em tempo real ││
│ │ • Registra decisões e razões ││
│ │ • Captura timeline eventos ││
│ │ • Cria base para post-mortem ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Workflow Resposta
Resposta Inicial
PRIMEIROS 15 MINUTOS:
┌─────────────────────────────────────────────────────────────┐
│ AÇÕES IMEDIATAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ MINUTO 0-5: DETECÇÃO & DECLARAÇÃO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Alerta disparado (monitoramento) ou reportado ││
│ │ 2. On-call recebe notificação ││
│ │ 3. Verificar incidente é real (não falso alarme) ││
│ │ 4. Declarar nível severidade ││
│ │ 5. Criar canal/tarefa incidente ││
│ │ ││
│ │ NO GITSCRUM: ││
│ │ Criar tarefa: "INCIDENTE: [Descrição breve]" ││
│ │ Adicionar labels: incident, sev-1 (ou nível apropriado) ││
│ │ Atribuir: Comandante Incidente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MINUTO 5-10: MOBILIZAÇÃO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Chamar membros time relevantes (se necessário) ││
│ │ 2. Abrir war room (videochamada ou canal chat) ││
│ │ 3. Atribuir papéis: IC, Líder Técnico, Comms, Escriba ││
│ │ 4. Briefar todos sobre fatos conhecidos ││
│ │ ││
│ │ IC DIZ: ││
│ │ "Temos SEV-1: [descrição]. Sou IC. [Nome] é Líder ││
│ │ Técnico. [Nome] cuida comms. [Nome] é escriba. ││
│ │ Aqui está o que sabemos..." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MINUTO 10-15: INVESTIGAÇÃO INICIAL │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Verificar deployments recentes (últimas 24 horas) ││
│ │ 2. Revisar dashboards monitoramento ││
│ │ 3. Verificar status dependências externas ││
│ │ 4. Reunir hipóteses iniciais ││
│ │ ││
│ │ LÍDER TÉCNICO PERGUNTA: ││
│ │ "Algo foi deployado recentemente?" ││
│ │ "Quando as métricas começaram a degradar?" ││
│ │ "É isolado ou generalizado?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Comunicação
Updates Status
PADRÕES COMUNICAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ MANTENDO STAKEHOLDERS INFORMADOS │
├─────────────────────────────────────────────────────────────┤
│ │
│ UPDATES INTERNOS (no GitScrum Discussions): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TEMPLATE: ││
│ │ ││
│ │ **[HORA] UPDATE INCIDENTE - [NOME INCIDENTE]** ││
│ │ ││
│ │ **Status:** Investigando / Identificado / Mitigando ││
│ │ **Impacto:** [Quem/o que está afetado] ││
│ │ **Ação atual:** [O que estamos fazendo] ││
│ │ **Próximo update:** [Hora do próximo update] ││
│ │ ││
│ │ Exemplo: ││
│ │ "14:35 UPDATE INCIDENTE - Latência API ││
│ │ Status: Identificado ││
│ │ Impacto: 50% requests API dando timeout ││
│ │ Atual: Revertendo deploy das 13:45 ││
│ │ Próximo update: 14:45 ou quando resolver" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FREQUÊNCIA UPDATES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SEV-1: A cada 15 minutos ou em mudança status ││
│ │ SEV-2: A cada 30 minutos ││
│ │ SEV-3: Em mudança de status ││
│ │ ││
│ │ Mesmo sem progresso: "Continuando investigação. Sem info"││
│ │ Silêncio é pior que "sem novidades" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Pós-Incidente
Post-Mortem Sem Culpa
APRENDENDO COM INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ ESTRUTURA POST-MORTEM │
├─────────────────────────────────────────────────────────────┤
│ │
│ DOCUMENTAR NO NOTEVAULT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ # Post-Mortem: [Nome Incidente] - [Data] ││
│ │ ││
│ │ ## Resumo ││
│ │ • Duração: 2h 15m ││
│ │ • Impacto: 45% usuários afetados ││
│ │ • Severidade: SEV-1 ││
│ │ ││
│ │ ## Cronologia ││
│ │ | Hora | Evento | ││
│ │ |-------|-------------------------------------| ││
│ │ | 13:45 | Deployment para produção | ││
│ │ | 14:02 | Primeiro reporte cliente | ││
│ │ | 14:15 | Incidente declarado | ││
│ │ | 14:30 | Causa raiz identificada | ││
│ │ | 15:00 | Rollback completado | ││
│ │ | 16:00 | Recuperação completa confirmada | ││
│ │ ││
│ │ ## Causa Raiz ││
│ │ Migração BD no deployment removeu índice necessário ││
│ │ para path de query principal. ││
│ │ ││
│ │ ## Items de Ação ││
│ │ • Adicionar testes performance queries no CI ││
│ │ • Mudar janela deploy para horários baixo tráfego ││
│ │ • Adicionar check dependência índices no review migração││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRINCÍPIOS SEM CULPA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ "O sistema permitiu que isso acontecesse" ││
│ │ ❌ "João causou a queda" ││
│ │ ││
│ │ Foco: Como prevenir que QUALQUER engenheiro cometa ││
│ │ este erro, não "quem cometeu o erro" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘