Техқолдауға арналған SLA: метрикалар, инциденттер және бақылау

Неліктен SLA қажет және одан тыс не бұзылады

Техқолдауға арналған SLA қолдау «қоңырауға көмектесу» болған сәттен бизнес күнделікті жұмысының бір бөлігіне айналғанда қажет. Ол қандай қызмет қолдауға алынатынын, қандай мерзімде және қандай жауапкершілікпен орындалатынын анықтайды.

SLA болмаған кезде әдетте бірдей дау-жанжалдар туындайды. Инцидент қашан басталады: қолданушы мәселені байқаған кезде ме, өтініш жасалғанда ма, әлде инженер көргенде ме? Ал инцидент қашан жабылған болып есептеледі: «қайта жұмыс істейді дегенде» ме, қолданушы растағанда ма, әлде себеп жойылып, есеп дайын болғанда ма? Егер бұл жазылмаса, әр тарап өз түсінігі бойынша есептейді. Статистика басқару емес, дау тудырады.

Ауызша уәделер өтініштер аз болғанда және барлығы бір-бірін танығанда жұмыс істейді. Содан кейін жүктеме өседі: қолданушылар, сервистер, мердігерлер көбейеді. «Біз әдетте жылдам жауап береміз» деген тіркес көмектеспейді. Приоритеттер секіріп, маңызды сұраныстар жоғалады, команда жалығады.

Бизнес үшін тәуекелдер айқын және өлшенеді: негізгі жүйелердің тоқтауы, мерзімдердің бұзылуы, келісімшарттық айыппұлдар, табыс пен беделдің жоғалуы. Пациент жазбасы сервисі немесе төлем шлюзі істен шықса, маңыздысы тек «жауап беру» емес, көрсетілген мерзімде жұмысты қалпына келтіру. Әйтпесе басшылыққа бір сағаттық тоқтау неге күнге созылғанын түсіндіру қиын болады.

SLA бірнеше тарапқа бірден пайдалы. IT ресурстарды жоспарлау мен приоритеттеуді алады. Сатып алулар ұсыныстарды салыстырып, келісімді бақылауды жеңілдетеді. Қауіпсіздік осалдықтарды қаншалықты тез жоятындығын және эскалация қалай жүретінін біледі. Басшылық тәуекелдерді сандар арқылы көре алады.

Тіпті егер қолдауды интегратор немесе жабдық өндіруші көрсетсе (мысалы, серверлер мен жұмыс орындары үшін 24/7 сервис), SLA күту мен жауапкершілікті айқын етіп, екі тарапты да «біз ойладық/деп ойладық» деген жағдайдан қорғайды.

Барлығы бірдей түсінуі үшін терминдер

Техқолдау SLA жиі «нашар қолдау» емес, бірдей сөздерді әртүрлі түсінуден сәтсіз болады. Сондықтан метрикалар мен жауапкершілікке өтпес бұрын терминдерде келісу маңызды.

Инцидент пен қызмет көрсету сұранысы шынайы өмірде әр түрлі. Инцидент — бірдеңе бұзылған немесе қалыптан тыс жұмыс істеп, бизнесті тежейтін жағдай (есеп жүйесі ашылмайды, желі құлаған, құжаттарды басатын принтер істемейді). Қызмет көрсету сұранысы — «жасау» немесе «өзгерту» қажеттілігі (кіру беру, ПО орнату, қолданушы қосу, жұмыс орнын дайындау). Олар араласып кетсе, әдемі есептер шығады, бірақ адамдар көңілі қалатын болады: қарапайым сұраныстар статистиканы жақсартады, ал нақты ақаулар батып қалады.

Уақыт туралы дау болдырмау үшін қарапайым анықтамаларды қолданыңыз:

• Время реакции: өтініш тіркелген сәттен бастап қолдаудың алғашқы мазмұнды жауабына дейін (растама, нақтылау сұрақтары, жауапты тағайындау).
• Время восстановления: сервис жұмыс күйіне қайтарылғанға дейін, тіпті уақытша шешім болса да (келісілген обход есепке алынады).
• Время решения: себеп толығымен жойылған сәтке дейін (жабдықты ауыстыру, баг түзету, конфигурация өзгерту).

Қолдаудың жұмыс сағаттарын да ашық көрсету қажет: 8x5, 12x6, 24x7. Бұл тек «қашан қоңырау шалуға болатынын» ғана емес, метрикалардың қалай есептелетінін де өзгертеді. Мысалы, SLA 8x5 болса, 19:30-дағы инцидент тіркеуі келесі жұмыс күні таңертең ғана есептелуі мүмкін.

Басталу нүктелері мен паузаларды бөлек бекітіңіз: тикет қашан жасалды, қашан расталды, қашан жұмысқа алынған. Қолданыстағы тәжірибе — бастаманы растау уақыты бойынша есептеу (деректері жоқ өтініштерді алып тастау үшін) және клиенттің жауабын күту таймерді тоқтатады деп жазу. Мысал: қолданушы «почта жұмыс істемейді» деп жазды, қолдау скрин және деректер сұрады, жауап 3 сағаттан кейін келді. Егер алдын ала ереже бекітілсе, сол 3 сағат қолдаудың кешігуі ретінде есептелмейді.

Инциденттерді жіктеу және басымдықтар

SLA-да инциденттерді жіктеу критикалық емес пен маңыздыны бірдей түсіну үшін керек. Әйтпесе приоритеттер тез «бәрі шұғылға» айналып, жауап беру мен қалпына келтіру мерзімдері мағынасыз болады.

Приоритетті әсері мен шұғылдығы бойынша белгілеу ыңғайлы, эмоциялар арқылы емес. Әсерді масштаб бойынша сипаттауға болады (бір қызметкер, бөлім/филиал, бүкіл ұйым) және маңызды сервис зардап шеккенін көрсетуге (мысалы, ERP, пошта, серверге кіру, кассалар).

Басымдық шкаласының мысалы

Қолайлы P1–P4 нұсқасы, оны түсіндіру және бақылау оңай:

• P1 (критикалық): негізгі сервис немесе инфрақұрылым тоқтаған, ұйымның үлкен бөлігі зардап шегеді, айналып өтудің жолы жоқ.
• P2 (жоғары): бөлім жұмысына қатты кедергі, уақытша айналып өту бар, бірақ шығындар байқалады.
• P3 (орташа): бір қолданушы немесе шағын топта мәселе, айналып өту бар, жұмыс әдетте жалғасады.
• P4 (төмен): консультация, баптау, бизнеске әсер етпейтін кішкентай қате, жоспарлауға болады.

Шұғылдығын әсерінен шатастырмау

Шұғылдық — «қандай жеделдікпен керек», әсер — «қаншаға және кімге кедергі келтіріп тұр». Қолданушы «қазір дәл қазір» деп сұрауы мүмкін, бірақ егер бір принтер жұмыс істемей, басқа принтер болса, бұл P1 емес. Приоритеттердің «жоғарылауын» болдырмау үшін ереже бекітіңіз: приоритет критерийлер бойынша тағайындалады, лауазымға немесе дауысқа емес.

Екі жиі сценарийді бөлек сипаттаңыз. Біріншісі — қайталанып болатын сәтсіздіктер: бір мәселе тұрақты түрде қайталанса, себепті жоюға бөлек тапсырма ашып, оны бір реттік инциденттерден бөлек қадағалаңыз. Екінші — жаппай инцидент: көптеген бірдей өтініштер бір мастер-инцидентке біріктіріледі, осылай команда қайталануды шешпейді және есептер нақты масштаб пен қалпына келтіру уақытын көрсетеді.

SLA-ға енгізілетін метрикалар: қажет минимум

SLA тек метрикалар түсінікті және деректерге тексерілетін кезде жұмыс істейді. Практикада қысқа көрсеткіштер жиынтығын алып, есептеу ережелерін сипаттап, инциденттер мен сұраныстарды араластырмау керек.

Көбіне жеткілікті минимум:

• жауап беру уақыты (өтініш расталып, бірінші байланыс болғанға дейін)
• сервис қалпына келтіру уақыты (келісілген workaround-ты қоса алғанда)
• сервистің қолжетімділігі белгілі кезеңде (ай немесе тоқсан)
• SLA сақталу пайызы (мерзімде орындалған өтініштердің үлесі)
• backlog пен сұраныстарды өңдеу мерзімдері (егер SLA тек инциденттерге ғана емес, запростарға да қатысса)

Жауап беруді екіге бөлу пайдалы: өтініш жұмыста қабылданған сәт (номер, жауапты адам, статус) және қолданушымен алғашқы байланыс болған сәт. Бұл басшылық үшін тәртіп көрсеткіші, ал қолданушылар үшін олардың жалғыз қалмағаны туралы сезім.

Қалпына келтіру уақыты критикалық сервис үшін басты көрсеткіш. Алдын ала не қалпына келтіру болып саналатынын жазу маңызды: жұмысқа қайтару, тіпті уақытша шешім болса да. Толық шешімге бөлек мерзім қоюға болады, бірақ оны қалпына келтірумен араластырудың қажеті жоқ — команда «идеалды шешімді» күтіп, тоқтауды ұзартуы мүмкін.

Қолжетімділікті өлшеу кезеңге байлаңыз (көбінесе ай) және есептеуден не шығып қалатынын көрсетіңіз: жоспарлы жұмыстар, келіскен техникалық терезелер, сыртқы провайдерлер. Егер бұл жазылмаса, есептер әрқашан сандар туралы дау болады.

SLA сақталу пайызын формалды етіп қойыңыз: «мерзімде» не екенін, клиенттің жауап күтуі қалай есептен шығарылатынын, келіскен пауза қалай есепке алынады және екінші деңгейге көшу қалай есептелетінін. Оңай нұсқа: «инцидент мерзімге дейін қалпына келтірілсе орындалған болып есептеледі, ал клиенттің күту сағаттары таймерге қосылмайды».

Егер SLA сұраныстарды да қамтитын болса (кірулер, орнатулар, консультациялар), backlog пен мақсатты мерзімдерді қосыңыз. Әйтпесе инциденттер тез жабылып, «қалыпты» тапсырмалар күшімен жиналады да жұмысқа кедергі болады.

Қадамдық: SLA-ны келісімшартқа немесе қосымшаға қалай жазу

SLA ниеттерді емес, өлшенетін уәделер мен олар қай кезде орындалатынын сипаттауы керек. Оны қосымша ретінде кестелермен дайындау ыңғайлы: солай сандарды өзгерту келісімшартты қайта жазбай-ақ оңай болады.

1) Нені қолдайтынын нақтылаңыз

Қызметтер тізімі мен жауапкершілік шегін сипаттаңыз: қандай жүйелер қолдау аясында, қандай сағаттарда, өтініш қабылдау қандай арналары ресми саналады. Бұл «мессенджерге жазылды» немесе «мәселе провайдердің жағында» деген дау туғызатын жағдайларды азайтады.

2) Инциденттер жіктелімі мен мақсаттар матрицасын келісіңіз

10 деңгейге бөлмеңіз. Көбіне P1–P4 жеткілікті. Одан кейін әр приоритет үшін реакция және қалпына келтіру (RTO) мақсаттары матрицасын қосыңыз, 24/7 және жұмыс уақытына бөлек, егер режимдер әртүрлі болса.

Мысал:

• P1: реакция 15 минут, қалпына келтіру 4 сағат
• P2: реакция 1 сағат, қалпына келтіру 8 сағат
• P3: реакция 4 сағат, қалпына келтіру 3 жұмыс күні
• P4: реакция 1 жұмыс күні, орындау келісілген мерзімге сай

Міндетті түрде «реакция» не екенін (тіркеу және алғашқы байланыс) және «қалпына келтіру» не екенін (келіскен деңгейге қайтару) жазыңыз.

3) Шығыстар мен тәуелділіктерді қосыңыз

Адал SLA мақсаты қолданылатын немесе қайта қаралатын жағдайларды қамтиды: жоспарлы жұмыстар, форс-мажор, запчастьтың болмауы, сыртқы вендорға тәуелділік (мысалы, өндірушіден жауап немесе бұлт сервисіне қолжетімділік қажет болғанда). Мұндай тәуелділік тикетте қалай тіркелетіні және мерзім қалай өзгеретіні көрсетілуі керек.

4) Тапсырыс берушінің міндеттері мен коммуникация ережелерін сипаттаңыз

SLA қолдаудың қолжетімділігін тапсырыс берушінің міндеттерісіз бұзады. Минимум ретінде тапсырыс беруші міндеттері: контакт тұлғалар, қашықтан қол жеткізу тәртібі, жұмыстарға терезелер, логтар мен тоқтауды растау талаптары.

P1–P2 үшін бөлек коммуникацияларды жазып қойыңыз: кімдерді хабардар ету, статустардың қаншалықты жиі шығатыны, қашан басшылық қосылады және негізгі арналары қандай.

5) Жабу критерийлері мен нәтижені растау

«Жабылған» формальдылыққа айналмас үшін сапа критерийлерін қойыңыз: не тексерілетіні, қандай көрсеткіштер қалыпқа келуі керек, P1 үшін түпкірлі себеп туралы есеп қажет пе. Жабу ережесі: мысалы, тапсырыс беруші растама жасағаннан кейін жабылады немесе сервистер мониторинг бойынша жұмыс істеп жатқанда жауап болмаған жағдайда N сағаттан кейін автоматты түрде жабылады.

Бақылау процестері: қабылдау, эскалациялар, жауапкершілік

Жақсы жазылған SLA де әрекетсіз процесссіз жұмыс істемейді: өтініш қалай қабылданады, дау-жанжалдарды кім шешеді және инцидент бірнеше команданы қамтыса кім жауап береді.

Біріккен кіріс және өтініш қабылдау

Бір ресми кіріс орнатыңыз: портал, бір пошта немесе бір нөмір. Каналдар көп болуы мүмкін, бірақ барлығы бір кезекке түсуі керек. Әйтпесе метрикалар «шашылады» және кейбір өтініштер жоғалады.

Қабылдауда уақытты есептеу үшін ең аз деректер тіркелуі тиіс:

• тіркеу уақыты (қолдауға өтініш көрінген сәт)
• сервис/жүйе және әсер қысқаша сипаттамасы
• приоритет және негіздемесі (қанша қолданушы зардап шегеді, тоқтау бар ма)
• тапсырыс берушіден жауапты контакт
• бұл жағдай үшін не «қалпына келтіру» ретінде саналатыны (уақытша айналып өту немесе толық шешім)

Эскалациялар, сменалар және жауапкершілік

Эскалация «қорқыныш туған кезде» емес, нақты триггерлер бойынша болуға тиіс. Мысалы: дедлайнның жартысы өтті, прогресс жоқ; қолжетімділік қажет; инцидент критикалық сервиске әсер етеді. Бұл кезде үлкен инженер қатысады, ал мерзім ұзару қаупі пайда болса — менеджер шақырылады, ол приоритеттерді шешіп, қосымша ресурстар тарта алады.

Егер 24/7 қажет болса, сменалар мен дежурларды тапсыру тәртібін сипаттаңыз: кім жабылмаған инциденттерді қабылдайды, статусты қалай береді және ештеңе «стыкта» қалып қоймағанын қалай тексереді. Үлкен жеткізушілерде бұл блок бөлек регламент ретінде жазылады — мысалы, GSE.kz сияқты 24/7 желіде.

«Кім кінәлі?» деген дауды болдырмау үшін RACI-ді қарапайым түрде пайдаланыңыз: Responsible (кім істейді), Accountable (нәтижеге кім жауапты), Consulted (кімге жүгінеді), Informed (кім хабардар болады). Көп команда қатысатын инциденттерге бір координатор белгілеңіз: ол уақыт кестесін жүргізеді, шешімдерді тіркейді және статусты тұрақты жаңартып отырады.

Басшылыққа есептер: нені көрсету және қалай оқу

SLA есептері шешім қабылдау үшін ғана пайдалы. IT тобына аптасына бір рет егжей-тегжейлі шолу керек. Басшылыққа — ай сайынғы қысқа шолу, артық деректерсіз. Бір есеп бәріне жарамаса, ол тым күрделі немесе тым беті жұқа болады.

Апталық есеп IT үшін инциденттердің нақты тізіміне негізделген болуы керек: ең жиі қайталанғаны, қай жерде мерзім өтіп кеткен, неге болғаны және қандай эскалациялар жұмыс істеді. Мұнда себептер (жаңарту қателігі, рұқсат қатесі, ресурс шамадан тыс жүктелуі) және қайталануды азайтатын іс-шаралар көрсетіледі.

Айлық есеп басшылыққа жауап беруі тиіс: SLA сақтала ма және бизнестің қандай тәуекелі бар. Көбіне 5–7 көрсеткіш жеткілікті:

• SLA ішінде инциденттер үлесі (реакция және қалпына келтіру бөлек)
• критикалық инциденттер саны және олардың жиынтық тоқтауы
• қалпына келтірудің орташа және 90%-дік мәні
• мерзімнен өту: қанша және қандай себеппен (ресурс жетіспеушілігі, клиент күтуі, сыртқы мердігер)
• қайталанатын инциденттер (бір ай ішінде бірдей мәселе)

Есепті оқуды жеңілдету үшін басқаруға болатын аймақтар бойынша кескіндер жасаңыз: сервистер, бөлімдер, мәселе түрлері және уақыт бойынша. Түнгі сағаттар мен демалыс күндер жиі әлсіз жерлерді көрсетеді.

Аномалияларды қысқа карточкамен көрсетіңіз: не болды, әсері қандай (сервис, қолданушылар, ұзақтығы), неге мерзімнен асты және не істеледі келесіде (мерзім мен жауапты тұлға). Мысалы, бір сервис бойынша екі критикалық тоқтау бір себеппен болса, бұл себепті жоюға арналған жұмыс, «өртенген отты сөндіру» емес.

Жақсарту жоспарының есеппен байланысы тік болу керек: қайталанатын инцидент нақты жұмысқа ауысады (себепті жою, нұсқаулық жаңарту, мониторинг орнату) және келесі есепте қайталану мен мерзімнен асулардың азайғаны көрінеді.

Сценарий мысалы: критикалық сервистері бар ұйым үшін SLA

500 жұмыс орны бар ұйымды елестетейік: орталық кеңсе, қашықтағы филиалдар және жұмыс тоқтайтын сервис жиынтығы (пошта, ERP, желі, мемлекеттік порталдарға қол жеткізу, телефония, құжат басу). Мұндай жағдайда SLA «орташа туралы» емес, ең ауыр ақаулар үшін нақты ережелер туралы болуы тиіс.

Негізгі қадам — приоритеттер мен құқықтарды алдын ала келісу. Мысалы, P1 тек критикалық сервис үлкен топ үшін тоқтаған немесе деректер жоғалу қаупі болған кезде қойылады. Приоритеттердің «барлығы шұғыл» болмауы үшін P1 қою құқығын кезекші админге, IT сменасының басшысына және бизнес өкіліне (мысалы, операциялық бөлім бастығы) беріңіз. Барлық басқа өтініштер бастапқыда P2–P3 болып басталады және тексерістен кейін жоғарылайды.

Мақсаттарды осылайша бекітуге болады: P1 үшін реакция — 15 минут, қалпына келтіру — 2 сағат (шамамен), мерзім сызығына шығу қаупі болса міндетті эскалация. «Реакция» инженер инцидентті қабылдап, әрекет бастағанын білдірсе, жай ғана «принято» деп жазу емес екенін бөлек көрсету маңызды.

Коммуникация уайымды азайтады. P1 үшін әр 30–60 минут сайын шаблон бойынша жаңарту енгізіңіз: не бұзылды және кого бұл әсер етті, не істелді, ағымдағы болжам, бизнестан не керек (қолжетімділік, растау, жұмыс терезесі) және келесі апдейт уақыты.

P1 жабылуы процесстің иесі немесе филиалдағы кезекші растағаннан кейін болады. Содан кейін қысқа постмортем жасалады: не болды, неге болды, қайталану тәуекелін қалай төмендету және мониторинг/регламентте не өзгерту керектігі туралы бірнеше жол.

SLA бақылауда қиын болатын құралдар

SLA жұмыс істеуі үшін тек шарт жеткіліксіз. Шындықты тіркейтін құралдар керек: инцидент қашан басталған, кім қабылдады, не істелді және сервис қашан шынымен қалпына келді.

Тикет-система: статистика осында туындайды

Тикет-система дәлелдер үшін қажет. Егер өтінішті чатта қабылдап, ұмытып кетуге болса, SLA «кім және қашан жазғаны туралы» дауғ©а айналады.

Тикетті жасау мен жабу кезінде міндетті түрде тіркелетін минимум: сервис/жүйе, приоритет пен әсер, тіркеу уақыты және негізгі маркерлер (бірінші жауап, қалпына келтіру), статус (жұмыста, клиент күтуінде, эскалацияда, шешілді), жабу себебі және қысқа қорытынды.

Алдын ала келісіңіз, қай статустар «сағаттарды тоқтататынын» (мысалы, қолжетімділік немесе клиент деректерін күту) және бұл есептерде қалай көрінетінін.

Мониторинг, база знаний және инвентаризация

Авто-хабарландырулар инциденттің басталуын кешіктірместен тіркеуге көмектеседі. Критикалық сервис үшін инцидент мониторингтен автоматты түрде ашылуы керек, телефон қоңырауынан кейін ғана емес. Бұл серверлер мен жұмыс орындары инфрақұрылымында түнде немесе демалыс күндерінде болатын ақаулар үшін әсіресе маңызды.

База знаний қалпына келтіруді жылдамдатады: типтік ақаулар, тексеру қадамдары, қолданушыларға арналған шаблон хабарламалар. Қайталанатын тапсырмалар (жаңартулар, рұқсаттар, жабдық ауыстыру) үшін мақалалар шешім уақытын тұрақтандырады және «негізгі адамдарға» тәуелділікті азайтады.

Инвентаризация (сервистер каталогы және иелері) апат кезінде құтқарады: сервис кімге тиесілі, қайда орналастырылған, эскалация үшін қандай контактілер, қандай өзгеріс терезелері рұқсат етілген.

SLA есептерінің тең түсінікті болуы үшін «бір ғана шынайы дереккөз» қажет: тикет-система біркелкі есеп үшін, уақыт ережелері біреу (уақыт белдеуі, жұмыс сағаттары) және мониторинг оқиғалары мен өтініш деректері бір жерде жиналуы тиіс. Сол кезде басшылыққа пікір емес, өлшенген фактілер көрсетіледі.

Қайталанатын қателер және оларды қалай болдырмау

SLA-дағы ең зиянды мәселелер көбіне нақты емес сөздерден туындайды. Егер формулировкалар айқын болмаса, әр тарап өз түсінігі бойынша оқиды және дау туындайды.

Төмендегі типтік қателер және оларды жабу жолы:

• «оперативно» немесе «мүмкіндігінше» сияқты уәделер. Оларды нақты уақытпен ауыстырыңыз: жауап беру уақыты, қалпына келтіру уақыты, жұмыс сағаттары және ресми өтініш арнасы.
• Қалпына келтіру не екенін анық көрсетпеген. Уақытша жұмысқа қайтару (обход) пен түпкі себепті жоюды бөліңіз.
• Инциденттер мен сұраныстарды бір кестеге салып, ережесіз араластырған. Оларды бөліңіз: инцидент — бұзу, сұраныс — өзгеріс/кіру/консультация.
• Шығыстар мен тапсырыс берушінің міндеттері жазылмаған. Таймерді не тоқтататынын (қолжетімділікті күту, келісімдер) және тапсырыс берушінің не беруі керектігін (контактілер, қашықтан қолжетімділік, логтар) көрсетіңіз.
• Есептер «формальдық» болып жіберіледі. Оларды басқарушылық етіңіз: бұзулар себептері, қайталанатын инциденттер, тар жерде мәселелер және келесі айға шаралар.

Егер есепте «99% орындалды» деп тұрса, мына бір сұрақты қойыңыз: сол 1% қайсы және оны болдырмау үшін не өзгертілді?

Қысқа чек-лист және келесі қадамдар

SLA нақты жұмыс істесе, әдемі сандардан емес, анық базаға көшіңіз: не қолдауға алынғаны, оның қаншалықты маңызды екенін және келісімдер орындалатынын қалай білесіз — осыдан бастаңыз.

Кез келген пунктке «қазір жоқ» деп жауап берсеңіз, оны 2–4 аптаның жұмыс жоспарына енгізіңіз:

• Сервис каталогы бар (мысалы, пошта, ERP/1С, филиалдардың желісі, жұмыс орындары) және нені бизнес үшін критикалық екенін белгілегенсіз.
• Приоритет матрицасы анықталған: P1/P2/P3 белгілері мен әр деңгейге арналған жауап беру және қалпына келтіру уақыттары.
• Біріккен өтініш кірісі орнатылған және эскалация ережелері жазылған: қашан кезекші, смена басшысы, вендор тартылады.
• Есеп форматы келісілген: қандай метрикалар көрсетіледі, қанша жиі және әр көрсеткіштің тапсырыс беруші мен орындаушы жағынан иесі кім.
• Пилот жоспарланған: 1–2 маңызды сервис таңдалып, SLA оларда 4–6 апта ішінде тестіленеді, кейін мақсаттар нақты деректер бойынша түзетіледі.

Практикалық келесі қадам — шешімдерді 1–2 беттік құжатқа жазып, осы ережелер бойынша жұмыс істейтіндермен қысқа кездесу өткізу: қолдау қызметі, IT-басшы және сервис иелері.

Егер процестерге, дежурлыққа немесе инфрақұрылымға (мониторинг, өтініштер есебі, запчасти) ресурстар жетпесе, 24/7 қолдауда тәжірибесі бар интеграторды қосуға болады. Қазақстанда мұндай тапсырмаларды жиі GSE.kz деңгейіндегі командалар шешеді: жүйелік интеграция, қолдау және жабдық жеткізу бірге болғанда, критикалық сервистерді тезірек қалпына келтіру және SLA бақылауын жеңілдету оңайырақ болады.