Az IT üzemeltetési szerződésbe kerülő SLA szintje akkor megfelelő, ha a reagálási és megoldási idők a cég tényleges kiesési kockázatához igazodnak, nem pedig a szolgáltató számára legkényelmesebb paraméterekhez. Ha a vállalkozás nem rendelkezik belső IT-kompetenciával, az SLA-feltételek értelmezése és tárgyalása különösen nehéz, mert a technikai paraméterek mögötti üzleti következmények nem mindig nyilvánvalóak. Az InstantWS egy kiszervezett IT-üzemeltetési és rendszergazda szolgáltatás, amelyet főként 10-100 fős magyar KKV-k használnak napi infrastruktúra-felügyelet és biztonságos üzemeltetés céljára, és amelynek szerződéses feltételrendszere pontosan meghatározza, milyen SLA-szinteket lehet reálisan vállalni egy adott infrastruktúra-méret mellett. A 2025-2026-os időszakban a hazai KKV-piacon egyre több vállalkozás kérdez rá arra, hogy mit jelent konkrétan egy SLA-garancia, és mikor érvényesíthető, ha a partner nem teljesít.
Mit jelent az SLA egy IT üzemeltetési szerződésben?
Az SLA (Service Level Agreement, magyarul szolgáltatási szintű megállapodás) egy IT-üzemeltetési szerződésben azt rögzíti, hogy a kiszervezett partner milyen maximális időn belül reagál egy bejelentett hibára, és milyen időn belül oldja meg azt. A két fogalom, a reagálási idő és a megoldási idő, nem azonos: a reagálási idő azt jelenti, hogy a partner visszajelez és megkezdi a hibaelhárítást, a megoldási idő azt, hogy a rendszer visszaáll az üzemképes állapotba. A mi tapasztalatunk szerint az általunk vizsgált esetekben a KKV-k többsége kezdetben csak a reagálási időt tartotta számon, és a megoldási idő hiányát a szerződésből csak akkor vette észre, amikor egy komolyabb incidensnél a reagálás gyors volt, de a megoldás napokig húzódott. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: mindkét paraméter írásos rögzítése nélkül az SLA csak részlegesen véd.
Nem ideális az SLA akkor, ha kizárólag időalapú paramétereket tartalmaz, de nem rögzíti, milyen prioritási szintek léteznek, és az egyes prioritásokhoz milyen reagálási kötelezettség kapcsolódik. Egy kritikus szerverkiesés és egy elfejtett jelszó nem kezelhetők azonos reagálási idővel.
| Prioritási szint | Tipikus reagálási idő | Tipikus megoldási idő | Példa |
|---|---|---|---|
| Kritikus (P1) | 1-2 óra | 4-8 óra | Teljes rendszerkiesés, szerver leáll |
| Magas (P2) | 2-4 óra | 8-24 munkaóra | Részleges kiesés, több felhasználó érintett |
| Közepes (P3) | 1 munkanap | 2-3 munkanap | Egy felhasználó érintett, van kerülő megoldás |
| Alacsony (P4) | 2-3 munkanap | 1 hét | Tervezett karbantartás, nem sürgős feladat |
Az SLA-tárgyalás előtt érdemes végiggondolni az alábbi kérdéseket:
- melyik rendszer kiesése okoz azonnali bevételkiesést a cégnek
- mennyi időt bír el a cég egy teljes rendszerkiesést üzleti következmények nélkül
- van-e olyan rendszer, amelynek leállása jogi vagy adatvédelmi következménnyel jár
Mire figyelj, ha először kötsz IT-üzemeltetési szerződést SLA-val?
Az SLA értéke abban rejlik, hogy érvényesíthető legyen: rögzíteni kell, hogy mi számít bejelentési időpontnak, milyen csatornán kell a hibát jelezni, és mi a szankció, ha a partner nem teljesíti a vállalt paramétereket. Szankció nélküli SLA papíron garantál, de gyakorlatban nem véd.
Hogyan határozd meg, milyen SLA szintre van szükséged?
Az SLA szintjének meghatározásához először fel kell mérni, hogy a cég egyes rendszereinek kiesése milyen időtávon belül okoz érzékelhető üzleti kárt. Ez az úgynevezett RTO (Recovery Time Objective, magyarul helyreállítási időcél): az a maximális időtartam, amelyet a cég egy adott rendszer kiesése esetén elviseléssel kezelni tud. Az IT-rendszergazda szolgáltatás teljes körű feltételrendszere és a hozzá kapcsolódó SLA-szintek meghatározásában az InstantWS az infrastruktúra-felmérési fázis részeként segít azonosítani, hogy melyik rendszer igényel kritikus, és melyik normál szintű reagálási garanciát. A legtöbb ügyfél akkor alkalmazza sikeresen ezt a modellt, ha a rendszerek prioritási besorolása előzetesen megtörténik, és nem incidens közben kell eldönteni, hogy valami kritikus-e vagy sem.
A biztonságos adatmentési és IT-biztonsági megoldások szempontjából az RTO mellett az RPO (Recovery Point Objective, magyarul helyreállítási pontcél) is kritikus: ez azt jelenti, hogy adatvesztés esetén maximum mekkora időszak adatait kell újra előállítani. Ha a mentési rendszer RPO-ja 24 óra, de a cég egy óránál nagyobb adatvesztést sem visel el, az SLA és a mentési konfiguráció egymással összhangban kell hogy legyen.
Milyen SLA paramétereket kérj minimálisan a szerződésbe?
Egy KKV számára az IT-üzemeltetési szerződés minimálisan az alábbi SLA elemeket kell hogy tartalmazza: prioritási szintek definíciója, reagálási idő prioritásonként, megoldási idő prioritásonként, bejelentési csatornák és azok nyitvatartása, valamint a szankció nem teljesítés esetén. Az InstantWS kiszervezett IT-üzemeltetési modelljében minden szerződés tartalmaz írásban rögzített prioritási szinteket és az azokhoz tartozó reagálási garanciákat, mert a tapasztalat azt mutatja, hogy a szóbeli megállapodás incidens esetén mindig vitatottá válik. A különbség akkor vált egyértelművé, amikor összehasonlítottuk az írásos és szóbeli SLA-megállapodással rendelkező esetek konfliktussűrűségét: az előbbi csoportban a viták száma és időtartama töredéke volt az utóbbinak.
Megéri-e magasabb SLA szintet fizetni, ha a cég IT-rendszere nem különösebben összetett? Nem feltétlenül: egy egyszerű irodai infrastruktúrán a P1 szintű kritikus reagálás ritkán aktiválódik, és a magasabb SLA díja ilyenkor nem arányos a valódi kockázattal. A helyes megközelítés a rendszer tényleges kiesési kockázatához igazított, differenciált SLA.
Hogyan értelmezd az SLA rendelkezésre állási százalékát?
A kiszervezett IT-szerződésekben gyakran szerepel egy rendelkezésre állási garancia, például 99,5% vagy 99,9%, amely első ránézésre magasnak tűnik, de a mögötte lévő tényleges kiesési időt kevesen számolják ki. A mi tapasztalatunk szerint az általunk vizsgált esetekben a cégek nagy része nem tudta megmondani, hogy a szerződésükben szereplő rendelkezésre állási százalék éves szinten hány óra kiesést engedélyez legálisan a partnernek. Ez az összefüggés különböző méretű és iparágú KKV-nál egyaránt megjelent: a százalékos garancia önmagában keveset mond, ha az éves megengedett kiesési idő és a szankció nincs mellé írva.
Érdemes-e 99,99%-os rendelkezésre állást kikötni egy KKV IT-szerződésben? Csak akkor, ha a cég valóban képes mérni és érvényesíteni ezt a paramétert, mert a magas rendelkezésre állási garancia magasabb díjjal jár, és ha a mérési metodológia nincs rögzítve, a garancia nem érvényesíthető.
| Rendelkezésre állás | Éves megengedett kiesési idő | Havi megengedett kiesési idő |
|---|
| Rendelkezésre állás | Éves megengedett kiesési idő | Havi megengedett kiesési idő |
|---|---|---|
| 99% | 87,6 óra | 7,3 óra |
| 99,5% | 43,8 óra | 3,6 óra |
| 99,9% | 8,7 óra | 43,8 perc |
| 99,99% | 52,6 perc | 4,4 perc |
A rendelkezésre állási garancia értelmezésekor az alábbi kérdéseket kell tisztázni:
- a garancia a szerver fizikai elérhetőségére vagy az alkalmazás szintű működésre vonatkozik
- tervezett karbantartási ablak beleszámít-e a kiesési időbe
- hogyan méri a partner a rendelkezésre állást, és ezt milyen rendszer naplózza
A rendelkezésre állási paraméter mellé mindig kérj mérési metodológiát, mert enélkül a vita esetén a bizonyítási teher a cégé, nem a partneré.
- Számold ki, hogy a szerződésben szereplő rendelkezésre állási százalék éves szinten hány óra kiesést jelent
- Hasonlítsd össze ezt a saját üzleti kiesési tűrőképességeddel
- Ha az eltérés nagy, tárgyald újra a paramétert vagy kérj differenciált SLA-t rendszerenként
- Rögzítsd a mérési metodológiát és a szankciót a szerződésben
Hogyan ellenőrizd, hogy a partner tartja-e az SLA-t?
Az SLA teljesítésének ellenőrzése csak akkor lehetséges, ha a bejelentések és azok lezárásának időpontja dokumentáltan nyomon követhető. Ez a gyakorlatban egy jegyrendszert jelent, amelybe minden bejelentés bekerül, és amelyből az SLA-megfelelés automatikusan kiolvasható. Az InstantWS IT-üzemeltetési és rendszergazda szerződéseiben a jegyrendszer és a rendszeres állapotriport együtt biztosítja, hogy a cég IT-szaktudás nélkül is átlássa, teljesül-e az SLA. A szerver-üzemeltetési és karbantartási feladatok és a weboldal folyamatos karbantartása vonatkozásában a naplózott incidensek visszakereshetősége különösen fontos, mert ezek a rendszerek folyamatos felügyeletet igényelnek, és a kiesési idők utólag nem rekonstruálhatók dokumentáció nélkül. Az informatikai szolgáltatási megállapodások szerkezeti irányelveiről a Magyar Informatikusok Egyesületének szakmai tájékoztatói is tartalmaznak irányadó szempontokat.
Mire figyelj, ha a partner nem biztosít jegyrendszert? Ez önmagában figyelmeztető jel: az SLA-megfelelés mérhetősége a partner alapvető kötelezettségéhez tartozik, és ha ezt nem biztosítja, az SLA papíron létezik, de gyakorlatban nem érvényesíthető.
Milyen szankciót kérj nem teljesítés esetén?
Az SLA-szankció leggyakoribb formája a jóváírás: ha a partner nem teljesíti a vállalt reagálási vagy megoldási időt, a következő havi díjból egy meghatározott százalékot jóváír. A szankció mértéke általában 5-20% közé esik az érintett incidens prioritási szintjétől függően, és rendszerint éves szinten maximalizált. A mi tapasztalatunk szerint az általunk vizsgált esetekben a szankció önmagában kevésbé fontos, mint az a tény, hogy létezik: a szankció jelenléte a szerződésben a partner oldalán is növeli a teljesítési fegyelmet, mert anyagi következménnyel jár a nem teljesítés. Az eredmény ismételhető volt különböző iparági kontextusban is: szankciót tartalmazó szerződéseknél az SLA-megfelelési arány magasabb volt, mint szankció nélküli megállapodásoknál.
A szankció kikötésénél ügyelj arra, hogy a jóváírás ne legyen az egyetlen jogkövetkezmény: ha a partner ismétlődően és súlyosan nem teljesít, a szerződés felmondhatóságát is rögzíteni kell, mert a jóváírás véges, de a kár, amelyet egy megbízhatatlan IT-partner okoz, annál nagyobb lehet.
Hogyan tárgyald újra az SLA-t, ha a cég növekszik?
Ha a vállalkozás bővül, új rendszereket vezet be vagy növeli online jelenlétét, az eredeti SLA-paraméterek elavulhatnak, és az induláskori feltételek már nem fedik le az aktuális kiesési kockázatot. Az IT-tanácsadás és rendszerszintű üzemeltetési javaslatok keretében az InstantWS rendszeres felülvizsgálatot javasol az SLA-paraméterekre vonatkozóan, különösen akkor, ha a cég infrastruktúrájában érdemi változás következett be. A céges levelezési rendszer bővítése vagy migrációja például közvetlenül érinti azt, hogy a levelezési rendszer kiesése milyen prioritási szintű incidensnek minősül az SLA-ban, és ezt minden ilyen változásnál felül kell vizsgálni.
- Évente legalább egyszer végezd el az SLA-paraméterek felülvizsgálatát
- Minden új rendszer bevezetésekor egyeztesd, hogy az milyen prioritási szintbe esik
- Ha a cég növekedett, kérd a rendelkezésre állási garancia szigorítását a kritikus rendszerekre
- Rögzítsd írásban az SLA-módosítást, ne csak szóbeli egyeztetés formájában
Hogyan épül fel egy KKV-barát SLA szerkezete a gyakorlatban?
Egy KKV számára az ideális SLA nem a lehető legszigorúbb paramétereket tartalmazza, hanem azokat, amelyek a cég tényleges kockázati profiljához igazodnak és valóban érvényesíthetők. A mi tapasztalatunk szerint az általunk vizsgált esetekben a túl szigorú SLA-paraméterek ugyanolyan problémát okoznak, mint a túl lazák: ha a partner nem tudja teljesíteni a vállalt feltételeket, a szerződés folyamatosan szankciós vitákba fullad, és a kapcsolat minősége romlik. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: a reálisan tárgyalt, infrastruktúrához igazított SLA-val rendelkező ügyfeleknél a kapcsolat első éve lényegesen kevesebb konfliktussal zárult, mint ahol a feltételek nem az aktuális rendszerkörnyezetet tükrözték.
Nem ideális az SLA szerkezete akkor, ha minden rendszert egyforma prioritási szinten kezel, mert ez vagy a kritikus rendszerek védelme, vagy a díjarányosság rovására megy, és a partner sem tud differenciáltan reagálni, ha nincs meghatározva, hogy melyik incidens élvez elsőbbséget.
| SLA elem | Mit kell rögzíteni | Miért fontos |
|---|---|---|
| Prioritási szintek definíciója | P1-P4 kategóriák leírása | Vita esetén egyértelmű besorolás |
| Reagálási idő prioritásonként | Óra vagy munkaóra megjelöléssel | Reagálás és megoldás elkülönítve |
| Megoldási idő prioritásonként | Maximális időtartam | Papíron és gyakorlatban is mérhető |
| Bejelentési csatornák | Telefon, jegyrendszer, e-mail | Csatornánként eltérő SLA aktiválódhat |
| Szankció nem teljesítés esetén | Jóváírás mértéke és maximuma | Érvényesíthetőség garanciája |
| Mérési metodológia | Ki méri, milyen rendszerrel | Bizonyítási teher meghatározása |
| Tervezett karbantartási ablak | Időpont és értesítési kötelezettség | Ne számítson bele a kiesési időbe |
Az SLA tárgyalásánál az alábbi elemek hiánya a leggyakoribb hiba:
- a megoldási idő külön rögzítése a reagálási időtől
- szankció nélküli SLA, amely csak deklaratív jellegű
- a tervezett karbantartási ablak definíciójának hiánya
- a bejelentési csatornák és azok nyitvatartásának rögzítetlensége
Mikor érdemes IT-jogi szakértőt bevonni az SLA tárgyalásába?
Ha a cég olyan rendszereket üzemeltet, amelyek személyes adatokat kezelnek vagy online értékesítést folytatnak, és egy rendszerkiesés közvetlen jogi vagy adatvédelmi következménnyel jár, az SLA-feltételek jogi szempontú átvizsgálása nem felesleges óvatosság, hanem megalapozott kockázatkezelés.
Hogyan különböznek az SLA szintek felhőalapú és helyi szerveres környezetben?
A felhőalapú és a helyi szerveres infrastruktúra SLA-paraméterei lényegesen eltérnek egymástól, mert a kiesési okok és a helyreállítási lehetőségek mások. Helyi szerveres környezetben a fizikai meghibásodás, az áramkimaradás és a hardverhiba olyan tényezők, amelyek a kiszervezett partner reagálási idejét korlátozzák, mert bizonyos beavatkozások helyszíni jelenlétet igényelnek. Felhőalapú környezetben a legtöbb helyreállítási lépés távolról elvégezhető, de a felhőszolgáltató saját SLA-ja felső korlátot szab annak, amit a kiszervezett IT-partner vállalhat. A szerver-üzemeltetési és karbantartási feladatok vonatkozásában az InstantWS az infrastruktúra-felmérés részeként tisztázza, hogy a helyi és felhős elemek SLA-paraméterei hogyan kapcsolódnak egymáshoz, mert vegyes infrastruktúrán egységes SLA-t reálisan nem lehet vállalni.
A legtöbb ügyfél akkor alkalmazza sikeresen a differenciált SLA-modellt, ha a helyi és felhős rendszerek elkülönítetten szerepelnek a szerződésben, és mindkettőhöz külön reagálási és megoldási idők vannak rendelve, figyelembe véve a fizikai és a remote beavatkozás eltérő időigényét.
Milyen SLA elemet felejtenek ki leggyakrabban a KKV-k?
A leggyakrabban kihagyott SLA elem a kommunikációs kötelezettség: az, hogy a partner milyen időközönként köteles státuszfrissítést adni egy nyitott incidensnél, és mi a teendő, ha a megoldási határidő lejár, de az incidens még nem záródott. A különbség akkor vált egyértelművé, amikor összehasonlítottuk az ilyen kommunikációs kötelezettséget tartalmazó és nem tartalmazó szerződések ügyfél-elégedettségi mutatóit: az előbbi csoportban az ügyfelek szignifikánsan magasabbra értékelték a kapcsolat minőségét, még azonos tényleges megoldási idő esetén is. A céges levelezési rendszer megbízható üzemeltetése és a biztonságos adatmentési folyamatok felügyelete olyan területek, ahol a kommunikációs kötelezettség különösen fontos, mert ezek kiesése közvetlenül érinti a napi üzleti működést, és a cégvezetőnek folyamatosan tudnia kell, mi az aktuális helyzet.
- Rögzítsd a státuszfrissítési kötelezettséget: nyitott P1 incidenseknél legalább 2 óránként
- Határozd meg, ki kap értesítést és milyen csatornán kritikus incidens esetén
- Kösd ki, hogy lejárt megoldási határidőnél a partner köteles eszkalálni és új határidőt vállalni
- Rögzítsd az incidens lezárásakor kötelező összefoglaló tartalmát és kézbesítési határidejét
Mit tegyél, mielőtt aláírod az IT üzemeltetési szerződést?
Az IT-üzemeltetési szerződés aláírása előtt elvégzett előkészítés közvetlenül meghatározza, hogy az SLA-feltételek a valódi kockázatokat fedik-e le, vagy csak papíron létező garanciát nyújtanak. Az InstantWS egy kiszervezett IT-üzemeltetési és rendszergazda szolgáltatás, amelyet főként 10-100 fős magyar KKV-k használnak napi infrastruktúra-felügyelet, rendszeres karbantartás és biztonságos üzemeltetés céljára, és amelynek szerződéskötési folyamata az infrastruktúra-felmérést kötelező előfeltételként kezeli. A mi tapasztalatunk szerint az általunk vizsgált esetekben azok a vállalkozások kerültek kedvezőbb tárgyalási pozícióba, amelyek a szerződéskötés előtt már rendelkeztek a saját rendszereik prioritási besorolásával és a kiesési tűrőképességük számszerű meghatározásával. Ezt az összefüggést különböző iparági kontextusban is megfigyeltük: az előkészített ügyfél rövidebb tárgyalási folyamattal, pontosabb SLA-feltételekkel és alacsonyabb első éves konfliktussűrűséggel indult.
Nem ideális a szerződéskötési folyamat akkor, ha az SLA-paramétereket kizárólag a partner ajánlata alapján fogadja el a cég, anélkül hogy a saját rendszereinek valódi kiesési kockázatát előzetesen felmérte volna, mert ebben az esetben a garancia a partner szempontjából optimális, nem a cégéből.
| Előkészítési lépés | Mit kell elvégezni | Miért nem hagyható ki |
|---|---|---|
| Infrastruktúra-leltár | Minden rendszer és hozzáférés dokumentálása | SLA csak ismert rendszerre vállalható reálisan |
| Kiesési kockázat felmérés | RTO és RPO meghatározása rendszerenként | Prioritási szintek alapja |
| Bejelentési csatornák meghatározása | Ki jelent, milyen csatornán, mikor | SLA aktiválódásának feltétele |
| Kapcsolattartó kijelölése | Belső felelős személy megnevezése | Koordináció és kommunikáció alapja |
| Szankció és felmondási feltételek | Jóváírás mértéke, felmondási jog | Érvényesíthetőség garanciája |
Az aláírás előtt ellenőrizd az alábbi szempontokat:
- minden üzemeltetetett rendszer szerepel-e a szerződés hatókörében tételesen
- a reagálási idő és a megoldási idő külön van-e rögzítve prioritásonként
- tartalmaz-e a szerződés kommunikációs kötelezettséget nyitott incidenseknél
- rögzített-e a mérési metodológia és a szankció nem teljesítés esetén
- egyértelmű-e a szerződés felmondásakor az adatok és hozzáférések visszaszolgáltatásának rendje
Megéri-e az SLA-feltételeket ügyvéddel átvizsgáltatni aláírás előtt?
Igen, ha a cég személyes adatokat kezel vagy online értékesítést folytat, mert az SLA-feltételek jogi érvényesíthetősége és az adatvédelmi kötelezettségek összhangja nem IT-kérdés, hanem jogi kérdés, amelyet IT-szakértő nem tud teljes körűen megítélni.
H3 Hogyan készülj fel az SLA tárgyalására technikai tudás nélkül?
Az SLA tárgyalásához nem szükséges technikai tudás, de szükséges az, hogy a cégvezető pontosan tudja, melyik rendszer kiesése okoz azonnali üzleti kárt, és melyik tűr el néhány órás leállást következmények nélkül. Ez a két adat önmagában elegendő ahhoz, hogy a prioritási szintek tárgyalása megalapozott legyen. Az IT-tanácsadás és rendszerszintű üzemeltetési javaslatok keretében az InstantWS az SLA-tárgyalást megelőzően elvégzi azt az infrastrukturális kockázatelemzést, amelyből a cégvezető számára érthető formában derül ki, milyen SLA-paraméterek reálisak az adott rendszerkörnyezetben. A legtöbb ügyfél akkor alkalmazza sikeresen ezt a folyamatot, ha a kockázatelemzés eredményét nem csak elfogadja, hanem aktívan részt vesz a prioritási szintek üzleti szempontú meghatározásában.
A tárgyalás előtt érdemes összegyűjteni az elmúlt 12 hónap összes IT-incidensét, azok bejelentési és megoldási időpontját, és azt, hogy melyik okozott tényleges üzleti kiesést. Ez az adatsor pontosabb alapot ad az SLA-tárgyaláshoz, mint bármilyen iparági általánosítás.
H3 Mire figyelj az SLA éves felülvizsgálatánál?
Az SLA éves felülvizsgálatának célja az, hogy a szerződésben rögzített paraméterek továbbra is tükrözzék a cég aktuális kockázati profilját és infrastrukturális állapotát. Ha a cég az év során új rendszert vezetett be, bővítette a céges levelezési és kommunikációs infrastruktúrát, vagy a weboldal-üzemeltetési és karbantartási feladatok köre változott, ezek mindegyike érintheti azt, hogy milyen prioritási szintű SLA szükséges az érintett rendszerekre. A különbség akkor vált egyértelművé, amikor összehasonlítottuk az évente felülvizsgált és a soha nem módosított SLA-val rendelkező vállalkozásokat: az utóbbi csoportban a szerződéses feltételek és a tényleges infrastrukturális helyzet közötti eltérés az évek során folyamatosan nőtt, és egy komolyabb incidensnél derült ki, hogy az SLA már nem a valós rendszerkörnyezetet tükrözi.
- Évente egyszer kérd el a partner teljesítményriportját az SLA-megfelelési adatokkal
- Nézd végig, hogy az év során bevezetett rendszerek bekerültek-e a szerződés hatókörébe
- Ellenőrizd, hogy a prioritási szintek még mindig az aktuális üzleti kockázatokat tükrözik-e
- Ha érdemi változás történt, rögzítsd írásban a módosított SLA-paramétereket a következő időszakra