GitHub legte in seinem Verfügbarkeitsbericht für September 2026 zwei Vorfälle offen, die die Leistung seiner Dienste beeinträchtigten, während das Unternehmen Fortschritte bei der Neuverteilung der Infrastruktur und bei der Verbesserung der Belastbarkeit seiner Datenbanken machte. Das Unternehmen weist darauf hin, dass die Abhilfemaßnahmen noch nicht abgeschlossen sind, obwohl Änderungen umgesetzt wurden, die darauf abzielen, die Ausfallrisiken bei hoher Last oder beim Ausfall einer gemeinsamen Komponente zu verringern.
Bis zum 7. Oktober waren 120 von 160 Produktionsdiensten in der Region Central US bereitgestellt, während 13 von 51 primären MySQL-Datenbanken verlagert worden waren. Azure verarbeitete 65,4 % des Leseverkehrs der zentralen GitHub-Anwendung, 48,3 % des Git-Leseverkehrs und 80,2 % des Datenstromverarbeitungsverkehrs. Das Unternehmen betont, dass sich diese Prozentsätze auf unterschiedliche Lasten beziehen und nicht addiert werden sollten.
Fortschritte bei der Verlagerung der Infrastruktur, jedoch Verzögerung gegenüber dem Zeitplan
GitHub stoppte am 11. September Bereitstellungen und die Erhöhung des Datenverkehrs in Central US, da die Kapazität zwischen den Verfügbarkeitszonen unausgewogen war. Die dauerhaften Erhöhungen wurden am 18. September wieder aufgenommen, nachdem vorübergehend Kapazität bereitgestellt worden war. Die Arbeiten an der langfristigen Kapazität dauern jedoch an, mit dem Ziel, bis Ende Oktober die gesamte verfügbare Kapazität bereitzustellen. Das Unternehmen erreichte sein ehrgeiziges Ziel nicht, bis zum 30. September alle Produktionsdienste dort bereitzustellen.
Während einer geplanten Umstellung einer Datenbank führte eine automatisierte Notfallmaßnahme dazu, dass Datenbankreplikate in Central US getrennt wurden, was Kunden in der Region beeinträchtigte. GitHub deaktivierte diese Maßnahme während geplanter Übergaben, bis die Wiederherstellungsmechanismen verbessert worden sind.
Reduzierung der Datenbankbelastung und Eindämmung von Ausfällen
GitHub verlagerte 24 Tabellen des zentralen Authentifizierungssystems von seiner ältesten gemeinsam genutzten Datenbank weg. Dadurch wurden etwa eine Million Abfragen pro Sekunde von den Replikaten entfernt. Außerdem wurden etwa 980 Millionen nicht benötigte Datensätze aus der Änderungshistorie des Clusters gelöscht, das Issues und Pull Requests unterstützt. Dadurch wurden etwa 1,8 Terabyte an wiederherstellbarem Speicherplatz freigesetzt. Die Zahl der wöchentlichen Transaktionskonflikte sank im Vergleich zum Höchststand im Juni um etwa 77 %.
Die Hälfte des untersuchten Pull-Request-Verkehrs konnte bei einem Ausfall einer gemeinsamen Abhängigkeit mit eingeschränkter Funktionalität fortgesetzt werden. Die Weiterleitung des Datenbankverkehrs kann bei Spitzen außerdem automatisch Kapazität hinzufügen: Eine Gruppe wurde während eines Anstiegs der Pull-Request-Aktivität am 23. September von 14 auf 19 Replikate erweitert. GitHub fügte einen Mechanismus zur Laststeuerung hinzu, der es ermöglicht, Anfragen mit niedrigerer Priorität abzulehnen, bevor die Dienste eine umfassendere Auslastung erreichen.
Die beiden Vorfälle im September
Am 13. September führte eine Hintergrundaufgabe zur Datenbereinigung zu einer erhöhten Belastung einer gemeinsam genutzten Datenbank. Der Schutzmechanismus überwachte die Verzögerung der Replikate, jedoch nicht die auf dem Primärserver angesammelte Last, die das Limit der verfügbaren Verbindungen erreichte. Das Fehlen eines kurzen Abfrage-Timeouts führte dazu, dass Anforderungsverarbeiter warteten. Gleichzeitig sendete eine Wiederholungsschleife weiterhin fehlgeschlagene Schreibvorgänge. Der Vorfall dauerte eine Stunde und 28 Minuten und endete, nachdem die interne Last reduziert und die Aufgabe gestoppt worden war.
Am 28. September führte eine Änderung an dem Dienst, der Copilot-Code-Reviews ausführt, dazu, dass einigen Kunden eine eingeschränkte Version der Review-Ergebnisse statt der vollständigen Version mit Kommentaren gesendet wurde. Dadurch erschienen die Aufgaben als abgeschlossen, obwohl die Reviews in den Pull Requests nicht sichtbar waren. Der Vorfall dauerte 52 Minuten. GitHub behob ihn durch ein Zurücksetzen der Änderung und forderte die Kunden auf, die betroffenen Reviews erneut anzufordern.
Was ändert sich in der Praxis?
Die beiden Vorfälle zeigen, dass Kapazitätsverbesserungen allein nicht ausreichen. Die Zuverlässigkeit hängt auch davon ab, Ausfälle frühzeitig zu erkennen, unnötige Wiederholungsversuche zu stoppen und sicherzustellen, dass eine Aufgabe nicht als erfolgreich gemeldet wird, bevor ihre Ergebnisse tatsächlich zugestellt wurden. GitHub arbeitet daran, die Steuerung der Hintergrundverarbeitung zu erweitern, das Verhalten beim Start von Diensten zu verbessern sowie die Überwachung und Zustellung von Copilot-Code-Review-Ergebnissen zu stärken.
GitHub verzeichnete außerdem Verbesserungen an der Infrastruktur von GitHub Actions: Die gemessenen Redis-Operationen gingen um etwa 28 % und die relative Prozessorauslastung um etwa 30 % zurück. Eine separate Caching-Schicht reduzierte die von Redis genutzte Bandbreite um 84 %, die mittlere Antwortzeit um 66 %, die mediane Antwortzeit einer grundlegenden Bestandsabfrage um 96 % und die Zahl der wartenden Anfragen um 95 %. Offene Fragen betreffen weiterhin die Fähigkeit des Unternehmens, die Kapazitätsarbeiten abzuschließen und eine Wiederholung von Ausfällen gemeinsamer Abhängigkeiten unter realen Produktionsbedingungen zu verhindern.