Бюджет комиссиясына серверлерді жаңарту бойынша бизнес-кейс

Комиссия бизнес-кейсте нені көргісі келеді

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

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

Серверлік тақырыпта «әсер» әдетте үш нәрсені білдіреді:

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

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

Техникалық бөлшектерге батып кетпей, фокус негізінен цифрлар мен тексерілетін фактілерде болсын:

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

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

Құжат құрылымы: қысқа және тексерілетін

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

Бірінші бетте тек таңдау жасайтын нәрсені қалдырыңыз:

• мақсат және нақты не өзгереді (мысалы, 10 серверді жаңартамыз, 6 негізгі сервисті тасымалдаймыз)
• ағымдағы мәселе фактілермен (сағат бойынша простой, өнімділіктің құлдырауы, инциденттердің көбеюі)
• екі сценарий: минимальды (тәуекелдерді жабу) және мақсатты (әсер алу)
• қорытынды цифрлар: CAPEX, OPEX, үнем, қайтарым мерзімі
• әсер жылдар бойынша 3–5 жыл перспективасында (қысқа кесте бір-неше жол)

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

Қосымшада әдетте төрт блок жеткілікті:

• есептеулер мен логика (не есептелді, қандай формулалар, TCO-ға не кірді)
• допущениялар мен дереккөздер (тикеттер, мониторинг, жалақы ставкалары, тарифтер, SLA)
• тәуекелдер және допущениялар орындалмаса не болады (мысалы, әсер 20% төмендейді)
• сценарийлер бойынша смета және жоба шекаралары (не кіреді, не кірмейді)

Егер шешімге интегратор немесе өндіруші қатысса («ключ бойынша» жеткізу және енгізу), құрылым әлі де цифрлар мен тексерілетін бастапқы деректерге сүйенуі керек, жабдық сипаттамасына емес.

Уақытты ұзартпай бастапқы деректерді жинау

Кейс комиссиядан өтуі үшін «идеал» дәлдік емес, түсінікті дереккөздер мен қарапайым допущениялар маңызды. Көп деректі 1–2 күнде жинауға болады, егер қайдан алынатынын алдын ала келіссеңіз: мониторинг журналдары, Service Desk, ИБ және бухгалтерия есептері.

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

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

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

Ағымдағы шығындарды тексеріңіз; олар жиі түрлі есептерге шашыраған болады. Оларды бірнеше жолға жинақтау ыңғайлы:

• ішкі қолдау (админ сағаттары, кезекшілік)
• запчастьтар мен жөндеулер
• сыртқы мердігерлер мен шақырулар
• лицензиялар мен ұзартулар
• айыппұлдар немесе сбоевтан келетін шығындар (егер тіркелсе)

Бастама ретінде: Service Desk-та жылына 12 ірі инцидент және орташа MTTR 3 сағат көрінсе, бұл әсер есептеуі үшін база бола алады. Қалғанын допущения ретінде рәсімдеп, жоба кезеңінде нақтылайтыныңызды көрсетіңіз.

Простайларды азайтудан пайдасын цифрмен қалай есептеу

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

Көбінесе төрт категория жеткілікті:

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

Негізгі формула қарапайым: шығын = простой сағаттары × сервистің сағаттық құны. Мәселе көбіне формуланың өзінде емес, сағаттық құнды адал бағалауда.

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

«Баяу жұмыс» әдетте күтудің адам-сағаттарына аударылады. Мысал: 120 қызметкер күн сайын 10 минутты есеп жүйесінің тежелуіне жұмсайды. Бұл күніне 20 адам-сағат. Содан кейін оны сағаттық құнға және жұмыс күндеріне көбейтесіз.

Келіспеушіліктер болмас үшін диапазон көрсетіңіз:

• консервативті: тек авариялық простойларды және минималды сағаттық құнды аламыз
• реалистік: ішінара простойлар мен деградацияны қосамыз, сондай-ақ жоғалған қызметтерді

Комиссия бір ғана «сиқырлы» сан орнына әсер коридорын және есеп логикасын көруді жөн көреді.

Жүйелерді жылдамдатудан пайдасын күрделі математикасыз қалай бағалау

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

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

Қарапайым есеп ақшамен:

• күндегі уақыт үнемі = (алдындағы уақыт − кейінгі уақыт) × операция саны × пайдаланушылар саны
• жылдық үнем = күндік үнем × жұмыс күндері
• ақшадағы әсер = үнемделген сағаттар × орташа сағаттық құн

Мысал: есеп 6 минуттан 3 минутқа дейін жасалады. 40 қызметкер оны күніне 2 рет іске қосады. Үнем: 3 минут × 80 іске қосу = күніне 240 минут, яғни 4 сағат. Оны жұмыс күндеріне және сағаттық құнға көбейтесіз (жалақыға шегерімдер немесе ішкі ставка қолдануға болады).

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

Осылай есеп адал әрі тексерілетін болады.

Қолдау және сервисте әдетте қайда шығын жасырынады

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

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

Практикалық есептеу тәсілі — инциденттер саны және бір инцидентке кеткен еңбек шығынына сүйену. Мысалы: қазір айына 18 инцидент, орташа еңбек 2,5 сағат, екі маман қатысады (1-ші және 2-ші желі), айына бір рет выезд. Унификациядан кейін айына 10 инцидент және бір инцидентке 1,5 сағат деп болжайсыз. Сағаттар бойынша үнем бірден көрінеді.

Қорғау үшін әсерлерді бірнеше жолмен көрсету ыңғайлы:

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

Жиынтық ЗИП пен қолдау жоспарын бөлек бекітіңіз: қандай бөлшектер жерде сақталады, не кепілдік бойынша ауыстырылады, қандай реакция мерзімі қажет. Егер 24/7 қолдау мен жеткізу желісіне сеніп отырсаңыз, оны тәуекел мен апатты шақырулардың азаюы ретінде рәсімдеуге болады. Ең бастысы — допущенияларды адал көрсету: ағымдағы инцидент статистикасы, унификациядан күтілетін әсер және шектеулер (мысалы, «ағымдағы жүктеме мен пайдалану тәртібі сақталғанда").

3–5 жылға TCO: қарапайым шығын моделі

Комиссия сенуі үшін сатып алу бағасынан бөлек толық иелік құнын (TCO) 3–5 жылға көрсетіңіз. Мұндай перспектива серверді ауыстырудың типтік мерзімімен сәйкес келеді және бір реттік CAPEX-пен қатар жыл сайынғы «ағытылатын» шығындарды көруге көмектеседі.

Екі топ шығыннан бастаңыз және оларды түсінікті тілмен тізіп шығыңыз, сол кезде қаржы және ИБ бірдей түсінеді:

• CAPEX: серверлер, СХД (қажет болса), желі жабдығы, стойкалар мен ИБП, монтаж және пусконаладка
• OPEX: электр және салқындату, сервис және запчастьтар, кепілдіктерді ұзарту, лицензиялар және жазылымдар, мердігерлер немесе ішкі қолдау жұмыстары

Содан кейін «қолда бар күй» мен «модернизация» сценарийлерін салыстырыңыз. "As-is" базасы шынайы болуы тиіс — әйтпесе есепті сұрақтармен оңай бөліп тастайды.

"Қалдыру" сценарийіне әдетте: ескіре келе апатты жөндеулердің өсуі, қолдауды ұзарту құны, простой тәуекелдері және қолмен айналып өтуге кеткен уақыт кіреді. "Жаңарту" сценарийіне: оқыту, миграция, мүмкін жұмыс терезелері және тұрақты қызмет көрсету арқасында OPEX-тің төмендеуі қосылады.

Қарапайым формат: 3 жыл ала отырып, 1-ші жылы CAPEX мәнін көрсетіп, әр жылға OPEX қосып, сценарийлер арасындағы айырмашылықты шығарыңыз.

5 жұмыс күні ішінде бизнес-кейсті қалай жинауға болады

Кейсті апталық қысқа жоба ретінде жасаңыз: әр күн нақты және тексерілетін нәтиже береді.

5 күндік жоспар

• Күн 1: мәселені фактілермен бекітіңіз. Service Desk инциденттері, SLA есептері, пайдаланушылардың хаттары, простой терезелері мен қалпына келтіру мерзімдері сияқты 3–5 растаманы жинаңыз. Керек — даталар, ұзақтығы, зардап шеккен жүйелер.
• Күн 2: 2–3 жаңарту сценариін сипаттаңыз. Көбіне «тәуекелді жабатын минимум», «3 жылға арналған мақсатты» және «бюджет қысқарса кезең-кезеңімен» жеткілікті. Әр сценарийде не өзгереді: серверлер, СХД, резервтеу, қолдау.
• Күн 3: үш топ бойынша әсерлерді есептеңіз. Простайлар (жылдық сағаттар және сағат құны), жылдамдық (қанша адам қанша уақыт жоғалтады) және қолдау (ескі парктің қолдауы қанша тұрады: выездтер, запчастьтар, түнгі жұмыстар).
• Күн 4: бәрін бір кестеге біріктіріңіз. Инвестициялар, жылдық үнем, қайтарым мерзімі, допущения мен тәуекелдер. Егер вендор ұсыныстары болса, бағаға не кіретінін белгілеңіз.
• Күн 5: 5–7 слайдқа арналған қорғанысты дайындаңыз. Мәселе, нұсқалар, есептер, тәуекелдер, енгізу жоспары, комиссиядан не қажет екені.

Қысқа допущение мысалы: «ERP тоқтайды квартал сайын 6 сағат, простойда 80 қызметкер бар, сағаттық құн консервативті түрде 4 000 тг». Комиссия дәл деректерден гөрі логикасы түсінікті есепті қабылдайды.

Түсінікті допущениялары бар сценарий мысалы

Аудандық ұйым: 220 қызметкер, үш негізгі жүйе — 1C және бухгалтерия, электронды құжат айналымы, ортақ файл ресурсы. Пайдаланушылар «баяу», IT бөлімі қолмен қайта жүктеу мен қалпына келтіруге уақыт жұмсайды.

Өткен жылға арналған бастапқы деректер: 8 авариялық простой. Орташа бір простой ұзақтығы — 2,5 сағат, қалпына келтіруден кейін шамамен 1 сағат «үйкеліс» (жұмыс кезегін түзету, қайталау операциялары). Барлығы шамамен 28 сағат қолжетімсіздік. Сағаттық құнға қатысты допущение: пайдаланушылар уақыты мен IT-дың қосымша төленетін сағаттары, консервативті 150 000–250 000 тенге/сағат ("жоғалған пайда" емес, нақты төленетін уақыт пен регламент бұзылу шығындары).

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

Күтілетін әсер (консервативті): жылдық 8 простой 2-ге дейін азаяды, орташасы 1 сағат болады. Қолжетімсіздік 28-ден 2 сағатқа түседі, үнем — 26 сағат. Ақшада: жылына 3,9–6,5 млн тенге. Қосымша — қолдау өтініштерінің 20–30% азаюы, бұл IT-да 0,2–0,4 штат босату эквивалентіне тең.

Егер жалпы жаңарту бюджеті 10–18 млн тенге болса (серверлер, енгізу, көшіру, тест), қайтарым мерзімі 18–36 ай аралығында шығады. Мұндай формат комиссияға ұнайды: диапазон, допущения және тексерілетін деректер бар.

Комиссияға "сандарды көру" үшін қосыңыз:

• инциденттер экспортын даталарымен және ұзақтығымен
• "алдымен" уақытының қысқа өлшеулері (есеп ашу, құжат өткізу)
• Service Desk статистикасы санаттар бойынша
• простай сағатының құнын есептеу формуласы мен дереккөздері (ФОТ, пайдаланушылар саны)
• миграция жұмыстары жоспары және жұмыс терезелері

Қате жиі кездеседі, сондықтан кейс қабылданбайды

Комиссия көбіне керісінше есептерді қиып тастайды: цифрларға зиян келтіретін сенімсіз есептер. Тіпті жақсы жоба да сандар «шатыстырылған» немесе тексерілмейтін болса әлсіз көрінеді.

Бірінші мәселе — өте оптимистік простойдарды төмендету пайыздары. Егер "70% азаяды" десеңіз, осының қайдан шыққанын көрсетіңіз: өткен жылдағы инцидент статистикасы, мониторинг логтары, өтініштер журналы. Көз жоқ мәлімдемеге сену қиын, сондықтан консервативті сценарийлер де көрсетіңіз (мысалы, 15–25%).

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

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

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

Бесінші — «поэтапты» нұсқаның болмауы. Егер бюджет қысқарса, жоба өміршең болуы үшін алдымен ядроны, кейін қалғанын жаңарту жоспары болуы керек.

Өзіңізді мына қысқа тізім бойынша тексеріңіз:

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

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

Тәуекелдер мен допущения: адал әрі сендірерлік түрде қалай жазуға болады

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

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

Жоба тәуекелдері және оларды азайту

• Жеткізу және енгізу мерзімдері. Буферлі жоспар және кезеңді енгізу (алдымен тест контур, содан кейін өндірістік), бір бөлік кешіктірілсе барлық жобаны тұзу қамтамасыз етіледі.
• Миграция және ауысу кезінде простой. Бір сервис бойынша пилот, ауысудың репетициясы, откат жоспары.
• Үйлесімділік пен өнімділік. Негізгі жүйелерді тесттік серверде тексеру, қабылдау/қабылдамау критерийлері (жауап уақыты, CPU жүктемесі, IOPS).
• Қолда бар қорғалу. Қуат, дисктер мен желі бойынша резервтеу, қалпына келтіру тесттері.
• Кадр факторлары. IT тарапынан жауапты адам тағайындау, жұмыс кестесі және мердігердің алғашқы апталардағы қолдауға жауапкершілігі.

Допущенияларды қалай жазу керек

Допущенияларды «біз былай есептейміз, өйткені әйтпесе есеп өзгереді» форматында жазу тиімді. Әр допущениеге дереккөз және оның орындалмауының әсерін көрсетіңіз.

Мысалдар:

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

Егер сіз поставщик қызметінің шарттарына (реакция уақыты, ЗИП, 24/7 қолдау) сүйенсеңіз, оны допущениялар тізімінде көрсетіп, құжаттық расталатындығын тексеріңіз.

Бюджет комиссиясына ұсынардан бұрын жылдам чек-лист

Ұсынардан бұрын: деректер, есептер, дәлелдер

Алдын ала тез әрі қайта тексерілетін минимумды жинаңыз:

• контур мен маңыздығы: серверлер мен жүйелер тізімі, сервис иелері, пайдаланушылар саны, рұқсат етілген простой терезесі, ағымдағы қолжетімділік талаптары
• сенімділік фактілері: 6–12 айдағы простойлар (өтініштер немесе мониторингтен), орташа қалпына келтіру уақыты, негізгі себептер (аппарат, қуат, СХД, ОС, адам факторы)
• есеп логикасы: бастапқы сценарий (қазір қалай) және мақсатты сценарий (жаңартудан кейін), өлшем бірліктері (сағаттар, тенге, FTE), екі рет есептелмегеніне көз жеткізу
• толық иелік құны: CAPEX және OPEX 3–5 жылға не кіретіні (қолдау, ЗИП, лицензиялар, электр, шкафтағы орын, выездтер, оқыту)
• тексерілетін қосымшалар: спецификациялар мен КП, миграция жоспары даталарымен және жауапты тұлғалар, допущениялар мен тәуекелдер кестесі, кілт жүйелер иелерінің келісімі

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

Қорғауда не айту және қалай жауап беру

Үш негізгі тезис:

• біз темір сатып алмаймыз — біз простойлар мен тәуекелдерді төмендетіп жатырмыз, сағаттық құн мен статистика расталған
• таңдалған нұсқа 3–5 жылға TCO және қолдау жағынан ең жақсы әсер береді, тек «көбірек қуатты» емес
• ауысу тәуекелдері төмендетілген (пилот, ауысу терезесі, откат, жауапкершілік)

Үш типтік сұрақ пен қысқа жауаптар:

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

Неге ағымдағы серверлердің қызметін ұзартпасқа? Бұл негізгі тәуекелдерді жаппайды және апатты жұмыстар мен простойлар себебінен жиі қымбатқа түседі.

Егер әсер аз шықса не болады? Модельде консервативті сценарий бар, допущения бөлек көрсетілген және іске қосқаннан кейін KPI арқылы бақыланады.

Келесі қадамдар: есептен жобалуға дейін

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

2–3 модернизация нұсқасын бекітіңіз (нүктелік сервер ауыстыру, виртуализация кластерін жаңарту, гибридті тәсіл) және коммерциялық ұсыныстар сұраңыз. Тапсырыс сұрауында бастапқы допущенияларды көрсетіңіз (ағымдағы простойлар, критикалық сервистер, ауысу терезелері), сонда ұсыныстар шын мәнінде салыстырмалы болады.

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

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

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

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

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