Si un scraper se rompe cada semana, primero separo cambios de fuente, fallos de extracción y fallos de entrega. Un rediseño puede exigir corregir el parser; un conjunto vacío puede reflejar un cambio real en el origen. Un HTTP 200 o una tarea completada no bastan para distinguirlos.
Antes de contratar mantenimiento, hay que acordar fuentes, campos y ventanas de entrega. El resultado útil es un acuerdo operativo: alguien puede detectar un problema, contener sus efectos, reparar el componente afectado y demostrar que los datos vuelven a servir. Ningún mantenimiento puede garantizar que una web externa siga disponible o no cambie.
Diagnosticar el fallo antes de sustituir el scraper
Empiezo por una ejecución fallida y otra correcta comparable. Registro URL, momento de captura, versión del parser, campos esperados, salida real y estado de entrega. La evidencia se limita a lo necesario para diagnosticar, con acceso y conservación acordados.
- Navegación: ¿la tarea llegó a la página y al punto de paginación esperados?
- Extracción: ¿existen los campos obligatorios o el selector encontró otro elemento?
- Significado: ¿cambiaron la moneda, la unidad, el formato de fecha o la definición de un campo?
- Entrega: ¿la salida válida fue rechazada, llegó tarde o se escribió dos veces tras un reintento?
Si una API oficial, una exportación o un proveedor de datos cubren la necesidad, conviene valorarlos primero. Si la fuente deja de ser accesible o cambia sus condiciones de acceso, se pausa y se revisa su uso. Acumular reintentos no resuelve esa decisión.
Separar la reparación del parser de la captura y la entrega
La navegación, extracción, normalización y escritura necesitan límites claros. Prefiero etiquetas estables y estructuras repetidas a cadenas largas de clases CSS generadas, y versiono las reglas de selección. La guía de arquitectura de Puppeteer desarrolla esa separación técnica.
captura -> extracción -> validación -> preparación -> entrega
|
+-> cuarentena y revisiónGuarda ejemplos permitidos y sanitizados con su salida esperada para comprobar una corrección sin escribir en producción. En Scrapy, los contratos de spiders permiten comprobar cantidades de salida y presencia de campos en callbacks. Eso no demuestra que un precio sea correcto ni que la escritura posterior haya funcionado.
Un timeout temporal puede justificar un reintento limitado. Un fallo reproducible del parser necesita investigación. La guía de colas, workers y reintentos cubre la ejecución; el mantenimiento define quién actúa cuando una fuente deja de cumplir el contrato de datos.
Qué debe cubrir un acuerdo de mantenimiento de scrapers
Trabaja con un inventario de fuentes identificadas y separa reparar el comportamiento acordado de pedir uno nuevo. Esta tabla propone criterios de alcance; no es un paquete de soporte ni una promesa de tiempo de respuesta.
| Cambio o incidencia | Qué acordar antes | Evidencia para cerrar |
|---|---|---|
| Cambio de estructura en una fuente existente | Plantillas y campos cubiertos; responsable del parser | Las muestras anteriores y nuevas producen la salida acordada |
| Campos vacíos o paginación incompleta | Qué campos bloquean la entrega y quién revisa excepciones | Cobertura esperada contrastada con muestras de la fuente |
| Fuente caída o condiciones de acceso nuevas | Quién pausa, avisa a operaciones y valora alternativas | Decisión documentada de reanudar, sustituir o retirar la fuente |
| Entrega fuera de plazo | Cómo señalar datos antiguos y si hay que recuperar el periodo | Registros recuperados y conciliados, o hueco aceptado expresamente |
| Nueva fuente, campo o destino | Estimación y criterios de aceptación separados | Comportamiento nuevo aprobado antes del mantenimiento habitual |
Nombra también al responsable de negocio, al técnico y a su contacto de respaldo. Define horario de soporte, vía de escalado y diferencia entre atender una incidencia y restaurar la entrega. Se acuerdan según la dependencia real; no hay que dar por hecho soporte continuo.
Vigilar datos utilizables, no solo tareas completadas
Revisa campos obligatorios completos, cobertura de fuentes, antigüedad del último dato aceptado, registros rechazados y duplicados inesperados. Compara ejecuciones equivalentes: misma fuente, filtros y ventana de captura. Una caída de volumen es una señal que investigar, no una prueba de rotura.
Ejemplo hipotético: un catálogo pasa de mostrar precio por unidad a precio por paquete. El selector sigue devolviendo un número y las tareas terminan bien. Contrastar unidades y ejemplos de origen revela el cambio. Se pausa la salida afectada, se identifica qué registros son dudosos y se acuerda si el histórico puede corregirse.
El caso de Adslyfy muestra ejecuciones, estados y capturas que un operador puede revisar. Ilustra visibilidad operativa; no acredita tiempos de reparación de scrapers ni calidad de datos garantizada.
Cómo aceptar la reparación de un scraper
Acordaría estas comprobaciones antes de cerrar una incidencia. Son criterios de aceptación propuestos, no resultados de una reparación realizada para un cliente.
- Reproducir el fallo con una muestra conservada e identificar fuente, versión del parser y periodo afectado.
- Probar la corrección con la página modificada y ejemplos antes válidos, incluidos campos ausentes y límites de paginación.
- Contrastar valores obligatorios y su significado: unidades, moneda, fechas e identidad del registro.
- Realizar una comprobación limitada en la fuente si el acceso sigue permitido. Mantener en cuarentena las salidas dudosas.
- Conciliar entrega y recuperación. Una página actual no permite reconstruir un valor histórico que nunca se capturó.
- Registrar versión desplegada, evidencia, huecos pendientes, responsable y procedimiento de reversión o pausa.
Para exportaciones, acuerda esquema y vigencia con la guía de entrega en CSV, API o dashboard. Si el destino es un CRM, aplica sus reglas de autoridad y reintentos antes de repetir escrituras. Reparar la extracción no autoriza a sobrescribir cambios de negocio.
De qué depende el coste de mantener un scraper
El número de fuentes no basta para estimar. Influyen las plantillas distintas, frecuencia de cambios, ejecución de navegadores, campos críticos, plazos de entrega, conservación de evidencia y esfuerzo de recuperación. Heredar código sin documentación exige además un diagnóstico antes de fijar un alcance recurrente.
Separa estabilización inicial, monitorización y reparaciones habituales, infraestructura o proveedores externos, y desarrollo nuevo. Compara soporte recurrente con intervenciones aprobadas por separado según la dependencia de la entrega y la capacidad interna para atender incidencias. Ninguna modalidad elimina el riesgo de la fuente.
La guía para comparar presupuestos de software ayuda a concretar inclusiones, exclusiones y responsables. Pregunta qué cambios se cubren, cuándo hace falta otra estimación y quién asume la recuperación. Sin ese alcance no hay un precio fijo defendible.
Empezar por una fuente inestable y un traspaso claro
Mi trabajo de plataformas internas e integraciones puede empezar revisando un flujo de datos existente. Primero identificaría dónde falla, definiría el contrato de la fuente y propondría una reparación o un alcance operativo menor. Reescribir solo tiene sentido si la evidencia lo justifica.
Si tu equipo depende de un scraper que no puede mantener con confianza, envíame las fuentes, campos necesarios, frecuencia de entrega y una ejecución fallida sanitizada. Tendremos una base concreta para hablar de responsabilidades, aceptación y el siguiente trabajo.