8 min lectura • Guide 811 of 877
Respuesta a Incidentes y Post-mortems
Los incidentes ocurren. GitScrum ayuda a los equipos a documentar incidentes, trackear remediación y capturar aprendizajes para mejora continua.
Respuesta a Incidentes
Proceso de Respuesta
FLUJO DE RESPUESTA A INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. DETECTAR │
│ ────────── │
│ • Alerta de monitoreo dispara │
│ • Cliente reporta issue │
│ • Miembro del equipo nota problema │
│ │
│ 2. TRIAGE │
│ ───────── │
│ • Evaluar severidad (SEV1, SEV2, SEV3) │
│ • Identificar servicios impactados │
│ • Pagear on-call apropiado │
│ │
│ 3. RESPONDER │
│ ────────── │
│ • Ensamblar equipo de incidente │
│ • Abrir canal de incidente │
│ • Comenzar investigación │
│ │
│ 4. MITIGAR │
│ ─────────── │
│ • Enfocarse en restaurar servicio │
│ • Roll back si es necesario │
│ • Aplicar fixes temporales │
│ │
│ 5. RESOLVER │
│ ────────── │
│ • Confirmar servicio restaurado │
│ • Monitorear estabilidad │
│ • Comunicar resolución │
│ │
│ 6. APRENDER │
│ ──────── │
│ • Programar post-mortem │
│ • Documentar timeline │
│ • Crear action items │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NIVELES DE SEVERIDAD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SEV1 (Crítico): ││
│ │ Outage completo, todos los usuarios afectados ││
│ │ Respuesta: Inmediata, todas las manos ││
│ │ ││
│ │ SEV2 (Mayor): ││
│ │ Servicio degradado, muchos usuarios afectados ││
│ │ Respuesta: Dentro de 30 min, on-call primario ││
│ │ ││
│ │ SEV3 (Menor): ││
│ │ Impacto limitado, workaround existe ││
│ │ Respuesta: Siguiente día hábil ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Roles de Incidente
ROLES DEL EQUIPO DE INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENT COMMANDER (IC): │
│ ──────────────────────── │
│ • Coordina respuesta │
│ • Toma decisiones │
│ • Asigna tareas │
│ • Comunica con stakeholders │
│ • Llama por ayuda adicional │
│ │
│ TECHNICAL LEAD: │
│ ─────────────── │
│ • Lidera investigación │
│ • Dirige debugging │
│ • Propone mitigaciones │
│ • Implementa fixes │
│ │
│ COMUNICACIONES: │
│ ─────────────── │
│ • Postea updates de status │
│ • Actualiza status page │
│ • Comunica con clientes │
│ • Mantiene stakeholders informados │
│ │
│ SCRIBE: │
│ ─────── │
│ • Documenta timeline │
│ • Registra decisiones │
│ • Captura qué se intentó │
│ • Prepara para post-mortem │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ASIGNACIÓN DE ROLES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INCIDENTE: Procesamiento de Pagos Caído ││
│ │ SEVERIDAD: SEV1 ││
│ │ HORA: 2025-01-15 14:30 UTC ││
│ │ ││
│ │ IC: @jordan ││
│ │ Tech Lead: @alex ││
│ │ Comms: @sam ││
│ │ Scribe: @pat ││
│ │ ││
│ │ Canal: #incident-2025-01-15-pagos ││
│ │ Status Page: https://status.acme.co ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Roles claros previenen confusión durante el caos │
└─────────────────────────────────────────────────────────────┘
Proceso de Post-Mortem
Post-Mortems Sin Culpa
PRINCIPIOS DE POST-MORTEM SIN CULPA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRINCIPIO CORE: │
│ ─────────────── │
│ Las personas no causan incidentes—los sistemas sí │
│ Enfocarse en: ¿Qué permitió que esto pasara? │
│ │
│ LENGUAJE SIN CULPA: │
│ ─────────────────── │
│ │
│ ❌ "Juan pusheó código malo" │
│ ✅ "El pipeline de deployment no detectó el bug" │
│ │
│ ❌ "Sara no notó la alerta" │
│ ✅ "La alerta no estaba configurada para pagear" │
│ │
│ ❌ "El equipo fue descuidado" │
│ ✅ "El proceso no tenía suficientes salvaguardas" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ POR QUÉ SIN CULPA: │
│ ────────────── │
│ │
│ CULPA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ → La gente oculta errores ││
│ │ → Menos información compartida ││
│ │ → Causas raíz permanecen ocultas ││
│ │ → Incidentes recurren ││
│ │ → Cultura de miedo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SIN CULPA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ → La gente habla abiertamente ││
│ │ → Contexto completo disponible ││
│ │ → Causas raíz verdaderas encontradas ││
│ │ → Fixes sistémicos implementados ││
│ │ → Cultura de aprendizaje ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ "Si alguien puede cometer un error, el sistema es frágil" │
└─────────────────────────────────────────────────────────────┘
Plantilla de Post-Mortem
DOCUMENTO DE POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENTE: Outage de Procesamiento de Pagos │
│ FECHA: 15 de Enero, 2025 │
│ DURACIÓN: 47 minutos │
│ SEVERIDAD: SEV1 │
│ AUTOR: @jordan │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RESUMEN: │
│ ──────── │
│ Procesamiento de pagos estuvo no disponible por 47 minutos │
│ debido a agotamiento de connection pool de database │
│ después de un pico de tráfico. │
│ │
│ IMPACTO: │
│ ─────── │
│ • ~2,500 intentos de pago fallidos │
│ • Tickets de soporte al cliente: 143 │
│ • Impacto estimado de revenue: $45,000 │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TIMELINE: │
│ ───────── │
│ 14:23 - Pico de tráfico comienza (campaña de marketing) │
│ 14:28 - Warnings de connection pool en logs │
│ 14:32 - Primer cliente reporta pago fallido │
│ 14:35 - Alerta de PagerDuty dispara │
│ 14:38 - Canal de incidente creado, IC asignado │
│ 14:45 - Causa raíz identificada (agotamiento de conexiones)│
│ 14:52 - Decisión de aumentar tamaño de pool │
│ 15:05 - Configuración deployada │
│ 15:12 - Pagos recuperándose │
│ 15:19 - Todos los sistemas normales, monitoreando │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CAUSA RAÍZ: │
│ ─────────── │
│ Connection pool de database estaba dimensionado para │
│ tráfico normal. Campaña de marketing impulsó 4x tráfico │
│ normal sin aviso previo a ingeniería. │
│ │
│ FACTORES CONTRIBUYENTES: │
│ ───────────────────── │
│ • Sin auto-scaling para connection pools │
│ • Threshold de alerta muy alto (disparó tarde) │
│ • Gap de comunicación marketing/ingeniería │
│ • Sin load testing para escenarios de alto tráfico │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ QUÉ FUNCIONÓ BIEN: │
│ ──────────────── │
│ • Respuesta a incidente fue rápida una vez disparada │
│ • Causa raíz identificada en menos de 10 minutos │
│ • Fix fue directo │
│ • Comunicación con cliente fue oportuna │
│ │
│ QUÉ PODRÍA MEJORAR: │
│ ──────────────────────── │
│ • Detección más temprana (alertas no dispararon pronto) │
│ • Comunicación cross-team sobre eventos de tráfico │
│ • Configuración de auto-scaling │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ACTION ITEMS: │
│ ───────────── │
│ 1. Implementar auto-scaling para connection pools @alex │
│ Due: 22 Ene │
│ │
│ 2. Bajar threshold de alerta de 80% a 60% @pat │
│ Due: 17 Ene │
│ │
│ 3. Agregar calendario de marketing a ingeniería @jordan │
│ Due: 19 Ene │
│ │
│ 4. Load test a 5x tráfico normal @sam │
│ Due: 31 Ene │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Post-mortem siempre para incidentes significativos
- Sin culpa enfocarse en sistemas no personas
- Action items trackeados con dueño y fecha
- Compartir aprendizajes entre equipos
- Mejorar detección para encontrar issues antes
- Documentar todo para referencia futura