GitHub down: il codice distribuito che prima vuole che torni il sito

Quando il cloud tossisce

GitHub down non suona mai come una catastrofe, almeno all’inizio. Sembra una piccola frase tecnica, una di quelle che compaiono nelle chat aziendali tra un “riavvio il router” e un “a me funziona”. Poi qualcuno prova ad aprire una pull request, un altro cerca una issue, il terzo aspetta il deploy automatico, e improvvisamente l’ufficio diventa una sala d’attesa con le sedie ergonomiche.

GitHub viene raccontato come il luogo dove il codice vive, collabora, si organizza e si racconta, come ricorda anche questa panoramica su GitHub come piattaforma centrale per software e AI. Il problema comincia quando una piattaforma “centrale” viene presa alla lettera. Il codice era distribuito, ma l’ansia aveva un unico indirizzo web.

Il distribuito che fa la fila allo stesso sportello

Git, tecnicamente, nasce per non dipendere da un solo punto. Ogni sviluppatore ha una copia, una storia, dei branch, un piccolo archivio personale del mondo. Le guide lo spiegano con pazienza, come nella guida a Git e GitHub sul versionamento distribuito, dove tutto sembra molto robusto finché non arriva il momento di premere quel pulsante verde che vive altrove.

In teoria puoi continuare a lavorare in locale. In pratica il team moderno non lavora soltanto sul codice: lavora sulle approvazioni, sui commenti, sulle pipeline, sulle notifiche, sulle emoji di revisione e su quella frase “LGTM” che ormai vale più di una firma notarile. Quando GitHub non risponde, resta il codice sul disco, ma sparisce il tribunale dove quel codice viene dichiarato socialmente accettabile.

La produttività appesa a una pull request

Negli uffici si parla molto di autonomia, asincronia, smart working e processi snelli. Poi basta un’interfaccia in difficoltà per scoprire che metà della produttività aziendale consiste nel ricaricare una pagina sperando che una rotellina smetta di girare. Chi ieri spiegava la resilienza dell’architettura oggi manda screenshot sfocati in chat con scritto: “anche da voi?”

La scena ha una sua compostezza tragica. Il frontend aspetta il backend, il backend aspetta il reviewer, il reviewer aspetta che tornino i commenti, il project manager aspetta un aggiornamento della board e tutti aspettano un servizio nato per evitare che il lavoro dipendesse da una persona sola. Semplicemente, ora dipende da una persona giuridica molto grande.

La sicurezza automatica col semaforo spento

Una parte del fascino moderno sta nell’idea che le macchine controllino le macchine. Workflow, scanner, analisi, controlli automatici: il codice entra in una catena di montaggio e, se tutto va bene, esce con una specie di benedizione tecnica. Microsoft spiega perfino come creare un workflow GitHub CodeQL per l’analisi di sicurezza, perché ormai anche la prudenza deve avere un file YAML.

Quando però GitHub down rallenta o blocca le automazioni, la sicurezza diventa una fila al semaforo spento. Tutti sanno cosa dovrebbe succedere, nessuno vuole passare per primo, e il deploy assume la stessa gravità morale di attraversare col rosso davanti a una scuola. Chi ha letto abbastanza storie di vulnerabilità sa che la dipendenza dagli strumenti non è molto diversa dalla dipendenza dalle patch: lo racconta bene anche il pezzo su 0-day e patch impossibili.

Il repository come infrastruttura civile

GitHub non ospita solo startup, librerie abbandonate e progetti chiamati “final-final-v2”. Ci sono anche repository pubblici, documentazione, strumenti, iniziative istituzionali: basta guardare il repository italia/dati.gov.it su GitHub per ricordarsi che perfino l’amministrazione digitale, a volte, parcheggia un pezzo di sé nella stessa piazza dove uno studente carica il suo primo esercizio in Python.

Così il down non riguarda più soltanto chi scrive codice. Riguarda chi lo legge, chi lo verifica, chi ci costruisce sopra un servizio, chi copia una riga da una documentazione, chi controlla se un progetto è ancora vivo. È lo stesso destino raccontato in molte tecnologie quotidiane: nel pezzo su Microsoft Windows e gli update infiniti il computer personale diventa un’amministrazione remota; qui il repository personale diventa una dipendenza urbana.

La normalità del refresh

C’è persino chi conserva e discute i tempi di inattività, come in questa conversazione sui downtime storici di GitHub tracciati e commentati. È una forma di archeologia del disservizio: non basta subire l’interruzione, bisogna anche misurarla, graficarla, archiviarla e trasformarla in memoria collettiva. Il guasto diventa dataset, perché ormai anche l’impazienza vuole una visualizzazione.

Intanto qualcuno aggiorna la pagina, qualcuno apre la chat, qualcuno propone di “lavorare su altro”, frase che negli ambienti digitali indica spesso un’attività vaga, quasi agricola. Quando GitHub torna online, nessuno festeggia davvero: semplicemente riprende la dipendenza, ma con un sospiro di sollievo. Poi si torna a parlare di cloud, automazione, collaborazione globale e privacy dei dati come se ogni cosa fosse sotto controllo, magari dopo aver letto anche la privacy che prima vuole consenso, banner e pazienza.

ODRUSSA!