Ende September stürzten weltweit iOS-Apps mit Firebase ab. Auslöser war eine einzige, geleerte Konfigurationszeile auf einem Backend-Server von Google. Die interessantere Geschichte beginnt danach: eine Statusseite, die grün blieb, eine Entwickler-Community, die die Ursache schneller fand als der Anbieter selbst, und ein Konzern, dessen Monitoring genau den Teil nicht erfasst, der die Kunden trifft.
Die Firebase-Störung traf praktisch jede iOS-App, die das Firebase-SDK mit aktivierter Analytics-Funktion eingebunden hatte. Beim Start stürzten diese Apps ab, reproduzierbar und weltweit. Für die betroffenen Teams war das kein Randproblem, sondern ein Totalausfall des eigenen Produkts, verursacht von einer Abhängigkeit, die man gewählt hatte, um sich weniger um Infrastruktur kümmern zu müssen. Der Autor des Newsletters The Pulse, Gergely Orosz, hat den Fall in einer Bonusausgabe aufgearbeitet und dabei vor allem das Incident-Management von Google kritisiert. Dieser Text stützt sich auf die öffentliche Zeitleiste im GitHub-Ticket, auf das vier Tage später veröffentlichte Postmortem und auf die dort dokumentierten Aussagen des Firebase-Teams.
Der Ablauf: von der ersten Meldung bis zum Rollback
Die Zeitleiste ist schnell erzählt. Gegen 17:41 Uhr pazifischer Zeit begann eine fehlerhafte Konfiguration, weltweit auf die Produktionsserver auszurollen. Apps, die diese Konfiguration beim Start abriefen, stürzten ab. Entwickler eröffneten daraufhin ein GitHub-Ticket, weil es sonst keinen Ort gab, an dem man sich hätte melden können. Auf diesem Ticket wiederholte sich der Satz „bei mir stürzt es auch ab“ in hunderten Varianten.
Eine Stunde und zehn Minuten nach Beginn des Ausfalls, um 18:51 Uhr, bestätigte ein Ingenieur des Firebase-Teams, dass man das Problem kenne. Um 19:24 Uhr begann der Rollback der schuldigen Backend-Änderung, rund fünfzig Minuten später war er abgeschlossen. Das klingt nach einer überschaubaren Reaktionszeit, täuscht aber: Weil viele Clients die fehlerhafte Antwort zwischengespeichert hatten, stürzten manche Apps noch bis zu sechs Stunden weiter ab, obwohl der Fehler längst behoben war.
Auffällig ist der Unterschied zwischen öffentlicher Wahrnehmung und interner Sicht. Im Postmortem schreibt das Team, es sei zwanzig Minuten nach dem Rollout durch Crash-Alarme und GitHub-Meldungen alarmiert worden. Warum es danach noch fünfzig Minuten dauerte, bis man sich öffentlich äußerte, bleibt offen. Wer einen Ausfall dieser Größe verantwortet, sollte die Zeit zwischen Erkennen und Kommunizieren genauso ernst nehmen wie die Zeit bis zum Fix.
Ein leeres Flag und die fehlende Prüfung im SDK
Die technische Ursache ist unspektakulär, gerade deshalb lohnt sie sich. Im Rahmen einer Routine-Bereinigung wurde ein alter, überflüssiger Konfigurationsschalter entfernt. Zurück blieb ein Eintrag ohne Namen, ein Wert der Länge null. Das Firebase-SDK auf iOS hatte keine Prüfung vorgesehen, ob der Name eines solchen Schalters überhaupt vorhanden ist, und stürzte beim Auslesen ab. Ein externer Entwickler hatte diesen Zusammenhang um 18:37 Uhr im Ticket benannt, also noch bevor Google den Ausfall offiziell bestätigte.
Man kann sich das wie einen Türsteher vorstellen, der jeden Morgen eine Aushangliste aus der Zentrale bekommt und sie laut vorliest: Name, Funktion, Zutritt ja oder nein. Solange alle Zeilen gefüllt sind, funktioniert das prächtig. Steht in einer Zeile aber nur ein Doppelpunkt ohne Namen, sollte er die Zeile getrost überspringen. Stattdessen stolpert er, und mit ihm jeder, der gerade durch die Tür will. Der Fehler lag nicht in der Zentrale allein, sondern in der Annahme, die Zentrale würde immer fehlerfreies Material liefern.
Google formuliert das im eigenen Postmortem erstaunlich klar: Backend-Datenanomalien sollten niemals einen Absturz auf der Client-Seite verursachen. Genau dieser Satz gehört über jeden Schreibtisch, an dem ein SDK entwickelt wird. Wer eine Bibliothek ausliefert, die millionenfach in fremden Apps läuft, darf sich nicht darauf verlassen, dass die Gegenseite wohlgeformte Daten schickt. Vertrauen ist keine Validierungsstrategie.
Die Statusseite blieb grün – und das ist das größere Problem
Während der gesamten Firebase-Störung zeigte die offizielle Statusseite alle Systeme in Ordnung. Kein Eintrag, keine gelbe Warnung, kein Vermerk im Nachgang. Die Begründung im Postmortem lautet, die Dashboards stützten sich vor allem auf serverseitige Gesundheitsmetriken und würden clientseitige Abstürze schlicht nicht erfassen. Technisch nachvollziehbar, als Antwort trotzdem dürftig.
Statusseiten existieren aus zwei Gründen: um Kunden während und nach einem Ausfall zu informieren und um Transparenz über die Stabilität des Dienstes herzustellen. Beides ist hier komplett ausgefallen. Wenn ein Vorfall, der praktisch alle iOS-Apps mit Firebase-Analytics zum Absturz bringt, keinen Eintrag auf der Statusseite rechtfertigt, welcher Vorfall sollte es dann tun? Für die betroffenen Teams war das der ärgerlichste Teil: Sie standen um 18 Uhr vor abstürzenden Apps und hatten keinen offiziellen Ort, an dem sie hätten nachlesen können, ob das Problem bekannt ist.
Immerhin hat Google angekündigt, SDK-bezogene Ausfallinformationen in die Status-Dashboards zu integrieren und den manuellen Aktualisierungsprozess zu verschlanken. Solche Zusagen sind notwendig, sie sind aber auch der einfachste Teil der Arbeit.
Das Postmortem kam vier Tage später – und fand keinen Weg auf die Statusseite
Am Freitag darauf veröffentlichte das Firebase-Team eine ausführliche Analyse im Blog. Sie beschreibt die Bereinigung des Altlast-Flags, den Beginn des Ausrollens um 17:41 Uhr und den fehlenden Null-Check im iOS-SDK. Inhaltlich ist das ein ordentliches Postmortem, eines, das Ursache, Ablauf und Lehren benennt. Der Autor von The Pulse merkt jedoch an, dass diese Analyse mehr als eine Woche später noch immer nicht auf der Firebase-Statusseite verlinkt war.
Das Muster kennt man aus vielen großen Organisationen: Verantwortung ist verteilt, und niemand fühlt sich für den letzten Meter zuständig. Die fehlerhafte Änderung kam aus dem Umfeld von Google Analytics. Der Absturz entstand im Firebase-SDK. Das Dashboard, auf dem der Vorfall im Hintergrund gelaufen sein soll, gehört zu Google Ads. Jede dieser Einheiten hat ihren Teil beigetragen, und keine hatte offensichtlich das Mandat, die Kommunikation nach außen zu übernehmen.
Auch der Kontrast zur Selbstdarstellung ist auffällig. Google hat den Begriff des Site Reliability Engineer geprägt und mit dem SRE-Buch einen Standard für Incident-Management gesetzt, an dem sich die Branche seit Jahren orientiert. Ein Unternehmen mit dieser DNA sollte in der Lage sein, eine Statusseite zu aktualisieren, während die eigenen Kunden ratlos auf GitHub diskutieren. Dass es nicht passiert ist, wiegt schwerer als der Programmierfehler selbst.
Nur iOS stürzte ab, Android nicht – und der Blick zurück nach 2020
Android-Apps blieben von der Firebase-Störung verschont, weil das dortige SDK robuster gebaut ist und das fehlende Flag nicht zum Absturz brachte. Das wirft eine naheliegende Frage auf: Warum vergleicht man die beiden Implementierungen nicht systematisch auf genau solche Unterschiede? Mit heutigen Werkzeugen ist der Abgleich zweier SDK-Codebasen deutlich einfacher als noch vor wenigen Jahren, und Firmen wie Shopify haben bei ihrer Rückkehr zu nativen Apps vorgemacht, wie so ein Abgleich aussehen kann. Ein entsprechender Punkt fehlt im Postmortem.
Wer sich an den Mai 2020 erinnert, kennt das Déjà-vu. Damals legte ein Fehler im Facebook-SDK Apps wie Spotify, TikTok und Pinterest lahm, weil ein Wert, der als Objekt erwartet wurde, plötzlich ein boolescher Wert war. Auch damals versammelten sich die Entwickler in einem GitHub-Ticket und fanden den Fehler selbst. Es gab Memes, um die Wartezeit zu überbrücken. Facebook rollte die Änderung schließlich zurück und teilte so gut wie nichts mit.
Der Unterschied ist der Maßstab. Bei Meta überrascht die schweigsame Reaktion wenig, Entwicklerwerkzeuge gehören dort nicht zur DNA. Bei Google Firebase darf man mehr erwarten, gerade weil das Produkt ausdrücklich an Entwickler adressiert ist. Dass die Aufarbeitung eines globalen Ausfalls nicht dort auftaucht, wo Kunden zuerst nachsehen, kostet Vertrauen.
Was du für deine eigenen Apps daraus mitnehmen kannst
Die praktische Lehre ist einfach: Behandle alles, was von außen in deine App kommt, als potenziell kaputt. Initialisiere ein SDK nicht bedingungslos beim Start, sondern kapsele den Aufruf so, dass ein Fehler nicht die gesamte Anwendung mitreißt. Teste deine Integrationen mit absichtlich fehlerhaften Antworten, mit leeren Feldern, mit falschen Typen. Und prüfe, ob du einen Schalter hast, um eine problematische Komponente zur Laufzeit stillzulegen, ohne ein Update auszuliefern, das erst durch die Review-Prozesse muss.
Fast genauso wichtig ist der eigene Blick aufs Monitoring. Wenn dein Nutzer eine weiße Fläche sieht und dein Dashboard Grün meldet, überwacht du den falschen Ort. Clientseitige Abstürze sind deine Frühwarnung, nicht die Servermetriken deines Anbieters. Wer eine App auf fremdem Fundament baut, braucht eine eigene Alarmanlage für das Haus, das darauf steht.
Und dann ist da noch die größere Frage. Der Firebase-Ausfall war technisch in wenigen Stunden behoben, die durch Caching verursachten Nachbeben inklusive. Wie viel Ausfallzeit und wie viel Schweigen ist akzeptabel bei einem Anbieter, dessen Wertversprechen genau darin besteht, dass man sich um solche Dinge nicht mehr kümmern muss? Die Antwort hängt nicht von der Größe des Anbieters ab. Sie hängt davon ab, ob er den letzten Meter geht, wenn es unangenehm wird.
Quelle: blog.pragmaticengineer.com
