Producción en llamas en desarrollo — qué es, causas y algoritmo de acción

Qué significa “la producción está en llamas” y tipos de fallas

La expresión “la producción está en llamas” (everything is down) describe una situación en la que el entorno de producción funciona incorrectamente y los usuarios se ven afectados. La falla puede manifestarse como indisponibilidad total de la aplicación (pantalla en blanco, error 502), indisponibilidad parcial (el módulo de pagos no funciona pero las demás funciones están disponibles) o degradación del rendimiento (carga extremadamente lenta). La severidad del incidente se determina por el porcentaje de usuarios afectados y la duración de la caída.

Según Atlassian Statuspage (2025), el tiempo de inactividad promedio para aplicaciones móviles en 2024 fue de 27 minutos por incidente. Las causas más comunes: regresión de código tras el despliegue (34%), caída del proveedor de la nube (22%), problemas con la base de datos (18%), errores de configuración (15%) y ataques DDoS (11%). Conclusión clave: la mayoría de las fallas son causadas por cambios que el propio equipo introdujo, no por factores externos.

Es importante distinguir entre un crash (caída de la aplicación en el cliente) y una caída del backend (indisponibilidad del servidor). Un crash generalmente se soluciona con un hotfix del código del cliente, mientras que una caída del backend requiere cambios en la infraestructura o un redespliegue del servicio. Métricas de monitoreo: para el cliente — tasa libre de crashes, para el servidor — tasa de error 5xx y latencia p95. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — ayuda a determinar rápidamente el tipo de falla.

Severidad de incidentes: P0, P1, P2 y criterios de clasificación

Una clasificación unificada de severidad es la base de una respuesta rápida. Sin ella, el equipo pierde tiempo discutiendo “qué tan urgente es esto” en lugar de actuar. La escala clásica: P0 (crítico) — la aplicación está completamente indisponible o se están filtrando datos de usuarios, tiempo de respuesta — inmediato; P1 (alto) — la funcionalidad crítica no funciona para el 50%+ de los usuarios, tiempo de respuesta — 15 minutos; P2 (medio) — funcionalidad no crítica no disponible para algunos usuarios, tiempo de respuesta — 1 hora.

P0 requiere escalación inmediata: el ingeniero de guardia interrumpe cualquier trabajo en curso y se enfoca en el incidente. Si el problema no se resuelve en 10 minutos — se involucra al tech lead. Si después de 30 minutos — escalación al engineering manager. Para incidentes P0 está permitido romper cualquier proceso: hacer un hotfix sin revisión completa de código, desplegar directamente en producción, ignorar las reglas de protección de ramas. Emergency override debe estar preacordado a nivel de equipo.

Tabla de severidad

Es extremadamente importante no equivocarse con la severidad hacia abajo. Los incidentes P0 y P1 clasificados como P2 provocan una respuesta tardía y un aumento del tiempo de inactividad. Regla: si tienes dudas — asigna P0. Sobreclasificar es mejor que subclasificar: es mejor reunirse de más que perder una hora de recuperación.

Primeros 10 minutos: algoritmo de acción durante una falla

El temporizador comienza: desde el momento en que llega una alerta o un mensaje de un usuario. Los primeros 10 minutos son los más importantes. Algoritmo: 1) confirmar el problema — asegurarse de que el problema es real (no una falsa alarma); 2) detener la hemorragia — reducir el impacto de inmediato (rollback, feature toggle, bloqueo de endpoint); 3) comunicar — escribir en el canal general #incident el estado: qué sucedió, severidad, qué se está haciendo. Los primeros 10 minutos no se dedican al análisis de la causa raíz.

En paralelo con detener la hemorragia, un ingeniero comienza el diagnóstico y otro maneja la comunicación. Canales de comunicación: canal de Slack #incident (para el equipo), página de estado (para los usuarios), correo electrónico/SMS de escalación (para la gerencia). Cada 15 minutos — una actualización de estado con información: qué se sabe, qué se está haciendo, tiempo estimado de recuperación. Página de estado (StatusPage, Statuspal) muestra el tiempo de actividad y el historial de incidentes para usuarios externos.

Cómo detener la hemorragia: rollback, feature toggle y hotfix

La primera y más importante regla: no intentes arreglar el problema en producción. Si un nuevo lanzamiento causó la falla — revierte a la versión estable anterior. Si la falla es causada por una funcionalidad específica que está detrás de un feature toggle — simplemente desactiva el toggle. Si ni el rollback ni el toggle están disponibles — aplica un hotfix con un diff mínimo. Rollback es la opción más segura porque regresa a un estado que ya funcionaba.

Feature toggle (también conocido como feature flag) es una herramienta poderosa para detener la hemorragia sin un despliegue. Si el módulo de pagos falla pero está desactivado mediante un toggle — los usuarios simplemente no ven el botón de pago en lugar de recibir una pantalla de error. Un toggle no requiere compilación, no requiere revisión de la tienda, y se activa en segundos. Cada funcionalidad crítica debe estar detrás de un feature toggle con posibilidad de desactivación a nivel de servidor (configuración remota). Feature flag — la primera línea de defensa.

Si el rollback es imposible (por ejemplo, debido a una migración irreversible de base de datos) y no hay un toggle — el último recurso es un hotfix con cambios mínimos. El hotfix se crea desde la última etiqueta de lanzamiento, contiene solo las líneas necesarias para solucionar la falla y pasa por un despliegue acelerado (consulta el artículo “Hotfix — correcciones urgentes”). Regla de oro: después de la estabilización, siempre realiza un análisis de causa raíz, incluso si la causa parece obvia.

Diagnóstico de causas: registros, métricas y alertas

Después de detener la hemorragia (o en paralelo, si la cantidad de ingenieros lo permite), comienza el diagnóstico. La primera fuente son los registros. El registro centralizado (ELK, Grafana Loki, Datadog Logs) permite encontrar errores por marca de tiempo, ID de usuario o ID de solicitud. Importante: los registros deben estar estructurados (JSON) para que grep funcione rápidamente. Registro estructurado es un requisito obligatorio para todos los servicios.

La segunda fuente son las métricas. Grafana, Datadog, New Relic muestran cuándo ocurrió el pico de errores, en qué endpoints y con qué códigos de estado. La comparación de métricas antes y después del despliegue ayuda a localizar el problema en un servicio o endpoint específico. Métricas RED (Rate, Errors, Duration) — el estándar de monitoreo de microservicios.

La tercera fuente es el rastreo distribuido (distributed tracing). Jaeger, Zipkin, Datadog APM muestran la ruta de la solicitud a través de los microservicios e identifican dónde exactamente ocurrió la demora o el error. El rastreo es especialmente útil en fallas en cascada, cuando una falla en un servicio causa errores en todos los dependientes. Trace ID debe transmitirse desde el cliente a todos los servicios del backend.

# Ejemplo de diagnóstico rápido usando kubectl y logs
# Listar pods con errores
kubectl get pods --field-selector=status.phase!=Running

# Ver logs del pod caído
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Buscar errores en el servicio de los últimos 30 minutos
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Importante: no intentes diagnosticar la causa antes de detener la hemorragia. Si el 50% de los usuarios ven un crash — primero revierte, luego investiga. Excepción: si un rollback tomara más tiempo que un hotfix directo (por ejemplo, debido a incompatibilidad de datos). En este caso, aplica el hotfix de inmediato y realiza el post-mortem después de la estabilización. Diagnosticar antes de arreglar es un patrón peligroso que aumenta el tiempo de inactividad.

Post-mortem: cómo analizar incidentes sin buscar culpables

Post-mortem (también llamado revisión de incidentes) es un análisis estructurado del incidente realizado entre 24 y 72 horas después de su resolución. Su objetivo: entender por qué ocurrió la falla, por qué el monitoreo y las pruebas no la detectaron antes de producción, y qué cambiar en los procesos para prevenir que se repita. Cultura sin culpas es un principio fundamental: el post-mortem discute procesos, herramientas y comunicación, no los errores de personas específicas.

Estructura del documento post-mortem: cronología (secuencia de eventos con marcas de tiempo), impacto (usuarios afectados, duración, pérdidas financieras), causa raíz (causa técnica principal), detección (cómo se descubrió, por qué no se detectó antes), respuesta (qué se hizo, qué se pudo haber hecho más rápido), acciones (tareas específicas con responsables y plazos). Las acciones deben ser S.M.A.R.T.: específicas, medibles, asignables, realistas y con plazo definido.

Acciones típicas después de una falla de producción: agregar monitoreo y alertas para la métrica que estaba en silencio; ampliar la cobertura de pruebas para el caso omitido; agregar una página al runbook con un algoritmo paso a paso para una situación similar; capacitar al equipo en la herramienta que se usó incorrectamente. Cada acción es un cambio concreto que reduce la probabilidad de que el incidente se repita.