La plupart des plans de collecte de données web budgétisent les scrapers et oublient les personnes. La première version prend quelques semaines à écrire, donc une équipe d’une seule personne paraît suffisante. Puis les sites changent, le volume augmente, un client trouve un chiffre erroné, et il s’avère que le travail n’a jamais été d’écrire des scrapers. C’était de les maintenir fidèles à la réalité.
Nous n’avons trouvé aucun référentiel publié crédible sur le nombre de personnes que cela nécessite, et de toute façon, un ratio unique vous induirait en erreur. Ce guide propose donc les rôles, un petit modèle que vous pouvez exécuter avec vos propres chiffres, et ce qui a tendance à casser en premier à chaque taille.
Ce qui détermine les effectifs
Le volume de données compte moins qu’on ne le pense. Récupérer dix fois plus de pages des mêmes sources est surtout une question de budget et d’infrastructure. Les effectifs dépendent de quatre choses :
- Le nombre de sources, puisque chacune peut casser indépendamment.
- La fréquence des pannes, qui dépend de la fréquence des changements d’un site et de la difficulté d’y accéder.
- La marge d’erreur acceptable. Un jeu de données de recherche hebdomadaire peut attendre. Un flux de prix sur lequel les clients agissent ne le peut pas.
- Le nombre de nouvelles sources ajoutées, car l’intégration entre en concurrence avec la maintenance pour les mêmes personnes.
Les rôles
Ce sont des rôles, pas des titres de poste. Dans une petite équipe, une personne en cumule plusieurs, ce qui est acceptable tant que chacun a un nom en face.
| Rôle | Responsable de | Souvent absent jusqu’à ce que |
|---|---|---|
| Ingénieur collecte | Scrapers, extraction, correction des pannes | Jamais absent |
| Ingénieur plateforme | Planification, files d’attente, proxies, navigateurs, stockage, coût | Plusieurs personnes répètent la même plomberie |
| Responsable qualité des données | Contrôles, dérive, ce que « correct » signifie | Un client trouve l’erreur en premier |
| Responsable produit ou données | Quoi collecter, priorités, décisions de sources | Tout est urgent |
| Contact juridique et conformité | Périmètre, conditions, données personnelles, approbations | Une nouvelle source soulève une question à laquelle personne ne sait répondre |
Le dernier rôle est rarement à temps plein, mais il doit s’agir d’une personne nommée. Une courte politique écrite de collecte de données évite à cette personne de répondre sans cesse aux mêmes questions.
Un modèle de planification
Le script transforme le travail récurrent en heures, et les heures en personnes. Il ne nécessite rien d’autre que Python 3.9 ou une version ultérieure. Chaque chiffre est une hypothèse à remplacer par vos propres données : comptez le nombre de corrections effectuées le trimestre dernier, et le temps que cela a pris.
"""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}")Résultat :
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 22Les scénarios utilisent des données illustratives plutôt que des mesures, et les arguments du script montrent chacun d’eux. Les sources stables cassent une fois tous les quatre mois et prennent quatre heures à réparer ; les sources difficiles cassent une fois et demie par mois et prennent six heures.
Deux éléments se démarquent. Passer de 50 à 200 sources mixtes multiplie le nombre de sources par 4, mais la taille de l’équipe par environ 2,4 seulement, car le travail de plateforme est partagé. Ensuite, ces mêmes 200 sources passent de 7 à 22 personnes uniquement parce qu’elles sont plus difficiles à maintenir en fonctionnement. Le taux de pannes fait davantage varier les effectifs que le nombre de sources, c’est donc le chiffre à mesurer en premier.
Le modèle réserve un quart du temps de chaque personne au travail de projet. C’est serré. Le livre SRE de Google fixe un objectif d’au moins 50 % du temps consacré à l’ingénierie plutôt qu’au travail opérationnel, et à ce rythme, ces équipes seraient 1,5 fois plus grandes. Si personne n’a le temps de corriger les causes profondes, les mêmes pannes continuent de revenir.
Ce qui casse en premier
Une à deux personnes. Le facteur bus. Tout réside dans une seule tête, et les vacances deviennent des incidents. Consignez par écrit le fonctionnement de chaque source et comment la réparer. Achetez votre infrastructure plutôt que de la faire tourner vous-même.
Trois à cinq personnes. La qualité. L’équipe est occupée à réparer les pannes visibles pendant que des pannes silencieuses s’accumulent, comme un sélecteur qui renvoie le mauvais champ avec un 200. Nommez un responsable qualité et surveillez le pipeline sur le contenu autant que sur les codes de statut.
Six à dix personnes. Duplication et priorités. Chaque ingénieur a construit ses propres retries et sa propre gestion de proxies, et la source de chaque partie prenante est urgente. C’est le moment où un responsable plateforme se rentabilise, ainsi qu’un responsable produit capable de dire non.
Plus de dix personnes. Coordination et astreinte. Le livre SRE de Google calcule qu’une équipe sur un seul site avec deux personnes d’astreinte et des rotations d’une semaine nécessite au moins huit ingénieurs. Peu d’équipes data devraient construire cela. Concevez des pipelines capables de récupérer seuls et de rattraper le retard ensuite, et réservez une couverture permanente pour ce dont les clients dépendent réellement.
Réduire le nombre de personnes nécessaires
- Achetez les couches de base. Notre guide construire ou acheter couvre ce que signifie réellement faire tourner sa propre infrastructure.
- Réduisez les sources. Retirer les dix sources les moins précieuses est souvent l’embauche la moins chère que vous puissiez faire.
- Privilégiez les voies stables. Les API officielles, les flux et les données structurées cassent moins que les sélecteurs HTML.
- Corrigez des classes de pannes. Des retries partagés, des contrôles partagés et des parseurs partagés transforment de nombreux petits incendies en un seul.
L’essentiel à retenir
Ne dimensionnez pas vos effectifs à partir d’un ratio. Dimensionnez-les à partir de votre nombre de sources, de votre taux de pannes et de la marge d’erreur acceptable, et mesurez ces chiffres avant la prochaine discussion de recrutement. Nommez tôt un responsable qualité, achetez ce qui ne constitue pas votre avantage, et attendez-vous à ce que le goulot d’étranglement se déplace à mesure que vous grandissez.
Sources et références
- Google, Site Reliability Engineering, Being On-Call : sre.google
- Google, Site Reliability Engineering, Eliminating Toil : sre.google