In questo articolo Indice dei contenuti 2 sezioni
Chi lavora con il codice se ne è accorto subito: il GitHub down iniziato nel pomeriggio del 17 agosto, ora italiana, ha messo in difficoltà una fetta enorme della piattaforma, con errori a raffica e rallentamenti che hanno toccato sito web, API e buona parte degli strumenti usati ogni giorno negli ambienti di sviluppo. Non un intoppo passeggero da qualche minuto, insomma, ma un disservizio ampio che la stessa società ha confermato pubblicamente, mettendo nero su bianco numeri tutt’altro che rassicuranti.
Il quadro è quello di una piattaforma che risponde a singhiozzo. I tassi di errore hanno raggiunto il 20% per la maggior parte degli utenti, sia navigando dall’interfaccia web sia effettuando chiamate alle API. Tradotto in pratica: una richiesta su cinque va a vuoto, e in un flusso di lavoro dove le operazioni automatiche sono centinaia al giorno l’effetto si moltiplica in fretta.
Quali servizi di GitHub sono coinvolti
L’elenco delle aree colpite è lungo e comprende praticamente tutto ciò che gli sviluppatori toccano nell’arco di una giornata: sito web, API, Actions, Pull Request, Issues, Webhooks e, per molti, anche Copilot. Il capitolo più delicato riguarda il download dei repository, dove il tasso di errore sale fino al 50%. Una soglia che si può definire critica senza esagerare, perché significa che scaricare o semplicemente accedere ai file diventa un’impresa per la maggior parte degli utenti.
Ci sono poi i servizi legati all’autenticazione e alla gestione degli account aziendali, che nelle organizzazioni strutturate sono il primo cancello da attraversare. Tra questi risultano interessati SAML, OIDC, SCIM e Team Sync, quindi non solo il lavoro sul codice ma anche l’ingresso stesso agli ambienti condivisi. Le segnalazioni raccolte parlano di errori del server durante l’accesso e di problemi nel caricamento di commit, repository e pagine dedicate alle Pull Request, quelle su cui si concentra buona parte della revisione collaborativa.
Cosa continua a funzionare e i tempi di ripristino
Non tutto è fermo, per fortuna. Alcuni servizi hanno continuato a rispondere più o meno normalmente, e qui rientrano Git Operations, Packages, Pages e Codespaces. Un dettaglio importante, perché consente almeno una parte delle operazioni locali e della pubblicazione, anche se il quadro generale resta compromesso e la sensazione, per chi ci lavora, è quella di muoversi su un terreno instabile.
Sul fronte degli interventi, nell’arco di un paio d’ore dalla prima conferma ufficiale la piattaforma di Microsoft ha comunicato di aver individuato un componente problematico e di aver distribuito le prime contromisure, con hotfix già in circolo. Il che è una buona notizia soltanto a metà: la situazione è rimasta difficoltosa anche dopo il rilascio delle prime correzioni, segno che l’origine del guasto ha ramificazioni non banali all’interno dell’infrastruttura. Verosimilmente servirà ancora del tempo prima che l’emergenza rientri del tutto e che i valori tornino nella norma su tutti i fronti, download dei repository compresi. La società ha fatto sapere di stare continuando a investigare, quindi il lavoro di analisi procede in parallelo alle patch già applicate. Per gli sviluppatori l’indicazione implicita è quella di mettere in pausa le operazioni più pesanti, in particolare quelle che passano dalle Actions o dalle chiamate massive alle API, ed evitare di insistere su richieste che con un tasso di errore del 20% rischiano soltanto di caricare ulteriormente i sistemi.
Il disservizio conferma quanto l’intera catena di sviluppo software moderna dipenda da un numero ristretto di infrastrutture centrali, dove un singolo componente in avaria si porta dietro autenticazione, automazioni, revisione del codice e assistenti basati sull’intelligenza artificiale nello stesso momento.
