Gestión de Incidentes para Líderes

Por Qué Importa la Gestión de Incidentes

Todo sistema de software eventualmente fallará. La pregunta no es si ocurrirán incidentes, sino qué tan preparado está tu equipo para manejarlos. Como Tech Lead, tu rol durante los incidentes se extiende más allá de la resolución técnica: estableces el tono de cómo el equipo responde bajo presión, aseguras que la comunicación fluya a las personas correctas e impulsas el proceso de postmortem que previene la recurrencia.

Las organizaciones con prácticas maduras de gestión de incidentes tienen menor tiempo medio de resolución (MTTR), menos agotamiento de ingenieros y mayor confianza del cliente. Aquellas sin procesos estructurados experimentan fallos en cascada, culturas basadas en culpa y los mismos incidentes recurriendo una y otra vez.

Proceso de Respuesta a Incidentes

Fase 1: Detección y Alertas

Los incidentes deben ser detectados por sistemas de monitoreo, no por quejas de clientes. Invierte en:

• Monitoreo de rendimiento de aplicación (APM) con umbrales de alerta
• Endpoints de health check que verifican dependencias críticas
• Monitoreo de tasa de errores con escalación automática
• Monitoreo sintético (pruebas automatizadas ejecutándose contra producción)
• Página de estado orientada al cliente que se actualiza automáticamente

Fase 2: Triaje y Respuesta

Una vez que se declara un incidente, establece estructura inmediatamente:

## Roles de Respuesta a Incidentes

Comandante de Incidente (IC):
- Es responsable de la respuesta general al incidente
- Coordina entre los respondedores
- Toma decisiones sobre escalación
- Comunica actualizaciones de estado

Líder Técnico:
- Lidera la investigación técnica
- Dirige los esfuerzos de depuración
- Propone e implementa correcciones

Líder de Comunicaciones:
- Actualiza la página de estado
- Notifica a los clientes afectados
- Mantiene informadas a las partes interesadas
- Gestiona el canal de Slack del incidente

Escriba:
- Documenta la línea de tiempo de eventos
- Registra decisiones y acciones tomadas
- Captura información para el postmortem

Fase 3: Mitigación y Resolución

La prioridad durante un incidente activo es mitigar primero, encontrar la causa raíz después. Restaurar el servicio es más importante que entender por qué se rompió. Las estrategias comunes de mitigación incluyen:

• Hacer rollback del despliegue más reciente
• Escalar la infraestructura para manejar carga aumentada
• Habilitar feature flags para deshabilitar funcionalidad problemática
• Hacer failover a un sistema o región de respaldo
• Aplicar un hotfix temporal mientras se investiga la causa raíz

Postmortems Sin Culpa

El postmortem es donde vive el verdadero valor de la gestión de incidentes. Un postmortem sin culpa se enfoca en entender qué sucedió y mejorar los sistemas, no en castigar a individuos. La filosofía es simple: los humanos cometen errores; los sistemas deben diseñarse para prevenir que esos errores causen interrupciones.

## Plantilla de Postmortem

### Resumen del Incidente
- Fecha/Hora: 2026-03-10, 14:32 - 15:47 UTC
- Duración: 1 hora 15 minutos
- Severidad: SEV-2
- Impacto: 40% de las solicitudes API devolvieron errores 500

### Línea de Tiempo
14:32 - Las alertas de monitoreo se disparan por tasa elevada de 5xx
14:35 - El ingeniero de guardia reconoce la alerta
14:40 - Se declara el incidente, se asigna IC
14:45 - Causa raíz identificada: pool de conexiones de BD agotado
14:50 - Intento de mitigación: reiniciar pods de aplicación
14:55 - El reinicio no resolvió; el pool se llena de nuevo en minutos
15:10 - Identificado: nueva funcionalidad con patrón de consulta N+1
15:20 - Feature flag deshabilitada para la nueva funcionalidad
15:30 - Las tasas de error vuelven a la normalidad
15:47 - Incidente resuelto, monitoreo confirma estabilidad

### Causa Raíz
Una nueva funcionalidad desplegada a las 13:00 contenía una consulta N+1
que generaba 500 consultas de base de datos por solicitud API en lugar de 2.
Bajo tráfico normal, esto agotó el pool de conexiones.

### Factores Contribuyentes
- No se realizó prueba de carga antes del despliegue
- Las métricas del pool de conexiones de BD no estaban monitoreadas
- La revisión de código no detectó el patrón N+1

### Elementos de Acción
1. [P0] Agregar monitoreo y alertas del pool de conexiones de BD
2. [P0] Corregir la consulta N+1 en la nueva funcionalidad
3. [P1] Agregar detección de N+1 al pipeline de CI (pg-lint)
4. [P1] Crear requisitos de prueba de carga para funcionalidades
   que toquen endpoints de alto tráfico
5. [P2] Agregar conteo de consultas de BD al checklist de revisión de código

Mejores Prácticas de Guardia

• Runbooks: Crea guías paso a paso para cada alerta común para que cualquier ingeniero de guardia pueda responder
• Equidad en la rotación: Distribuye la guardia equitativamente. Compensa a los ingenieros por trabajo fuera de horario.
• Rutas de escalación: Documentación clara de a quién escalar y cuándo
• Proceso de traspaso: Traspaso estructurado entre rotaciones documentando problemas activos
• Calidad de alertas: Revisa y ajusta las alertas regularmente. Una rotación de guardia con 50 falsas alarmas por semana crea fatiga de alertas.