SLA jelentése: mit tartalmazzon egy jó SLA?

Az SLA (Service Level Agreement), magyarul szolgáltatási szint megállapodás azt rögzíti, hogy egy szolgáltató milyen szolgáltatási szintet vállal az ügyfél felé, ezt hogyan mérik, és mi történik akkor, ha a vállalt szint nem teljesül.

Szoftverüzemeltetésnél az SLA egyik legfontosabb feladata, hogy a homályos ígéretek helyett mérhető feltételeket teremtsen. A „gyorsan reagálunk a hibákra” például nem SLA-szintű vállalás. Az már igen, ha pontosan meghatározzák, hogy egy kritikus hiba esetén mikor kezdődik a reakcióidő mérése, mennyi a vállalt reakcióidő, milyen időszakban érvényes a vállalás, és milyen feltételekkel történik a helyreállítás.

Egy jól megírt SLA ugyanakkor nem csak válaszidőkből és százalékokból áll. Rögzítenie kell a szolgáltatás határait, a felelősségeket, a hibák prioritását, a kommunikáció módját, a mérési módszereket és a kivételeket is. Különösen fontos ez olyan egyedi szoftverek esetében, amelyek egy vállalkozás napi működésének részévé váltak.

Mit jelent pontosan az SLA?

Az SLA egy szolgáltató és ügyfele közötti, mérhető szolgáltatási vállalásokat tartalmazó megállapodás. Informatikai környezetben vonatkozhat például felhőszolgáltatásra, tárhelyre, hálózatra, üzleti alkalmazásra, egyedi szoftverre vagy ezek üzemeltetésére.

A megállapodásban meghatározott szolgáltatási szint többféle mutatóval leírható. Ilyen lehet a rendelkezésre állás, az incidensre adott reakció ideje vagy egy meghatározott szolgáltatás teljesítménye. A nagy felhőszolgáltatók SLA-i is pontosan definiált szolgáltatási vállalásokkal, mérési módszerekkel, feltételekkel és következményekkel dolgoznak.

Fontos különbség, hogy az SLA nem egyszerűen azt mondja meg, milyen jó egy szolgáltatás, hanem azt, hogy a szolgáltató konkrétan mit vállal az ügyfél felé.

Ez különösen lényeges, ha az alkalmazás valamilyen üzletileg fontos rendszerhez, például vállalatirányítási rendszerhez kapcsolódik. Egy néhány perces kiesés hatása egészen más lehet egy belső segédalkalmazásnál, mint egy olyan rendszernél, amely nélkül a munkatársak nem tudnak rendelést rögzíteni, számlázni vagy kiszolgálni az ügyfeleket.

SLA, SLO és SLI: nem ugyanazt jelentik

A kapcsolódó fogalmakat érdemes szétválasztani.

Az SLI (Service Level Indicator) egy ténylegesen mért mutató. Ilyen lehet például a szolgáltatás rendelkezésre állása vagy egy kérés válaszideje.

Az SLO (Service Level Objective) az adott mutatóhoz kapcsolódó célérték.

Az SLA pedig az ügyfél és szolgáltató közötti szolgáltatási vállalás, amely meghatározhatja a vállalt szintet és a nem teljesítés következményeit. A Microsoft megbízhatósági dokumentációja is elkülöníti az SLA-t mint szerződéses vállalást és az SLO-t mint megbízhatósági célértéket.

Egyszerűsített példával:

• SLI: az elmúlt hónap mért rendelkezésre állása.

• SLO: a szolgáltatás célként kitűzött rendelkezésre állása.

• SLA: az ügyfél felé vállalt szolgáltatási szint, annak feltételeivel és esetleges következményeivel.

Ez a különbség azért lényeges, mert egy üzemeltető belső célértéke lehet szigorúbb annál, amit szerződésben garantál.

Az első kérdés: pontosan mire vonatkozik az SLA?

Az egyik leggyakoribb probléma, hogy a dokumentum részletesen meghatározza a reakcióidőket, de maga a szolgáltatás nincs megfelelően körülhatárolva. Először azt kell rögzíteni, mi tartozik az SLA hatálya alá. Egy üzleti szoftvernél például ide tartozhat:

• az alkalmazás backendje;

• a webes felület;

• az adatbázis;

• bizonyos API-k;

• szerverek vagy felhőinfrastruktúra;

• háttérfolyamatok;

• integrációk;

• hibakezelés;

• monitoring;

• biztonsági frissítések;

• mentések;

• technikai támogatás.

Ugyanilyen lényeges leírni azt is, ami nem része a szolgáltatásnak.

Ha például egy alkalmazás külső számlázó-, fizetési vagy más szolgáltató API-jára támaszkodik, tisztázni kell, hogy annak hibája hogyan befolyásolja az SLA-t. Egy modern üzleti alkalmazás gyakran több komponensből áll, ezért a teljes rendszer rendelkezésre állása nem vezethető le automatikusan egyetlen infrastruktúra-szolgáltató SLA-jából. Ez különösen igaz felhőalapú rendszereknél, ahol maga az alkalmazás is több külső infrastruktúra- és szoftverszolgáltatásra épülhet.

A hibák súlyossági szintjeit egyértelműen definiálni kell

Nem minden hiba egyformán sürgős. Ha egy felhasználó nem tudja megváltoztatni a profilképét, az kellemetlen lehet, de általában nem indokol ugyanolyan reakciót, mint amikor az egész rendszer elérhetetlenné válik.

Ezért az SLA-kban célszerű prioritási vagy súlyossági kategóriákat meghatározni. Ezek elnevezése szolgáltatónként eltérhet, például P1–P4, Severity 1–4 vagy kritikus–alacsony besorolás formájában.

Egy lehetséges logika:

• kritikus: a rendszer vagy egy alapvető üzleti funkció teljesen használhatatlan, és nincs elfogadható kerülőmegoldás;

• magas: jelentős funkció nem működik, sok felhasználó érintett, de a rendszer részben használható;

• közepes: korlátozott működési probléma, amely nem akadályozza meg az alapvető üzleti folyamatokat;

• alacsony: kisebb hiba vagy kényelmetlenség, amelynek nincs jelentős üzleti hatása.

A pontos definíció fontosabb, mint maga az elnevezés. A hibák rendszerezését érdemes összekapcsolni megfelelő hibakövető szoftverrel, hogy az incidensek állapota és előzménye visszakövethető legyen.

Reakcióidő és megoldási idő: két külön vállalás

Az SLA egyik legkönnyebben félreérthető része a reakcióidő. Ha egy szolgáltató azt vállalja, hogy egy kritikus hibára például meghatározott időn belül reagál, az nem feltétlenül jelenti azt, hogy ugyanennyi idő alatt a hibát is kijavítja.

Érdemes ezért külön kezelni legalább a következőket:

• Reakcióidő: mennyi idő telhet el a szabályosan bejelentett incidens és a szolgáltató érdemi reakciója között.

• Helyreállítási vagy megoldási cél: milyen időkeretben törekszik a szolgáltató a működés helyreállítására vagy a probléma megoldására.

A kettő közé további mérföldkövek is kerülhetnek. Meghatározható például az első diagnózis, a státuszfrissítések vagy az eszkaláció időkerete. A hibakövetés és projektmenedzsment kapcsolatáról szóló folyamatok azért is lényegesek, mert egy incidens kezelése nem pusztán technikai javítás: kommunikációs és szervezési feladat is.

Mikortól ketyeg az óra?

Egy „2 órás reakcióidő” önmagában még nem elég pontos. Tisztázni kell, hogy a két óra:

• naptári vagy munkaórát jelent;

• csak munkanapokon számít-e;

• 0–24 órás szolgáltatásra vonatkozik-e;

• mikor indul a mérés;

• melyik bejelentési csatorna indítja el;

• mi történik hiányos hibajegy esetén;

• megáll-e a mérés, ha a szolgáltató az ügyféltől vár szükséges információra.

Például egy péntek este 22:00-kor beküldött kritikus hibajegy teljesen mást jelent 24/7-es ügyelet és hétfőtől péntekig, munkaidőben biztosított támogatás esetén. Ezért a támogatási időszakot ugyanúgy definiálni kell, mint magát a reakcióidőt.

A bejelentések követhető kezeléséhez használható külön ticketing rendszer, de bizonyos szervezeteknél a meglévő feladatkezelő rendszerek is részei lehetnek az operatív folyamatnak.

Mit jelent a 99,9%-os rendelkezésre állás?

A rendelkezésre állási vállalás az SLA-k egyik legismertebb eleme, de a százalék önmagában félrevezető lehet.

Nem elég azt írni, hogy:

„A szolgáltatás rendelkezésre állása 99,9%.”

A dokumentumból annak is ki kell derülnie, hogy:

• milyen időszakra számítják;

• pontosan mely szolgáltatásokat mérik;

• mi számít kiesésnek;

• honnan történik a mérés;

• milyen tervezett karbantartások vannak kizárva;

• milyen külső hibák nem számítanak bele;

• részleges szolgáltatáskimaradás hogyan kerül elszámolásra.

A felhőszolgáltatók SLA-i jól mutatják, mennyire szolgáltatásspecifikus lehet egy ilyen vállalás. A Google Cloud külön SLA-kat tesz közzé az egyes szolgáltatásokhoz, eltérő rendelkezésre állási célokkal és feltételekkel, a Microsoft pedig szintén szolgáltatásonként definiálja az online szolgáltatásokra vonatkozó vállalásait.

Egy üzleti rendszer esetében ráadásul nemcsak az infrastruktúra számít. Az adattárolás felhőben, az alkalmazás, az adatbázis, a hálózat és a külső integrációk együttesen határozzák meg, hogy a felhasználó ténylegesen tudja-e használni a szolgáltatást.

A tervezett karbantartást is szabályozni kell

Szoftvereket időnként frissíteni kell. Ez lehet hibajavítás, biztonsági frissítés, adatbázis-módosítás vagy infrastruktúra-karbantartás. Az SLA-ban ezért érdemes rögzíteni:

• mikor végezhető tervezett karbantartás;

• mennyivel korábban kell jelezni;

• van-e meghatározott karbantartási ablak;

• beleszámít-e a rendelkezésre állási mutatóba;

• mi történik sürgős biztonsági frissítés esetén.

Egy rendszer hosszú távú működtetése ugyanis nem választható teljesen külön a továbbfejlesztéstől. Az üzleti igények változnak, a függőségek frissülnek, és idővel olyan módosításokra is szükség lehet, amelyek túlmutatnak a napi üzemeltetésen. Az egyedi szoftverfejlesztés vállalkozásra szabott megközelítésénél ezért már a fejlesztés során célszerű gondolni a későbbi működtethetőségre.

Mi tartozik az üzemeltetéshez, és mi számít fejlesztésnek?

Ez az egyik legfontosabb határvonal. Az ügyfél azt mondja:

„A rendszer nem azt csinálja, amit szeretnénk.”

A szolgáltatónak viszont el kell döntenie, hogy hibáról vagy új fejlesztési igényről van szó. Ha a specifikáció szerint egy funkciónak működnie kellene, de nem működik, az jellemzően hibajavítási kérdés. Ha viszont a funkció megfelelően működik, csak az ügyfél mostantól más működést szeretne, az már változtatási vagy fejlesztési igény lehet.

Ezt az SLA-ban vagy a hozzá kapcsolódó szerződéses dokumentációban érdemes világosan elválasztani. Azért is fontos a határ, mert az egyedi szoftverfejlesztés cégek számára folyamatosan követheti az üzleti folyamatok változását, míg az üzemeltetési SLA alapvetően egy már meghatározott szolgáltatási kör fenntartására vonatkozik.

RTO és RPO: amikor nem elég azt tudni, mikor reagál a support

Komolyabb rendszereknél két további fogalom is előkerülhet.

• Az RTO (Recovery Time Objective) azt fejezi ki, milyen helyreállítási időt céloz meg a szervezet egy kiesést követően.

• Az RPO (Recovery Point Objective) arra vonatkozik, hogy helyreállítás esetén mekkora adatvesztési időablak elfogadható.

Tegyük fel, hogy egy adatbázist biztonsági mentésből kell visszaállítani. Nemcsak az a kérdés, mennyi idő alatt működik újra a rendszer, hanem az is, milyen állapotig lehet visszaállítani az adatokat. Egy óránként mentett adatbázis és egy naponta mentett adatbázis egészen más üzleti kockázatot jelenthet. Ezért a rendelkezésre állás, az RTO és az RPO nem csereszabatos fogalmak. Más kérdésekre válaszolnak.

Monitoring nélkül az SLA nehezen mérhető

A vállalt szolgáltatási szinteket objektíven mérni kell. Ha a felek csak akkor értesülnek a kiesésről, amikor egy felhasználó telefonál, nehéz pontosan megállapítani, mikor kezdődött a probléma. A monitoring figyelheti például:

• a szolgáltatás elérhetőségét;

• API-végpontokat;

• háttérfolyamatokat;

• adatbázis-kapcsolatokat;

• erőforrás-használatot;

• hibaarányt;

• válaszidőket;

• bizonyos üzleti folyamatokat.

Egy megfelelően felépített rendszerben az üzemeltető sok hibáról már azelőtt értesülhet, hogy az ügyfél bejelentené. Ez különösen lényeges olyan összetett rendszereknél, amelyek több alkalmazást kapcsolnak össze. Egy ERP-rendszer vagy más integrált üzleti megoldás esetében például az alkalmazás látszólag működhet, miközben egy háttérintegráció hibája miatt valamely üzleti folyamat már nem fut le megfelelően.

A kommunikáció szabályai is az SLA részét képezhetik

Egy kritikus incidens közben az ügyfélnek nemcsak technikai megoldásra, hanem információra is szüksége van. Érdemes ezért előre rögzíteni:

• hol jelenthető be incidens;

• kik jogosultak kritikus hibát bejelenteni;

• ki kap értesítést;

• milyen gyakran történik státuszfrissítés;

• mikor történik eszkaláció;

• mikor tekinthető lezártnak az incidens.

Ha egy kritikus hiba megoldása több órát vesz igénybe, az ügyfél számára nagy különbséget jelent, hogy közben rendszeresen kap-e információt az aktuális állapotról. Az incidensek dokumentálása később a visszatérő problémák felismerését is segíti. Ebben a feladatkezelő programok hatékony használata és a megfelelő hibajegykezelési folyamat is szerepet kaphat.

Felelősségi körök: nem minden hiba az üzemeltető hibája

Egy SLA-nak az ügyfél kötelezettségeit is célszerű meghatároznia. Előfordulhat például, hogy az üzemeltető nem fér hozzá egy szükséges külső rendszerhez, az ügyfél nem biztosít megfelelő információt a hiba reprodukálásához, vagy egy harmadik fél szolgáltatásában következik be kiesés.

Ezért tisztázni kell többek között:

• ki felel az infrastruktúráért;

• ki kezeli a hozzáféréseket;

• ki felel a külső szolgáltatásokért;

• milyen információkat kell biztosítani hibabejelentéskor;

• mely rendszermódosításokat végezheti el az ügyfél;

• milyen esetekben szünetelhet az SLA-idő mérése.

Az üzemeltetés felelősségi modellje különösen összetett lehet kiszervezett fejlesztésnél. Ha a fejlesztési és üzemeltetési feladatok külső partnerhez kerülnek, célszerű pontosan rögzíteni a szerepeket. A kiszervezett szoftverfejlesztés akkor működik jól, ha a technikai feladatok mellett a felelősségi határok is világosak.

Biztonsági eseményekre külön szabályok lehetnek szükségesek

Nem minden incidens egyszerű működési hiba. Biztonsági eseménynél más reakcióra, kommunikációra és eszkalációra lehet szükség. Az SLA-nak vagy a kapcsolódó biztonsági dokumentációnak ezért érdemes kitérnie arra is, hogyan történik a biztonsági incidensek kezelése.

Egy webes rendszer esetében már az alapvető biztonsági komponensek, például a HTTPS és az SSL/TLS tanúsítványok működése is befolyásolhatja a szolgáltatás használhatóságát.

A biztonsági feladatok azonban jóval szélesebb kört jelenthetnek: jogosultságok, naplózás, frissítések, biztonsági mentések és az incidensekre adott reakció egyaránt része lehet az üzemeltetési modellnek.

Mi történjen, ha az SLA nem teljesül?

Ha a szolgáltatási szinthez nincs meghatározva mérési módszer és következmény, az SLA könnyen puszta ígéretté válhat.

A következmény nem feltétlenül kötbér. Felhőszolgáltatásoknál gyakori megoldás a szolgáltatási jóváírás: például a Google Cloud egyes SLA-i meghatározott feltételek teljesülése mellett pénzügyi jóváírást rendelnek a vállalt szolgáltatási szint elmaradásához, és a Microsoft online szolgáltatásainál is szolgáltatási jóváírás kapcsolódhat az SLA feltételeihez.

Egy egyedi üzemeltetési szerződésben más konstrukció is kialakítható. A lényeg az, hogy előre egyértelmű legyen:

• hogyan állapítják meg a nem teljesítést;

• milyen adatok alapján;

• ki és milyen határidővel jelezheti;

• milyen következmény kapcsolódik hozzá;

• milyen kivételek vannak.

A konkrét jogi és pénzügyi feltételeket természetesen az adott szerződéshez kell kialakítani.

Milyen kivételeket érdemes meghatározni?

A rendelkezésre állási vállalás általában nem azt jelenti, hogy a szolgáltató minden elképzelhető eseményért felelősséget vállal. Az SLA hatályán kívül eshetnek például előre meghatározott karbantartási időszakok, az ügyfél által okozott hibák, bizonyos külső szolgáltatói problémák vagy olyan konfigurációk, amelyek nem felelnek meg a szolgáltatás előfeltételeinek.

A Microsoft SLA-értelmezési útmutatója is hangsúlyozza, hogy a vállalások feltételekhez és kizárásokhoz kötődnek, ezért a puszta rendelkezésre állási százalék helyett mindig a teljes definíciót kell vizsgálni.

A kivételeket azonban nem érdemes túl általánosan megfogalmazni. A „külső körülményekért nem vállalunk felelősséget” típusú mondatok helyett sokkal használhatóbb, ha egyértelműen meghatározható, milyen esemény melyik fél felelősségi körébe tartozik.

SLA egy SaaS vagy előfizetéses rendszer esetében

Az SLA különösen fontos lehet akkor, ha ugyanazt a szolgáltatást sok ügyfél használja. Egy előfizetéses rendszer esetében egyetlen központi hiba egyszerre sok felhasználót érinthet. Ilyenkor a rendelkezésre állás, a monitoring, az incidenskezelés és a kapacitástervezés már magának a szolgáltatási modellnek a része.

Más megközelítés szükséges viszont egy kizárólag egyetlen vállalat által használt belső alkalmazásnál. Ott az SLA-t közvetlenül az adott üzleti folyamat kritikus pontjaihoz lehet igazítani. Nem feltétlenül a magasabb százalék a jobb megoldás. Az a megfelelő szolgáltatási szint, amely arányban áll az üzleti kockázattal és a fenntartás költségével.

A túl szigorú SLA-nak ára van

A 24/7 rendelkezésre álló szakértői ügyelet, a néhány perces reakcióidő és a magas rendelkezésre állási vállalás technikai és szervezeti hátteret igényel. Szükség lehet többek között:

• redundáns infrastruktúrára;

• automatikus monitoringra;

• riasztási rendszerre;

• ügyeleti rendre;

• megfelelő dokumentációra;

• automatizált mentésekre;

• helyreállítási eljárásokra;

• több szakember bevonására.

Ezért az SLA kialakításakor nem az a cél, hogy minden szám a lehető legszigorúbb legyen. Egy kevésbé kritikus belső adminisztrációs rendszerhez indokolatlan lehet ugyanazt a szolgáltatási szintet fenntartani, mint egy olyan rendszerhez, amelynek leállása azonnal megakadályozza az értékesítést.

Az adminisztrációs rendszerek esetében is az üzleti szerep alapján érdemes meghatározni a szükséges rendelkezésre állást, nem pusztán technikai szempontok alapján.

Mit tartalmazzon tehát egy jó szoftverüzemeltetési SLA?

Egy használható SLA-nak legalább az alábbi kérdésekre egyértelmű választ kell adnia:

• pontosan milyen szolgáltatásokra vonatkozik;

• mikor érhető el a támogatás;

• milyen csatornán jelenthető be hiba;

• hogyan történik a hibák prioritásának meghatározása;

• mennyi a vállalt reakcióidő prioritásonként;

• van-e helyreállítási vagy megoldási célidő;

• hogyan történik az eszkaláció;

• milyen gyakran kap az ügyfél státuszfrissítést;

• milyen rendelkezésre állást vállal a szolgáltató;

• hogyan számítják ezt a rendelkezésre állást;

• mi számít kiesésnek;

• mely események számítanak kivételnek;

• hogyan kezelik a tervezett karbantartást;

• ki felel a monitoringért és a biztonsági mentésekért;

• milyen RTO- és RPO-célok érvényesek, ha ezek relevánsak;

• mi az ügyfél felelőssége;

• mi történik harmadik fél szolgáltatásának hibája esetén;

• hogyan dokumentálják és zárják le az incidenseket;

• mi történik, ha a vállalt szolgáltatási szint nem teljesül.

Az SLA akkor működik jól, ha egy valódi incidens közben nem újabb kérdéseket hoz létre, hanem válaszokat ad.

Egy szoftver hosszú távú működtetésénél ezért az SLA-t célszerű már a technikai és üzleti folyamatok ismeretében kialakítani. A megfelelő szolgáltatási szint ugyanis nem választható el attól, hogyan épül fel maga a rendszer, milyen függőségei vannak, és mekkora üzleti kárt okozhat egy kiesés. Ezt a szemléletet érdemes már a szoftverfejlesztési projekt tervezésekor figyelembe venni, nem csak akkor, amikor az elkészült alkalmazás üzemeltetése elkezdődik.