O 06:08 UTC we wtorek, 20 października 2026 roku, region europe-west2 Google Cloud, czyli region londyński, zaczął zwracać błędy. W ciągu dwóch godzin miliony ludzi w Wielkiej Brytanii i Irlandii odkryły, że nie mogą za nic zapłacić.
Najbardziej widoczną ofiarą był Revolut. Płatności kartą, wypłaty z bankomatów, przelewy i logowanie do konta przestały działać albo działały z przerwami. Firma potwierdziła zakłócenie dotyczące wielu usług i oświadczyła, że „pieniądze i dane wszystkich naszych klientów są bezpieczne".
Revolut nie był jednak sam; i tu wymagane jest poszerzenie perspektywy. Doniesienia wymieniają również Lloyds, HSBC, Halifax, Royal Mail, DPD, NHS England oraz ING Germany. Jeden region chmurowy w Londynie i spora część brytyjskiej codzienności przestały funkcjonować.
Trzy zastrzeżenia na wstępie:
Nie ma żadnych przesłanek wskazujących na atak. Nikt tego nie sugerował. To awaria infrastruktury i traktowanie jej jako incydentu bezpieczeństwa byłoby błędem.
Pieniądze i dane klientów nie są zagrożone. Zarówno Revolut, jak i Google są w tej kwestii konsekwentni.
To wciąż rozwijająca się sprawa. W chwili pisania nie podano czasu przywrócenia usług, a Google nie opublikował analizy przyczyny źródłowej.
Co się wydarzyło
Awaria Google Cloud
Strona statusu Google odnotowała początek incydentu na poniedziałek 19 października, godz. 23:08 PDT — czyli 06:08 UTC we wtorek. Opis był charakterystycznie lakoniczny: „Wiele usług Google Cloud doświadcza podwyższonej liczby błędów i przerywanych awarii sieci w regionie europe-west2".
Wśród dotkniętych usług wymieniano BigQuery, App Engine, Looker, Cloud SQL, Cloud Filestore oraz Google Kubernetes Engine, czyli bazy danych, orkiestrację kontenerów, pamięć masową i analitykę. Fundamenty, a nie dodatki.
Google zalecił klientom przeniesienie obciążeń do innych regionów, informował, że zespół inżynierski bada sprawę i przeprosił. The Register donosił, że nie podano szacowanego czasu naprawy ani żadnych obejść.
Co do przyczyny: administratorzy komentujący incydent publicznie przypisywali go awarii zasilania w londyńskim centrum danych — z zasilaniem już przywróconym i podnoszoną siecią. Google nie potwierdził tego oficjalnie w chwili pisania, więc należy traktować to jako wiarygodne doniesienie, a nie ustalony fakt. Dla porównania: własne raporty powypadkowe Google dla analogicznych awarii w regionach europe-west z 2020 i 2024 roku również prowadziły do zdarzeń zasilania, więc schemat jest prawdopodobny.
Szczegół, który ma największe znaczenie
Kilka relacji, w tym The Register, wskazuje, że awaria koncentrowała się w strefie europe-west2-b — jednej z trzech stref dostępności regionu londyńskiego.
Strefy dostępności istnieją właśnie po to, żeby coś takiego nie mogło się zdarzyć. To fizycznie oddzielone domeny awarii, a cała obietnica architektoniczna brzmi: utrata jednej ma być do przeżycia. Awaria ograniczona do jednej strefy powinna być dla dobrze zaprojektowanych systemów niedogodnością, a nie ogólnokrajowym zdarzeniem płatniczym.
To, że nią nie była, stawia niewygodne pytanie przed każdą organizacją z listy poszkodowanych: czy te systemy naprawdę były wielostrefowe, czy tylko nominalnie?
Co powiedział i zrobił Revolut
Strona statusu Revoluta pokazywała większość usług jako niedostępne lub częściowo niedostępne, w tym płatności kartą i wypłaty z bankomatów. Publiczne oświadczenie firmy potwierdzało zakłócenie, zapewniało o bezpieczeństwie pieniędzy i danych, informowało, że prace nad usunięciem problemu trwają od rana, i zawierało przeprosiny. Firma zapowiedziała aktualizację dla klientów około 09:30 UTC.
Osoba zaznajomiona ze sprawą przekazała agencji Reuters, że awaria Revoluta była związana z zakłóceniami Google Cloud.
Dlaczego akurat Revolut
Zależność Revoluta od Google Cloud nie jest ani tajemnicą, ani nowością. Gdy Google uruchamiał region londyński w 2017 roku, współzałożyciel i CTO Revoluta Vladyslav Yatsenko był cytowany w oficjalnym komunikacie Google, opisując Google Cloud jako rozwiązanie pozwalające Revolutowi zachować zwinność przy jednoczesnym zapewnieniu bezpiecznych i niezawodnych usług w dużej skali.
To długoletnia decyzja architektoniczna podjęta z dobrych powodów — i w normalny dzień stanowiąca przewagę. Dla banku zbudowanego natywnie w chmurze, bez starego centrum danych, chmura jest bankiem.
Jedno zastrzeżenie do pierwotnego ujęcia tematu: mówi się, że Revolut opiera na infrastrukturze Google całe zaplecze, aplikację mobilną i narzędzia antyfraudowe. Revolut jest ewidentnie dużym klientem Google Cloud, a awaria ewidentnie dotknęła kluczowych usług płatniczych, ale ani Revolut, ani Google nie opublikowały opisu architektury. Bezpieczniej mówić o „systemach kluczowych" niż o „wszystkim".
Podobnie nie udało się zweryfikować liczby 36 dotkniętych usług Google. Strona statusu mówi o „wielu usługach" i wymienia zbiór obejmujący te wyliczone wyżej. Jeśli liczba ma pojawić się w tekście, warto ją wyraźnie przypisać do źródła albo pominąć.
Dlaczego to ma znaczenie
Ryzyko koncentracji przestało dziś rano być teoretyczne. Pojedynczy region — a właściwie prawdopodobnie pojedyncza strefa — u jednego dostawcy jednocześnie obniżył sprawność bankowości detalicznej, poczty, firmy kurierskiej i części NHS. Żaden napastnik tego nie osiągnął. Mogła to zrobić jedna rozdzielnica.
Banki natywnie chmurowe mają inny profil awarii. Tradycyjny bank z własnymi centrami danych psuje się powoli i częściami. Bank chmurowy pada równo i w całości, a potem równo i w całości wraca. Żaden model nie jest z założenia lepszy, ale drugi koncentruje ryzyko w zależności od tego, który bank nie obsługuje i nie może samodzielnie naprawić.
Strefy dostępności to obietnica, a nie coś, co automatycznie wykorzystujesz. Płacenie za region z trzema strefami nie czyni Twojej aplikacji wielostrefową. Jeśli baza danych ma instancję główną w jednej strefie, a przełączenie awaryjne nigdy nie było testowane, masz architekturę jednostrefową i wielostrefową fakturę.
Płatności są dziś infrastrukturą krytyczną. Gdy ludzie nie mogą kupić obiadu, różnica między „awarią usług finansowych" a „zdarzeniem publicznym" znika. Regulatorzy w UE i Wielkiej Brytanii budowali ramy dokładnie pod ten scenariusz. Unijne rozporządzenie DORA obejmuje ryzyko ICT stron trzecich w podmiotach finansowych, a Brytyjczycy mają reżim krytycznych dostawców zewnętrznych dla takich podmiotów jak wielcy dostawcy chmury. Dzisiejszy dzień to scenariusz, pod który te przepisy napisano.
I uwaga kontekstowa. Revolut miał trudny wrzesień — donoszono o dwóch odrębnych incydentach dotyczących danych, w tym jednym u dostawcy zewnętrznego. Tamte sprawy dotyczyły bezpieczeństwa. Dzisiejsza nie. Mieszanie ich byłoby nierzetelne, ale skumulowany efekt wizerunkowy u klientów jest realny niezależnie od kategorii.
Kogo to dotyczy
Klientów Revoluta w Wielkiej Brytanii, Irlandii i Europie — w samej Irlandii to około 3,4 miliona osób — bez możliwości płacenia kartą, wypłacania gotówki, robienia przelewów i logowania się.
Klientów innych dotkniętych banków, w tym Lloyds, HSBC, Halifax i ING Germany.
Royal Mail i DPD, z zakłóconymi operacjami doręczeń i śledzenia przesyłek.
Usług NHS England, co przypomina, że ochrona zdrowia działa na tej samej powszechnej infrastrukturze co wszystko inne.
Każdego, kto hostuje w europe-west2, łącznie z firmami bez medialnego rozgłosu, które po prostu dziś nie działają.
Sprzedawców, którzy stracili transakcje klientów mających przy sobie wyłącznie kartę Revoluta.
Co powinny zrobić organizacje
Dziś, jeśli jesteś dotknięty awarią
Sprawdź, czy Twoje obciążenia mogą przejść do innego regionu i czy ktokolwiek ma uprawnienia, by to uruchomić. Zalecenie Google brzmiało: przenieście zasoby gdzie indziej, co pomaga wyłącznie tym, którzy to wcześniej zaprojektowali.
Komunikuj wcześnie, konkretnie i wielokrotnie. Przekaz Revoluta był szybki i jasny w najważniejszej kwestii: pieniądze są bezpieczne. Klienci znoszą awarie znacznie lepiej niż ciszę.
Ostrzeż klientów przed phishingiem już teraz. Po awariach niezawodnie pojawiają się oszustwa „zweryfikuj konto" i „odbierz rekompensatę". Wskaż kanały, których będziesz używać.
Utrzymuj ręczną ścieżkę awaryjną dla kluczowych procesów klienckich, choćby w formie ograniczonej.
Architektura
Zweryfikuj nadmiarowość stref, zamiast ją zakładać. Potwierdź, że bazy danych, pamięci podręczne, kolejki i warstwy sterowania mają aktywne repliki w innych strefach — i że przełączenie awaryjne było testowane pod obciążeniem, a nie tylko w teorii.
Testuj failover regularnie i celowo. Jeden z administratorów w dzisiejszych dyskusjach zgłosił bazę danych, która po przełączeniu nie wstała. Tak właśnie wygląda nieprzetestowany failover.
Traktuj awarię całego regionu jako wymaganie projektowe, a nie przypadek skrajny. Dla usług o znaczeniu systemowym uczciwą odpowiedzią jest architektura wieloregionalna, a dla części — wielochmurowa, ze wszystkimi kosztami i złożonością, jakie to niesie.
Zmapuj swoje pojedyncze punkty awarii, również te, których nie jesteś właścicielem. Większość organizacji nie potrafi dziś odpowiedzieć: „które z naszych krytycznych usług dzielą jeden region chmurowy?".
Ład korporacyjny i regulacje
Udokumentuj zależności ICT od stron trzecich. Zgodnie z DORA podmioty finansowe w UE muszą prowadzić rejestr informacji o umowach z dostawcami ICT oraz mieć strategie wyjścia i ciągłości działania dla dostawców krytycznych. Ten incydent jest praktycznym sprawdzianem, czy Twój rejestr odpowiada rzeczywistości.
Zadawaj dostawcom trudne pytania o izolację stref. Jeśli awaria zasilania w jednej strefie potrafi obniżyć sprawność całego regionu, to powinno wpływać na Twoje decyzje architektoniczne.
Przećwicz zegar regulacyjny. Incydenty operacyjne tej wagi wiążą się z obowiązkami zgłoszeniowymi. Wiedz, kto zgłasza, do kogo i w jakim czasie — zanim będzie to potrzebne.
Dla klientów — teraz
Miej przy sobie alternatywną metodę płatności. Dzisiejsza lekcja dla osób prywatnych brzmi po prostu: nie polegaj na jednej karcie ani jednej aplikacji.
Nie ponawiaj nieudanych płatności bez sprawdzenia — po przywróceniu systemów podwójne obciążenia są częste.
Ignoruj nieoczekiwane wiadomości dotyczące awarii, zwłaszcza te proszące o potwierdzenie danych lub obiecujące rekompensatę.
Podsumowanie
Nie ma tu czarnego charakteru. Nikt nie został zhakowany, nic nie zostało wykradzione, a inżynierowie obu firm mają dziś znacznie gorszy dzień niż ktokolwiek, kto o tym czyta. To, co się stało, jest bardziej przyziemne i bardziej pouczające: domena awarii, która miała zostać odizolowana, nie została — a skutki rozeszły się na wszystkie organizacje, które po cichu zakładały, że będzie inaczej.
Lekcja: odporności nie kupuje się od dostawcy chmury — buduje się ją na nim. Google sprzedaje trzy strefy dostępności w Londynie. To, czy Twój bank, szpital albo sieć kurierska faktycznie wykorzysta wszystkie trzy, jest decyzją podjętą wewnętrznie, lata wcześniej, zwykle pod presją kosztów i rzadko testowaną.
Druga lekcja dotyczy widoczności. Większość organizacji z dzisiejszej listy prawdopodobnie nie potrafiłaby wczoraj powiedzieć, że dzieli pojedynczy punkt awarii z pocztą i służbą zdrowia. Mapowanie zależności to żmudna, nieefektywna praca, która nie wytwarza żadnej funkcji nadającej się do zaprezentowania — i jedyny sposób, by wiedzieć, co się z Tobą stanie, gdy centrum danych w Londynie straci zasilanie.
Dwa pytania na ten tydzień, gdy już wskaźniki zrobią się zielone: czy Wasze przełączenie do innej strefy kiedykolwiek faktycznie wykonało się pod obciążeniem — i czy wiecie, którzy z Waszych krytycznych dostawców siedzą w tym samym regionie co Wy?
