Az SLA nem az IT-rendszer tökéletes működésének garanciája, hanem a szolgáltató reakciójának és beavatkozásának szerződéses kerete: rögzíti, mennyi időn belül reagál egy bejelentett problémára, mennyi időn belül oldja meg, és mi történik, ha ezt nem teljesíti. A rendelkezésre állás ezzel szemben azt fejezi ki, hogy a kritikus rendszerek – szerver, weboldal, levelezés – az összes időből ténylegesen mennyi százalékban voltak elérhetők. A magyarországi KKV-k jelentős részénél az IT-szolgáltatói szerződés nem tartalmaz valódi, mérhető SLA-t, csak általános, számon nem kérhető ígéreteket. Az alábbiakban azt mutatjuk be, mely konkrét pontokra érdemes figyelni egy SLA-szerződésben, és hogyan lehet ellenőrizni, hogy a szolgáltató ténylegesen tartja-e a vállalt szinteket.

Miből áll egy valódi, mérhető SLA-szerződés

Egy jól kialakított SLA nem általános ígéreteket, hanem pontosan értelmezhető célértékeket tartalmaz: a szolgáltatás tárgyát és hatókörét, az üzemidőt, a rendelkezésre állást, a hibák prioritási kategóriáit, a reakcióidőt és a helyreállítási időt. Enélkül a szerződés gyakorlatilag nem kényszeríthető ki, mert nincs mihez viszonyítani a szolgáltató tényleges teljesítményét.

Miért nem elegendő a „gyorsan reagálunk” típusú vállalás

Tapasztalataink alapján a magyarországi KKV-k többségénél az IT-szolgáltatói szerződés nem tartalmaz valódi SLA-t: a „gyorsan reagálunk” és a „minden tőlünk telhetőt megteszünk” típusú vállalások sem mérhetők, sem számon kérhetők. Ha a szerződésben nincs konkrét óraszám vagy percérték rögzítve, a cégnek gyakorlatilag nincs jogi vagy szerződéses alapja arra, hogy számonkérje a szolgáltatót egy lassú vagy elmaradt beavatkozás esetén.

Miért kell külön választani a bejelentést, a reagálást és a megoldást

Egy kritikus hiba esetén külön kell választani a bejelentés visszaigazolását, a munkavégzés megkezdését, az ideiglenes helyreállítást és a végleges megoldást, mert ezek eltérő időpontban következnek be, és a szerződésnek mindegyikre önálló határidőt kell rögzítenie. Mire figyelj, ha ajánlatot kérsz egy IT-üzemeltető cégtől? Érdemes pontosan megkérdezni, hogy a reakcióidő a bejelentés visszaigazolására vagy a tényleges munkavégzés megkezdésére vonatkozik-e, mert ez a két időpont jelentősen eltérhet egymástól.

Milyen rendelkezésre állási szinteket érdemes elvárni 2026-ban

A rendelkezésre állás konkrét, számszerűsíthető mutató, amelyet az összidő és a szolgáltatás-kiesési periódusok összideje alapján kell kiszámítani, nem szubjektív benyomás alapján megítélni.

Hogyan számítható ki a tényleges rendelkezésre állás

A rendelkezésre állás éves alapon az alábbiak szerint számítandó: az összidőből levonva a kiesési periódusok összidejét, majd ezt százalékban kifejezve az összidőhöz viszonyítva. A szerver üzemeltetés és karbantartás SLA-ja 2026-ra jellemzően 99,5%-os minimum rendelkezésre állást ír elő a kritikus rendszereknél, ami éves szinten körülbelül 44 óra maximális kiesést jelent.

Miért nem mindegy, hogy 99% vagy 99,9% a vállalt szint

A rendelkezésre állási százalékok közötti látszólag apró különbség a valóságban jelentős eltérést jelent kiesési időben: 99%-os rendelkezésre állás évi közel 88 óra kiesést enged meg, míg 99,9%-nál ez már csak körülbelül 8,8 óra. Kinek nem elegendő a 99%-os rendelkezésre állás? Azoknak a cégeknek biztosan nem, amelyeknél egy néhány órás leállás is jelentős bevételkiesést vagy szerződéses kötbér-kockázatot okoz, mert náluk a magasabb, 99,5-99,9%-os szint indokolt, még ha ez magasabb havidíjjal is jár.

Mielőtt aláírnál egy SLA-szerződést, érdemes megkérdezni, hogyan méri a szolgáltató a rendelkezésre állást, és a mért adatokat rendszeres riport formájában megkapja-e a cég, mert enélkül a vállalt százalék puszta ígéret marad, nem ellenőrizhető tény.

SLA-szintek összehasonlítása kritikusság szerint

Szolgáltatási szint	Ajánlott rendszertípus	Jellemző reakcióidő	Rendelkezésre állás
Alap (5×8)	Munkaidőben használt alkalmazások	Néhány órán belül	98-99%
Emelt	Napi működéshez szükséges rendszerek	1-2 órán belül	99-99,5%
Kritikus (7×24)	Szerverek, üzletileg kritikus rendszerek	Percen belül, 24 órás felügyelettel	99,5-99,9%

Az SLA felépítéséről és a szolgáltatási szintek meghatározásáról a SLA fogalmának részletes lexikoni áttekintése ad további, szakmailag pontos hátteret.

Milyen napi üzemeltetési elemek biztosítják a vállalt SLA-t a gyakorlatban

A szerződésben rögzített SLA önmagában nem garantálja a magas rendelkezésre állást, ha a mögöttes napi üzemeltetési munka nem támogatja azt. A folyamatos rendszerfelügyelet, a riasztások kezelése és a rendszeres riportkészítés az IT üzemeltetés, rendszergazda szolgáltatás keretében pontosan azt a napi gyakorlatot jelenti, amely a szerződéses vállalásokat ténylegesen teljesíthetővé teszi.

Kiegészítő olvasnivalóként érdemes átnézni, hogyan kapcsolódik a szerverek folyamatos monitorozása és a szerver üzemeltetés, szerver karbantartás a rendelkezésre állási mutatók fenntartásához, mert a szerveroldali karbantartás elhanyagolása az egyik leggyakoribb oka a vállalt SLA-szintek alá csúszásnak.

Megéri-e ragaszkodni a mérhető, dokumentált SLA-hoz, ha eddig szóbeli megállapodás alapján dolgozott a cég? Akkor mindenképp megéri, ha a cég szeretné objektíven ellenőrizni a szolgáltató teljesítményét, és számon kérhető alapot akar arra, ha a vállalt szintek nem teljesülnek. Nem feltétlenül szükséges azonnal a legmagasabb, 7×24-es kritikus szintre váltani, ha a cég rendszerei kizárólag munkaidőben kritikusak, mert ekkor egy alacsonyabb, 5×8-as szint is elegendő védelmet nyújt, alacsonyabb költség mellett.

Milyen mérőszámokkal ellenőrizhető, hogy a szolgáltató valóban tartja az SLA-t

Az SLA-szerződés aláírása önmagában nem garancia arra, hogy a szolgáltató a gyakorlatban is tartja a vállalt szinteket, ezért a cégnek rendszeres, objektív ellenőrzési eszközökre van szüksége.

Miért nélkülözhetetlen a ticketing rendszer az SLA ellenőrzéséhez

A ticketing rendszer és egy jól felépített SLA-struktúra nemcsak az IT-szolgáltató munkáját teszi átláthatóvá, hanem a szervezet számára is döntéshozatali alapot teremt: láthatóvá válik, melyik rendszer okozza a legtöbb incidenst, melyik felhasználói csoport igényel legtöbb támogatást, és a szolgáltató valóban teljesíti-e a szerződéses vállalásait. Ha a szolgáltató nem használ ticketing rendszert, a cégnek gyakorlatilag nincs objektív bizonyítéka arra, mennyi idő telt el egy bejelentés és a megoldás között.

Mit kell tartalmaznia a rendszeres teljesítményriportnak

A mi tapasztalatunk szerint a jól működő SLA-kapcsolat velejárója a havi vagy negyedéves riport, amely tételesen bemutatja a bejelentett incidensek számát, a vállalt és a tényleges reakcióidőt, valamint a rendelkezésre állási százalékot az adott időszakra vonatkozóan. Mikor nem elegendő csak a havidíjas számlát kapni a szolgáltatótól? Akkor biztosan nem, ha a cég szeretné ellenőrizni, hogy a fizetett szolgáltatás ténylegesen a szerződésben vállalt szinten teljesül-e, mert enélkül a riport nélkül a cég csak a szolgáltató szavára hagyatkozhat.

Miért kritikus az SLA a NIS2 és más megfelelőségi kötelezettségek szempontjából

Az SLA-szerződés és a mögötte álló ticketing napló nem csak üzleti, hanem jogi és megfelelőségi szempontból is egyre fontosabb dokumentum a magyar KKV-k számára.

Hogyan bizonyítja az SLA-napló az incidenskezelés dokumentáltságát

Kiberbiztosítói és NIS2-audit esetén a ticketing rendszer naplója az incidenskezelés egyetlen hiteles bizonyítéka, mert enélkül a cég nem tudja dokumentáltan igazolni, hogy egy biztonsági eseményre mikor és hogyan reagált. Ezt az összefüggést több projekten is megfigyeltük: azok a cégek, amelyeknél nem volt rendszeres ticketing napló, az audit során komoly nehézségekkel szembesültek annak igazolásában, hogy az incidenskezelési folyamataik ténylegesen a jogszabályban előírt határidőkön belül működtek.

Mit jelent ez a gyakorlatban a szerződés kiválasztásakor

Mielőtt aláírnál egy IT-üzemeltetési szerződést, érdemes rákérdezni, hogy a szolgáltató biztosít-e visszamenőleges, exportálható incidensnaplót, mert ez a dokumentáció a NIS2 vagy más szabályozási megfelelés esetén ugyanolyan fontos, mint maga a technikai beavatkozás gyorsasága.

Mennyibe kerül a magasabb SLA-szint, és mikor éri meg a különbözetet kifizetni

A magasabb rendelkezésre állási szint és a rövidebb reakcióidő jellemzően magasabb havidíjjal jár, ezért a döntést a tényleges üzleti kockázathoz kell mérni, nem automatikusan a legmagasabb szintet választani.

Hogyan számold ki, mennyit ér egy óra kiesés a cégednek

Az esetek jelentős részében a cégek nem számolják ki, mennyibe kerül nekik ténylegesen egy óra rendszerkiesés – a kiesett munkaidő, az elmaradt bevétel és az esetleges szerződéses kötbér együttes összegében –, pedig ez a szám adja meg a válasz alapját arra, mennyit érdemes fizetni egy magasabb SLA-szintért. Ha egy óra kiesés több tízezer forintos veszteséget okoz, a magasabb szintű, gyorsabb reakcióidejű szerződés gyorsan megtérül.

Mikor elegendő az alacsonyabb, 5×8-as szolgáltatási szint

Nem ideális megoldás minden cégnek automatikusan a legdrágább, 7×24-es kritikus szintet választani. Ha alkalmazásaidat csak munkaidőben használod, optimális választás lehet az 5×8-as támogatás, amellyel megbízható és gazdaságos support biztosítható vállalati rendszerek számára, míg üzletileg kritikus, folyamatosan futó rendszerek esetén a 7×24-es támogatás szinte elengedhetetlen.

Az IT biztonság, biztonsági mentés szolgáltatás keretében a mentési stratégia rendelkezésre állási szintje is külön SLA-elemként kezelendő, mert egy sikeres mentés és egy ténylegesen tesztelt, gyors helyreállítás nem ugyanaz a vállalás.

Melyik szempont dönt végül egy jó SLA-szerződés kiválasztásában

A cikk során bemutatott elemek – a mérhető célértékek, a ticketing napló, a NIS2-audit dokumentációs szerepe és a rendelkezésre állási szintek közötti valós költségkülönbség – mind arra a közös következtetésre vezetnek, hogy egy SLA-szerződés értékét nem az adja, mennyire hangzik meggyőzően, hanem hogy ténylegesen ellenőrizhető és számon kérhető-e. Tapasztalataink alapján a legtöbb magyar KKV azért marad szóbeli megállapodásoknál vagy homályos szerződéses megfogalmazásoknál, mert nem tudja, pontosan milyen kérdéseket kell feltennie a szolgáltatónak ajánlatkéréskor. A mi tapasztalatunk szerint a legjobb döntést azok a cégvezetők hozzák, akik előre kiszámolják, mennyibe kerül nekik egy óra rendszerkiesés, és ez alapján, nem pedig a legalacsonyabb havidíj alapján választanak szolgáltatási szintet.

Mikor érdemes felülvizsgálni a jelenlegi szerződést

Mikor nem érdemes tovább várni a szerződés felülvizsgálatával? Akkor biztosan nem, ha a cég jelenlegi IT-szolgáltatójával nincs írásos, mérhető SLA-ja, vagy sosem kapott tényleges teljesítményriportot a vállalt reakcióidőkről és a rendelkezésre állásról, mert enélkül a cég gyakorlatilag nem tudja ellenőrizni, mit is fizet valójában havonta. Az IT üzemeltetés, rendszergazda szolgáltatás keretében az IWS minden szerződéshez világosan rögzített, mérhető rendelkezésre állási és reakcióidő-vállalásokat biztosít, amelyek nem általános ígéretként, hanem rendszeres riportban dokumentált, ellenőrizhető teljesítményként jelennek meg.