A megfelelő SLA szint kiválasztása nem azon múlik, mekkora a cég, hanem azon, mennyire kritikus a rendszerek folyamatos elérhetősége a napi működéshez. Egy 5×8-as, munkaidőben elérhető támogatás elegendő lehet egy irodai környezetnek, míg egy folyamatosan futó webshopnak vagy termelésirányítási rendszernek 7×24-es, gyors reakcióidejű szint szükséges. A gyakorlatban a legtöbb cég vagy túlfizet egy indokolatlanul magas szintért, vagy alulbiztosítja magát egy olyan alapcsomaggal, amely nem fedezi a tényleges kockázatot. Az alábbiakban azt mutatjuk be, milyen konkrét szempontok alapján válaszd ki, pontosan milyen SLA szintet kérj a szerződésbe, és mit érdemes explicit módon kikötni.
Milyen kérdésekkel mérd fel, mekkora SLA szintre van szükséged
Mielőtt ajánlatot kérnél, érdemes tisztázni, mennyire kritikus valójában az adott rendszer, mert ez a felmérés adja meg az alapját annak, milyen szintet érdemes kérni.
Mennyire kritikus a rendszer leállása a napi működésre
Az esetek jelentős részében a cégek nem különböztetik meg a rendszereiket kritikusság szerint, pedig egy webáruház szervere vagy a számlázórendszer sokkal érzékenyebb egy rövid leállásra, mint egy belső dokumentumtár. A mi tapasztalatunk szerint érdemes minden rendszert külön besorolni: mi az, aminek kiesése azonnal bevételkiesést okoz, mi az, ami néhány órás késleltetést elvisel, és mi az, ami akár egy napig is várhat probléma esetén.
Milyen napszakban és mennyire sűrűn használják a rendszert
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ó, míg üzletileg kritikus, folyamatosan futó rendszerek esetén a 7×24-es támogatás szinte elengedhetetlen. Mire figyelj, ha bizonytalan vagy a választásban? Érdemes egy hónapig naplózni, mikor és milyen gyakorisággal fordulnak elő IT-problémák, mert ez a gyakorlati adat pontosabb képet ad, mint az elméleti feltételezés arról, mikor kritikus a rendszer.
Kinek nem éri meg a legmagasabb, 7×24-es szintet kérni? Azoknak a cégeknek, amelyeknek minden rendszere kizárólag munkaidőben fut, és egy esti vagy hétvégi leállás nem okoz tényleges üzleti kárt, mert náluk a magasabb szint fölösleges többletköltséget jelent.
Milyen konkrét elemeket kérj be a szerződésbe az SLA szint mellett
Az SLA szint önmagában nem elegendő, ha a szerződés nem rögzíti pontosan, mit takar a vállalt reakcióidő és rendelkezésre állás.
Miért kérj külön reakcióidőt a bejelentésre és a tényleges munkavégzésre
A jó gyakorlat szerint 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, ezért érdemes mind a négy időpontra külön, számszerű határidőt kérni a szerződésbe. Ha a szerződés csak annyit rögzít, hogy „gyors reakcióidő”, az gyakorlatilag nem kényszeríthető ki, mert nincs konkrét viszonyítási pont.
Miért kérj rendszeres, dokumentált teljesítményriportot
Mielőtt aláírnál egy szerződést, kérd ki, hogy a szolgáltató biztosít-e havi vagy negyedéves riportot a tényleges reakcióidőkről és a rendelkezésre állási százalékról, mert enélkül a vállalt SLA szint csak papíron létezik, a gyakorlatban nem ellenőrizhető. Az esetek jelentős részében azok a cégek maradnak elégedetlenek a szolgáltatóval, amelyek soha nem kaptak ilyen riportot, és csak akkor szembesülnek a problémával, amikor egy komolyabb incidens rávilágít a hiányosságokra.
Milyen SLA elemeket érdemes konkrétan kikötni
| Szerződéses elem | Mit kell rögzítenie | Miért fontos |
|---|---|---|
| Bejelentés visszaigazolása | Konkrét percben vagy órában | Bizonyítja, hogy a szolgáltató tud a problémáról |
| Munkavégzés megkezdése | Konkrét órában, prioritás szerint | Ez a tényleges reakcióidő, nem a visszaigazolás |
| Rendelkezésre állási százalék | Éves szinten, mérési módszerrel együtt | Számszerűsíti a megengedett kiesést |
| Teljesítményriport gyakorisága | Havi vagy negyedéves | Ellenőrizhetővé teszi a vállalást |
| Nem teljesítés következménye | Kötbér vagy kompenzáció mértéke | Valódi kikényszeríthetőséget ad a szerződésnek |
Milyen SLA szintet kérj, ha a cég NIS2 hatálya alá tartozik
Ha a cég a Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény hatálya alá tartozik, az SLA szerződés nem csak üzleti, hanem megfelelőségi kérdés is.
Miért fontos az incidensnapló a megfelelőség szempontjából
Kiberbiztosítói és NIS2-audit esetén a ticketing rendszer naplója az incidenskezelés egyik hiteles bizonyítéka, ezért mielőtt szerződést kötsz, kérdezd meg, biztosít-e a szolgáltató exportálható, visszamenőleges incidensnaplót. Mikor különösen fontos ez a szempont? Akkor biztosan, ha a cég a NIS2 törvény hatálya alá tartozik, mert az audit során a hatóság pontosan azt vizsgálja, hogy a dokumentáció és a valós működési gyakorlat egyezik-e egymással.
Milyen rendelkezésre állási szintet érdemes kérni kritikus rendszereknél
A szerver üzemeltetés és karbantartás SLA-ja kritikus rendszereknél jellemzően 99,5%-os minimum rendelkezésre állást jelent, ami éves szinten körülbelül 44 órányi maximális kiesést enged meg. Mielőtt eldöntenéd, hogy ez elegendő-e a céged számára, érdemes kiszámolni, mennyibe kerülne egy ekkora kiesés, és ez alapján dönteni arról, szükséges-e a még magasabb, 99,9%-os szintet kérni.
Az IT üzemeltetés, rendszergazda szolgáltatás keretében az IWS a szerződéskötés előtt pontosan ezt a felmérést végzi el, hogy a cég ne túl magas, feleslegesen drága, se túl alacsony, kockázatos SLA szintet válasszon.
Milyen SLA szintet kérj a biztonsági mentésre és a helyreállításra külön
A mentési SLA gyakran elkülönül az általános rendszertámogatási SLA-tól, ezért érdemes külön kérdezni rá.
Miért nem elég, ha csak a mentés létezését garantálja a szerződés
Egy sikeres mentés és egy ténylegesen tesztelt, gyors helyreállítás nem ugyanaz a vállalás, ezért kérdezd meg, milyen helyreállítási időt (RTO) és milyen adatvesztési határt (RPO) garantál a szolgáltató. Az IT biztonság, biztonsági mentés szolgáltatás keretében ezeket a mutatókat érdemes ugyanolyan konkrétsággal kérni a szerződésbe, mint a rendszertámogatási reakcióidőt.
Megéri-e alaposan kitárgyalni az SLA részleteit egy szerződéskötés előtt, ahelyett hogy elfogadnád a szolgáltató alapajánlatát? Akkor mindenképp megéri, ha a cég rendszerei kritikusak a napi működéshez, vagy érzékeny adatot kezel, mert ekkor a pontosan kialkudott SLA jelentősen csökkenti a jövőbeli vitás helyzetek kockázatát.
Milyen SLA szintet kérj IT üzemeltetési szerződésbe?
A megfelelő SLA szint kiválasztása nem azon múlik, mekkora a cég, hanem azon, mennyire kritikus a rendszerek folyamatos elérhetősége a napi működéshez. Egy 5×8-as, munkaidőben elérhető támogatás elegendő lehet egy irodai környezetnek, míg egy folyamatosan futó webshopnak vagy termelésirányítási rendszernek 7×24-es, gyors reakcióidejű szint szükséges. A gyakorlatban a legtöbb cég vagy túlfizet egy indokolatlanul magas szintért, vagy alulbiztosítja magát egy olyan alapcsomaggal, amely nem fedezi a tényleges kockázatot. Az alábbiakban azt mutatjuk be, milyen konkrét szempontok alapján válaszd ki, pontosan milyen SLA szintet kérj a szerződésbe, és mit érdemes explicit módon kikötni.
Milyen kérdésekkel mérd fel, mekkora SLA szintre van szükséged
Mielőtt ajánlatot kérnél, érdemes tisztázni, mennyire kritikus valójában az adott rendszer, mert ez a felmérés adja meg az alapját annak, milyen szintet érdemes kérni.
Mennyire kritikus a rendszer leállása a napi működésre
Az esetek jelentős részében a cégek nem különböztetik meg a rendszereiket kritikusság szerint, pedig egy webáruház szervere vagy a számlázórendszer sokkal érzékenyebb egy rövid leállásra, mint egy belső dokumentumtár. A mi tapasztalatunk szerint érdemes minden rendszert külön besorolni: mi az, aminek kiesése azonnal bevételkiesést okoz, mi az, ami néhány órás késleltetést elvisel, és mi az, ami akár egy napig is várhat probléma esetén.
Milyen napszakban és mennyire sűrűn használják a rendszert
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ó, míg üzletileg kritikus, folyamatosan futó rendszerek esetén a 7×24-es támogatás szinte elengedhetetlen. Mire figyelj, ha bizonytalan vagy a választásban? Érdemes egy hónapig naplózni, mikor és milyen gyakorisággal fordulnak elő IT-problémák, mert ez a gyakorlati adat pontosabb képet ad, mint az elméleti feltételezés arról, mikor kritikus a rendszer.
Kinek nem éri meg a legmagasabb, 7×24-es szintet kérni? Azoknak a cégeknek, amelyeknek minden rendszere kizárólag munkaidőben fut, és egy esti vagy hétvégi leállás nem okoz tényleges üzleti kárt, mert náluk a magasabb szint fölösleges többletköltséget jelent.
Milyen konkrét elemeket kérj be a szerződésbe az SLA szint mellett
Az SLA szint önmagában nem elegendő, ha a szerződés nem rögzíti pontosan, mit takar a vállalt reakcióidő és rendelkezésre állás.
Miért kérj külön reakcióidőt a bejelentésre és a tényleges munkavégzésre
A jó gyakorlat szerint 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, ezért érdemes mind a négy időpontra külön, számszerű határidőt kérni a szerződésbe. Ha a szerződés csak annyit rögzít, hogy „gyors reakcióidő”, az gyakorlatilag nem kényszeríthető ki, mert nincs konkrét viszonyítási pont.
Miért kérj rendszeres, dokumentált teljesítményriportot
Mielőtt aláírnál egy szerződést, kérd ki, hogy a szolgáltató biztosít-e havi vagy negyedéves riportot a tényleges reakcióidőkről és a rendelkezésre állási százalékról, mert enélkül a vállalt SLA szint csak papíron létezik, a gyakorlatban nem ellenőrizhető. Az esetek jelentős részében azok a cégek maradnak elégedetlenek a szolgáltatóval, amelyek soha nem kaptak ilyen riportot, és csak akkor szembesülnek a problémával, amikor egy komolyabb incidens rávilágít a hiányosságokra.
Milyen SLA elemeket érdemes konkrétan kikötni
| Szerződéses elem | Mit kell rögzítenie | Miért fontos |
|---|---|---|
| Bejelentés visszaigazolása | Konkrét percben vagy órában | Bizonyítja, hogy a szolgáltató tud a problémáról |
| Munkavégzés megkezdése | Konkrét órában, prioritás szerint | Ez a tényleges reakcióidő, nem a visszaigazolás |
| Rendelkezésre állási százalék | Éves szinten, mérési módszerrel együtt | Számszerűsíti a megengedett kiesést |
| Teljesítményriport gyakorisága | Havi vagy negyedéves | Ellenőrizhetővé teszi a vállalást |
| Nem teljesítés következménye | Kötbér vagy kompenzáció mértéke | Valódi kikényszeríthetőséget ad a szerződésnek |
Milyen SLA szintet kérj, ha a cég NIS2 hatálya alá tartozik
Ha a cég a Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény hatálya alá tartozik, az SLA szerződés nem csak üzleti, hanem megfelelőségi kérdés is.
Miért fontos az incidensnapló a megfelelőség szempontjából
Kiberbiztosítói és NIS2-audit esetén a ticketing rendszer naplója az incidenskezelés egyik hiteles bizonyítéka, ezért mielőtt szerződést kötsz, kérdezd meg, biztosít-e a szolgáltató exportálható, visszamenőleges incidensnaplót. Mikor különösen fontos ez a szempont? Akkor biztosan, ha a cég a NIS2 törvény hatálya alá tartozik, mert az audit során a hatóság pontosan azt vizsgálja, hogy a dokumentáció és a valós működési gyakorlat egyezik-e egymással.
Milyen rendelkezésre állási szintet érdemes kérni kritikus rendszereknél
A szerver üzemeltetés és karbantartás SLA-ja kritikus rendszereknél jellemzően 99,5%-os minimum rendelkezésre állást jelent, ami éves szinten körülbelül 44 órányi maximális kiesést enged meg. Mielőtt eldöntenéd, hogy ez elegendő-e a céged számára, érdemes kiszámolni, mennyibe kerülne egy ekkora kiesés, és ez alapján dönteni arról, szükséges-e a még magasabb, 99,9%-os szintet kérni.
Az IT üzemeltetés, rendszergazda szolgáltatás keretében az IWS a szerződéskötés előtt pontosan ezt a felmérést végzi el, hogy a cég ne túl magas, feleslegesen drága, se túl alacsony, kockázatos SLA szintet válasszon.
Milyen SLA szintet kérj a biztonsági mentésre és a helyreállításra külön
A mentési SLA gyakran elkülönül az általános rendszertámogatási SLA-tól, ezért érdemes külön kérdezni rá.
Miért nem elég, ha csak a mentés létezését garantálja a szerződés
Egy sikeres mentés és egy ténylegesen tesztelt, gyors helyreállítás nem ugyanaz a vállalás, ezért kérdezd meg, milyen helyreállítási időt (RTO) és milyen adatvesztési határt (RPO) garantál a szolgáltató. Az IT biztonság, biztonsági mentés szolgáltatás keretében ezeket a mutatókat érdemes ugyanolyan konkrétsággal kérni a szerződésbe, mint a rendszertámogatási reakcióidőt.
Megéri-e alaposan kitárgyalni az SLA részleteit egy szerződéskötés előtt, ahelyett hogy elfogadnád a szolgáltató alapajánlatát? Akkor mindenképp megéri, ha a cég rendszerei kritikusak a napi működéshez, vagy érzékeny adatot kezel, mert ekkor a pontosan kialkudott SLA jelentősen csökkenti a jövőbeli vitás helyzetek kockázatát.
Miért érdemes referenciákat kérni a tényleges SLA-teljesítésről
Mielőtt aláírnál egy szerződést, kérj konkrét referenciákat olyan ügyfelektől, akik már hosszabb ideje dolgoznak az adott szolgáltatóval, és kérdezd meg tőlük, ténylegesen tartja-e a vállalt reakcióidőt és rendelkezésre állást a gyakorlatban, nem csak papíron.
Melyik szempont dönt végül a megfelelő SLA szint kiválasztásában
A cikk során bemutatott elemek – a rendszerek kritikusság szerinti besorolása, a számszerűsített reakcióidők, a kötbér-klauzula szükségessége, a NIS2-megfelelőségi dokumentáció és a szolgáltató tényleges kapacitása – mind arra a közös következtetésre vezetnek, hogy a megfelelő SLA szint nem egy előre gyártott csomag kiválasztását jelenti, hanem a cég saját kockázati profiljának pontos felmérését. Tapasztalataink alapján a legjobb szerződéseket azok a cégek kötik, amelyek a tárgyalás előtt tisztázzák maguknak, mely rendszerük kiesése okoz azonnali üzleti kárt, és ez alapján kérnek eltérő szintű vállalásokat a kritikus és a kevésbé kritikus rendszerekre, nem pedig egységesen a legmagasabb vagy legalacsonyabb szintet választják mindenre. A mi tapasztalatunk szerint a leggyakoribb hiba nem a rossz szint kiválasztása, hanem az, hogy a cég egyáltalán nem kér számszerű, ellenőrizhető vállalásokat, és így a szerződés a gyakorlatban semmilyen tényleges védelmet nem nyújt egy csúszó vagy elmaradó szolgáltatóval szemben.
Mi az első lépés a szerződéskötés előtt
Mikor érdemes elkezdeni az SLA szint tudatos meghatározását? Már jóval a szerződéskötés előtt, amint a cég felismeri, hogy a jelenlegi vagy tervezett IT-szolgáltatói kapcsolatban nincs pontosan rögzített, számszerű vállalás. Az IT üzemeltetés, rendszergazda szolgáltatás keretében az IWS minden ügyfélnél a rendszerek kritikusság szerinti felmérésével kezdi a szerződéskötést, hogy a végleges SLA szint valóban a cég tényleges kockázatához és nem egy általános, mindenkire egyformán alkalmazott sablonhoz igazodjon.