Am 17. August erlebte GitHub einen 7 Stunden und 47 Minuten andauernden Ausfall. Der Ausfall beeinträchtigte github.com, die Authentifizierung, GitHub Actions, APIs, Pull Requests, Issues und Copilot und wirkte sich auf Entwickler und Organisationen auf der ganzen Welt aus. Wenn Sie an diesem Tag versucht haben, Software zu veröffentlichen, haben wir Sie im Stich gelassen.
Dies war nach dem Ausfall von Actions am 6. August unser zweiter bedeutender Vorfall im August. Im März und April hatte ich über unsere Arbeit zur Verbesserung der Zuverlässigkeit von GitHub berichtet. Wir haben Fortschritte erzielt, aber diese Vorfälle machen deutlich, dass wir diese Arbeit beschleunigen müssen.
Was ist passiert?
Unsere Untersuchung hat ergeben, dass der Ausfall begann, als der Datenverkehr einen neuen Höchststand erreichte und eine kritische Infrastrukturkomponente in unserem Rechenzentrum in der Mitte der USA nicht entsprechend skalieren konnte. Der daraus resultierende Kapazitätsdruck breitete sich auf unsere Systeme aus, führte zu Authentifizierungsfehlern und beeinträchtigte mehrere GitHub-Dienste.
Für die Wiederherstellung waren mehrere koordinierte Schritte erforderlich. Die Teams leiteten den Datenverkehr um, isolierten die betroffene Infrastruktur und stellten die Dienste schrittweise wieder her. Die meisten GitHub-Dienste erholten sich noch früher an diesem Tag, bei einigen Copilot-Diensten dauerte es jedoch länger. Die Fehler in diesen Diensten lösten eine clientseitige Wiederholungsschleife aus, die den Datenverkehr während der Wiederherstellung erhöhte. Wir mussten dieses Verhalten zunächst abmildern, bevor wir den Datenverkehr sicher wiederherstellen konnten. Die umfassende Analyse der Grundursachen enthält eine detaillierte technische Zeitleiste.
Keine der beiden Ausfälle wurde durch eine Code- oder Konfigurationsänderung verursacht. Beide Vorfälle hatten ihre Ursache in unzureichender Kapazität. Wir konnten kritische Komponenten nicht skalieren, bevor sie die Kapazität der Nachfrage überschritten. Seit April ist die monatliche Zahl der Commits von 1,4 Milliarden auf 2,9 Milliarden gestiegen. Dieses Wachstum erklärt den Druck auf unsere Systeme, entschuldigt diese Ausfälle jedoch nicht.
Was wir getan haben und was als Nächstes ansteht
Als Teil unserer zu Beginn dieses Jahres eingegangenen Zuverlässigkeitsverpflichtungen konzentrierten wir uns auf drei Prioritäten: Kapazität hinzuzufügen, die Effizienz zu steigern und architektonische Engpässe zu beseitigen. Seitdem haben wir mehr als 3 Millionen CPU-Kerne, 120 Petabyte Hochgeschwindigkeitsspeicher und erhebliche zusätzliche Netzwerkkapazität hinzugefügt. In unseren bestehenden Rechenzentren haben wir weiterhin Hardware im Rahmen der verfügbaren Stromkapazität installiert und gleichzeitig unsere Migration zu Azure beschleunigt.
Heute bedient Azure etwa 58 % der Plattformauslastung von GitHub und die Hälfte aller Git-Vorgänge – gegenüber 12 % der Plattformauslastung im Mai. Diese erweiterte Infrastruktur unterstützt auch das Wachstum der in der folgenden Abbildung dargestellten Job-Ausführungen von GitHub Actions.
Die Infrastruktur und Kapazität von Azure haben auch unsere Bemühungen beschleunigt, die größten Monorepos zu skalieren. Unser nächster Meilenstein ist eine Architektur, die die Lesekapazität linear mit der Zahl der Leser skaliert und unbegrenzte Lesevorgänge ermöglicht.
Wir werden dies schrittweise einführen und mit den größten Monorepos beginnen.
Die Skalierung ist nicht die einzige Herausforderung, mit der wir konfrontiert sind. Mit zunehmender Geschwindigkeit und Komplexität der Veränderungen konnten unsere bestehenden Betriebsabläufe nicht Schritt halten. Wir haben Teams und Ressourcen auf die Verfügbarkeit ausgerichtet und in robustere Tests, sicherere Bereitstellungsprozesse, eine bessere Beobachtbarkeit und wirksamere Warnmechanismen investiert. Wir haben Fortschritte erzielt, aber diese Arbeit ist noch nicht abgeschlossen.
Darüber hinaus isolieren wir kritische Systeme voneinander und beseitigen die gemeinsamen Abhängigkeiten zwischen ihnen. Diese Arbeit soll die Wahrscheinlichkeit eines Ausfalls verringern und seine Auswirkungen begrenzen, wenn es zu einem Ausfall kommt.
Wir lernen aus jedem Ausfall und nehmen unserem Arbeitsplan für die Verfügbarkeit neue Maßnahmen hinzu. Die Vorfälle vom 6. August und vom 17. August führten zu zwei dringenden Änderungen.
Erstens führen wir bei Interaktionen zwischen Diensten konsistente Grenzen für Wiederholungsversuche, Budgets für Wiederholungsversuche und variable Zeitüberschreitungen ein, um Wiederholungsstürme und Kaskadenlast zu verhindern. Zweitens überprüfen wir Warnungen zu CPU und Arbeitsspeicher mit niedriger Priorität, um Komponenten zu identifizieren, die bei plötzlichen Verkehrsspitzen ausfallen könnten.
Unser Bekenntnis zu hoher Verfügbarkeit ist nicht nur ein technisches Versprechen.