SLA sutartis: kas tai ir ką tikrinti IT priežiūroje

SLA sutartis: kas tai ir ką tikrinti IT priežiūroje

esolutions redakcijaRedakcija
Komentarai (0)
Turinys

SLA (angl. Service Level Agreement) – paslaugų lygio susitarimas: sutarties dalis, kurioje skaičiais įrašyta, kiek laiko paslauga turi veikti, per kiek laiko tiekėjas sureaguos ir išspręs gedimą ir kas nutinka, jei pažadas netesėtas. IT priežiūroje būtent SLA atskiria „prižiūrime jūsų svetainę“ nuo įsipareigojimo, kurį galima patikrinti ir už kurio nevykdymą tiekėjas atsako.

Santrumpa SLA kartais reiškia ir stereolitografinį 3D spausdinimą, bet čia kalbame apie sutartis. Žemiau rasite, ką reiškia 99,9 % prieinamumas minutėmis, kuo skiriasi reakcijos ir sprendimo laikas, kaip sudaryti prioritetus P1–P4, kiek iš tikrųjų kompensuoja Google Cloud, AWS ir Cloudflare, kaip įrašyti atsargines kopijas (RPO ir RTO) ir ką privaloma turėti svetainės ar el. parduotuvės priežiūros sutartyje.

Trumpai

  • 99,9 % prieinamumas leidžia iki 43 minučių prastovos per 30 dienų mėnesį, 99 % – net 7 valandas 12 minučių.
  • Reakcijos laikas nėra sprendimo laikas: sutartyje turi būti abu, atskirai kiekvienam prioritetui.
  • Didžiųjų debesų kompensacijos – 10–30 % mėnesio mokesčio už tą paslaugą ir tik pateikus prašymą laiku; jos nepadengia prarastų pardavimų.
  • Svarbiausia SLA dalis el. parduotuvei – patikrintas atkūrimas: kiek duomenų galite prarasti (RPO) ir per kiek laiko sistema vėl veiks (RTO).

Kas yra SLA sutartis IT priežiūroje

SLA gali būti atskiras dokumentas arba pagrindinės paslaugų sutarties priedas. Svarbu ne pavadinimas, o tai, ar jame yra išmatuojami rodikliai. Gera SLA sutartis atsako į šiuos klausimus:

  • Kas prižiūrima: konkretūs domenai, serveriai, programos, el. paštas, kompiuteriai – sąrašu, ne „IT infrastruktūra“.
  • Kada: darbo valandos (pvz., I–V 8–17 val.) ar visą parą, ir kaip skaičiuojamos šventinės dienos.
  • Kaip matuojama: prieinamumas procentais, kas laikoma prastova, kieno stebėsenos įrankiu ji fiksuojama.
  • Kaip greitai: reakcijos ir sprendimo laikas pagal prioritetą.
  • Kas, jei ne: kompensacijos, jų skaičiavimo formulė, prašymo pateikimo terminas, teisė nutraukti sutartį.
  • Kaip atkuriama: atsarginės kopijos, jų dažnis, saugojimo vieta ir atkūrimo laikas.
  • Kas atsakingas už saugumą: atnaujinimai, pažeidžiamumų taisymas, pranešimas apie incidentus.

Svetainės priežiūra, el. parduotuvės priežiūra ir IT ūkio priežiūra biure skiriasi objektais, bet SLA principai visur tie patys. Toliau – kiekvienas rodiklis su skaičiais.

Prieinamumas: ką reiškia 99,9 % minutėmis

Prieinamumas – dalis laiko, kai paslauga veikia. Procentai atrodo panašiai, bet skirtumas tarp 99 % ir 99,9 % – dešimt kartų ilgesnė leistina prastova. Lentelėje – leistina prastova 30 dienų mėnesiui (43 200 minučių) ir 365 dienų metams.

PrieinamumasLeistina prastova per mėnesįLeistina prastova per metus
99 %432 min. (7 val. 12 min.)87,6 val. (3 d. 15 val. 36 min.)
99,5 %216 min. (3 val. 36 min.)43,8 val.
99,9 %43,2 min.8 val. 46 min.
99,95 %21,6 min.4 val. 23 min.
99,99 %4,3 min.52,6 min.
SLA prieinamumo lygiai ir leistina prastova minutėmis per mėnesį
Leistina prastova per 30 dienų mėnesį. Skaičiavimas: 43 200 min. × (100 % − prieinamumas).

Pats procentas dar nieko nesako, kol neaišku, kaip jis skaičiuojamas. Patikrinkite tris dalykus:

  1. Ar planiniai darbai išskiriami. Jei tiekėjas iš anksto praneša apie atnaujinimą ir jo neįskaičiuoja į prastovą, 99,9 % gali reikšti kelias valandas tamsos per mėnesį. Įrašykite planinių darbų limitą ir laiką (pvz., ne daugiau 2 val. per mėn., tik 0–6 val. naktį).
  2. Kas laikoma prastova. Ar tik visiškai neatsidaranti svetainė, ar ir neveikiantis krepšelis, mokėjimai ar 10 sekundžių kraunantis puslapis? El. parduotuvei verta įrašyti, kad prastova – tai ir neveikiantis užsakymo pateikimas.
  3. Kieno matavimas galioja. Geriausia – nepriklausoma išorinė stebėsena, tikrinanti svetainę kas 1–5 minutes iš kelių vietų, su istorija, kurią matote ir jūs.

Kai svetainė staiga neatsidaro, pirmiausia verta patikrinti, ar problema ne pas didelį tiekėją: ar veikia Cloudflare, ChatGPT ir kitos paslaugos šiandien.

Reakcijos laikas ir sprendimo laikas: prioritetai P1–P4

Reakcijos laikas – nuo jūsų pranešimo iki momento, kai specialistas patvirtina, kad pradėjo darbą (ne automatinis „gavome jūsų laišką“). Sprendimo laikas – iki paslaugos atkūrimo. Dažnai naudojama ir tarpinė riba – laikinas sprendimas (pvz., grąžinta ankstesnė versija), po kurio galutinis taisymas atliekamas ramiau.

Vienas bendras „reaguojame per 4 valandas“ visiems atvejams yra ženklas, kad tiekėjas nesiskiria kritinio gedimo nuo prašymo pakeisti banerį. Sutartyje turi būti prioritetų lentelė su pavyzdžiais. Žemiau – mūsų siūlomi orientyrai el. parduotuvei; tai ne standartas, juos derinkite pagal savo apyvartą ir biudžetą.

PrioritetasPavyzdysReakcijaLaikinas sprendimas
P1 – kritinissvetainė neveikia, nepriimami mokėjimai, įtariamas įsilaužimas ar duomenų nutekėjimasiki 30–60 min., visą parąiki 4 val.
P2 – aukštasneveikia viena pagrindinė funkcija: kurjerio integracija, paieška, registracija; dalis klientų negali užsakytiiki 2 val. darbo laikuiki 1 darbo dienos
P3 – vidutinisklaida, kurią galima apeiti; lėtas puslapis; neveikiantis filtrasiki 1 darbo dienosiki 5 darbo dienų
P4 – žemasturinio pakeitimai, kosmetinės klaidos, naujų funkcijų prašymaiiki 2 darbo dienųpagal suderintą planą

Svarbu, kas nustato prioritetą. Geriausia, kai jį pagal sutarties apibrėžimus nurodo klientas, o tiekėjas gali pakeisti tik su paaiškinimu. Kitaip kiekvienas P1 tyliai tampa P3. Taip pat įrašykite, kaip pranešama apie P1 ne darbo metu: telefonas, el. paštas ar užklausų sistema, ir nuo kurio momento skaičiuojamas laikas.

Incidento laiko juosta: RPO, reakcijos laikas, sprendimo laikas ir RTO
RPO matuojamas atgal nuo gedimo (kiek duomenų prarasta), reakcijos laikas ir RTO – pirmyn (kiek laiko neveikia).

Kompensacijos: kiek realiai grąžina didieji tiekėjai

Kompensacija (angl. service credit) – tai nuolaida kitai sąskaitai, kai tiekėjas nepasiekia pažadėto lygio. Viešos didžiųjų tiekėjų SLA sąlygos – geras orientyras, ko tikėtis ir iš mažesnio tiekėjo.

Tiekėjas ir paslaugaPažadasKompensacijaKaip gauti
Google Cloud Compute Engine, keliose zonose (Premium)≥ 99,99 % per mėn.99–99,99 %: 10 %; 95–99 %: 25 %; < 95 %: 100 % tos paslaugos mėnesio sąskaitoskreiptis per 60 d. su žurnalais, rodančiais prastovą
AWS EC2, regiono lygiu≥ 99,99 % per mėn.99–99,99 %: 10 %; 95–99 %: 30 %; < 95 %: 100 %kreiptis iki antrojo atsiskaitymo ciklo po incidento pabaigos
AWS EC2, vienas serveris≥ 99,5 %99–99,5 %: 10 %; 95–99 %: 30 %; < 95 %: 100 %kaip aukščiau
Cloudflare Business100 %prastovos minutės × paveiktų lankytojų dalis ÷ mėnesio minutės; per 12 mėn. ne daugiau nei 1 mėnesio mokestispranešti per 5 darbo dienas, prašymą pateikti iki kito mėnesio pabaigos

Pasiskaičiuokime. Tarkime, serveriui mokate 200 € per mėnesį. Jei AWS regionas mėnesį veikė 99,0 % (7 val. 12 min. prastovos), kompensacija – 10 %, t. y. 20 €. Cloudflare atveju valandos prastova, paveikusi visus lankytojus 30 dienų mėnesį, duoda 60 ÷ 43 200 ≈ 0,14 % mėnesio mokesčio. Tuo metu parduotuvė, kurios apyvarta 15 000 € per mėnesį, per 7 valandas vidutiniškai praranda apie 150 € pardavimų, o piko valandomis – daugiau.

Be to, Google Cloud SLA tiesiai rašo, kad kompensacija yra vienintelė kliento teisių gynimo priemonė, jei paslaugos lygis nepasiektas. Todėl kompensacijos yra signalas tiekėjui, o ne draudimas jums. Iš mažesnio tiekėjo verta reikalauti ne didelių procentų, o teisės nutraukti sutartį be baudų, jei SLA pažeidžiamas, pavyzdžiui, du mėnesius iš eilės.

Dėmesio

Visi trys didieji tiekėjai kompensaciją skiria tik pateikus prašymą per nustatytą terminą ir su įrodymais. Jei priežiūros tiekėjas talpina jūsų svetainę debesyje, įrašykite į sutartį, kad prašymus debesų tiekėjui teikia jis ir gautą sumą perduoda jums.

Atsarginės kopijos: RPO ir RTO sutartyje

Daugelis sutarčių sako „daromos atsarginės kopijos“, bet nesako, kiek duomenų galite prarasti ir per kiek laiko viskas bus atkurta. Tam yra du rodikliai, kuriuos NIST apibrėžia taip:

  • RPO (atkūrimo taško tikslas) – laiko taškas, iki kurio duomenys turi būti atkurti po gedimo. Jei kopija daroma kas parą, RPO – iki 24 valandų: prarasite visus tos dienos užsakymus.
  • RTO (atkūrimo laiko tikslas) – kiek laiko sistema gali būti atkuriama, kol tai ima kenkti veiklai; paprastai – kiek valandų galite gyventi be svetainės ar sistemos.

Asmens duomenų atveju tai ne tik verslo, bet ir teisės klausimas. Bendrasis duomenų apsaugos reglamentas reikalauja, kad duomenų valdytojas ir tvarkytojas įgyvendintų priemones, įskaitant:

„gebėjimą laiku atkurti sąlygas ir galimybes naudotis asmens duomenimis fizinio ar techninio incidento atveju“

– BDAR 32 straipsnio 1 dalies c punktas, EUR-Lex

Orientyrai pagal sistemos tipą (mūsų rekomendacija, ne teisės aktų reikalavimas):

SistemaRPORTOKopijų dažnis ir saugojimas
Pristatomoji svetainėiki 24 val.iki 1 darbo dienoskas parą, saugoti 30 d.
El. parduotuvėiki 1 val.iki 4 val.duomenų bazė kas valandą, failai kas parą, saugoti 30–90 d.
Rezervacijų sistema, ERPiki 15 min.iki 2–4 val.nuolatinis duomenų bazės žurnalas ir kasdienė pilna kopija

Į sutartį įrašykite ne tik dažnį, bet ir tai, kad bent viena kopija saugoma kitame duomenų centre ar pas kitą tiekėją, kad kopijos šifruojamos ir kad atkūrimas bandomas reguliariai, pavyzdžiui, kartą per ketvirtį, su ataskaita jums. Neišbandyta kopija – tik prielaida, kad ji veiks.

Patarimas

Paprašykite tiekėjo per pirmą sutarties mėnesį atkurti jūsų svetainę iš kopijos į atskirą bandomąjį adresą ir pamatuoti laiką. Taip sužinosite tikrąjį RTO, o ne pažadėtą.

Saugumo atnaujinimai ir incidentai

Kiekvienas komponentas su viešai žinomu ir neužtaisytu pažeidžiamumu – atviros durys, nes jo aprašymą mato ir užpuolikai. Priežiūros sutartyje turi būti aišku, kas, kada ir kaip atnaujina:

  • Serverio programinė įranga. Pvz., PHP 8.1 jau nebepalaikoma, PHP 8.2 saugumo pataisos baigiasi 2026 m. gruodžio 31 d., 8.3 – 2027 m. gruodžio 31 d. Įrašykite, kad versijos keičiamos prieš palaikymo pabaigą ir ar šis darbas įeina į mėnesio mokestį.
  • Turinio valdymo sistema ir papildiniai. Kritinės saugumo pataisos – per sutartą laiką (pvz., 48–72 val.), kitos – suplanuotu langu, išbandžius bandomojoje aplinkoje.
  • SSL sertifikatai ir domenai. Kas atsako už automatinį pratęsimą ir kam priklauso domeno registracija. Domenas turi būti registruotas jūsų įmonės vardu, ne tiekėjo.
  • Prieigos. Dviejų veiksnių autentifikacija administratoriams, asmeninės paskyros vietoj bendrų slaptažodžių, prieigų peržiūra išeinant darbuotojui.

Jei tiekėjas mato jūsų klientų duomenis, jis yra duomenų tvarkytojas, ir BDAR 28 straipsnis reikalauja rašytinės sutarties su privalomomis sąlygomis. Įvykus asmens duomenų saugumo pažeidimui, duomenų valdytojas apie jį priežiūros institucijai turi pranešti ne vėliau kaip per 72 valandas, o tvarkytojas valdytoją informuoja nepagrįstai nedelsdamas. Todėl SLA turi nurodyti konkretų terminą, per kurį tiekėjas jums praneša apie incidentą, pavyzdžiui, 24 valandos.

Domeno galiojimo pabaiga – viena dažniausių ir labiausiai apmaudžių prastovų priežasčių. Palyginti registratorių kainas ir pratęsimo sąlygas galite domenų kainų įrankyje.

Ką privaloma įrašyti svetainės ar el. parduotuvės priežiūros sutartyje

Kontrolinis sąrašas, kurį galite naudoti peržiūrėdami tiekėjo sutarties projektą:

  1. Prižiūrimų objektų sąrašas: domenai, serveriai, programos, integracijos (mokėjimai, kurjeriai, apskaita).
  2. Prieinamumo tikslas, prastovos apibrėžimas, matavimo įrankis ir planinių darbų langas.
  3. Prioritetų lentelė su pavyzdžiais, reakcijos ir sprendimo laikais, darbo valandomis ir P1 kontaktu ne darbo metu.
  4. Atsarginių kopijų dažnis, saugojimo vieta ir trukmė, RPO, RTO ir atkūrimo bandymų dažnis.
  5. Saugumo atnaujinimų terminai, versijų keitimo tvarka, pranešimo apie incidentą terminas.
  6. Kas įeina į mėnesio mokestį ir kas apmokama atskirai: valandų paketas, jo likučio perkėlimas, įkainis virš paketo.
  7. Ataskaitos: kas mėnesį prieinamumas, incidentai, atlikti atnaujinimai, sunaudotos valandos.
  8. Prieigos ir nuosavybė: domenas, talpinimo paskyra, kodas ir duomenys priklauso jums; slaptažodžiai perduodami saugiai.
  9. Išėjimo planas: per kiek dienų ir kokiu formatu tiekėjas perduoda kodą, duomenų bazę, kopijas ir dokumentaciją nutraukus sutartį.
  10. Duomenų tvarkymo sutartis pagal BDAR 28 straipsnį.

Kaip tokią priežiūrą organizuojame mes ir ką ji apima, aprašyta priežiūros paslaugos puslapyje.

IT ūkio priežiūra biure: ką dar įtraukti

Jei sutartis apima ne tik svetainę, bet ir įmonės IT ūkį, sąrašą papildykite: kompiuterių ir telefonų inventorius, el. pašto ir biuro paketų paskyros, darbuotojų įvedimas ir išvedimas (per kiek laiko išjungiamos prieigos), tinklo įranga, spausdintuvai, licencijų apskaita ir antivirusinė apsauga. Kiekvienam objektui – ar priežiūra nuotolinė, ar su atvykimu, ir per kiek laiko atvykstama P1 atveju.

Raudonos vėliavos ir dažniausios klaidos

  • „Reaguojame kuo greičiau“ be skaičių – nėra ko išmatuoti ir nėra dėl ko reikalauti.
  • Tik reakcijos laikas, be sprendimo laiko. Tiekėjas gali per 15 minučių atsakyti „žiūrime“ ir taisyti dvi dienas.
  • Prieinamumą matuoja tik pats tiekėjas, o jūs ataskaitų nematote.
  • Kopijos saugomos tame pačiame serveryje ar pas tą patį tiekėją be atskiros vietos – sugedus serveriui, dingsta ir kopijos.
  • Domenas ar talpinimo paskyra registruoti tiekėjo vardu. Keičiant tiekėją, tai tampa derybų įrankiu prieš jus.
  • Nėra išėjimo plano. Nutraukus sutartį kodą ir duomenis tenka „išprašyti“.
  • Neribotas planinių darbų laikas, kuris neįskaičiuojamas į prastovą.
  • Kompensacijų nėra arba jos simbolinės ir nėra teisės nutraukti sutartį dėl pakartotinių pažeidimų.

Ką klausti tiekėjo prieš pasirašant

  • Kokie buvo jūsų prieinamumo ir reakcijos rodikliai per paskutinius 6–12 mėnesių kitiems klientams?
  • Kada paskutinį kartą atkūrėte kliento sistemą iš kopijos ir kiek tai užtruko?
  • Kas konkrečiai budi naktį ir savaitgaliais, ir kaip juos pasiekti?
  • Kokie trečiųjų šalių tiekėjai (talpinimas, debesis, CDN) naudojami ir kokie jų SLA?
  • Ką darote, kai svetainę reikia perkelti į naują platformą? Pavyzdžiui, jei šiandien naudojate WordPress su dešimtimis papildinių, verta įvertinti ir migraciją iš WordPress, kuri sumažina atnaujinimų kiekį.

Panašūs klausimai tinka ir verslo sistemoms: jei renkatės ERP ar individualų sprendimą, priežiūros kaina sudaro didelę dalį penkerių metų sąnaudų, kaip parodėme ERP sistemos kainos skaičiavime.

Dažni klausimai

Ką reiškia SLA?

SLA – angl. Service Level Agreement, paslaugų lygio susitarimas. Tai sutarties dalis, kurioje skaičiais nurodyta, kiek paslauga turi veikti, per kiek laiko sprendžiami gedimai ir kokios pasekmės tiekėjui, jei pažadai netesėti.

Kiek minučių per mėnesį leidžia 99,9 % SLA?

Per 30 dienų mėnesį – 43,2 minutės, per metus – apie 8 valandas 46 minutes. 99,99 % leidžia vos 4,3 minutės per mėnesį.

Kuo skiriasi reakcijos laikas nuo sprendimo laiko?

Reakcijos laikas – kol specialistas pradeda dirbti su jūsų problema, sprendimo laikas – kol paslauga vėl veikia. Sutartyje turi būti abu, atskirai kiekvienam prioritetui.

Kas yra RPO ir RTO paprastai?

RPO – kiek duomenų galite prarasti: jei kopija kas valandą, prarasite iki valandos užsakymų. RTO – kiek laiko sistema gali neveikti, kol bus atkurta iš kopijos.

Ar mažai įmonei reikia SLA sutarties svetainės priežiūrai?

Taip, jei svetainė priima užsakymus, rezervacijas ar užklausas. Užtenka trumpo priedo su prioritetais, kopijų dažniu, atnaujinimų tvarka ir išėjimo planu – tai apsaugo nuo didžiausių nuostolių keičiant tiekėją ar įvykus gedimui.

Ar priežiūros tiekėjas atsako už prastovą, kurią sukėlė talpinimo ar debesų tiekėjas?

Priklauso nuo sutarties. Dažniausiai trečiųjų šalių gedimai išimami iš SLA, todėl reikalaukite, kad tiekėjas nurodytų, kokius tiekėjus naudoja, ir perduotų jums jų kompensacijas.

Šaltiniai

  1. Compute Engine Service Level Agreement – Google Cloud, 2025
  2. Amazon Compute Service Level Agreement – Amazon Web Services, 2022
  3. Business Service Level Agreement – Cloudflare, 2026
  4. Recovery Point Objective – NIST CSRC žodynas, NIST SP 800-34 Rev. 1
  5. Recovery Time Objective – NIST CSRC žodynas, NIST SP 800-34 Rev. 1
  6. Reglamentas (ES) 2016/679 (BDAR), 28, 32 ir 33 straipsniai – EUR-Lex, 2016
  7. Supported Versions – PHP Group, 2026
Komentarai (0)
Apie autorių
esolutions redakcija
Redakcija
10 straipsnių →

Komentarų (0)

Komentarų dar nėra. Būk pirmas!

Komentuoti gali tik prisijungę vartotojai. Registruokis — ir galėsi pasidalinti savo mintimis apie šį straipsnį.

Registruotis
Savaitės suvestinė

DI kainos, Google atnaujinimai ir prekybos sezonai

Kartą per savaitę: kas pasikeitė DI, paieškoje ir el. prekyboje. Be triukšmo.

SLA sutartis: kas tai ir ką tikrinti IT priežiūroje – esolutions