Pană Google Cloud la Londra: Revolut și alte servicii, blocate ore întregi

Marți dimineață, 20 octombrie 2026, milioane de oameni din Europa au descoperit că nu-și pot folosi cardul Revolut la casă, nu pot face un transfer și nici nu se pot autentifica în aplicație. Cauza nu a fost un atac informatic și nici o greșeală a băncii, ci o pană în centrul de date al unui furnizor de cloud: regiunea europe-west2 (Londra) a Google Cloud. Pentru noi, cei care administrăm zilnic servere și infrastructură pentru firme, incidentul este un studiu de caz despre o întrebare pe care puțini antreprenori și-o pun: ce se întâmplă cu afacerea mea când pică furnizorul furnizorului meu?

#Ce s-a întâmplat

Conform paginii de stare Google Cloud, problemele au început la 06:08 UTC (09:08, ora României). Mai multe servicii din regiunea londoneză au început să raporteze „erori crescute și întreruperi intermitente de rețea”: Compute Engine, Google Kubernetes Engine, Cloud Run, BigQuery, Cloud Filestore, Managed Service for Apache Kafka și alte câteva zeci de produse.

Câteva ore mai târziu, Google a explicat cauza: „din cauza unui eveniment de alimentare electrică (power event), am suferit o întrerupere în zona europe-west2-b”. Cu alte cuvinte, o problemă de curent într-una dintre cele trei zone ale regiunii Londra. Efectele s-au simțit însă mult mai larg: unii observatori au remarcat că serviciile au avut probleme în toată regiunea, nu doar în zona afectată. În lipsa unei soluții de ocolire, Google a recomandat la un moment dat clienților să-și mute încărcarea în altă regiune, „dacă este posibil”.

Google a anunțat ulterior că problema a fost atenuată pentru majoritatea clienților, iar incidentul a fost închis după aproximativ 8 ore.

#Revolut: carduri, transferuri și aplicație blocate

Revolut, care are peste 80 de milioane de utilizatori și își rulează o mare parte din infrastructură în Google Cloud, a fost cea mai vizibilă victimă. Clienții din Marea Britanie, Irlanda și din alte țări europene au raportat că nu pot:

• să se autentifice în aplicație;
• să plătească cu cardul sau să retragă numerar de la bancomat;
• să facă transferuri, schimburi valutare sau tranzacții cu acțiuni.

Banca a confirmat o „întrerupere care afectează mai multe servicii” și a transmis că banii și datele clienților sunt în siguranță. Revolut nu a numit oficial Google Cloud drept cauză, însă momentul și natura problemelor coincid cu incidentul din Londra. Pe parcursul după-amiezii, pagina de stare a băncii mai arăta în jur de 30 de servicii parțial indisponibile, chiar și după ce Google raportase atenuarea problemei. Este un detaliu important: revenirea furnizorului de cloud nu înseamnă revenirea instantanee a aplicațiilor clienților săi.

Pe lista celor afectați, potrivit raportărilor utilizatorilor pe Downdetector, au apărut și Lloyds, HSBC, Royal Mail, DPD, BT și Spotify. Nu toate aceste legături au fost confirmate oficial de companii.

#De ce contează și pentru o firmă din România

Poate nu aveți servere în Londra, dar foarte probabil depindeți de cloud fără să știți: aplicația de facturare, magazinul online, procesatorul de plăți, emailul, platforma de curierat sau chiar aplicația băncii cu care vă plătiți furnizorii. Incidentul de marți ne amintește trei lucruri pe care le vedem des în proiectele noastre:

1. „Cloud” nu înseamnă „nu pică niciodată”. Cloud-ul este tot un centru de date cu alimentare electrică, răcire și rețea. Google a mai avut incidente similare, de exemplu în 2023 la Paris, când o scurgere de apă și un incendiu au scos din funcțiune o regiune întreagă.
2. Mai multe zone în aceeași regiune nu sunt întotdeauna suficiente. Arhitectura „multi-zonă” protejează de căderea unei săli de servere, dar nu neapărat de o problemă care se propagă în toată regiunea. Serviciile critice au nevoie de un plan pentru altă regiune sau chiar alt furnizor.
3. Dependența de un singur canal de plată este un risc operațional. O firmă care își plătește salariile, furnizorii sau achizițiile doar printr-o singură aplicație bancară poate rămâne blocată o zi întreagă din cauza unui incident pe care nu-l controlează.

#Ce recomandăm concret

• Aveți o a doua metodă de plată. Un card de la altă bancă, pentru firmă și personal, rezolvă cea mai neplăcută parte a unei astfel de zile.
• Faceți inventarul dependențelor. Notați ce servicii externe folosiți (facturare, plăți, email, stocare) și unde rulează. Dacă unul pică, știți ce se oprește și ce alternativă aveți.
• Țineți backup-ul în altă locație decât producția. Un backup aflat în același centru de date sau la același furnizor cade odată cu sistemul principal. La Activ.NET proiectăm backup-uri în locații separate tocmai pentru astfel de scenarii.
• Testați restaurarea, nu doar backup-ul. Un plan de recuperare care n-a fost încercat niciodată este doar o presupunere.
• Urmăriți paginile de stare ale furnizorilor. Abonați-vă la notificările de status ale serviciilor critice, ca să aflați de la sursă, nu de la clienți, că ceva nu merge.

#Concluzia noastră

Pana de marți nu a fost cauzată de hackeri și nici de un bug spectaculos, ci de o problemă banală de alimentare electrică într-un centru de date. Tocmai de aceea este relevantă: astfel de evenimente se pot întâmpla oricui, oricât de mare ar fi furnizorul. Diferența dintre o oră de neplăcere și o zi pierdută o face pregătirea: redundanță, backup-uri în altă locație și alternative pentru serviciile critice. Dacă vreți să știți cât de expusă este infrastructura firmei voastre, echipa Activ.NET vă poate ajuta cu o evaluare și cu soluții de găzduire și backup adaptate.

Inspirat din: The Register, The Irish Times, The Stack