A lényeg röviden (TL;DR):
- Mi történt? November 18-án globális leállás volt a Cloudflare-nél, ami miatt rengeteg weboldal, webshop és céges szoftver elérhetetlenné vált.
- Mi volt az ok? Nem hackertámadás, hanem egy belső szoftverhiba egy rutin karbantartás után.
- Miért érint téged? Még ha nem is fizetsz közvetlenül a Cloudflare-nek, a szoftvereid (SaaS) vagy a beszállítóid valószínűleg igen.
- A megoldás: Mi is használjuk a rendszert, de nálunk van “vészgomb”. Az ügyfeleinknél kikerültük a hibás szolgáltatót, így ők alig éreztek valamit.
Ha tegnap dél körül (magyar idő szerint 12:20-kor) úgy érezted, hogy hirtelen “elment a net”, vagy furcsa hibaüzeneteket dobáltak a kedvenc szoftvereid, nem voltál egyedül. És nem, nem a routereddel volt a baj.
Az internet egyik óriása, a Cloudflare botlott meg, és mivel a világháló forgalmának jelentős részét ők kezelik, az esés fájdalmas volt. De mit jelent ez a te cégednek, és mit tanulhatsz belőle vezetőként?
Mi az a Cloudflare és miért van mindenhol?
Hogy értsd a probléma súlyát: a Cloudflare az internet “kidobóembere” és forgalomirányítója egyben. Ők védik meg a weboldalakat a támadásoktól, és ők gyorsítják fel a betöltést.
Képzeld el úgy, mint egy pláza bejáratát. Ha a biztonsági szolgálatnál (Cloudflare) rendszerhiba lép fel, és lezárják a kapukat, senki nem jut be a boltokba (a te weboldaladra vagy a webshopodba). Hiába van nyitva az üzlet, hiába van áru a polcon, a vevők kint rekednek.
Kedden pontosan ez történt. Egy technikai hiba miatt a “digitális kapuk” bezárultak.
Nem hackerek, hanem egy rossz fájl
A pánik során sokan azonnal kibertámadásra gyanakodtak. A valóság azonban sokkal prózaibb – és éppen ezért ijesztőbb – volt. Egy “latent bug”, azaz egy rejtett szoftverhiba okozta a bajt.
A cég mérnökei egy rutin karbantartást végeztek, ami után egy biztonsági konfigurációs fájl túl nagyra hízott. Amikor a rendszer megpróbálta ezt “megenni”, megakadt tőle. Az eredmény: 500 Internal Server Error világszerte.
Miért használjuk mi is, és hogyan kezeltük a helyzetet?
Nem árulok el titkot: mi is használjuk a Cloudflare-t a rendszereinkben. Miért? Mert békeidőben verhetetlen: ez adja a tűzfalat, ez gyorsítja a betöltést, és ez tartja távol a spambotokat és a kártékony támadókat az ügyfeleink oldalaitól.
De mi nem bíztuk a véletlenre. Amikor beütött a krach, mi nem pánikoltunk, hanem cselekedtünk:
- Tájékoztatás: Azonnal szóltunk azoknak az ügyfeleinknek, akiknél ez a védelem aktív volt, hogy tudják, nem az ő oldalukkal van a baj.
- Azonnali megoldás: Nálunk a rendszer eleve úgy van kiépítve, hogy baj esetén van lehetőség a Cloudflare “kikerülésére” (bypass). A kritikus fontosságú oldalaknál ezt a vészmegoldást élesítettük is, így az adatforgalom a hibás kaput megkerülve, közvetlenül érkezett a szerverekre.
Az eredmény? Az ügyfeleink oldalai működtek, amíg a világ fele még a hibaüzenetet nézte.
Mit tehetsz vezetőként? 3 lépés a jövőre nézve
Nem tudsz leválni a globális rendszerekről, de felkészülhetsz – vagy választhatsz olyan partnert, aki felkészült.
1. Legyen “B-terved” a kommunikációra
Amikor leáll a webshop, az ügyfelek téged fognak hívni. Legyen egy előre megírt sablonod: “Tudunk a hibáról, központi üzemzavar van a nemzetközi szolgáltatónál, dolgoznak rajta.” A csönd bizalomvesztést szül, a gyors tájékoztatás profizmust sugall.
2. Auditáld a függőségeket (Kérdezd meg az IT-st!)
Tedd fel a kérdést a rendszergazdádnak: “Mi történik, ha a védelmi vonal leáll?” Van nálatok is lehetőség – ahogy nálunk –, hogy ideiglenesen kikerüljétek a hibás szolgáltatót, és működőképesen tartsátok az oldalt? Ha a válasz nem, érdemes elbeszélgetni a fejlesztőkkel.
3. Diverzifikálj!
A “ne tartsunk minden tojást egy kosárban” elv itt is igaz. Ha minden kritikus rendszered felhő alapú, egy internetkimaradás vagy felhő-hiba megbénítja a céget.
Összegzés: A tegnapi nap egy ébresztő volt. A technológia csodálatos, amíg működik. De a te feladatod, hogy olyan partnerekkel dolgozz, akiknél akkor is van terv, amikor a technika – akár csak pár órára is – cserben hagy.