Il 17 agosto, GitHub ha subito un’interruzione durata 7 ore e 47 minuti. L’interruzione ha compromesso github.com, l’autenticazione, GitHub Actions, le API, le pull request, le issue e Copilot, colpendo sviluppatori e organizzazioni in tutto il mondo. Se quel giorno stavate cercando di distribuire software, vi abbiamo lasciati a metà strada.
Questo è stato il nostro secondo incidente significativo di agosto, dopo il guasto di Actions del 6 agosto. A marzo e ad aprile avevo condiviso il lavoro che stavamo portando avanti per migliorare l’affidabilità di GitHub. Abbiamo fatto progressi, ma questi incidenti dimostrano chiaramente che dobbiamo accelerare questo lavoro.
Che cosa è successo
La nostra indagine ha rilevato che l’interruzione è iniziata quando il traffico ha raggiunto un nuovo picco e un componente infrastrutturale critico nel nostro data center degli Stati Uniti centrali non è riuscito a scalare per tenere il passo. La pressione sulla capacità che ne è derivata si è propagata ai nostri sistemi, causando errori di autenticazione e compromettendo diversi servizi di GitHub.
Per il ripristino sono stati necessari diversi passaggi coordinati. I team hanno reindirizzato il traffico, isolato l’infrastruttura interessata e ripristinato gradualmente i servizi. La maggior parte dei servizi di GitHub si è ripresa prima quel giorno, ma alcuni servizi di Copilot hanno richiesto più tempo. Gli errori in questi servizi hanno attivato un ciclo di nuovi tentativi lato client che ha aumentato il traffico durante il ripristino. Prima di poter ripristinare il traffico in sicurezza, abbiamo dovuto mitigare questo comportamento. L’analisi completa delle cause principali include una cronologia tecnica dettagliata.
Nessuna delle due interruzioni è stata causata da modifiche al codice o alla configurazione. Alla base di entrambi gli incidenti c’era una capacità insufficiente. Non siamo riusciti a scalare i componenti critici prima che la capacità della domanda venisse superata. Da aprile, il numero mensile di commit è passato da 1,4 miliardi a 2,9 miliardi. Questa crescita spiega la pressione sui nostri sistemi, ma non giustifica queste interruzioni.
Cosa abbiamo fatto e cosa ci aspetta
All’inizio di quest’anno, nell’ambito degli impegni assunti per l’affidabilità, ci siamo concentrati su tre priorità: aggiungere capacità, aumentare l’efficienza ed eliminare i colli di bottiglia architetturali. Da allora abbiamo aggiunto più di 3 milioni di core CPU, 120 petabyte di storage ad alta velocità e una capacità di rete significativamente maggiore. Nei nostri data center esistenti, abbiamo accelerato anche la migrazione ad Azure, installando tutto l’hardware consentito dalla capacità energetica disponibile.
Oggi Azure gestisce circa il 58% del carico della piattaforma di GitHub e la metà di tutte le operazioni Git; questa percentuale è aumentata rispetto al 12% del carico della piattaforma a maggio. Questa infrastruttura in espansione ha inoltre sostenuto la crescita delle esecuzioni dei job di GitHub Actions mostrata di seguito.
L’infrastruttura e la capacità di Azure hanno accelerato anche il nostro lavoro per scalare i monorepo più grandi. Il prossimo traguardo è un’architettura che consenta di scalare la capacità di lettura linearmente rispetto al numero di lettori e renda possibili operazioni di lettura illimitate.
La implementeremo gradualmente, iniziando dai monorepo più grandi.
La scalabilità non è l’unica sfida che abbiamo dovuto affrontare. Con l’aumentare della velocità e della complessità dei cambiamenti, le nostre attuali pratiche operative non sono riuscite a tenere il passo. Abbiamo indirizzato team e risorse verso la disponibilità; abbiamo investito in test più rigorosi, processi di rilascio più sicuri, una migliore osservabilità e meccanismi di avviso più efficaci. Abbiamo fatto progressi, ma questo lavoro non è ancora concluso.
Inoltre, stiamo isolando i sistemi critici gli uni dagli altri e rimuovendo le dipendenze condivise tra loro. Questo lavoro è stato progettato per ridurre la probabilità che si verifichi un’interruzione e limitarne l’impatto quando si verifica.
Impariamo da ogni interruzione e aggiungiamo nuove attività al nostro piano di lavoro per la disponibilità. Gli incidenti del 6 agosto e del 17 agosto hanno portato a due cambiamenti urgenti.
In primo luogo, stiamo applicando limiti coerenti ai nuovi tentativi, budget per i nuovi tentativi e timeout variabili nelle interazioni tra i servizi, per prevenire tempeste di nuovi tentativi e carichi a cascata. In secondo luogo, stiamo rivedendo gli avvisi a bassa priorità relativi a CPU e memoria per individuare i componenti che potrebbero guastarsi durante improvvisi aumenti del traffico.
Il nostro impegno per un’elevata disponibilità non è soltanto una promessa tecnica.