A jó tanuló megbukott: nem a Google leállása volt a Revolut legnagyobb hibája

Neked is gondod akadt október 20-án kedd reggel a kávéd kifizetésével, amikor Revolut-oddal szerettél volna fizetni? Nem csak te jártál így.

A Revoult 8 – 12 órán át tartó leállásáról eredetileg csak egy LinkedIn postot akartam írni, de végül annyi szempont merült fel menet közben, hogy úgy gondoltam érdemes részletesebben vizsgálni az esetet és tanulságait. A Revolut ugyanis szerintem mindig is a pénzügyi szolgáltatások jó tanulója volt, egészen mostanáig. Ugyanakkor a probléma rajtuk is túlmutat. 

Aki lemaradt volna: 2026. október 20-án a Revolut mobil alkalmazása és kártyái Európa-szerte működésképtelenné váltak az ügyfelek számára. És bár ez – joggal – sovány vigasznak tűnhet az ügyfelei számára, a probléma a Revolut rendszerénél egy réteggel mélyebben keletkezett.

A hiba a Google-nél keletkezett, a felelősség a Revolutnál maradt

A Revout leállása mögött ugyanis a Google Cloud meghibásodása állt. 

Érdemes tudni, hogy az olyan nagy felhőszolgáltatók, mint az Amazon Web Services (AWS), a Microsoft Azure és a Google Cloud, világszerte helyi vagy regionális létesítményekben teszik elérhetővé szolgáltatásaikat ügyfeleik számára, ezeket a földrajzilag elkülönülő egységeket „régióknak” nevezik.

A Google Cloud kedden reggel közzétett állapot frissítéseiben arról számolt be, hogy több felhőszolgáltatásánál „megnövekedett hibaszám és időszakos hálózati kiesések” tapasztalhatók az europe-west2 régióban, vagyis a londoni brit felhőszolgáltatási létesítményében.

A vállalat később közölte, hogy a problémákat az egyik kisebb adatközponti zónájában, az europe-west2-b egységben történt „áramellátási esemény” okozta.

A fennakadások elsősorban brit platformokat és szolgáltatásokat érintettek. 

Mi itt Magyarországon a Revolut leállását szenvedhettük meg, de az Egyesült Királyságban még ettől is szélesebb volt az érintett szolgáltatások köre, a felhasználók többek között a Royal Mail postai szolgáltatásnál és DPD csomagküldő cégnél is problémákat tapasztaltak. 

Ezen felül az incidens érintette azt a brit videorendszert is, amelyet a vádlottak, az ügyvédek és más felek arra használnak, hogy távolról vegyenek részt bírósági tárgyalásokon egész Angliában és Walesben, a szolgáltatás pedig az egész délelőtt folyamán nem működött.

De kétségtelenül a bankok tartoztak a legsúlyosabban érintett szolgáltatók közé, az angoloknál nem csak a Revolut, hanem inkumbens bankok így a Lloyd és a HSBC is érintettjei voltak a súlyos incidensnek. 

Mindezzel együtt emlékezetnék arra a fontos szolgáltatási alapelvre, ami a pénzügyi szolgáltatásoknál a szabályozásokban is benne szokott lenni, hogy a kiszervezés nem szünteti meg a – jelen esetben – pénzügyi intézmény felelősségét. 

Vagyis végső soron a bank akkor is felelős marad a kritikus szolgáltatásai fenntartásáért, ha a meghibásodás egy külső technológiai szolgáltatónál következik be.

A Revolut kommunikáció elvérzett

Sokat írtam már a Revolut-ról, akiket az egyik legjobb product company-nak tartok, ebben az incidensben viszont nem elég cudarul teljesítettek. 

A nap nagy részében elmaradt a tájékoztatás

A Revolut status oldalon 07:47-kor jelezték a kártyás fizetésekkel kapcsolatos problémát, az X-en pedig – feltehetően a magyar időt mutatja – 09:54-kor tettek közzé a problémáról bejegyzést.

Ezt követően azonban órákon át ez maradt az egyetlen tájékoztatás, amelyet a Revolut az X-en megosztott. Facebook-ra is ugyanaz a két poszt ment ki, nagyjából hasonló időben – reggel és nap végén -, azaz úgy 9 óra 45 percen át a vállalat nem kommunikált semmilyen fejleményről az ügyfelei felé.

És délben ugyan a Revolut nyilatkozott a sajtónak, azonban az ügyfelek felé nem posztolt semmit, azaz média kapott frissítést, az ügyfél nem. A Google 16:00-kor lezárta az incidenst, a Revolut 3,5 órával később szólt, és erre semmilyen magyarázatot nem adott.

Ez most vagy azt jelenti, hogy a saját rendszereik lassabban álltak vissza, vagy azt, hogy jóval a tényleges helyreállás után szóltak, bármi legyen is igazság, mindkét verzió rosszul fest. 

E-mail másnap, tovább növelve a zavart

Másnap reggel érkezett még egy emailben tájékoztatás, ami természetesen nem haszontalan, de nem helyettesíti a – Revoult által elmulasztott – kiesés közbeni, proaktív tájékoztatást.

A levélben azt írják, hogy a kártyás tranzakciók és a visszatérítések napokig is késhetnek. Ez például egy olyan információ, ami a kiesés közben aranyat ért volna, mert ettől nem fizetett valaki kétszer, vagy nem pánikol a hiányzó pénz miatt – közben ez csak egy nappal később derült ki.

Az ügyfélszolgálat elérhetetlen

Az incidens során kiderült, hogy a Revolut szinte teljes egészében az in-app chatre épülő ügyfélszolgálata saját farkába harapó kígyónak bizonyult. 

A chat ugyanis az incidensben érintett szolgáltatások közé tartozott, így a felhasználók vagy nem tudták használni, vagy egy részük be sem tudott lépni, ezért még elméleti esélyük sem maradt, hogy eljussanak a supporthoz. 

A pontosság kedvéért megemlítem, hogy az Ultra csomaggal rendelkezőknek jár a telefonos ügyfélszolgálat de csak appon belüli hívásként, és csak angolul. Elég kínos, hogy ugyanez már az Egyesült Királyságban és Írországban már minden csomagban elérhető, de a kulcsszó megint csak, hogy “„appon belül”. 

Mi kell ahhoz, hogy egy leállás ne legyen katasztrófa?

Ez az incidens úgy gondolom egy újabb példája annak, hogy az internet működése milyen mértékben függ néhány nagy tech vállalattól, és hogy egy-egy szolgáltatás kiesése milyen széles körű zavarokhoz vezethet.

Az ügy egyébként a digitális szuverenitásról szóló európai vita fontosságát is aláhúzza, azaz szükséges volna, hogy a kritikus infrastruktúrának meglegyen a szolgáltatás folytonossága, és szükség esetén legyenek alternatívák, ha változnak a körülmények. 

Hétköznapi userként mindenki levonta gondolom a tanulságot, azaz ne csak egy daily-banking szolgálatóra építs, mindig legyen backupod. Ami szolgáltatói szinten tanulság, alapjaiban nagyon hasonló.

A Monzo tartalékbankja: 18 szolgáltatás 3000 helyett

Már írtam arról, hogy a  Monzo rég felismerte, hogy a hagyományos hibatűrési mechanizmusok nem elegendők a ritka, de súlyos hibák kezelésére, ezért fejlesztették ki a a Monzo Stand-int, ami egy teljesen független, különálló rendszer. 

A Monzo Stand-in lényege, hogy a bank akkor is működőképes maradjon, ha a teljes elsődleges felhőinfrastruktúrája összeomlik. Nem pusztán egy biztonsági mentésről van szó, hanem egy második, önállóan működni képes banki rendszerről.

Hogyan működik?

• Teljesen független kódállomány és felhőszolgáltató: az elsődleges rendszer AWS-en, a tartalék Google Cloudon fut.
• Gyors, kontrollált átállás: a fejlesztők percek alatt bekapcsolhatják, akár egyes ügyfelekre, akár mindenkire. 2024 augusztusában, egy kb. egyórás, szinte minden rendszert érintő incidensnél először kapcsolták be minden ügyfélre, és közben is lehetett kártyával fizetni, utalni és egyenleget nézni.
• Minimális kritikus funkciók: 3000-nél több elsődleges mikroszolgáltatás helyett csak 18 tartalék szolgáltatást tart fenn, a normál platformköltség körülbelül 1%-án.
• Folyamatos működés és tesztelés: a Monzo Stand-in nem egy „porosodó” biztonsági rendszer. Tesztként mindig van néhány ügyfél, aki ezen fut, és az átállási útvonalakat folyamatosan, élesben tesztelik.

A Stand-in közben végrehajtott műveleteket rögzíti, majd az elsődleges rendszer helyreállásakor átadja neki az eredményeket. A visszaállás fokozatosan történik, nem automatikusan abban a pillanatban, amikor az AWS újra elérhető.

Amikor a Stand-in bekapcsol, a Monzo app egy leegyszerűsített felületre vált, ami a user oldaláról egy olyan képernyőt mutat, ami elmondja, hogy a Monzónál problémák vannak, és felsorolja, mely funkciók működnek. Az ügyfél tehát látja, hogy valamilyen technikai probléma áll fent, de tud fizetni, utalni és egyenleget nézni.

A jelenlegi Stand-in  elvi hátulütője, hogy abban a nagyon valószínűtlen esetben ha az AWS és a GCP egyszerre áll le, a Monzo Stand-in sem jelent automatikus megoldást. 

A két külön felhő használata még nem jelent teljes infrastruktúra-függetlenséget, a saját infrastruktúrán futó tartalékrendszer egy lehetséges következő védelmi réteg lenne.

Proaktív ügyfél kommunikáció incidens idején

A Monzo példája azt mutatja, hogy a kommunikáció lehet a termék része, de ehhez nem kell feltétlenül egy teljes tartalék bankrendszer, az alapelvek minden szolgáltatónál ugyanazok.

Először is a tájékoztatás csatornája nem függhet attól a rendszertől, amelynek a kieséséről tájékoztat. A Revolutnál sajnos az ügyfélszolgálat és az értesítések is az appon belül futnak, így pont akkor váltak elérhetetlenné, amikor a legnagyobb szükség lett volna rájuk. 

A status page-nek, a push- vagy SMS-értesítésnek és egy vészhelyzeti ügyfélszolgálati csatornának az elsődleges infrastruktúrától függetlenül kell működnie.

A második szint a kadencia. Egy kiesés alatt nem az a kérdés, hogy van-e új információ, hanem hogy az ügyfél tudja-e, mire számíthat. 

Négy dolgot érdemes minden frissítésben kommunikálni:

•  mi nem működik
•  mi működik
• mit tegyen az ügyfél (például fizessen más kártyával)
• és mikor jön a következő frissítés. 

A harmadik szint a felkészülés. Ha a kommunikáció az incidenskezelési folyamat része, előre megírt és jóváhagyott sablonokkal, akkor nem marketingdöntés, hogy posztol-e valaki. Ilyen módon vélhetően el lehet kerülni, hogy 9 óra 45 perc teljen el két poszt között.

Hozzá kell tennem, hogy kívülről nem tudjuk, hogy a Revolut értesítési rendszerei is leálltak-e, vagy tudatos döntés volt a hallgatás. De bármi legyen is az ok, egyik sem üdvözítendő egy digitális banktól.

Vész esetére olyan csatorna, ami nem az appon keresztül vezet

Két olyan példa is van, akik szintén digitális bankok mégis “hagyományos ügyfélszolgálatban” is erősek.

Az egyik jó best practice megint csak a Monzo-tól jön. Bár az az appon belüli chat az elsődleges csatorna náluk, de van ingyenes telefonszám is. A súgójuk kifejezetten azt írja, hogy ha nem éred el az appot, hívd a xy számot, vagy írj a help@monzo.com-ra. A support telefonszáma a Monzo  bankkkártyák hátoldalán is szerepel.

A másik jó példa a neobankok között különben legendás Starling, ahol alapvetően szintén az app a leggyorsabb út, de telefonon és e-mailben is elérhetők, 0–24-ben.

Mindebből azt a következtetést lehet levonni hogy az egyik oldalról a proaktív kommunikáció az ügyfélszolgálat terhelésének első védvonala. Ha az ügyfél pontosan tudja, mi nem működik, mi igen, és mikor jön a következő frissítés, akkor nem kell telefonálnia.

Az másik oldalról az app-független ügyfélszolgálat így a sürgős esetekre marad: csalás, külföldön ragadt ügyfél, kártyaletiltás.

Három megoldás adja ki az ellenálló modellt

A Revolut incidens tanulságaiból és a más szolgáltatók által már alkalmazott megoldásokból három layer rajzolódik ki, amely kiadhat egy igazán ellenálló modellt: 

1. Független tartalék rendszer: a bank alapvető funkciói akkor is működhetnek, ha az elsődleges felhő-infrastruktúra kiesik.
2. Független és proaktív ügyfél-kommunikáció: a bank azonnal értesítheti az ügyfeleket, és megmutathatja, mely funkciók érhetők el.
3. Legyen legalább egy valós idejű csatorna, ami nem az appon keresztül vezet, és a kártya hátoldalán is ott van.

A három rétegben az a közös, hogy a tartalék nem függhet attól a rendszertől, amelynek a kiesésére felkészít. Míg az első réteg költséges és évekig tarthat felépíteni, addig második és a harmadik viszonylag olcsó, és teljesen a bank/szolgáltató kezében van.

A Revolut eddig a pénzügyi szolgáltatások és úgy általában a digitális productok jó tanulója volt, amit a mostani incidens ugyan nem ír teljesen felül, de jó emlékeztető arra, hogy még a legjobb cégnél is a hiba a szolgáltatás igazi vizsgája, ahol nem az számít, hány featue van az appban, hanem, hogy mi marad belőle, amikor nem működik.