On-prem, бұлт немесе гибрид: қосымшаларға арналған таңдау матрицасы

Таңдау қайдан басталады: мәселе, технология емес

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

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

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

Интеграциялар жасырын күрделілікті қосады. Қосымша сирек қана отдельно тұрады: бухгалтерия, қойма, CRM, BI, ЭДО, порталдар, кассалар, терминалдар, мемлекеттік сервистер. Егер тек «ядроны» ғана көшіріп, ал алмасуды «как получится» қалдырсаңыз, тез арада кезектер, дубльдер және қолмен жасаған экспорттар пайда болады.

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

Модель дұрыс таңдалмағанының белгілері:

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

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

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

Үш орналастыру моделі қарапайым тілде

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

On-prem (өз объектіңізде)

On-prem дегеніміз серверлер мен жүйелер физикалық түрде сізде орналасқанын білдіреді: серверлік бөлмеде, корпоративтік дата-орталықта немесе мердігерде, бірақ сізге бөлінген жабдықта. Сіз дерлік бәрін басқаратын боласыз: қолжетімділік, жаңартулар, бэкап, мониторинг.

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

Бұлт (провайдерде)

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

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

Шектеулер технологияда емес, шарттарда көрінеді: деректер қайда сақталады, экспорт қалай жасалады, қалпына келтіруге қанша уақыт беріледі, не тоқтап қалу ретінде есептеледі.

Гибрид (аралас тәсіл)

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

Гибридтің жиі «бұзылатын» жерлері:

• интернет арнасы (кіру қабілеті мен кешігу);
• интеграциялар және тұрақты алмасу «осыдан-аянға»;
• қолжетімділік басқару (екі ортада әр түрлі тіркелгілер мен рөлдер);
• қолдау (стыкта қай адам инцидентке жауапты екені анық емес);
• шығын (трафик және дубликацияға күтпеген шығындар).

Жай мысал: егер қосымшаның интерфейсі бұлтта, ал база on-prem болса, әр бір клик арна кешігуіне ұшырайды. Сол кезде деректер мен қосымшаны «жақындату» не критикалық контурды бір жақта қалдыру қажет.

Деректер мен талаптар: ұмытпауыңыз тиіс нәрселер

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

Деректерді классификациялаңыз: клиенттер мен қызметкерлердің персоналдық деректері, қаржылық құжаттар, медициналық жазбалар, өндірістік деректер (телеметрия, рецептуралар, жабдық параметрлері), техникалық журналдар. Әрбір класстың өзіне тән қолжетімділік, аудит және сақтау мерзімі талаптары бар.

«Ел ішінде сақтау» және қолжетімділік шектеулері қайда пайда болады

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

Тек «дерекқор қайда» деп қана тексермей, резервтік көшірмелер, журналдар, шифрлау кілттері мен әкімшілік қолжетімділіктің қайда екенін де қараңыз.

Практикалық тексеріс:

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

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

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

On-prem толық бақылауды береді, бірақ бәрін орнату және қолдау міндетін жүктейді. Гибридте журналдардың бір бөлігі бұлтта, бір бөлігі жергілікті болғанда «көмескі аймақ» пайда болмауы тиіс — біртұтас көріністі және оған кім жауапты екенін алдын ала анықтау маңызды.

Резервтік көшіру мен қалпына келтіру жауапкершілік бойынша да ерекшеленеді. Бұлтта көшірмелер жасау оңай, бірақ бұл автоматты түрде сенімді қалпына келтіру емес. On-prem-де сіз кесте, тасымал, көшірмелерді изоляциялау және тестілеу үшін жауапты боласыз. Гибридте «шындық көзі» қайсы екенін және апат кезінде жүйені қалай көтеретініңізді алдын ала шешіңіз.

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

Интеграциялар: жасырын күрделіліктің негізгі көзі

Орналастыру моделін жиі сервер бағасына емес, интеграцияларға байланысты «сыныптап жібереді». Қосымша күнделікті бухгалтериямен, CRM-мен, қойма жүйелерімен, кадрлық жүйелермен, филиалдардағы терминалдармен, цехтағы жабдықпен немесе медициналық техникалармен деректер алмасады.

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

Қосымшалармен интеграция қалай жасалады

Әдетте бірнеше нұсқа бар:

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

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

Тағы бір мәселе — сәтсіздік нүктелері. VPN, шлюзтер, проксилер, файрволдар және балансировщиктер қауіпсіздікті арттырса да, бәрі тоқтап қалатын орындарды көбейтеді. Критикалық интеграциялардың көбі «бұлт‑локал» шекарадан өтсе, байланысты компоненттерді бір жерде ұстаудың маңызы артады.

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

Кешігулер мен өнімділік: сандарға қалай аудару керек

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

«Ұнамайды» мен «мүлде болмайды» айырмасын бөлу маңызды. Касса үшін қосымша бір секунд кезекке айналуы мүмкін. Қоңырау орталығы үшін әр кликте 2–3 секунд үнемделмейтін болса, сөйлесулер уақыты тез азаяды. MES жүйелерінде кешігу өндірістің тоқтауына әкелуі мүмкін.

Бизнеспен бір тілде сөйлесу үшін ориентирлер:

• 50–100 мс: былайша өндірісте сезілмейді, жиі кликтер мен интерактив экрандарға жарайды;
• 100–300 мс: көбінесе офис жұмысы үшін қалыпты;
• 300–800 мс: байқалады, бірақ сирек операциялар үшін төзімді;
• 1–3 секунд: есептер мен ауыр формалар үшін қабылданады;
• ондаған секундтар мен минуттар: тек фондық тапсырмалар үшін.

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

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

Модельді бекітер алдында тексеріңіз:

• бизнес үшін 3–5 негізгі операцияға рұқсат етілген максималды кешігу қандай;
• 10–30 минуттық канал үзілісінде не болады;
• қай жерде «жергілікті» деректер қажет (кэш, анықтамалықтар, қалдықтар);
• бір жыл ішінде жүктеменің қалай өсетінін.

Қосымшаның модели таңдау алгоритмі

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

Айқындық беретін 5 қадам

1. Критикалық процестер мен рұқсат етілген тоқтап қалуды сипаттаңыз. Қосымша қолжетімсіз болса не тоқтайды: сатылымдар, қойма, пациент жазбалары, есептеулер? Тоқтап қалу терезесін бекітіңіз: «30 минуттан артық емес», «түнгі сағатта 4 сағатқа дейін рұқсат етіледі», «тоқтау қабылданбайды».

2. Деректерді классификациялап, қолжетімділік ережелерін белгілеңіз. Деректерді топтарға бөліп, кім қайдан қол жеткізуі керек екенін (офис, филиалдар, мердігерлер), қандай тексерулер міндетті екенін (журналдар, сақтау, рөлдер) белгілеңіз.

3. Интеграциялар мен деректер ағымының схемасын салыңыз. Бір парақ жеткілікті: қандай жүйелер деректер алмасады, «шындық көзі» қай жерде, қай жерде кезек, қай жерде файлдар, қай жерде API.

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

5. 2–3 нұсқаны таңдап, бір кестеде салыстырыңыз. Мысалы: on-prem, бұлт, гибрид. Әрқайсысын деректер, интеграциялар, кешігулер, меншік құны және өзгерістер жылдамдығы бойынша бағалаңыз.

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

Шешім матрицасы: критерийлер және оны қалай толтыру керек

Матрица «on-prem, бұлт не гибрид» дауынан эмоцияны алып тастап, шешімді тексерілетін фактілерге негіздейді. Әр қосымша үшін бөлек толтырыңыз: CRM, бухгалтерия, VDI және бейнебақылау әртүрлі деректер, интеграция және жауап уақыты талаптарына ие.

Критерийлер мен шкала

5–6 критерийді таңдаңыз, олар сіздің қосымшаларға нақты әсер етеді. Көбінесе жеткілікті болғандары:

• деректер (сезімталдық, сақтау орны, реттеуші талаптар);
• интеграциялар (жүйелер саны, протоколдар, алмасу жиілігі);
• кешігу және өнімділік (рұқсат етілген жауап уақыты, пикаптар);
• қолжетімділік және қалпына келтіру (SLA, RTO/RPO);
• команда және бюджет (мамандар, CAPEX/OPEX, мерзімдер).

Содан кейін шкаланы 1–5 арқылы белгілеп, сипатты белгілер арқылы бағалаңыз, «қалай сезіледі» емес. Мысалы: кешігуде 5 = көбінесе операциялар үшін 50–100 мс қажет, 3 = 200–300 мс, 1 = секундтар маңызды емес. Деректер үшін 5 = персоналдық/медициналық деректер мен қатал шектеулер, 1 = ашық немесе оңай деперсоналданатын деректер.

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

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

Ыңғайлы тәсіл — критерийді тікелей локализацияға тартымдылығына бағалау: 1 = дерлік тартпайды, 5 = қатты тартады. Содан кейін маңыздырақ критерийлерге салмақтар (1–3) беріңіз.

Санақтан кейін қарапайым ережелерді қолданыңыз:

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

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

Қателіктер мен тұзақтар

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

Шекарасы жоқ гибрид

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

Бір құжат көмектеседі, онда жазылады:

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

«VPN бәрін түзетеді» деген ой

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

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

Тек баға бойынша таңдау

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

Бэкаптарды «қанша заман» деп қою

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

Интеграцияларды өзгеріссіз көшіру

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

Шынайы мысал: филиалдары және ортақ базасы бар компания

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

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

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

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

Практикалық схема мысалы:

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

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

Жедел тексерістер және келесі қадамдар

Уақыт аз болса, сәйкес келмейтін нұсқаларды тез саралап, «on-prem, бұлт немесе гибрид» туралы әңгіме талғамнан гөрі фактілерге негізделсін.

Қысқа чек‑лист бойынша өтіңіз:

• басты деректер қайда тұрады және олардың иесі кім;
• қанша интеграция бар және олар кіммен (бухгалтерия, ЭДО, CRM, өндіріс, мемлекеттік сервистер);
• негізгі операциялар үшін қандай кешігу рұқсат етіледі;
• байланыс арнасы құлдырағанда не болады (офлайн режим, кезек, кэш);
• сәйкестік талаптары қандай (РК ішінде сақтау, аудит, журналдар, қолжетімділік сегментациясы).

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

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

Пилот үшін 3–5 типтік сценарий жинап, әділ салыстыру жасау үшін әртүрлі рөлдерден пайдаланушыларды және күнделікті өлшенетін метрикаларды (жауап уақыты, қателер саны, алмасу жылдамдығы, тоқтап қалу) енгізіңіз.

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

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