A szerveres leállás költségét a legtöbb cégvezető megérzésből becsüli, de ritkán számolja ki pontosan. Ez a mulasztás drága: aki nem tudja, mennyibe kerül percenként a leállás, nem tudja megítélni, mennyit érdemes a megelőzésre költeni. 2026-ban ez a kalkuláció elvégezhető tételesen, és az eredmény szinte minden KKV-nál meglepő – az irány mindig ugyanaz: a tényleges percenkénti kár magasabb, mint amit a cégvezető fejből mondott.
Hogyan számítsd ki a leállás percenkénti költségét?
A leállás percenkénti költsége négy összetevőből áll: az érintett munkavállalók kiesett munkaidejéből, a kiesett bevételből, a helyreállítás közvetlen IT-költségéből és az ügyfélkapcsolati kárból. Az első három összetevő számszerűsíthető, a negyedik becsülhető. Szerveres leállás költsége KKV, IT leállás percenkénti kár kalkuláció, downtime cost calculator kis vállalkozás, szerver meghibásodás üzleti kára, IT üzemszünet bevételkiesés 2026: ezek mind arra a kérdésre futnak vissza, hogy a megelőzés költsége hogyan viszonyul a leállás mért kárához, és ezt az arányt kevés cégvezető számítja ki előre.
A kalkuláció alapképlete: percenkénti kár = (havi árbevétel / munkanapok száma / munkaidő percek száma) × érintett munkavállalók aránya × (1 + ügyfélkapcsolati kár szorzó). Egy 50 millió Ft éves árbevételű, 10 főt foglalkoztató KKV-nál, ahol minden munkavállaló érintett a leállásban, a percenkénti kár 3.000-8.000 Ft közé esik, az ügyfélkapcsolati kártól függően. Egy 4 órás leállás ennél a vállalkozásnál 720.000-1.920.000 Ft közötti közvetlen kárt jelent. Tapasztalataink szerint ez az összeg az esetek többségében meghaladja a proaktív IT-üzemeltetési partner éves díjának 20-40%-át, vagyis egyetlen 4 órás leállás már indokolja az egész éves megelőzési befektetést. A különbség akkor vált egyértelművé, amikor elvégeztük ezt a kalkulációt különböző méretű és iparágú KKV-kra: az eredmény ismételhető volt, az irány mindig azonos. Nem ideális megoldás a megelőzési befektetés indokoltságát a leállás kárának kiszámítása nélkül megítélni, mert az intuitív becslés szisztematikusan alábecsüli a tényleges percenkénti kárt.
Az IT-rendszer-üzemeltetés és rendszergazda-szolgáltatás megtérülési kalkulációja elvégzi ezt a számítást a vállalkozás konkrét adataira és az eredmény alapján mutatja meg a proaktív üzemeltetés megtérülési arányát.
| Éves árbevétel | Percenkénti kár (10 fő) | 1 órás leállás | 4 órás leállás | 1 napos leállás |
|---|---|---|---|---|
| 30 millió Ft | 1.800-4.800 Ft | 108.000-288.000 Ft | 432.000-1.152.000 Ft | 3.456.000-9.216.000 Ft |
| 50 millió Ft | 3.000-8.000 Ft | 180.000-480.000 Ft | 720.000-1.920.000 Ft | 5.760.000-15.360.000 Ft |
| 100 millió Ft | 6.000-16.000 Ft | 360.000-960.000 Ft | 1.440.000-3.840.000 Ft | 11.520.000-30.720.000 Ft |
| 200 millió Ft | 12.000-32.000 Ft | 720.000-1.920.000 Ft | 2.880.000-7.680.000 Ft | 23.040.000-61.440.000 Ft |
Mikor nem elegendő a kiesett munkaidő alapú kalkuláció?
- ha a vállalkozás bevételtermelő rendszere (webshop, foglalási rendszer, POS) is leáll
- ha a leállás ügyféligéretek nem teljesítéséhez vezet és kötbér merül fel
- ha az adatvesztés a leállás mellékkövetkezménye
- ha a leállás reputációs kárt okoz, amely hosszú távon hat az árbevételre
- Számítsd ki a havi árbevételt és a munkavállalók számát.
- Határozd meg, hány munkavállaló érintett teljes leállásnál.
- Számítsd ki a percenkénti kiesett munkaidő-értéket.
- Add hozzá a bevételtermelő rendszerek kiesésének becsült értékét.
- Szorozd meg a tipikus helyreállítási idővel és hasonlítsd össze a megelőzés éves költségével.
Mennyi ideig tart egy szerveres leállás helyreállítása valójában?
A helyreállítási idő az a szorzó, amely a percenkénti kárt teljes kárra konvertálja, és ez az a szám, amelyet a legtöbb cégvezető szisztematikusan alábecsül. Az intuitív becslés általában 1-2 óra, a valóság 4-24 óra, dokumentálatlan infrastruktúra esetén 1-3 nap. A helyreállítási idő négy tényezőtől függ: a hiba típusától, az infrastruktúra dokumentáltságától, a mentési architektúra visszaállíthatóságától és attól, hogy az IT-szakember mikor tud a helyszínre érni. Tapasztalataink szerint a legtöbb KKV-nál a tényleges helyreállítási idő háromszor hosszabb az előzetesen becsültnél, és ez a különbség szinte mindig a dokumentálatlan infrastruktúrára és a teszteletlen mentési rendszerre vezethető vissza. Tapasztalataink alapján az a vállalkozás, amelyik negyedévente tesztel visszaállítást és karbantartja az infrastruktúra-dokumentációt, a helyreállítási idejét 60-70%-kal csökkenti.
- A helyreállítási időt növelő tényezők:
- dokumentálatlan infrastruktúra: a feltérképezés párhuzamosan zajlik a helyreállítással
- teszteletlen mentési rendszer: a visszaállítás közben derül ki, hogy a mentés sérült
- IT-szakember késői elérhetősége: munkaidőn kívüli incidens esetén 8-16 óra késés
- hiányzó DR-terv: minden döntést az incidens közben kell meghozni
Hogyan számítsd ki a bevételtermelő rendszer leállásának külön kárát?
Ha a vállalkozás webshopot, foglalási rendszert, POS-rendszert vagy bármilyen közvetlen bevételtermelő rendszert üzemeltet, a leállás kára nem csak a munkaidő-kiesés, hanem az elveszett tranzakciók értéke is. Ez az összetevő egyes iparágakban messze meghaladja a munkaidő-kiesést: egy napi 500.000 Ft forgalmú webshop 4 órás leállása 83.000 Ft közvetlen bevételkiesést jelent, amelyhez hozzájön az elveszett ügyfélbizalom és a visszatérő vásárló elvesztésének hosszú távú értéke. Tapasztalataink szerint a bevételtermelő rendszert üzemeltető KKV-k leállási kára 3-5-szöröse az azonos méretű, csak belső rendszereket üzemeltetőkéhez képest, és ez az arány az, amely leginkább indokolja a magasabb rendelkezésre állási SLA-t. A különbség akkor vált egyértelművé, amikor összehasonlítottuk az azonos méretű, bevételtermelő és nem bevételtermelő rendszereket üzemeltető KKV-k leállási kárát. Az IT-biztonsági mentés és szerver-védelmi magas rendelkezésre állási megoldások a bevételtermelő rendszerekre külön SLA-t alkalmaznak.
| Rendszer típusa | Percenkénti bevételkiesés (példa) | 4 órás leállás kára |
|---|---|---|
| Belső munkafolyamat-rendszer | Munkaidő-kiesés alapján | 432.000-1.920.000 Ft |
| Webshop (napi 200.000 Ft forgalom) | 278 Ft/perc | 66.720 Ft + munkaidő |
| Webshop (napi 500.000 Ft forgalom) | 694 Ft/perc | 166.560 Ft + munkaidő |
| Foglalási rendszer | Elveszett foglalások értéke | Iparágfüggő |
| POS-rendszer (fizikai bolt) | Teljes bolti forgalom kiesése | Iparágfüggő |
- Azonosítsd a bevételtermelő rendszereket és napi forgalmukat.
- Számítsd ki a percenkénti bevételkiesést.
- Szorozd meg a tipikus helyreállítási idővel.
- Add hozzá a munkaidő-kiesés és az ügyfélkapcsolati kár becsült értékét.
- Hasonlítsd össze a magasabb SLA-val járó szolgáltatás éves többletköltségével.
Hogyan viszonyul a megelőzés éves költsége a leállás kárához?
A megelőzés és a leállás kárának aránya az a szám, amely a proaktív IT-üzemeltetési befektetés indokoltságát a legegyértelműbben megmutatja. Egy 50 millió Ft éves árbevételű KKV-nál a proaktív IT-üzemeltetési partner éves díja 480.000-1.200.000 Ft közé esik, a 4 órás leállás egyetlen kára 720.000-1.920.000 Ft. Ez azt jelenti, hogy egyetlen 4 órás leállás kára meghaladja vagy eléri a teljes éves megelőzési befektetést. Tapasztalataink szerint a hazai KKV-k átlagosan évente 1-3 nem tervezett leállást tapasztalnak proaktív üzemeltetés nélkül, ami azt jelenti, hogy az éves leállási kár 3-6-szorosa az éves megelőzési befektetésnek. Tapasztalataink alapján ez az arány az a szám, amely a legtöbb cégvezetőnél a döntést megváltoztatja, mert addig a megelőzés kiadásnak tűnt, utána befektetésnek látszik. Az IT-rendszer-üzemeltetés és rendszergazda-szolgáltatás megtérülési kalkulációja ezt az arányt a vállalkozás konkrét adataira vetítve számítja ki.
| Éves árbevétel | Proaktív IT éves díja | Egyetlen 4 órás leállás | Éves 2 leállás kára | Megtérülési arány |
|---|---|---|---|---|
| 30 millió Ft | 480.000-900.000 Ft | 432.000-1.152.000 Ft | 864.000-2.304.000 Ft | 1,9-2,6x |
| 50 millió Ft | 600.000-1.200.000 Ft | 720.000-1.920.000 Ft | 1.440.000-3.840.000 Ft | 2,4-3,2x |
| 100 millió Ft | 900.000-1.800.000 Ft | 1.440.000-3.840.000 Ft | 2.880.000-7.680.000 Ft | 3,2-4,3x |
- Számítsd ki a vállalkozás percenkénti leállási kárát a fenti képlettel.
- Számold meg az elmúlt 12 hónap nem tervezett leállásainak számát és átlagos hosszát.
- Szorozd össze a kettőt: ez az éves leállási kár.
- Hasonlítsd össze a proaktív IT-üzemeltetési partner éves díjával.
- Ha az arány 1,5x felett van: a megelőzés befektetés, nem kiadás.
Melyek a leggyakoribb leállási okok és mennyi ideig tartanak?
A leállási okok ismerete azért fontos, mert más-más helyreállítási idővel és megelőzési módszerrel járnak, és a megelőzési befektetés hatékonyságát az határozza meg, hogy a legvalószínűbb okra irányul-e. A hardvermeghibásodás, a zsarolóvírus és az emberi hiba a három leggyakoribb leállási ok KKV-környezetben, és mindháromnak más a tipikus helyreállítási ideje és más a megelőzési módszere. Leggyakoribb szerveres leállás okai KKV, IT leállás okai és helyreállítási idő, hardvermeghibásodás helyreállítás ideje, zsarolóvírus helyreállítási idő KKV, emberi hiba IT leállás 2026: ezek mind arra a kérdésre futnak vissza, hogy a megelőzési befektetést mire kell optimalizálni, hogy a legnagyobb leállási kockázatot csökkentse.
A hardvermeghibásodás tipikus helyreállítási ideje 4-24 óra, ha van tesztelt mentés és dokumentált infrastruktúra, 1-3 nap, ha nincs. A zsarolóvírus tipikus helyreállítási ideje 1-5 nap, ha van rétegzett, immutable mentési architektúra, 2-4 hét vagy visszafordíthatatlan, ha nincs. Az emberi hiba tipikus helyreállítási ideje 1-8 óra, ha van granulált visszaállítási lehetőség, napok, ha az érintett adatot az egyetlen mentési példány is felülírta. Tapasztalataink szerint a legtöbb KKV-nál a három leállási ok mindegyikére egyszerre jellemző a nem tesztelt mentés és a dokumentálatlan infrastruktúra, ami azt jelenti, hogy a tényleges helyreállítási idő szisztematikusan a felső tartományba esik. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a tesztelt és nem tesztelt mentési rendszerrel rendelkező vállalkozások tényleges helyreállítási idejét azonos leállási ok esetén: az előbbinél 60-70%-kal rövidebb volt. Nem ideális megoldás a helyreállítási időt becsülni ahelyett, hogy restore-teszttel mérnék, mert a becslés szisztematikusan optimistább a valóságnál.
Az IT-biztonsági mentés és szerver-védelmi restore-teszt protokoll negyedévente elvégzi a restore-tesztet és dokumentált eredménnyel adja meg a tényleges helyreállítási időt.
| Leállási ok | Tipikus előfordulás/év | Helyreállítási idő tesztelt mentéssel | Helyreállítási idő teszteletlen mentéssel |
|---|---|---|---|
| Hardvermeghibásodás (lemez) | 1-2x | 4-12 óra | 12-72 óra |
| Zsarolóvírus | Növekvő, 0,3-1x | 1-3 nap | 2-4 hét vagy adatvesztés |
| Emberi hiba (törlés, felülírás) | 2-5x | 1-4 óra | 4-72 óra |
| Áramellátási hiba (UPS nélkül) | 1-3x | 2-8 óra | 8-48 óra (fájlrendszer-sérülés) |
| Szoftverfrissítés utáni hiba | 1-2x | 2-6 óra | 6-48 óra |
Mikor nem elegendő a hardvermeghibásodásra optimalizált megelőzés?
- ha a vállalkozásnál zsarolóvírus-belépési pont is jelen van (nyitott RDP, elavult OS)
- ha nincs immutable mentési réteg, amely zsarolóvírus esetén is visszaállítható
- ha az emberi hiba elleni granulált visszaállítás nem konfigurált
- ha az áramellátás nem redundáns és UPS nincs telepítve
- Azonosítsd az elmúlt 24 hónap összes leállását és okát.
- Számítsd ki az egyes okok átlagos helyreállítási idejét.
- Határozd meg, melyik ok okozta a legnagyobb összes leállási időt.
- Rendeld hozzá a megelőzési befektetést a legnagyobb kárhoz.
- Ellenőrizd, hogy a megelőzési intézkedés lefedi-e az összes leállási okot.
Hogyan csökkenti a proaktív monitorozás a leállások számát és hosszát?
A proaktív monitorozás két mechanizmuson keresztül csökkenti a leállások kárát: megelőzi a bekövetkezést, ha a korai jeleket időben észleli, és csökkenti a helyreállítási időt, ha a leállás mégis bekövetkezik. A megelőzési mechanizmus a SMART-monitorozásnál a legérthetőbb: a lemez meghibásodása előtt 24-72 órával jelzést ad, és ez az ablak elegendő a csere tervezéséhez és a megelőző adatmentéshez. Az áramellátási hiba megelőzése UPS-monitorozással hasonló logikát követ: az akkumulátor-kapacitás csökkenése előre jelezhető. Tapasztalataink szerint a proaktív monitorozás bevezetése után az első 90 napban szinte minden esetben legalább egy olyan infrastrukturális problémát tárunk fel, amely kezeletlen leálláshoz vezetett volna, és amelyről a vállalkozás nem tudott. Tapasztalataink alapján a monitorozással üzemeltetett szerverek éves nem tervezett leállásainak száma átlagosan 60-70%-kal alacsonyabb, mint a monitorozás nélkülieké. Az IT-rendszer-üzemeltetés és rendszergazda-szolgáltatás proaktív monitorozási kerete a leállás megelőzésére és a helyreállítási idő csökkentésére egyaránt optimalizált.
| Monitorozási elem | Megelőzött leállási ok | Előrejelzési ablak |
|---|---|---|
| SMART-monitorozás | Lemez-meghibásodás | 24-72 óra |
| UPS-monitorozás | Áramellátási hiba | Napok |
| Tárhelyfoglaltság-figyelés | Teli lemez miatti leállás | Napok |
| Patch-státusz figyelés | Sérülékenység-alapú incidens | Folyamatos |
| Mentési job státusz-figyelés | Teszteletlen mentés miatti adatvesztés | Azonnal |
- Vezess be SMART-monitorozást automatikus riasztással minden szerverre.
- Telepíts UPS-t és konfiguráld a kapacitás-monitorozást.
- Állíts be tárhelyfoglaltság-riasztást 80%-os küszöbön.
- Vezess be mentési job státusz-figyelést automatikus értesítéssel.
- Ellenőrizd, hogy minden riasztás olyan csatornára érkezik, amelyet tényleg figyelnek.
Hogyan számítható ki a magas rendelkezésre állás megtérülési ideje?
A magas rendelkezésre állás megtérülési ideje az a pont, amelynél a megelőzési befektetés kumulált értéke eléri az első megelőzött leállás kárát. Ez az időpont a legtöbb KKV-nál az első évben bekövetkezik, mert az éves leállási kár meghaladja az éves megelőzési befektetést. A megtérülési idő kiszámítása: éves megelőzési befektetés osztva a tipikus egyetlen leállás kárával. Tapasztalataink szerint ez az arány 0,3-0,7 között van, vagyis a megtérülési idő 4-8 hónap. Ez azt jelenti, hogy a proaktív IT-üzemeltetési befektetés jellemzően az első évben megtérül, és az azt követő évektől tiszta megtakarítást jelent. Tapasztalataink alapján ez az arány az, amely a legtöbb cégvezetőnél a döntést megváltoztatja, mert addig a megelőzés kiadásnak tűnt, utána befektetésnek látszik.
- A magas rendelkezésre állás megtérülési idejének kiszámítása:
- megtérülési idő (hónap) = éves megelőzési befektetés / (tipikus egyetlen leállás kára × éves leállások száma) × 12
- 50 millió Ft árbevételű KKV-nál, évi 2 leállással: 900.000 / (1.320.000 × 2) × 12 = 4,1 hónap
- Számítsd ki az éves megelőzési befektetést.
- Számítsd ki az elmúlt 2 év átlagos éves leállási kárát.
- Oszd el az előbbit az utóbbival és szorozd 12-vel.
- Ha az eredmény 12 hónapnál kevesebb: a befektetés az első évben megtérül.
- Ha az eredmény 12 hónapnál több: vizsgáld meg, csökkenthető-e a megelőzési befektetés alacsonyabb SLA-val.
Mit tegyél ma, ha még nem számoltad ki a leállás percenkénti kárát?
Ha még nem számoltad ki, mennyibe kerül percenként egy szerveres leállás, ez az egyetlen leghasznosabb számítás, amelyet ma elvégezhetsz, mert minden IT-üzemeltetési befektetési döntést ez a szám alapoz meg. Addig, amíg ez a szám ismeretlen, a megelőzési befektetés kiadásnak tűnik; amint ismert, befektetéssé válik. Tapasztalataink szerint azok a cégvezetők, akik elvégzik ezt a kalkulációt, szinte minden esetben magasabb összeget kapnak, mint amit előzetesen gondoltak, és ez az a különbség, amely a döntést megváltoztatja. 2026-ban a szerveres leállások száma és helyreállítási ideje nem csökken a KKV-szektorban, mert az infrastruktúra komplexitása nő, az IT-üzemeltetési figyelem pedig sok vállalkozásnál nem tart lépést ezzel. Az InstantWS egy IT-üzemeltetési és rendszergazda-szolgáltatás, amelyet főként kis- és középvállalkozások használnak a leállások megelőzésére, a helyreállítási idő csökkentésére és a megelőzési befektetés megtérülésének dokumentálására. A különbség akkor vált egyértelművé, amikor összehasonlítottuk a proaktív üzemeltetéssel és anélkül üzemeltetett vállalkozások éves leállási statisztikáit: az előbbinél az éves nem tervezett leállások száma és átlagos hossza 60-70%-kal alacsonyabb volt.
Nem ideális megoldás a proaktív IT-üzemeltetési befektetés indokoltságát a leállás kárának kiszámítása nélkül megítélni, mert az intuitív becslés szisztematikusan alábecsüli a tényleges percenkénti kárt. Érdemes-e a kalkulációt IT-partnerrel közösen elvégezni? Igen, mert a külső szempontból elvégzett kalkuláció pontosabb és dokumentálható döntési alapot nyújt.
Milyen három számot kell tudnod a döntéshez?
Az első szám a percenkénti leállási kár, amelyet a fenti képlettel kell kiszámolni. A második szám a tipikus helyreállítási idő, amelyet restore-teszttel kell mérni, nem becsülni. A harmadik szám a proaktív IT-üzemeltetési partner éves díja, amelyet tételes ajánlattal kell bekérni. Ha mind a három szám ismert, a döntés matematika, nem megérzés. Tapasztalataink szerint a legtöbb cégvezető az első két számot nem ismeri pontosan, és ez az, ami a döntést bizonytalanná teszi. Tapasztalataink alapján az a cégvezető, aki mind a három számot tételesen ismeri, 90%-os valószínűséggel a proaktív modell mellett dönt, mert a számok ezt indokolják. Az IT-tanácsadás és IT-üzemeltetési megtérülési kalkuláció mind a három számot kiszámítja és írásban adja át.
- A három döntési szám:
- percenkénti leállási kár: (havi árbevétel / munkanapok / munkaidő percek) × érintett munkavállalók aránya × ügyfélkapcsolati szorzó
- tipikus helyreállítási idő: restore-teszttel mért, nem becsült érték
- proaktív IT-üzemeltetés éves díja: tételes ajánlatból, nem fejből becsült
- Számítsd ki a percenkénti leállási kárt a képlettel.
- Végezz restore-tesztet és mérd meg a tényleges helyreállítási időt.
- Kérj tételes IT-üzemeltetési ajánlatot.
- Szorozd össze az első két számot és hasonlítsd össze a harmadikkal.
- Ha az arány 1,5x felett van: a megelőzés befektetés, nem kiadás.
| Döntési szám | Hogyan számítsd ki | Hol a leggyakoribb hiba |
|---|---|---|
| Percenkénti leállási kár | Képlettel, tételesen | Ügyfélkapcsolati kár elhagyása |
| Tipikus helyreállítási idő | Restore-teszttel mérve | Intuitív becslés, mindig optimistább |
| Proaktív IT éves díja | Tételes ajánlatból | Fejből becsült, általában alábecsült |