Dal “è abilitato” al “è adottato”
Un amministratore di enterprise risponde prima o poi a una domanda molto semplice: quello che paghiamo lo stiamo usando? Abilitare una funzionalità è un evento di configurazione, adottarla è un comportamento ricorrente, e i due dati non coincidono quasi mai. Un’organizzazione può avere GitHub Code Security attivo su tutti i repository senza aver mai chiuso un alert; può avere licenze assegnate a persone che non entrano nella console; può avere una policy di GitHub Actions permissiva e nessun workflow che gira davvero. In tutti e tre i casi la pagina delle impostazioni dice “sì” e la realtà dice “no”. Il tuo lavoro qui non è configurare, è misurare e poi raccomandare.
Vale la pena chiarire subito la terminologia, perché è cambiata: la sicurezza del codice non si chiama più con un nome unico. La documentazione parla oggi di GitHub Secret Protection e GitHub Code Security come prodotti distinti, e li vedi separati anche nei report di licenza, dove esistono colonne dedicate come code security license user e secret protection license user. Se in un’analisi di adozione tratti la sicurezza come un blocco unico, non riesci a dire quale dei due prodotti è quello inutilizzato.
Dove si leggono i segnali
Le sorgenti utili sono quattro e rispondono a domande diverse. La prima è l’audit log dell’enterprise, che racconta chi ha fatto cosa: si interroga con qualificatori come actor, action, created, operation, repository, country, ip e hashed_token. Attenzione a due limiti che pesano su un’analisi di trend: la finestra di conservazione è limitata e per i Git events è ancora più corta, quindi per ragionare su periodi lunghi devi attivare lo streaming dell’audit log verso una destinazione esterna (Amazon S3, Azure Blob Storage, Azure Event Hubs, Datadog, Google Cloud Storage, Microsoft Purview, Splunk) e analizzare lì.
La seconda è la sezione Billing and licensing dell’enterprise. La vista Usage distingue Metered usage e AI usage, permette di filtrare e raggruppare per repository, prodotto o SKU su intervalli di tempo scelti, ed esporta un CSV. La vista Licensing mostra le licenze consumate e consente il download del report di licenza, un CSV con decine di campi fra cui il login, i ruoli, il tipo di licenza e lo stato della two-factor authentication. Per automatizzare, esiste l’endpoint REST /enterprises/ENTERPRISE/settings/billing/usage/summary, filtrabile per year, month, day, hour e cost_center_id: qui c’è una trappola d’esame ricorrente, perché quegli endpoint di billing usage richiedono un personal access token classico e non accettano i fine-grained personal access token.
La terza è la lista People dell’enterprise, che oltre a Members, Outside collaborators e Invitations espone una vista Dormant users: è il modo più diretto per trovare account che consumano una licenza senza produrre attività. La quarta è la security overview, nella scheda Security and quality, dove la vista Coverage misura quanto le funzionalità di sicurezza sono attivate sui repository mentre Risk misura l’esposizione agli alert. Sono due domande diverse e vanno lette insieme: copertura alta con rimedio fermo significa strumenti accesi e processo assente. Per Copilot, infine, i report di attività espongono campi come last_activity_at, last_authenticated_at e last_surface_used, che dicono non solo se una persona usa il prodotto ma dove.
Dal dato alla raccomandazione
Un numero da solo non è una raccomandazione. Il passaggio che l’esame ti chiede di saper fare è collegare il segnale all’azione di governo. Licenze consumate da account dormienti si affrontano rimuovendo il seat o convertendo il membro in outside collaborator. Un consumo di licenze più alto del previsto ha una causa classica e documentata: la stessa persona con indirizzi email diversi fra i deployment consuma più licenze, e il rimedio è allineare gli indirizzi, usare i verified domains e verificare la sincronizzazione. Un prodotto a consumo che cresce senza controllo si governa con i cost centers, che attribuiscono la spesa a organizzazioni e repository, e con budgets and alerts: qui la distinzione da ricordare è che sui prodotti a licenza il budget avvisa e basta, mentre su prodotti a consumo come Actions e i crediti AI di Copilot può anche bloccare l’uso oltre soglia. Una funzionalità abilitata e mai usata non si “spegne e via”: prima verifichi se il problema è di enablement, di formazione o di policy che la rende inutilizzabile.
Che cosa produci prima di coinvolgere il Support
Aprire un ticket senza evidenze allunga il ciclo. Sul GitHub Support portal compili campi precisi — la selezione fra personal account, enterprise account o organization, il campo From, Product, Type of Issue, Subject e la descrizione — e alleghi materiale entro il limite di dimensione previsto. Prima però assicurati che il tema sia in perimetro: sono dichiarati fuori scope, fra gli altri, le integrazioni di terze parti, la configurazione dei provider di identità SAML, la scrittura di script, le configurazioni del cloud provider e le domande sul consumo di Copilot o sulla spiegazione della fatturazione a consumo.
Su GitHub Enterprise Server la diagnostica si genera tu. Il diagnostic file è un file di testo con l’assetto dell’istanza, ottenibile dal Management Console con Download diagnostics info oppure via ghe-diagnostics. Il support bundle è invece un archivio che contiene la diagnostica più i log sanificati — password, token e chiavi private vengono rimossi od offuscati e il contenuto dei repository non è incluso — e si crea con ghe-support-bundle -o; l’opzione -x produce il bundle esteso con una finestra di log più ampia e i file ruotati, -u carica direttamente verso GitHub, e su installazioni in cluster si usa ghe-cluster-support-bundle. Non confondere i due artefatti: il Support chiede quasi sempre il bundle, non solo la diagnostica. Per capire quando è successo qualcosa, i monitor dashboards del Management Console mostrano lo storico di CPU, storage e tempi di risposta; la disponibilità di dashboard Grafana personalizzate dipende dalla versione dell’istanza, quindi verifica sempre sulla documentazione della tua release. Con il piano Premium puoi infine caricare un support bundle nel portale e richiedere un Health Check, che restituisce un’analisi di General Health, Security, Git Analysis e API Analysis: è diagnostica proattiva, non reattiva, ed è spesso la risposta corretta quando la domanda parla di ottimizzazione e non di incidente.