Postmortem-Bibliothek

GitHub: Enterprise Importer-Migrationen für über 5 Stunden unterbrochen

Am 28. Juli 2025 geriet GitHub Enterprise Importer (GEI) in einen fehlerhaften Zustand, sodass Migrationen für über fünf Stunden unterbrochen wurden. Die Ursache war eine Infrastrukturänderung, die neue IP-Adressen erforderlich machte. In diesem Bericht: Ursachenanalyse, getroffene Maßnahmen, Kundenkommunikation und Learnings – inklusive konkreter Handlungsempfehlungen für Teams.

Unternehmen & Produkt

GitHub betreibt die weltweit größte Entwicklerplattform. Das betroffene Produkt, GitHub Enterprise Importer (GEI), ist GitHubs hochpräziser Migrationsdienst für Repositories, Organisationen und deren Kollaborationshistorie (Pull Requests, Reviews, Kommentare) – aus Quellen wie GitHub Enterprise Server, Bitbucket und Azure DevOps in die GitHub Enterprise Cloud.

Was war passiert?

Am 28. Juli 2025 um 21:41 UTC fiel GEI in einen fehlerhaften Zustand. Migrationen konnten nicht mehr verarbeitet werden. Eine Fehleranalyse ergab, dass eine GEI-Komponente im Rahmen interner Verbesserungen außer Betrieb genommen wurde und nicht in ihre vorherige Konfiguration zurückversetzt werden konnte. Neue Infrastrukturressourcen mussten bereitgestellt werden. Dabei wurden neue IP-Bereiche eingeführt, die Kunden in IP-Zulassungslisten freischalten mussten.

Timeline

  • Anfang: Montag, 28. Juli 2025, 21:41 UTC – GEI im beeinträchtigten Zustand, Migrationen gestoppt
  • Ende / Wiederherstellung: Dienstag, 29. Juli 2025, 03:15 UTC – Dienst nach Bereitstellung neuer Ressourcen wiederhergestellt
  • Dauer: 5 Stunden, 34 Minuten
  • Erkennung & Eskalation: Der Bericht enthält das Zeitfenster des Vorfalls, gibt jedoch weder die Zeit bis zur Erkennung noch den Zeitstempel der Meldung an.

Betroffene Kunden

Unternehmen und Organisationen, die während des Zeitfensters Migrationen mit GEI durchführten. Alle Kunden mit aktivierten IP-Zulassungslisten mussten ihre Konfiguration anpassen.

So reagierte GitHub

GitHub reagierte umgehend, untersuchte die Störung und konnte die Ursache auf eine Infrastrukturkomponente zurückführen, die im Rahmen routinemäßiger Änderungen entfernt worden war. Der Dienst wurde wiederhergestellt, indem neue Infrastrukturressourcen bereitgestellt wurden.

Nach dem Incident führte GitHub verschiedene Verbesserungen ein:

  • Maßnahmen zur Wiederherstellung von Infrastrukturkomponenten
  • Erweiterung von Unit-Tests
  • Bessere Validierung durch den Einsatz realistischer Testdaten vor Änderungen

Zudem kündigte GitHub neue GEI-IP-Bereiche an und empfahl Kunden, ihre IP-Zulassungslisten zu aktualisieren – sowohl für GitHub Organisationen/Enterprises als auch für Azure Blob Storage oder Amazon S3 (wenn bei Migrationen verwendet) sowie Azure DevOps.

So kommunizierte GitHub

  • Statusseite: GitHub informierte in Echtzeit über die öffentliche Statusseite.
  • Verfügbarkeitsbericht: Veröffentlichung eines Post-Incident-Berichts mit Timeline, Root Cause, Maßnahmen und Kundenanweisungen (Bericht vom Juli 2025).
  • Direkte Benachrichtigung: Per E-Mail an Nutzer, die in den letzten 90 Tagen Migrationen durchgeführt hatten – mit Hinweis auf notwendige IP-Listen-Updates.

Erkenntnisse & Maßnahmen für andere Teams

Sicherheitsmechanismen bei Infrastrukturänderungen

Eine routinemäßige Verbesserung der Infrastruktur führte dazu, dass eine kritische Komponente nicht verfügbar war – ohne dass die Möglichkeit zu einer schnellen Wiederherstellung bestand. Das macht deutlich, wie wichtig es ist, Änderungsstopps oder zusätzliche Genehmigungen speziell für Migrations- und Egress-Infrastruktur zu erzwingen. Ebenso sollten Canary- oder Blue-Green-Muster mit automatisierten Rollback-Mechanismen für Konfigurationsänderungen zum Einsatz kommen. Darüber hinaus ist es besonders wichtig, über Konfigurations-Snapshots zu verfügen, die sich mit einem Klick wiederherstellen lassen.

Validierung vor dem Rollout

Die Validierung vor der Bereitstellung sollte gestärkt werden, indem Unit-Tests ausgeweitet und Änderungen mit realistischen Testdaten durchgespielt werden. Es sollte verpflichtend sein, dass Pre-Flight-Checks und synthetische Migrationen in der Staging-Umgebung erfolgreich abgeschlossen werden, bevor ein Rollout erfolgt. Deployments sollten außerdem durch Richtlinienprüfungen abgesichert werden, etwa durch vorgeschriebene Test-Suites und klar definierte Erfolgsschwellen.

Vorbereitung auf Netzwerkabhängigkeiten (IP-Zulassungslisten & Speicher-Egress)

Die Wiederherstellung führte zur Einführung neuer Egress-IP-Adressen und zwang Kunden dazu, ihre Zulassungslisten kurzfristig zu aktualisieren. Das verdeutlicht, wie wichtig es ist, das Egress- und IP-Management zentral zu koordinieren, Änderungsfenster möglichst frühzeitig an Kunden zu kommunizieren, und die Pflege von Zulassungslisten per API über GitHub-Organisationen, Cloud-Speicher und DevOps-Tools hinweg zu automatisieren. Zusätzlich sollte ein Notfall-Runbook für dringende IP-Änderungen vorhanden sein.

Kurzfassung

Am 28. Juli 2025 um 21:41 UTC kam es zu einem Ausfall von GEI-Migrationen bei GitHub. Ursache: Eine Infrastrukturkomponente wurde entfernt und konnte nicht wiederhergestellt werden. Die Wiederherstellung erfolgte am 29. Juli um 03:15 UTC durch neue Ressourcen – dabei wurden neue GEI-IP-Bereiche eingeführt. Kunden mit IP-Zulassungslisten mussten diese aktualisieren. GitHub informierte über Statusseite, Verfügbarkeitsbericht und direkte E-Mail-Benachrichtigungen.

So kann ilert helfen, die Incident Response zu verbessern

  • Echtzeit-Alarmierung & Bereitschaftsmanagement. Vermeidung langer Ausfallzeiten, indem symptombezogene Signale (z. B. Stau in Migrationswarteschlangen, Job-Fehler) sofort die zuständigen Personen alarmieren – einschließlich automatischer Eskalationen.
  • Change Intelligence. Erfassung von Deployment- und Infrastrukturänderungen mit ilert, Korrelierung von Migrationsfehlern mit Änderungen und automatische Ursachenanalyse.
  • Stakeholder- und Kundenkommunikation. Veröffentlichung von Statusseiten-Updates mithilfe von KI direkt in ilert, um die Kommunikation schnell und korrekt zu gestalten.
  • Postmortems mit Maßnahmenverfolgung. Erstellung strukturierter Postmortems mit Verantwortlichkeiten für Follow-ups und Verfolgung der Maßnahmen bis zur erfolgten Durchführung.
Weitere Postmortems finden:
Bereit, dein Incident-Management zu verbessern?
Danke! Deine Einreichung ist eingegangen!
Hoppla! Beim Absenden des Formulars ist etwas schief gelaufen.
Unsere Cookie-Richtlinie
Wir verwenden Cookies, um Ihre Erfahrung zu verbessern, den Seitenverkehr zu verbessern und für Marketingzwecke. Erfahren Sie mehr in unserem Datenschutzrichtlinie.
Open Preferences
Danke! Deine Einreichung ist eingegangen!
Hoppla! Beim Absenden des Formulars ist etwas schief gelaufen.
Danke! Deine Einreichung ist eingegangen!
Hoppla! Beim Absenden des Formulars ist etwas schief gelaufen.