Zusammenfassung

  • GitHub ergänzte den Vorfall qcvjkzcs7j74 am 11. August substanziell; die eigentliche Beeinträchtigung dauerte vom 6. August, 15:05 Uhr UTC, bis zum 7. August, 00:14 Uhr UTC.
  • Auf dem Höhepunkt erlitten 71 Prozent der Workflow-Läufe Infrastrukturfehler; 75 Prozent des verbleibenden Teils warteten länger als fünf Minuten.
  • Der Austausch von Pods während eines Routine-Deployments legte eine vorhandene Kapazitäts- und Nebenläufigkeitsschwäche frei und löste eine Kaskade über mehrere Cluster aus.
  • Mehr Kapazität, gedrosselte webhook-ausgelöste Eingänge und höhere Rückstandsverarbeitung stellten die erste Stufe wieder her.
  • Ein latenter Zuweisungsfehler ließ Runner ungültige Jobs erneut anfordern; einige ARC Runner brauchten manuelle Hilfe und manche Ereignisse konnten nicht automatisch nachgespielt werden.
  • Die angekündigten Schutz- und Wiederherstellungsmaßnahmen sind erst dann belastbare Kontrollen, wenn ihre Auslieferung und Wirkung nachgewiesen sind.

Der spätere Bericht verändert den Störungszeitraum nicht

Actions war am 7. August wiederhergestellt. Der 11. August markiert die Veröffentlichung von Ursache, Wirkungsmessung und Gegenmaßnahmen. Er ist kein zweiter Ausfall und verlängert den ersten nicht.

Zwei getrennte Uhren machen sowohl die technische Wiederherstellungszeit als auch die Verzögerung bis zur öffentlichen Erklärung sichtbar.

71 und 75 Prozent haben unterschiedliche Nenner

Die 71 Prozent beziehen sich auf alle Läufe mit Infrastrukturfehlern. Die 75 Prozent gelten nur für die übrigen 29 Prozent und messen Verzögerungen von mehr als fünf Minuten. Beide Werte dürfen weder addiert noch als Prozentpunkte desselben Ganzen gelesen werden.

Die Trennung zeigt dennoch zwei Kontrollfälle: ein expliziter Fehlschlag benötigt eine Wiederholungsentscheidung, eine lange Warteschlange eine Termin- und Zustandsprüfung.

Das Deployment verbrauchte seine eigene Reserve

Der betroffene interne Dienst verarbeitet Ereignisse und erzeugt Actions-Jobs. Als Pods ersetzt wurden, reichte die verbleibende Flotte nicht aus. Sättigung und Abstürze weiteten sich auf mehrere Cluster und nachgelagerte Dienste aus.

Kapazitätsplanung für Änderungen muss deshalb mehr als den normalen Spitzenverkehr abdecken. Vorübergehend entfernte Instanzen und der entstehende Rückstau treffen gleichzeitig auf dieselbe Reserve.

Mehr Durchsatz behob den ungültigen Zustand nicht

GitHub erweiterte Kapazität, drosselte neue webhook-ausgelöste Arbeit und beschleunigte die Bearbeitung des Rückstands. Danach wurde sichtbar, dass Runner Jobs erhielten, die nicht mehr gültig waren, und deren Erwerb wiederholt versuchten.

Erst eine Änderung gegen diese Schleife ließ gültige Arbeit weiterlaufen. Die Queue war damit nicht nur ein Mengenproblem, sondern auch ein Problem verlässlicher Job-Identität.

Ein Teil der Wiederherstellung blieb Handarbeit

Eine Zwischenmaßnahme ließ einige Actions Runner Controller Runner hängen; sie mussten manuell wiederhergestellt werden. Bestimmte push- und pull-request-Ereignisse wurden nicht verarbeitet und konnten nicht automatisch wiederholt werden.

Kunden mussten daher prüfen, ob sie einen Trigger erneuern, einen Workflow manuell starten oder zunächst einen Runner reparieren. Der Anbieterstatus beantwortet diese Repository-Frage nicht.

Die angekündigte Prävention ist noch ein Prüfprogramm

GitHub nennt stärkere Deployment- und Kapazitätssicherungen, frühere Überwachung, robustere Queues und Zuweisung, Kaskadenbegrenzung sowie automatische Runner-Wiederherstellung. Diese Punkte passen zur veröffentlichten Fehlerkette.

Offen bleiben Versionen, Schwellenwerte, Rollout und Erfolgsmetriken. Erst nachprüfbare Releases oder ein späterer Belastungsfall zeigen, ob die Verteidigung wirkt.

Ein kundeneigenes Ausführungsbuch schließt die Lücke

Organisationen können erwartete Ereignisse, Run-IDs, Endzustände und erzeugte Artefakte abgleichen. So finden sie ausgefallene Trigger, ohne verspätet erfolgreiche Arbeit doppelt auszuführen.

Die grüne Statusanzeige belegt die aktuelle Plattformverfügbarkeit. Der lokale Abgleich belegt, dass jeder während der Störung erwartete Prozess einen vertrauenswürdigen Abschluss erhalten hat.

Quellen