Revolut a britské banky bez služeb: co ukázal výpadek Google Cloud

Když přestanou fungovat platby, zákazníka nezajímá, který dodavatel právě řeší problém. Potřebuje zaplatit, dokončit objednávku nebo se dostat ke svému účtu. Výpadek z 20. října 2026 ukázal, jak rychle se problém infrastruktury může přenést do běžného života i firemního prodeje.

Co je u tohoto výpadku potvrzeno

Google v konečné zprávě z 27. října 2026 spojil výpadek londýnské zóny europe-west2-b s výpadkem externího napájení a chybnou konfigurací řízení automatického spouštění generátorů. Přesměrování zátěže zatížilo sousední zóny a některé řídicí závislosti. Incident podle zprávy trval celkem šest hodin a osm minut, z toho hlavní dopad přibližně pět a půl hodiny. Konečná zpráva Google Cloud.

AP mezi bankami s problémy uvedla Revolut, Lloyds, Halifax a HSBC. Reuters u Revolutu popisoval i narušené platby kartou, převody a výběry. Obnova jednotlivých bankovních funkcí měla vlastní průběh. AP, Reuters.

Bezpečnost zahrnuje i schopnost fungovat

Uvedené podklady popisují technický výpadek. Nepotvrzují hackerský útok ani příčinu v AI. Pro firmu je však výsledná otázka stejně naléhavá: jak dlouho dokážeme zůstat bez kritické služby a co se mezitím stane s objednávkami a daty?

Ochrana před napadením a provozní odolnost se doplňují. Firma může mít dobře chráněné přístupy, a přesto nemít připravenou obnovu po poruše. Při auditu proto nestačí podívat se jen na viditelnou webovou stránku. Potřebujete znát i databázi, úložiště, přihlašování, DNS, platby a externí rozhraní.

Dva servery ještě nemusí znamenat nezávislou zálohu

Při návrhu záložního provozu si položte otázku, co oba systémy sdílejí. Stejný region, správa identit, síť, řídicí služba nebo přístupy mohou vytvářet společný bod selhání. Záložní prostředí navíc potřebuje kapacitu a aktuální data.

To neznamená, že každá firma potřebuje nejdražší infrastrukturu. Rozsah má vycházet z dopadu výpadku. Pro některou službu postačí ověřená obnova; kritický prodejní proces může potřebovat připravené přepnutí a omezený režim provozu.

Co prověřit ve firemních systémech

• Které služby potřebuje interní systém, přihlašování zaměstnanců a zpracování objednávek?
• Jak se eviduje platba, jejíž výsledek přijde se zpožděním?
• Dokážou zaměstnanci a zákazníci bezpečně pokračovat bez ztráty dat či duplicitních úkonů?
• Kdo rozhodne o přepnutí na záložní provoz a podle jakých podmínek?
• Kde jsou uložené kontakty a postupy, pokud nefunguje běžná administrace?
• Kdy naposledy proběhl praktický test obnovy?

Čím začít bez zbytečné složitosti

Sepište kritické služby, jejich vlastníky a přípustný výpadek. Připravte konkrétní scénář: hlavní interní systém neodpovídá, zaměstnanci potřebují pracovat a integrace čekají na potvrzení. Ověřte, kdo co udělá a jak se po návratu sesouladí nová data a nedokončené úlohy. U e-shopu navíc otestujte objednávky, platby a sklad.

Pokračujte článkem Failover, RTO a RPO: jak připravit rychlý návrat do provozu.