Casi todos los planes para la recopilación de datos web presupuestan para scrapers y se olvidan de las personas. La primera versión tarda unas semanas en escribirse, así que un equipo de una persona parece suficiente. Luego los sitios cambian, el volumen crece, un cliente encuentra un dato incorrecto, y resulta que el trabajo nunca fue escribir scrapers. Era mantenerlos fieles a la realidad.
No encontramos un benchmark publicado y creíble sobre cuántas personas hacen falta para esto, y cualquier ratio único te engañaría de todos modos. Así que esta guía ofrece los roles, un pequeño modelo que puedes ejecutar con tus propios números, y qué suele romperse primero en cada tamaño.
Qué determina la plantilla
El volumen de datos importa menos de lo que cabría pensar. Obtener diez veces más páginas de las mismas fuentes es sobre todo una cuestión de presupuesto e infraestructura. La plantilla depende de cuatro cosas:
- El número de fuentes, ya que cada una puede fallar por su cuenta.
- Con qué frecuencia fallan, lo que depende de cuánto cambia un sitio y de lo difícil que es acceder a él.
- Cuánto margen de error te puedes permitir. Un conjunto de datos de investigación semanal puede esperar. Un feed de precios sobre el que actúan los clientes no.
- Cuántas fuentes nuevas añades, porque la incorporación de fuentes compite con el mantenimiento por las mismas personas.
Los roles
Estos son roles, no puestos de trabajo. En un equipo pequeño una persona asume varios, lo cual está bien siempre que cada uno tenga un nombre asignado.
| Rol | Responsable de | A menudo falta hasta que |
|---|---|---|
| Ingeniero de recolección | Scrapers, extracción, arreglar roturas | Nunca falta |
| Ingeniero de plataforma | Programación, colas, proxies, navegadores, almacenamiento, coste | Varias personas repiten la misma fontanería |
| Responsable de calidad de datos | Comprobaciones, deriva, qué significa “correcto” | Un cliente encuentra el error primero |
| Responsable de producto o datos | Qué recopilar, prioridades, decisiones sobre fuentes | Todo es urgente |
| Contacto legal y de cumplimiento | Alcance, términos, datos personales, aprobaciones | Una fuente nueva plantea una pregunta que nadie sabe responder |
El último rol rara vez es a tiempo completo, pero debería ser una persona con nombre. Una breve política escrita de recopilación de datos evita que esa persona tenga que responder las mismas preguntas una y otra vez.
Un modelo de planificación
El script convierte el trabajo recurrente en horas, y las horas en personas. No necesita nada más que Python 3.9 o posterior. Cada número es una suposición que debes sustituir por la tuya propia: cuenta cuántas correcciones hiciste el trimestre pasado, y cuánto tiempo te llevaron.
"""A planning model for how many engineers a data collection operation needs.
Every default is an assumption to replace with your own numbers.
"""
from __future__ import annotations
import math
HOURS_PER_FTE = 30 # focused engineering hours per person per week
def team_size(sources, breaks_per_source_per_month, hours_per_fix, new_sources_per_month,
hours_per_new_source, weekly_platform_hours=20, weekly_support_hours=8):
"""Recurring hours become people; reserve a quarter of the time for project work."""
fixes = sources * breaks_per_source_per_month * hours_per_fix / 4.33
onboarding = new_sources_per_month * hours_per_new_source / 4.33
weekly = fixes + onboarding + weekly_platform_hours + weekly_support_hours
fte = weekly / (HOURS_PER_FTE * 0.75)
return {"fixes": round(fixes), "onboarding": round(onboarding),
"platform": weekly_platform_hours, "support": weekly_support_hours,
"weekly_hours": round(weekly), "fte": round(fte, 1), "people": math.ceil(fte)}
if __name__ == "__main__":
scenarios = {
"10 sources, stable": (10, 0.25, 4, 1, 16),
"50 sources, mixed": (50, 0.5, 4, 3, 16),
"200 sources, mixed": (200, 0.5, 4, 8, 16),
"200 sources, hard": (200, 1.5, 6, 8, 24),
}
print(f"{'scenario':22}{'fixes':>6}{'new':>5}{'platform':>9}{'support':>8}{'hrs/wk':>7}{'FTE':>6}{'people':>7}")
for name, args in scenarios.items():
r = team_size(*args)
print(f"{name:22}{r['fixes']:>6}{r['onboarding']:>5}{r['platform']:>9}{r['support']:>8}"
f"{r['weekly_hours']:>7}{r['fte']:>6}{r['people']:>7}")Salida:
scenario fixes new platform support hrs/wk FTE people
10 sources, stable 2 4 20 8 34 1.5 2
50 sources, mixed 23 11 20 8 62 2.8 3
200 sources, mixed 92 30 20 8 150 6.7 7
200 sources, hard 416 44 20 8 488 21.7 22Los escenarios usan valores ilustrativos en lugar de mediciones, y los argumentos del script muestran cada uno. Las fuentes estables se rompen una vez cada cuatro meses y tardan cuatro horas en arreglarse; las difíciles se rompen una vez y media al mes y tardan seis.
Dos cosas destacan. Pasar de 50 a 200 fuentes mixtas multiplica el número de fuentes por 4, pero el tamaño del equipo solo por unas 2,4 veces, porque el trabajo de plataforma se comparte. Luego, las mismas 200 fuentes pasan de 7 personas a 22 únicamente porque son más difíciles de mantener en funcionamiento. La tasa de roturas mueve la plantilla más que el número de fuentes, así que ese es el número que hay que medir primero.
El modelo reserva una cuarta parte del tiempo de cada persona para trabajo de proyecto. Eso es ajustado. El libro de SRE de Google fija un objetivo de al menos el 50% del tiempo en ingeniería en lugar de trabajo operativo, y a ese ritmo estos equipos serían 1,5 veces más grandes. Si nadie tiene tiempo para arreglar causas raíz, las mismas roturas siguen volviendo.
Qué se rompe primero
Una o dos personas. El factor bus. Todo vive en una sola cabeza, y las vacaciones se convierten en incidentes. Documenta cómo funciona cada fuente y cómo arreglarla. Compra tu infraestructura en lugar de gestionarla tú mismo.
De tres a cinco personas. La calidad. El equipo está ocupado arreglando fallos visibles mientras se acumulan los silenciosos, como un selector que devuelve el campo equivocado con un 200. Nombra a un responsable de calidad y monitoriza el pipeline tanto en el contenido como en los códigos de estado.
De seis a diez personas. Duplicación y prioridades. Cada ingeniero ha construido sus propios reintentos y su propia gestión de proxies, y la fuente de cada interesado es urgente. Es aquí cuando un responsable de plataforma se amortiza, junto con un responsable de producto que pueda decir que no.
Más de diez personas. Coordinación y guardias. El libro de SRE de Google calcula que un equipo de un solo sitio con dos personas de guardia y turnos de una semana necesita al menos ocho ingenieros. Pocos equipos de datos deberían construir eso. Diseña los pipelines para que se recuperen solos y se pongan al día después, y mantén cobertura las 24 horas para aquello de lo que los clientes realmente dependen.
Reducir el número de personas que necesitas
- Compra las capas de commodity. Nuestra guía de construir frente a comprar cubre lo que realmente supone gestionar tu propia infraestructura.
- Reduce fuentes. Retirar las diez fuentes menos valiosas suele ser la contratación más barata que puedes hacer.
- Prefiere rutas estables. Las APIs oficiales, los feeds y los datos estructurados se rompen menos que los selectores HTML.
- Arregla clases de fallos. Los reintentos compartidos, las comprobaciones compartidas y los parsers compartidos convierten muchos pequeños incendios en uno solo.
La conclusión
No dimensiones la plantilla a partir de un ratio. Dimensiónala a partir de tu número de fuentes, tu tasa de roturas y el margen de error que te puedes permitir, y mide esos números antes de la próxima discusión de contratación. Nombra a un responsable de calidad pronto, compra lo que no es tu ventaja competitiva, y espera que el cuello de botella se desplace a medida que creces.
Fuentes y referencias
- Google, Site Reliability Engineering, Being On-Call: sre.google
- Google, Site Reliability Engineering, Eliminating Toil: sre.google