5 min lectura • Guide 719 of 877
Análisis Post-Mortem para Equipos de Desarrollo
Los incidentes son inevitables - no aprender de ellos no lo es. GitScrum ayuda a equipos a documentar, analizar, y trackear outcomes de post-mortems para construir sistemas y procesos más resilientes.
Principios de Post-Mortem
CULTURA BLAMELESS VS BLAME
══════════════════════════
CULTURA DE BLAME:
┌─────────────────────────────────────────────────────────────┐
│ │
│ "¿Quién pusheó el código malo?" │
│ "¿Por qué no testeaste esto?" │
│ "Esta es tu responsabilidad" │
│ │
│ RESULTADO: │
│ • Personas esconden errores │
│ • Incidentes no se reportan │
│ • Causas raíz quedan ocultas │
│ • Problemas se repiten │
│ • Cultura de miedo │
│ │
└─────────────────────────────────────────────────────────────┘
CULTURA BLAMELESS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ "¿Qué permitió que esto pasara?" │
│ "¿Qué información faltaba?" │
│ "¿Cómo podemos prevenir esto sistémicamente?" │
│ │
│ RESULTADO: │
│ • Personas reportan proactivamente │
│ • Aprendemos de cada incidente │
│ • Sistemas mejoran │
│ • Confianza aumenta │
│ • Innovación florece │
│ │
└─────────────────────────────────────────────────────────────┘
Cuándo Hacer Post-Mortem
TRIGGERS PARA POST-MORTEM
═════════════════════════
SIEMPRE:
┌─────────────────────────────────────────────────────────────┐
│ ├── Downtime de producción > X minutos │
│ ├── Pérdida de datos │
│ ├── Breach de seguridad │
│ ├── Impacto significativo a usuarios │
│ └── Near-miss que pudo ser grave │
└─────────────────────────────────────────────────────────────┘
CONSIDERAR:
┌─────────────────────────────────────────────────────────────┐
│ ├── Incidentes repetitivos │
│ ├── Situaciones que revelaron gaps │
│ ├── Éxitos que queremos replicar │
│ └── Eventos donde aprendimos algo importante │
└─────────────────────────────────────────────────────────────┘
NO NECESARIO:
┌─────────────────────────────────────────────────────────────┐
│ ├── Issues menores con fix obvio │
│ ├── Incidentes ya analizados antes │
│ └── Cuando no hay nada nuevo que aprender │
└─────────────────────────────────────────────────────────────┘
Proceso de Post-Mortem
TIMELINE DE POST-MORTEM
═══════════════════════
DURANTE INCIDENTE:
┌─────────────────────────────────────────────────────────────┐
│ ├── Resolver primero, documentar después │
│ ├── Pero: capturar timeline mientras está fresco │
│ └── Notas rápidas de qué pasó y cuándo │
└─────────────────────────────────────────────────────────────┘
24-48 HORAS DESPUÉS:
┌─────────────────────────────────────────────────────────────┐
│ ├── Agendar post-mortem meeting │
│ ├── Recolectar logs, métricas, screenshots │
│ ├── Construir timeline detallado │
│ └── Invitar a todos los involucrados │
└─────────────────────────────────────────────────────────────┘
MEETING (1-2 horas):
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. CONTEXTO (5 min) │
│ └── Recordar directiva blameless │
│ │
│ 2. TIMELINE (15-20 min) │
│ └── ¿Qué pasó, cuándo, en qué orden? │
│ │
│ 3. ANÁLISIS (30-40 min) │
│ ├── ¿Por qué pasó? (5 whys) │
│ ├── ¿Qué funcionó bien? │
│ └── ¿Qué pudimos hacer mejor? │
│ │
│ 4. ACTION ITEMS (15-20 min) │
│ ├── ¿Qué haremos para prevenir recurrencia? │
│ └── Owners y fechas │
│ │
│ 5. WRAP-UP (5 min) │
│ └── Próximos pasos, comunicación │
│ │
└─────────────────────────────────────────────────────────────┘
DESPUÉS:
┌─────────────────────────────────────────────────────────────┐
│ ├── Documentar findings │
│ ├── Crear tareas para action items │
│ ├── Compartir aprendizajes │
│ └── Follow-up en próximas semanas │
└─────────────────────────────────────────────────────────────┘
Template de Documento
DOCUMENTO DE POST-MORTEM
════════════════════════
INCIDENTE: [Nombre descriptivo]
FECHA: [Fecha del incidente]
SEVERIDAD: [SEV1/SEV2/SEV3]
DURACIÓN: [Tiempo total de impacto]
RESUMEN EJECUTIVO:
[2-3 oraciones describiendo qué pasó y el impacto]
TIMELINE:
┌─────────────────────────────────────────────────────────────┐
│ 10:15 - Alerta de error rate disparada │
│ 10:18 - Oncall notificado │
│ 10:25 - Identificada causa (bad deploy) │
│ 10:32 - Rollback iniciado │
│ 10:45 - Servicio restaurado │
│ 11:00 - Confirmado todo normal │
└─────────────────────────────────────────────────────────────┘
IMPACTO:
├── Usuarios afectados: ~5,000
├── Revenue perdido: $X
└── Duración: 30 minutos
ROOT CAUSE:
[Explicación técnica de por qué ocurrió]
CONTRIBUTING FACTORS:
├── [Factor 1]
├── [Factor 2]
└── [Factor 3]
QUÉ FUNCIONÓ BIEN:
├── [Ejemplo]
└── [Ejemplo]
QUÉ MEJORAR:
├── [Ejemplo]
└── [Ejemplo]
ACTION ITEMS:
├── [Acción 1] - Owner: @X - Fecha: Y
├── [Acción 2] - Owner: @X - Fecha: Y
└── [Acción 3] - Owner: @X - Fecha: Y
En GitScrum
TRACKING DE POST-MORTEMS
════════════════════════
CREAR TAREAS DE ACTION ITEMS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ [POST-MORTEM] Agregar validación pre-deploy │
│ │
│ Origen: Post-mortem INC-123 │
│ Owner: @carlos │
│ Fecha límite: 2 semanas │
│ │
│ Labels: 🔍 post-mortem, 🔧 improvement │
│ │
│ Linked: Documento de post-mortem en NoteVault │
│ │
└─────────────────────────────────────────────────────────────┘
TRACKING DE FOLLOW-UP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Post-Mortem INC-123 Action Items: │
│ │
│ ├── [✅] Rollback automático implementado │
│ ├── [🔄] Validación pre-deploy (en progreso) │
│ └── [⏳] Mejorar alertas (pendiente) │
│ │
│ Completion: 1/3 (33%) │
│ │
└─────────────────────────────────────────────────────────────┘