Por Andrew Tan
La paradoja del postmortem
Ahora todas las grandes empresas tecnológicas los publican. Stripe tiene una página de estado llena de ellos. Netflix escribe análisis de ingeniería detallados. Uber, LinkedIn, GitHub, Cloudflare — todos han abierto el telón sobre lo que salió mal y por qué.
Aquí está la paradoja: los mismos fallos siguen ocurriendo. No las mismas empresas, no los mismos sistemas, sino los mismos patrones. Un equipo en DoorDash pierde datos de pago de la misma manera que un equipo en Netflix perdió métricas de visualización tres años antes. Un pipeline de Uber se rompe por un cambio de esquema en 2024 de la misma manera que un pipeline de LinkedIn se rompió en 2021.
Pasé las últimas semanas leyendo 50 postmortems públicos e informes de incidentes de empresas que han procesado colectivamente trillones de eventos. El objetivo no era catalogar todos los modos de fallo posibles. Era encontrar los grupos — las causas raíz que aparecen con suficiente frecuencia como para no ser descartadas como mala suerte aislada.
Cuatro patrones dominan. Y aquí está lo que me sorprendió: la mayoría de ellos son prevenibles en la etapa de diseño, no en la etapa de operaciones.
Cómo se seleccionaron los 50
Antes de sumergirse en los patrones, una breve nota sobre la metodología. Me centré en postmortems públicos de empresas que operan infraestructuras de datos a gran escala: Uber, Netflix, Stripe, LinkedIn, GitHub, Cloudflare, DoorDash, Airbnb, Spotify y AWS. Omití brechas de seguridad y caídas puras de infraestructura (como fallos de DNS) a menos que afectaran directamente a los Data Pipelines.
La selección no fue aleatoria. Priorizé postmortems que incluyeran:
- Análisis de causa raíz con profundidad técnica
- Cronología del fallo y recuperación
- Mención explícita de la calidad de los datos o impacto en el pipeline
- Lecciones aprendidas o cambios de proceso
Algunas empresas publican con frecuencia (Cloudflare, GitHub). Otras rara vez (Netflix). Los 50 representan una sección transversal de arquitecturas batch ETL, streaming e híbridas.
Patrón 1: Desviación de esquema (38% de los incidentes)
La causa raíz más común era engañosamente simple: el sistema upstream cambió su formato de datos, y el pipeline no lo sabía.
En un incidente bien documentado, un equipo de datos descubrió que un almacén downstream había estado cargando registros corruptos durante once días. El API fuente había añadido un nuevo campo. El analizador JSON del pipeline lo trató como una clave inesperada y silenciosamente descartó todo el lote de registros. No se activaron alertas porque el pipeline no se estrelló — solo produjo menos filas de las esperadas, y la diferencia estaba dentro de la variación normal hasta que no lo estuvo.
Este no es un caso aislado. Es el comportamiento predeterminado de muchas herramientas de Data Integration.
Los postmortems revelan tres variantes de este patrón:
Desviación aditiva
Aparece un nuevo campo, columna o tipo de evento. El pipeline lo ignora o falla dependiendo de cuán estricta sea su validación de esquema. La mayoría de los postmortems señalaron que sus pipelines estaban configurados para ser "permisivos" porque la validación estricta había causado falsas alarmas en el pasado.
Desviación de tipo
Un campo existente cambia su tipo. Una cadena se convierte en un número. Una marca de tiempo pierde su zona horaria. Estos son los más difíciles de detectar porque los datos aún parecen válidos. Un postmortem describió una métrica de ingresos que se duplicó silenciosamente porque un campo de código de moneda cambió de formato ISO a un enum numérico, y el pipeline interpretó el valor del enum como un multiplicador.
Desviación semántica
El formato permanece igual, pero el significado cambia. Un campo "user_id" comienza a contener IDs de dispositivos en lugar de IDs de cuentas. Un campo "status" gana un nuevo estado que la lógica downstream trata como un error. Los datos pasan todas las verificaciones de validación y aún están incorrectos.
Lo que es sorprendente es cuán raramente estos incidentes fueron detectados por registros de esquemas o contratos de datos. En la mayoría de los casos, los equipos tenían un registro. Simplemente no se aplicaba en el límite del pipeline. El esquema estaba documentado en algún lugar, pero el pipeline no estaba obligado a validar contra él.
Patrón 2: Contrapresión y picos de carga (24% de los incidentes)
El segundo grupo involucra pipelines que funcionan perfectamente a carga normal y colapsan bajo volumen inesperado. El desencadenante varía — una campaña de marketing, un evento viral, un ciclo de informes trimestrales, un trabajo upstream mal configurado que de repente emite 10 veces su tasa habitual.
El modo de fallo es casi siempre el mismo: el pipeline no puede deshacerse de la carga, por lo que la deja caer.
Un postmortem de una plataforma de streaming describió un consumidor de Kafka que se retrasó seis horas durante un lanzamiento de producto. El grupo de consumidores se autoescaló, pero las nuevas instancias alcanzaron un límite de grupo de conexiones de base de datos que nunca había sido probado a esa escala. El pipeline no se estrelló. Simplemente dejó de procesar nuevos eventos mientras los antiguos caducaban. Para cuando el equipo se dio cuenta, los datos habían desaparecido.
Otro describió un trabajo batch ETL que funcionó bien durante dos años hasta el Black Friday, cuando el sistema fuente emitió archivos 40 veces más grandes de lo habitual. El trabajo se ejecutó durante 18 horas, agotó el almacenamiento temporal y falló sin limpiar sus salidas parciales. La siguiente ejecución programada comenzó sobre los datos corruptos.
El hilo común: estos pipelines fueron diseñados para operación en estado estable, no para condiciones límite. Tenían monitoreo para si estaban funcionando, pero no para qué tan cerca de sus límites estaban operando.
Varios postmortems señalaron que las pruebas de carga habían sido despriorizadas porque "simplemente autoescalaremos". La autoescalabilidad funciona para el cómputo. No funciona para grupos de conexiones, límites de memoria, I/O de disco o límites de tasa de API downstream — los cuellos de botella que realmente rompen los pipelines.
Patrón 3: Pérdida de datos silenciosa (19% de los incidentes)
Este es el patrón que mantiene a los ingenieros despiertos por la noche. El pipeline informa éxito. Los paneles muestran verde. El SLA se cumple. Pero los datos están incompletos, duplicados o corruptos — y nadie lo sabe hasta que un usuario de negocio pregunta por qué los números se ven mal.
La pérdida silenciosa aparece en varias formas a través de los postmortems:
El filtro que fue demasiado agresivo
Una regla de calidad de datos eliminó registros que coincidían con un patrón mal formado. La regla estaba destinada a capturar datos upstream corruptos, pero también capturó registros legítimos con valores inusuales pero válidos. Durante tres semanas, se filtraron el 12% de las transacciones legítimas.
El exactamente una vez que no lo fue
Un pipeline afirmaba tener semántica exactamente una vez, pero usaba un sink no idempotente. Cuando un error de red transitorio desencadenó un reintento, algunos registros se escribieron dos veces. La lógica de deduplicación existía en teoría pero no en la ruta de código real.
La brecha de retención
Un pipeline de streaming escribió en una cola de mensajes con una ventana de retención de 24 horas. Cuando el procesamiento downstream se retrasó debido a un incidente separado, los datos no procesados expiraron antes de la recuperación. Los registros del pipeline mostraron escrituras exitosas. Los datos simplemente no estaban allí cuando alguien intentó leerlos.
Lo que hace que la pérdida silenciosa sea tan peligrosa es que es invisible para el monitoreo tradicional. Las métricas de salud del pipeline — tiempo de ejecución, throughput, tasa de errores — no la detectan. Necesitas métricas de calidad de datos: conteos de filas, verificaciones de cardinalidad, integridad referencial, pruebas de distribución. La mayoría de los postmortems admitieron que estas verificaciones se agregaron después del incidente, no antes.
Patrón 4: Fallos en cascada por estado compartido (14% de los incidentes)
El grupo más pequeño pero a menudo el más catastrófico. Estos son incidentes donde un fallo en un pipeline corrompe o desactiva otros a través de infraestructura compartida.
Un postmortem memorable describió un evento "píldora venenosa" — un solo registro mal formado que causó que un analizador entrara en un bucle infinito. El hilo del consumidor se colgó, la partición se reequilibró, y el nuevo hilo del consumidor también se colgó. En minutos, un grupo entero de consumidores estaba fuera de línea. Debido a que el pipeline compartía un clúster de Kafka con otros servicios, la compactación de registros del broker se vio afectada, y pipelines no relacionados comenzaron a ver un aumento en la latencia.
Otro describió un almacén de metadatos utilizado por múltiples trabajos batch. Una migración de esquema para un trabajo bloqueó la tabla de metadatos durante 90 segundos. Cada otro trabajo que tocaba la misma tabla falló o agotó el tiempo de espera. Lo que debería haber sido un problema de un solo equipo se convirtió en un incidente a nivel de empresa.
La lección de estos postmortems no es solo "aísla tus fallos". Es que el estado compartido es a menudo invisible. Los equipos no se dan cuenta de que están compartiendo infraestructura hasta que falla. El clúster de Kafka, la tabla de metadatos, el montaje NFS compartido — estos no se consideran parte del diseño del pipeline, pero son parte de su dominio de fallo.
Cómo se veían el 5% restante
El resto de los postmortems fueron genuinamente casos aislados: un rayo cósmico cambiando un bit, un API de proveedor cambiando su comportamiento sin aviso, un certificado expirando en un fin de semana festivo. Estos son los fallos que no puedes diseñar para evitar. El 95% anterior, sí puedes.
La lista de verificación de diseño
Después de leer estos 50 postmortems, seguí viendo la misma brecha. Los fallos no ocurrieron porque los equipos carecieran de talento, herramientas o conciencia. Ocurrieron porque no se hicieron preguntas de diseño específicas lo suficientemente temprano.
Aquí hay seis preguntas que, si se responden honestamente durante la revisión de diseño, habrían prevenido la mayoría de los incidentes que analicé:
1. ¿Qué sucede cuando el esquema cambia sin aviso?
No "¿tenemos un registro de esquema?" — esa es una pregunta de herramientas. La pregunta de diseño es: ¿el pipeline falla cuando el esquema se desvía de las expectativas, o se adapta silenciosamente? El comportamiento adaptativo parece más seguro hasta que produce datos incorrectos. Predetermina a fallar. Haz que los desajustes de esquema sean ruidosos.
2. ¿Cuál es la carga máxima que este pipeline ha sido probado y qué se rompe primero cuando la excedemos?
La mayoría de los equipos prueban para corrección. Muchos menos prueban para límites. Conoce tu primer cuello de botella — memoria, conexiones, disco, límites de tasa downstream — y ten un plan de degradación gradual para cuando lo alcances.
3. ¿Cómo sabríamos si estuviéramos perdiendo silenciosamente el 10% de nuestros datos?
Esta es la pregunta más importante. Si tu única validación es "el trabajo terminó", estás volando a ciegas. Necesitas verificaciones de calidad de datos independientes que comparen el volumen de salida, la distribución y las métricas clave contra las líneas base históricas.
4. ¿Son seguros nuestros reintentos?
Cualquier lógica de reintento es un mecanismo potencial de duplicación a menos que el sink sea estrictamente idempotente. Revisa cada llamada de API, cada escritura de base de datos, cada anexado de archivo. Si no puedes garantizar idempotencia, garantiza al menos una vez y acepta la pérdida ocasional sobre la duplicación garantizada.
5. ¿Qué otros sistemas fallan si este lo hace?
Mapea tu dominio de fallo. Si tu pipeline se cuelga, ¿bloquea una cola compartida? ¿Agota un grupo de conexiones? ¿Llena un disco que otros trabajos necesitan? Diseña para contención de radio de explosión, no solo para recuperación.
6. ¿Puede alguien que nunca ha visto este pipeline depurarlo a las 3 AM?
Los postmortems con los tiempos de recuperación más rápidos tenían una cosa en común: observabilidad que no requería conocimiento institucional. Registros que explican decisiones, no solo cambios de estado. Métricas que muestran la salud de los datos, no solo la salud del sistema. Alertas que apuntan a la causa raíz, no solo a los síntomas.
La verdad incómoda
Leer 50 postmortems no te hace inmune al fallo. Pero sí hace que los patrones sean obvios. Y los patrones son, en su mayoría, aburridos. Desviación de esquema. Límites de carga. Validación faltante. Estado compartido. Estos no son problemas exóticos de sistemas distribuidos. Son higiene de diseño.
Los equipos que publicaron estos postmortems están entre los mejores del mundo en construir infraestructura de datos. Si todavía están enfrentando estos patrones, todos los demás también lo están. La diferencia es si los detectas en la revisión de diseño o a las 3 AM.
Si estás diseñando Data Pipelines y quieres una plataforma que haga cumplir contratos de esquema, maneje backpressure con gracia y te brinde depuración visual cuando las cosas salen mal — ya sea batch o streaming — echa un vistazo a layline.io. 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 batch y en tiempo real a escala.