8 min lectura • Guide 836 of 877
Respuesta a Incidentes para Equipos de Desarrollo
Cuando las cosas fallan, el proceso ayuda. GitScrum ayuda a los equipos a trackear incidentes junto al trabajo de desarrollo, conectando fixes a sus eventos disparadores.
Básicos de Incidentes
Qué Es un Incidente
DEFINICIÓN DE INCIDENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ UN INCIDENTE ES: │
│ ─────────────── │
│ Interrupción no planeada del servicio │
│ Degradación significativa de calidad del servicio │
│ Breach de SLA o SLO │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NIVELES DE SEVERIDAD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SEV-1 (CRÍTICO): ││
│ │ • Outage completo del servicio ││
│ │ • Feature mayor rota para todos los usuarios ││
│ │ • Pérdida de datos o breach de seguridad ││
│ │ Respuesta: Todas las manos, 24/7 ││
│ │ ││
│ │ SEV-2 (ALTO): ││
│ │ • Outage parcial o degradación ││
│ │ • Feature mayor rota para algunos usuarios ││
│ │ • Workaround existe pero doloroso ││
│ │ Respuesta: Inmediata durante horario laboral ││
│ │ ││
│ │ SEV-3 (MEDIO): ││
│ │ • Feature menor rota ││
│ │ • Performance degradado pero usable ││
│ │ • Subconjunto pequeño de usuarios afectados ││
│ │ Respuesta: Siguiente día hábil ││
│ │ ││
│ │ SEV-4 (BAJO): ││
│ │ • Issues cosméticos ││
│ │ • Inconveniente menor ││
│ │ Respuesta: Trabajo programado ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OBJETIVO: Restaurar servicio ASAP, aprender después │
└─────────────────────────────────────────────────────────────┘
Fases de Incidentes
Flujo de Respuesta
CICLO DE VIDA DEL INCIDENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FASE 1: DETECTAR │
│ ─────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ FUENTES: ││
│ │ • Alertas de monitoreo automatizadas ││
│ │ • Reportes de clientes ││
│ │ • Avisos de equipo interno ││
│ │ ││
│ │ ACCIÓN: ││
│ │ Crear registro de incidente inmediatamente ││
│ │ No esperar a confirmar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FASE 2: TRIAGE │
│ ─────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PREGUNTAS: ││
│ │ • ¿Cuál es el impacto? ││
│ │ • ¿Quién está afectado? ││
│ │ • ¿Cuál es la severidad? ││
│ │ ││
│ │ ACCIÓN: ││
│ │ Asignar severidad ││
│ │ Pagear responders apropiados ││
│ │ Abrir canal de incidente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FASE 3: RESPONDER │
│ ──────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INVESTIGAR: ││
│ │ • Revisar logs, métricas, cambios recientes ││
│ │ • Formar hipótesis ││
│ │ • Probar y validar ││
│ │ ││
│ │ ARREGLAR: ││
│ │ • Aplicar remediación (restart, rollback, patch) ││
│ │ • Verificar servicio restaurado ││
│ │ • Monitorear recurrencia ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FASE 4: RECUPERAR │
│ ──────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Confirmar servicio estable ││
│ │ • Cerrar incidente ││
│ │ • Programar post-mortem ││
│ │ • Comunicar resolución ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FASE 5: APRENDER │
│ ────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Conducir post-mortem ││
│ │ • Documentar hallazgos ││
│ │ • Crear tareas de seguimiento ││
│ │ • Compartir aprendizajes ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Roles Durante Incidentes
Equipo de Incidentes
ROLES DE INCIDENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENT COMMANDER (IC): │
│ ──────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RESPONSABILIDADES: ││
│ │ • Coordina respuesta ││
│ │ • Toma decisiones cuando no está claro ││
│ │ • Asegura que la comunicación ocurra ││
│ │ • Delega tareas ││
│ │ ││
│ │ NO HACE: ││
│ │ • Debugear el issue (usualmente) ││
│ │ • Escribir código ││
│ │ ││
│ │ DICE: ││
│ │ "Alex, investiga conexiones de database" ││
│ │ "Jordan, actualiza status page" ││
│ │ "¿Cuál es nuestra teoría actual?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RESPONDERS TÉCNICOS: │
│ ───────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RESPONSABILIDADES: ││
│ │ • Investigar causa raíz ││
│ │ • Proponer e implementar fixes ││
│ │ • Reportar hallazgos a IC ││
│ │ ││
│ │ DICE: ││
│ │ "Veo connection pool agotado en logs" ││
│ │ "Reiniciando servicio ahora" ││
│ │ "Fix deployado, monitoreando" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LEAD DE COMUNICACIONES: │
│ ──────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RESPONSABILIDADES: ││
│ │ • Actualizar status page ││
│ │ • Comunicar con clientes ││
│ │ • Mantener stakeholders informados ││
│ │ ││
│ │ Para equipos pequeños: IC maneja esto ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SCRIBE: │
│ ─────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RESPONSABILIDADES: ││
│ │ • Documentar timeline ││
│ │ • Registrar acciones tomadas ││
│ │ • Anotar hallazgos clave ││
│ │ ││
│ │ Esencial para precisión del post-mortem ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Comunicación
Durante Incidentes
COMUNICACIÓN DE INCIDENTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COMUNICACIÓN INTERNA: │
│ ─────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ #incident-2025-01-21-api-outage ││
│ │ ││
│ │ 14:32 [IC] Incidente declarado - API retornando 503s ││
│ │ Severidad: SEV-1 ││
│ │ Impacto: Todos los usuarios afectados ││
│ │ ││
│ │ 14:35 [Alex] Investigando. Conexiones DB lucen altas. ││
│ │ ││
│ │ 14:38 [IC] Alex continúa DB. Jordan revisa app logs. ││
│ │ ││
│ │ 14:42 [Alex] Connection pool agotado. Deploy reciente ││
│ │ agregó query sin cerrar conexiones. ││
│ │ ││
│ │ 14:45 [IC] Decisión: Rollback a versión anterior. ││
│ │ Alex procede con rollback. ││
│ │ ││
│ │ 14:48 [Alex] Rollback completo. Monitoreando. ││
│ │ ││
│ │ 14:55 [IC] Servicio restaurado. Tasa de error volvió ││
│ │ a normal. Manteniendo incidente abierto 15 min. ││
│ │ ││
│ │ 15:10 [IC] Incidente resuelto. Post-mortem programado ││
│ │ para mañana 10 AM. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ COMUNICACIÓN EXTERNA: │
│ ──────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ UPDATES DE STATUS PAGE: ││
│ │ ││
│ │ 14:35 - Investigando ││
│ │ "Estamos investigando reportes de errores de API. ││
│ │ Algunos usuarios pueden experimentar issues accediendo ││
│ │ al servicio. Proporcionaremos updates según aprendamos."││
│ │ ││
│ │ 14:50 - Identificado ││
│ │ "Hemos identificado la causa y estamos deployando ││
│ │ un fix. El servicio debería restaurarse en 15 minutos."││
│ │ ││
│ │ 15:10 - Resuelto ││
│ │ "El issue ha sido resuelto. API está completamente ││
│ │ operacional. Pedimos disculpas por cualquier molestia."││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FRECUENCIA DE UPDATE: │
│ Cada 15-30 min durante incidente activo │
│ Incluso si solo es "Aún investigando, sin nueva info" │
│ El silencio es peor que no tener noticias │
└─────────────────────────────────────────────────────────────┘
Post-Mortems Sin Culpa
ESTRUCTURA DE POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRINCIPIO CORE: │
│ ─────────────── │
│ Enfocarse en QUÉ pasó, no QUIÉN lo causó │
│ Las personas hicieron lo mejor que pudieron con la info │
│ que tenían. La culpa crea miedo, el miedo oculta problemas │
│ │
│ SECCIONES DEL DOCUMENTO: │
│ • Resumen del incidente │
│ • Impacto y métricas │
│ • Timeline detallado │
│ • Causa raíz y factores contribuyentes │
│ • Qué funcionó bien │
│ • Qué podría mejorar │
│ • Action items con dueños y fechas │
│ │
│ TIMING: Dentro de 48-72 horas del incidente │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Roles claros previenen confusión durante el caos
- Comunicar frecuentemente incluso sin novedades
- Documentar en tiempo real para post-mortem preciso
- Sin culpa enfocarse en sistemas, no personas
- Action items concretos con dueño y fecha
- Compartir aprendizajes a través de equipos