Ішкі чат-бот үшін SLA: өлшенетін көрсеткіштер мен ерекшеліктер

Ішкі чат-ботқа SLA не үшін керек және не анықтауы тиіс

Ішкі чат-ботқа арналған SLA формальдылық үшін емес, күнделікті қызметтен не күту керектігін пайдаланушыларға түсіндіру және ИТ пен қолдау үшін нақты міндеттемелерді көрсету үшін керек. SLA жоқ болғанда бот талқылаулар көзіне айналады: біреулер кез келген уақытта лезде жауап күтсе, басқалары «қалай шығса солай» деп ойлайды.

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

Көп жағдайда ішкі чат-бот қайталанатын сұрақтарға жауап береді және өтініштер қабылдайды. Бұл әдетте HR (анықтамалар, демалыс, onboarding), ИТ (парольді қалпына келтіру, рұқсаттар, ПО орнату, инцидент статусы), сервистік өтініштер (канцелярия, өту рұқсаттары, жөндеу), қаржы (растау статус, типтік сұрақтар) және оқыту (курсқа қолжетімділік, кесте, нұсқаулар бойынша жауаптар).

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

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

Қызмет шекарасы: не SLA-ға кіреді, не кірмейді

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

«Қызмет» дегенде әдетте тек бот логикасы ғана емес, пайдаланушыға дейінгі жол да қарастырылады. Бот бірнеше арнада қолжетімді болса, бұл әр түрлі сәтсіздік нүктелері және әр түрлі метрикалар. Бот өзі жұмыс істеп тұрса да, арна (Teams немесе Telegram) уақытша қолжетімсіз болуы мүмкін. Немесе AD, HR жүйесі, білім базасымен интеграция құлау ықтималдығы бар.

Практикалық рамка:

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

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

Сценарийлердің критиктігін бөлек талқылаңыз. Пароль қалпына келтіру, корпоративтік жүйелерге қолжетімділік және ИТ-өтініштер әдетте анықтамалық жауаптардан маңыздырақ. Түрлі сұраныс түрлері үшін әр түрлі реакция уақыты мақсаттарын қоюға болады.

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

Қолжетімділік: аптаймды қалай анықтау және өлшеу

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

Аптайм пайызын есептеу кезеңімен бірге көрсетіңіз. Қатты жиі — ай бойынша (есептеуге және талқылауға жеңіл), сирек — тоқсан бойынша (жекелеген оқиғаларды тегістейді, алайда үнемі қайталанатын проблемаларды жасырады). Формулировка бірмәнді болуы тиіс: «ай сайын 99,5% қолжетімділік», және тоқтап қалуды нақты анықтау (мысалы, бот хабарламаларды қабылдамайды немесе N секундтан артық жауап бермейді) көрсетілуі керек.

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

Минималды деңгейлер:

• Негізгі: бот «оболочкасы» үшін аптайм мақсаты (кіріс, хабарлама жіберу), ай сайын есептеледі.
• Жоғары: критикалық сценарийлерге бөлек қолжетімділік мақсаты (мысалы, өтініш жасау), тәуелділіктерді бөлек есептеу.

Мысал: бот ай ішінде 99,5% қолжетімді, бірақ «авариялық өтініш» функциясы үшін 99,9% пен бөлек мониторинг қойылады. Осылайша метрика нақты сапаны көрсетеді, тек чаттың ашылуын ғана емес.

Жауап уақыты және шешім уақыты: нақты қолданылатын көрсеткіштер

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

Әдетте бірнеше көрсеткіш жеткілікті, бірақ қай оқиғадан бастап қай оқиғаға дейін есептелетіні нақты жазылуы керек:

• Бірінші жауап уақыты: пайдаланушы хабарламасын жіберген сәттен боттың алғашқы мазмұндық жауабына дейін (жай «принято» емес, пайдалы реплика).
• Шешім уақыты: пайдаланушы жауап алғанға немесе әрекет орындалғанға дейін (мысалы, өтініш жасалып, нөмір берілген сәт).
• Тапсыру уақыты: бот «адам қажет/Service Desk» деген шешім қабылдағаннан бастап шын мәнінде тапсырма тапсырылғанға дейін (карточка жасалып, өрістер толтырылып, кезекке жіберілгенге дейін).
• Оператор күту уақыты: егер процеске адам қатысса, бөлек метрика.

Егер бот сұранысты операторға немесе Service Desk-ке жіберсе, «стоп-сағат» ережесін бірден анықтаңыз. Мысалы, бот жағынан шешім уақыты өтініш жасаған сәтке дейін есептелсін, әрі қарайғы уақыт Service Desk SLA-сына жатсын. Сонда бот дұрыс жіктеуге, деректерді толтыруға және жылдам тапсыруға жауапты, бірақ басқа команда кезегіне емес.

Мақсаттарды сұрау түрлеріне бөліп қою жақсы, әйтпесе бір мән тым қатал немесе мәнсіз болады:

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

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

Сұрауларға шектеулер: лимиттер, кезектер және түсінікті деградация

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

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

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

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

Басқа тарату мен автоматты сценарийлерді бөлек талқылаңыз. Егер HR 2000 қызметкерге сауалнама жіберсе немесе мониторинг хабарламалар жіберсе, бұл қызметтік арна арқылы, келісілген квоталар мен кестемен жүргізілуі керек. Әйтпесе бір пайдалы автоматтандыру барлығы үшін сервис нормасын бұзуы мүмкін.

Жаңарту терезелері: жоспарланған простоялар мен коммуникация

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

Жаңарту терезесін қалай сипаттау керек

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

Төмендегілерді белгілеңіз:

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

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

Откат және простайды тіркеу

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

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

Исключения: форс-мажор, сыртқы тәуелділіктер және қауіпсіздік

Исключения жауапкершілікті жою үшін емес, алдын ала келісілген қандай оқиғалар бұзушылық sayылмайтынын және команда осы жағдайда қалай әрекет ететінін көрсету үшін керек. Негізгі ереже: әрбір исключение өлшенетін және тексерілетін болуы тиіс, әйтпесе ол ыңғайлы отмазкаға айналады.

Сыртқы тәуелділіктер мен форс-мажор

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

Әдетте жарамды категориялар:

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

Форс-мажорды кең емес етіп сипаттаңыз: «кез келген күтпеген жағдай» емес, нақты оқиғалар мен оларды форс-мажор деп тану белгілерін жазыңыз.

Қауіпсіздік бойынша исключения

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

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

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

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

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

Қандай деректерді жинау керек

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

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

Есептер және уақыт бірізділігі

Есептер тек инженерлерге емес, бизнес иесіне де түсінікті болуы керек. Әдетте қызмет иесі мен дежур команда жеткілікті. Жариялауды былай бекітуге болады:

• күнделікті автоматты қысқа статус (негізгі метрикалар бойынша);
• апталық SLA және инциденттер тізімі бойынша есеп;
• айлық қорытынды — тенденциялар мен төмендеулер себептері.

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

Алерттар үшін шектемелер мен әрекеттерді алдын ала қойыңыз, адамдарды ұйықтатып алмау үшін:

• критикалық: бот қолжетімсіз немесе 5xx жауаптар белгіленген N минуттан жоғары - дежур келуге;
• маңызды: кідірістің немесе кезектің өсуі - тикет ашып, жүктемені тексеру;
• бақылау: бір реттік қателер — жазылып, апталық талқылауға.

Осылай бақылау процессі түсінікті болады және «міндеттемелер орындалды/орындалмады» туралы дау жоқ.

Қадам-қадам: SLA қалай құрып, бизнеспен келісу керек

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

Практикалық тәртіп

1. Нақты сценарийлерді жинаңыз: регламент іздеу, өтініш статусы, ИТ көмегі, білім базасына қолжетімділік. Оларды критиктілікке бөліңіз: критикалық (процесті тоқтатады), маңызды (сапаны төмендетеді), ыңғайлы (қосымша артықшылық).

2. Метрикалардың анықтамаларын бекітіңіз. Қолжетімділік неден есептеледі: health-check, API-ның сәтті жауабы, әлде пайдаланушының чатта жауап алу мүмкіндігі ме? Чат-боттың «жауап уақыты» деген не: бірінші хабарлама немесе толық жауап? Өлшеу бірліктерін (секунд, минут, пайыз) және өлшеу орнын жазыңыз.

3. Мақсаттарды деңгейлер бойынша келісіңіз. Критикалық сценарийлер үшін қатаң мақсаттар, ыңғайлы үшін жеңілірек. Дәлелденбейтін уәделерден гөрі шынайы мақсаттар мен деградацияны көрсету жақсы.

4. Жаңарту терезелері мен исключенияларды қосыңыз. Қашан жоспарлы жұмыстар мүмкін, қалай хабарлайсыз, не есептен шеттеледі (мысалы, сыртқы провайдердің сәтсіздігі, қауіпсіздік блоктаулары).

5. Эскалация мен есептілікті сипаттаңыз. Инцидентті кім қабылдайды, 2‑ші сынып қашан қосылады, байланыс арнасы қандай, айлық есеп форматы (аптайм, жауап уақыттарының перцентильдері, отклонен сұраулар үлесі, себептер).

Мысал: егер бот ішкі өтініштер үшін қолданылса, бизнес «24/7 қолдау тәрізді» талап етуі мүмкін. Онда SLA нақты қолдау деңгейлері мен реакция уақыттарын және неден қолжетімсіздік саналатынын жазып қою керек, дау кейінірек туындамас үшін.

SLA жазуда жиі кездесетін қателер

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

Әдеттегі қателер:

• «жауап уақыты» мен «шешім уақыты» араласады. Бот 3 секундта жауап беруі мүмкін, бірақ нақты мәселе (мысалы, жүйеге қолжетімділікті қалпына келтіру) 2 сағатты алады — не «сәтсіз» деп саналуы керек түсініксіз.
• 99,9% аптайм көрсетіп, бірақ простай не екенін айтпайды: интерфейс неде, бір сценарий ме, интеграциялар ма, әлде кідіріс пе.
• Сыртқы тәуелділіктер үшін міндеттемелер алады. Егер бот HR жүйесіне, Service Desk-ке немесе пайдаланушылар каталогына жүгіне берсе, бұл сервистердің өз кестелері мен ақаулары бар — бәріне бірдей SLA уәде етуге болмайды.
• Жүктеме кезінде мінез-құлықты жазбайды. Шың уақытында бот үнсіз қалуы, жауаптарды қайталауы немесе нәтиже бермей сұраулар қабылдауы мүмкін, содан кейін қолдауға көп жүгініс келеді.
• Исключенияларды тым кең қылып жазады. «Кез келген провайдердің мәселесі» немесе «барлық жаңартулар» сияқты тұжырымдар SLA-ны жояды.

Жақсы тест: дүйсенбі, таңғы 09:00 — қызметкерлер көптеп қатынасады делік. Егер SLA кезек кезінде не болатынын айтпаса (мысалы, күту болжамын көрсету, кей функцияларды шектеу, өтініштерді қабылдау режиміне көшіру), онда хаосқа орын қалдырып отырсыз.

SLA бекітуге дейін қысқа чек-лист

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

Тез тексерулер:

• Қызмет нақты сипатталған: қандай арналар қолдауға алынған, қызмет иесі кім, жұмыс және бейнежұмыс уақытында кімге жазу немесе қоңырау шалу керек.
• Метрикалар өлшенетін және бірліктері бар: қолжетімділік (период бойынша пайыз және простай қалай есептеледі), бірінші жауап (мысалы p95), шешім уақыты (шешім деп нені есептеу керек), сұрау лимиттері (минутына сұраулар, кезек, жүктеме кезіндегі мінез-құлық).
• Жаңарту терезелері ереже ретінде рәсімделген: жоспарлы простайлар қашан, алдын ала қалай хабарланады, не болады егер жаңарту созылса.
• Исключения ақтаулар тізіміне айналмауы тиіс: форс-мажор тар әрі тексерілетін түрде жазылсын, сыртқы тәуелділіктер (SSO, білім базасы, пошта, провайдер LLM) көрсетілсін, қауіпсіздік себептері процедурамен қамтылсын.
• Бақылау және эскалация ойластырылған: мониторинг, есеп форматы мен жиілігі, инцидентті кім қабылдайды, қашан келесі сынып қосылады, SLA орындалуын қалай тіркеу.

Осыдан кейін нақты сценарий бойынша тексеріңіз: қызметкер 09:05-те қолжетімділік үшін өтініш жібереді, 09:07-де бот жауап береді, бірақ өтініштер жүйесі қолжетімсіз. SLA осы жағдайды бұзушылық есептейтін-жоқ па, пайдаланушыға қалай хабарланады, деградация қаншаға созыла алады және қашан дежур инженер шақырылады — бәрі анық болуы керек.

Егер бір тармақ таулы дау тудырса, оны бекітуге дейін нақтылаңыз — бірінші инциденттен кейін емес.

Қарапайым кейске SLA мысалы және келесі қадамдар

2000 қызметкері бар компания ішкі чат-ботты іске қосады: ол HR сұрақтарына жауап береді (анықтамалар, демалыс, командировка) және ИТ-өтініштерді жасай алады, кейде оларды Service Desk-ке жібереді.

SLA-ны түсінікті ету үшін тапсырмаларды түрлері бойынша бөліңіз. FAQ үшін жауап жылдамдығы мен қолжетімділік маңызды, ал өтініштер үшін — қолдауға болжамды тапсыру.

Метрікалар мысалы:

• Боттың қолжетімділігі: ай сайын 99,5%, 1–5 минут сайын тест сұраулардың сәтті жауаптары бойынша өлшенеді.
• FAQ: жауап уақыты p95 бойынша 5 секундтан аспауы (медиана, мысалы, 2 секундқа дейін).
• ИТ-өтініш: өтініштің расталуы (нөмір мен статус) p95 бойынша 30 секундтан аспауы.
• Операторға тапсыру: жұмыс уақытында 09:00–18:00 аралығында оператордың бірінші реакциясы p95 бойынша 10 минуттан аспауы.
• Шектеулер: пайдаланушыға минутына 20 сұрауға дейін және компания бойынша минутына 200 сұрауға дейін; жүктеме кезінде бот кезек пен күту уақытын хабарлайды.

Жаңарту терезелерін таңдау таңертеңгі шыңға ене бермейтіндей жоспарлаңыз. Мысалы: жоспарлы жұмыстар жексенбі 02:00–04:00 аралығында, хабарлама кемінде 48 сағат бұрын. Шұғыл өзгертулерге ереже: будниде 09:00–11:00 аралығында өзгертулер жасамау, егер қауіпсіздік инциденті болмаса.

Исключения өлшенетін болуы қажет. Мысалы, Service Desk қолжетімсіздігі (API немесе өтініштер базасы), корпоративтік желінің ақауы немесе бірізді кіру қолжетімсіздігі сыртқы себеп ретінде танылады: бот FAQ-қа жауап беруді жалғастырады, бірақ өтініш жасау уақытша мүмкін емес. Қауіпсіздік тұрғысынан күмәнді сұрауларды блоктау SLA бұзушылық есептелмейді.

Келесі қадамдар қарапайым: 4–6 апталық пилот, нақты метрикаларды жинау (қолжетімділік пен аптайм, p95, кезектер, шыңдар), содан кейін сандар мен исключенияларды түзету.

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