8 min lectura • Guide 95 of 877
Manejando Problemas Urgentes de Producción
Los incidentes de producción demandan respuesta inmediata y coordinada. Las capacidades de gestión de incidentes de GitScrum ayudan a equipos a responder rápidamente a través de workflows de escalación dedicados, integración de comunicación en tiempo real, y seguimiento estructurado de incidentes. La clave es tener playbooks ensayados para que equipos actúen instintivamente en lugar de descifrar cosas bajo presión, luego conducir post-mortems exhaustivos para prevenir recurrencia.
Framework Respuesta Incidentes
Clasificación Severidad
NIVELES SEVERIDAD INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ DEFINIENDO SEVERIDAD │
├─────────────────────────────────────────────────────────────┤
│ │
│ SEV-1: CRÍTICO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Definición: ││
│ │ • Servicio core completamente caído ││
│ │ • Pérdida datos o brecha seguridad ││
│ │ • Todos clientes afectados ││
│ │ ││
│ │ Ejemplos: ││
│ │ • Base datos producción offline ││
│ │ • Procesamiento pagos falló ││
│ │ • Sistema autenticación caído ││
│ │ ││
│ │ Respuesta: ││
│ │ • Todos a bordo inmediatamente ││
│ │ • Liderazgo notificado en 5 minutos ││
│ │ • Comunicación cliente en 15 minutos ││
│ │ • Updates continuos hasta resolver ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SEV-2: ALTO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Definición: ││
│ │ • Feature importante no disponible ││
│ │ • Degradación performance significativa ││
│ │ • Muchos clientes afectados ││
│ │ ││
│ │ Respuesta: ││
│ │ • Equipo on-call activo en 15 minutos ││
│ │ • Horario laboral: team lead informado ││
│ │ • Updates cada 30 minutos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SEV-3: MEDIO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Definición: ││
│ │ • Problemas feature menor ││
│ │ • Workaround disponible ││
│ │ • Algunos clientes afectados ││
│ │ ││
│ │ Respuesta: ││
│ │ • Atender dentro del día laboral ││
│ │ • Trackear en workflow normal ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Roles Incidente
ESTRUCTURA EQUIPO RESPUESTA:
┌─────────────────────────────────────────────────────────────┐
│ ASIGNACIÓN ROLES │
├─────────────────────────────────────────────────────────────┤
│ │
│ COMANDANTE INCIDENTE (IC): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUIÉN: Ingeniero on-call o líder designado ││
│ │ ││
│ │ RESPONSABILIDADES: ││
│ │ • Coordina todas actividades respuesta ││
│ │ • Toma decisiones de escalación ││
│ │ • Asigna tareas a miembros equipo ││
│ │ • Decide cuándo declarar "resuelto" ││
│ │ ││
│ │ NO RESPONSABLE DE: ││
│ │ • Debuggear código (delega a otros) ││
│ │ • Escribir comunicaciones cliente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LÍDER TÉCNICO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUIÉN: Ingeniero más experimentado disponible ││
│ │ ││
│ │ RESPONSABILIDADES: ││
│ │ • Investiga causa raíz ││
│ │ • Implementa fixes ││
│ │ • Asesora IC en decisiones técnicas ││
│ │ • Coordina con otros ingenieros ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LÍDER COMUNICACIONES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUIÉN: PM, líder soporte, o comunicador designado ││
│ │ ││
│ │ RESPONSABILIDADES: ││
│ │ • Actualiza página estado ││
│ │ • Notifica stakeholders ││
│ │ • Responde consultas clientes ││
│ │ • Mantiene timeline incidente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ESCRIBA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUIÉN: Cualquier miembro equipo disponible ││
│ │ ││
│ │ RESPONSABILIDADES: ││
│ │ • Documenta todo en tiempo real ││
│ │ • Registra decisiones y razones ││
│ │ • Captura timeline eventos ││
│ │ • Crea base para post-mortem ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Workflow Respuesta
Respuesta Inicial
PRIMEROS 15 MINUTOS:
┌─────────────────────────────────────────────────────────────┐
│ ACCIONES INMEDIATAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ MINUTO 0-5: DETECCIÓN & DECLARACIÓN │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Alerta disparada (monitoreo) o reportada (usuario) ││
│ │ 2. On-call recibe notificación ││
│ │ 3. Verificar incidente es real (no falsa alarma) ││
│ │ 4. Declarar nivel severidad ││
│ │ 5. Crear canal/tarea incidente ││
│ │ ││
│ │ EN GITSCRUM: ││
│ │ Crear tarea: "INCIDENTE: [Descripción breve]" ││
│ │ Añadir labels: incident, sev-1 (o nivel apropiado) ││
│ │ Asignar: Comandante Incidente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MINUTO 5-10: MOVILIZACIÓN │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Paginar miembros equipo relevantes (si necesario) ││
│ │ 2. Abrir war room (videollamada o canal chat) ││
│ │ 3. Asignar roles: IC, Líder Técnico, Comms, Escriba ││
│ │ 4. Briefear a todos sobre hechos conocidos ││
│ │ ││
│ │ IC DICE: ││
│ │ "Tenemos SEV-1: [descripción]. Soy IC. [Nombre] es ││
│ │ Líder Técnico. [Nombre] maneja comms. [Nombre] ││
│ │ es escriba. Esto es lo que sabemos..." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MINUTO 10-15: INVESTIGACIÓN INICIAL │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Revisar deployments recientes (últimas 24 horas) ││
│ │ 2. Revisar dashboards monitoreo ││
│ │ 3. Verificar estado dependencias externas ││
│ │ 4. Reunir hipótesis iniciales ││
│ │ ││
│ │ LÍDER TÉCNICO PREGUNTA: ││
│ │ "¿Se deployó algo recientemente?" ││
│ │ "¿Cuándo empezaron a degradarse las métricas?" ││
│ │ "¿Es aislado o generalizado?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Comunicación
Updates Estado
PATRONES COMUNICACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ MANTENIENDO STAKEHOLDERS INFORMADOS │
├─────────────────────────────────────────────────────────────┤
│ │
│ UPDATES INTERNOS (en GitScrum Discussions): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TEMPLATE: ││
│ │ ││
│ │ **[HORA] UPDATE INCIDENTE - [NOMBRE INCIDENTE]** ││
│ │ ││
│ │ **Estado:** Investigando / Identificado / Mitigando ││
│ │ **Impacto:** [Quién/qué está afectado] ││
│ │ **Acción actual:** [Qué estamos haciendo] ││
│ │ **Próximo update:** [Hora del próximo update] ││
│ │ ││
│ │ Ejemplo: ││
│ │ "14:35 UPDATE INCIDENTE - Latencia API ││
│ │ Estado: Identificado ││
│ │ Impacto: 50% requests API timing out ││
│ │ Actual: Revirtiendo deploy de 13:45 ││
│ │ Próximo update: 14:45 o cuando se resuelva" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FRECUENCIA UPDATES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SEV-1: Cada 15 minutos o en cambio de estado ││
│ │ SEV-2: Cada 30 minutos ││
│ │ SEV-3: En cambio de estado ││
│ │ ││
│ │ Incluso sin progreso: "Siguiendo investigando. Sin info"││
│ │ Silencio es peor que "sin novedades" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Post-Incidente
Post-Mortem Sin Culpa
APRENDIENDO DE INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ ESTRUCTURA POST-MORTEM │
├─────────────────────────────────────────────────────────────┤
│ │
│ DOCUMENTAR EN NOTEVAULT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ # Post-Mortem: [Nombre Incidente] - [Fecha] ││
│ │ ││
│ │ ## Resumen ││
│ │ • Duración: 2h 15m ││
│ │ • Impacto: 45% usuarios afectados ││
│ │ • Severidad: SEV-1 ││
│ │ ││
│ │ ## Cronología ││
│ │ | Hora | Evento | ││
│ │ |-------|-------------------------------------| ││
│ │ | 13:45 | Deployment a producción | ││
│ │ | 14:02 | Primer reporte cliente | ││
│ │ | 14:15 | Incidente declarado | ││
│ │ | 14:30 | Causa raíz identificada | ││
│ │ | 15:00 | Rollback completado | ││
│ │ | 16:00 | Recuperación completa confirmada | ││
│ │ ││
│ │ ## Causa Raíz ││
│ │ Migración BD en deployment eliminó índice necesario ││
│ │ para path query principal. ││
│ │ ││
│ │ ## Items Acción ││
│ │ • Añadir tests performance queries a CI ││
│ │ • Cambiar ventana deploy a horas bajo tráfico ││
│ │ • Añadir check dependencia índices a review migración ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRINCIPIOS SIN CULPA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ "El sistema permitió que esto pasara" ││
│ │ ❌ "Juan causó la caída" ││
│ │ ││
│ │ Foco: Cómo prevenir que CUALQUIER ingeniero cometa ││
│ │ este error, no "quién cometió el error" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘