10 buenas prácticas de gestión de Incidents para equipos de ingeniería

Todo equipo de ingeniería tendrá Incidents en producción. La diferencia entre quienes los gestionan bien y quienes no no es suerte: es preparación. Aquí van 10 prácticas que separan una respuesta efectiva del caos.

1. Define qué constituye un Incident

No todo bug es un Incident, y no toda alerta merece respuesta de Incident. Sin una definición clara, los equipos o reaccionan de más ante problemas menores o reaccionan de menos ante los graves.

Un marco útil:

• Gravedad 1 (crítica): caída total del servicio o pérdida de datos que afecta a todos los usuarios. Todos a cubierto.
• Gravedad 2 (mayor): función importante no disponible o degradación grave del rendimiento. Equipo dedicado.
• Gravedad 3 (menor): impacto parcial, hay workaround. Se atiende en horario laboral.
• Gravedad 4 (baja): cosmético o menor. Se registra como bug, no como Incident.

Escríbelo. Acórdalo en equipo. Revísalo y ajústalo cada trimestre.

2. Automatiza la detección

Si el equipo se entera de las caídas por quejas de clientes, ya vas tarde. El monitoring automatizado debería detectar problemas antes que los usuarios.

Detección automatizada esencial:

• Uptime monitoring de todos los endpoints críticos (intervalos de 15–30 segundos)
• Alertas de tasa de error cuando superen la línea base
• Alertas de rendimiento por degradación del tiempo de respuesta
• Alertas de infraestructura por agotamiento de recursos (CPU, memoria, disco)

Objetivo: detectar Incidents en 60 segundos, notificar al equipo en 90 segundos y empezar la respuesta en 5 minutos.

3. Establece propiedad clara

Cuando hay un Incident, alguien debe mandar. Sin propiedad clara, o no responde nadie («pensé que lo llevaba otro») o responden todos a la vez de forma caótica.

Define roles antes de que ocurra:

• Incident Commander: coordina la respuesta, toma decisiones, comunica el estado. No tiene que ser el ingeniero más senior: debe estar organizado y mantener la calma.
• Technical Lead: diagnostica y corrige. Quien más conoce el sistema afectado.
• Communications Lead: actualiza el Status Page, habla con stakeholders y gestiona el mensaje hacia clientes.

En equipos pequeños, una persona puede cubrir varios roles. Está bien — pero los roles deben ser explícitos.

4. Crea runbooks para escenarios habituales

Bajo presión, hasta ingenieros experimentados se equivocan. Los runbooks reducen la carga cognitiva con procedimientos paso a paso para fallos conocidos.

Un buen runbook incluye:

• Síntomas: ¿cómo se ve este fallo?
• Pasos de diagnóstico: cómo confirmar la causa raíz.
• Pasos de resolución: cómo arreglarlo, paso a paso.
• Rollback: cómo deshacer cambios recientes si son la causa.
• Escalado: cuándo involucrar a más gente o equipos.

Runbooks iniciales típicos:

• Caída / reinicio del servidor de aplicación
• Agotamiento de conexiones a la base de datos
• Caducidad del certificado SSL
• Error de configuración DNS
• Rollback de despliegue
• Mitigación de DDoS

5. Comunica pronto y con honestidad

El silencio durante un Incident es la peor estrategia. Los usuarios rellenan el vacío con suposiciones, y suelen ser peores que la realidad.

Comunicación interna:

• Abre un canal dedicado al Incident al instante
• Publica actualizaciones cada 10–15 minutos como mínimo
• Incluye: lo que sabes, lo que no sabes y lo que estás haciendo
• Marca la hora de los hitos importantes

Comunicación externa:

• Actualiza tu Status Page en los 5 primeros minutos tras detectar el Incident
• Publica actualizaciones según evolucione la situación
• Sé honesto sobre el impacto: no lo minimices
• Da una estimación de tiempo de resolución cuando sea posible

Un mensaje simple como «Estamos investigando tasas de error elevadas en la API. Algunas peticiones pueden fallar. Trabajamos en ello y actualizaremos en 15 minutos» es infinitamente mejor que el silencio.

6. Usa procedimientos según la gravedad

Cada gravedad merece un nivel de respuesta distinto. La misma urgencia para todo genera agotamiento en lo menor y complacencia en lo crítico.

Respuesta gravedad 1:

• Page inmediato al de guardia
• Incident Commander activado
• Status Page actualizado en 5 minutos
• Todos a cubierto si hace falta
• Actualizaciones cada 10 minutos
• Post-mortem obligatorio

Respuesta gravedad 2:

• Notificar al de guardia por Slack y email
• Status Page en 15 minutos
• Actualizaciones cada 30 minutos
• Post-mortem recomendado

Respuesta gravedad 3:

• Registrado en el sistema de incidencias
• Atención en horario laboral
• Status Page si hay impacto visible para el cliente
• Resumen breve documentado

7. Mide métricas con rigor

No mejoras lo que no mides. Sigue estas métricas de Incident:

• MTTD (Mean Time to Detect): del inicio del Incident a la detección. Objetivo: < 2 min para Sev 1.
• MTTR (Mean Time to Recovery): de la detección a la resolución. Es la métrica más importante.
• MTTA (Mean Time to Acknowledge): de la alerta a la primera respuesta humana. Mide la efectividad del de guardia.
• Frecuencia de Incidents: número por semana/mes, por gravedad.
• Duración del impacto para el cliente: cuánto tiempo sufrieron el problema los clientes (no solo desde la detección).

Revísalas cada mes. Fija objetivos de mejora. Celebra el progreso.

8. Haz post-mortems sin culpa

Los post-mortems son la práctica más valiosa para reducir Incidents futuros — si se hacen bien.

Estructura de post-mortem sin culpa:

1. Resumen: un párrafo sobre lo ocurrido.
2. Impacto: quién se vio afectado, cuánto tiempo, cuantificado si es posible.
3. Línea de tiempo: minuto a minuto desde la detección hasta la resolución.
4. Causa raíz: la causa de fondo, no solo el disparador. Pregunta «por qué» cinco veces.
5. Factores agravantes: qué empeoró el Incident o dificultó la resolución.
6. Qué salió bien: qué funcionó en la respuesta.
7. Acciones: mejoras concretas, responsables y plazos.

La parte «sin culpa» es crítica. Si hay miedo a la culpa, se oculta información; sin información no aprendes. Céntrate en sistemas y procesos, no en personas.

9. Mantén una línea de tiempo del Incident

Durante un Incident activo, documenta todo sobre la marcha:

• ¿Cuándo se detectó por primera vez?
• ¿Cuándo se notificó al primer humano?
• ¿Qué pasos de diagnóstico se hicieron?
• ¿Qué se probó y no funcionó?
• ¿Cuándo se identificó la causa raíz?
• ¿Qué corrección se aplicó?
• ¿Cuándo se restauró el servicio?

La documentación en tiempo real ayuda al equipo durante el Incident y alimenta el post-mortem después.

Usa el canal del Incident en Slack/Teams: ya tiene marcas de tiempo y es colaborativo.

10. Practica e itera

La respuesta a Incidents mejora con práctica — pero no quieres esperar a Incidents reales para practicar.

Formas de practicar:

• Game days: simula Incidents y practica procedimientos. Inyecta fallos en staging y sigue los runbooks.
• Ejercicios de mesa: recorre escenarios hipotéticos en equipo. «La base de datos principal cae a las 2 AM un sábado. ¿Qué hacemos?»
• Chaos engineering: introduce fallos en producción (con cuidado) para probar monitoring, alertas y recuperación.
• Retrospectivas: tras cada Incident real, identifica mejoras e impleméntalas.

Los mejores equipos no son los que nunca tienen Incidents: son los que responden rápido, comunican con claridad y aprenden sin parar.

Por dónde empezar

Si construyes la práctica desde cero, empieza aquí:

1. Configura uptime monitoring de tus servicios críticos
2. Crea un Status Page para comunicar con clientes
3. Define niveles de gravedad y procedimientos de respuesta
4. Escribe runbooks para tus 3 modos de fallo más probables
5. Haz tu primer post-mortem tras el próximo Incident

No necesitas un proceso perfecto el día uno. Empieza simple, aprende de cada Incident e itera.

Construye la base de tu respuesta a Incidents. Empieza gratis — uptime monitoring, seguimiento de Incidents y Status Pages en una sola plataforma.