8 min leitura • Guide 836 of 877
Resposta a Incidentes para Times de Desenvolvimento
Quando coisas quebram, processo ajuda. GitScrum ajuda times a rastrear incidentes junto com trabalho de desenvolvimento, conectando fixes aos eventos que os dispararam.
Básico de Incidentes
O Que É um Incidente
DEFINIÇÃO DE INCIDENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ UM INCIDENTE É: │
│ ─────────────── │
│ Interrupção não planejada do serviço │
│ Degradação significativa da qualidade do serviço │
│ Violação de SLA ou SLO │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NÍVEIS DE SEVERIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SEV-1 (CRÍTICO): ││
│ │ • Outage completo do serviço ││
│ │ • Feature principal quebrada para todos usuários ││
│ │ • Perda de dados ou violação de segurança ││
│ │ Resposta: Todos disponíveis, 24/7 ││
│ │ ││
│ │ SEV-2 (ALTO): ││
│ │ • Outage parcial ou degradação ││
│ │ • Feature principal quebrada para alguns usuários ││
│ │ • Workaround existe mas doloroso ││
│ │ Resposta: Imediata durante horário de trabalho ││
│ │ ││
│ │ SEV-3 (MÉDIO): ││
│ │ • Feature menor quebrada ││
│ │ • Performance degradada mas usável ││
│ │ • Pequeno subconjunto de usuários afetados ││
│ │ Resposta: Próximo dia útil ││
│ │ ││
│ │ SEV-4 (BAIXO): ││
│ │ • Issues cosméticos ││
│ │ • Inconveniência menor ││
│ │ Resposta: Trabalho agendado ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OBJETIVO: Restaurar serviço ASAP, aprender depois │
└─────────────────────────────────────────────────────────────┘
Fases do Incidente
Workflow de Resposta
CICLO DE VIDA DO INCIDENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FASE 1: DETECTAR │
│ ───────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ FONTES: ││
│ │ • Alertas de monitoramento automatizado ││
│ │ • Reportes de clientes ││
│ │ • Time interno percebe ││
│ │ ││
│ │ AÇÃO: ││
│ │ Criar registro de incidente imediatamente ││
│ │ Não espere para confirmar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FASE 2: TRIAGEM │
│ ─────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PERGUNTAS: ││
│ │ • Qual o impacto? ││
│ │ • Quem está afetado? ││
│ │ • Qual a severidade? ││
│ │ ││
│ │ AÇÃO: ││
│ │ Atribuir severidade ││
│ │ Paginar respondentes apropriados ││
│ │ Abrir canal de incidente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FASE 3: RESPONDER │
│ ────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INVESTIGAR: ││
│ │ • Verificar logs, métricas, mudanças recentes ││
│ │ • Formar hipóteses ││
│ │ • Testar e validar ││
│ │ ││
│ │ CORRIGIR: ││
│ │ • Aplicar remediação (reiniciar, rollback, patch) ││
│ │ • Verificar serviço restaurado ││
│ │ • Monitorar recorrência ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FASE 4: RECUPERAR │
│ ────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Confirmar serviço estável ││
│ │ • Fechar incidente ││
│ │ • Agendar post-mortem ││
│ │ • Comunicar resolução ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FASE 5: APRENDER │
│ ──────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Conduzir post-mortem ││
│ │ • Documentar achados ││
│ │ • Criar tarefas de follow-up ││
│ │ • Compartilhar aprendizados ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Papéis no Incidente
Estrutura do Time
PAPÉIS DE RESPOSTA A INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COMANDANTE DE INCIDENTE (IC): │
│ ═════════════════════════════ │
│ Responsabilidades: │
│ • Coordenar esforços de resposta │
│ • Tomar decisões │
│ • Delegar tarefas │
│ • Gerenciar escalação │
│ • Manter time focado │
│ │
│ COMUNICADOR: │
│ ════════════ │
│ Responsabilidades: │
│ • Postar atualizações de status │
│ • Atualizar página de status │
│ • Coordenar com suporte ao cliente │
│ • Notificar stakeholders │
│ │
│ INVESTIGADOR TÉCNICO: │
│ ═════════════════════ │
│ Responsabilidades: │
│ • Diagnosticar issue │
│ • Implementar fix │
│ • Verificar resolução │
│ • Documentar causa raiz │
│ │
│ ESCRIBA: │
│ ═════════ │
│ Responsabilidades: │
│ • Documentar timeline │
│ • Registrar ações tomadas │
│ • Capturar decisões │
│ • Preparar material do post-mortem │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NOTA: Em times pequenos, pessoas podem cobrir │
│ múltiplos papéis. Em incidentes grandes, cada papel │
│ deve ser preenchido por pessoa dedicada. │
└─────────────────────────────────────────────────────────────┘
Comunicação Durante Incidentes
Estratégia de Comunicação
COMUNICAÇÃO DE INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COMUNICAÇÃO INTERNA: │
│ ════════════════════ │
│ │
│ Canal de Incidente: │
│ #incidente-2024-01-15-api │
│ │
│ Formato de Update: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 INCIDENTE: API Serviço de Pagamento ││
│ │ Severidade: SEV-1 | Status: Investigando ││
│ │ IC: @alex | Início: 14:32 UTC ││
│ │ ││
│ │ IMPACTO: Todos pagamentos falhando ││
│ │ ÚLTIMA AÇÃO: Revisando logs do último deploy ││
│ │ PRÓXIMA UPDATE: 15:00 UTC (em 10 min) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMUNICAÇÃO EXTERNA: │
│ ════════════════════ │
│ │
│ Página de Status: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 Outage Major - Processamento de Pagamentos ││
│ │ ││
│ │ Estamos investigando issues afetando processamento ││
│ │ de pagamentos. Clientes podem experienciar falhas ││
│ │ de transação. Estamos trabalhando para resolver ││
│ │ o mais rápido possível. ││
│ │ ││
│ │ Última atualização: 14:45 UTC ││
│ │ Próxima atualização em: 15 minutos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CADÊNCIA DE UPDATES: │
│ ════════════════════ │
│ SEV-1: A cada 15 minutos mínimo │
│ SEV-2: A cada 30 minutos │
│ SEV-3: A cada hora ou mudança de status │
└─────────────────────────────────────────────────────────────┘
Post-Mortem Sem Culpa
Conduzindo Post-Mortem
TEMPLATE DE POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENTE: API Serviço de Pagamento Fora │
│ DATA: 15 Janeiro 2024 │
│ DURAÇÃO: 38 minutos │
│ SEVERIDADE: SEV-1 │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ SUMÁRIO: │
│ ───────── │
│ Bug de vazamento de conexão no release v2.3.4 causou │
│ esgotamento do pool de conexões, resultando em falha │
│ de todos os pagamentos por 38 minutos. │
│ │
│ TIMELINE: │
│ ────────── │
│ 08:00 - v2.3.4 deployado │
│ 14:32 - Alertas de taxa de erro disparados │
│ 14:35 - IC atribuído, canal aberto │
│ 14:45 - Causa raiz identificada │
│ 14:55 - Serviço reiniciado │
│ 15:10 - Sistema estável, incidente fechado │
│ │
│ CAUSA RAIZ: │
│ ───────────── │
│ Mudança de código introduziu path de código onde │
│ conexões de BD não eram liberadas após exceções. │
│ │
│ CONTRIBUINTES: │
│ ────────────── │
│ • Sem teste de load para vazamento de conexão │
│ • Alertas de pool de conexão não configurados │
│ • Code review não pegou o padrão de vazamento │
│ │
│ ACTION ITEMS: │
│ ────────────── │
│ 1. Corrigir vazamento de conexão (@sarah, Jan 16) │
│ 2. Adicionar alerta pool > 80% (@alex, Jan 18) │
│ 3. Adicionar teste de vazamento no CI (@mike, Jan 20) │
│ 4. Atualizar checklist de review (@jordan, Jan 22) │
│ │
│ O QUE DEU BEM: │
│ ─────────────── │
│ • Detecção rápida (3 min) │
│ • Comunicação clara │
│ • Causa raiz identificada rapidamente │
│ • Serviço restaurado em menos de 1 hora │
└─────────────────────────────────────────────────────────────┘
Rastreando no GitScrum
| Tipo Item | Propósito | Exemplo |
|---|---|---|
| Incidente | Rastrear incidente ativo | INC-047: Outage API |
| Bug | Causa raiz corrigida | BUG-312: Vazamento conexão |
| Tarefa | Item de post-mortem | TASK: Adicionar alerta |
| Melhoria | Prevenção longo prazo | Teste de load CI |