GitHub CTO entschuldigt sich bei den Entwicklern nach einem der größten Ausfälle

Der Chief Technology Officer von GitHub, Vlad Fedorov, entschuldigte sich öffentlich bei den Entwicklern nach einem der schwersten Ausfälle der Plattform, der am 17. August sieben Stunden und 47 Minuten dauerte. Der Ausfall störte Kerndienste wie Authentifizierung, Aktionen, APIs, Pull-Requests, Probleme und Copilot, so dass viele Benutzer nicht auf essentielle Tools für ihre Workflows zugreifen konnten. Laut einem am 20. August veröffentlichten Blogbeitrag räumte Fedorov ein, dass das Problem eher auf eine grundlegende Skalierbarkeitsherausforderung als auf einen menschlichen Fehler zurückzuführen ist.

Er stellte fest, dass niemand fehlerhaften Code oder falsch konfigurierte Systeme verschoben hat, und das Problem entstand, weil die Plattform einfach keinen Platz mehr hatte, um beispiellose Verkehrsniveaus zu bewältigen. Die Ursache des Ausfalls wurde auf eine Autoscaling-Richtlinie zurückgeführt, die die falsche Metrik überwachte. Insbesondere konzentrierte sich die Richtlinie auf den Host-Service und nicht auf den Istio-Sidecar, der seine Konkurrenzgrenze erreichte. Dies führte zu einer Sättigung der Lastbalancer innerhalb des GitHub Central US-Rechenzentrums.

Als Ergebnis blieb der Copilot Token Service deutlich länger als andere Dienste offline. Ingenieure deaktivierten schließlich Gateway-Wiederholungen und begannen, HTTP 403-Fehler für eingehende Copilot-Token-Anfragen zurückzugeben. Zusätzlich erschwerten Scraping-Angriffe auf Codeload-Endpunkte den Wiederherstellungsprozess. Auf dem Höhepunkt des Ausfalls verzeichnete GitHubs Statusseite Fehlerraten von nahezu 20% für Web- und API-Verkehr und etwa 50% für Archive und Raw-Repository-Downloads. Die meisten Dienste wiederaufnahmen den normalen Betrieb um 1636 UTC, wobei Actions bis 1803 UTC wiederhergestellt wurde und der Copilot Token Service schließlich um 2102 UTC wieder online kam.

Die verlängerte Ausfallzeit hatte spürbare Auswirkungen auf Entwickler, die versuchten, Code bereitzustellen oder zu verwalten, insbesondere während einer Periode erhöhter Aktivität auf der Plattform. Fedorov hob hervor, dass das schnelle Wachstum von GitHub zu einem wichtigen Faktor für seine Zuverlässigkeitsprobleme geworden ist.

Als Reaktion darauf skizzierte GitHub mehrere geplante Korrekturen, darunter die Implementierung konsistenter Wiederholungsgrenzen, Wiederholungsbudgets und variabler Timeouts für Service-Interaktionen. Es plant auch, CPU- und Speicheralarme mit niedrigerer Priorität zu überprüfen und eine neue Architektur einzuführen, die die Lesekapazität proportional zur Anzahl gleichzeitiger Leser skalieren soll. Diese Änderungen werden zunächst auf die größten Monorepositories abzielen. Der Zeitpunkt dieser Entwicklungen fällt mit einem anderen Vorfall zusammen, der GitHub Anfang August betraf, als am 6. August eine Störung des Actions-Dienstes auftrat.

Während dieser Zeit startete Cursor eine frühe Beta-Version seines Origin Code Hosting-Produkts und nutzte die Nichtverfügbarkeit von GitHub aus.