Il confine: la configurazione è tua, la piattaforma è loro
La maggior parte delle segnalazioni che arrivano a un amministratore non sono guasti: sono conseguenze di una configurazione. Un utente che non vede un repository è quasi sempre un problema di base permissions dell’organizzazione o di accesso del team. Un workflow che non parte in una organizzazione è quasi sempre una Actions policy ereditata dall’enterprise. Un accesso che fallisce dopo un cambio nell’identity provider è SAML o SCIM da sistemare. Tutte cose che risolvi tu, dalle impostazioni di organizzazione o di enterprise, senza scomodare nessuno.
GitHub Support interviene su prodotto e piattaforma: malfunzionamenti del servizio, comportamenti anomali dell’istanza, problemi di licenza o di account che non puoi sanare dalla console. La documentazione elenca in modo esplicito ciò che resta fuori dall’ambito di GitHub Support: integrazioni di terze parti, sistemi CI/CD esterni, scripting e automazioni personalizzate, la configurazione del tuo identity provider esterno, la tua rete con firewall e proxy, Kubernetes e le preview features, siano esse public, private o technical preview. Per quel tipo di lavoro esistono i GitHub Expert Services. È il punto in cui l’esame ti mette davanti a uno scenario e chiede di scegliere: “l’autenticazione SAML si è rotta dopo la rotazione del certificato sull’IdP” non è un ticket, è manutenzione tua.
Quando il ticket serve davvero si apre dal GitHub Support portal, indicando account, prodotto, tipo di problema, oggetto e descrizione; enterprise owner e billing manager hanno l’entitlement in automatico. La priority va scelta con onestà, perché è documentata: Urgent esiste solo con GitHub Premium Support e descrive workflow di produzione fermi con impatto diretto sul business, High copre impatti limitati su account o sicurezza, Normal i disservizi moderati e le domande, Low ciò che non blocca nessuno. Gonfiare la priorità non accelera nulla e brucia credibilità.
Support bundle e diagnostica su GitHub Enterprise Server
Su GitHub Enterprise Server l’evidenza da allegare ha nomi precisi. Il diagnostic file è un testo con impostazioni e ambiente dell’istanza: versione, licenza, hostname, SSL, configurazione di rete, metodo di autenticazione, conteggi di repository e utenti. Il support bundle è un archivio compresso che contiene la diagnostica più i log sanificati — authentication, Management Console, exception, audit, Git proxy — insieme a metriche dei servizi e, nelle configurazioni ridondate, stato di replica e dei nodi.
ssh -p122 admin@HOSTNAME -- 'ghe-diagnostics' > diagnostics.txt
ssh -p122 admin@HOSTNAME -- 'ghe-support-bundle -o' > support-bundle.tgz
ssh -p122 admin@HOSTNAME -- 'ghe-support-bundle -o -x' > support-bundle.tgz
ssh -p122 admin@HOSTNAME -- 'ghe-support-bundle -u'Il bundle standard copre due giorni di log, l’extended support bundle generato con -x ne copre otto, e --period permette una finestra diversa; per un cluster si usa ghe-cluster-support-bundle. L’opzione -u carica il file direttamente e richiede uscita HTTPS verso l’endpoint dei bundle: se il firewall la blocca, restano il pulsante Download support bundle nella scheda Support della Management Console, il portale di upload, oppure Settings > License > Upload a support bundle dall’enterprise account.
Due precisazioni che l’esame ama. Primo: il bundle non contiene il contenuto dei repository, e token, chiavi e segreti vengono rimossi dai log — il timore di “spedire il codice” è infondato. Secondo: il support bundle è un concetto di GHES. In GHEC, con account personali, con Enterprise Managed Users o con data residency, non generi bundle: fornisci URL di organizzazione o repository, orari precisi e voci dell’audit log. Le pagine GHES qui citate sono fissate a enterprise-server@3.21 e alcuni comportamenti dipendono dalla versione: le metriche OpenTelemetry sono ormai la base del monitoraggio mentre collectd è in dismissione, quindi controlla la release della tua istanza prima di dare per scontato un dashboard.
Prima di aprire il ticket guarda i monitor dashboards della Management Console, i system logs e le soglie di allarme raccomandate su disco, memoria e CPU: un’istanza sotto-dimensionata è un problema di capacity planning, non di Support. Il Health Check è un servizio riservato ai clienti Premium e richiede comunque un support bundle caricato. Questa raccolta di evidenze torna nel dominio dedicato a monitoraggio e troubleshooting; qui interessa il momento dell’escalation, cioè decidere quando smettere di indagare e allegare.
Standard di processo e leve tecniche per imporli
L’amministratore raccomanda il GitHub flow: un branch di breve vita per ogni insieme di modifiche, commit descrittivi, pull request con sintesi del problema risolto, revisione, merge e cancellazione del branch. Sulle release, la convenzione parte dai Git tags: una release nasce da un tag e può usare le automatically generated release notes, quindi conviene fissare uno schema di nomi per i tag e stabilire chi può crearli o cancellarli.
La leva moderna per rendere effettivo tutto questo sono i rulesets, definibili a livello di repository, organizzazione ed enterprise, da Policies > Code > New ruleset. Rispetto alle protected branches hanno tre vantaggi che l’esame verifica: più ruleset possono applicarsi allo stesso branch e le regole si aggregano nella versione più restrittiva, esiste una bypass list per ruoli e team, ed esiste lo stato Evaluate che misura le violazioni senza bloccare nessuno, accanto ad Active e Disabled. Da qui imponi Require a pull request before merging con numero di approvazioni, dismissione delle approvazioni obsolete, revisione dei Code Owners e risoluzione delle conversazioni; poi Require status checks to pass, Require linear history, Require signed commits, Block force pushes, le restrizioni su creazione e cancellazione e le metadata restrictions su messaggi di commit e nomi dei tag. I push rulesets bloccano push indesiderati anche sull’intera fork network di repository private o internal.
Completano il quadro i workflow templates, che vivono nella cartella workflow-templates del repository .github dell’organizzazione con una coppia di file .yml e .properties.json, e i default community health files — CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, SUPPORT, template di issue e pull request — pubblicati nello stesso repository .github. Attenzione alla confusione più frequente: CODEOWNERS non è un file defaultabile, va messo in ogni repository. Infine, quando parli di controlli di sicurezza nel processo, usa i nomi attuali: GitHub Secret Protection per secret scanning, push protection e delegated bypass, e GitHub Code Security per code scanning con CodeQL e dependency review.