Az üzemszünet rejtett költségei: mit fizet valójában a cég, ha a szerver leáll?

Egy szerver leáll. Az IT-csapat kap egy hibajegyet, néhány óra múlva minden ismét működik. Az ügyvezető megkérdezi: „Mennyibe került?” — és az egyik munkatárs megbecsüli az elveszett tranzakciókat. Ennyi. Pedig az üzemszünet rejtett költségei gyakran jóval nagyobbak ennél.

A valódi kár általában háromszor-ötször akkora, mint amit a könyvelés a leállás után kimutat — és a különbség a rejtett részben van. Abban, ami soha nem kerül számlára, soha nem jelenik meg egy riportban, mégis nagyon is valóságos.

Ez a cikk megmutatja, miből áll a teljes kár, hogyan számolható ki vállalati szinten, és mit lehet tenni ellene.

Egy leállás soha nem „csak” az a leállás

Az ösztönös reakció érthető: a szerver nem üzemel, tehát az eladott termékek vagy számlázott szolgáltatás kiesnek. De egy IT-kiesés valójában legalább három párhuzamos veszteségréteget indít el egyszerre.

Az első réteg a közvetlen pénzügyi kár — az elveszett tranzakciók, a kiesett termelési idő, a késedelmi kötbér. Ez látható, mérhető, és többnyire megjelenik valahol a pénzügyi kimutatásban.

A második réteg az indirekt, belső veszteség. A szerver ugyan nem fut, de bérköltség attól még van. Minden munkatárs, aki nem tud dolgozni, vagy aki a helyreállításon dolgozik — és aki normál üzleti feladatokat nem végez közben — reálköltséget jelent.

A harmadik réteg a leghosszabb életű: a reputációs és bizalmi kár. Ezt nem lehet kiszámlázni, nem jelenik meg a havi zárlaton, mégis ez szokott a legtöbbe kerülni.

Direkt veszteségek: amit biztosan mérni lehet

A üzemszünet rejtett költségei az alábbiak lehetnek:

Elveszett bevétel: minden olyan tranzakció, amelyet az üzemszünet idején nem lehetett teljesíteni — rendelés, foglalás, számlázás, fizetési feldolgozás.

SLA-bírság és kötbér: ha a vállalat üzemeltetési megállapodásban vagy szerződésben vállalt rendelkezésre állási szintet, a kiesés után bírság követheti. Egy 99,9%-os SLA-kötelezettségnél havi 43 perces tolerancia van — ennél több kiesés esetén a kötbér automatikusan aktiválódhat.

Azonnali helyreállítási kiadás: sürgős külső szervizes beavatkozás, csereeszköz expressz szállítása, túlóra.

A Gartner kutatása alapján a vállalati IT-kiesés átlagos közvetlen költsége körülbelül 5 600 USD percenként — és ez kizárólag a nagyvállalati szegmensre vonatkozik. Kis- és középvállalatoknál a szám alacsonyabb, de a viszonylagos kár — az éves bevétel arányában — hasonló vagy magasabb.

A „nines” matematikája — mit jelent valójában 99,9% vs. 99,99%?

A rendelkezésre állást „nines”-ban, azaz kilences sorozatokban szokás mérni. A különbség egy kilences hozzáadásával drámaian csökken az elfogadott éves állásidő:

Rendelkezésre állás	Éves megengedett állásidő
99%	~87 óra 36 perc
99,9% („three nines”)	~8 óra 46 perc
99,99% („four nines”)	~52 perc
99,999% („five nines”)	~5 perc

A különbség 99,9% és 99,99% között közel 8 óra évente. Ha a vállalatnál egy óra kiesés 500 000 Ft közvetlen veszteséget jelent — ami egy 20–30 fős cég esetében nem irreális —, ez a 8 óra 4 millió forint különbséget jelent közvetlenül évenként.

Ezért az infrastruktúra megbízhatóságának javítása nem kizárólag IT-döntés: pénzügyi döntés is.

Rejtett veszteségek: amit sosem látsz a könyvelésben

Ez az a rész, ahol a legtöbb vállalat alábecsüli a kárt, hiszen egy üzemszünet rejtett költségei láthatatlanok is lehetnek, pl a könyvelésben.

Belső munkaidő-veszteség

Amikor a szerver leáll, az IT-csapat azonnali válságüzemmódba kapcsol: hibakeresés, eszközök újraindítása, logok elemzése, kommunikáció a gyártóval, esetleg helyszíni beavatkozás szervezése. Ez 4–12 óra munkaidőt vehet el — olyan munkaidőt, amelyet normál esetben fejlesztésre, karbantartásra vagy egyéb üzleti projektekre szántak volna.

De nemcsak az IT érintett. A pénzügyes, aki nem tud számlát kiállítani, a logisztikus, aki nem tud csomagot feladni, az értékesítő, aki nem fér hozzá a CRM-hez — mind elveszített produktív órákat képviselnek. Ezek bérköltségként mind megjelennek, de az leállás oka nem lesz feltüntetve mellettük.

Adatvesztés és újrafeldolgozás

Ha a kiesés előtt az utolsó biztonsági mentés 6 órával korábban készült, a közben keletkezett adatok elveszhetnek. Ezeket pótolni kell: újra rögzíteni, rekonstruálni, külső forrásokból visszatölteni. Ez az a munka, amelyet kétszer kell elvégezni — és ami láthatatlan marad, mert a számla nem tükrözi.

Megfelelési és jogi kockázat

A NIS2 irányelv kötelező incidens-bejelentési határidőket ír elő: egyes szektorkritikus esetekben 24 órán belül kell előzetes értesítést küldeni a hatóságnak. GDPR-érintettség esetén az adatvédelmi kockázat külön jogi eljárást vonhat maga után. Ezek a kockázatok minden esetben jelen vannak, de ritkán kerülnek az üzemszünet-kalkulációba.

Reputációs kár — a legnagyobb számla, amit sosem kapsz kézhez

Az IBM és a Ponemon Institute Cost of a Data Breach jelentése évek óta arra mutat, hogy az üzleti incidens hosszú távú ügyfél-hatása a közvetlen kárnak akár kétszerese-háromszorosa lehet — és ez kizárólag az ügyfélbizalom eróziójából ered.

Egy üzemszünet rejtett költségei közé az is beletartozik, ha az ügyfelek is tapasztalják (elérhetetlen webshop, lassú ügyfélszolgálat, késő kiszállítás), bizalomvesztést okoz. A Baymard Institute adatai szerint az online vevők 17%-a soha nem tér vissza olyan boltba, ahol rossz tapasztalatot szerzett — és közülük a legtöbben nem is reklamálnak, csak nem vásárolnak többé.

Az ügyféllemorzsolódás, a visszatérő ügyfelek részleges elvesztése, nem fog megjelenni az IT-incidens utójelentésében, de valós és tartós veszteséget jelent egy rendszerleállás esetén.

Iparágonként más a tét

Nem minden leállás egyforma súlyú — az iparági kontextus alapvetően befolyásolja a tényleges kár mértékét.

E-commerce és webshop: minden perc kiesés elveszett megrendelésekkel és potenciálisan egy konkurens oldalon leadott rendeléssel ér fel. A mozgás azonnali és mérhetően visszakövethető.

Gyártás és logisztika: a termelési sor leállása dominószerű késedelmet generál az ellátási lánc mentén. Egy 2 órás szerver-kiesés 8–12 órányi csúszást hozhat a kiszállításban.

Egészségügy és szociális ellátás: az infrastruktúra leállása, egy rendszerleállás közvetlenül az ellátás biztonságát érintheti. Ez a terület külön jogszabályi elvárásoknak is megfelel.

Pénzügyi és számviteli: a zárási határidők, NAV-adatszolgáltatások és banki tranzakciók szoros időkapcsokhoz kötöttek. Egy zárási napon bekövetkező kiesés jogi következményekkel is járhat.

Számold ki a saját downtime-költségedet

Egyszerű, azonnal alkalmazható kalkuláció:

Közvetlen kiesési költség/óra = (Érintett munkavállalók száma × átlagórabér) + (elveszett bevétel/óra) + (SLA-bírság/óra)

Példa egy 25 fős cégre:

• 20 érintett munkavállaló × 4 000 Ft/óra = 80 000 Ft/óra bérköltség
• Elveszett bevétel: 150 000 Ft/óra (becsült)
• SLA-bírság: 0 Ft (nincs ügyfél-SLA)
• Közvetlen kiesési költség: ~230 000 Ft/óra

Erre jön az indirekt szorzó (IT munkaidő, pótmunka, rekonstrukció): általában 1,5–2,5×-es tényező, iparágtól és leállás súlyosságától függően.

Éves kiesési kockázat: ha a vállalat évente átlagosan 10 óra váratlan leállással számol (ami 99,9%-os rendelkezésre állás alatt reális), a fenti példában ez 2,3–5,75 millió Ft/év tartományban van, a szorzótól függően.

Ez az a szám, amelyet érdemes összevetni egy megbízható, redundáns szerverhardver éves üzemeltetési költségével.

Megelőzés vs. helyreállítás — mi a valódi ROI?

A helyreállítás mindig drágább a megelőzésnél — ez egy IT-axióma, amelyet mégis ritkán számszerűsítenek.

Egy dual PSU konfigurációjú szerver az egyszerű, egytápegységes megoldáshoz képest nettó 80 000–150 000 Ft felár — egyszeri beruházás, amely megakadályozza a legelterjedtebb hardveres leállások okait. Szerver meghibásodások esetén a tápegység-hiba az egyik leggyakoribb eset — de ez az egyik legkönnyebben megelőzhető is.

Egy UPS az áramkimaradás elleni védelmet adja: 10–30 perces akkumulátoros tartalékidővel, amely elegendő a kontrollált leállításhoz és az adatvesztés elkerüléséhez. Nettó 100 000–250 000 Ft-os beruházás, amely akár évente többször is megakadályozhatja az adatveszteséget.

Ha a fenti 25 fős cégnél egyetlen 2 órás rendszerleállást akadályoz meg évente, a megtérülés már az első évben pozitív. Az adatbiztonság és a 100 000 eurós veszteség elkerüléséről részletesen írtunk korábban: a megelőzési beruházás és a potenciális kár arányát ott szemléletes számokkal mutatjuk be.

Az üzleti folytonosság intézményes védelméhez BCP és DR terv is szükséges: ez határozza meg, hogy kiesés esetén pontosan mi a teendő, ki a felelős, és mi az elfogadható visszaállítási idő (RTO) és visszaállítási pont (RPO).

Konkrét lépések — mit tegyél most?

Ha nincs pontos képed arról, hogy a vállalat infrastruktúrája milyen rendelkezésre állási szintet nyújt valójában, az első lépés a hardver audit. Ez nem hónapokig tartó projekt — egy tapasztalt infrastruktúra-mérnök 1–2 nap alatt átvizsgálja a kritikus pontokat.

A legfontosabb ellenőrzési szempontok:

• Van-e redundáns tápegység a termelési szervereknél?
• A RAID-konfiguráció valóban véd-e meghibásodás ellen, és mikor tesztelték utoljára?
• Az UPS valóban üzemképes, vagy csak bekapcsolt állapotban van?
• Mikor készült az utolsó visszaállítási teszt a biztonsági mentésből?
• Dokumentált-e a kiesési forgatókönyv, és mindenki tudja-e a szerepét?

Ha ezekre a kérdésekre nem adható azonnali, biztos válasz, az rendszerleállás nem kérdés — csak időpont kérdése.

A szerverdokk.hu csapata segít infrastruktúra-átvizsgálásban és a megfelelő hardverkonfiguráció kialakításában. Kérj ajánlatot és konzultációt tőlünk ide kattintva: szerverdokk.hu.