9 min leitura • Guide 723 of 877
Análise Post-Mortem para Times de Desenvolvimento
Incidentes são inevitáveis - não aprender com eles não é. O GitScrum ajuda times a documentar, analisar e rastrear outcomes de post-mortems para construir sistemas e processos mais resilientes.
Princípios de Post-Mortem
Cultura Blameless
BLAMELESS VS CULTURA DE CULPA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CULTURA DE CULPA: │
│ │
│ "Quem deu push no código ruim?" │
│ "Por que você não testou isso?" │
│ "Isso é sua responsabilidade" │
│ │
│ RESULTADO: │
│ • Pessoas escondem erros │
│ • Incidentes não são reportados │
│ • Root causes ficam escondidas │
│ • Problemas se repetem │
│ • Cultura de medo │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CULTURA BLAMELESS: │
│ │
│ "O que no nosso sistema permitiu isso acontecer?" │
│ "Como podemos tornar a coisa certa fácil?" │
│ "O que aprendemos?" │
│ │
│ RESULTADO: │
│ • Incidentes reportados cedo │
│ • Root causes reais encontradas │
│ • Sistemas melhoram │
│ • Problemas não se repetem │
│ • Cultura de aprendizado │
│ │
│ INSIGHT CHAVE: │
│ "A pessoa que cometeu o 'erro' é frequentemente a pessoa │
│ mais próxima do problema e melhor posicionada para corrigir"│
└─────────────────────────────────────────────────────────────┘
Quando Rodar Post-Mortems
GATILHOS DE POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DEFINITIVAMENTE EXECUTE POST-MORTEM: │
│ • Outage de produção │
│ • Perda ou breach de dados │
│ • Impacto significativo em usuários │
│ • SLA não cumprido │
│ • Incidente de segurança │
│ │
│ CONSIDERE POST-MORTEM: │
│ • Near miss (quase teve incidente) │
│ • Incidente menor com valor de aprendizado │
│ • Falha de processo │
│ • Deadline significativo perdido │
│ │
│ REVISÃO MAIS LEVE: │
│ • Bug que chegou em produção │
│ • Issues pequenos de processo │
│ • Oportunidade de aprendizado │
│ │
│ DEFINIÇÕES DE SEVERIDADE: │
│ │
│ SEV-1: Crítico - Post-mortem completo obrigatório │
│ Sistema down, perda de dados, impacto major │
│ │
│ SEV-2: Major - Post-mortem recomendado │
│ Outage parcial, impacto significativo em usuários │
│ │
│ SEV-3: Minor - Revisão breve │
│ Impacto pequeno, recuperação rápida │
│ │
│ SEV-4: Low - Opcional │
│ Impacto mínimo, principalmente interno │
└─────────────────────────────────────────────────────────────┘
Processo de Post-Mortem
Timeline
TIMELINE DO POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENTE │
│ │ │
│ ▼ │
│ RESPONDER (Minutos a Horas) │
│ • Mitigar impacto │
│ • Comunicar status │
│ • Documentar enquanto acontece │
│ │ │
│ ▼ │
│ RESOLVER (Horas a Dias) │
│ • Corrigir o issue imediato │
│ • Verificar resolução │
│ • Declarar incidente fechado │
│ │ │
│ ▼ │
│ ESFRIAR (1-3 Dias) │
│ • Deixar emoções assentarem │
│ • Coletar dados e logs │
│ • Rascunhar timeline │
│ │ │
│ ▼ │
│ POST-MORTEM (Dia 3-5) │
│ • Facilitar reunião │
│ • Analisar root causes │
│ • Documentar aprendizados │
│ • Atribuir action items │
│ │ │
│ ▼ │
│ FOLLOW UP (Contínuo) │
│ • Rastrear action items │
│ • Verificar fixes deployed │
│ • Fechar quando completo │
└─────────────────────────────────────────────────────────────┘
Estrutura da Reunião
AGENDA DA REUNIÃO DE POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DURAÇÃO: 45-90 minutos (baseado na severidade) │
│ │
│ PARTICIPANTES: │
│ • Pessoas envolvidas na resposta ao incidente │
│ • Liderança de engineering (para incidentes major) │
│ • Facilitador (parte neutra preferido) │
│ │
│ AGENDA: │
│ │
│ 1. PREPARAR O CENÁRIO (5 min) │
│ • Ler lembrete de cultura blameless │
│ • Declarar o propósito: aprender e melhorar │
│ │
│ 2. REVISÃO DA TIMELINE (15 min) │
│ • Caminhar pelo que aconteceu │
│ • Preencher gaps, corrigir erros │
│ • Anotar pontos de decisão chave │
│ │
│ 3. FATORES CONTRIBUINTES (20 min) │
│ • Quais condições levaram a isso? │
│ • Por que cada fator existia? │
│ • Continue perguntando "por quê" (técnica 5 whys) │
│ │
│ 4. O QUE FUNCIONOU BEM (10 min) │
│ • O que funcionou na nossa resposta? │
│ • O que queremos continuar fazendo? │
│ │
│ 5. ACTION ITEMS (15 min) │
│ • O que vai prevenir recorrência? │
│ • O que vai melhorar detecção? │
│ • O que vai acelerar recuperação? │
│ • Atribuir owners e deadlines │
│ │
│ 6. ENCERRAMENTO │
│ • Confirmar action items │
│ • Agendar follow-up se necessário │
└─────────────────────────────────────────────────────────────┘
Técnicas de Análise
5 Whys
TÉCNICA DOS 5 PORQUÊS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENTE: Database de produção crashou │
│ │
│ POR QUÊ 1: Por que o database crashou? │
│ → Espaço em disco acabou │
│ │
│ POR QUÊ 2: Por que espaço em disco acabou? │
│ → Arquivos de log cresceram inesperadamente │
│ │
│ POR QUÊ 3: Por que arquivos de log cresceram? │
│ → Uma nova feature estava logando dados demais │
│ │
│ POR QUÊ 4: Por que feature logava tanto? │
│ → Debug logging foi deixado habilitado em produção │
│ │
│ POR QUÊ 5: Por que debug logging estava habilitado? │
│ → Sem check no CI/CD para prevenir isso │
│ │
│ ROOT CAUSE: Safeguards de deployment faltando │
│ │
│ ACTION ITEMS: │
│ 1. Adicionar check no CI para falhar em debug log em prod │
│ 2. Configurar monitoramento de espaço com alertas │
│ 3. Implementar rotação de logs │
│ │
│ DICAS: │
│ • Pode precisar de menos ou mais de 5 porquês │
│ • Pode ter múltiplos branches de causas │
│ • Pare quando chegar em root causes acionáveis │
│ • Foque em sistemas, não pessoas │
└─────────────────────────────────────────────────────────────┘
Fatores Contribuintes
ANÁLISE DE FATORES CONTRIBUINTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CATEGORIAS DE FATORES: │
│ │
│ TÉCNICO: │
│ • Monitoramento faltando │
│ • Sem recuperação automática │
│ • Single point of failure │
│ • Dívida técnica │
│ │
│ PROCESSO: │
│ • Testing insuficiente │
│ • Runbook faltando │
│ • Ownership não clara │
│ • Gaps de comunicação │
│ │
│ AMBIENTAL: │
│ • Pressão de tempo │
│ • Restrições de recursos │
│ • Mudança organizacional │
│ • Dependências externas │
│ │
│ EXEMPLO DE MAPEAMENTO: │
│ │
│ Incidente: Outage de checkout de 2 horas │
│ │
│ Técnico: Sem circuit breaker quando API pagamento falhou │
│ Processo: Sem runbook para falhas de pagamento │
│ Ambiental: Pressão de deadline de lançamento pulou testes │
│ │
│ Múltiplos fatores usualmente combinam para causar incidentes│
│ Modelo queijo suíço: Múltiplos buracos tiveram que alinhar │
└─────────────────────────────────────────────────────────────┘
Documentação
Template de Post-Mortem
TEMPLATE DE DOCUMENTO POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENTE: [Título] │
│ DATA: [Quando ocorreu] │
│ SEVERIDADE: [SEV-1/2/3/4] │
│ DURAÇÃO: [Tempo total do incidente] │
│ IMPACTO: [Usuários afetados, receita perdida, etc.] │
│ AUTORES: [Quem escreveu] │
│ STATUS: [Rascunho/Revisado/Fechado] │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ ## Resumo │
│ [Overview de 2-3 frases do que aconteceu] │
│ │
│ ## Timeline │
│ 14:32 - Alerta disparou por alta taxa de erro │
│ 14:35 - On-call acknowledged │
│ 14:40 - Root cause identificada │
│ 15:15 - Fix deployed │
│ 15:20 - Taxa de erro retornou ao normal │
│ │
│ ## Fatores Contribuintes │
│ [Quais condições levaram a este incidente] │
│ │
│ ## Detecção │
│ [Como foi descoberto? Poderíamos detectar mais rápido?] │
│ │
│ ## Resposta │
│ [O que fizemos? O que foi bem? O que foi difícil?] │
│ │
│ ## Root Cause │
│ [Causa(s) subjacente(s)] │
│ │
│ ## Action Items │
│ | Ação | Owner | Due | Status | │
│ |------|-------|-----|--------| │
│ | ... | ... | ... | ... | │
│ │
│ ## Lições Aprendidas │
│ [Takeaways chave para a organização] │
└─────────────────────────────────────────────────────────────┘
Rastreamento de Ações
Seguindo em Frente
RASTREAMENTO DE AÇÕES POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENTE: Outage de Checkout (15 Jan) │
│ │
│ ACTION ITEMS: │
│ │
│ ☑️ Adicionar circuit breaker ao serviço de pagamento │
│ Owner: @alex | Due: Jan 22 | Status: Done │
│ Link: PR #1234 │
│ │
│ 🔄 Criar runbook para falhas de pagamento │
│ Owner: @maria | Due: Jan 25 | Status: In Progress │
│ Notes: 60% completo, vai terminar amanhã │
│ │
│ ☐ Configurar monitoramento de API de pagamento │
│ Owner: @jordan | Due: Jan 29 | Status: Not Started │
│ │
│ ☐ Revisar cobertura de teste para fluxo checkout │
│ Owner: @alex | Due: Feb 5 | Status: Not Started │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ REGRAS DE RASTREAMENTO: │
│ • Revisar action items semanalmente │
│ • Escalonar se atrasado │
│ • Não fechar post-mortem até todas ações concluídas │
│ • Linkar ações à implementação │
│ │
│ MÉTRICAS: │
│ • Tempo médio para fechar todas ações: 14 dias │
│ • Taxa de conclusão de ações: 92% │
│ • Incidentes repetidos: 2 (de ações não completadas) │
└─────────────────────────────────────────────────────────────┘