Code Orange: Fail Small è stato completato. Il risultato è una rete Cloudflare più solida

Negli ultimi due trimestri e mezzo, abbiamo intrapreso uno sforzo ingegneristico intensivo, con nome in codice interno "Code Orange: Fail Small", volto a rendere l'infrastruttura di Cloudflare più resiliente, sicura e affidabile per ogni cliente.

All'inizio di questo mese, il team di Cloudflare ha completato questo lavoro.

Anche se il miglioramento della resilienza non dovrà mai essere un "lavoro finito" e sarà sempre una priorità assoluta lungo l'intero ciclo di vita del nostro sviluppo, i lavori che ci avrebbero evitato le interruzioni globali del 18 novembre 2025 e del 5 dicembre 2025 sono ora completati.

Questo lavoro si è concentrato su diverse aree chiave: modifiche di configurazione più sicure, riduzione dell'impatto dei guasti e revisione delle nostre procedure di emergenza e gestione degli incidenti. Abbiamo anche introdotto misure per prevenire gli scostamenti e le regressioni nel tempo e rafforzato il modo in cui comunichiamo ai nostri clienti durante un'interruzione.

In questo articolo, ti spieghiamo nel dettaglio cosa abbiamo messo in atto e cosa significa per te.

Cosa significa per te: nella maggior parte dei casi, le modifiche alla configurazione interna di Cloudflare non raggiungono più la nostra rete istantaneamente e vengono invece distribuite in modo progressivo con monitoraggio in tempo reale dell'integrità. Questo consente ai nostri strumenti di osservabilità di rilevare i problemi e risolverli prima che influiscano sul tuo traffico.

Per individuare potenziali distribuzioni pericolose prima che raggiungano l'ambiente di produzione, abbiamo identificato pipeline di configurazione ad alto rischio e creato nuovi strumenti per gestire meglio le modifiche alla configurazione.

Per i prodotti che operano sulla nostra rete di elaborazione del traffico dei clienti e ricevono le modifiche alla configurazione, non distribuiamo più tali modifiche istantaneamente su tutta la rete. Invece, i team pertinenti hanno adottato una metodologia di "distribuzione mediata dall'integrità", la stessa che utilizziamo per il rilascio del software, per tutte le distribuzioni di configurazione. Ciò include, a titolo esemplificativo, i team di prodotto che sono stati direttamente interessati dagli incidenti.

Elemento centrale del cambiamento è un nuovo componente interno denominato Snapstone, che abbiamo creato per trasferire la distribuzione mediata dall'integrità alle modifiche alla configurazione. Snapstone è un sistema che racchiude le modifiche di configurazione in un pacchetto, quindi consente di rilasciare gradualmente la modifica di configurazione con i principi di mediazione dell'integrità. Prima di Snapstone, applicare questa metodologia alla configurazione era possibile ma complicato. Richiedeva un notevole impegno per ogni singolo gruppo e non veniva applicato in modo coerente nella rete. Snapstone colma questa lacuna offrendo un sistema unificato per fornire distribuzione progressiva, monitoraggio dell'integrità in tempo reale e rollback automatico alle distribuzioni di configurazione per impostazione predefinita.

Ciò che rende particolarmente potente Snapstone è la sua flessibilità. Anziché offrire una soluzione a problemi specifici passati, Snapstone consente ai team di definire dinamicamente qualsiasi unità configurativa che richieda una mediazione dell'integrità, sia che si tratti di un file dati come quello che ha causato l'interruzione del 18 novembre, sia che si tratti un flag di controllo nel nostro sistema di configurazione globale, come quello coinvolto nell'interruzione del 5 dicembre. I team creano queste unità di configurazione su richiesta e Snapstone si assicura che vengano distribuite in modo sicuro in qualsiasi luogo vengano utilizzate.

Questo ci offre qualcosa che prima non avevamo. In altre parole, quando una verifica dei rischi o un'esperienza operativa identifica uno schema di configurazione pericoloso, la soluzione è semplice: viene importato in Snapstone e questo erediterà immediatamente la distribuzione sicura. 

Cosa significa per te: nel caso in cui venga rilevato un problema nella nostra rete, i nostri sistemi ora si interrompono in modo più graduale. In questo modo, si riduce notevolmente il potenziale raggio d'impatto, per garantire che il traffico venga distribuito anche nello scenario peggiore possibile.

I team di prodotto hanno esaminato attentamente, sia in modalità manuale che programmatica, le loro potenziali modalità di guasto per i prodotti che sono fondamentali per gestire il traffico dei clienti. I team hanno rimosso le dipendenze runtime non essenziali e implementato modalità di guasto migliori. D'ora in poi utilizzeremo l'ultima configurazione valida nota laddove possibile ("fail stale") e, qualora non fosse possibile, abbiamo analizzato ogni caso di guasto implementando le modalità "fail open" o "fail close", a seconda che sia preferibile servire il traffico con funzionalità ridotte piuttosto che interromperlo del tutto.

Esaminiamo un esempio di come funziona. Il disservizio di novembre 2025 è stato innescato da un errore nell'implementazione del nostro classificatore di machine learning per il rilevamento Bot Management. In base alle nostre nuove procedure, se fossero stati generati nuovamente dei dati non leggibili dal nostro sistema, il sistema si sarebbe rifiutato di utilizzare la nuova configurazione e avrebbe utilizzato la configurazione precedente. Se la configurazione precedente non fosse disponibile per qualsiasi motivo, il sistema andrebbe in fail open, in modo da garantire che il traffico di produzione dei clienti continui ad essere servito, un esito decisamente migliore rispetto ai tempi di inattività.

Di conseguenza, se ora venisse applicato lo stesso aggiornamento di Bot Management che ha causato l'interruzione del servizio a novembre, il sistema rileverebbe il problema già nella fase iniziale della distribuzione, prima che abbia interessato più di una piccola percentuale di traffico.

Abbiamo inoltre iniziato a segmentare ulteriormente il nostro sistema in modo che le copie indipendenti dei servizi vengano eseguite per gruppi diversi di traffico. Cloudflare già oggi utilizza queste coorti di clienti per la mitigazione dell'impatto dei guasti con tecniche di gestione del traffico, e questo ulteriore lavoro di segmentazione dei processi ci fornisce una potente capacità di affidabilità per il futuro.  

Ad esempio, il sistema di runtime di Workers è suddiviso in più servizi indipendenti che gestiscono diversi gruppi di traffico, con uno che gestisce solo il traffico per i nostri clienti con un piano gratuito. Le modifiche vengono distribuite in questi segmenti sulla base delle coorti di clienti, a partire dai clienti con un piano gratuito. Stiamo inoltre inviando aggiornamenti più rapidi e frequenti ai segmenti meno critici e a un ritmo più lento ai segmenti più critici.

Di conseguenza, se una modifica venisse distribuita nel runtime di Workers e interrompesse il traffico, ora riguarderebbe solo una piccola percentuale dei nostri clienti con un piano gratuito prima di essere rilevata automaticamente e interrotta.

Prendendo ad esempio il runtime del sistema Workers, in sette giorni all'inizio del mese, il processo di distribuzione è stato attivato più di 50 volte. Puoi vedere come ciascuna di esse avvenga a "ondate" quando la modifica si propaga fino all'edge, spesso in parallelo rispetto ai rilasci precedenti e successivi:

Siamo impegnati a estendere questo modello di distribuzione a molti altri dei nostri sistemi in futuro.

Cosa significa per te: se si verificasse un incidente, disponiamo degli strumenti e dei team necessari per comunicare in modo più chiaro e per risolverlo più rapidamente, riducendo al minimo i tempi di inattività.

Cloudflare viene eseguita su Cloudflare. Utilizziamo i nostri prodotti Zero Trust per proteggere la nostra infrastruttura, ma questo crea una dipendenza: se un'interruzione a livello di rete influisce su questi strumenti, perdiamo proprio i percorsi di cui abbiamo bisogno per risolverli. Prima di questa iniziativa Code Orange, i nostri percorsi di emergenza erano limitati a un numero limitato di persone e offrivano un accesso limitato agli strumenti. Abbiamo bisogno che questi strumenti e questi percorsi siano più ampiamente disponibili durante un’interruzione.

Per risolvere questo problema, abbiamo eseguito una valutazione completa degli strumenti essenziali per la visibilità, il debug e le modifiche alla produzione nei sistemi. Abbiamo infine sviluppato percorsi di autorizzazione di backup per 18 servizi chiave, supportati da nuovi script e proxy di emergenza.

Durante il programma Code Orange, siamo passati dalla teoria alla pratica. Dopo esercitazioni di team di piccole dimensioni, abbiamo condotto una simulazione a livello di ingegneria il 7 aprile 2026, coinvolgendo oltre 200 membri del team. Sebbene l'automazione mantenga funzionali questi percorsi, esercitazioni come queste garantiscono che i nostri ingegneri abbiano gli automatismi necessari per utilizzarli sotto pressione.

Questo impegno si concentrava anche sul flusso di informazioni. Quando la visibilità interna è interrotta, la nostra risposta agli incidenti rallenta e la nostra capacità di comunicare con il mondo esterno ne risente. Storicamente, le osservazioni tecniche a caldo non si sono tradotte sempre in aggiornamenti chiari per i nostri clienti.

Per colmare questo divario, abbiamo istituito un team di comunicazione dedicato per lavorare a stretto coordinamento con i team di risposta agli incidenti durante gli eventi più importanti. Proprio come i nostri ingegneri hanno esercitato le proprie procedure di emergenza, questo team ha utilizzato il programma Code Orange per esercitarsi nella semplificazione della cadenza e della chiarezza degli aggiornamenti per i clienti. Grazie alla garanzia di avere sia gli strumenti per monitorare che la struttura per comunicare, possiamo risolvere gli incidenti più rapidamente e informare meglio i nostri clienti.

Cosa significa per te: ricorderemo gli insegnamenti dei nostri incidenti e abbiamo codificato le risoluzioni. La nostra rete diventerà solo più resiliente.

Per evitare deviazioni e reintrodurre regressioni al lavoro svolto nel contesto dell'iniziativa Code Orange nel tempo, il team ha creato un Codex interno che consolida tutte le nostre linee guida in regole chiare e concise.

Il Codex è ora obbligatorio per tutti i team di ingegneri e prodotto ed è diventato una parte centrale delle procedure interne di Cloudflare. Le regole sono applicate tramite revisioni del codice basate sull'IA che evidenziano automaticamente qualsiasi istanza che potrebbe divergere dalle linee guida, richiedendo ulteriori revisioni manuali. Questo viene applicato senza eccezioni all'intera base di codice. L'obiettivo è semplice: creare una memoria istituzionale che si applichi da sé.

I problemi di novembre e dicembre hanno condiviso una modalità di guasto comune: il codice presupponeva che gli input sarebbero sempre stati validi, senza un ripristino funzionale quando tale ipotesi veniva meno. Un servizio Rust ha chiamato .unwrap() invece di gestire un errore; il codice Lua ha indicizzato un oggetto inesistente. Entrambi i modelli possono essere evitati se le lezioni vengono apprese e applicate.

Codex è parte della nostra risposta. Si tratta di un repository vivente di standard ingegneristici redatto da esperti del settore tramite il nostro processo RFC (Request For Comments), poi distillato in regole pratiche. Le best practice che in precedenza risiedevano nella mente degli ingegneri senior o che venivano scoperte solo dopo un incidente, ora sono una conoscenza condivisa accessibile a tutti. Ogni regola segue un formato semplice: "Se hai bisogno di X, usa Y" con un link alla RFC che spiega perché.

Ad esempio, ora una RFC afferma: "Non utilizzare .unwrap() al di fuori dei test e di build.rs." Un altro principio più ampio afferma: "I servizi DEVONO verificare che le dipendenze a monte siano nel loro stato previsto prima dell'elaborazione".

Se queste regole fossero state applicate in precedenza, le interruzioni di novembre e dicembre sarebbero state merge request rifiutate anziché incidenti globali.

Le regole non applicate diventano semplici suggerimenti. Il Codex si integra con agenti basati sull'IA in ogni fase del ciclo di vita dello sviluppo del software (dalla revisione del progetto alla distribuzione e all'analisi degli incidenti). Questo anticipa l'applicazione delle regole a monte (shift-left), da "interruzione globale" a "merge request rifiutata". Il raggio d'azione di una violazione si riduce da milioni di richieste interessate a un unico sviluppatore che riceve un feedback fruibile prima che il suo codice raggiunga la produzione.

Il Codex è un documento in costante evoluzione e sarà continuamente perfezionato nel tempo. Gli esperti di dominio scrivono le RFC per codificare le best practice. Gli incidenti segnalano lacune che diventeranno nuove RFC. Ogni RFC approvata genera regole Codex. Queste regole alimentano gli agenti che rivedranno la merge request successiva. È come un volano: la conoscenza diventa uno standard, lo standard diventa un'applicazione concreta, e l'applicazione concreta innalza il livello qualitativo di base per tutti.

Cosa significa per te: la trasparenza è importante per noi. Se qualcosa va storto, ci impegniamo a inviare aggiornamenti continui in ogni fase del processo, in modo che tu possa concentrarti su ciò che conta per te.

I disservizi a livello globale ci hanno spinto a rivedere i nostri processi principali e i nostri approcci culturali anche al di là dell'ingegneria e dello sviluppo di prodotti. Nell'ambito delle più ampie iniziative Code Orange, abbiamo introdotto ulteriori obiettivi di livello di servizio (SLO) per tutti i nostri servizi, imposto un changelog globale, incorporato tutti i team nel nostro sistema di coordinamento della manutenzione e migliorato la trasparenza all'interno dell'azienda per eliminare il backlog dei ticket di "prevenzione" degli incidenti. 

Abbiamo anche migliorato il modo in cui comunichiamo con i nostri clienti durante un'interruzione. Il nostro obiettivo è avvisarti di un problema nel momento in cui lo confermiamo, prima ancora che tu te ne accorga. Al momento della notifica di un ritardo o di un errore, il nostro obiettivo è avere già un aggiornamento in attesa nelle tue notifiche.

Durante un incidente attivo, ora forniamo aggiornamenti a intervalli prevedibili (ad esempio, ogni 30 o 60 minuti), anche se l'aggiornamento consiste semplicemente in "Stiamo ancora testando la correzione. Nessuna nuova modifica per ora". Questo ti consente di organizzare la tua giornata invece di aggiornare costantemente una pagina dello stato.

Il nostro lavoro non termina quando si ripristina il normale stato operativo. Forniamo dei post mortem dettagliati in cui illustriamo cosa e perché è accaduto e, infine, quali cambiamenti strutturali attuiamo per evitare che si ripeta nuovamente.

Prendiamo questi incidenti molto sul serio e attuiamo una responsabilità condivisa in tutta l'organizzazione di Cloudflare ponendo a ogni team la stessa domanda: cosa si sarebbe potuto fare meglio? Questo ha guidato il lavoro che abbiamo svolto negli ultimi due trimestri.

Anche se questo lavoro non sarà mai davvero concluso, siamo certi di essere in una posizione ben superiore e che Cloudflare sia ora molto più forte per questo.