Il blackout di GitHub: il carico di commit raddoppiato

Sette Ore E Quarantasette Minuti, Ricondotte A Un Proxy Sovraccarico

Il rapporto di GitHub, pubblicato sul proprio blog di ingegneria con il titolo 'The August 17 outage, and the work ahead', riconduce il guasto a un proxy sidecar Istio nel data center Central US che ha raggiunto la sua capacità massima di elaborazione concorrente. La politica di autoscaling che sorvegliava quella capacità valutava solo il servizio applicativo in sé, non lo stato di connessione e concorrenza dei sidecar posti davanti a esso, cosicché nulla si è scalato quando i sidecar hanno toccato il limite. Una volta saturi quei proxy, le richieste si sono spostate su altri nodi, che a loro volta hanno raggiunto i propri limiti di capacità, e la logica di retry automatico di GitHub ha aggravato la spirale inviando nuove richieste verso load balancer già sovraccarichi. Un bug di retry separato, secondo quanto riportato da The Register, presente in un'estensione di VS Code usata per l'autenticazione di GitHub Copilot, ha aggravato ulteriormente il guasto: continuava a richiedere nuovi token di autenticazione senza pausa, portando il servizio di emissione token di GitHub da una base normale di 7.000-9.000 richieste al secondo fino a 70.000-100.000 richieste al secondo, circa dieci volte il carico abituale.

I Numeri Dietro Un Brutto Pomeriggio

Il blackout è durato dal 17 agosto 2026, dalle 13:28 alle 21:15 UTC, e gli stessi aggiornamenti di stato di GitHub hanno indicato tassi di errore massimi vicini al 20 per cento su traffico web e API e circa al 50 per cento sui download di archivi e contenuti raw, esattamente il tipo di richiesta da cui dipendono una pipeline di build o il recupero di una dipendenza. Issues, pull request, API, Actions e Copilot sono stati tutti degradati, insieme all'autenticazione SAML e OIDC, a SCIM e a Team Sync; la maggior parte dei servizi si è ripresa entro le 16:36 UTC, Actions entro le 18:03 UTC, e il servizio token di Copilot per ultimo, alle 21:02 UTC. GitHub ha precisato esplicitamente che né questo incidente né il più piccolo guasto di Actions del 6 agosto sono stati causati da una modifica di codice o configurazione; entrambi sono stati, nelle parole della stessa azienda, guasti di capacità nella loro essenza, cioè il sistema ha esaurito il margine invece di rompersi per un errore rilasciato.

Il Volume Dei Commit È Quasi Raddoppiato In Quattro Mesi

Nascosto nello stesso rapporto c'è il dato che trasforma questa storia da racconto di un blackout a storia di infrastruttura: GitHub afferma che il volume mensile di commit è cresciuto da 1,4 a 2,9 miliardi da aprile 2026, praticamente raddoppiato in circa quattro mesi, accompagnato da grafici che mostrano le pull request unite avvicinarsi a 130 milioni al mese e i nuovi repository avvicinarsi a 24 milioni al mese. GitHub aveva già segnalato la causa nel proprio rapporto sulla disponibilità di maggio 2026, dove riconosceva che la programmazione assistita dall'IA e i flussi di lavoro agentici stavano aggiungendo pressione alla propria infrastruttura, e Microsoft ha dichiarato pubblicamente che l'IA scrive ormai fino al 30 per cento del codice in alcuni dei propri repository, soggetto a revisione umana. Una piattaforma dimensionata per un mondo in cui i commit arrivavano al ritmo della digitazione umana ora assorbe uno schema di carico dettato da agenti di codifica che scrivono, ramificano e fanno push in modo continuo, e la risposta di GitHub finora è stata aggiungere capacità: oltre 3 milioni di core CPU e 120 petabyte di storage ad alta velocità, con Azure che ora sostiene circa il 58 per cento del carico della piattaforma, contro il 12 per cento di maggio.

GitHub Actions Ha Registrato Tredici Incidenti In Diciassette Giorni

Tech Times, analizzando la cronologia degli incidenti e i dati di stato di GitHub, ha riferito che GitHub Actions da sola ha registrato 13 incidenti distinti in un arco di 17 giorni questo agosto, e che la sua disponibilità su 90 giorni è scesa dal 99,39 per cento prima del blackout del 17 agosto al 99,33 per cento dopo, un calo da circa 13 ore di inattività accumulata in tre mesi a circa 14,5 ore. Quella testata ha descritto l'incidente del 17 agosto come capace da solo di consumare quasi un intero anno di inattività consentita rispetto a un obiettivo di tre nove. Il rapporto di GitHub conta diversamente e definisce il 17 agosto il proprio secondo incidente significativo del mese dopo il guasto di Actions del 6 agosto, un conteggio corretto dei grandi blackout a livello di piattaforma, ma che non dice nulla sulle interruzioni di Actions più piccole e frequenti che restano sotto la superficie. Entrambi i conteggi possono essere veri insieme, e insieme descrivono un problema di affidabilità a due livelli: il servizio Git di base regge meglio della pipeline CI/CD costruita sopra di esso, ed è proprio quella pipeline a sostenere la maggior parte del nuovo carico dello sviluppo assistito dall'IA.

Una Piattaforma, Ogni Pipeline: Il Rischio Di Concentrazione

Per un'azienda che gestisce l'intero flusso di lavoro ingegneristico tramite GitHub, cioè controllo versione, CI tramite Actions, il proprio registro pacchetti e Copilot per la generazione di codice, nulla di tutto ciò è rumore di fondo; è un unico fornitore posizionato sul percorso critico di ogni rilascio. Un team di sviluppo europeo lo percepisce come uno statunitense durante la finestra stessa del blackout, ma porta con sé un ulteriore strato di esposizione: scadenze contrattuali di consegna, impegni di livello di servizio verso clienti UE e obblighi di segnalazione degli incidenti previsti da normative come NIS2 non si fermano perché il blackout è nato in un data center statunitense fuori dal controllo del team. Trattare 'GitHub è down' come rumore di fondo smette di avere senso non appena i numeri sottostanti mostrano perché è accaduto: un'infrastruttura costruita per un mondo più lento e scandito da ritmi umani ora assorbe uno schema di carico quasi raddoppiato in quattro mesi, su una piattaforma che, per sua stessa ammissione, ha passato agosto a risolvere due volte la stessa categoria di guasto di capacità.

Come Appare Davvero La Ridondanza

Nulla di tutto ciò è un argomento per abbandonare GitHub, che resta l'opzione predefinita per buone ragioni, ma è un argomento concreto per trattare la dipendenza da un unico fornitore come un rischio pianificato e non come un ripensamento scoperto a metà di un blackout. Questo significa mantenere una copia speculare dei repository critici su un secondo host o su un server Git autogestito, una configurazione alternativa di runner CI capace di prendere in carico le build quando Actions è degradato e non solo quando è completamente fuori uso, e una cache locale o autogestita per le dipendenze dei pacchetti, così che il blackout di un registro non fermi ogni build della pipeline. Nessuna di queste misure deve funzionare in modo continuo; devono esistere, essere testate ogni tanto ed essere documentate abbastanza bene perché un team sotto pressione durante il prossimo incidente non stia improvvisando una soluzione per la prima volta mentre l'orologio di una scadenza con un cliente continua a scorrere.

Da leggere ora: Il Vostro Secondo Host Git Si È Attivato Da Solo  |  L'Irlanda annulla il contratto con Microsoft