Report dei prodotti metered e ottimizzazione di licenze e risorse
Nella console di enterprise il consumo vive sotto Billing and licensing, dove le voci Metered usage e AI usage mostrano i prodotti a consumo, mentre Licensing mostra le postazioni occupate. Sono due mondi che si leggono e si tagliano in modo diverso: le licenze si liberano cambiando chi ha accesso, i prodotti metered si riducono cambiando come vengono usati. Confonderli è l’errore più comune quando arriva la richiesta “spendiamo troppo, tagliate”.
Leggere un report di uso dei prodotti metered
GitHub espone tre report distinti. Il summarized usage report aggrega su un orizzonte lungo e raggruppa per data, SKU, repository e cost center: è quello giusto per capire l’andamento e per il confronto mese su mese. Il detailed usage report copre una finestra breve ma aggiunge le colonne username e workflow_path, quindi è l’unico che ti dice chi e quale workflow sta consumando. L’AI usage report scende al livello del modello, con input, output, cache_read e cache_write.
Le colonne comuni sono date, product, sku, quantity, unit_type, applied_cost_per_quantity, gross_amount, discount_amount e net_amount. La distinzione che devi avere chiara è fra gross amount e net amount: il secondo è l’importo effettivamente fatturabile dopo l’applicazione di discount_amount, ed è lì che finisce la quota inclusa nel piano. Un repository può quindi apparire con un consumo lordo importante e un netto pari a zero perché rientra ancora nell’incluso: guardare la colonna sbagliata porta a ottimizzare dove non c’è nulla da risparmiare.
Per automatizzare c’è l’endpoint REST di riepilogo, nella forma /enterprises/ENTERPRISE/settings/billing/usage/summary, con i parametri temporali year, month, day, hour e, solo a livello enterprise, cost_center_id. Due dettagli che l’esame ama: le billing usage API non supportano i fine-grained personal access token, servono i personal access token (classic); e i dati del detailed usage report sono disponibili solo nell’interfaccia web, non via REST. Se qualcuno ti chiede una pipeline automatica sul dettaglio per workflow, la risposta corretta è che non esiste.
Attribuire la spesa: cost center e budget
I cost center si creano da Billing and licensing > Cost centers con New cost center e servono ad attribuire consumo e spesa a unità organizzative reali. Puoi aggiungerci organizations, repositories, users ed enterprise teams — questi ultimi sono la scelta scalabile, perché l’appartenenza si aggiorna da sola quando cambia il team. Una risorsa può appartenere a un solo cost center per volta.
L’attribuzione segue la natura del prodotto, ed è materia da domanda a scenario. I prodotti a consumo, come GitHub Actions, si attribuiscono al repository o all’organization dove l’uso avviene. I prodotti a licenza si attribuiscono all’utente, con una precedenza precisa: assegnazione diretta dell’utente, poi enterprise team (se ne ha più di uno, vince quello creato prima), poi organization, infine enterprise. I crediti AI seguono l’utente che li ha generati o l’organization che gli ha concesso la licenza Copilot. Ricorda anche che i cost center funzionano sul consumo metered, non sulla fatturazione a volume o in abbonamento.
Sui cost center si applicano i budget, che possono avere scope su account, repositories, organizations, cost center o utenti. Qui c’è la trappola classica: l’opzione Stop usage when budget limit is reached blocca davvero solo i prodotti metered, mentre per i prodotti a licenza — GitHub Enterprise, GitHub Team, Copilot — il budget produce soltanto avvisi e non impedisce di superare la soglia. Fanno eccezione le SKU della sicurezza del codice, oggi GitHub Secret Protection e GitHub Code Security, i due prodotti in cui è stato scorporato quello che la documentazione più vecchia chiamava GitHub Advanced Security: lì il blocco è supportato. Gli alert partono a soglie percentuali predefinite e vanno per default a owner e billing manager, con destinatari aggiuntivi configurabili.
Ottimizzare le licenze
Dalla pagina Licensing scarichi il CSV con l’elenco nominativo: username, tipo di licenza (Enterprise oppure Visual Studio subscription), organizations e ruolo, stato della 2FA, cost center e invitations in sospeso. Da lì si lavora su tre fronti. Gli utenti dormienti che restano membri o owner di almeno un’organization continuano a consumare: vanno rimossi o, su Enterprise Managed Users, sospesi, perché un managed user account sospeso non consuma licenza. Gli outside collaborator su repository private o internal consumano (una volta sola, anche con accesso a molti repository), mentre su repository pubbliche no: convertire un membro in outside collaborator con accesso ai soli repository pubblici è la leva documentata per ridurre le postazioni. Gli inviti in sospeso sono il punto dove quasi tutti sbagliano: con la fatturazione a volume occupano una postazione, con la fatturazione usage-based non consumano licenza. Sotto usage-based conviene inoltre ragionare in termini di consumed licenses contro billable licenses, perché chi smette di consumare a metà mese si vede l’aggiustamento sulla fattura successiva.
Se il conteggio è più alto del previsto in uno scenario misto con GHES, la causa tipica sono le identità duplicate: verifica i membri senza indirizzo email di un dominio verificato, allinea la stessa email su tutti gli account e controlla il timestamp dell’ultimo license sync, forzandone uno nuovo se necessario. Su GHES (documentazione fissata a 3.21) il consumo licenze viaggia verso l’enterprise account tramite la sincronizzazione, quindi un dato “vecchio” è spesso un sync non ancora eseguito, non un errore di fatturazione.
Ottimizzare le risorse a consumo
Sul lato risorse le leve stanno nelle policy Actions dell’enterprise. Artifact and log retention e le Cache settings (retention e limite di storage per repository) sono i due parametri che incidono di più sullo storage senza toccare una riga di workflow: abbassare la retention degli artifact è il taglio più indolore che puoi fare. Sui minuti, la scelta del runner conta: i larger runners non sono ammessi ai minuti inclusi sulle repository private e vengono sempre fatturati al minuto, però un larger runner definito e non usato non costa nulla — quindi il problema non è quanti ne hai configurati, ma quali job ci mandi sopra. I runner groups servono a controllare quali repository possono usarli, ed è la vera protezione contro il consumo non voluto. Ricorda infine che i self-hosted runner si governano con policy separate a livello di enterprise e organization: spostare i carichi lunghi su self-hosted riduce il metered, ma sposta il costo sull’infrastruttura, non lo elimina.