Een server-side wijziging bij Google heeft ertoe geleid dat wereldwijd talloze iOS-apps die de Firebase SDK gebruiken zijn gecrasht. Het incident legde ernstige tekortkomingen bloot in de validatieprocessen en monitoring van Firebase; het probleem werd pas opgemerkt na talloze meldingen van ontwikkelaars op GitHub, terwijl de officiële statuspagina urenlang geen incidenten rapporteerde. De outage duurde tussen de twee en zes uur en werd uiteindelijk opgelost door een rollback van de wijziging. Er is aanzienlijke kritiek op de engineering-standaarden van Google vanwege het gebrek aan interne detectie en communicatie.
Firebase SDK veroorzaakt wereldwijde crashes van iOS-applicaties
Oorzaak van het incident
Het probleem werd veroorzaakt door een wijziging aan de serverzijde van Firebase. Deze aanpassing leidde ertoe dat meerdere versies van de SDK begonnen te crashen. Volgens Orosz roept dit grote vragen op over de validatieprocessen binnen Google; het is onbegrijpelijk hoe een wijziging in productie kan worden doorgevoerd zonder dat deze vooraf is geverifieerd, aangezien de primaire functie van de SDK is om stabiel te werken.
Falende monitoring en incidentmanagement
Een opvallend aspect van dit incident is de trage reactie van het Firebase-team en het falen van hun interne monitoringsystemen:
- Detectie door community: Ontwikkelaars merkten de crashes op en maakten melding via de GitHub issue tracker. Vijay Tholpadi wees erop dat iOS-apps sinds de ochtend intermitterend crashten, wat deed denken aan het 'Facebook swizzling crash' incident.
- Gebrek aan interne monitoring: Ondanks de massale impact merkte de eigen monitoring van Firebase het probleem aanvankelijk niet op. Pas nadat er ongeveer 100 berichten op de issue tracker stonden, merkte een Firebase-ontwikkelaar het probleem op.
- Onbetrouwbare statuspagina: Zelfs vijf uur nadat het probleem bekend was, gaf de officiële statuspagina (
status.firebase.google.com) aan dat er geen incidenten waren.
Impact en herstel
De outage had een wereldwijde impact met een duur van twee tot zes uur, waarbij de duur afhankelijk was van of clients de foutieve server-payload hadden gecached.
Orosz noemt specifiek het voorbeeld van DoorDash, dat door de crashes hinder ondervond. Dit soort incidenten kan directe zakelijke gevolgen hebben, zoals het wegduwen van klanten naar concurrenten zoals UberEats.
Uiteindelijk is de server-side wijziging teruggedraaid (rollback), maar er is tot op heden geen communicatie verschenen op de statuspagina en er is geen belofte gedaan voor een post-mortem analyse.
Conclusie en kritiek
Het incident werpt een schaduw op de reputatie van Google wat betreft engineering-standaarden. De belangrijkste punten van kritiek zijn:
- Een backend-wijziging is doorgevoerd zonder schijnbare verificatie.
- Firebase heeft de outage niet zelf gedetecteerd.
- De statuspagina werd niet bijgewerkt, zelfs niet nadat het team intern had bevestigd dat er sprake was van een incident.
Firebase SDK veroorzaakt wereldwijde crashes van iOS-applicaties
Oorzaak van het incident
Het probleem werd veroorzaakt door een wijziging aan de serverzijde van Firebase. Deze aanpassing leidde ertoe dat meerdere versies van de SDK begonnen te crashen. Volgens Orosz roept dit grote vragen op over de validatieprocessen binnen Google; het is onbegrijpelijk hoe een wijziging in productie kan worden doorgevoerd zonder dat deze vooraf is geverifieerd, aangezien de primaire functie van de SDK is om stabiel te werken.
Falende monitoring en incidentmanagement
Een opvallend aspect van dit incident is de trage reactie van het Firebase-team en het falen van hun interne monitoringsystemen:
- Detectie door community: Ontwikkelaars merkten de crashes op en maakten melding via de GitHub issue tracker. Vijay Tholpadi wees erop dat iOS-apps sinds de ochtend intermitterend crashten, wat deed denken aan het 'Facebook swizzling crash' incident.
- Gebrek aan interne monitoring: Ondanks de massale impact merkte de eigen monitoring van Firebase het probleem aanvankelijk niet op. Pas nadat er ongeveer 100 berichten op de issue tracker stonden, merkte een Firebase-ontwikkelaar het probleem op.
- Onbetrouwbare statuspagina: Zelfs vijf uur nadat het probleem bekend was, gaf de officiële statuspagina (
status.firebase.google.com) aan dat er geen incidenten waren.
Impact en herstel
De outage had een wereldwijde impact met een duur van twee tot zes uur, waarbij de duur afhankelijk was van of clients de foutieve server-payload hadden gecached.
Orosz noemt specifiek het voorbeeld van DoorDash, dat door de crashes hinder ondervond. Dit soort incidenten kan directe zakelijke gevolgen hebben, zoals het wegduwen van klanten naar concurrenten zoals UberEats.
Uiteindelijk is de server-side wijziging teruggedraaid (rollback), maar er is tot op heden geen communicatie verschenen op de statuspagina en er is geen belofte gedaan voor een post-mortem analyse.
Conclusie en kritiek
Het incident werpt een schaduw op de reputatie van Google wat betreft engineering-standaarden. De belangrijkste punten van kritiek zijn:
- Een backend-wijziging is doorgevoerd zonder schijnbare verificatie.
- Firebase heeft de outage niet zelf gedetecteerd.
- De statuspagina werd niet bijgewerkt, zelfs niet nadat het team intern had bevestigd dat er sprake was van een incident.
Groetjes,