9 min leitura • Guide 811 of 877
Resposta a Incidentes e Post-Mortems
Incidentes acontecem. GitScrum ajuda times a documentar incidentes, rastrear remediação e capturar aprendizados para melhoria contínua.
Resposta a Incidentes
Processo de Resposta
FLUXO DE RESPOSTA A INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. DETECTAR │
│ ──────────── │
│ • Alerta de monitoramento dispara │
│ • Cliente reporta issue │
│ • Membro do time percebe problema │
│ │
│ 2. TRIAGEM │
│ ───────── │
│ • Avaliar severidade (SEV1, SEV2, SEV3) │
│ • Identificar serviços impactados │
│ • Paginar on-call apropriado │
│ │
│ 3. RESPONDER │
│ ──────────── │
│ • Montar time de incidente │
│ • Abrir canal de incidente │
│ • Iniciar investigação │
│ │
│ 4. MITIGAR │
│ ─────────── │
│ • Foco em restaurar serviço │
│ • Rollback se necessário │
│ • Aplicar fixes temporários │
│ │
│ 5. RESOLVER │
│ ──────────── │
│ • Confirmar serviço restaurado │
│ • Monitorar estabilidade │
│ • Comunicar resolução │
│ │
│ 6. APRENDER │
│ ────────── │
│ • Agendar post-mortem │
│ • Documentar timeline │
│ • Criar action items │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NÍVEIS DE SEVERIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SEV1 (Crítico): ││
│ │ Outage completo, todos usuários afetados ││
│ │ Resposta: Imediata, todos disponíveis ││
│ │ ││
│ │ SEV2 (Major): ││
│ │ Serviço degradado, muitos usuários afetados ││
│ │ Resposta: Dentro de 30 min, on-call primário ││
│ │ ││
│ │ SEV3 (Menor): ││
│ │ Impacto limitado, workaround existe ││
│ │ Resposta: Próximo dia útil ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Papéis no Incidente
PAPÉIS DO TIME DE INCIDENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COMANDANTE DE INCIDENTE (IC): │
│ ────────────────────────────── │
│ • Coordena resposta │
│ • Toma decisões │
│ • Atribui tarefas │
│ • Comunica com stakeholders │
│ • Pede ajuda adicional │
│ │
│ LEAD TÉCNICO: │
│ ───────────── │
│ • Lidera investigação │
│ • Dirige debugging │
│ • Propõe mitigações │
│ • Implementa fixes │
│ │
│ COMUNICAÇÃO: │
│ ───────────── │
│ • Posta atualizações de status │
│ • Atualiza página de status │
│ • Comunica com clientes │
│ • Mantém stakeholders informados │
│ │
│ ESCRIBA: │
│ ───────── │
│ • Documenta timeline │
│ • Registra decisões │
│ • Captura o que foi tentado │
│ • Prepara para post-mortem │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ATRIBUIÇÃO DE PAPÉIS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INCIDENTE: Processamento de Pagamento Fora ││
│ │ SEVERIDADE: SEV1 ││
│ │ HORA: 2025-01-15 14:30 UTC ││
│ │ ││
│ │ IC: @jordan ││
│ │ Tech Lead: @alex ││
│ │ Comms: @sam ││
│ │ Escriba: @pat ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Post-Mortems Sem Culpa
Princípios
PRINCÍPIOS DE POST-MORTEM SEM CULPA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRINCÍPIO 1: ASSUMA BOAS INTENÇÕES │
│ ───────────────────────────────────── │
│ Pessoas vieram trabalhar para fazer um bom trabalho. │
│ Erros acontecem por falhas de sistema, não malícia. │
│ │
│ PRINCÍPIO 2: FOQUE EM SISTEMAS, NÃO PESSOAS │
│ ───────────────────────────────────────────── │
│ Pergunte "Como o sistema permitiu isso?" │
│ Não "Quem fez isso?" │
│ │
│ PRINCÍPIO 3: BUSQUE ENTENDIMENTO, NÃO CULPA │
│ ───────────────────────────────────────────── │
│ Objetivo é prevenir recorrência, não punir. │
│ Culpa impede aprendizado honesto. │
│ │
│ PRINCÍPIO 4: TODOS CONTRIBUEM │
│ ─────────────────────────────── │
│ Perspectivas diversas revelam quadro completo. │
│ Pessoas júnior frequentemente veem coisas frescas. │
│ │
│ PRINCÍPIO 5: FATOS SOBRE NARRATIVAS │
│ ───────────────────────────────────── │
│ Colete evidência: logs, métricas, timestamps. │
│ Evite revisão tendenciosa com hindsight. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LINGUAGEM IMPORTA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ EVITE: │ ✅ USE: ││
│ │ "João causou o outage" │ "O deploy causou outage" ││
│ │ "Quem aprovou isso?" │ "Como foi aprovado?" ││
│ │ "Isso foi descuidado" │ "O que dificultou pegar?" ││
│ │ "Deveria ter sabido" │ "Que info faltou?" ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Conduzindo Post-Mortem
AGENDA DE REUNIÃO DE POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DURAÇÃO: 60-90 minutos │
│ PARTICIPANTES: Respondentes do incidente + stakeholders │
│ FACILITADOR: Pessoa neutra (não envolvida no incidente) │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ 1. PREPARAR O TERRENO (5 min) │
│ ───────────────────────────── │
│ • Lembrar princípios sem culpa │
│ • Explicar objetivo: aprender, não culpar │
│ • Confirmar que todos se sentem seguros para falar │
│ │
│ 2. REVISAR TIMELINE (15 min) │
│ ──────────────────────────── │
│ • Passar por timeline preparada │
│ • Preencher lacunas com participantes │
│ • Corrigir imprecisões │
│ │
│ 3. ANÁLISE DE CAUSA RAIZ (20 min) │
│ ───────────────────────────────── │
│ • Use técnica dos "5 Porquês" │
│ • Identifique causas contribuintes │
│ • Olhe para fatores de sistema │
│ │
│ 4. O QUE DEU BEM (10 min) │
│ ────────────────────────── │
│ • Resposta rápida? │
│ • Comunicação boa? │
│ • Monitoramento ajudou? │
│ │
│ 5. ACTION ITEMS (20 min) │
│ ──────────────────────── │
│ • Brainstorm melhorias │
│ • Priorizar por impacto │
│ • Atribuir donos e datas │
│ │
│ 6. ENCERRAMENTO (5 min) │
│ ───────────────────── │
│ • Resumir decisões │
│ • Acordar comunicação │
│ • Agradecer participantes │
└─────────────────────────────────────────────────────────────┘
Template de Post-Mortem
Documento Completo
POST-MORTEM: [ID do Incidente] - [Título Breve]
═══════════════════════════════════════════════════════════════
METADADOS:
─────────────────────────────────────────────────────────────
Data do Incidente: [Data]
Severidade: [SEV1/SEV2/SEV3]
Duração: [Tempo total de impacto]
Time de Resposta: [Nomes]
Autor do Post-Mortem: [Nome]
Data de Revisão: [Data]
───────────────────────────────────────────────────────────────
SUMÁRIO EXECUTIVO:
───────────────────────────────────────────────────────────────
[Parágrafo único explicando o que aconteceu, impacto e causa
raiz em linguagem não-técnica adequada para executivos]
───────────────────────────────────────────────────────────────
IMPACTO:
───────────────────────────────────────────────────────────────
• Usuários afetados: [Número ou porcentagem]
• Transações falhadas: [Número]
• Receita perdida: [Valor estimado]
• Duração: [Minutos/horas]
• Serviços impactados: [Lista]
───────────────────────────────────────────────────────────────
TIMELINE:
───────────────────────────────────────────────────────────────
[HH:MM] - [Evento]
[HH:MM] - [Evento]
[HH:MM] - [Evento]
...
───────────────────────────────────────────────────────────────
ANÁLISE DE CAUSA RAIZ:
───────────────────────────────────────────────────────────────
Causa direta:
[O que diretamente causou o incidente]
Causas contribuintes:
• [Fator 1]
• [Fator 2]
• [Fator 3]
Análise dos 5 Porquês:
1. Por que [problema aconteceu]? → [Resposta]
2. Por que [resposta anterior]? → [Resposta]
3. Por que [resposta anterior]? → [Resposta]
4. Por que [resposta anterior]? → [Resposta]
5. Por que [resposta anterior]? → [CAUSA RAIZ]
───────────────────────────────────────────────────────────────
O QUE DEU BEM:
───────────────────────────────────────────────────────────────
• [Item positivo 1]
• [Item positivo 2]
• [Item positivo 3]
───────────────────────────────────────────────────────────────
O QUE PODE MELHORAR:
───────────────────────────────────────────────────────────────
• [Área de melhoria 1]
• [Área de melhoria 2]
• [Área de melhoria 3]
───────────────────────────────────────────────────────────────
ACTION ITEMS:
───────────────────────────────────────────────────────────────
| # | Item | Prioridade | Dono | Due | Status |
|---|------------------|------------|-------|---------|--------|
| 1 | [Descrição] | P1 | @nome | [data] | Aberto |
| 2 | [Descrição] | P2 | @nome | [data] | Aberto |
| 3 | [Descrição] | P3 | @nome | [data] | Aberto |
Rastreamento de Action Items
Integrando com GitScrum
RASTREAMENTO DE ACTION ITEMS DE INCIDENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CRIAR EPIC PARA CADA INCIDENTE: │
│ ═════════════════════════════════ │
│ │
│ EPIC: INC-047 Post-Mortem Action Items │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Vinculado a: INC-047 (Tarefa de incidente original) ││
│ │ ││
│ │ Tarefas Filhas: ││
│ │ ├── INC-047-1: Corrigir vazamento conexão BD [P1] ││
│ │ │ Status: Em Progresso ││
│ │ │ Atribuído: @sarah ││
│ │ │ Due: Jan 16 ││
│ │ │ ││
│ │ ├── INC-047-2: Adicionar monitoramento pool [P1] ││
│ │ │ Status: Não Iniciado ││
│ │ │ Atribuído: @mike ││
│ │ │ Due: Jan 18 ││
│ │ │ ││
│ │ ├── INC-047-3: Criar alerta uso > 80% [P2] ││
│ │ │ Status: Não Iniciado ││
│ │ │ Atribuído: @alex ││
│ │ │ Due: Jan 18 ││
│ │ │ ││
│ │ └── INC-047-4: Atualizar checklist review [P3] ││
│ │ Status: Não Iniciado ││
│ │ Atribuído: @jordan ││
│ │ Due: Jan 20 ││
│ │ ││
│ │ Progresso: 0/4 completos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ VISIBILIDADE: Stakeholders podem ver progresso │
│ ACCOUNTABILITY: Donos claros e prazos │
│ PRIORIZAÇÃO: Itens P1 entram no próximo sprint │
└─────────────────────────────────────────────────────────────┘
Métricas de Incidentes
| Métrica | O Que Mede | Meta |
|---|---|---|
| MTTD | Tempo para detectar | < 5 min |
| MTTR | Tempo para recuperar | < 30 min SEV1 |
| Taxa Recorrência | Mesmo incidente repetido | 0% |
| Conclusão Action Items | Items completados vs criados | > 90% |