Indice dell'articolo

Il 20 ottobre una zona della regione londinese di Google Cloud ha perso l’alimentazione, con effetti a cascata su banche, logistica e servizi pubblici britannici. La causa dichiarata è un generico “power event”, l’analisi ufficiale non c’è ancora. Per i CIO italiani il caso riporta al centro i test di failover delle architetture ridondanti, che NIS2 e DORA rendono una questione di conformità.

Martedì 20 ottobre, alle 08:08 ora italiana, la zona europe-west2-b di Google Cloud, una delle tre della regione di Londra, ha perso l’alimentazione elettrica. L’interruzione ha reso indisponibile la zona e ha causato errori e problemi di rete nell’intera regione europe-west2. Una regione è fatta da più zone di disponibilità collegata a bassa latenza, proprio per permettere di replicare i servizi e – in caso di incidenti a una zona – far subentrare rapidamente la gemella.

Il fatto eclatante quindi non è che si accaduto un incidente che ha messo offline una zona – le architetture resilienti vengono progettate proprio per questa eventualità – ma che il guasto abbia coinvolto tutta la regione. Google parla di un “power event” e ha promesso un’analisi solo a indagine interna conclusa.

Che cosa è successo

Secondo la pagina di stato di Google Cloud, l’incidente è iniziato alle 06:08 UTC del 20 ottobre e ha riguardato il sistema di alimentazione. Nella tarda mattinata Google ha dichiarato mitigato l’evento elettrico, precisando che la priorità era il ripristino dei carichi di lavoro esistenti, mentre la creazione di nuovi carichi poteva non essere ancora possibile. Verso le 14:00 UTC la maggior parte dei clienti era tornata operativa. Google parla di pochissimi clienti ancora coinvolti, mentre il Ministero della Giustizia britannico ha confermato che nel pomeriggio la piattaforma video dei tribunali non era ancora del tutto ripristinata.

La pagina di stato elenca oltre trenta servizi coinvolti, tra cui Compute Engine, Kubernetes Engine, Cloud Run, Cloud SQL, Spanner, BigQuery, Cloud Load Balancing e VPC. A valle, hanno avuto problemi le applicazioni finanziarie di Lloyds, HSBC e Revolut, i servizi di Royal Mail e DPD, il portale Rightmove, BT e Screwfix. Tra i servizi pubblici risultano coinvolti NHS England (l’istitituzione sanitaria) e Gov.uk, il portale di accesso alla pubblica amministrazione per i cittadini del Regno Unito. Sono stati segnalati disservizi ovviamente anche per tutti i fornitori terzi i cui servizi dipendono dalle organizzazioni coinvolte in prima persona.

Che cosa è confermato e che cosa no

Di confermato c’è poco. Google ha indicato un “power event” nella zona europe-west2-b, senza spiegare che cosa sia accaduto all’alimentazione, e non ha fissato una data per la pubblicazione dell’analisi. Tutto ciò che segue è quindi una ricostruzione di terze parti e va letto come ipotesi.

I generatori di backup. Un amministratore, citato da Computer Weekly, ha diffuso un aggiornamento tecnico che attribuisce a Google. La corrente di rete sarebbe tornata, ma i generatori di emergenza non sarebbero entrati in funzione all’inizio del guasto, e gli ingegneri avrebbero mantenuto il drain (lo svuotamento controllato del traffico) dei cluster della zona B mentre i tecnici verificavano l’alimentazione.

L’impianto interno. Sempre secondo Computer Weekly, UK Power Networks, il gestore della rete di distribuzione, ha riferito che i propri sistemi londinesi funzionavano normalmente, escludendo un guasto alla sottostazione. Se il problema non era a monte, l’attenzione si sposta sull’impianto interno al sito.

Perché una zona ha coinvolto la regione. Un tecnico su Reddit sostiene che le zone A e C non abbiano assorbito del tutto il carico, senza saperne indicare il motivo, e indica in Apigee, la piattaforma di gestione delle API di Google, il sistema più problematico. Spiegazioni come servizi regionali con dipendenze dalla zona B o capacità insufficiente nelle altre zone restano ipotesi che nessuna fonte ha confermato. Pesa poi un dato di contesto: Google ha una sola regione nel Regno Unito, quindi chi non aveva una configurazione multi-regione – per esempio tutti i servizi governativi e quelli che per policy non possono archiviare dati fuori dal paese – non disponevano di un’alternativa nazionale.

Il punto di vista del CIO

Il modello delle zone di disponibilità promette che un servizio regionale sopravviva alla perdita di una zona. In questo caso non è successo. L’esito dipende però anche da come ogni cliente ha disegnato carichi, database e dipendenze, e questo incidente lo mostra. La resilienza non si ottiene semplicemente spostandosi sul cloud, ma richiede progetti pensati per i guasti regionali, distribuzione su più regioni, portabilità dei carichi e procedure di ripristino collaudate.

Un aspetto da considerare è anche il bilanciamento tra due principi di governance apparentemente in contraddizione tra loro: le politiche sulla data residency – tenere tutti i dati nel Paese – possono avere effetti nefasti sulla resilienza, perché impediscono di avere repliche dell’infrastruttura su regioni differenti, se sono fuori dai confini. L’Italia non ha il vincolo britannico, perché Google Cloud offre due regioni, Milano e Torino, ma la lezione sulle dipendenze vale ovunque.

Per un CIO le domande sono concrete. Dove girano davvero i carichi critici e quali dipendenze regionali nascondono, dal gateway API al bilanciatore? In quali regioni lavorano i fornitori SaaS da cui dipendono i processi di business?

Dire “sono su un cloud ridondato” non basta a soddisfare NIS2 e DORA

La direttiva NIS2 (UE 2022/2555, recepita in Italia con il D.Lgs. 138/2024) chiede ai soggetti essenziali e importanti misure di gestione del rischio che comprendono continuità operativa, gestione dei backup, ripristino in caso di disastro e sicurezza della catena di fornitura. Prevede inoltre la notifica degli incidenti significativi, con preallarme entro 24 ore e notifica entro 72.

Per banche, assicurazioni e intermediari il regolamento DORA (UE 2022/2554, applicabile dal 17 gennaio 2025) aggiunge un programma di test di resilienza operativa digitale, che comprende la verifica dei piani di continuità e di ripristino. Impone poi la gestione del rischio dei fornitori ICT terzi, con registro degli accordi e strategie di uscita, e la classificazione degli incidenti maggiori.

In entrambi i casi, l’interruzione di un fornitore cloud non sposta la responsabilità, che resta in capo al soggetto regolato. Che è anche tenuto a verificare periodicamente l’efficacia dei piani di contingenza in caso di incidente.

Spesso, una delle leve di vendita dei servizi cloud è che sono “nativamente ridondanti”. Come si dice spesso per i backup, questa affermazione è valida solo finché non si prova l’efficacia di un failover, preservando dati e operatività dei servizi.

Che cosa testare

Come per il backup, una ridondanza funziona solo finché non si è dimostrato mai provata resta un’ipotesi di progetto. Questo incidente suggerisce alcune prove da inserire nel piano dei test:

  • il failover verso le altre zone con carico reale, per verificare che abbiano la capacità di assorbirlo;
  • il riavvio di database e servizi con stato dopo il failover;
  • le dipendenze regionali condivise, come gateway API, bilanciatori e NAT;
  • un ripristino che non presupponga la creazione di nuove risorse nella regione colpita, perché in questo caso Google ha dichiarato che nelle prime ore poteva non essere possibile;
  • il passaggio a un’altra regione, con tempi di recupero misurati e non stimati.