Firebase: Konfigurationsbereinigung führt weltweit zum Absturz von iOS-Apps

Unternehmen und Produkt

Firebase ist die App-Entwicklungsplattform von Google, die unter anderem Funktionen für die Analyse und Remote-Konfiguration mobiler Apps bietet. Google Analytics for Firebase (GA4F) wird als SDK bereitgestellt, das Entwickler direkt in ihre Apps integrieren.

Das SDK verwendet Remote-Konfigurationsflags, die von Google-Servern bereitgestellt werden. Dazu gehören auch Flags, die Google als Kill Switches nutzt, um fehlerhafte Releases rückgängig zu machen.

Was war passiert?

Die Entwickler entfernten ein veraltetes Konfigurationsflag aus der serverseitigen GA4F-Konfiguration. Die Änderung umfasste lediglich zwei Codezeilen und alle bestehenden Tests verliefen erfolgreich. Allerdings wurde das Flag weiterhin vom iOS-SDK referenziert.

‍

Der Fehler entwickelte sich in vier Schritten:

1. Das Flag wurde serverseitig entfernt: Durch die Bereinigung entstand eine Konfiguration, in der ein vom SDK erwarteter Eintrag nicht mehr vorhanden war.
2. Die fehlerhafte Konfiguration wurde weltweit ausgerollt: Der Flag-Mechanismus dient Google selbst als Kill Switch, um fehlerhaftes SDK-Verhalten rückgängig zu machen. Dieser Mechanismus wird weltweit ausgerollt.
3. Das SDK validierte die Eingabedaten nicht: Beim Parsen der Konfiguration prüfte das SDK nicht, ob der Name eines Flags einen gültigen Wert hatte oder nil war. Das fehlende Flag löste einen schwerwiegenden Fehler aus, sodass die App beim Start abstürzte.
4. Auf jedem betroffenen Gerät kam es zu einem einmaligen App-Absturz: Betroffen waren aktive Nutzer, die die fehlerhafte Konfiguration abgerufen hatten. Danach griff das SDK auf die vorherige Konfiguration zurück. Die längerfristigen Auswirkungen betrafen nicht die Wiederherstellung, sondern die Fehlerberichterstattung: Absturzberichte wurden lokal zwischengespeichert und erst hochgeladen, wenn der Nutzer die App das nächste Mal erfolgreich öffnete.

Die eigentliche Ursache war eine Diskrepanz zwischen den Erwartungen von Server und Client: Während der Server das Flag als entfernbar behandelte, setzte der Client dessen Vorhandensein voraus. Die bestehenden Tests verliefen erfolgreich und keine der Prüfungen innerhalb der Bereitstellungspipeline erkannte die verbliebene Referenz.

Timeline

Alle Zeitangaben beziehen sich auf die Pacific Daylight Time (PDT), wie im Postmortem-Bericht von Google angegeben.

‍

28. September 2026

• 17:38 Uhr PDT: Ein veraltetes Konfigurationsflag wird aus der serverseitigen GA4F-Konfiguration entfernt.
• 17:41 Uhr PDT: Der Rollout der fehlerhaften Konfiguration auf die Produktionsserver beginnt. Apps, die diese Konfiguration abrufen, stürzen beim Start ab.
• 17:59 Uhr PDT: Die Crash-Alerts der Entwickler nehmen sprunghaft zu und auf GitHub erscheinen die ersten externen Fehlermeldungen. Das Bereitschaftsteam von Google wird benachrichtigt.
• 19:16 Uhr PDT: Das Incident-Response-Team führt die Abstürze auf die Bereinigung der Konfiguration zurück und leitet einen Rollback ein.
• 19:52 Uhr PDT: Der Rollback ist auf allen Produktionsservern abgeschlossen. Die fehlerhafte Konfiguration wird nicht mehr ausgeliefert.
• In den folgenden Stunden: Die Anzahl der gemeldeten Abstürze bleibt erhöht, da die Geräte die Absturzberichte zunächst lokal zwischenspeichern und erst beim nächsten erfolgreichen App-Start hochladen.

2. Oktober 2026: Google veröffentlicht seinen Postmortem-Bericht im Firebase-Blog.

‍

Time to Detect (TTD): etwa 18 Minuten (17:41 bis 17:59 Uhr). Laut Google erfolgte die Alarmierung innerhalb von 20 Minuten über verschiedene Kanäle. Der zeitliche Ablauf zeigt, dass die Crash-Alerts der Entwickler sprunghaft zunahmen und die ersten externen Fehlermeldungen über GitHub eingingen.

‍

Time to Resolve (TTR): 2 Stunden und 11 Minuten vom Beginn des Rollouts bis zum vollständigen Rollback (17:41 bis 19:52 Uhr). Den größten Teil dieser Zeit nahm die Fehlerdiagnose in Anspruch: Zwischen der Erkennung des Problems und der Identifizierung der verantwortlichen Änderung vergingen etwa 1 Stunde und 17 Minuten.

Wer war betroffen?

Google beschreibt die Auswirkungen als eine „große Anzahl von Anwendungen auf iOS und anderen Apple-Plattformen“, hat jedoch keine konkreten Zahlen veröffentlicht.

• App-Nutzer auf Apple-Plattformen: Bei aktiven Nutzern von Apps mit integriertem GA4F-SDK kam es während des Vorfalls zu einem einmaligen Absturz beim App-Start.
• App-Entwickler und ihre Bereitschaftsteams: Die Absturzraten stiegen bei zahlreichen voneinander unabhängigen Apps gleichzeitig sprunghaft an.
• Absturz- und Stabilitätsmetriken: Aufgrund der verzögerten Übermittlung der Absturzberichte blieb die Anzahl der gemeldeten Abstürze auch Stunden nach der Fehlerbehebung erhöht.

Laut Google wurden keine Geräte beobachtet, bei denen die Apps in eine dauerhafte Absturzschleife gerieten.

‍

Wie reagierte Google?

Nachdem die Techniker die Abstürze um 19:16 Uhr PDT auf die Bereinigung der Konfiguration zurückgeführt hatten, setzten sie die serverseitige Konfiguration auf den letzten als fehlerfrei bekannten Stand zurück. Um 19:52 Uhr PDT war der Rollback auf allen Produktionsservern abgeschlossen. Die Abstürze wurden damit gestoppt, ohne dass ein App-Update erforderlich war.

‍

Google kündigte Maßnahmen in vier Bereichen an:

1. SDK-Validierung: Ein innerhalb einer Woche geplanter GA4F-Patch soll die vom Server bereitgestellten Konfigurationsdaten strikt validieren. Fehlerhafte oder unvollständige Flags werden ignoriert und das SDK greift auf zwischengespeicherte Standardwerte zurück. Darüber hinaus will Google seine anderen iOS- und Android-SDKs auf ähnliche Schwachstellen bei der Verarbeitung von Konfigurationsdaten überprüfen.
2. Prüfungen in der Bereitstellungspipeline: Automatisierte Validierungen in den Konfigurationspipelines und Tests vor der Übernahme von Änderungen sollen verhindern, dass Änderungen mit verwaisten Bezeichnern oder fehlerhaften Abhängigkeiten übernommen werden.
3. Sicherere Rollouts: Google will den Bereitstellungsprozess für Konfigurationen verbessern, insbesondere durch eine optimierte Überwachung und eine schrittweise Einführung von Änderungen.
4. Statusmeldungen: Die Status-Dashboards sollen künftig auch SDK-spezifische Ausfälle anzeigen. Zudem soll die Aktualisierung der Statusmeldungen weniger manuelle Eingriffe erfordern.

Wie kommunizierte Google?

In seinem Postmortem-Bericht räumt Google offen ein, dass die Kommunikation unzureichend war.

• Die Status-Dashboards zeigten zu keinem Zeitpunkt eine Störung an: Sowohl das Firebase- als auch das Google Ads-Dashboard stützen sich hauptsächlich auf serverseitige Zustandsmetriken. Deshalb wurden die clientseitigen SDK-Abstürze nicht erfasst.
• Es gab keinen eigenen Statuseintrag: Das Firebase-Status-Dashboard verfügt über keine separate GA4F-Komponente und verweist stattdessen auf das Google Ads-Status-Dashboard. Die Aktualisierung beider Dashboards musste manuell erfolgen und dauerte mehrere Stunden.
• GitHub wurde zur inoffiziellen Statusseite: Da die Status-Dashboards keine zuverlässigen Informationen lieferten, veröffentlichte Google Updates im öffentlichen GitHub-Issue, in dem Entwickler die Abstürze zuerst gemeldet hatten.
• Hinweisbanner und nachträgliche Updates: Google fügte in der Firebase-Konsole ein Hinweisbanner hinzu und aktualisierte die Status-Dashboards am nächsten Morgen und Abend.

Die öffentlich verfügbaren Informationen bestätigen diese Darstellung allerdings nur teilweise. In der Firebase-Statushistorie ist für den 28. und 29. September kein Incident verzeichnet. Stattdessen wird bei Google-Analytics-Störungen auf das Google Ads-Status-Dashboard verwiesen. Dort ist ein Google-Analytics-Incident für den 28. September von 17:41 bis 19:52 Uhr PDT (29. September, 00:41 bis 02:52 Uhr UTC) dokumentiert. Dieser Zeitraum stimmt mit den Angaben im Postmortem-Bericht überein.

‍

Das erste Status-Update mit der Meldung „Wir untersuchen Berichte über ein Problem mit Google Analytics“ wurde am 29. September um 17:57 Uhr PDT (30. September, 00:57 Uhr UTC) veröffentlicht – etwa 22 Stunden nach der Fehlerbehebung. Dies deckt sich mit dem von Google erwähnten abendlichen Update. Ein Update vom Morgen ist hingegen nicht ersichtlich. In keiner der Statusmeldungen werden iOS, das SDK oder App-Abstürze erwähnt.

‍

Der vier Tage später veröffentlichte Postmortem-Bericht selbst ist dagegen ein gutes Beispiel für eine transparente Nachbereitung: Er enthält genaue Zeitangaben, erläutert die Fehlerursache und beschreibt konkrete Maßnahmen zur Vermeidung ähnlicher Vorfälle.

‍

Wichtige Erkenntnisse für andere Teams

• Konfigurationen wie Code und ihre Änderungen wie Deployments behandeln: Das Entfernen eines Flags durch eine Änderung von nur zwei Codezeilen hatte weltweite Auswirkungen. Konfigurationsänderungen erfordern dieselben sorgfältigen Code-Reviews, Tests in Staging-Umgebungen und Rollback-Verfahren wie die Bereitstellung von Binärdateien.
• Clients müssen die vom Server übermittelten Daten validieren: Ein SDK, das in die App eines Drittanbieters integriert ist, darf niemals aufgrund eines fehlenden oder fehlerhaften Datenfelds einen Absturz verursachen. Fehlerhafte Eingaben sollten ignoriert, zwischengespeicherte Standardwerte verwendet und der Fehler protokolliert werden.
• Vor dem Entfernen von Konfigurationselementen die Kompatibilität zwischen Server und Client prüfen: Bevor ein Flag gelöscht wird, muss sichergestellt sein, dass keine bereits veröffentlichte Client-Version mehr darauf zugreift. Einmal ausgelieferte mobile SDKs können über Monate oder Jahre auf den Geräten der Nutzer verbleiben.
• Auch Kill Switches benötigen eigene Sicherheitsmechanismen: Ausgerechnet über den Mechanismus, mit dem fehlerhafte Releases rückgängig gemacht werden sollen, wurde die fehlerhafte Konfiguration weltweit verteilt. Auch Notfallmechanismen erfordern eine schrittweise Einführung und entsprechende Validierungen.
• Änderungen schrittweise ausrollen – selbst wenn sie als sicher gelten: Ein Canary-Rollout für einen kleinen Teil der Clients hätte den Absturz wahrscheinlich frühzeitig aufgedeckt und die Auswirkungen erheblich begrenzt.
• Ein funktionierender Server bedeutet nicht automatisch, dass die Anwendungen für Nutzer funktionieren: Die Status-Dashboards zeigten keine Störung an, während die Apps abstürzten. Deshalb sollten Teams neben serverseitigen Metriken auch clientseitige Signale wie Absturzraten und SDK-Fehlertelemetrie überwachen.
• Statusseiten müssen den tatsächlichen Zustand widerspiegeln: Eine Statusseite, die während eines offensichtlichen Ausfalls keine Störung anzeigt, untergräbt das Vertrauen. Statusmeldungen sollten sich einfach aktualisieren lassen und auch clientseitige Fehlersignale berücksichtigen.

Kurzfassung

Am 28. September 2026 entfernte Google ein veraltetes Flag aus der serverseitigen Konfiguration von Google Analytics for Firebase. Da das iOS-SDK weiterhin auf dieses Flag zugriff und die Eingabedaten nicht validierte, stürzten Apps auf Apple-Plattformen nach dem Abrufen der neuen Konfiguration beim Start ab. Die fehlerhafte Konfiguration wurde weltweit 2 Stunden und 11 Minuten lang ausgeliefert, bevor ein Rollback erfolgte. Währenddessen zeigten die Status-Dashboards keine Störung an, da sie sich hauptsächlich auf serverseitige Zustandsmetriken stützen. Google kündigte strengere SDK-Validierungen, zusätzliche Prüfungen in den Bereitstellungspipelines, Verbesserungen beim schrittweisen Rollout von Konfigurationen und eine zuverlässigere Statuskommunikation an. Die wichtigste Erkenntnis für alle Teams: Konfigurationen sollten wie Code behandelt, Eingabedaten clientseitig validiert und die tatsächlichen Auswirkungen auf die Nutzer überwacht werden.

So kann ilert helfen

• Verknüpfung von Alarmierungen mit kürzlich vorgenommenen Änderungen: Durch die Verknüpfung von Alarmierungen mit Deployments und Konfigurationsänderungen erkennen die zuständigen Teams sofort, was sich geändert hat. Dadurch verkürzt sich die Zeit zwischen der Erkennung und der Feststellung der Ursache eines Incidents.
• Sicherstellen zuverlässiger Eskalationen: Dienstpläne und Eskalationsrichtlinien stellen sicher, dass die zuständigen Techniker innerhalb weniger Minuten per Push-Benachrichtigung, SMS oder Sprachanruf erreicht werden.
• Statusseiten aktuell halten: Mit ilert lassen sich Statusseiten innerhalb weniger Sekunden oder automatisch auf Basis von Incidents aktualisieren. So sehen Kunden während eines offensichtlichen Ausfalls keine Statusseite, die fälschlicherweise einen störungsfreien Betrieb anzeigt.
• Schnelle Einbeziehung von Ausfällen bei Drittanbietern in das Incident-Management: Wenn ein SDK oder ein Service eines Drittanbieters einen Ausfall der eigenen App verursacht, hilft ilert dabei, einen Incident zu erfassen, Stakeholder zu benachrichtigen und die Incident-Kommunikation zu koordinieren – selbst wenn die eigentliche Fehlerursache beim externen Anbieter liegt.
• Schnellere Fehleranalyse dank des integrierten AI SRE: Die Funktionen von ilert AI SRE unterstützen Incident-Response-Teams dabei, Alarmierungen, kürzlich vorgenommene Änderungen und relevante Kontextinformationen während eines Incidents zusammenzuführen und anschließend einen Postmortem-Bericht zu erstellen.