Die meisten Pläne für das Sammeln von Webdaten kalkulieren Scraper ein und vergessen die Menschen. Die erste Version zu schreiben dauert ein paar Wochen, also sieht ein Team von einer Person gut aus. Dann ändern sich Websites, das Volumen wächst, ein Kunde findet eine falsche Zahl, und es stellt sich heraus, dass die Aufgabe nie darin bestand, Scraper zu schreiben. Sie bestand darin, sie wahrheitsgetreu zu halten.
Wir konnten keine verlässliche veröffentlichte Benchmark dafür finden, wie viele Personen das erfordert, und jede einzelne Quote würde Sie ohnehin in die Irre führen. Daher bietet dieser Leitfaden die Rollen, ein kleines Modell, das Sie mit Ihren eigenen Zahlen ausführen können, und das, was bei jeder Größe tendenziell zuerst versagt.
Was die Personalstärke bestimmt
Das Datenvolumen spielt eine geringere Rolle, als man denken würde. Zehnmal mehr Seiten von denselben Quellen abzurufen ist größtenteils eine Frage von Budget und Infrastruktur. Die Personalstärke richtet sich nach vier Dingen:
- Die Anzahl der Quellen, da jede für sich allein ausfallen kann.
- Wie oft sie ausfallen, was davon abhängt, wie oft sich eine Website ändert und wie schwer der Zugriff ist.
- Wie falsch Sie es sich leisten können zu sein. Ein wöchentlicher Forschungsdatensatz kann warten. Ein Preisfeed, auf den Kunden reagieren, kann das nicht.
- Wie viele neue Quellen Sie hinzufügen, denn das Onboarding konkurriert mit der Wartung um dieselben Leute.
Die Rollen
Dies sind Rollen, keine Jobtitel. In einem kleinen Team hält eine Person mehrere davon, was in Ordnung ist, solange jede einen Namen danebenstehen hat.
| Rolle | Verantwortet | Fehlt oft bis |
|---|---|---|
| Collection Engineer | Scraper, Extraktion, Behebung von Ausfällen | Fehlt nie |
| Platform Engineer | Scheduling, Queues, Proxys, Browser, Speicher, Kosten | Mehrere Personen wiederholen dieselbe Infrastrukturarbeit |
| Data Quality Owner | Prüfungen, Drift, was „korrekt“ bedeutet | Ein Kunde findet den Fehler zuerst |
| Product oder Data Owner | Was gesammelt wird, Prioritäten, Quellentscheidungen | Alles ist dringend |
| Legal- und Compliance-Kontakt | Umfang, Bedingungen, personenbezogene Daten, Freigaben | Eine neue Quelle wirft eine Frage auf, die niemand beantworten kann |
Die letzte Rolle ist selten Vollzeit, sollte aber eine namentlich benannte Person sein. Eine kurze schriftliche Datenerfassungsrichtlinie erspart dieser Person, dieselben Fragen immer wieder zu beantworten.
Ein Planungsmodell
Das Skript verwandelt wiederkehrende Arbeit in Stunden und Stunden in Personen. Es benötigt nichts weiter als Python 3.9 oder neuer. Jede Zahl ist eine Annahme, die Sie durch Ihre eigenen ersetzen sollten: Zählen Sie, wie viele Korrekturen Sie im letzten Quartal durchgeführt haben und wie lange sie gedauert haben.
"""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}")Ausgabe:
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 22Die Szenarien verwenden veranschaulichende Eingaben statt Messwerte, und die Argumente im Skript zeigen jedes einzelne. Stabile Quellen fallen einmal alle vier Monate aus und brauchen vier Stunden zur Behebung; schwierige fallen eineinhalb Mal im Monat aus und brauchen sechs.
Zwei Dinge fallen auf. Der Übergang von 50 auf 200 gemischte Quellen vervierfacht die Quellenanzahl, vergrößert die Teamgröße aber nur um etwa das 2,4-fache, weil sich die Plattformarbeit verteilt. Dann wachsen dieselben 200 Quellen von 7 auf 22 Personen, rein weil sie schwerer am Laufen zu halten sind. Die Ausfallrate verändert die Personalstärke stärker als die Quellenanzahl, deshalb ist das die Zahl, die man zuerst messen sollte.
Das Modell behält ein Viertel der Zeit jeder Person für Projektarbeit. Das ist knapp bemessen. Googles SRE-Buch setzt ein Ziel von mindestens 50% der Zeit für Engineering statt für operative Arbeit, und bei dieser Rate wären diese Teams 1,5-mal größer. Wenn niemand Zeit hat, Grundursachen zu beheben, kehren dieselben Ausfälle immer wieder zurück.
Was zuerst versagt
Ein bis zwei Personen. Der Bus-Faktor. Alles lebt in einem Kopf, und Urlaube werden zu Vorfällen. Schreiben Sie auf, wie jede Quelle funktioniert und wie man sie repariert. Kaufen Sie Ihre Infrastruktur, statt sie selbst zu betreiben.
Drei bis fünf Personen. Qualität. Das Team ist damit beschäftigt, sichtbare Ausfälle zu beheben, während sich stille Fehler aufbauen, wie ein Selektor, der mit einem 200er-Status das falsche Feld zurückgibt. Benennen Sie einen Quality Owner und überwachen Sie die Pipeline sowohl inhaltlich als auch bei Statuscodes.
Sechs bis zehn Personen. Duplikation und Prioritäten. Jeder Ingenieur hat seine eigenen Retries und seine eigene Proxy-Handhabung gebaut, und die Quelle jedes Stakeholders ist dringend. Jetzt zahlt sich ein Platform Owner aus, zusammen mit einem Product Owner, der Nein sagen kann.
Mehr als zehn. Koordination und Bereitschaftsdienst. Googles SRE-Buch rechnet vor, dass ein Single-Site-Team mit zwei Personen im Bereitschaftsdienst und wochenlangen Schichten mindestens acht Ingenieure benötigt. Nur wenige Datenteams sollten das aufbauen. Gestalten Sie Pipelines so, dass sie sich selbst erholen und danach aufholen können, und halten Sie rund um die Uhr Abdeckung für das vor, worauf Kunden wirklich angewiesen sind.
Die benötigte Anzahl reduzieren
- Kaufen Sie die Commodity-Schichten. Unser Leitfaden Build versus Buy behandelt, was der Betrieb eigener Infrastruktur wirklich bedeutet.
- Reduzieren Sie Quellen. Die zehn am wenigsten wertvollen Quellen abzuschalten ist oft die günstigste Einstellung, die Sie vornehmen können.
- Bevorzugen Sie stabile Wege. Offizielle APIs, Feeds und strukturierte Daten fallen seltener aus als HTML-Selektoren.
- Beheben Sie Fehlerklassen. Gemeinsame Retries, gemeinsame Prüfungen und gemeinsame Parser machen aus vielen kleinen Bränden einen einzigen.
Fazit
Besetzen Sie nicht nach einer Quote. Besetzen Sie nach Ihrer Quellenanzahl, Ihrer Ausfallrate und danach, wie falsch Sie es sich leisten können zu sein, und messen Sie diese Zahlen vor der nächsten Einstellungsdiskussion. Benennen Sie früh einen Owner für Qualität, kaufen Sie, was nicht Ihr Vorteil ist, und rechnen Sie damit, dass sich der Engpass mit dem Wachstum verschiebt.
Quellen und Referenzen
- Google, Site Reliability Engineering, Being On-Call: sre.google
- Google, Site Reliability Engineering, Eliminating Toil: sre.google