Zusammenfassung
- Die Störung begann am 24. Juli um 16:04 Uhr UTC; GitHub ergänzte die Detailanalyse am 29. Juli um 02:36:25 Uhr UTC.
- In einer von drei physischen Zonen gingen die Verbindungen zwischen den Spine-Switches eines Cages und der Aggregationsschicht verloren.
- Nach dem Verlust von 25 Prozent der verfügbaren Interconnect-Kapazität sättigten sich die aktiven Restpfade.
- Zehn Prozent der Actions-Jobs scheiterten, 5 Prozent starteten verspätet, 27 Prozent der Issues-Interaktionen waren langsam oder liefen ab, und bei Copilot sowie git push waren jeweils 4 Prozent betroffen.
- GitHub wich auf Glasfaser für künftige Ausbauten aus, beendete den Paketverlust um 17:07 Uhr, stellte alle Pfade bis 17:36 Uhr wieder her und beschleunigt die Umstellung von 100 auf 400 Gbit/s.
Die veröffentlichten Prozentwerte sind keine Teile eines einzigen Ausfallmaßes. Sie beschreiben unterschiedliche Vorgänge. Gerade deshalb liefert der Bericht eine brauchbare Wiederherstellungslogik: Jede Nutzeraktion muss nach ihrem Zustand und ihren möglichen Nebenwirkungen behandelt werden.
Am 29. Juli kam der Befund, nicht eine zweite Störung
Der Diensteffekt trat am 24. Juli auf und der Eintrag wurde an diesem Tag geschlossen. Fünf Tage später ergänzte GitHub den Netzwerklayer, die verlorene Kapazität, Produktquoten, den Notpfad und den geplanten Umbau.
Eine Überschrift über einen Ausfall am 29. Juli würde eine nicht gemeldete Wiederholung erfinden. Auch andere GitHub-Vorfälle am 25. oder 27. Juli gehören nicht in diese Chronologie. Die offizielle Kennung yjysg0xrl67m setzt die Ereignisgrenze.
Offen bleibt der erste Auslöser. GitHub erklärt, dass Konnektivität verloren ging und danach die verbleibenden Pfade sättigten. Welches Gerät, welche Wartung oder welche Änderung den Verlust verursachte, steht nicht im Bericht.
Ein Cage, aber unterschiedliche Produktzustände
Jeder Compute-Cage besitzt eine Leaf-Spine-Struktur; seine Spine-Switches verbinden sich mit der Aggregation innerhalb der Zone. Nach dem Ausfall wurden Workloads in diesem Cage durch Paketverlust beeinträchtigt. Das Ereignis nahm ein Viertel der verfügbaren Interconnect-Kapazität weg.
Bei Actions scheiterten 10 Prozent der Jobs, weitere 5 Prozent begannen verspätet und waren erfolgreich. Bei Issues waren 27 Prozent der Interaktionen langsam oder liefen in ein Timeout. Vier Prozent der Copilot-Anfragen lieferten Fehler, obwohl die meisten automatisch wiederholt wurden. Vier Prozent der Pushes waren betroffen. Die Anmeldung wurde langsamer, blieb aber unter 1 Prozent Fehlern.
Diese Quoten haben andere Nenner und dürfen nicht addiert werden. Sie zeigen, wie Warteschlangen, Wiederholungsregeln, Schreibzustände und Latenzbudgets denselben Paketverlust unterschiedlich übersetzen.
Die Wiederherstellung nutzte Kapazität von morgen
GitHub leitete Verbindungen auf Glasfaserpfade um, die für künftige Kapazitätserweiterungen reserviert waren. Um 17:07 Uhr reichte die Kapazität wieder aus, um Paketverlust zu beseitigen. Um 17:16 Uhr zeigten die meisten Dienste volle Erholung. Um 17:36 Uhr waren alle Pfade hergestellt.
Die drei Marken sind nicht austauschbar. Netzreserve, Erholung der meisten Anwendungen und vollständige Topologie kamen nacheinander. Eine einzige Abschlusszeit würde diesen gestuften Verlauf verdecken.
Der Erweiterungspfad war eine wirksame Reserve. GitHub nennt jedoch weder die verbleibende Reserve während der Umleitung noch den Zeitpunkt, zu dem diese Glasfaser wieder als Notfalloption verfügbar war.
Vor einem Neustart muss der tatsächliche Zustand feststehen
GitHubs Dokumentation erlaubt die Wiederholung eines ganzen Workflows, aller fehlgeschlagenen Jobs oder eines bestimmten Jobs. Die Wiederholung verwendet Rechte des ursprünglichen Akteurs, Commit-SHA und Git-Referenz. Das erhält den Kontext, macht eine Veröffentlichung, Bereitstellung oder Datenmigration aber nicht automatisch idempotent.
Ein verspäteter Job kann nach dem Start eines neueren Laufs noch fertig geworden sein. Ein Push mit fehlender Antwort kann die entfernte Referenz bereits verändert haben. Eine Issues-Änderung kann trotz Client-Timeout gespeichert worden sein. Deshalb ist zuerst der entfernte Zustand zu lesen.
Automatische Copilot-Wiederholungen verringern sichtbare Endfehler, verbergen aber mögliche Erstversuchsprobleme. Auch weniger als 1 Prozent Anmeldefehler schließen schädliche Latenz nicht aus. Jede Gruppe braucht ihren eigenen Abschlussnachweis.
Vierhundert Gbit/s treffen den Mechanismus, beantworten aber nicht alles
Ältere Cages verwenden 100-Gbit/s-Schnittstellen. GitHub will den geplanten Wechsel auf 400 Gbit/s beschleunigen, um bei Verlust eines Pfads oder Geräts mehr Bandbreite in allen Fabric-Schichten zu behalten. Das reagiert direkt auf die beobachtete Sättigung.
Nicht veröffentlicht sind Zeitplan, Zahl alter Cages, Mindestreserve und akzeptierte Fehlerkombinationen. Eine viermal höhere Nennrate bedeutet nicht automatisch viermal höhere End-to-End-Resilienz. Erkennung, Isolation und erreichbare Krisenwerkzeuge bleiben ebenso wichtig.
Die sinnvolle Abnahme findet unter Fehlerbedingungen statt: Ein Cage verliert den Aggregationspfad, ohne dass die Restpfade sättigen, und der Alarm erreicht den Betrieb vor den Nutzersymptomen.
Netzwerk- und Transaktionsbilanz gemeinsam schließen
Kunden können Job-IDs sichern, entfernte Git-Referenzen prüfen, doppelte Issues-Mutationen suchen und ersten Fehler von Erfolg nach Wiederholung trennen. Sichere Wiederherstellung gleicht Auswirkungen ab, bevor Schreibvorgänge wiederholt werden.
GitHubs nächste Veröffentlichung sollte den ersten Auslöser, die Reserve nach der Umleitung, Umfang und Termin des 400-Gbit/s-Programms sowie die Isolationskontrollen nennen. Auch die Rückkehr der Ausbauglasfaser in den Reservebestand gehört dazu.
Der Bericht vom 29. Juli macht eine Cloud-Abhängigkeit physisch messbar: Ein Viertel der Verbindungskapazität verschwand, die übrigen Pfade füllten sich, und jedes Produkt hinterließ eine andere Aufräumliste.