Google Cloud in crash per un campo vuoto. Tre ore.

Contenuto di questo video

• Un campo vuoto, un puntatore nullo, ogni regione
• Cronologia: 29 maggio → 17:45 → ciclo di crash → pulsante rosso → 17:52 Cloudflare
• us-central1: l'effetto gregge
• Meccanismo: controllo nel percorso di richiesta, replicazione globale, un fornitore
• git blame — la scissione

Trascrizione tradotta

Tradotto dalla narrazione originale inglese. L'audio e i sottotitoli disponibili sono controllati da YouTube.

Un campo vuoto, un puntatore nullo, ogni regione

0:00 Una riga di policy con campi vuoti causa un puntatore nullo, e Google Cloud va in crash in ogni regione contemporaneamente — e Cloudflare cade con esso, poi chiama Google "un provider di terze parti". 12 giugno 2025, 17:49 UTC. Il rapporto di Google: Service Control, il binario che approva ogni richiesta API, in un ciclo di crash per tre ore. Quello di Cloudflare, la stessa sera: Workers KV, il novanta percento fallisce, due ore ventotto.

0:23 Come è successo, perché un campo vuoto è diventato globale in pochi secondi, e chi riceve la colpa. Questo è The Daily Diff, postmortem. 29 maggio. Service Control ottiene un nuovo controllo di quota, rilasciato regione per regione con un

Cronologia: 29 maggio → 17:45 → ciclo di crash → pulsante rosso → 17:52 Cloudflare

0:35 pulsante rosso — ma il nuovo percorso di codice non viene mai eseguito durante il rollout; nulla lo attiva ancora. Nessun controllo null. Nessun feature flag. 17:45. Una modifica della policy con campi vuoti arriva nella tabella Spanner. La quota è globale, quindi la riga si replica ovunque in pochi secondi. Ogni binario di Service Control la legge, incontra il puntatore nullo, va in crash, si riavvia, la legge di nuovo. Ogni chiamata API: 503.

0:55 Google è veloce: triage in due minuti, causa radice in dieci. Il pulsante rosso è fuori in quaranta, e le regioni più piccole si riprendono per prime. La pagina di stato pubblica il suo primo aggiornamento con un'ora di ritardo, perché funziona su Google Cloud. 17:52. Il team WARP di Cloudflare vede nuovi dispositivi che non riescono a registrarsi. Workers KV, la metà dello store che Cloudflare usa per configurazione e identità, vive su un cloud di terze parti. Access fallisce ogni login — per design, fallisce chiuso.

1:20 Workers AI fallisce ogni inferenza. 19:11, Gergely Orosz: due cloud indipendenti giù contemporaneamente, mai visto prima. 19:32, il supporto Google dice a un utente che non ci sono interruzioni note — prova a cancellare i tuoi cookie. Ogni altro luogo si riprende entro le 19:48.

us-central1: l'effetto gregge

1:34 us-central1 no: i task di riavvio assalgono la stessa tabella Spanner, nessun backoff randomizzato, quindi Google li limita a mano. Due ore quaranta. Uno: il controllo della policy si trova all'interno del percorso di richiesta; quando il controllo muore,

Meccanismo: controllo nel percorso di richiesta, replicazione globale, un fornitore

1:46 l'API muore. Due: i dati di quota diventano globali senza staging; una riga errata è una riga globale. Tre: Cloudflare lo sapeva. Workers KV era in piena migrazione verso il suo R2, ridotto a un solo provider — il postmortem lo chiama una lacuna nella copertura.

git blame — la scissione

2:00 git blame. Google, cinquantacinque percento: nessun controllo null, nessun feature flag, nessun backoff — il loro rapporto dice che un flag l'avrebbe intercettato nello staging. Replicazione globale, venti: una riga, ogni regione, secondi. Cloudflare, venti: metà di una linea di prodotti su un negozio di un fornitore, e un postmortem che non dice mai Google. La pagina di stato, cinque, per vivere su ciò che riporta. Raggio d'impatto: settanta prodotti Google Cloud, dieci app Workspace,

Raggio d'impatto

2:23 ogni regione. Tre ore. Su Cloudflare: Access, WARP, Workers AI, Pages, Stream — due e mezzo. Hacker News, quattordici cento punti; commento principale: la pagina di stato è verde.

Verdetto + la linea del lunedì

2:33 Verdetto, postmortem: SHIP IT. Entrambi i postmortem arrivano entro trenta ore, entrambi si incolpano, e le correzioni di Google sono concrete: fail open, flag disattivati di default, backoff esponenziale. La linea del lunedì: nuovo codice dietro un flag che si disattiva, e un controllo null dove arrivano i dati. Inviami l'incidente di cui non ti è ancora permesso parlare, nei commenti, o a the daily diff dot dev. E questo è il diff per oggi.

2:53 Sono Niko di Axrisi. Merge responsibly.

Fonti

1. Google Cloud Service Health, Incident Report (Jun 13, 2025) + Mini Incident Report (Jun 12)status.cloud.google.com
2. Cloudflare, "Cloudflare service outage June 12, 2025" (Jun 12, 2025, 22:00 UTC)blog.cloudflare.com
3. Cloudflare Status, "Broad Cloudflare service outages" (18:19–21:31 UTC)www.cloudflarestatus.com
4. Gergely Orosz, 19:11 UTC, "Their infra is fully independent AFAIK"x.com
5. @Google support, 19:32 UTC, "there aren't any known service disruptions"x.com
6. Thomas Kurian (Google Cloud CEO), Jun 13 01:35 UTCx.com
7. Hacker News, "GCP Outage" (1,468 points)news.ycombinator.com
8. Hacker News, "Cloudflare was down" (341 points)news.ycombinator.com
9. Hacker News, "Google Cloud Incident Report – 2025-06-13" (209 points)news.ycombinator.com