データ収集に関するほとんどの計画は、スクレイパーの予算は組んでも、人のことは忘れている。最初のバージョンは数週間で書けるので、担当者一人でも問題なく見える。そのうちサイトが変わり、ボリュームが増え、顧客が誤った数値を見つける。そうして初めて、本当の仕事はスクレイパーを書くことではなく、それを正しく保ち続けることだったとわかる。
この作業に何人必要かについて、信頼できる公開ベンチマークは見つからなかったし、どんな比率を示しても誤解を招くだけだろう。そこで本ガイドでは、役割、自分の数字で動かせる小さなモデル、そして規模ごとに最初に壊れやすい点を示す。
人員数を左右するもの
データ量は思うほど重要ではない。同じソースから10倍のページを取得することは、主に予算とインフラの問題にすぎない。人員数は次の4つに左右される。
- ソースの数。 それぞれが個別に壊れうるため。
- 壊れる頻度。 サイトがどれだけ頻繁に変更され、アクセスがどれだけ難しいかによる。
- どこまで間違いを許容できるか。 週次のリサーチ用データセットなら待てるが、顧客が判断材料にする価格フィードは待てない。
- 新規追加するソースの数。 オンボーディングは保守と同じ人員を奪い合うため。
役割
これらは役割であり、肩書きではない。小さなチームでは一人が複数を兼ねることもあるが、それぞれに担当者の名前がついている限り問題ない。
| 役割 | 担当すること | 欠けていることに気づくのは |
|---|---|---|
| 収集エンジニア | スクレイパー、抽出、破損の修正 | 決して欠けることはない |
| プラットフォームエンジニア | スケジューリング、キュー、プロキシ、ブラウザ、ストレージ、コスト | 複数人が同じ配管作業を繰り返している時 |
| データ品質オーナー | チェック、ドリフト、「正しい」の定義 | 顧客が先にエラーを見つけた時 |
| プロダクト／データオーナー | 何を収集するか、優先順位、ソースの選定 | すべてが緊急になった時 |
| 法務・コンプライアンス担当 | 範囲、利用規約、個人データ、承認 | 新しいソースが誰も答えられない疑問を生んだ時 |
最後の役割がフルタイムであることは稀だが、名前のある担当者であるべきだ。簡潔な文書化されたデータ収集ポリシーがあれば、同じ質問に何度も答える手間を省ける。
計画モデル
このスクリプトは、繰り返し発生する作業を時間数に、時間数を人数に変換する。必要なのはPython 3.9以降だけだ。すべての数値は仮定であり、自分の数字に置き換えるべきものだ。前四半期に行った修正の件数と、それにかかった時間を数えてみてほしい。
"""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}")出力:
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 22これらのシナリオは実測値ではなく例示的な入力値を使っており、スクリプト中の引数にそれぞれが示されている。安定したソースは4か月に1回壊れ、修正に4時間かかる。難しいソースは月に1.5回壊れ、6時間かかる。
ここで2つのことが目を引く。ソースが50から200の混合型に増えると、ソース数は4倍になるが、チーム規模は約2.4倍にしかならない。これはプラットフォーム作業が共有されるためだ。そして同じ200のソースでも、維持が難しいというだけで、7人から22人へと増える。ソース数よりも、破損率の方が人員数を大きく動かす。だからこそ、まずそこを測るべき数値になる。
このモデルは、各担当者の時間の4分の1をプロジェクト作業のために確保している。これはかなり切り詰めた水準だ。GoogleのSRE本では、運用作業ではなくエンジニアリングに費やす時間の目標を少なくとも50%としており、その割合で計算すると、これらのチームは1.5倍の規模になる。根本原因を修正する時間が誰にもなければ、同じ破損が繰り返し発生し続ける。
最初に壊れるもの
1〜2人。 バスファクターの問題。すべてが一人の頭の中にあり、休暇がそのままインシデントになる。各ソースの仕組みと修正方法を文書化すること。インフラは自前で運用するのではなく、購入すること。
3〜5人。 品質の問題。チームは目に見える障害の修正に追われる一方で、200ステータスで誤ったフィールドを返すセレクタのような、見えない障害が蓄積していく。品質オーナーを任命し、ステータスコードだけでなくコンテンツについてもパイプラインを監視すること。
6〜10人。 重複と優先順位の問題。各エンジニアが独自のリトライやプロキシ処理を構築しており、関係者それぞれのソースがすべて緊急扱いになる。この段階になると、プラットフォームオーナーを置くことが効果を生み、ノーと言えるプロダクトオーナーも必要になる。
10人超。 調整とオンコールの問題。GoogleのSRE本の試算では、オンコール担当2名・1週間交代のシングルサイトチームには最低8人のエンジニアが必要とされる。これほどの体制を組むべきデータチームは少ない。パイプラインは自力で回復し、後で追いつけるように設計し、顧客が本当に依存している部分についてのみ24時間体制のカバーを維持すること。
必要人数を減らす
- コモディティ層は購入する。 自前のインフラ運用に本当に何が必要かは、ビルド対バイのガイドにまとめている。
- ソースを減らす。 価値の低い10のソースをやめることが、しばしば最も安上がりな「採用」になる。
- 安定した経路を優先する。 公式API、フィード、構造化データはHTMLセレクタより壊れにくい。
- 障害のクラス単位で修正する。 共有のリトライ、共有のチェック、共有のパーサーがあれば、多くの小さな火事を一つにまとめられる。
結論
比率で人員を決めてはいけない。ソース数、破損率、どこまで間違いを許容できるかに基づいて人員を決め、次の採用の議論の前にそれらの数値を測定すること。早い段階で品質の担当者を任命し、自社の強みでない部分は購入し、成長とともにボトルネックが移動していくことを見越しておくこと。
出典と参考資料
- Google, Site Reliability Engineering, Being On-Call: sre.google
- Google, Site Reliability Engineering, Eliminating Toil: sre.google