Fiabilidad en rastreo web

Contexto

Un producto utilizaba un navegador automatizado para visitar páginas web y analizar su comportamiento. Las ejecuciones recorrían sitios ajenos, con tiempos de carga y estructuras que podían cambiar sin aviso. Algunos trabajos quedaban activos sin avanzar; otros fallaban sin dejar información suficiente para explicar al usuario lo sucedido.

El sistema ya estaba en producción y tenía poca cobertura de pruebas. Había que resolver incidencias mientras seguían llegando solicitudes, con margen limitado para reorganizar la arquitectura. Empecé por entender cómo se iniciaba cada trabajo, cómo comunicaba su progreso y dónde podía perderse la información sobre un fallo.

Mi papel y liderazgo técnico

Asumí la responsabilidad técnica del sistema tras el traspaso del desarrollo anterior. Me convertí en el referente para investigar incidencias y decidir las correcciones de mantenimiento. Coordinaba con producto los cambios que afectaban al comportamiento esperado y trabajaba con atención al cliente para entender el problema que veía cada usuario.

Esa responsabilidad incluía seguir un fallo desde el síntoma hasta su causa, elegir el alcance de la corrección e implementarla. Introduje mejoras en el control de las ejecuciones y pruebas sobre los comportamientos que daban problemas. También propuse cambios de arquitectura para reducir limitaciones que las correcciones locales no resolvían.

Las propuestas más amplias necesitaban prioridad y recursos compartidos. No llegaron a convertirse en un plan de ejecución durante mi etapa, así que concentré el trabajo en mejorar la fiabilidad del producto existente y mantener la entrega de funcionalidades.

Desafíos y trade-offs

Un rastreador necesita decidir cuándo una página está lista para analizarse. Hay contenido que aparece después de la carga inicial y componentes incrustados dentro de otros documentos. Esperar demasiado prolonga la ejecución; continuar antes de tiempo puede dejar fuera información relevante. Ajusté la estrategia de navegación y amplié el tratamiento de esos casos, conservando el carácter heurístico del sistema.

Introduje límites de tiempo en operaciones que podían esperar indefinidamente. Elegirlos implicaba admitir que algunas páginas lentas podían terminar con un error, pero también evitar que un trabajo consumiera recursos sin avanzar. Reforcé la propagación de esos fallos para que el producto mostrara un resultado comprensible.

Una reescritura completa habría retrasado correcciones que los usuarios ya necesitaban. Los cambios incrementales permitían atender esos problemas con un alcance menor, aunque mantenían dependencias y restricciones de la arquitectura heredada.

Cómo seguíamos cada ejecución

El sistema recibía una solicitud, la enviaba a procesamiento y ejecutaba el análisis en segundo plano. El proceso encargado del navegador comunicaba avances y resultados a la aplicación. Había varios puntos en los que una operación podía fallar antes de completar ese recorrido.

Revisé la validación de entrada y el manejo de errores entre esas etapas. Una excepción local debía reflejarse en el estado general del trabajo. De otro modo, una parte del sistema podía haberse detenido mientras el producto seguía mostrando la ejecución como activa.

Para investigar, consultaba el estado guardado y buscaba el último paso conocido en los registros de ejecución. Eso ayudaba a distinguir un problema al iniciar el trabajo de uno ocurrido durante la navegación o al comunicar el resultado. Permitía centrar la investigación antes de modificar código.

Un trabajo que nunca terminaba

Una incidencia mostraba un trabajo activo que había dejado de avanzar. Seguí su estado y los registros hasta encontrar una dirección de entrada inválida. El error se producía al preparar la ejecución, antes de que comenzara el análisis, y no quedaba reflejado correctamente en el estado que veía el usuario.

Añadí validación temprana al crear la solicitud y una comprobación defensiva antes de ejecutarla. Reforcé también el manejo de errores para que un fallo en esa fase no dejara una ejecución aparentemente activa. Revisé qué errores admitían otro intento y cuáles requerían terminar el trabajo con un fallo identificado.

El reintento tenía sentido para una interrupción temporal. Una entrada inválida necesitaba corrección antes de volver a ejecutarse. Separar esas situaciones ayudó a evitar repeticiones inútiles y a conservar un resultado que pudiera investigarse.

Pruebas y evolución de la arquitectura

Incorporé pruebas unitarias y de extremo a extremo de forma progresiva. Las primeras permitían comprobar comportamientos concretos; las segundas ejecutaban rastreos y revisaban sus resultados. Los casos que habían causado incidencias servían para comprobar las correcciones y reducir el riesgo de volver a introducir el mismo fallo.

Las pruebas sobre páginas reales aportaban variedad, aunque esas páginas podían cambiar entre ejecuciones. Ajustar la navegación y tratar mejor el contenido dinámico aumentó la consistencia en los casos investigados. El sistema seguía dependiendo del comportamiento de sitios externos.

También detecté que el seguimiento de ejecuciones y la recepción de resultados podían cargar demasiado la aplicación. Propuse separar mejor ese tráfico del uso interactivo y reducir el coste de manejar resultados grandes. Esa evolución quedó pendiente; las mejoras entregadas se concentraron en el control de ejecución, el tratamiento de errores y las pruebas.

Resultados

Se redujeron los trabajos bloqueados y los fallos silenciosos. La información de estado permitió investigar con más contexto y dar respuestas más claras a las incidencias. Las ejecuciones fueron más consistentes en los comportamientos que habíamos corregido.

La fiabilidad mejoró dentro del desarrollo habitual del producto. Mi aportación combinó responsabilidad técnica sobre un sistema heredado, coordinación con producto y atención al cliente, y cambios concretos en su funcionamiento. No había una base histórica suficiente para cuantificar la reducción de fallos, por lo que el resultado se expresa de forma cualitativa.

Si algo falla, queda contexto para investigar y actuar.

Qué aprendí y qué cambiaría

Definiría antes cómo medir la fiabilidad: qué proporción de trabajos llega a un estado final, cuánto tarda y en qué fase falla. Eso habría permitido relacionar las correcciones con su efecto en el uso del producto y acordar prioridades con más información.

Añadiría un conjunto de páginas controladas para comprobar comportamientos repetibles, junto con las pruebas sobre sitios reales. Así sería más fácil distinguir una regresión propia de un cambio en la página analizada.

Las propuestas de arquitectura las dividiría en entregas pequeñas, con coste, responsable y una mejora verificable. Conseguí resolver incidencias y reforzar el sistema, pero algunas limitaciones estructurales quedaron sin un plan para abordarlas.