Não foi a IA que inflou sua conta de nuvem. Foram os robôs que leem seu site

No git.kernel.org, 14 núcleos ficam ocupados só renderizando páginas para scrapers, mais que todo acesso legítimo somado. Como separar robô de gente no seu log antes de comprar

Os núcleos estão ocupados o tempo todo. A pergunta é com quem.

Antes de aprovar mais uma máquina no provedor, faça uma conta chata que leva uns quarenta minutos. Pegue o log de acesso dos últimos sete dias, agrupe por user-agent e por faixa de IP, e some tempo de CPU e tempo de resposta dentro de cada grupo. Em sistema que serve página pública gerada na hora, é comum a maior fatia desse tempo estar indo para robô de leitura, e não para cliente.

O exemplo mais nítido dessa semana veio do servidor oficial do kernel do Linux. Konstantin Ryabitsev, que cuida da infraestrutura do kernel.org, contou que o git.kernel.org queima mais ciclos de CPU renderizando commits em HTML para scrapers do que gasta com todo o resto de acesso legítimo somado, git clone incluído. São cinco nós espalhados geograficamente e, a qualquer momento, catorze núcleos ocupados sem fazer outra coisa. Simon Willison publicou o relato no site dele há poucos dias, e o assunto foi parar no Hacker News.

Catorze núcleos. Nenhum humano do outro lado.

A página mais cara do seu site é a que ninguém abre duas vezes

O log de acesso responde em quarenta minutos o que a reunião de orçamento discute há três meses.

Interface web de git funciona assim: cada commit vira uma página gerada na hora, com diff, lista de arquivos alterados e links para a árvore do projeto naquele ponto do histórico. Multiplique o número de commits pelo número de arquivos e pelas visões possíveis, diff, blame, raw, árvore, e você tem um espaço de endereços que cresce por multiplicação. Num repositório do tamanho do kernel, ninguém consegue nem estimar de cabeça quantas páginas existem ali.

Gente abre uma dessas por vez, e quase sempre a mesma meia dúzia. Crawler abre todas, uma vez cada. Esse padrão anula qualquer cache: para cada endereço, a requisição do robô é a primeira e a última. Você paga o custo cheio de geração e não reaproveita nada.

O problema não pertence ao git. Willison escreveu no mesmo texto que se preocupa com isso por causa do Datasette, que por natureza publica um monte de página navegável. E a forma é a mesma em sistema comum de empresa: catálogo com filtro combinável na URL, agenda com uma página por dia, busca com parâmetro indexável, relatório que aceita intervalo de datas. Toda vez que uma combinação de filtros virou endereço público, você abriu uma superfície que se multiplica sozinha enquanto ninguém olha.

"Mas a gente tem robots.txt"

Essa é a primeira resposta que aparece na sala, e ela não segura o peso. O robots.txt é um pedido educado. Quem respeita já respeitava. E boa parte do tráfego de coleta em larga escala hoje não se identifica: chega com user-agent de navegador comum, saindo de faixas de IP residenciais que giram a cada punhado de requisições. Você não tem um nome para bloquear.

Tem um detalhe que muda o rumo da conversa: negar também custa. Quando a sua regra decide barrar, o handshake TLS já aconteceu, o roteamento já aconteceu, alguma camada já leu o cabeçalho. O que muda é a ordem de grandeza, e a diferença é enorme, porque devolver um 403 sai muito mais barato que renderizar um diff. Por isso vale bloquear. Só que uma regra escrita no lugar errado da pilha, dentro da aplicação, depois de abrir conexão com o banco, devolve quase nada. O trabalho caro já foi feito antes de alguém dizer não.

Três medições antes de comprar qualquer coisa

A fatura chega separada por serviço, nunca por causa.

Meça primeiro. Três números encerram a discussão, e nenhum deles exige ferramenta nova nem projeto de observabilidade.

1. A fatia de requisições e de tempo total de CPU por tipo de cliente nos últimos sete dias, separando navegador, bot que se identifica e tráfego sem identificação clara. Se o terceiro grupo for o maior, você já sabe para onde está indo o dinheiro.
2. As vinte rotas mais caras por tempo somado, não por número de acessos. A rota que aparece 300 vezes por dia e leva 900 ms pesa mais na fatura que a que aparece 90 mil vezes e leva 4 ms. Escreva ao lado de cada uma a taxa de acerto de cache.
3. Quantos endereços distintos o seu sistema é capaz de gerar. Se ninguém do time responde isso em voz alta numa reunião, essa é a resposta, e ela explica boa parte do que você paga todo mês.

Nenhuma dessas contas depende de aprovação de orçamento. Depende de alguém sentar com o log e aceitar que o número pode ser constrangedor.

O que cabe numa semana de trabalho

Com os três números na mão, as decisões ficam curtas. A primeira é servir uma versão barata para quem não é gente: a mesma informação, sem o render pesado, sem as consultas que montam a visão completa. A segunda é cache com chave certa e tempo generoso nas páginas que nascem de combinação de parâmetros, porque ali o conteúdo muda pouco e o custo de gerar é alto. A terceira é tirar a combinatória do índice, com canonical apontando para a versão sem filtro e a visão cara atrás de autenticação quando ela só interessa a quem já entrou. A quarta é limite por faixa e por sistema autônomo na borda, antes da aplicação, onde negar custa quase nada.

E agora o limite honesto disso tudo. Se o seu site é institucional, tem trinta páginas estáticas e vive atrás de CDN, nada disso é problema seu, e a sua conta subiu por outro motivo. Se a sua aplicação é toda atrás de login, idem. O que está escrito aqui vale para quem publica muita página gerada e navegável, e é justamente essa a arquitetura de quase todo produto que resolveu ser encontrável no Google.

A fatura vem separada por serviço, nunca por causa

A conta do provedor chega organizada por recurso: computação, banco, tráfego de saída, armazenamento. Nenhuma linha diz por que subiu. Então a reunião procura a explicação mais recente e disponível, que neste ano costuma ser a funcionalidade de IA que entrou no trimestre. Aprovam duas instâncias, a curva se comporta por umas seis semanas e volta a subir. No trimestre seguinte a conversa recomeça do mesmo lugar, com o mesmo culpado e um servidor a mais.

O que impede essa reunião de acontecer é instrumentação, e é aí que a maioria descobre que não tem. Um endpoint de health que responde 200 e um painel colorido com dado vazio passam a sensação de monitoramento sem entregar nenhum. Quando o sistema chega aqui para resgate, esse é o conjunto que aparece quase sempre junto: query lenta encadeada, log que não separa quem chamou o quê, e cobertura de teste sem expect. Nesses casos, a primeira semana é diagnóstico, não conserto/diagnostic-sprint>), porque mexer em produção sem medir antes é como trocar o registro achando que o vazamento está nele.

Vale dizer o que essa medição não responde. Ela não diz se o crawler que está te consumindo alimenta um buscador que te traz cliente, e essa é uma pergunta de negócio, não de infraestrutura. Tem robô que você quer receber. Tem robô que copia o seu catálogo inteiro toda madrugada e devolve zero. O log separa os dois pelo comportamento, não pela intenção declarada, e você é quem decide qual dos dois merece catorze núcleos.

O número do kernel.org é público. O seu ninguém mediu

O relato do git.kernel.org é útil porque veio de um lugar onde a infraestrutura é levada a sério, com gente competente cuidando e orçamento apertado. Se acontece lá, a chance de estar acontecendo no seu sistema, sem ninguém ter olhado, é alta.

Abra o log de ontem e some o tempo de CPU por user-agent. Se a maior fatia estiver com quem nunca vai comprar nada de você, a instância que você aprovar amanhã vai servir robô com uma latência ligeiramente melhor, e a linha da fatura vai subir de novo em uns dois meses. Quando alguém na sua empresa disser que a conta de nuvem subiu por causa da IA, faça uma pergunta só: qual porcentagem do tempo de CPU da semana passada foi gasta com requisição que não veio de um navegador? Se ninguém souber, a discussão sobre servidor pode esperar mais quarenta minutos. Sobre como a gente compara caminhos antes de recomendar um/compare>), e sobre o que já foi resgatado assim/cases>), o resto do site conta melhor que este parágrafo.