Il contesto: incidenti e crescita incontrollata
Nel periodo compreso tra maggio 2025 e aprile 2026, IncidentHub ha registrato 257 incidenti su GitHub, di cui 48 sono stati classificati come “panne majeure” e hanno comportato più di 110 ore di indisponibilità. Jay Parikh, vice‑presidente esecutivo del team CoreAI di Microsoft, ha riconosciuto in una keynote il 28 ottobre che la “crescita e l’ampiezza del fenomeno agentico” hanno contribuito alle difficoltà, ma ha sottolineato che “non può servire da scusa”.
Tra settembre 2025 e settembre 2026 il numero di push è salito a 17,9 miliardi, i commit a 34,3 miliardi, le pull request mergiate a 1,3 miliardi e i job di GitHub Actions a 45,4 miliardi. Per fare un confronto, nel 2024 i valori erano rispettivamente 5,2 miliardi di push, 10 miliardi di commit, 8 miliardi di job Actions e 402 milioni di pull request mergiate. In due anni l’interazione sulla piattaforma è triplicata, con un incremento fino a cinque volte per i job Actions.
Segnali premonitori e punto di svolta
I primi segnali di allarme si sono avvertiti a marzo 2025, ma è stato novembre 2025, con il rilascio dei modelli Claude 4.5 di Anthropic, a confermare la tendenza. Il vero punto di svolta è stato giugno 2026, quando gli sviluppatori hanno iniziato a utilizzare intensivamente gli agenti IA, i “harnais” e gli strumenti correlati. Da settembre 2026, più del 40 % delle pull request è generato da agenti, contro il 17 % di marzo 2026.
Espansione infrastrutturale: numeri e investimenti
Per far fronte al sovraccarico, GitHub ha potenziato drasticamente le proprie risorse nel 2026:
- 4 milioni di nuovi vCPU
- 160 pétaoctet di storage
- Rete potenziata a 50 Tb/s (6,25 To/s)
Non è chiaro se queste risorse siano state allocate esclusivamente nei data center di GitHub o se includano anche le capacità di Azure, ma Parikh ha confermato che la migrazione verso Azure è in corso.
La migrazione ha l’obiettivo di sostituire i data center tradizionali con due regioni cloud Azure negli Stati Uniti. Al momento, il 70 % del trasferimento è completato e dovrebbe terminare entro il primo semestre 2027, secondo Jakub Olesky, vicepresidente senior dell’ingegneria software di GitHub.
Strategia di migrazione “brownfield”
Per minimizzare le interruzioni, GitHub ha adottato una migrazione “brownfield”: l’architettura esistente è stata replicata e spostata su Azure, mantenendo una separazione geografica per la versione Enterprise europea.
GitHub Actions e GitHub Copilot, già ospitati su cloud Microsoft, non sono stati direttamente coinvolti nella migrazione. Tuttavia, hanno subito problemi a causa dell’interazione con componenti remoti, poiché il 58 % del carico di lavoro della piattaforma e la metà delle operazioni Git erano gestiti dal cloud di Microsoft.
Il collo di bottiglia: il sistema di replica Spokes
Il vero “colpevole” dei disservizi è stato il sistema di replica dei file, denominato Spokes. I repository sono memorizzati come blob e replicati cinque volte su dischi locali. Quando un push avviene, viene avviato un “protocollo di validazione in tre fasi” che usa un quorum per garantire coerenza tra CI, interfaccia web e API.
Il meccanismo di durabilità è lo stesso usato per la scalabilità: le copie su disco sono la fonte di verità. Aumentare la capacità di lettura implica aggiungere una replica durevole, ma tutte le repliche partecipano a ogni scrittura, rendendo la velocità dipendente dalla più lenta.
Le conseguenze sono evidenti:
- L’aggiunta di repliche per gestire la lettura rallenta le scritture.
- La perdita di una replica diminuisce la capacità di lettura.
- Se il quorum cade, le scritture si bloccano.
April Leonard, vicepresidente dell’ingegneria, ha spiegato che per i repository più richiesti, un ritardo di 25 ms tra i data center è critico. La scrittura su disco locale richiede 2 ms, mentre l’invio della quinta replica verso Azure ne richiede 25 ms, creando una coda di richieste di scrittura.
Nuova gestione delle scritture
Per mitigare il problema, GitHub ha modificato il lock a livello di repository: ora si blocca solo il ramo (branch) in aggiornamento, consentendo a più agenti di operare in parallelo su rami diversi. Questo ha aumentato il throughput di scrittura di 3‑4 volte, riducendo la saturazione della coda.
Separazione calcolo‑storage: verso Azure Blob Storage
La soluzione temporanea di lock per ramo è solo una tappa intermedia. Il prossimo passo è il “re‑platforming” completo, ispirato al modello S3 di Amazon. Azure Blob Storage gestirà automaticamente le repliche, separando il calcolo dallo storage.
Secondo Leonard, il codice sarà archiviato in modo durevole su Azure Blob Storage, che fungerà da fonte di verità. I server che rispondono alle richieste GET utilizzeranno una cache effimera per migliorare la velocità, mentre la piccola transazione di riferimento rimarrà sul percorso critico, gestita da un servizio di journaling replicato ottimizzato per la velocità.
Nel nuovo modello, lo storage object diventa membro del quorum, una replica virtuale. Un write è considerato valido solo quando è durabilmente memorizzato nello storage object, aggiungendo una leggera latenza ma evitando colli di bottiglia.
Replica virtuale e scalabilità futura
Le repliche di scrittura saranno virtualizzate su nodi effimeri, e GitHub prevede di distribuire “tante repliche virtuali di lettura quanto necessario” per soddisfare la domanda crescente. Questo approccio consentirà di scalare orizzontalmente senza dipendere da hardware fisico aggiuntivo.
In sintesi, la risposta di GitHub alla sovraccarico dell’IA agentica si articola in tre pilastri:
- Espansione immediata delle risorse computazionali e di rete.
- Migrazione verso Azure con una strategia brownfield per preservare la continuità.
- Riprogettazione dell’architettura di storage, introducendo Azure Blob Storage e repliche virtuali per separare calcolo e persistenza.
Con queste misure, GitHub intende non solo risolvere i problemi di disponibilità attuali, ma anche prepararsi a una futura era in cui gli agenti IA genereranno la maggioranza delle attività di sviluppo software.