O Que É Utilização de Runner? Você Está Pagando por Tempo Ocioso?
Utilização de runner é a fração do tempo de runner que você paga que está de fato fazendo trabalho útil - o resto é capacidade ociosa na qual você está queimando dinheiro.
Baixa utilização é o custo silencioso do CI. Um runner que fica com boot dado mas ocioso, ou uma máquina de 16 cores rodando um job single-threaded, é dinheiro gasto sem valor retornado. Medir a utilização diz onde está o desperdício.
Dois tipos de desperdício
Desperdício baseado em tempo são runners ociosos ainda sendo cobrados (pools superprovisionados, scale-down lento). Desperdício baseado em recursos são runners grandes demais para o job - pagando por cores e memória que um build single-threaded nunca toca.
Por que a utilização cai
- Pools fixos dimensionados para o pico que ficam ociosos a maior parte do dia.
- Runners superdimensionados escolhidos "por segurança".
- Longo tempo de provisionamento ou de fila contado como tempo de runner pago.
- Jobs sequenciais que deixam a capacidade paralela sem uso.
Aumentando a utilização
Faça right-sizing dos runners para o job, use autoscaling e scale-to-zero para que o tempo ocioso não custe nada, e paralelize o trabalho para manter as máquinas ocupadas. A cobrança por segundo também ajuda - você para de pagar por caudas ociosas arredondadas para cima.
Utilização em runners gerenciados
Plataformas gerenciadas aumentam a utilização automaticamente: o scale-to-zero remove o desperdício ocioso e o right-sizing evita máquinas superdimensionadas. A cobrança por segundo e o autoscaling da Latchkey significam que você paga por trabalho, não por ociosidade.
Medindo
Acompanhe o tempo ativo de job contra o tempo total de runner cobrado, e compare o tamanho de runner solicitado contra a CPU e memória realmente usadas por job. Uma grande diferença em qualquer um dos eixos aponta diretamente para superprovisionamento - a economia de CI mais barata geralmente está bem ali.
Principais conclusões
- Utilização é a parcela do tempo de runner pago que faz trabalho útil.
- Pools ociosos e runners superdimensionados são as principais fontes de desperdício.
- Right-sizing, scale-to-zero e paralelismo a aumentam.
- Autoscaling e cobrança por segundo alinham o custo com o trabalho real.