Il 20 ottobre un’interruzione elettrica nella struttura che ospita una zona della regione londinese di Google Cloud ha provocato oltre sei ore di disservizi. Reuters ha verificato ripercussioni su Revolut, Lloyds e HSBC; nel caso di Revolut sono risultati indisponibili anche accesso al conto, pagamenti con carta e prelievi.
Non si sono fermate intere banche, come potrebbe suggerire una formula troppo ampia. Si sono interrotti servizi bancari specifici, con conseguenze comunque concrete per i clienti. L’incidente offre soprattutto una lezione meno spettacolare: distribuire un’applicazione tra più macchine o zone non basta, se dipendenze e capacità di recupero non reggono alla perdita improvvisa di una parte dell’infrastruttura.
Che cosa si è guastato a Londra
L’incidente ha interessato europe-west2, la regione Google Cloud di Londra. Secondo il rapporto preliminare del fornitore, il problema è iniziato nella struttura che ospita la zona europe-west2-b.
Durante un’interruzione della rete elettrica, il carico è passato alle batterie UPS mentre avrebbero dovuto avviarsi i generatori di emergenza. Il sistema automatico di controllo, sia nella componente primaria sia in quella di riserva, non ha completato l’avvio e il trasferimento del carico. Esaurite le batterie, server fisici, apparati di rete e sistemi di archiviazione locali hanno perso alimentazione.
Istanze, repliche di database e nodi di elaborazione presenti nella zona sono diventati irraggiungibili. Google indica una durata complessiva di 6 ore e 10 minuti, dalle 07:00 alle 13:10 nell’orario britannico.
Perché il problema non è rimasto confinato a una zona
Lo spegnimento fisico ha innescato una seconda fase. I meccanismi di instradamento e le applicazioni dei clienti hanno trasferito traffico e carichi verso le altre zone disponibili nella regione. Queste infrastrutture hanno dovuto assorbire improvvisamente query, failover di database e workload di calcolo aggiuntivi.
La capacità residua si è saturata in alcuni punti, producendo code, ritardi ed errori intermittenti. Inoltre, chiamate interzona provenienti dai piani di controllo dei servizi regionali hanno continuato a raggiungere componenti di metadati e catalogo ormai offline, incontrando timeout.
La precisione è importante: il rapporto non dice genericamente che tutti i sistemi di controllo dipendessero dalla zona guasta. Documenta specifiche chiamate verso componenti non più raggiungibili, insieme alla congestione generata dal trasferimento del carico.
Come possono fermarsi servizi di banche diverse
Due istituti non devono condividere tutta la piattaforma informatica per risentire dello stesso incidente. È sufficiente che funzioni decisive dipendano dalla medesima regione cloud o da componenti incapaci di operare quando una parte della catena non risponde.
Un’applicazione può persino aprirsi normalmente mentre autenticazione, database, code o controlli necessari a completare una transazione rimangono indisponibili. Per il cliente il risultato è comunque evidente: non riesce a entrare, pagare o prelevare.
Reuters ha identificato tra le organizzazioni interessate Revolut, Lloyds e HSBC. Revolut ha comunicato che fondi e dati dei clienti sono rimasti al sicuro. È una distinzione essenziale: indisponibilità, perdita dei dati e violazione delle informazioni sono rischi differenti. Un servizio può non essere raggiungibile senza che il suo contenuto venga cancellato o sottratto.
Non bisogna nemmeno confondere il numero complessivo dei clienti degli istituti coinvolti con quello delle persone effettivamente colpite. Le fonti non offrono una misura pubblica abbastanza precisa per questa equivalenza.
Perché “multi-zona” non significa resiliente per definizione
Distribuire un servizio tra più zone protegge da molti guasti locali, ma funziona soltanto se ogni dipendenza essenziale segue la stessa logica. Replicare i server applicativi serve a poco se database, identità, code o configurazioni mantengono punti unici di fallimento.
Occorre inoltre lasciare capacità libera. Se le zone superstiti riescono a sostenere soltanto il loro carico ordinario, l’arrivo improvviso dei workload trasferiti può trasformare il failover in congestione. La ridondanza esiste nel diagramma, ma non regge nelle condizioni per cui era stata progettata.
Una strategia su più regioni offre maggiore separazione geografica, ma introduce costi e complessità: replica dei dati, coerenza, latenza, gestione delle scritture e ritorno alla sede principale. Nemmeno adottare due fornitori è una scorciatoia. Un ambiente alternativo non aggiornato o mai collaudato rischia di non partire proprio durante l’emergenza.
La concentrazione del cloud diventa un tema pubblico
Il giorno successivo al blackout, l’Autorità bancaria europea ha confermato a Reuters di avere contattato Google Cloud per ottenere informazioni e valutare il possibile impatto sulle organizzazioni finanziarie dell’Unione. Anche la FCA britannica ha avviato interlocuzioni con Google.
La commissione del Tesoro del Parlamento britannico ha scritto alla Bank of England e alla FCA chiedendo chiarimenti sulla portata dell’incidente e sulla risposta dei supervisori. Nel Regno Unito Google Cloud, AWS, Microsoft e Oracle sono stati inclusi nel regime per le terze parti critiche del settore finanziario.
Il problema non è affidarsi per principio a un grande fornitore. La concentrazione diventa rilevante quando molte organizzazioni dipendono dallo stesso operatore e un singolo incidente attraversa confini aziendali che, dal punto di vista del cliente, sembravano separati. La supervisione, inoltre, non cancella la responsabilità degli istituti sui servizi affidati all’esterno.
Che cosa può fare un cliente durante il disservizio
In caso di blackout infrastrutturale, reinstallare l’app bancaria o cambiare password difficilmente risolve il problema. Ripetere più volte un pagamento dal risultato incerto può invece complicare i controlli quando i sistemi tornano disponibili.
È più prudente consultare i canali ufficiali, verificare saldo e movimenti prima di riprovare e conservare eventuali ricevute. Per le necessità urgenti può aiutare un metodo di pagamento realmente indipendente: non semplicemente una seconda carta collegata allo stesso conto, ma uno strumento che non condivida l’intera catena tecnica.
Non serve organizzare la propria vita intorno a un evento raro. Una piccola alternativa può però ridurre parecchio il disagio di alcune ore senza accesso ai servizi principali.
Le prove che contano per un’azienda
Definire un’applicazione “multi-zona” non è una verifica. Bisogna conoscere dipendenze critiche, capacità disponibile dopo il guasto e funzioni minime che devono rimanere operative.
Le domande utili sono concrete: il failover avviene davvero senza intervento? È stato provato isolando un’intera zona, non soltanto simulando la perdita di un server? Database, identità e code continuano a funzionare? I backup possono essere ripristinati altrove? Il personale sa chi deve decidere il passaggio e come comunicarlo agli utenti?
Va provato anche il ritorno alla normalità. Dopo il ripristino possono rimanere operazioni accodate, notifiche arretrate e transazioni da riconciliare. Tornare online non significa avere già completato il recupero.
La resilienza si misura prima dell’incidente
Il blackout è partito da un problema elettrico, ma la sua portata è dipesa anche da timeout verso componenti offline, failover e capacità residua. Sono elementi che un diagramma architetturale non riesce a certificare.
Il cloud offre strumenti potenti per distribuire dati e workload. Il loro valore dipende però da configurazione, dimensionamento ed esercitazioni realistiche. La domanda decisiva non è quante copie del servizio esistano, ma quali operazioni continuino davvero a funzionare quando una parte dell’infrastruttura scompare senza preavviso.