I servizi digitali moderni vengono progettati partendo da un presupposto implicito: devono essere sempre disponibili.
Indice degli argomenti
Il mito della disponibilità permanente e la fragilità del cloud
Questa idea di continuità permanente influenza sia le architetture tecnologiche sia le aspettative degli utenti.
Il cloud, con la sua promessa di elasticità, ridondanza e scalabilità pressoché illimitata, ha contribuito a consolidare questa convinzione, offrendo nella maggior parte dei casi livelli elevati di affidabilità.
Tuttavia, le interruzioni su larga scala che hanno colpito negli anni i principali provider dimostrano che l’assunto della disponibilità costante è fragile. Quando si verificano outage estesi, emerge una realtà ben nota ai professionisti della sicurezza e della resilienza: nei sistemi complessi il fallimento è inevitabile.
L’outage AWS del 2021: quando cade il livello di controllo, non solo la potenza di calcolo
L’outage che nel dicembre 2021 ha colpito AWS nella regione us-east-1, causato da problemi interni di rete e del control plane, ha reso evidente questa vulnerabilità. L’interruzione ha avuto effetti globali, coinvolgendo sia applicazioni consumer sia workload enterprise. In molti casi i sistemi continuavano a funzionare a livello infrastrutturale, ma i clienti avevano perso accesso agli strumenti necessari per monitorarli e gestirli.
Non era solo una questione di capacità computazionale indisponibile; era il livello di controllo a risultare compromesso. Schemi simili si sono ripetuti in altri incidenti significativi, nei quali malfunzionamenti nei servizi di gestione centralizzata, nell’identità o nei componenti di rete hanno provocato disservizi diffusi e tempi di ripristino più lunghi del previsto.
La storia tende a ripetersi e, nonostante numerosi episodi che mettono in luce la fragilità di determinate architetture, l’approccio all’affidabilità non si è ancora adattato pienamente.
Progettare per il guasto: i nuovi principi di reliability nei framework evoluti
I framework più evoluti in materia di reliability partono da un principio diverso rispetto al passato: il guasto va considerato una condizione operativa ordinaria e previsto fin dalla fase di progettazione. Il principio di affidabilità definito dall’AWS Well-Architected Framework, ad esempio, invita a progettare sistemi capaci di reagire in modo prevedibile quando qualcosa smette di funzionare.
L’obiettivo non è mantenere ogni componente sempre attivo al massimo delle prestazioni, bensì garantire che il sistema nel suo insieme continui a operare in modo controllato anche in presenza di errori.
Degrado controllato: le soluzioni concrete per garantire i servizi essenziali
Questo approccio si traduce in soluzioni concrete: modalità in sola lettura, funzionalità temporaneamente ridotte, elaborazioni differite, isolamento dei workload. Tutte misure che condividono la stessa finalità: assicurare che i servizi essenziali restino operativi quando si verifica un evento inatteso. L’affidabilità diventa quindi una questione di gestione del degrado, non di eliminazione assoluta dell’errore. Progettare per condizioni degradate significa identificare in anticipo quali componenti devono restare attive a ogni costo, quali possono essere sospese temporaneamente e quali dipendenze rappresentano potenziali punti di blocco.
Cyber resilience e il framework NIST SP 800-160: anticipare, assorbire, ripristinare
Una logica analoga è alla base dei framework di cyber resilience, come il NIST SP 800-160. La resilienza si definisce nella capacità di anticipare le interruzioni, assorbirne gli effetti, ripristinare rapidamente le funzionalità e adattarsi a uno scenario mutato.
Che la causa sia un attacco informatico, un difetto software o un guasto infrastrutturale incide meno del risultato finale: preservare i servizi critici evitando effetti a cascata e perdita di controllo. Il vero banco di prova consiste nel tradurre questi principi teorici in meccanismi verificabili nei sistemi reali.
Chaos engineering: testare il fallimento prima che accada davvero
Ed è qui che si inserisce il chaos engineering. L’idea di fondo è comprendere come i sistemi si comportano effettivamente, non come si presume che si comportino. Invece di attendere che un’interruzione reale riveli debolezze strutturali, le organizzazioni introducono deliberatamente guasti controllati, come ritardi di rete, indisponibilità di dipendenze, errori nei servizi condivisi o saturazione delle risorse, osservandone gli effetti.
L’obiettivo ovviamente non è quello di provocare disservizi, ma di verificare che l’architettura sia in grado di assorbire lo shock e recuperare rapidamente senza perdere il controllo operativo. Come un’esercitazione antincendio, questi test mettono in luce dipendenze nascoste, presupposti impliciti e fragilità che emergono solo sotto stress, permettendo di intervenire prima che un evento reale produca conseguenze più gravi.
Multi-cloud e hybrid cloud: ridondanza reale o solo teorica?
Alla luce di queste considerazioni, assume maggiore chiarezza anche il ruolo delle strategie multi-cloud e hybrid cloud. Sebbene i due termini vengano spesso utilizzati come sinonimi, rispondono a esigenze differenti.
Un approccio multi-cloud distribuisce i workload tra più provider pubblici, riducendo la dipendenza da un singolo ecosistema. Un’architettura ibrida combina servizi cloud pubblici con infrastrutture private o on-premise, consentendo di mantenere operative funzioni critiche anche quando una piattaforma esterna risulta indisponibile.
Quando la ridondanza diventa solo apparente: il rischio dei servizi condivisi
Gli outage recenti dimostrano che molti incidenti su larga scala non sono stati causati da carenza di potenza di calcolo, bensì da malfunzionamenti in servizi condivisi come identità, networking, DNS o sistemi di gestione centralizzata.
Quando ambienti apparentemente distinti dipendono dalle stesse componenti sottostanti, la ridondanza diventa solo teorica. In tali condizioni, un singolo punto di errore può generare un’interruzione diffusa. Progettazioni hybrid e multi-cloud che introducono una reale separazione logica e operativa non eliminano la possibilità di guasti, ma ne limitano l’estensione e riducono il rischio di propagazione incontrollata.
Un nuovo paradigma: l’affidabilità si misura nella capacità di contenere il danno
Questi episodi indicano un cambiamento più ampio nel modo di intendere l’affidabilità. Oggi la continuità si misura nella capacità di ridurre l’impatto del fallimento e contenerne gli effetti. Progettare sistemi che prevedano l’interruzione, che degradino in modo controllato e che mantengano il governo delle operazioni anche durante una crisi rappresenta una condizione di base per qualsiasi organizzazione che dipenda in modo critico dai servizi digitali.
