A függőségek valódi költsége: mit tanít a Downdetector kiesése?

Egy webáruház működését nem védi meg önmagában az, hogy két helyen fut az alkalmazása. Ha mindkét példányt ugyanazon a hálózati kapun keresztül lehet elérni, vagy ugyanaz a beléptető szolgáltatás kell hozzájuk, annak hibája mindkettőt használhatatlanná teheti. A redundancia értékét ezért a teljes üzleti útvonalon kell vizsgálni.

A Downdetector története jó kiindulópont ehhez, de nem bizonyítja, hogy minden vállalkozásnak több felhőt kell használnia. Egy magyar KKV számára a feladat az, hogy megnevezze az elfogadható kiesést, kiszámolja a védekezés költségét, és kipróbálja a vállalt helyreállítást.

A történet 2025 novemberében történt

A Cloudflare 2025. november 18-i incidense 11:20 UTC-kor kezdődött. A vállalat jelentése szerint egy adatbázis-jogosultság módosítása megváltoztatta a botvédelmi konfiguráció előállítását. A keletkező fájl túllépte a feldolgozó szoftver korlátját, és a hálózaton szétterített hibás adat szolgáltatási hibákhoz vezetett. A Cloudflare ezt nem kibertámadásnak minősítette. A Cloudflare elsődleges incidensjelentése.

A Downdetector érintettségéhez fontos kiegészítés tartozik: már több régióban és több felhőben működött. A DNS, a tartalomkiszolgálás és a botvédelem szintjén azonban Cloudflare-függősége maradt. Ezt a The Pragmatic Engineer szerzője az Ookla mérnöki vezetőjével folytatott beszélgetésére hivatkozva írta le. Ez a vállalati vezetőtől származó, újságíró által közvetített információ; nem nyilvános rendszerleltár vagy független audit. Az eredeti interjús beszámoló.

Az esetből az következik, hogy a háttérrendszer földrajzi és szolgáltatói szétválasztása mellett is lehet közös belépési pont. Azt viszont a rendelkezésre álló adatokból nem lehet megállapítani, hogy a Downdetectornak üzletileg megérte volna minden ilyen függőséget kiváltania.

Először az üzleti funkciót térképezzük fel

A leltár ne a szerverek számával kezdődjön. Kövessünk végig egy rendelést vagy ajánlatkérést a cím beírásától a munkatárs értesítéséig. A DNS a név feloldását végzi, a CDN közeli kiszolgálást és gyorsítótárazást adhat, a beléptetés jogosultságot ellenőriz, a monitoring pedig hibát jelez. Mindegyik külön függőség, akkor is, ha egy szolgáltató számlázza őket.

Az alábbi kitölthető tábla a saját rendszer áttekintésére szolgál. A helyreállítási célhoz időtartamot írjunk, a felelőshöz személyt vagy szerződésben megnevezett csapatot. A „tárhelyes megoldja” nem végrehajtható felelősségi rend.

Üzleti funkció	DNS / CDN	Azonosítás	Monitoring	Közös szolgáltató	Kiesési következmény	Felelős	Helyreállítási cél
Termékkatalógus	…	…	…	…	…	…	…
Rendelés / ajánlatkérés	…	…	…	…	…	…	…
Belső adminisztráció	…	…	…	…	…	…	…
Ügyféltájékoztató oldal	…	…	…	…	…	…	…

A táblázat mögött a kezelőfelületek hozzáféréseit is vizsgáljuk. Ha az átkapcsoláshoz szükséges belépés ugyanattól a kiesett szolgáltatótól függ, a tartalék infrastruktúra létezése nem oldja meg az incidenst. Ugyanez igaz a jelszótárolóra, a többtényezős azonosításra és a csapat riasztási csatornájára.

Mennyi kiesést akarunk kivédeni?

A helyreállítási idő célértéke, az RTO azt rögzíti, mennyi időn belül kell visszahozni egy funkciót. Az RPO az elfogadható adatvesztési időablak: például mennyi friss adat hiányozhat egy visszaállított mentésből. Ezek vezetői vállalások, amelyekhez a műszaki csapat megoldást és költséget rendel.

Egy tájékoztató oldalnál elfogadható lehet az ideiglenes elérhetetlenség. Egy rendelésrögzítőnél viszont külön kell kezelni a már elfogadott és a még el nem küldött megrendelést. A fizetés sikeréről kapott értesítés elvesztése más hiba, mint egy termékkép lassú megjelenése. A célértékeket ezért funkciónként, nem egyetlen weboldalszintű számmal érdemes megadni.

A beszállítói rendelkezésre állási vállalás sem azonos a saját helyreállítási idővel. A vállalkozásnak az értesüléshez, a döntéshez és a beavatkozáshoz is idő kell. Ha csak munkaidőben van elérhető rendszergazda, ezt a feltételt a hétvégi működés tervében is szerepeltetni kell.

Szemléltető költségmodell forintban

Az alábbi adatok feltételezések, nem piaci árak és nem ügyfélmérések. Tegyük fel, hogy egy nagykereskedő portálja egy kieséssel érintett órában 200 000 Ft nettó árbevételt közvetítene, ennek fedezeti hányada 25%. A rendelések 60%-a később visszatér. Az elvesző fedezet így óránként 200 000 × 0,25 × 0,40 = 20 000 Ft.

Ha a vizsgált hibafajtából évente összesen 12 kiesési órát feltételezünk, a kieső fedezet 240 000 Ft. Ehhez adjunk feltételezett 120 000 Ft incidenskezelési többletköltséget: az éves modell 360 000 Ft kárt mutat. Ez nem előrejelzés; a feltételezéseket saját forgalmi és hibajegyekből kell majd pontosítani.

Tegyük mellé a tartalék rendszer feltételezett árát: 600 000 Ft egyszeri kiépítés, évi 240 000 Ft szolgáltatási díj és 180 000 Ft próba, frissítés, munkaidő. Három évre egyenletesen elosztva a kiépítést, az éves összehasonlító költség 620 000 Ft. Még az összes modellezett kár kivédése mellett is drágább a tartalék, és a valóságban nem minden hibát védene ki.

Ha viszont ugyanilyen feltételekkel 40 kiesési órával számolunk, a veszteség 920 000 Ft lenne. Ebben az esetben már érdemes részletesebben vizsgálni a beruházást. A döntéshez hozzáadandó a szerződéses következmény és az elveszett ügyfélkapcsolat, ha ezek becsülhetők; ugyanazt a bevételkiesést viszont ne számoljuk el kétszer.

A tartalék útvonal ne legyen hátsó ajtó

Egy DNS-átírás nem garantál azonnali átkapcsolást: korábbi válaszok gyorsítótárban maradhatnak. Az alternatív kiszolgálón működő TLS-tanúsítvány, megfelelő kapacitás, naprakész alkalmazás és ellenőrzött adatkapcsolat kell. A munkamenetek folytonosságát sem szabad feltételezni.

Külön veszély, ha a védekezéshez nyilvánossá tesszük az eredeti szervert, miközben eltűnik előle a webes tűzfal vagy a kérésszám-korlát. A tartalék útvonalon ugyanúgy szükséges a hozzáférések ellenőrzése, a naplózás és a támadások elleni védelem. Ha ez nem biztosítható, biztonságosabb lehet egy korlátozott tájékoztató oldal, amely nem fogad fizetést vagy érzékeny adatot.

Egy külön szolgáltatónál lévő állapotoldal hasznos lehet, de annak névfeloldását és beléptetését is ellenőrizni kell. A másik logóval ellátott szolgáltatás mögött is maradhat ugyanaz a közös technikai függőség.

Kipróbálható helyreállítási forgatókönyv

1. Észlelés: külső ellenőrzés vizsgálja a valódi üzleti útvonalat. A puszta kezdőoldal-letöltés nem bizonyít működő rendelést.
2. Döntés: a kijelölt felelős összeveti a hibát az átkapcsolási feltételekkel. Nem minden lassulás indokol költöztetést.
3. Beavatkozás: dokumentált lépések, elérhető hozzáférések és ellenőrzött tartalék védelem szükséges. A változtatás időpontját rögzítjük.
4. Ellenőrzés: próbamegrendelés vagy tesztajánlat igazolja a működést. Az ügyfelek tájékoztatása külön feladatot és felelőst kap.
5. Visszaállás: egyeztetjük a közben keletkezett adatokat, kizárjuk a kettős feldolgozást, majd ellenőrzött módon visszatérünk.

A próbát olyan kolléga is hajtsa végre, aki nem építette a rendszert. Mérjük meg, mennyi idő telt el az első jelzéstől a funkció helyreállításáig, és mi akadályozta a munkát. A negyedéves próba lehet kiinduló vállalás, de az ütemezést a változásokhoz és az üzleti kockázathoz kell igazítani.

A hosszú távú teher a tartalék naprakészen tartása. Egy elfelejtett tanúsítvány vagy elavult adatkapcsolat éppen akkor derülhet ki, amikor szükség lenne rá. A jó döntés ezért lehet teljes tartalék rendszer, korlátozott üzemmód vagy tudatosan elfogadott kiesés is – ha a költség, a felelős és a bizonyíték egyaránt szerepel mögötte.