Wereldwijde Google Cloud-storing kwam door gebrek aan 'flagprotection' - update

Google laat weten dat de recente wereldwijde storing van het cloudplatform veroorzaakt werd door een update zonder 'flagprotection'. Hierdoor kon een bug geïntroduceerd worden waardoor Googles clouddienst urenlang onbereikbaar was.

In het rapport over de storing van donderdag 12 juni schrijft Google dat de oorzaak aanvankelijk met een functie-update voor Service Control eind mei is geïntroduceerd. Dit onderdeel van Googles cloudplatform autoriseert en beheert api-verzoeken. Een probleem met een gedeelte van de code voor deze update werd toen echter niet geautomatiseerd opgemerkt omdat hiervoor een policy update nodig was.

De ingebouwde noodoplossing om de uitrol van dergelijke probleemcode te stoppen werkte ook niet goed en de update was niet flag protected. Dat laatste had ervoor moeten zorgen dat de code geleidelijk werd uitgerold, eerst intern en daarna naar de individuele regionale systemen. Google schrijft dat flagprotection het probleem vroegtijdig had kunnen voorkomen, maar dat dat niet is gebeurd.

Op 12 juni werd een update uitgerold naar Service Control. De update bevatte 'onbedoeld lege vlakken'. Het Service Control-systeem deed beroep op deze waarden en kwam daardoor in een crashloop terecht. Google claimt dat het managen van api-verzoeken van een wereldwijde aard is en dat de bug daarom 'binnen enkele seconden na de uitrol' wereldwijd regionale systemen deed crashen.

Volgens Google werd het probleem binnen enkele minuten opgemerkt en binnen veertig minuten zou er een bugfix beschikbaar zijn geweest. De storing duurde echter bijna drie uur. Het bedrijf geeft toe dat de crash- en herstartloop de lokale infrastructuren overbelastte, waarvoor geen voorzorgsmaatregelen getroffen waren. Hierdoor moest het bedrijf eerst problemen met de onderliggende serverinfrastructuur oplossen voordat de bugfix uitgerold kon worden.

Door het beschreven probleem waren volgens het rapport ruim tachtig diensten en functies van Google Cloud onbereikbaar. Niet alleen Googles diensten zelf werden getroffen. Omdat veel bedrijven gebruikmaken van de clouddienst van Google, waren ook partijen als Cloudflare, Spotify en IKEA niet of niet goed bereikbaar.

Update, 17.10 uur: De verwijzingen naar 'nullwaarden' zijn uit het artikel en de titel gehaald omdat deze mogelijk onjuist waren. Met dank aan Aftansert.

Reacties (34)

[SPee]

"flag protected" ==> feature flag of toggle ==> een stukje achter een if-code om te zorgen dat iets wel/niet uitgevoerd wordt. 'uit' is werking volgens de oude manier, 'aan' is werking volgens de nieuwe manier (of andersom).

En dat wordt vaak gebruikt om geleidelijk functionaliteit (veilig) naar productie te brengen. Ik heb in omgevingen gewerkt waar het de norm was om nieuwe functionaliteit via 'feature flags' te introduceren. Maar ik merkte ook vaak dat teams geen zin in hadden om voor een nieuwe feature zo'n 'feature flag' te introduceren. Het kost toch veel werk om dat te doen; Eerst een release om die flags toe te voegen. Daarna een release met die feature standaard uit. Later een release met de feature standaard aan. En uiteindelijk een release met opgeschoonde code. Daar gaat veel tijd tussen zitten en je moet beide scenario's ondersteunen en testen. Het is veel makkelijker en sneller om dat allemaal in één keer door te voeren. Teams hebben daar veelal geen zin in en gaan tegen die norm in. Totdat het een keer fout gaat.
Ik mag hopen dat hier consequenties aan zitten. Deze outage had voorkomen kunnen worden, als ze zich aan die standaard hadden gehouden.

[Bux666]

Eerst een release om die flags toe te voegen. Daarna een release met die feature standaard uit. Later een release met de feature standaard aan. En uiteindelijk een release met opgeschoonde code.

Dat zijn 4 stappen voor uiteindelijk 1 handeling: het toevoegen van nieuwe functionaliteit.
Ik zou zeggen: sla stap 1, 2 en 4 over en je bereikt precies hetzelfde.

[Luchtbakker]

Je zou toch zeggen dat zo iets als een verkeerd verwerkt API verzoek toch wel in een pre-productie omgeving te zien moet zijn?

[FreezeXJ]

Klopt, en dat ging hier dus mis als ik het bericht goed lees... Dit ging meteen naar productie, in plaats van eerst via de interne omgeving.
Zoals bekend, iedereen heeft een test-omgeving, en alleen geluksvogels hebben een aparte productie-omgeving

[AJM94]

Nog een stap daarvoor had eigenlijk vóór de merge naar main al een test moeten draaien of de flag protected wel aanwezig was.

Het "de update was niet flag protected." klinkt als een 'over het hoofd gezien' van een principe/afspraak.

[Jimbolino]

Ik vind het nog steeds onduidelijk waarom cloudflare down gaat, als google storing heeft.
https://blog.cloudflare.c...vice-outage-june-12-2025/
maakt het ook niet veel duidelijker

[SPee]

Die gebruikten een Google database service om verwijzingen op te zoeken.
En deden dat niet met een locale cache, waardoor de remote outage ook voor hun storing gaf.
Ze zullen er wel van geleerd hebben, dat ze te sterk afhankelijk zijn van Google en zullen hier vast iets aan doen om dit in de toekomst te voorkomen.

[cricque]

Wat gaan ze doen, alles zelf hosten ? Naar Azure overstappen of naar AWS ? In 10 jaar tijd heb ik 3x een issue gehad met Google Cloud en ik gebruik nogal wat dingen. Azure/AWS hoor ik constant mensen over klagen (ex collega's en vrienden) dat dit elke maand er wel eens uit ligt. Op 10 jaar 3x minder dan een uur last gehad noem ik helemaal niet slecht. Er zijn er genoeg die een pak minder halen. Kan het beter uiteraard, maar iedereen maakt wel eens een fout. Maar wat zijn de andere opties ? Maar het zou ook gewoon kunnen dat Cloudflare een paar dingen extra daar staan heeft zoals backups bijvoorbeeld, maar dit was dus een probleem niet in 1 zone maar globaal. Dus zelfs als je binnen dezelfde cloud backups had werkte niet alles. Maar voor mijn app bijvoorbeeld was het slechts een deel dat niet werkte. En er waren genoeg dingen die nog wel werkten. Dingen cross project of met IAM werkten dus niet zoals de storage bijvoorbeeld. Cloudflare kan GCP ook misschien gebruiken als log storage ... aan 0.05$ per gb helemaal niet zo duur en qua traffiek ken ik de prijs niet zo direct.

[jaapzb]

Kritieke infra redundant uitvoeren bij verschillende providers. Voor een HA service als cloudflare verrassend dat dat nog niet zo is, eigenlijk

[PaulHelper]

However, Workers KV today relies on a central data store to provide a source of truth for data. A failure of that store caused a complete outage for cold reads and writes to the KV namespaces used by services across Cloudflare.

Waar ze eerder zeiden dat dus de source of truth wel degelijk deels of volledig op GCP staat.

[cricque]

Het ding is op 10 jaar tijd is dit slechts de 3de maal dat er iets voor valt. De eerste maal was het een uur ofzo. 2de maal slechts 15 minuten. Ben nog altijd een tevreden gebruiker. Enja er kan altijd wat fout gaan. Er zijn genoeg diensten die er veel vaker uit liggen en waar veel meer problemen mee zijn

[jmb66]

Ik ben eveneens een tevreden gebruiker, deze storing heb ik zelfs niet gemerkt.
Het is knap hoe je storingen weet te plaatsen.
Ik krijg altijd een gevoel van machteloosheid, wanneer er tijdens het werk een storing plaatsvindt waar ik geen enkele invloed op heb.
Misschien heel erg vreemd, ook al werkt iets 25 jaar achter elkaar uitmuntend, bij de eerste storing krijg ik direct een unheimisch gefühl.

[Hatsieflatsie]

Dit is de tweede keer dat er een outage optreedt in Google Cloud, terwijl we 8 jaar lang op zitten, naast Azure.

Als je kijkt hoe vaak er een Azure outage is (jaarlijks), dan doet Google dit toch vele malen beter dan Microsoft.

[Viper1995]

Wat nemen jullie af in Azure? Zit zelf al vanaf 2018 in Azure en ik kan me niet echt een moment herinneren dat we zulke downtime hadden dat alles echt offline was.

[MPAnnihilator]

Palo Alto firewalls via de cloud zat er ook niet meer in toen. Lekker handig toch om alles in de cloud te zetten

[Aalard99]

Inderdaad, terwijl die een multi cloud oplossing hebben met als uitwijk AWS. Blijkt toch even dat het tijd kost om die aan te zetten.

[DutchEZmoder]

M'n NAS die ik hier lokaal heb staan met 2 HDD's lag er ook uit, toeval of wordt voor de verbinding ook Google Cloud gebruikt?

[jDuke]

Als je gebruikt maakt van Cloudflare WARP/tunnels dan lag dat er ook uit. Of de cloud leverancier die op Google Cloud leunde had ook problemen....

[Reactie gewijzigd door jDuke op 16 juni 2025 16:57]

[comatoast]

mss heb je een google-ip als primaire dns-resolver ? geen idee of die er ook uit lag maar dat is het eerste dat bij mij opkomt.

[maniak]

Ik ga toch anders kijken naar meldingen zoals deze. Grote techbedrijven zoals Microsoft (https://www.theregister.c...microsoft_meta_autocoding) presenteren vol trots dat steeds meer code geschreven wordt door AI. Ik ben bang dat we steeds vaker grote vage problemen gaan ondervinden.

[Stukfruit]

Dit soort problemen ontstaan doorgaans juist door fouten die komen vanuit een gebrek aan automatisering (wat "AI" is), dus het is vreemd om daar bang voor te zijn als het keer op door een mens wordt veroorzaakt

[Reactie gewijzigd door Stukfruit op 16 juni 2025 16:38]

[Tintel]

Dit soort problemen ontstaan doorgaans juist door fouten die komen vanuit een gebrek aan automatisering

Dat is een tikkie bijzonder opmerking; dit is allemaal automatisering. En storingen/fouten zijn uitzonderingen en die automatisch oplossen blijft moeilijk natuurlijk.
Er was zelfs een systeem dat automatisch had moeten voorkomen dat de storing groter werd....en jij stelt dat er een gebrek aan automatisering is.... tja, dan hadden ze dus een automatisch systeem moeten hebben dat inspringt als het andere automatische systeem faalt.... je ziet hopelijk toch dat dit ergens een keer misgaat?

En het punt van de huidige AI is: deze heeft geen context besef dus die zou dit inderdaad kunnen gaan doen: bijv. automatisch corrigeren tot het oneindige.

[Stukfruit]

dit is allemaal automatisering

Mooi verhaal, maar niet wat de officiële uitleg aangeeft:

On May 29, 2025, a new feature was added to Service Control for additional quota policy checks. This code change and binary release went through our region by region rollout, but the code path that failed was never exercised during this rollout due to needing a policy change that would trigger the code. As a safety precaution, this code change came with a red-button to turn off that particular policy serving path. The issue with this change was that it did not have appropriate error handling nor was it feature flag protected

De binary zal vast niet met de hand gebuild zijn, maar de "code change" + "a new feature was added" doet redelijk zwaar vermoeden dat het gewoon een mens was.

[Tintel]

"a new feature was added" doet redelijk zwaar vermoeden dat het gewoon een mens was.

Oh dat wel. Maar er wordt toch ook gezegd dat het automatische systeem dat dit soort fouten minder verstrekkend maakt, ook niet goed werkte.

[TheVivaldi]

Waarom zou dat falen? Vliegtuigen hebben doorgaans ook drie automatische piloten aan boord.

[Tintel]

Ik bedoelde meer dat je niet telkens safety systems kan maken die de vorige opvangen omdat de uitzondering dan steeds uitzonderlijker wordt en de onvoorspelbaarheid steeds verder toeneemt.

Volgens mij hebben vliegtuigen een ander systeem dan een dergelijke waterval; alledrie de systemen nemen de beslissing en 'de meeste stemmen gelden'.

[SPee]

Dit is juíst door een "menselijke fout" veroorzaakt!
Die hele "was niet flag protected" is eigenlijk "wij hebben deze feature niet achter een flag geïmplementeerd, omdat we geen zin hadden om hiervoor een specifieke 'feature flag' voor te gebruiken en deze over een langere periode in productie te brengen".
Kortom: luiheid, gemakzucht of andere menselijke eigenschap die heeft dit veroorzaakt.

[drfisheye]

Och, luiheid... Misschien was er wel een hele vergadering over geweest over die feature flag. Dubbele code bases beheren is net zo goed foutgevoelig en geeft inconsistent gedrag.

[drfisheye]

AI's als in LLM zijn bijna per definitie foutgevoelig. We weten niet eens hoe we kunnen bewijzen dat ze iets wel goed kunnen doen. Systemen die je niet begrijpt kan je niet vertrouwen, net als mensen. Dus daar zijn dan allerlei protocollen voor nodig om fouten te voorkomen. Net als bij mensen.

[Stukfruit]

Dat niet begrijpen zit 'm vooral in de uitkomst van modellen die op zichzelf wel begrepen worden.

Dus in het kort: dat zit in de gebruikte data en bv. het soort feature extraction. Als maker van zo'n model heb je daar de volledige controle over, in tegenstelling tot wat de marketeers roepen.

Als eindgebruiker inderdaad vaak niet, dat klopt

[noidea_2]

Niemand die hem even inkopt? Vooruit, dan doe ik het maar:

"Google platgelegd door een stel nullen"

[Yannick_Vink]

Sinds donderdagavond, toen de storing bij Google Cloud plaatsvond, merk ik – samen met meerdere mensen in mijn omgeving – dat de audiokwaliteit op YouTube en Spotify merkbaar is verslechterd ten opzichte van daarvoor.

Ik vermoed dat dit verband houdt met de storing bij Google Cloud.

Zijn er meer mensen die vergelijkbare problemen ervaren met de audiokwaliteit op deze platforms, of lijkt dit beperkt te zijn tot een specifieke regio?