Che pasticcio, Cloudflare!
No, dai, scherziamo, sono cose che succedono, ma…

Il feature file è rigenerato ogni pochi minuti e distribuito velocemente a tutti i nodi globali perché il sistema di Bot Management possa aggiornare in tempo reale il suo modello di machine learning (chi è bot, chi non lo è). Quando la dimensione del file è raddoppiata per colpa dei duplicati, il modulo che lo legge ha oltrepassato il limite operativo e ha smesso di funzionare correttamente. Da lì è partita una cascata di errori 5xx: il core proxy non riusciva più a gestire il traffico che dipendeva da quel file.

Prince, uno degli ingegneri coinvolti, l’ha raccontata così: “All’inizio sembrava che il sistema si riprendesse, poi ricadeva di nuovo, era come inseguire un fantasma”. Per rendere il quadro ancora più confuso, la pagina di status ufficiale di Cloudflare, ospitata esternamente, era anch’essa irraggiungibile nello stesso intervallo, alimentando per un po’ il sospetto di un attacco esterno.

La timeline in breve

12:05 — modifica ai permessi del cluster ClickHouse (innesco).
12:20 — la configurazione alterata raggiunge abbastanza nodi da generare un impatto visibile: gli errori 5xx iniziano a crescere.
13:00 / 13:05 — interventi di mitigazione: bypass temporanei e rollback parziali cominciano a ridurre l’impatto.
Cosa si è rotto, praticamente L’effetto domino ha colpito molti pezzi dell’infrastruttura:

La CDN e i sistemi di sicurezza hanno cominciato a restituire pagine di errore dal core proxy, Turnstile (il controllo anti‑bot) non si caricava, Workers KV ha registrato un aumento delle risposte 5xx, la dashboard era accessibile solo a chi aveva già una sessione attiva, perché il login dipendeva da componenti non operativi, Email Security ha perso l’accesso ad alcune fonti di reputazione IP; alcune automazioni non hanno funzionato, Cloudflare Access ha fallito spesso nelle autenticazioni, bloccando l’accesso ad applicazioni protette.
A peggiorare le cose (come se tutto il resto non fosse già sufficiente) è arrivato l’aumento di latenza: i sistemi di debugging, cercando di raccogliere dettagli diagnostici, hanno generato carico aggiuntivo proprio nel momento peggiore.

Perché dovresti interessartene (anche se non usi Cloudflare)
Due lezioni semplici ma importanti:

Non serve un attaccante per farcela pagare cara: una modifica intenzionata a migliorare qualcosa può innescare un disastro se non ci sono limiti e controlli adeguati.
Dipendere da servizi esterni significa avere responsabilità: bisogna progettare pensando che anche il provider possa avere un brutto giorno.

Soluzioni pratiche (quelle che Digiup preferisce)

Smettiamo di parlare come se fossimo in un RFC e parliamo chiaro: ecco cosa possiamo fare per ridurre la probabilità di finire nelle stesse pastoie.

– Controllo rapido delle dipendenze: mappiamo i tuoi Single Points of Failure e ti diciamo subito cosa mettere dietro alla porta.
– Piani di fallback che funzionano davvero: multi‑CDN, backup DNS e failover testati, non slide eleganti.
– Regole semplici per i file di configurazione: limiti di dimensione, schemi di validazione e controlli pre‑deploy per evitare raddoppi magici dei file.
– Rotazioni credenziali senza drammi: gestione centralizzata dei segreti, rollout canary e separazione degli ambienti.
– Monitoraggio intelligente: alert non solo per “è giù?”, ma per segnali anomali (crescita incontrollata di file, spike di duplicati, latenza in salita).
– Esercitazioni pratiche: prove, simulazioni e qualche esercizio di chaos (ben controllato) così il team non si ritrova impreparato.

L’opinione di Digiup

Il blackout di Cloudflare ci ricorda che il cloud non è una divinità invulnerabile: è fatto di software, dati e persone che possono sbagliare. Meglio prevenire che correre ai ripari con il panico. Se vuoi un check veloce della tua resilienza, enza giri di parole e con consigli pratici, Digiup ti aiuta volentieri. Niente gergo inutile, solo risultati.