Montando uma Equipe de Coleta de Dados: Funções, Proporções e O Que Quebra Primeiro

Na maioria dos planos de coleta de dados da web o orçamento contempla os scrapers e esquece as pessoas. A primeira versão leva algumas semanas para ser escrita, então uma equipe de uma pessoa parece suficiente. Depois os sites mudam, o volume cresce, um cliente encontra um número errado, e descobre-se que o trabalho nunca foi escrever scrapers. Era mantê-los corretos.

Não encontramos um benchmark publicado e confiável sobre quantas pessoas isso exige, e qualquer proporção única seria enganosa de qualquer forma. Então este guia apresenta as funções, um pequeno modelo que você pode rodar com seus próprios números, e o que costuma quebrar primeiro em cada tamanho.

O que determina o número de pessoas

O volume de dados importa menos do que você imaginaria. Buscar dez vezes mais páginas das mesmas fontes é principalmente uma questão de orçamento e infraestrutura. O número de pessoas depende de quatro fatores:

• O número de fontes, já que cada uma pode quebrar por conta própria.
• Com que frequência elas quebram, o que depende de quanto um site muda e de quão difícil é acessá-lo.
• Quanto erro você pode se permitir. Um conjunto de dados de pesquisa semanal pode esperar. Um feed de preços sobre o qual os clientes agem não pode.
• Quantas fontes novas você adiciona, porque a integração de novas fontes compete com a manutenção pelas mesmas pessoas.

As funções

Isso são funções, não cargos. Em uma equipe pequena, uma pessoa acumula várias, o que é aceitável desde que cada uma tenha um nome associado.

Função	Responsável por	Geralmente ausente até
Engenheiro de coleta	Scrapers, extração, correção de falhas	Nunca ausente
Engenheiro de plataforma	Agendamento, filas, proxies, navegadores, armazenamento, custo	Várias pessoas estão repetindo a mesma infraestrutura
Responsável pela qualidade dos dados	Verificações, desvios, o que significa “correto”	Um cliente encontra o erro primeiro
Responsável pelo produto ou pelos dados	O que coletar, prioridades, decisões sobre fontes	Tudo é urgente
Contato de jurídico e conformidade	Escopo, termos, dados pessoais, aprovações	Uma nova fonte levanta uma questão que ninguém consegue responder

O último raramente é um cargo em tempo integral, mas deve ser uma pessoa nomeada. Uma política de coleta de dados curta e escrita poupa essa pessoa de responder repetidamente às mesmas perguntas.

Um modelo de planejamento

O script transforma trabalho recorrente em horas, e horas em pessoas. Ele não exige nada além de Python 3.9 ou posterior. Cada número é uma suposição a ser substituída pelos seus próprios: conte quantas correções você fez no último trimestre, e quanto tempo levaram.

"""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}")

Saída:

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

Os cenários usam entradas ilustrativas em vez de medições reais, e os argumentos no script mostram cada um deles. Fontes estáveis quebram uma vez a cada quatro meses e levam quatro horas para serem corrigidas; as difíceis quebram uma vez e meia por mês e levam seis.

Duas coisas se destacam. Ir de 50 para 200 fontes mistas multiplica o número de fontes por 4, mas o tamanho da equipe por cerca de 2,4, porque o trabalho de plataforma é compartilhado. Em seguida, as mesmas 200 fontes passam de 7 pessoas para 22 puramente porque são mais difíceis de manter funcionando. A taxa de falhas afeta o número de pessoas mais do que o número de fontes, então esse é o número a medir primeiro.

O modelo reserva um quarto do tempo de cada pessoa para trabalho de projeto. Isso é enxuto. O livro SRE do Google estabelece uma meta de pelo menos 50% do tempo em engenharia em vez de trabalho operacional, e nessa proporção essas equipes seriam 1,5 vezes maiores. Se ninguém tem tempo para corrigir causas raiz, as mesmas falhas continuam voltando.

O que quebra primeiro

Uma a duas pessoas. O fator de ônibus. Tudo vive em uma única cabeça, e férias viram incidentes. Documente como cada fonte funciona e como corrigi-la. Compre sua infraestrutura em vez de operá-la.

Três a cinco pessoas. Qualidade. A equipe está ocupada corrigindo falhas visíveis enquanto falhas silenciosas se acumulam, como um seletor que retorna o campo errado com um 200. Nomeie um responsável pela qualidade e monitore o pipeline tanto no conteúdo quanto nos códigos de status.

Seis a dez pessoas. Duplicação e prioridades. Cada engenheiro construiu suas próprias retentativas e tratamento de proxy, e a fonte de cada parte interessada é urgente. É nesse ponto que um responsável pela plataforma compensa, junto com um responsável pelo produto que saiba dizer não.

Mais de dez pessoas. Coordenação e plantão. O livro SRE do Google calcula que uma equipe de site único com duas pessoas de plantão e turnos de uma semana precisa de pelo menos oito engenheiros. Poucas equipes de dados deveriam construir isso. Projete pipelines para se recuperar sozinhos e se atualizar depois, e mantenha cobertura ininterrupta apenas para o que os clientes realmente dependem.

Reduzindo o número de pessoas necessárias

• Compre as camadas commodity. Nosso guia de construir versus comprar cobre o que realmente exige operar sua própria infraestrutura.
• Corte fontes. Aposentar as dez fontes menos valiosas costuma ser a contratação mais barata que você pode fazer.
• Prefira rotas estáveis. APIs oficiais, feeds e dados estruturados quebram menos do que seletores HTML.
• Corrija classes de falha. Retentativas compartilhadas, verificações compartilhadas e parsers compartilhados transformam muitos pequenos incêndios em um só.

Conclusão

Não dimensione a equipe a partir de uma proporção. Dimensione a partir do número de fontes, da taxa de falhas e de quanto erro você pode se permitir, e meça esses números antes da próxima discussão de contratação. Nomeie um responsável pela qualidade desde cedo, compre o que não é seu diferencial, e espere que o gargalo mude conforme você cresce.

Fontes e referências

• Google, Site Reliability Engineering, Being On-Call: sre.google
• Google, Site Reliability Engineering, Eliminating Toil: sre.google