Por Andrew Tan
Las verdaderas razones por las que los data pipelines de producción fallan en medio de la noche y las prácticas de ingeniería que lo previenen
El buscapersonas suena
Son las 3:17 AM. Tu teléfono vibra fuera de la mesita de noche. Lo buscas a tientas, entrecerrando los ojos por el brillo, y ves el mismo mensaje que has visto antes: "Data pipeline fallido. Última ejecución exitosa: hace 14 horas."
Sabes lo que sigue. Pasarás las próximas dos horas en hilos de Slack, mirando registros que no tienen sentido, tratando de averiguar si esta es la misma falla de la semana pasada o algo nuevo. Para las 6 AM, tendrás una solución temporal en funcionamiento. Para las 9 AM, le dirás a tu equipo que está "resuelto por ahora". Y para el próximo mes, lo harás todo de nuevo.
He estado allí. Más veces de las que me gustaría admitir. Y después de años construyendo infraestructura de datos y hablando con equipos que han pasado por el mismo ciclo, he notado algo: las fallas de las 3 AM no son aleatorias. Siguen patrones. Y la mayoría de ellas son prevenibles.
¿Por qué específicamente a las 3 AM?
No hay nada mágico sobre la hora. Pero sí hay algo predecible sobre las condiciones que existen a las 3 AM:
El factor humano está en su punto más bajo. Los ingenieros que construyeron el pipeline están dormidos. Los operadores que conocen las peculiaridades están fuera de turno. El conocimiento institucional que vive en la cabeza de alguien no está accesible. Te quedas con documentación que era precisa hace seis meses y un manual de operaciones que omite los pasos que "todos conocen".
El volumen de datos a menudo alcanza su pico. Las bases de usuarios globales significan que "noche" en tu zona horaria es "día" en otro lugar. ¿Esa falla de las 3 AM? Probablemente está ocurriendo cuando tus usuarios asiáticos o europeos están más activos. El pipeline que manejaba 10,000 eventos por minuto al mediodía de repente se está ahogando en 50,000.
Las dependencias fallan en cadenas en cascada. Tu pipeline no existe en aislamiento. Extrae de bases de datos que ejecutan sus propias ventanas de mantenimiento. Escribe en APIs que tienen límites de tasa. Depende de servicios que despliegan actualizaciones durante horas de menor actividad. Cuando un eslabón se rompe a las 3 AM, los efectos dominó golpean tu pipeline antes de que alguien esté despierto para notarlo.
Los trabajos por lotes se acumulan. Ese trabajo ETL de las 2 AM funciona bien hasta el día que no lo hace. Tal vez el sistema fuente fue más lento. Tal vez el volumen de datos fue mayor. Tal vez un problema de red añadió 20 minutos de latencia. De repente, tu trabajo de las 2 AM todavía está en ejecución a las 3 AM, y el trabajo de las 3 AM —del que depende tu panel de control— comienza de todos modos, creando una condición de carrera que corrompe la mitad de tus datos.
La falla de las 3 AM no es un solo error. Es la intersección de múltiples decisiones de diseño que estaban bien en aislamiento pero catastróficas juntas.
Los cinco patrones que causan la mayoría de las fallas nocturnas
Después de observar a docenas de equipos depurar estos incidentes, he identificado cinco patrones recurrentes:
1. La falla silenciosa
El trabajo informa "éxito" pero produjo datos basura. No se activaron alertas porque el pipeline no se estrelló, simplemente hizo silenciosamente lo incorrecto. No te das cuenta hasta que alguien en la mañana pregunta por qué los números de ingresos de ayer parecen un número de teléfono.
Por qué ocurre por la noche: Las fallas diurnas son detectadas por humanos que miran paneles de control y notan anomalías. Las fallas nocturnas esperan hasta la mañana.
La solución: Puertas de validación. Cada pipeline debería tener verificaciones explícitas de calidad de datos que fallen el trabajo si las salidas no cumplen con las expectativas. Conteos de filas dentro de rangos esperados. Tasas de nulos por debajo de umbrales. Verificaciones de integridad referencial. Si los datos están mal, el pipeline debería fallar ruidosamente, no tener éxito silenciosamente.
2. El agotamiento de recursos
Tu pipeline funcionó bien en staging. Funcionó bien durante meses en producción. Luego, un día, el volumen de datos alcanzó un umbral que no sabías que existía, y de repente te quedas sin memoria, sin disco o sin cuota de API.
Por qué ocurre por la noche: Muchos límites de recursos son suaves hasta que no lo son. Las fugas de memoria se acumulan. Los archivos de registro crecen. Las tablas temporales se llenan. El trabajo de las 3 AM es el que finalmente golpea la pared.
La solución: Monitoreo de recursos con límites proactivos. No solo monitorees si el trabajo terminó, monitorea las tendencias de uso de memoria, las trayectorias de espacio en disco, el consumo de cuota de API. Establece alertas en umbrales del 70%, no del 100%. Y diseña para una degradación elegante: si no puedes procesar todo, ¿puedes procesar el subconjunto más importante?
3. El tiempo de espera de dependencia externa
Tu pipeline llama a una API. Usualmente responde en 200ms. Esta noche está tardando 30 segundos. Tu tiempo de espera predeterminado es de 60 segundos, por lo que el trabajo no falla inmediatamente, solo se ralentiza hasta arrastrarse. Para cuando se agota el tiempo, está manteniendo bloqueos en recursos que otros trabajos necesitan.
Por qué ocurre por la noche: Los servicios de terceros hacen mantenimiento durante horas de menor actividad. Las rutas de red se redirigen. El DNS se propaga. La infraestructura que no controlas cambia sin advertencia.
La solución: Interruptores automáticos y tiempos de espera ajustados a la realidad. Si el 99% de las llamadas a la API se completan en menos de 5 segundos, establece tu tiempo de espera en 10 segundos, no en 60. Implementa interruptores automáticos que fallen rápidamente cuando una dependencia está luchando. Diseña la lógica de reintento con retroceso exponencial, no con reintentos inmediatos que golpeen un servicio en apuros.
4. La desincronización de estado
Tu pipeline procesa eventos en orden. Pero esta noche, los eventos llegaron fuera de orden. O llegaron eventos duplicados. O llegaron eventos con marcas de tiempo que no tienen sentido entre sí. Tu agregación con estado produjo tonterías porque se violaron las suposiciones sobre el orden de los eventos.
Por qué ocurre por la noche: Los sistemas distribuidos son eventualmente consistentes. Las particiones de red ocurren. Las colas de mensajes se reordenan bajo carga. Las invariantes que asumiste —"los eventos llegan en orden", "los eventos llegan exactamente una vez"— son garantías que tu infraestructura no proporciona realmente.
La solución: Gestión defensiva del estado. Usa procesamiento en tiempo de evento, no en tiempo de procesamiento. Maneja eventos fuera de orden con marcas de agua. Diseña para semánticas de al menos una vez y haz que tus agregaciones sean idempotentes. Asume que los eventos llegarán tarde, duplicados o faltantes, y manéjalo con elegancia.
5. La deriva de configuración
El pipeline funcionó ayer. Nada cambió en el código. Pero alguien actualizó una variable de entorno. O rotó una credencial. O cambió un esquema de base de datos sin actualizar el pipeline. El código es el mismo, pero el mundo en el que se ejecuta cambió.
Por qué ocurre por la noche: Los cambios en la infraestructura a menudo se despliegan durante ventanas de mantenimiento. Las migraciones de esquemas se ejecutan en horas de menor actividad. Las rotaciones de credenciales ocurren en horarios. El trabajo de las 3 AM es el primero en encontrarse con el nuevo mundo.
La solución: Configuración como código, probada como código. Cada variable de entorno, cada referencia secreta, cada suposición de esquema debería estar controlada por versiones y validada. Ejecuta pipelines en un modo de "prueba" después de cambios en la infraestructura. Alerta sobre la deriva de esquemas. Trata los cambios de configuración con el mismo rigor que los cambios de código.
El cambio de mentalidad: de "manejar fallas" a "prevenirlas"
La mayoría de los equipos de datos que conozco operan en modo reactivo. El pipeline falla. Lo arreglan. Documentan lo que sucedió. Siguen adelante. Luego falla de nuevo, por una razón ligeramente diferente, y el ciclo se repite.
Los equipos que no son alertados a las 3 AM tienen un enfoque diferente. Piensan en términos de dominios de falla y radio de impacto. Preguntan: "Si este componente falla, ¿qué más se rompe?" Diseñan para una degradación elegante en lugar de una confiabilidad perfecta.
Así es como se ve en la práctica:
Prueba de fallas, no solo caminos de éxito. Tu suite de pruebas debería incluir escenarios donde las dependencias se agotan, los datos están mal formados y los recursos se agotan. Si solo pruebas el camino feliz, no estás probando producción.
Observabilidad sobre monitoreo. El monitoreo te dice que un trabajo falló. La observabilidad te dice por qué. Invierte en trazabilidad que siga eventos a través de tu pipeline. Registra contexto, no solo eventos. Construye paneles que muestren la salud de la calidad de los datos, no solo la finalización de trabajos.
Ingeniería del caos para data pipelines. Si no has roto deliberadamente tu pipeline de manera controlada, no sabes cómo falla. Realiza simulacros donde desconectas conexiones de bases de datos, introduces latencia y corrompes datos de entrada. Conoce tus modos de falla antes de que ellos te conozcan a ti.
Guardia que escala a personas que pueden solucionarlo. La persona que recibe la alerta a las 3 AM debería ser alguien que realmente pueda solucionar el problema, no solo reiniciar el trabajo y esperar. Si tu rotación de guardia es demasiado junior, solo estás retrasando la solución real hasta la mañana de todos modos.
Construyendo pipelines que duermen toda la noche
Los data pipelines resilientes comparten rasgos comunes. No son magia, están diseñados con patrones específicos:
Idempotencia en todas partes. Ejecutar el mismo trabajo dos veces debería producir el mismo resultado que ejecutarlo una vez. Esto hace que los reintentos sean seguros y la recuperación automática.
Manejo de backpressure. Cuando los sistemas descendentes no pueden mantenerse al día, el pipeline debería ralentizarse, no colapsar o perder datos. Debería reducir la carga de manera elegante, no catastrófica.
Estado acotado. Las operaciones con estado deberían tener límites. Agregaciones con ventanas con TTL. Almacenes de estado con políticas de eliminación. No dejes que un estado ilimitado se convierta en un problema ilimitado.
Contratos explícitos. Define y valida esquemas en los límites del pipeline. Rechaza datos mal formados temprano. Falla rápidamente cuando se violan las suposiciones.
Manuales de operaciones que funcionan. Cada alerta debería tener un manual de operaciones. Cada manual de operaciones debería ser probado. Si el manual dice "verifica los registros", especifica qué registros, qué buscar y qué hacer cuando lo encuentres.
La conclusión
El buscapersonas de las 3 AM no tiene que ser inevitable. Es un síntoma de decisiones de diseño que priorizaron el throughput sobre la resiliencia, la finalización sobre la corrección y la velocidad de características sobre la madurez operativa.
Los equipos que duermen toda la noche no son más afortunados. Han invertido en el trabajo poco glamuroso de manejo de errores, validación y observabilidad. Han aceptado que las fallas ocurrirán y han diseñado sistemas que las manejan con elegancia.
A tus usuarios no les importa si tu pipeline era ingenioso. Les importa si los datos son correctos cuando los necesitan. Construye para eso.
Qué sigue
Si estás cansado de las alertas de las 3 AM, comienza con un cambio: añade una sola puerta de validación a tu pipeline más crítico. Verifica conteos de filas. Verifica tasas de nulos. Valida una métrica clave del negocio. Haz que el pipeline falle si los datos parecen incorrectos.
No es una solución completa, pero es un comienzo. Y una vez que hayas sentido el alivio de detectar un problema de calidad de datos antes de que llegue a tus usuarios, estarás motivado para añadir la siguiente salvaguarda.
Para equipos de ingeniería de datos que construyen data pipelines de streaming, layline.io proporciona manejo de backpressure incorporado, semánticas de exactamente una vez y depuración visual que facilita entender qué está pasando cuando algo sale mal, ya sea a las 3 PM o a las 3 AM. La Community Edition es gratuita para explorar.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresarial que maneja cargas de trabajo tanto por lotes como en tiempo real a escala.
