Kokio SLA reikia jūsų įmonei
SLA (angl. Service Level Agreement, liet. paslaugų lygio susitarimas) — tai IT priežiūros sutarties dalis, kurioje aiškiai apibrėžiama, kokios kokybės paslaugą įmonė gaus: per kiek laiko tiekėjas sureaguos į gedimą, per kiek į kreipinį, per kiek išspręs, kokiomis valandomis teikiama pagalba, kokie duomenų kopijų darymo bei atstatymo įsipareigojimai (RTO – angl. Recovery Time Objective, RPO – angl. Recovery Point Objective), kaip skirstomi incidentų prioritetai ir kaip visa tai matuojama. Tinkamas SLA jūsų įmonei yra tas, kuris atitinka realią jūsų veiklos prastovų kainą: biurui dažniausiai pakanka standartinio darbo valandų aptarnavimo, o gamybai, e-prekybai ar kritines paslaugas teikiančioms organizacijoms reikia platesnių prieinamumo langų ir griežtesnio reagavimo į aukščiausio prioriteto incidentus.
Dažna klaida — rinktis SLA „iš akies”: arba maksimalų lygį „dėl ramybės”, už kurį mokama be realaus poreikio, arba minimalų, kuris sutaupo sutarties eilutėje, bet brangiai kainuoja pirmos rimtos veiklos prastovos metu, ar dar blogiau – duomenų praradimo atveju. Šiame vadove paaiškiname, iš kokių parametrų susideda SLA, kaip juos susieti su savo veiklos pobūdžiu ir ko klausti tiekėjo prieš pasirašant sutartį.
Kas yra SLA paprastais žodžiais
SLA yra pamatuojamas kokybės pažadas. Vietoje bendro teiginio „operatyviai reaguojame į gedimus” susitarime įrašoma, per kiek laiko tiekėjas privalo pradėti spręsti konkretaus prioriteto incidentą, kokiomis valandomis veikia pagalbos tarnyba ir kaip vykdymas įrodomas ataskaitose. Be SLA IT priežiūros sutartis lieka deklaratyvi — nėra objektyvaus kriterijaus, pagal kurį galėtumėte vertinti, ar gaunate tai, už ką mokate. Išsamiau apie tai, kas apskritai turi būti sutartyje, rašome puslapyje kas turi įeiti į IT priežiūros sutartį.
Svarbu suprasti: SLA nėra „kuo aukštesnis, tuo geresnis”. Tai balansas tarp rizikos ir kaštų, kurį kiekviena įmonė nustato pagal savo veiklą.
Pagrindiniai SLA parametrai
Reakcijos laikas
Reakcijos laikas — tai laikotarpis nuo incidento užregistravimo iki momento, kai specialistas realiai pradeda jį spręsti. Tai ne automatinis laiškas „jūsų užklausa gauta”, o faktinis darbo pradžios momentas. Sutartyje verta aiškiai apibrėžti, nuo kada skaičiuojamas laikas ir kas laikoma reagavimu.
Sprendimo laikas
Sprendimo laikas nurodo, per kiek laiko incidentas turi būti išspręstas arba pritaikytas laikinas apėjimo sprendimas, leidžiantis dirbti toliau. Dalis tiekėjų įsipareigoja tik dėl reakcijos, bet ne dėl sprendimo — tai svarbu išsiaiškinti iš anksto, nes verslui prastovos kainą lemia būtent sprendimo, o ne reakcijos greitis.
Paslaugų teikimo langai: 9×5, 12×5, 24×7 ar kitokie
- 9×5 — pagalba darbo valandomis darbo dienomis. Tinka įmonėms, kurių veikla vyksta įprastu biuro grafiku ir sustoja pasibaigus darbo dienai.
- 12×5 — prailgintos darbo valandos darbo dienomis. Aktualu, kai dalis komandos dirba anksti ryte ar vakarais, yra pamaininis darbas arba klientai aptarnaujami ilgesnėmis valandomis.
- 24×7 — pagalba visą parą, įskaitant savaitgalius ir šventes. Reikalinga, kai sistemų prastova bet kuriuo paros metu tiesiogiai stabdo pajamas ar kritinę veiklą.
Paslaugų teikimolangas gali būti skirtingas skirtingoms sistemoms: pavyzdžiui, darbo vietų aptarnavimas 9×5, o kritinių serverių stebėjimas — 24×7. Toks derinys dažnai racionalesnis nei vienodas lygis viskam.
Prioritetų kategorijos P1–P4
Incidentai skirstomi į prioritetus pagal poveikį veiklai. Žemiau — tipinė schema su pavyzdiniais intervalais (tai iliustracija, kaip prioritetai veikia, o ne konkretaus tiekėjo įsipareigojimai — realūs laikai visada fiksuojami individualioje sutartyje):
| Prioritetas ir incidento tipas | Pavyzdys | Kokio reagavimo tikėtis |
|---|---|---|
| P1 — kritinis: stovi visa įmonė arba kritinė sistema | Neveikia serveris, el. paštas visiems, sustojo e-parduotuvė ar gamybos apskaitos sistema | Reagavimas nedelsiant, pavyzdžiui, skaičiuojamas minutėmis ar valandomis; darbas be pertraukų iki veiklos atkūrimo |
| P2 — aukštas: sutrikusi svarbi funkcija, yra apėjimas | Neveikia vienas padalinys, lėtai veikia verslo valdymo sistema | Reagavimas tą pačią darbo dieną, pavyzdžiui, per kelias valandas |
| P3 — vidutinis: nepatogumas vienam ar keliems vartotojams | Vieno darbuotojo kompiuterio ar spausdintuvo gedimas | Reagavimas, pavyzdžiui, per vieną darbo dieną |
| P4 — žemas: planiniai darbai ir užklausos | Naujos darbo vietos paruošimas, programos įdiegimas, konsultacija | Atliekama suplanuotai, pavyzdžiui, per kelias darbo dienas suderintu laiku |
Kaip parinkti SLA pagal veiklos pobūdį
Universalaus atsakymo nėra — SLA lygį lemia klausimas „kiek mums kainuoja valanda prastovos?”. Principai pagal veiklos tipą:
- Biuras (paslaugos, administravimas, projektinis darbas). Prastova nemaloni, bet retai katastrofiška — darbuotojai gali laikinai persiorientuoti. Dažniausiai pakanka 9×5 lango su griežtu P1 reagavimu darbo valandomis. Investuoti verta ne į parą veikiančią liniją, o į prevenciją ir sklandų darbo vietų aptarnavimą.
- Gamyba. Jei gamybos linijos ar sandėlio sistemos veikia pamainomis, prieinamumo langas turi dengti visas pamainas — 12×5 ar platesnis. Kritinis parametras — sprendimo laikas P1 incidentams, nes stovinti linija generuoja tiesioginius nuostolius.
- E-prekyba. Parduotuvė uždirba ir naktį, ir savaitgalį, todėl kritinėms sistemoms paprastai reikalingas 24×7 stebėjimas su automatiniais įspėjimais — kad apie sutrikimą tiekėjas sužinotų anksčiau nei klientai. Darbo vietoms tuo pačiu metu gali pakakti 9×5.
- Kritinės paslaugos (finansai, sveikata, infrastruktūra, viešasis sektorius). Čia SLA dažnai diktuoja ne tik verslo logika, bet ir reguliaciniai reikalavimai — įskaitant NIS2 reikalavimus. Reikalingas 24×7 lygis kritinėms sistemoms, apibrėžtos eskalavimo procedūros ir dokumentuota atitiktis.
Geros praktikos požymis — kai tiekėjas pats padeda suskirstyti jūsų sistemas pagal kritiškumą ir siūlo skirtingus lygius skirtingoms grupėms, o ne vieną tarifą viskam.
Ko klausti tiekėjo apie SLA matavimą ir ataskaitas
SLA vertingas tik tiek, kiek jį galima patikrinti. Prieš pasirašydami sutartį užduokite šiuos klausimus:
- Kaip registruojami incidentai ir nuo kurio momento skaičiuojamas reakcijos laikas, o nuo kurio sprendimo?
- Ar gausime reguliarias ataskaitas apie kreipinių bei incidentų kiekį, prioritetus ir SLA vykdymą? Kaip dažnai?
- Ar matysime savo užklausų būseną realiu laiku — ar tik tiekėjo žodžiu?
- Kas nutinka, kai SLA nevykdomas: kokia eskalavimo tvarka, kokios numatytos pasekmės?
- Kaip prioritetas priskiriamas incidentui — pagal aiškius kriterijus ar tiekėjo nuožiūra?
- Ar sistemų stebėjimas automatizuotas, ar incidentai fiksuojami tik vartotojams paskambinus?
Brandūs tiekėjai IT ūkį valdo pagal ITSM ir ITIL praktikas, o sistemų stebėjimą automatizuoja — tada didelė dalis incidentų pastebima ir sprendžiama dar prieš vartotojams juos pajuntant. Daugiau kriterijų vertinant tiekėją rasite gide kaip pasirinkti IT priežiūros įmonę.
Per aukštas SLA — bereikalingi kaštai, per žemas — rizika
SLA lygis tiesiogiai veikia paslaugos kainą: platesnis prieinamumo langas ir griežtesni terminai reiškia daugiau budinčių specialistų ir brangesnę infrastruktūrą tiekėjo pusėje. Užsisakę 24×7 visoms sistemoms, kai realiai dirbate 9×5, mokėsite už pajėgumą, kurio niekada nepanaudosite. Atvirkščiai — sutaupę ties minimaliu SLA, pirmos rimtos prastovos metu galite prarasti daugiau, nei „sutaupėte“ per metus. Kaip SLA lygis įsilieja į bendrą paslaugos kainodarą, aprašome puslapyje kiek kainuoja IT priežiūra įmonei.
Racionalus kelias — periodiškai peržiūrėti SLA, o startui skirtingoms IT paslaugoms parenkant skirtingus SLA pagal įtakojamos veiklos kritiškumą: verslui augant, pridėjus e-kanalus ar pamainas, poreikiai keičiasi, ir susitarimas turi keistis kartu.
Kodėl Altic IT
SLA klausimais patariame ne teoriškai — kasdien pagal paslaugų lygio susitarimus aptarnaujame didelį ir įvairų klientų ratą, todėl gerai žinome, kokie lygiai realiai pasiteisina skirtingo pobūdžio veiklose.
- 180+ aptarnaujamų klientų, ~3 500 prižiūrimų kompiuterių ir mobilių įrenginių, ~350 serverių;
- ISO 20000 (IT paslaugų valdymo) ir ISO 27001 (informacijos saugos) sertifikatai — paslaugų lygis valdomas pagal tarptautinius standartus;
- IT ūkio valdymas pagal ITSM, ITIL ir COBIT gerąsias praktikas;
- automatizuotas nuolatinis sistemų stebėjimas ir reguliarios ataskaitos klientams — SLA vykdymas matomas, ne deklaruojamas;
- per pirmus 3 mėnesius incidentų kiekis klientams sumažinamas iki 5 kartų;
- profesinės atsakomybės ir kibernetinių rizikų draudimas — 2 mln. EUR;
- neterminuotos sutartys — būname kartu, kol patinka;
- didžioji dauguma klientų atėjo pagal rekomendacijas; tarp klientų — Lietuvos bankas, „Bitė Lietuva”, „CityBee”, Vilniaus miesto savivaldybė.
Dažniausiai užduodami klausimai
-
Kuo skiriasi reakcijos laikas nuo sprendimo laiko?
Reakcijos laikas — kada specialistas pradeda spręsti incidentą, sprendimo laikas — kada problema pašalinama arba pritaikomas apėjimas. Verslui svarbesnis sprendimo laikas, nes būtent jis lemia prastovos trukmę. Vertinant tiekėją klauskite abiejų parametrų.
-
Ar mažai įmonei apskritai reikia SLA?
Taip — SLA reikalingas ne dėl įmonės dydžio, o dėl aiškumo. Net kelių darbuotojų įmonei susitarimas apibrėžia, ko tikėtis sugedus sistemoms, ir leidžia objektyviai vertinti tiekėjo darbą. Mažai įmonei tiesiog tinka paprastesnis, siauresnis lygis.
-
Ar galima skirtingoms sistemoms taikyti skirtingą SLA?
Taip, ir tai dažnai racionaliausias sprendimas. Kritiniams serveriams ar e-parduotuvei galima numatyti platesnį prieinamumo langą ir griežtesnius terminus, o darbo vietų aptarnavimui — standartinį darbo valandų lygį. Taip mokate už aukštą lygį tik ten, kur jis tikrai reikalingas.
-
Kaip patikrinti, ar tiekėjas laikosi SLA?
Reikalaukite reguliarių ataskaitų apie incidentus, jų prioritetus ir terminų laikymąsi bei galimybės matyti užklausų būseną. Patikimas požymis — automatizuotas sistemų stebėjimas ir įrankiais grįsta incidentų registracija, o ne rankiniu būdu pildomi žurnalai.
-
Ar SLA lygį galima keisti sutarties galiojimo metu?
Gerose sutartyse — taip. Verslo poreikiai keičiasi: atsiranda pamainos, nauji pardavimo kanalai, griežtesni reguliaciniai reikalavimai. Verta pasirinkti tiekėją, kuris SLA peržiūri periodiškai ir siūlo korekcijas pats, o ne laukia sutarties pabaigos.
Pasitarti dėl tinkamo SLA lygio
Nesate tikri, kokio paslaugų lygio realiai reikia jūsų veiklai? Aptarkime: įvertinsime jūsų sistemų kritiškumą, darbo grafiką ir prastovų kainą, ir pasiūlysime racionalų SLA modelį — be permokų už nereikalingą pajėgumą ir be spragų ten, kur rizika didžiausia. Susisiekite per kontaktų puslapį arba telefonu +370 5 2032018 — daugiau apie mūsų paslaugas rasite IT priežiūros puslapyje.