Rescate de un ETL de facturación electrónica que fallaba en silencio
Recibí un pipeline heredado que perdía facturas reportando éxito. Lo audité contra producción y lo puse bajo pruebas, CI y despliegue por etiqueta; hoy falla en rojo, avisa solo y se audita factura por factura.
Ficha del proyecto
- Rol
- Ingeniero de datos a cargo del rescate y la operación del sistema
- Periodo
- ago de 2026 a hoy
- Enlaces públicos
- Sistema interno: el código es privado, y los nombres, datos y diagramas se omitieron o se recrearon.
74
hallazgos de auditoría, cada uno con evidencia medida contra producciónFuente: Auditoría técnica del sistema, agosto de 2026 0 a 151
pruebas automatizadas, en un código que llegó sin ningunaFuente: Suite de pytest del repositorio, septiembre de 2026 532
filas del portal cruzadas contra tres bases de datos para cuantificar un incidente el mismo díaFuente: Expediente del incidente de cambio de mes, septiembre de 2026
El problema
Un pipeline construido por un tercero descargaba las facturas electrónicas de proveedores desde el portal del operador de facturación, las convertía y las cargaba en el ERP financiero de dos empresas, tres veces al día. Llegó sin control de versiones, sin pruebas y con un defecto grave, porque podía perder facturas y aun así terminar en verde.
Mi rol
- Audité el sistema de punta a punta y documenté 74 hallazgos, con un resumen en el lenguaje del área usuaria.
- Lo puse bajo git, pruebas, CI con protección de rama y despliegue por etiqueta, sin detener las corridas diarias.
- Corregí las fallas que perdían facturas y migré la llave primaria de las tablas de destino, con ensayo previo en desarrollo.
- Opero el sistema, con incidentes, conciliaciones, despliegues y comunicación con el área financiera.
Restricciones
- El proceso no podía detenerse, porque de él dependen las cuentas por pagar de dos empresas.
- El portal de origen es de un tercero y cambia sin aviso, y descargar altera el estado del proceso real.
- Las bases de datos de destino son compartidas con otros sistemas, y cada cambio se coordina con su administrador.
- El orquestador lo comparten otros seis flujos de trabajo.
Decisiones
- 01
Auditar y medir antes de corregir
Una línea base medida contra producción permitió priorizar por impacto de negocio y demostrar cada mejora con cifras, en lugar de reescribir por intuición.
Descartado
- Reescribir el pipeline desde cero
- 02
Extraer un dominio puro y probado del código de scraping
Las reglas de calendario, paginación y clasificación salieron a módulos sin red ni secretos, con doctests como contrato. Se prueban en menos de un segundo sin tocar el portal.
Descartado
- Probar solo de punta a punta contra el portal real
- 03
Una corrida que no hizo nada termina en rojo
El defecto de origen era reportar éxito sin haber cargado nada. Ahora cada tarea verifica su resultado y, si el conteo no cuadra, falla y avisa por correo.
Descartado
- Agregar más reintentos y dejar el estado en verde
- 04
Un servidor MCP para diagnosticar el orquestador
Expone corridas, fallos agrupados por firma y análisis de causa raíz de los logs como herramientas para un agente de IA. Las dos herramientas que escriben simulan por defecto y exigen confirmación explícita.
Descartado
- Revisar los logs a mano en la interfaz del orquestador
Arquitectura
Origen
- Portal del operador de facturaciónPDF y XML de cada factura
Orquestación
- DescargaSelenium Grid, calendario y rejilla paginada
- ConversiónXML UBL a documento
- CargaSegún la empresa receptora
Almacenes
- Disco compartidoArchivos originales
- MongoDBTrazabilidad de cada documento
- Oracle por empresaTablas que lee el ERP
Consumo
- ERP financieroCuentas por pagar de dos empresas
Operación
- ConciliadorCruza portal, disco, MongoDB y Oracle
- Servidor MCP de diagnósticoCausa raíz y reproceso con simulación
Cómo se mueven los datos
- Portal del operador de facturaciónhaciaDescargaTres veces al día
- DescargahaciaDisco compartidoPDF y XML
- Disco compartidohaciaConversiónArchivos del periodo
- ConversiónhaciaMongoDBUn documento por factura
- MongoDBhaciaCargaPendientes por cargar
- CargahaciaOracle por empresaFacturas por empresa
- Oracle por empresahaciaERP financieroRecepción en el ERP
- ConciliadorhaciaOracle por empresaVerifica factura por factura
- Servidor MCP de diagnósticohaciaDescargaLee corridas y logs por la API del orquestador
Resultados
- El proceso que reportaba éxito habiendo perdido facturas hoy falla en rojo y avisa por correo.
- Un incidente de cambio de mes se cuantificó el mismo día, con 63 facturas pendientes exactas, respuesta al área usuaria antes del mediodía y corrección de fondo probada en vivo.
- Se verificaron una a una cerca de 1.050 facturas de un mes contra la base de destino.
- Cada log de producción se asocia a su commit, porque el despliegue es por etiqueta y cada corrida imprime la versión.
Qué haría distinto
- Construiría el conciliador entre almacenes antes que cualquier corrección; es la herramienta que convierte una sospecha en un número.
- Negociaría desde el inicio un entorno de pruebas del portal de origen, porque buena parte del riesgo vino de no poder ensayar descargas sin tocar el proceso real.
Tecnologías
- Python
- Apache Airflow
- Selenium
- Oracle
- MongoDB
- Docker
- pytest
- GitHub Actions
- Model Context Protocol
- Legacy code rescue
- Incident forensics