8 min lectura • Guide 750 of 877
Gestión de Incidentes con GitScrum
Cuando las cosas fallan, la respuesta rápida importa. GitScrum ayuda a los equipos a coordinar respuesta a incidentes y documentar aprendizajes para prevención futura.
Categorías de Incidentes
Niveles de Severidad
CLASIFICACIÓN DE SEVERIDAD DE INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEV 1 - CRÍTICO │
│ 🔴 Outage completo o pérdida de datos │
│ • Todos los usuarios afectados │
│ • Funcionalidad core rota │
│ • Breach de seguridad │
│ Respuesta: Todas las manos, escalamiento inmediato │
│ SLA: Acknowledge < 15 min, resolver ASAP │
│ │
│ SEV 2 - ALTO │
│ 🟠 Feature mayor no disponible │
│ • Muchos usuarios afectados │
│ • Funcionalidad significativa rota │
│ • Workaround existe pero doloroso │
│ Respuesta: On-call + equipo relevante │
│ SLA: Acknowledge < 1 hora, resolver < 4 horas │
│ │
│ SEV 3 - MEDIO │
│ 🟡 Feature degradada │
│ • Algunos usuarios afectados │
│ • Workaround existe │
│ • Feature no crítica │
│ Respuesta: On-call, escalar si es necesario │
│ SLA: Acknowledge < 4 horas, resolver < 24 horas │
│ │
│ SEV 4 - BAJO │
│ 🟢 Issue menor │
│ • Pocos usuarios afectados │
│ • Workaround fácil │
│ Respuesta: Proceso normal de bug │
│ SLA: Triage < 24 horas │
└─────────────────────────────────────────────────────────────┘
Respuesta a Incidentes
Flujo de Respuesta
PROCESO DE RESPUESTA A INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. DETECCIÓN │
│ ↓ │
│ • Alerta de monitoreo dispara │
│ • Usuario reporta issue │
│ • Miembro del equipo nota problema │
│ │
│ 2. TRIAGE (< 15 min para SEV 1) │
│ ↓ │
│ • Evaluar severidad │
│ • Asignar incident commander │
│ • Crear tarea de incidente en GitScrum │
│ • Notificar stakeholders │
│ │
│ 3. INVESTIGACIÓN │
│ ↓ │
│ • Reunir equipo (war room si es necesario) │
│ • Revisar logs, métricas, cambios recientes │
│ • Identificar causa raíz │
│ • Documentar hallazgos en tiempo real │
│ │
│ 4. MITIGACIÓN │
│ ↓ │
│ • Implementar fix o workaround │
│ • Rollback si es necesario │
│ • Verificar resolución │
│ • Monitorear recurrencia │
│ │
│ 5. COMUNICACIÓN │
│ ↓ │
│ • Actualizar status page │
│ • Notificar usuarios afectados │
│ • Update a stakeholders internos │
│ │
│ 6. SEGUIMIENTO │
│ • Post-mortem dentro de 48 horas │
│ • Action items trackeados en GitScrum │
│ • Mejoras de proceso identificadas │
└─────────────────────────────────────────────────────────────┘
Estructura de Tarea de Incidente
TAREA DE INCIDENTE EN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ 🔴 INC-047: Errores 503 API - Servicio de Pagos │
├─────────────────────────────────────────────────────────────┤
│ │
│ Severidad: SEV 1 - CRÍTICO │
│ Status: 🔥 Incidente Activo │
│ Commander: @alex │
│ Inicio: 2024-01-15 14:32 UTC │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ IMPACTO: │
│ • Todo procesamiento de pagos fallando │
│ • ~100% de intentos de checkout afectados │
│ • Inicio: 14:32 UTC │
│ • Duración: 45 minutos (en curso) │
│ │
│ TIMELINE: │
│ 14:32 - Alerta: Tasa error API pagos > 50% │
│ 14:35 - Incidente declarado, @alex en punto │
│ 14:40 - Identificado: Conexiones DB agotadas │
│ 14:45 - Causa raíz: Deploy reciente aumentó conexiones │
│ 14:50 - Mitigación: Haciendo rollback de deploy │
│ 15:00 - Rollback completo, verificando │
│ │
│ CAUSA RAÍZ: │
│ Deploy a las 14:15 introdujo memory leak de conexiones │
│ Connection pool agotado después de ~15 minutos │
│ │
│ RESOLUCIÓN: │
│ ☐ Rollback completado │
│ ☐ Servicios recuperándose │
│ ☐ Monitoreando estabilidad │
│ │
│ ENLAZADO: │
│ • Alerta: #12345 (PagerDuty) │
│ • PR de Rollback: #789 │
│ • Seguimiento: INC-047-PM (post-mortem) │
└─────────────────────────────────────────────────────────────┘
Comunicación
Updates a Stakeholders
COMUNICACIÓN DE INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COMUNICACIÓN INTERNA: │
│ │
│ NOTIFICACIÓN INICIAL (< 15 min): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 INCIDENTE: Procesamiento de pagos caído ││
│ │ ││
│ │ Severidad: SEV 1 ││
│ │ Impacto: Todos los checkouts fallando ││
│ │ Inicio: 14:32 UTC ││
│ │ Commander: @alex ││
│ │ Canal: #incident-047 ││
│ │ ││
│ │ Updates seguirán cada 15 minutos. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ UPDATE (Cada 15-30 min): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🟡 UPDATE: Incidente de pagos ││
│ │ ││
│ │ Status: Mitigación en progreso ││
│ │ Causa raíz: Issue de conexión a database ││
│ │ Acción: Haciendo rollback de deploy reciente ││
│ │ ETA resolución: 15 minutos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RESOLUCIÓN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ RESUELTO: Incidente de pagos ││
│ │ ││
│ │ Duración: 45 minutos ││
│ │ Resolución: Rollback de deploy problemático ││
│ │ Post-mortem programado: Mañana 10am ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Status Page
UPDATES DE STATUS EXTERNO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STATUS PAGE PARA CLIENTES: │
│ │
│ INICIAL: │
│ "Estamos investigando issues con procesamiento de pagos. │
│ Proporcionaremos updates a medida que aprendamos más." │
│ │
│ PROGRESO: │
│ "Hemos identificado la causa y estamos implementando │
│ un fix. Esperamos resolver esto en 30 minutos." │
│ │
│ RESUELTO: │
│ "Procesamiento de pagos ha sido restaurado. Todos los │
│ servicios están operando normalmente. Pedimos disculpas │
│ por cualquier inconveniente causado." │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PRINCIPIOS: │
│ │
│ ✅ HACER: │
│ • Acknowledge rápidamente │
│ • Actualizar regularmente │
│ • Ser honesto sobre impacto │
│ • Proporcionar ETAs cuando se conocen │
│ • Pedir disculpas sinceramente │
│ │
│ ❌ NO HACER: │
│ • Culpar (personas, vendors) │
│ • Ser demasiado técnico │
│ • Prometer de más tiempo de resolución │
│ • Quedarse en silencio durante incidente │
└─────────────────────────────────────────────────────────────┘
Post-Mortem
Análisis Sin Culpa
PROCESO DE POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIMING: Dentro de 48 horas del incidente │
│ │
│ ASISTENTES: │
│ • Incident commander │
│ • Responders involucrados │
│ • Team leads relevantes │
│ • (Opcional) Stakeholders │
│ │
│ AGENDA: │
│ │
│ 1. REVISIÓN DE TIMELINE (15 min) │
│ • Qué pasó, en secuencia │
│ • Cuándo detectamos, respondimos, resolvimos │
│ │
│ 2. ANÁLISIS DE CAUSA RAÍZ (20 min) │
│ • ¿Por qué pasó esto? │
│ • Técnica de 5 Porqués │
│ • Factores contribuyentes │
│ │
│ 3. QUÉ FUNCIONÓ BIEN (10 min) │
│ • ¿Detección rápida? │
│ • ¿Buena comunicación? │
│ • ¿Mitigación efectiva? │
│ │
│ 4. QUÉ PODRÍA MEJORAR (10 min) │
│ • ¿Dónde tuvimos dificultades? │
│ • ¿Qué faltaba? │
│ • ¿Qué ayudaría la próxima vez? │
│ │
│ 5. ACTION ITEMS (15 min) │
│ • Específicos, asignados, con fecha límite │
│ • Trackear en GitScrum │
│ │
│ SIN CULPA: │
│ Enfocarse en sistemas y procesos, no en personas │
│ "El proceso de deploy permitió..." no "@alex rompió..." │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Clasificar severidad inmediatamente
- Comunicar frecuentemente durante incidentes
- Documentar en tiempo real para post-mortem
- Post-mortem sin culpa para aprendizaje real
- Action items trackeados hasta completarse
- Mejorar procesos basado en aprendizajes