Таңдаудың мәні

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

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

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

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

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

IT-қызмет үшін маңызды бірнеше қарапайым сұрақ бар:

Инцидентті бірінші қабылдайтын кім және ол кез келген уақытта ма?
Себеп анық емес болғанда координацияны кім жасайды?
Логтарды кім жинайды, барлық тараптармен кім сөйлеседі және эскалацияны кім жүргізеді?
Мәселені толықтай, тек өз бөлігін емес, кім жабады?
Жылдам әрі түсінікті жауапты қаншалықты тез алуға болады, хат алмасудан гөрі?

Сондықтан схема таңдау — тек сервер немесе лицензияны сатып алу емес. Бұл жұмыс ыңғайлылығы, IT-инциденттердің эскалациясы жылдамдығы және IT-қызметтің мердігерлер арасында диспетчерге айналатын жағдайларының саны туралы. Салыстырмалы жүйелер үшін бұл жиі басты критерий.

Бір келісім-шарттың артықшылығы

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

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

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

Қай жерде уақыт үнемделеді

Бір келісім-шарт ең көп көмектесетін нүктелер:

бастапқы диагностикада
қолдау сызықтары арасында инцидентті беру кезінде
техникалық қызметке шығу, ауыстыру немесе жаңарту туралы келісуде
мерзімдер мен статустарды бақылауда
қайталанатын ақауларды талдауда

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

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

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

Мысалы, компания сервер, жүйелік ПО және қолдауды бір интегратордан сатып алса, жылдам шешімге қол жеткізу оңайырақ. Мұндай тәсілді сервер инфрақұрылымы және бүкіл ел бойынша сервис желісі бар жобаларда жиі таңдайды.

Қашан бірнеше мердігер ақталады

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

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

Қашан лоттар бойынша бөлу тиімді

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

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

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

Көп мердігерлі схема даулы IT-инциденттерді азайту үшін компания ішінде әдетте алдын ала орнатылады:

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

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

IT-қызмет үшін көрінісі

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

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

Көп мердігерлі схема кезінде бір ақау жиі 2–4 өтінішке айналады. Серверге бөлек, жүйелік ПО-ға бөлек, кейде интеграторға немесе жергілікті сервистік компанияға бөлек жазылады. Әрқайсысына бірдей бастапқы деректер керек: қате уақыты, симптомдар, скриншоттар, логтар, сериялық нөмірлер, ақау алдындағы өзгерістер.

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

Нагрузка көбейетін жерлер:

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

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

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

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

Инцидентті эскалациялау қадамдары

Сервер жауап бермегенде IT-қызметке жалпылама жоспар емес, нақты әрекеттер тізбегі керек. Өтінішті қабылдап, бастапқы тексеруді бір жауапты тағайындаған сайын ішкі даулар азаяды.

Эскалация қалай жүреді

Кәдімгі жұмыс схемасы мынадай:

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

Алғашқы қадамда көбіне уақыт көп жоғалады. Өтініште сервер атауы, қате скриншоты немесе соңғы өзгерістер көрсетілмесе, эскалация дереу тежеледі.

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

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

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

IT-қолдау келісім-шартына тек жауап беру уақытын ғана емес, эскалация тәртібін де қосқан жөн. Қиын инциденттер үшін әдетте белгіленеді:

бірінші линияда жауап беру уақыты
аға инженердің қосылу мерзімі
жауапкершілік аймағын растау уақыты
уақытша шешім ұсыну мерзімі
сервис қалпына келу мақсатты уақыты

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

Қайталанатын қателіктер мен даулы инциденттер

Компания «бір келісім-шарт па, әлде бірнеше мердігер ме» деп шешкенде ең ауыр проблемалар көбіне сатып алу кезінде емес, ақау кезінде шығады. Сервер қолжетімсіз болғанда IT-қызметтің мақсаты — формальды түрде кім жауапты екенін емес, сервисті тез қайтару.

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

Тағы бір жиі қате — әртүрлі SLA және әртүрлі жұмыс уақыты. Бір мердігер 24/7 жұмыс істейді, екіншісі тек жұмыс күндері 18:00-ге дейін. Егер ақау түнде немесе демалыс күндерінде болса, өтініш командалар арасында іліп қалады. Бизнес үшін бұл жай ғана «жүйе тұрған» көрініс. IT үшін — қолмен үйлестіру қажеттігі.

Проблема диагностиканың біртұтас тәртібі болмаған кезде күшейеді. Логтарды әртүрлі форматта жинайды, серверлер уақыты синхрондалмаған және бастапқы тексеріске қойылатын талаптар алдын ала келісілмеген. Бір мердігер ОС журналдарының шығарылуын сұраса, екіншісі BMC немесе RAID бақылағышының деректерін сұрайды, үшіншісі өз утилиттерінің нәтижелерін талап етеді. Бірлескен шаблон болмаса, IT командасы бәрін өз бетінше жинап, біріктіреді.

Міне осында IT-дегі даулы инциденттер пайда болады. "Қалай сервис қалпына келтіреміз" деген сұраққа жауап іздегенше, "мәселенің түпкі себебі қайда" туралы дау басталады. Іштегі IT-қызметтің тәжірибесі мен өкілеттігі көбіне сыртқы командаларды бірге жұмыс істеуге мәжбүрлеуге жетпейді.

Көбіне дауларға келесі келісім-шарттағы олқылықтар әкеледі:

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

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

Егер жеткізуші серверді, жүйелік ПО-ны және қолдауды өз мойнына алса, осындай сұр зоналар әдетте азаяды. Ал схема аралас болса, анық эскалация ережелері болмаса, даулы инциденттер дерлік мәжбүрлі түрде пайда болады.

Мысал: түнде сервер жауап бермей қалды

Көз алдымызға келтірейік: 02:15-те маңызды ішкі жүйе орналасқан сервер жауап бермей қалады. Таңертең 9:00-де бухгалтерия, сатып алу бөлімі немесе тіркеу қызметі оны қолданады. IT-қызметтің түнгі мақсаты — себеп туралы дау шығармай, сервис жұмысқа дайын болу.

Егер компанияда сервер, жүйелік ПО және қолдау бір келісім-шартта болса, тізбек әдетте қысқа болады. Кезекші инженер инцидентті қабылдап, бастапқы деректерді жинап, аппараттық бөлікті, жүйелік журналдарды, дисктерді, желіні және виртуализацияны тексереді. Бір орындаушы ішіндегі команда кімді қосу керектігін өзара шешеді.

Кәдімгі уақыттар мынадай көрінуі мүмкін:

02:20 — өтініш тіркеліп, жұмысқа алынған
02:40 — бастапқы диагностика орындалған
03:10 — қажетті маманға ішкі эскалация жасалған
04:00 — себеп табылған немесе уақытша шешім іске қосылған
08:00-ге дейін — сервис қалпына келген немесе жұмыс режиміне көшірілген

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

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

Уақыт жиі мына жерде жоғалады:

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

Нәтижесінде таңертеңгі 7-де IT-қызметтің қолында шешім емес, үш бөлек хат алмасу және «қосымша диагностика қажет» деген алдын ала қорытынды болуы мүмкін. Түнгі инцидент үшін бұл нашар нәтиже.

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

Таңертеңгі жұмыс терезелері маңызды компанияларда бір инциденттің бір иесі бар схема ыңғайлырақ. Сондықтан ірі интеграторлар, оның ішінде GSE.kz сияқты компаниялар, қолдауды осылай ұйымдастыруға тырысады — IT-қызметке түн ортасында үш түрлі команданы үйлестірудің қажеті жоқ.

Схеманы таңдағанда жылдам чек-лист

Схеманы таңдамас бұрын бірнеше сұраққа жауап беру пайдалы. Олар қай жерде бір мердігер IT-қызметтің жүктемесін азайтарынан, ал қай жерде бірнеше орындаушы қиындық тудырмайтынын тез көрсетеді.

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

Сізде бір сағатқа да тоқтатуға болмайтын сервистер бар ма? Егер сервер есеп жүйелеріне, кассаға, оқу процесіне, медициналық деректерге немесе филиалдардың жұмысына тәуелді болса, алдын ала аппарат, жүйелік ПО және қалпына келтірудің толық тізбегі үшін жауапты анықтаған дұрыс.
Компания ішінде мердігерлерді басқаратын адам немесе команда тағайындаңыз. Бірнеше орындаушы схемасында кім логтарды жинайтынын, өтініш ашатынын, мерзімдерді сәйкестендіретінін нақтылау керек.
Бүкіл сервис үшін бір SLA қажет пе? Егер жауап беру мен қалпына келтірудің нақты мерзімі маңызды болса, бір келісім-шарт жиі оңайырақ. Әйтпесе бір мердігер өз бөлігін жапты деп, жалпы тоқтап қалу жалғасуы мүмкін.
Географияны бағалаңыз. Бір орын мен болжамды жүктеме басқаруға жеңілірек. Егер филиалдар көп және әр түрлі қалаларда болса, выездтерді, жабдықты қамту мен біртұтас қолдауды қамтамасыз ету маңыздырақ.
Келісім-шарт жобасын ашып, даулы жағдайларды тексеріңіз. Онда кім бастапқы диагностика жүргізетіндігі, тараптар арасында инциденттер қалай берілетіні, жауапкершілік шекарасы қалай расталатыны және келесі деңгейге қандай мерзімде қосылатындығы түсінікті болуы тиіс.

Кіші IT-команда үшін бұл әсіресе маңызды. Ақау кезінде ішкі келісулер неғұрлым көп болса, мәселе почта, чат және қоңыраулар арасында қалып қою қаупі жоғары.

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

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

Қане іске кірісу

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

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

Пәтер сұрақтары:

ақау болғанда кім бірінші өтініш қабылдайды?
инцидент толық қалпына келгенге дейін эскалацияны кім жүргізеді?
сервер мен жүйелік ПО арасындағы қиылыста кім жауап береді?
критикалық жағдайлар үшін қандай реакция және қалпына келтіру мерзімдері пропискада көрсетілген?
іске қосылғаннан кейін шешімді кім сүйемелдейді?

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

Егер сізге бірыңғай шеңбер керек болса, интегратормен мұны талқылау орынды. Мысалы, GSE тексерілген жабдық өндіреді, сонымен бірге жүйелік интеграция және тәулік бойы техникалық қолдау көрсетеді. Мұндай формат IT-қызметке әр ақауда бірнеше орындаушыны үйлестіруге қарағанда ыңғайлырақ.

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