GitHub gab bekannt, dass der Ausfall seiner Plattform am 17. August, der 7 Stunden und 47 Minuten dauerte, durch das Versagen einer kritischen Infrastrukturkomponente verursacht wurde, die bei einem Rekordverkehrsaufkommen in seinem Rechenzentrum in der zentralen Region der Vereinigten Staaten nicht ausreichend skaliert werden konnte. Der daraus resultierende Kapazitätsdruck führte dazu, dass sich die Probleme auf mehrere Systeme ausbreiteten. Betroffen waren github.com, die Authentifizierung, GitHub Actions, APIs, Pull Requests und Issues sowie Copilot. Die Auswirkungen des Ausfalls erstreckten sich auf Entwickler und Organisationen weltweit.
Der Vorfall war das zweite größere Ereignis, mit dem GitHub im August konfrontiert war, nach einem Ausfall von Actions am 6. August. Das Unternehmen erklärte, die Untersuchung habe keinen Zusammenhang zwischen einem der beiden Vorfälle und einer Änderung am Code oder an den Konfigurationen festgestellt. Der Kern beider Vorfälle sei vielmehr eine unzureichende Kapazität gewesen, da zentrale Komponenten nicht erweitert worden seien, bevor die Nachfrage ihre Kapazitätsgrenzen überschritt. Nach Angaben von GitHub stieg die Zahl der monatlichen Commits von 1,4 Milliarden im April auf 2,9 Milliarden seitdem. Das Unternehmen räumte jedoch ein, dass das Nutzungswachstum es nicht von seiner Verantwortung entbindet, Ausfälle zu verhindern.
Wie erholten sich die Dienste?
Die Wiederherstellung erforderte die Umleitung des Datenverkehrs, die Isolierung der betroffenen Infrastruktur und die schrittweise Wiederinbetriebnahme der Dienste. Die meisten GitHub-Dienste waren noch am selben Tag wieder verfügbar, doch einige Copilot-Dienste benötigten mehr Zeit. Fehler in diesen Diensten verursachten eine clientseitige Wiederholungsschleife, die während der Wiederherstellung zu zusätzlichem Datenverkehr führte. Daher mussten die Teams dieses Verhalten begrenzen, bevor sie den Datenverkehr sicher umleiten konnten.
GitHub zufolge enthält der vollständige Bericht zur Ursachenanalyse eine detaillierte technische Zeitleiste. Gleichzeitig setzt das Unternehmen die bereits angekündigten Verpflichtungen zur Verbesserung von Verfügbarkeit und Zuverlässigkeit weiter um.
Was ändert sich in der Praxis?
Der Plan von GitHub konzentriert sich auf die Erhöhung der Kapazität, die Steigerung der Effizienz und die Beseitigung architektonischer Engpässe. Das Unternehmen gab bekannt, mehr als 3 Millionen CPU-Kerne und 120 Petabyte Hochgeschwindigkeitsspeicher sowie zusätzliche Netzwerkkapazitäten hinzugefügt zu haben. Außerdem installierte es so viel Hardware wie innerhalb der verfügbaren Stromkapazität in seinen bestehenden Rechenzentren möglich war und beschleunigte parallel den Übergang zu Azure.
Azure verarbeitet derzeit rund 58 % der Last der GitHub-Plattform und die Hälfte der Git-Vorgänge, verglichen mit 12 % der Plattformlast im Mai. Diese Erweiterung half auch dabei, das Wachstum der Ausführungen von GitHub-Actions-Aufgaben zu unterstützen. Das Unternehmen arbeitet an einer neuen Architektur, um die Lesekapazität in sehr großen Repositorys linear mit der Zahl der Leser zu skalieren und theoretisch unbegrenzte Lesevorgänge zu ermöglichen. Die schrittweise Einführung soll in den größten Monorepositories beginnen.
Begrenzung des Ausfallumfangs und Verhinderung von Laststürmen
GitHub ist nicht der Ansicht, dass eine Skalierung allein ausreicht. Das Unternehmen hat zusätzliche Teams und Ressourcen auf die Verfügbarkeit ausgerichtet und in robustere Tests, sicherere Bereitstellungsprozesse, eine bessere Überwachung und wirksamere Warnmeldungen investiert. Außerdem isoliert es kritische Systeme und entfernt gemeinsame Abhängigkeiten zwischen ihnen, um die Wahrscheinlichkeit eines Ausfalls zu verringern und dessen Auswirkungen im Falle eines Eintretens zu begrenzen.
Auf Grundlage der Vorfälle vom 6. und 17. August wird das Unternehmen einheitliche Grenzen und Budgets für Wiederholungsversuche sowie variable Zeitüberschreitungen bei der Kommunikation zwischen Diensten einführen, um Wiederholungsstürme und kaskadierende Lasten zu verhindern. Zudem überprüft es Warnmeldungen mit niedriger Priorität zu CPU und Arbeitsspeicher, um Komponenten zu erkennen, die bei plötzlichen Anstiegen des Datenverkehrs ausfallen könnten. Diese Maßnahmen sind für Entwickler und Organisationen, die beim Erstellen, Ausliefern und Betreiben von Software auf GitHub angewiesen sind, von unmittelbarer Bedeutung. Denn die Erholung der Plattform besteht nicht nur in der Wiederherstellung des Dienstes, sondern auch darin, eine Wiederholung des Ausfalls zu verhindern und seinen Umfang im Falle eines erneuten Auftretens zu begrenzen.