Аралас ортада неге жылдам түсініспеушілік туындайды

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

Осыдан түсініспеушіліктің негізгі себебі шығады. Мердігерлер әдетте тек өз учаскесіне жауап береді: біреу серверлерді жүргізеді, екіншісі — жұмыс орындарын, үшіншісі — ОЖ, төртіншісі — СУБД, бесінші — интеграцияларды. Формальды жағынан аймақтар анық. Практикада инцидент бірден бірнеше деңгей арқылы өтеді, сол кезде «кім өтініш қабылдайды», «кім көрші компоненттерді тексеруі тиіс» және «кім жұмысты нәтижеге дейін жеткізеді» деген дау басталады.

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

Түнгі уақытта, демалыс күндері және мерекелерде бұл әсіресе қымбатқа түседі. Күні бойы шекара туралы дау қоңырау немесе хабарлама арқылы тез шешіледі. 24/7 режимінде әр қосымша өтініштің берілуі бірнеше минут пен сағатты қосады. Ал бұл офис, касса жүйесі, есеп жүйелері мен филиалдармен алмасудың тоқтау қаупі.

Көбінесе түсініспеушілік төрт жерде туындайды:

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

Сондықтан аралас инфрақұрылымға арналған 24/7 қолдау келісімін жеке қызметтердің жиынтығы ретінде құруға болмайды. Жобаға серверлер, жұмыс орындары, ОЖ, СУБД және интеграциялар кірсе, құжат сервисті түгелімен қарауы тиіс. Бұл ірі ұйымдар үшін, онда техника, жүйелік бөлік және қолдау түрлі командалар арасында бөлінген кезде, әсіресе маңызды. Тіпті инфрақұрылым жергілікті өндірілген серверлер мен жұмыс станциялары негізінде құрылған болса да, даулы аймақтар өздері жоғалмайды. Оларды жою үшін нақты шекаралар, бірыңғай эскалация ережелері және түсінікті инцидент иесі қажет.

Қолдаудың периметріне не қосу керек

Қолдаудың периметрі түсінікке орын қалдырмастай сипатталуы керек. "ИТ инфрақұрылымын қолдау" сияқты жалпылама фраза көбіне пайдалы емес. Келісімде дәл не қамтылатынын бірден тізіп өткен дұрыс.

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

Бағдарламалық жасақтаманың нұсқаларын бөлек жазып қою керек. Құжатта ОЖ, СУБД және қолданбалы жүйелердің редакциялары мен нұсқалары көрсетілмеген болса, кейін «біз осы нұсқаны қолдамаймыз» деген дау туындауы оңай. Бұл Windows пен Linux аралас ортасында, дерекқорлар әртүрлі жаңартылған жағдайда және қолданба нақты кітапханалар мен драйверлерге тәуелді болған кезде өте маңызды.

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

алмасу қызметтері мен хабар кезектері;
API, коннекторлар және шлюздер;
кестелік файл алмасулары;
пошта, пайдаланушылар каталогы және сыртқы сервистермен интеграциялар;
регламенттік тапсырмалар, скрипттер және фондық процестер.

Тағы бір маңызды блок — орта(лар). Тек production ғана ма, әлде тестілік, резервтік және авариялық орталар да қолдауға кіреді ме — бұлты айқындау керек. Олай болмаса, мердігер формальды түрде тест стендінде мәселені қараудан бас тартуы мүмкін, тіпті дәл сол жерде ақау анықталған болса да.

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

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

Жауапкершілік аймақтарын қалай бөлу керек

Ол алдын ала жасалмаса, кез келген ауыр ақау тез дауға айналады. Сервер қолжетімді, бірақ дерекқор жауап бермейді. Дерекқор іске қосылған, бірақ алмасу жүрмейді. Жұмыс орны қосылады, алайда пайдаланушы жүйеге кіре алмайды. Мұндай жобада шекараларды қабаттар бойынша бөлген дұрыс: жабдық, ОЖ, СУБД, қосымшалар және интеграциялар.

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

Шекара қай жерде өтеді

Жабдық бойынша әдетте серверлер, жұмыс станциялары, дискілер, жад, желілік карталар және аппараттық ақауды базалық диагностикалау жауапкершілігі жатады. ОЖ бойынша — жүктеу, есептік жазбалар, қызметтер, жаңартулар және қате журналдары. СУБД бойынша — инстанстың қолжетімділігі, резервтік көшіру, қалпына келтіру және базалық жұмыс параметрлері. Қосымшалар мен интеграциялар бойынша — бизнес-логика, кезектер, коннекторлар, API және деректер алмасудың дұрыстығы.

Мердігердің зонасы қайда аяқталып, тапсырыс берушінің зонасы қайда басталатынын бөлек жазып қою керек. Тапсырыс берушінің жағында әдетте қолжетімділіктер, өзгерістерді келісу, жұмыс терезелерін растау, актуалды контактілер тізімі және өзіңнің вендорларыңдағы сыртқы өзгерістер туралы хабарландыру қалатын болады. Олай болмаса, тіпті мықты қолдау да жылдам әрекет ете алмайды. Мысалы, мердігер дерекқорға қатынас құқығының қателігін көрсе де, есептік жазбаларды өзгертуге рұқсаты жоқ болуы мүмкін. Формальды түрде кешігу оның тарапында емес.

Кім вендорлармен және сыртқы мердігерлермен сөйлесетінін алдын ала шешіңіз. Егер Microsoft, Oracle, SAP немесе басқа өндірушілердің шешімдері қолданылса, кім хат ашады, кім лог жинайды, кім хат алмасуын жүргізеді және түзетуге қатысты соңғы шешімді кім қабылдайтыны келісімшартта нақты көрсетілуі тиіс.

Рөлдерді қарапайым кестеге жинау ыңғайлы:

Тарап	Не үшін жауапты	Қай жерінде жауапты емес
Жабдық бойынша мердігер	Аппараттық компоненттерді диагностикалау және ауыстыру, сервер немесе жұмыс орнын базалық тексеру	Қосымшалар қателері, бизнес-логиканы баптау
ОЖ және СУБД бойынша мердігер	ОЖ қолжетімділігі, қызметтер, жаңартулар, резервтік көшіру, қалпына келтіру, СУБД инстансының жұмысы	Қолданба коды, бизнес-процесс деңгейіндегі алмасу қателері
Қосымшалар және интеграциялар бойынша мердігер	Жүйенің жұмысы, коннекторлар, API, алмасулар және кезектер	Аппараттық ақаулар және түйіндерді физикалық ауыстыру
Тапсырыс беруші	Қолжетімділіктер, өзгерістерді келісу, контакт тұлғалар, қауіпсіздік ережелері	Техникалық қалпына келтіру, егер ол қолдауға тапсырылған болса
Вендор немесе сыртқы мердігер	Өз өніміндегі түзетулер, лицензиялар, 3-ші деңгейге эскалация	Өзіне жатпайтын көрші жүйелер

Инфрақұрылымның бір бөлігін бір интегратор жеткізсе және қолдаса, оны да бөлек көрсету дұрыс. Сонда «темір» мен базалық жүйелік бөліктің арасында сұр аймақтар азаяды, эскалация жылдамырақ жүреді. Қазақстандағы компаниялар үшін бұл тәсіл жиі ыңғайлы, бір серіктес жабдық пен интеграцияны бірге жабса. Мысалы, GSE.kz техника өндірушісі және жүйелік интегратор рөлін біріктірсе, сол жобаларда жауапкершілік шекаралары бір контурда анықталуы жеңілдейді.

Келісімді қадамдап қалай жинау керек

Жақсы қолдау келісімін сирек бос қағаздан жазады. Алдымен фактілер жиналады: компанияда не жұмыс істейді, оны кім пайдаланатыны, қандай сервистер тоқтап қалмауы керек және әр қабатқа кім жауапты. Әйтпесе мықты мердігер де жауапкершілік аймағын анықтауға уақыт жоғалтады.

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

Системалар картасын жасаңыз. Серверлер, жұмыс станциялары, виртуалдық машиналар, ОЖ, СУБД, пошта, бизнес-қосымшалар және алмасулардың біртұтас тізімі қажет. Қасында тапсырыс беруші мен орындаушының иесін көрсетіңіз.
Маңыздысын және екіншісін бөліп алыңыз. Барлық сервистер түнде бірдей маңызды емес. Есептеу базасы мен төлем интеграциясы бірден жауап қажет етсе, офис ПК-дегі драйвер жаңартуын таңертеңге қалдыруға болады.
Қабаттар бойынша типтік ақауларды сипаттаңыз. Серверлер үшін — диск қателігі немесе қызу; жұмыс орындары үшін — кіру мәселелері, желі немесе басып шығару проблемалары; ОЖ үшін — іліну және жаңарту қателері; СУБД үшін — қызметтердің тоқтауы, блокировкалар, орын жетпеуі; интеграциялар үшін — алмасудың тоқтауы немесе кезектің бүлінуі.
Байланыс тәртібін бекітіңіз. Құжатта шұғыл және әдеттегі өтініштер үшін анық каналдар, жауапты тұлғалар, резевртік контактілер және эскалация деңгейлері болуы керек.
Өлшенетін ережелерді қосымшаларға шығарыңыз. Келісімшартты ықшам қалдыру үшін SLA, приоритет матрицасы, қолдауды көрсетілген жүйелер тізімі және жұмыс терезелері бөлек қосымшаларда болғаны дұрыс. Оларды бүкіл мәтінді қайта жазбай жаңарту оңай.

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

SLA шарттарында не көрсету керек

Аралас ортаға SLA жасаудағы негізгі қате — бір ортақ уақытты "барлық жағдайға" қою. Серверлерге, жұмыс орындарына, ОЖ-ға, СУБД-ға және интеграцияларға бұл көп жағдайда дау тудырады. Орындаушы уақытында жауап бердім деп есептейді, ал тапсырыс беруші сервистің толық қалпына келтірілуін күтеді. Сондықтан жауап беру уақыты мен қалпына келтіру уақытын бірден бөліңіз.

Жауап беру уақыты — өтініш жұмысқа алынған уақыт пен іс-қимылдар басталған уақытты көрсетуі керек. Қалпына келтіру уақыты — сервис келісілген көлемде қайта жұмыс істей бастаған уақыт. Критикалық жүйелер үшін бұл екеуі бөлек көрсетілуі тиіс.

Әртүрлі инцидент түрлері үшін әр түрлі мерзімдер

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

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

Әр категорияға өз жауап беру және қалпына келтіру мерзімдері қажет. СУБД-ның түнгіде тоқтауы мен таңертең принтер орнату сұранысын бір норма бойынша қарау мүмкін емес.

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

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

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

Тәжірибеден мысал: офис, серверлер, дерекқор және алмасулар

Дүйсенбі күні 9:10-да кейбір қызметкерлер жұмыс орындарын қосады, бірақ жүйеге кіре алмайды. Біреуінде авторизация терезесі ілініп қалады, біреуінде қосымша ашылады, бірақ деректер шықпайды. Басшы үшін жағдай айқын: жұмыс тоқтады, ал себеп белгісіз.

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

Керісінше де болады. Кіру өтеді, бірақ құжаттар өткізіліп жатпайды, деректер тартылмайды, ал жүйелер арасындағы алмасу тоқтап қалды. Онда қате СУБД-де, интеграция қызметінде немесе алмасу кезегінде ізделуі тиіс.

Сол себепті келісім тек «ИТ инфрақұрылымын қолдау» деген сөзбен шектелмеуі керек. Жобаға серверлер, жұмыс орындары, ОЖ, дерекқор және алмасулар кірсе, бірінші қоңыраудан бастап диагностика маршруты анық болуы тиіс.

Жұмыс схемасы әдетте былай көрінеді:

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

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

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

Формулировкалардағы жиі кездесетін қателіктер

Ең жиі кездесетін қате — мердігер "барлық ИТ инфрақұрылымды қолдайды" деп жазып, оның нақты не қамтитынын аша салмау. Аралас ортада бұл қауіпті формулировка. Серверлер, жұмыс орындары, ОЖ, СУБД, резервтік көшіру, интеграциялар, желілік жабдық және қолданбалы сервистер әр тарап өзіне қарайша түсінеді.

Келесі проблема — SLA шарттарыда шарттар, шегерімдер және паузалар болмауы. Егер құжатта тек "реакция 15 минут, шешім 4 сағат" ғана жазылса, бірақ уақыттың тоқтатылатыны туралы, мысалы, қолжетім болмағанда немесе тапсырыс берушінің келісімін күту кезінде көрсетілмесе, мұндай SLA-ны әділ орындау мүмкін емес.

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

Көбіне қолжетімділік тәртібі ұмытылып кетеді. 24/7 қолдау үшін «қолжетім берілген» деген жалпылама уәде жеткіліксіз. Құжатта нақты көрсету керек:

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

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

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

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

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

Бес нәрсені тексеріңіз:

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

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

Ірі ұйымдарда, серверлер, жұмыс орындары және интеграциялық компоненттер әртүрлі компаниялармен жеткізілген жағдайда, бұл қадам өте маңызды. Ол қолдаудың нақты аймағын алдын ала келісіп, қызмет басталғанға дейін дауларды азайтады.

Келесі қадамдар

Егер сіз 24/7 қолдау келісімін дайындап жатсаңыз, шаблоннан бастаңыз демеңіз. Алдымен нақты қандай нәрсені қолдау қажет екенін толық жинаңыз. Практикада қақтығыс көбінесе бағада емес, кейбір жүйелер периметрге кірмей қалған кезде туындайды.

Барлық қолдау объектілерінің тізімін бір реестрге түйіндеп алыңыз: серверлер, жұмыс орындары, ОЖ, СУБД, резервтік көшіру, интеграциялар, желілік түйіндер және критикалық сервистер. Әр тармақ үшін иесін, орнату орнын, маңыздылық деңгейін және басқа компоненттерге тәуелділігін көрсетіңіз.

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

Практикалық іс-қимыл тәртібі:

жабдық, ПО және интеграциялардың біртұтас реестрін жинаңыз;
критикалық түйіндерді белгілеңіз — тоқтау бизнеске дереу әсер ететіндер;
бірінші желіні, диагностиканы, түзетуді және эскалацияны кім жауапты екенін анықтаңыз;
SLA, регламенттер және рөлдер бойынша қосымшалар бар келісімнің жобасын сұраңыз.

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

Жобаны қарапайым сценарий бойынша тексеріп шығыңыз: дерекқор қолжетімсіз, пайдаланушылар жүйеге кіре алмайды, себебі әзірге белгісіз. Түнде кім өтініш қабылдайды? Кімді серверді тексеруге шақырады? Кімді ОЖ-ны қарауға қосады? Кім СУБД-ге қосылады? Егер осы сұрақтарға бір минут ішінде жауап бере алмасаңыз, құжат әлі дайын емес.

Қазақстандағы компаниялар үшін кейде бір серіктесті таңдау ыңғайлы, ол тек қолдауды ғана емес, инфрақұрылымдық негізді де жабады. Мысалы, GSE.kz Қазақстанда компьютерлер, серверлер, жұмыс станциялары және моноблоктар шығарады және жүйелік интегратор ретінде де жұмыс істейді. Аралас ортадағы жобаларда бұл жабдықты жеткізу, базалық жүйелік бөлік және қолдауды үйлестіру арасындағы үзілістерді азайтуға көмектеседі.

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