Análise de custo

Entenda custo teórico vs. faturável, acompanhe os minutos do plano gratuito para GitHub e Latchkey, e encontre seus repositórios e workflows mais caros.

A página Cost Analysis responde "para onde vai o dinheiro da nossa CI?" tanto para runners hospedados pelo GitHub quanto do Latchkey.

A página é organizada em três seções: Cost Overview (os KPIs de destaque), Cost Analysis (os gráficos que você detalha) e Latchkey Runner Costs (o quanto seus runners gerenciados estão custando neste período de faturamento). Antes que qualquer disso seja útil, porém, você precisa da distinção sobre a qual toda a página é construída.

Dois números para entender#

Por que dois números? Os planos gratuitos absorvem a primeira fatia do seu uso, o que torna o custo faturável um sinal de tendência ruim: ele pode ficar perto de zero por parte de um período e depois subir abruptamente assim que os minutos gratuitos acabam, mesmo quando seu uso real cresceu de forma suave. O custo teórico se move em proporção ao uso, então é o que se deve ler quando você pergunta "estamos usando mais CI do que no mês passado?" O custo faturável é o que se deve ler quando você pergunta "quanto vamos pagar?"

Seção Cost Overview#

• Theoretical Cost com um selo de tendência semana a semana e as porções de GitHub vs. Latchkey rotuladas embaixo. O selo de tendência compara o custo faturável dos últimos 7 dias com os 7 anteriores e mostra um traço até existirem duas semanas completas de dados.
• Highest Spend (Theoretical): seus 3 principais repositórios por custo modelado no período selecionado.
• Cost Per Build e Build Efficiency Ratio para normalizar o gasto em relação à produção. O custo por build é o custo teórico médio por build bem-sucedido; a razão de eficiência é a taxa de sucesso de build em relação ao custo teórico, então maior significa mais builds bem-sucedidos por dólar.
• Pilhas de KPI de GitHub e Latchkey: custo faturável previsto para o período e minutos do plano gratuito usados e restantes de cada lado.
• Free Tier Minutes Tracking: medidores segmentados para minutos incluídos do GitHub e minutos incluídos do Latchkey lado a lado, com os limites refletindo as cotas do seu próprio plano.

Uma observação sobre Cost Per Build: o custo total sobe sempre que sua equipe entrega mais, o que geralmente é boa notícia, não um problema. O custo por build remove o volume do quadro. Se o custo total está em alta mas o custo por build está estável, você simplesmente está construindo mais. Se o próprio custo por build está subindo, cada build ficou mais caro: execuções mais longas, runners maiores ou novas etapas, e essa é a tendência que vale investigar.

A previsão também merece uma observação. Assim que o mês atual acumula histórico de uso suficiente, a pilha de KPI do GitHub projeta o gasto faturável até o fim do ciclo de faturamento como Forecasted billable cost by end of cycle, com base no seu padrão de gasto no mês até a data. Até lá, o cartão exibe "Not enough data yet, run more jobs for a forecast". De qualquer forma, você vê para onde o mês está indo enquanto ainda há tempo de reagir.

Seção Cost Analysis#

• Cost Over Time: custo faturável e teórico diário como duas séries ao longo do intervalo de datas selecionado.
• Repository Costs: custo teórico e faturável por repositório, com um menu suspenso Top 5 / Bottom 5. Os nomes dos repositórios têm link direto para o GitHub, para que você possa ir de um pico de custo aos arquivos de workflow por trás dele em um clique.
• Cost by Runner OS: uma rosca de gasto entre Linux, Windows e macOS, separando Linux (GitHub) de Linux (Latchkey) quando ambos existem.

Duas dicas de leitura para esta seção. No Cost Over Time, o ponto em que a linha faturável começa a acompanhar a linha teórica é o ponto em que seus minutos do plano gratuito acabaram; antes disso, os minutos gratuitos estavam absorvendo a diferença. E no Cost by Runner OS, lembre-se de que o GitHub cobra um adicional pelos minutos de Windows e macOS, então uma grande fatia de Windows ou macOS costuma ser uma lista de jobs que vale mover para runners Linux mais baratos.

Seção Latchkey Runner Costs#

Se você executa jobs em runners gerenciados, esta seção aparece com uma tabela de custo por configuração: Config Name (com o rótulo de runner que você usa nos arquivos de workflow, como latchkey-small), um selo de tipo Custom or Preset, Jobs, Avg Duration e Cost para o período selecionado. Quando minutos gratuitos foram usados, um rodapé mostra "Free tier applied: X / Y min" e o valor em dólares economizado. Os KPIs de custo de runner do Latchkey sempre refletem o período de faturamento atual, independentemente do filtro de intervalo de datas.

Acima da tabela, um destaque exibe "Estimated savings vs GitHub-hosted: $X": os dólares que sua equipe economizou ao executar jobs em runners do Latchkey em vez de runners comparáveis hospedados pelo GitHub no período selecionado. Ele aparece sempre que a economia é positiva.

Filtros nesta página#

A barra de filtros compartilhada funciona aqui como funciona em qualquer lugar (tipo de runner, multisseleções de repositório e workflow, redefinir), com uma diferença: o seletor de intervalo de datas usa predefinições voltadas para faturamento: MTD, 7D, 30D, 3M, 6M e 12M. Todo gráfico também abre em um modo de tela cheia que mantém a barra de filtros, e a engrenagem de configurações de exibição tem um botão "Show decimals" que alterna os valores em dólares entre precisão de centavos e dólares inteiros arredondados.

Qual gráfico responde qual pergunta#

Usando esta página para de fato cortar custo#

Uma rotina sugerida quando o gasto precisa cair. Nada aqui é imposto pelo produto; é simplesmente a ordem em que os gráficos respondem às perguntas uns dos outros:

Referência de métricas#

Para modelar o gasto antes que ele apareça nesta página - um novo repo, um runner maior, mais jobs - use a calculadora de custo do GitHub Actions no Learn, ou navegue pelos guias de custo de CI para a mecânica de preços entre provedores.