Google Cloud-leállás: mi a terved, ha megáll a felhő?

A keddi Google Cloud-leállás nem azt bizonyította, hogy a felhő megbízhatatlan, hanem azt, hogy a legtöbb cég nem tudja, mitől függ. Egy kkv-nak nem saját adatközpont kell, hanem egy lista a kritikus szolgáltatásairól és egy B-terv arra a napra, amikor az egyik kiesik.

Google Cloud-leállás: mi a terved, ha megáll a felhő?

Rövid válasz: a keddi leállás nem a felhőről szólt, hanem a függőségről. Egy londoni adatközpontban nem indultak el a tartalék generátorok, és órákkal később emberek nem tudtak kártyával fizetni egy olyan bankkal, amelyről a legtöbben nem is tudták, hogy a Google-nél fut. Egy kkv nem fogja elkerülni, hogy a szolgáltatói egyszer leálljanak. Azt viszont eldöntheti, hogy aznap megáll-e vele az egész cég.

Mi történt?

A Google Cloud saját incidensbeszámolója szerint október 20-án 06:00 és 12:10 (UTC) között több szolgáltatás akadozott a londoni europe-west2 régióban. A kiváltó ok egy áramkimaradás volt az europe-west2-b zónát kiszolgáló adatközpontban. A tartalék generátorok vezérlése hibára futott, ezért nem indultak el; a létesítmény akkumulátorról ment, amíg bírta, aztán a zóna szerverei, hálózata és tárolói leálltak.

A legérdekesebb rész ezután jön. A Google szerint a gond nem maradt egy zónán belül: a másik két zónába átterelt forgalom és a zónák közötti függőségek miatt ott is lassulás és hibák jelentkeztek. Az érintett termékek listája mintegy ötven tételből áll, a virtuális gépektől az adatbázisokon át a terheléselosztásig. Az október 22-i előzetes jelentés szerint a teljes kivizsgálás még tart.

A következmény a hétköznapokban jelent meg. Az Irish Times szerint a Revolut ügyfelei Írországban és az Egyesült Királyságban órákig nem tudtak belépni, utalni, kártyával fizetni vagy készpénzt felvenni; a HWSW szerint a magyar ügyfelek jelentős része is érintett volt, a rendszerek a délutánra álltak helyre. A Revolut közölte, hogy az ügyfelek pénze és adatai biztonságban voltak. A Reuters (a The Star által átvett cikk) szerint a Lloyds és a HSBC is az érintettek között volt, a HWSW pedig a DPD-t, az NHS-t és a Royal Mailt is az érintettek között említi.

A hatóságok gyorsan reagáltak. A Reuters szerint az Európai Bankhatóság (EBA) felvette a kapcsolatot a Google Clouddal, a brit pénzügyi felügyelet (FCA) is egyeztet. Az EU tavaly 19 technológiai céget jelölt ki a pénzügyi szektor kritikus beszállítójának, és ez az új rendszer első komoly próbája.

Mit jelent ez egy kkv-nak?

Valószínűleg nincs Google Cloud-fiókod, és mégis érintett vagy. Ez a lényeg.

A bankod, a webshopmotorod, a könyvelőprogramod, a számlázód, a CRM-ed mind valakinek a felhőjében fut, és ritkán derül ki, kiében. A kedd azt mutatta meg, hogy egy ilyen láncban egyetlen áramkimaradás is elég ahhoz, hogy egy cég délelőttje elmenjen. Nem kell hozzá támadás, és nem kell hozzá rossz szándék.

Tipikus helyzet, hogy a cégnek egyetlen bankszámlája és egyetlen fizetési módja van. Ha azon a napon jár le a beszállítói határidő, vagy azon a napon kellene fizetni a bérleti díjat, a „néhány órás kiesés” már nem technikai kérdés. Ugyanez igaz a webshopra: ha a fizetési szolgáltató áll, a kosarak üresen maradnak.

A felhő ettől még nem rosszabb a saját szervernél. A saját gépterem is leáll, csak ott senki nem ír róla incidensbeszámolót. A különbség az, hogy a saját szervernél tudod, hol a kockázat. A felhőben ezt neked kell kideríteni. A felhőbe költözésről szóló cikkünkben is azt írtuk, hogy a felelősség megosztott: a szolgáltató az adatközpontért felel, azért viszont te, hogy mit csinálsz, ha valami nem elérhető.

A pénzügyi szektorban ezt már jogszabály mondja ki. A HWSW szerint a DORA-rendelet alapján a bank akkor is teljes felelősséggel tartozik, ha a rendszerét felhőszolgáltatóra szervezte ki. Egy kkv-ra nincs ilyen szabály. A logika attól még ugyanaz.

Mit tegyél most?

  1. Írd össze a kritikus szolgáltatásaidat. Melyik az az öt rendszer, amely nélkül egy napig sem működik a cég (bank, levelezés, számlázás, webshop, ügyviteli rendszer)? Mindegyik mellé írd oda, ki a szolgáltató, és kit hívsz, ha leáll.
  2. Legyen második fizetési csatornád. Egy második bankszámla vagy kártya egy másik banknál olcsó biztosítás arra a napra, amikor az első nem működik. Ugyanez a webshopnál: ha lehet, legyen tartalék fizetési mód.
  3. Kérdezd meg a fontos szoftverszolgáltatóidat: milyen felhőn és hány zónában fut a rendszer, mi történik egy adatközpont kiesésekor, és mit vállalnak a szerződésben a helyreállításra. Ha nincs válasz, az is információ.
  4. Készíts egyoldalas B-tervet. Ki dönt leállás esetén, hogyan értesítitek az ügyfeleket és a munkatársakat, és mi az a minimális, papíron vagy offline is elvégezhető folyamat, amivel a nap átvészelhető.
  5. Legyen saját másolatod a legfontosabb adatokról. Ügyféllista, nyitott számlák, aktuális rendelések: ne csak a szolgáltató felhőjében legyenek elérhetők.

Ha szeretnéd, hogy valaki végignézze, mitől függ a céged működése, és hol érdemes tartalékot építeni, nézd meg az infrastruktúra szolgáltatásunkat.

Források

Caster Consulting

A Caster Consulting Kft. AI-megoldásokra, folyamatautomatizálásra, IT outsourcingra és IT tanácsadásra szakosodott magyar IT tanácsadó cég, amelynek csapata az USA-tól Kínáig vezetett projekteket.

Kövessen minket LinkedInen →

Átbeszélné, mit jelent ez a cégének?

Egy díjmentes, 30 perces beszélgetésben átnézzük a helyzetét, és őszintén megmondjuk, mivel érdemes kezdeni.

Időpontot kérek