Quando i Giganti Cadono: Outage Cloudflare e AWS

Analisi completa degli outage Cloudflare e AWS che hanno fermato internet. Scopri cosa succede quando i giganti del cloud cadono e come prepararsi ai major internet outage.

IN PRIMA PAGINARETI E INFRASTRUTTURE DIGITALICULTURA E FILOSOFIA DIGITALECYBERSECURITY E RESILIENZA DIGITALE

Network Caffè

11/27/202513 min leggere

Quando i Giganti Cadono:

Analisi degli Outage di Cloudflare e AWS che Hanno Fermato Internet

"Internet non dorme mai" — così si dice. Eppure, nel giro di poche settimane tra ottobre e novembre 2025, abbiamo assistito a qualcosa che sembrava impossibile: pezzi enormi di quel "sempre attivo" si sono semplicemente spenti. Prima Amazon Web Services, poi Cloudflare. Due incidenti separati, due cause diverse, ma un'unica, scomoda verità: l'infrastruttura che sostiene la nostra vita digitale è molto più fragile di quanto vogliamo ammettere.

Non parliamo di siti minori o servizi di nicchia. Parliamo di ChatGPT che smette di rispondere. Di X (ex Twitter) che mostra pagine di errore. Di Snapchat, Fortnite, Spotify, servizi bancari, piattaforme crypto — tutti caduti come tessere del domino. E mentre milioni di utenti fissavano schermi con il famigerato "Error 500", una domanda emergeva spontanea: come siamo arrivati a questo punto?

Questo articolo non è un bollettino di guerra digitale. È un'autopsia. Una ricostruzione meticolosa di cosa è andato storto, perché è andato storto, e soprattutto cosa ci dice questo sul futuro di Internet. Perché dietro ogni "Error 500" c'è una storia di codice, di architetture, di decisioni prese anni fa che tornano a presentare il conto.

1. L'Outage di Cloudflare: 18 Novembre 2025

1.1 Il Risveglio Brutale

Il 18 novembre 2025, alle 11:20 UTC, Cloudflare — uno dei pilastri invisibili di Internet — ha iniziato a restituire errori HTTP 500 a milioni di utenti in tutto il mondo. Per chi non mastica gergo tecnico, un errore 500 è il modo elegante che ha un server di dire: "Non so cosa sia successo, ma qualcosa è andato terribilmente storto."

La cosa paradossale? Anche Downdetector, il sito che monitora i disservizi internet, è andato giù. È come se l'ambulanza avesse bucato mentre correva all'emergenza.

1.2 La Portata dell'Impatto

L'elenco dei servizi colpiti legge come un Who's Who del web moderno:

Categoria | Servizi Impattati

Social Media ---> X (Twitter), Letterboxd

AI & Produttività ---> ChatGPT/OpenAI, Canva

Gaming ---> League of Legends, vari giochi multiplayer

Streaming ---> Spotify

Crypto ---> Arbiscan, DefiLlama, BitMEX, Toncoin

Finanza ---> PayPal, Uber Eats (pagamenti)

Comunicazione ---> HubSpot, Zoom (parziale)

E non dimentichiamo l'ironia suprema: la pagina di status di Cloudflare stessa è andata offline per un periodo, mostrando agli utenti un messaggio di errore che diceva "We can't connect to the server for this app or website at this time."

1.3 Timeline dell'Incidente

Ricostruiamo la cronologia dell'evento basandoci sul post-mortem ufficiale di Cloudflare:

Orario(UTC) Evento

11:05 Viene applicata una modifica ai permessi del database ClickHouse

11:20 Primi errori 5xx rilevati sulla rete Cloudflare

11:28 L'impatto raggiunge gli ambienti dei clienti

11:31-11:32 Test automatici rilevano il problema, inizia l'investigazione

11:35 Creata la war room per la gestione dell'incidente

11:48 Cloudflare pubblica il primo aggiornamento ufficiale

13:05 Implementato bypass per Workers KV e Access — impatto ridotto

13:37 Team focalizzato sul rollback del file di configurazione Bot Management

14:24 Fermata la creazione e propagazione di nuovi file di configurazione

14:30 File corretto distribuito globalmente — traffico principale ripristinato

17:06 Tutti i servizi completamente operativi

L'outage totale è durato circa 6 ore, con il picco di disservizio concentrato nelle prime 3 ore.

1.4 La Causa Tecnica: Quando un File Raddoppia di Dimensione

Ed eccoci al cuore del problema. La causa non è stata un attacco DDoS. Non è stato un hacker. Non è stata nemmeno una configurazione errata nel senso classico del termine. È stato qualcosa di molto più sottile e, per certi versi, più inquietante.

Il Sistema Bot Management

Cloudflare utilizza un sistema di Bot Management per distinguere il traffico umano da quello automatizzato. Questo sistema si basa su un modello di machine learning che analizza ogni richiesta che transita sulla rete. Per funzionare, il modello ha bisogno di un "feature file" — un file di configurazione che contiene le caratteristiche (features) usate per fare le predizioni.

Questo file viene aggiornato ogni pochi minuti e distribuito su tutta la rete globale di Cloudflare. La velocità è fondamentale: i bot malevoli cambiano tattica rapidamente, e il sistema deve adattarsi.

Il Bug nel Database ClickHouse

Il problema è iniziato con una modifica ai permessi del database ClickHouse che genera questo feature file. ClickHouse è un database analitico distribuito, organizzato in "shard" (frammenti). Le query vengono eseguite attraverso tabelle distribuite nel database "default", che a loro volta interrogano tabelle sottostanti nel database "r0".

Prima della modifica, gli utenti vedevano solo i metadati delle tabelle nel database "default". La modifica aveva lo scopo di rendere esplicito l'accesso alle tabelle in "r0" — una cosa sensata dal punto di vista della sicurezza e della tracciabilità.

Il problema? Una query nel sistema di generazione del feature file faceva così:

--------------------------------------------------

sql

SELECT name, type

FROM system.columns

WHERE table = 'http_requests_features'

ORDER BY name;

--------------------------------------------------------

Notate cosa manca? Il filtro sul database. La query non specificava quale database interrogare. Prima della modifica, restituiva solo le colonne dal database "default". Dopo la modifica, restituiva le colonne da entrambi i database — "default" e "r0" — raddoppiando effettivamente le righe nel risultato.

L'Effetto Domino

Il feature file, normalmente con circa 60 features, si è improvvisamente ritrovato con oltre 200 features (tutte duplicate). Ma il software che legge questo file aveva un limite hardcoded di 200 features — un limite posto per ragioni di performance e allocazione memoria.

Quando il file corrotto è stato propagato ai server, il codice Rust che lo processava ha fatto quello che un buon codice Rust fa quando incontra una condizione impossibile: panic. In termini non tecnici, il software ha alzato le mani e si è rifiutato di continuare.

-------------------------------------------------------

rust

thread fl2_worker_thread panicked: called

Result::unwrap() on an Err value

-----------------------------------------------------------------------

Il Comportamento Intermittente

Una cosa che ha reso particolarmente difficile la diagnosi: l'errore era intermittente. Il file veniva rigenerato ogni 5 minuti. Ma la modifica ai permessi era stata applicata gradualmente al cluster ClickHouse. Quindi, a seconda di quale nodo del cluster eseguiva la query, il file poteva essere corretto o corrotto.

Per diversi minuti, la rete oscillava tra funzionamento e fallimento, confondendo i team di risposta. Inizialmente, hanno persino sospettato un attacco DDoS di tipo Aisuru — una serie di attacchi che aveva colpito vari provider nelle settimane precedenti.

1.5 L'Impatto sui Servizi Cloudflare

ServizioTipo di ImpattoCore CDN e SecurityErrori HTTP 5xx per tutto il trafficoTurnstileImpossibile caricare (CAPTCHA di Cloudflare)Workers KVErrori 5xx elevatiDashboardLogin impossibile (dipendenza da Turnstile)AccessAutenticazione fallita per la maggior parte degli utentiEmail SecurityRiduzione temporanea dell'accuratezza anti-spam

1.6 La Risposta e le Azioni Correttive

Matthew Prince, CEO e co-fondatore di Cloudflare, ha pubblicato scuse pubbliche definendo l'incidente "il peggior outage dal 2019". L'azienda ha annunciato diverse misure correttive:

Hardening dei file di configurazione — Trattare i file generati internamente con la stessa cautela degli input utente
Kill-switch globali — Implementare interruttori di emergenza per disabilitare rapidamente features problematiche
Limiti sulle risorse di debug — Evitare che i core dump e i report di errore sovraccarichino il sistema
Review delle condizioni di errore — Audit completo dei failure modes in tutti i moduli del proxy

2. L'Outage di AWS: 20 Ottobre 2025

2.1 Un Mese Prima, lo Stesso Copione (Ma Diverso)

Meno di un mese prima dell'incidente Cloudflare, un altro gigante dell'infrastruttura era caduto. Amazon Web Services — il più grande cloud provider al mondo con circa il 30% del mercato — aveva subito un'interruzione massiccia nella sua regione più critica: US-EAST-1 (Northern Virginia).

Per capire la gravità: US-EAST-1 non è una regione come le altre. È la prima regione AWS mai creata, la scelta di default per molti servizi, e si stima che ospiti il 30-40% di tutti i workload AWS a livello globale. Il corridoio del Northern Virginia è così denso di data center che attraverso di esso transita circa il 70% del traffico Internet mondiale.

2.2 La Portata dell'Impatto

L'outage di AWS ha avuto un'eco ancora più vasta di quello Cloudflare:

Categoria Servizi Impattati

Social & Entertainment Snapchat, Reddit, Disney+, Hulu, Roblox, Fortnite

Finanza & Pagamenti Coinbase, Venmo, banche UK (Lloyds, Halifax)

AI & Produttività Perplexity AI, Signal

Smart Home Amazon Ring, Alexa, Eight Sleep

Trasporti App United Airlines, Delta

Gaming Pokémon GO, vari servizi

E-commerce Amazon.comstesso, Prime Video

Governo HMRC (agenzia fiscale UK)

Downdetector ha registrato oltre 17 milioni di segnalazioni durante l'incidente.

2.3 Timeline dell'Incidente

Orario (PDT/UTC) Evento

23:48 PDT (06:48 UTC) Primi errori API DynamoDB rilevati

00:26 PDT (07:26 UTC) Identificato il problema DNS

01:15 PDT (08:15 UTC) Prime mitigazioni temporanee applicate

02:25 PDT (09:25 UTC) DNS DynamoDB ripristinato

02:25 - 13:50 PDT Effetti a cascata su EC2, NLB, Lambda

05:30 - 14:09 PDT Network Load Balancer con health check failures

13:50 PDT EC2 completamente recuperato

14:20 PDT Maggior parte dei servizi ripristinata

21 Ottobre 04:05 PDT Ultimi cluster Redshift ripristinati

L'incidente è durato complessivamente oltre 15 ore, con impatti residui che si sono protratti fino al giorno successivo.

2.4 La Causa Tecnica: Una Race Condition nel DNS

L'Architettura DNS di DynamoDB

DynamoDB, il database NoSQL di AWS, utilizza un sistema automatizzato per gestire i suoi record DNS. Questo sistema è composto da due componenti indipendenti (per ragioni di ridondanza):

DNS Planner: Monitora lo stato dei load balancer e crea "DNS plans" — istruzioni su dove indirizzare il traffico
DNS Enactor: Applica i piani aggiornando Amazon Route 53 (il servizio DNS di AWS)

Il DNS Enactor viene eseguito in modo ridondante in tre Availability Zone diverse per garantire alta disponibilità.

La Race Condition

Una race condition è un bug che si verifica quando il comportamento di un sistema dipende dall'ordine temporale di eventi che non sono adeguatamente sincronizzati. È come quando due persone che cercano di entrare dalla stessa porta contemporaneamente — normalmente funziona, ma ogni tanto si incastrano .

Ecco cosa è successo:

Il DNS Planner genera un piano (chiamiamolo PLAN_V02) con gli IP aggiornati per DynamoDB
L'Enactor A inizia ad applicare il piano, ma subisce un ritardo anomalo
Nel frattempo, viene generato un piano più recente
L'Enactor B applica il piano più recente e avvia la pulizia dei piani obsoleti
In quel preciso istante, l'Enactor A (ritardato) applica finalmente PLAN_V01 — un piano ormai obsoleto
Il processo di pulizia, vedendo un piano molto vecchio, lo cancella immediatamente

Il risultato? L'endpoint regionale di DynamoDB si è ritrovato con un record DNS vuoto. Nessun IP. Niente. Come se qualcuno avesse cancellato il numero di telefono dall'elenco.

Per capire l'impatto: il DNS è l'elenco telefonico di Internet. Quando un'applicazione vuole connettersi a DynamoDB, prima chiede al DNS "a che indirizzo IP trovo dynamodb.us-east-1.amazonaws.com?". Con il record vuoto, la risposta era: nessun indirizzo trovato.

L'Effetto a Cascata

DynamoDB non è solo un database per i clienti AWS. È il database su cui AWS stessa costruisce i propri servizi interni. Quando DynamoDB è diventato irraggiungibile:

EC2 DropletWorkflow Manager (DWFM) — il sistema che gestisce i server fisici — non poteva rinnovare i suoi "lease" con DynamoDB. Nuove istanze EC2 non potevano essere lanciate.
Network Load Balancer (NLB) — dipendente da EC2 — ha iniziato a vedere health check failures. I suoi sistemi di failover automatico hanno iniziato a rimuovere nodi "non sani" che in realtà erano perfettamente funzionanti.
Lambda, ECS, EKS, Fargate — tutti dipendenti da EC2 — non potevano avviare nuove funzioni o container.
Persino il Support Center di AWS è andato in tilt, perché un suo sottosistema forniva risposte errate sugli account, impedendo agli utenti legittimi di accedere.

Il Problema del Recovery

Ma la cosa peggiore? Ripristinare il DNS non ha risolto immediatamente tutto.

Quando DynamoDB è tornato online alle 02:25, DWFM ha cercato di ristabilire i lease per l'intero fleet EC2 tutto in una volta. Il risultato è stato quello che AWS ha definito "congestive collapse" — un sovraccarico tale che i retry continuavano ad accumularsi più velocemente di quanto il sistema potesse smaltirli.

Gli ingegneri hanno dovuto intervenire manualmente, applicando throttling (limitazione del traffico) e riavviando parti di DWFM. EC2 è tornato completamente operativo solo alle 13:50 — oltre 11 ore dopo il ripristino di DynamoDB.

2.5 Le Azioni Correttive di AWS

AWS ha annunciato diverse misure:

Disabilitazione globale del DNS Planner e DNS Enactor automatici
Fix della race condition prima di riabilitare l'automazione
Velocity control per NLB — limiti alla capacità che un singolo NLB può rimuovere durante failover
Nuova test suite per DWFM — testing specifico dei workflow di recovery
Miglioramento del throttling EC2 — rate limiting basato sulla dimensione della coda di attesa

3. Il Paradosso della Centralizzazione: Internet è Meno Decentralizzata di Quanto Pensi

3.1 La Promessa Originale

Quando Internet è nata, negli anni '60 e '70, la sua architettura era intrinsecamente decentralizzata. Il protocollo TCP/IP era stato progettato per sopravvivere a un attacco nucleare — se un nodo veniva distrutto, i pacchetti trovavano automaticamente un'altra strada. Nessun punto centrale di controllo. Nessun singolo punto di fallimento.

Questa promessa di resilienza è stata uno dei pilastri filosofici e tecnici su cui abbiamo costruito la nostra fiducia in Internet.

3.2 La Realtà del 2025

Guardiamo i numeri:

ProviderQuota di Mercato Cloud (2025)AWS~30%Microsoft Azure~24%Google Cloud~11%Altri~35% (frammentati)

Tre aziende controllano quasi i due terzi dell'infrastruttura cloud globale. Ma la concentrazione non finisce qui:

Cloudflare gestisce proxy e CDN per milioni di siti web
Akamai serve una porzione significativa dei contenuti internet
La regione US-EAST-1 di AWS da sola ospita il 30-40% dei workload AWS mondiali
Il Northern Virginia vede transitare circa il 70% del traffico Internet globale

3.3 L'Analogia della Casa

Immagina Internet come un quartiere residenziale. La promessa originale era: ogni casa ha la propria alimentazione, le proprie tubature, i propri sistemi. Se una casa ha un problema, le altre continuano a funzionare.

La realtà? Quasi tutte le case del quartiere sono collegate allo stesso trasformatore elettrico (AWS US-EAST-1), allo stesso sistema idrico centrale (pochi DNS provider), e condividono le stesse guardie di sicurezza all'ingresso (Cloudflare, Akamai).

Quando il trasformatore salta, non è una casa a restare al buio. È l'intero quartiere.

3.4 Perché è Successo?

La centralizzazione non è avvenuta per caso o per cattiva volontà. È il risultato di forze economiche e tecniche precise:

Economie di Scala

AWS, Azure e Google possono offrire servizi a prezzi che un datacenter aziendale interno non può eguagliare. Hanno potere d'acquisto per hardware, energia, e possono distribuire i costi di R&D su milioni di clienti.

Complessità Operativa

Gestire infrastruttura è difficile. Richiede competenze specializzate, team operativi 24/7, e investimenti continui. Per la maggior parte delle aziende, ha più senso delegare questo compito a chi lo fa di mestiere.

Effetti di Rete

Più clienti usano una piattaforma, più servizi vengono costruiti su di essa, più diventa conveniente usarla. AWS ha oltre 200 servizi che si integrano nativamente tra loro. Costruire lo stesso ecosistema altrove è quasi impossibile.

Il Mito della Ridondanza Geografica

Molte aziende credono di essere protette perché usano "multiple Availability Zones" all'interno di una regione. Ma come dimostra l'outage AWS, le AZ proteggono da guasti al singolo datacenter, non da guasti a livello regionale o di control plane.

È come avere stanze diverse nella stessa casa. Se una stanza si allaga, ti sposti in un'altra. Ma se tutta la casa si allaga, ogni stanza è sott'acqua.

3.5 Il Costo della Convenienza

La centralizzazione ha portato benefici innegabili:

Costi ridotti
Facilità di deployment
Accesso a tecnologie avanzate
Scalabilità immediata

Ma il prezzo nascosto è la fragilità sistemica. Quando le Fortune 500, le startup, le banche, i governi, e le app consumer dipendono tutti dagli stessi pochi provider, un singolo bug può avere conseguenze da centinaia di miliardi di dollari.

Lloyd's of London stimava già nel 2018 che un outage di 3-6 giorni di un top-3 cloud provider potrebbe causare danni tra 6.9 e 14.7 miliardi di dollari. E questo prima che l'adozione del cloud accelerasse ulteriormente durante la pandemia.

3.6 Il Multi-Cloud è la Risposta?

La risposta teorica alla centralizzazione è il multi-cloud: distribuire i workload tra più provider (AWS, Azure, GCP) così che se uno cade, gli altri reggono.

La realtà è più complicata:

Complessità tecnica: Ogni provider ha le sue API, i suoi servizi, le sue peculiarità. Costruire applicazioni veramente portabili richiede uno sforzo enorme.
Costi: Gestire infrastruttura su più cloud significa duplicare competenze, strumenti, e spesso capacità.
Dipendenze nascoste: Anche se la tua app gira su Azure, potrebbe dipendere da una libreria che chiama un servizio su AWS. Oppure il tuo provider di pagamenti usa Cloudflare. Le dipendenze sono spesso invisibili fino a quando non si rompono.
Internet come dipendenza: Anche con multi-cloud perfetto, rimani dipendente da DNS globale, BGP routing, CDN. Come nota la Cloud Security Alliance: "Internet stesso è un single point of failure."

3.7 Verso una Nuova Architettura?

Gli esperti suggeriscono alcune direzioni:

Strategia Pro Contro

--------------------------------------------------------------------------------------------------------------

Multi-region Relativamente semplice, Non protegge da outage del control plane

(stesso provider) buon rapporto costo/beneficio

-------------------------------------------------------------------------------------------------------------------

Multi-cloud attivo Massima resilienza teorica Complessità e costi elevati

-------------------------------------------------------------------------------------------------------------------

Hybrid cloud

(cloud + on-premise)

---------------------------------------------------------------------------------------------------------------------

Edge computing distribuito Riduce dipendenza da datacenter centrali Ancora immaturo per molti use case

----------------------------------------------------------------------------------------------------------------------

La raccomandazione pragmatica per la maggior parte delle organizzazioni:

Inizia con multi-region all'interno del tuo provider principale
Identifica i workload veramente critici e valuta backup su un secondo provider
Mappa le dipendenze — non solo le tue, ma quelle dei tuoi fornitori
Implementa chaos engineering — testa regolarmente i failure modes prima che ti sorprendano in produzione

4. Le Lezioni Apprese

4.1 Per gli Ingegneri

Il Codice Dormiente Può Svegliarsi

Entrambi gli incidenti coinvolgono bug latenti — difetti nel codice che esistevano da tempo ma che si sono attivati solo quando specifiche condizioni si sono allineate.

Nel caso Cloudflare, il limite di 200 features era probabilmente adeguato quando è stato scritto. Nel caso AWS, la race condition poteva non manifestarsi mai finché i ritardi non raggiungevano una certa soglia.

Takeaway: Le code review non bastano. Serve testing approfondito dei failure modes, fuzzing, e chaos engineering.

I Sistemi Complessi Falliscono in Modi Complessi

Nessuno dei due outage è stato causato da un singolo errore "stupido". Entrambi sono stati il risultato di interazioni impreviste tra componenti multipli:

Cloudflare: modifica permessi DB → query restituisce duplicati → file supera limite → panic
AWS: race condition → DNS vuoto → DynamoDB down → cascade su EC2 → cascade su tutto il resto

Takeaway: L'architettura distribuita introduce complessità emergente. Servono modelli mentali che abbracciano il failure come inevitabile.

Il Recovery Può Essere Peggio dell'Outage

L'esperienza AWS con DWFM dimostra che ripristinare un servizio può scatenare problemi peggiori del guasto originale. Quando milioni di lease scaduti cercano di rinnovarsi contemporaneamente, il sistema che doveva riprendersi si ritrova in ginocchio.

Takeaway: Testare non solo i failover, ma anche i recovery workflow. Implementare rate limiting e circuit breaker anche nei path di ripristino.

4.2 Per i Decision Maker

La Convenienza Ha un Prezzo Nascosto

Usare un solo provider, una sola regione, affidarsi completamente a un CDN è comodo e conveniente. Ma il costo del "when it breaks" può superare di ordini di grandezza i risparmi accumulati.

Takeaway: Nel budget di ogni progetto, includere una voce per la resilienza. Non è un nice-to-have.

Le Assicurazioni Non Bastano

AWS offre un credito del 30% ai clienti impattati che rientrano negli SLA. È una consolazione minima per un'azienda che ha perso una giornata di business.

Takeaway: Gli SLA cloud garantiscono rimborsi, non continuità operativa. La responsabilità di rimanere online è tua.

4.3 Per Tutti Noi

Internet Non È un Diritto Acquisito

Trattiamo la connettività come l'elettricità o l'acqua corrente — qualcosa che "c'è sempre". Ma a differenza delle utility tradizionali, Internet non ha un regolatore che impone standard di uptime, ridondanza, o trasparenza.

Takeaway: Come società, dovremmo iniziare a discutere se i principali cloud provider e i servizi infrastrutturali vadano trattati come infrastruttura critica, con le relative responsabilità.

La Concentrazione È un Rischio Sistemico

Quando un bug in un database può far cadere ChatGPT, le banche britanniche, e i giochi online contemporaneamente, abbiamo un problema che va oltre la singola azienda o il singolo incidente.

Takeaway: La diversificazione dell'infrastruttura Internet non è solo una questione tecnica. È una questione di resilienza sociale ed economica.

5. Conclusioni: Costruire su Sabbie Mobili

Torniamo alla domanda iniziale: come siamo arrivati a questo punto?

La risposta è semplice e complessa allo stesso tempo. Siamo arrivati qui un passo alla volta, ogni passo perfettamente razionale. Usare il cloud è conveniente. Affidarsi a un CDN è pratico. Standardizzare su un provider riduce la complessità operativa.

Ma la somma di decisioni individualmente sensate ha prodotto un sistema globalmente fragile. Un'infrastruttura dove la promessa originale di Internet — la resilienza attraverso la distribuzione — è stata silenziosamente erosa in nome dell'efficienza.

Gli outage di Cloudflare e AWS non sono stati incidenti isolati. Sono sintomi di un'architettura che privilegia la convenienza sulla robustezza, la centralizzazione sulla diversità, l'ottimizzazione dei costi sulla resilienza.

Non significa che dovremmo abbandonare il cloud o tornare ai datacenter aziendali degli anni '90. Significa che dovremmo progettare i nostri sistemi con la consapevolezza che tutto può fallire — e probabilmente lo farà nel momento meno opportuno.

Significa investire in ridondanza prima che diventi necessaria. Mappare le dipendenze prima che diventino evidenti (nel peggior modo possibile). Testare i failure modes prima che si manifestino in produzione.

E forse, a livello di policy e regolamentazione, iniziare a trattare l'infrastruttura digitale con la stessa serietà con cui trattiamo ponti, autostrade, e reti elettriche.

Perché la prossima volta che i giganti cadranno, e ci sarà una prossima volta, l'impatto dipenderà da quanto saremo stati saggi nel prepararci.

Sei pronto a verificare la resilienza della tua infrastruttura? Inizia mappando le dipendenze dei tuoi servizi critici. Potresti scoprire di dipendere da più "giganti" di quanto pensassi. E la prossima volta che uno di loro cadrà, almeno non sarai colto di sorpresa.