Egy hétfő reggeli szerverhiba, egy nem működő levelezés vagy egy elérhetetlen üzleti alkalmazás percek alatt megakaszthatja az egész irodát. Ilyenkor nem az a kérdés, hogy ki ért a technikához, hanem az, hogy ki kezd el foglalkozni a hibával, mikor, és milyen vállalás alapján. Az SLA alapú üzemeltetés erre ad világos választ: előre rögzíti, milyen gyorsan reagál az IT-partner, milyen esetek élveznek elsőbbséget, és milyen szolgáltatások tartoznak a folyamatos felügyeletbe.
Egy kis- vagy középvállalkozásnál az informatika ritkán önálló üzleti terület. A számlázás, az ügyfélkapcsolat, a belső kommunikáció, a fájlok elérése és sokszor a munkavégzés maga is a működő rendszerektől függ. Ha nincs belső IT-csapat, könnyű belecsúszni az eseti tűzoltásba: akkor keresnek szakembert, amikor már áll a munka. A szerződéses, szolgáltatási szinthez kötött üzemeltetés ennek a kockázatát csökkenti.
Mit jelent az SLA alapú üzemeltetés?
Az SLA a szolgáltatási szint megállapodása. Nem egy hangzatos technikai kifejezés, hanem a megbízó és az üzemeltető közötti egyértelmű vállalás. Meghatározza, hogy egy adott típusú hibabejelentés után milyen időn belül történik meg a visszajelzés, a hiba vizsgálatának megkezdése, illetve indokolt esetben a helyszíni kiszállás.
Lényeges különbség van a válaszidő és a megoldási idő között. A válaszidő azt jelenti, hogy a szolgáltató mennyi idő alatt veszi fel a kapcsolatot, értékeli a hibát és megkezdi az intézkedést. A megoldás időtartama már függhet a hiba természetétől: egy elfelejtett jelszó vagy nyomtatóbeállítás gyakran gyorsan kezelhető, egy meghibásodott háttértár, sérült adatbázis vagy külső szolgáltatóhoz kötődő leállás viszont hosszabb helyreállítást igényelhet.
Egy korrekt SLA ezért nem ígér lehetetlent. Azt rögzíti pontosan, hogy kritikus helyzetben nem marad magára az ügyfél, és a hiba kezelése előre meghatározott rend szerint indul el.
Milyen elemeket érdemes rögzíteni?
A jó megállapodás mindig a vállalkozás tényleges működéséhez igazodik. Más szintű rendelkezésre állás kell egy nyolcórás irodának, és más egy olyan cégnek, amelynek kollégái folyamatosan, több telephelyről vagy külföldről dolgoznak.
Az SLA-ban általában az alábbiak szerepelnek:
- a támogatási időszak, például munkanapokon munkaidőben vagy kiterjesztett rendelkezésre állással;
- a hibák súlyossági kategóriái és azok üzleti hatása;
- a vállalt reakcióidők az egyes kategóriákhoz;
- a távoli beavatkozás és a helyszíni kiszállás rendje;
- a monitorozás, mentésellenőrzés, karbantartás és riportolás feladatai;
- az ügyfél és az üzemeltető felelősségi körei, kapcsolattartói és bejelentési csatornái.
A részletek nem adminisztratív terhet jelentenek. Éppen ellenkezőleg: egy stresszes hibánál megspórolják a félreértéseket. Az irodavezető tudja, kit kell értesíteni, a munkatársak tudják, milyen információt adjanak át, az üzemeltető pedig gyorsabban tud érdemi lépést tenni.
Miért több ez, mint gyors hibaelhárítás?
Az eseti hibaelhárításnak is megvan a helye. Ha egy otthoni számítógép nem indul, adatmentésre van szükség, vagy egy kisebb iroda egyszeri telepítési feladattal keres szakembert, a gyors távoli segítség vagy kiszállás teljesen ésszerű megoldás lehet. Nem minden helyzet igényel havidíjas szerződést.
A vállalati informatika azonban idővel összetettebbé válik. Új kollégák érkeznek, nő a levelezési fiókok száma, megjelennek a felhőalapú rendszerek, a távoli hozzáférések, a mobileszközök és a jogosultsági kérdések. Egyetlen hiba mögött ilyenkor gyakran több rendszer kapcsolata áll. Ha a problémák csak akkor kerülnek felszínre, amikor már kiesést okoznak, a javítás drágább, a munkatársak pedig bizonytalanabbá válnak.
Az SLA alapú üzemeltetés szemlélete ezért megelőző. A rendszerfelügyelet jelezheti például, ha fogy a szerver tárhelye, egy mentés nem futott le, egy eszköz erőforrásai tartósan túlterheltek, vagy egy hálózati kapcsolat szokatlanul instabillá vált. Ezekből még nem mindig lesz azonnali üzleti leállás, de a korai beavatkozás sok kellemetlen helyzetet előzhet meg.
A hiba súlyossága az üzleti hatástól függ
Nem minden informatikai probléma egyformán sürgős. Ha egyetlen felhasználó nem tud nyomtatni, az kellemetlen és megoldandó hiba. Ha a teljes iroda nem éri el a levelezést, a központi fájlokat vagy az ügyfélkezelő rendszert, az már kritikus esemény lehet. A prioritásokat nem a technikai kifejezések, hanem a cég működésére gyakorolt hatás alapján érdemes meghatározni.
Egy jól kialakított szerződésben a kritikus hibák gyorsabb reagálást kapnak. A kevésbé sürgős, de fontos feladatok – például új munkaállomás telepítése, új belépő fiókjának előkészítése vagy egy szoftver beállítása – tervezetten, a napi működés megzavarása nélkül végezhetők el.
Ez az átláthatóság az ügyfélnek is előnyös. Nem kell minden bejelentésnél külön eldöntenie, hogy „elég sürgős-e” a probléma. A szolgáltatási szintek és az előre egyeztetett kapcsolattartás rendet visznek a bejelentésekbe.
Mitől működik valóban egy SLA-szerződés?
Az SLA önmagában nem old meg hibákat. Akkor értékes, ha mögötte naprakész dokumentáció, rendszeres kommunikáció és olyan üzemeltetési gyakorlat áll, amely képes a vállalások teljesítésére. A szerződés megkötése előtt ezért fel kell mérni a meglévő környezetet: milyen eszközök vannak használatban, hol tárolódnak az adatok, hogyan működik a mentés, kik rendelkeznek adminisztrátori hozzáféréssel, és mely szolgáltatások kritikusak a napi munkához.
Külön figyelmet érdemel a mentési stratégia. A mentés nem attól megbízható, hogy létezik egy külső meghajtó vagy felhőmappa. Ellenőrizni kell, hogy a mentések valóban lefutnak-e, visszaállíthatók-e, megfelelő időszakot fednek-e le, és egy zsarolóvírus vagy eszközhiba esetén elkülönülten is elérhetők maradnak-e. A georedundáns, felhőalapú megoldások sok esetben jobb védelmet adhatnak, de a választás itt is az adatmennyiségtől, a költségkerettől és a helyreállítási elvárásoktól függ.
Ugyanilyen fontos a jogosultságok kezelése. Egy távozó munkatárs hozzáférése, egy közösen használt jelszó vagy egy régen nem frissített adminisztrátori fiók komoly biztonsági kockázat lehet. A folyamatos üzemeltetés része, hogy ezek ne csak egy incidens után kerüljenek napirendre.
Amit az ügyfél is megtehet a gyors megoldásért
A szolgáltatási szint kétoldalú együttműködés. A hibabejelentés akkor kezelhető a leggyorsabban, ha az érintett munkatárs röviden leírja, mi nem működik, mikor kezdődött a jelenség, hány embert érint, és történt-e előtte változtatás. Egy képernyőkép vagy pontos hibaüzenet gyakran perceket takarít meg.
Érdemes kijelölni egy vagy több kapcsolattartót is, akik jogosultak sürgős döntéseket meghozni. Például akkor, ha egy szerver újraindítása, egy hozzáférés ideiglenes tiltása vagy egy helyszíni beavatkozás szükséges. Így nem áll meg a hibaelhárítás a jóváhagyásra várva.
Kinek éri meg a szerződéses üzemeltetés?
Különösen azoknak a KKV-knak, amelyeknek nincs saját informatikusuk, de már nem fér bele, hogy egy rendszerhiba órákig bizonytalanságot okozzon. Ilyen lehet egy könyvelőiroda, kereskedelmi vállalkozás, ügyvédi iroda, szolgáltató cég vagy több telephelyes vállalkozás is. A megfelelő konstrukció nem feltétlenül a legnagyobb csomag: a cél az, hogy a reakcióidő, a felügyelet mélysége és a havi költség arányban legyen a valós kockázatokkal.
A Precíz rendszergazda szerződéses KKV-üzemeltetésnél a gyors elérhetőség, a rendszeres felügyelet és az érthető kommunikáció ugyanúgy része a szolgáltatásnak, mint a technikai beavatkozás. Az ügyfélnek nem kell rendszergazdai nyelven megfogalmaznia a hibát: elég elmondania, mi akadályozza a munkát.
Ha a vállalkozásában egy leállás már nem egyszerű bosszúság, hanem bevételkiesés, ügyfélpanasz vagy határidőcsúszás, érdemes még nyugodt időszakban tisztázni az elvárt szolgáltatási szintet. Egy jól felépített SLA nem azt ígéri, hogy soha nem lesz hiba, hanem azt, hogy hiba esetén lesz felelős szakember, kiszámítható folyamat és gyorsan megkezdett segítség.