engenharia
O que aprendemos executando um milhão de jobs de CI
Tempo de fila, comportamento do cache, dimensionamento correto e modos de falha que só aparecem em escala.
{autor} · {papel} · {data} · {minutos} {minutosLabel}
Um milhão de empregos é suficiente para ver a cauda longa. Aqui está o que nos surpreendeu.
O tempo de fila é invisível e enorme
As durações das etapas são mostradas com destaque. O tempo de fila não é mostrado. Encontramos repositórios onde o tempo médio da fila excedeu o tempo médio de construção, e a equipe passou um quarto otimizando a construção.
A maioria dos corredores tem o tamanho errado em ambas as direções
Cerca de 40% dos trabalhos tiveram em média menos de 30% de utilização da CPU – pagando por núcleos ociosos. Outros 12% ficaram fixados em 100% durante toda a duração e permaneceram no caminho crítico. O dimensionamento correto em ambas as direções valeu mais do que qualquer alteração no cache para a maioria dos clientes.
A espera de E/S é o assassino silencioso
npm gravando 40.000 arquivos, Cargo descompactando caixas, Docker extraindo camadas - nada disso é trabalho de CPU. No armazenamento conectado à rede, essas etapas dominam e cada gráfico da CPU parece bom enquanto isso.
Testes instáveis custam mais do que qualquer modelo
O custo direto de uma repetição é óbvio. O custo indireto – engenheiros repetindo falhas reais porque tentar novamente é um hábito – é muito maior e não aparece em nenhuma fatura.
O tráfego do agente mudou o formato da carga
Repositórios com agentes de codificação de IA apresentam frequência de push várias vezes maior do que repositórios somente humanos, em rajadas. O cancelamento de simultaneidade passou de uma ótima otimização a um requisito difícil para essas equipes.
Seu próximo build pode ser duas vezes mais rápido, pela metade do preço
Comece grátis. Sair é a mesma linha, e publicamos esse diff também.