Nexus-ты open source-қа ауыстыру: пакеттерді көшіру және сақтау ережелері

Неліктен Nexus немесе Artifactory-ді ауыстыру керек және әдеттегі проблемалар

Репозиторий кіші болған кезде коммерциялық Nexus немесе Artifactory «қойып, ұмытып қоюға» ыңғайлы шешім сияқты көрінеді. Бірақ командалар мен пакеттер саны өскен сайын бюджеттің және сенімділіктің ауыртпалығы көрініп шығады.

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

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

Осы фонда open source-қа өту көбіне «ең арзан жолмен үнемдеу» емес, бақылауды қайтару туралы болады. Өз ережелеріңізді орнатқыңыз келеді, деректердің қайда сақталатынын білу және бір ғана жеткізушіге байланбау маңызды.

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

Artifactory-ге балама таңдағанға дейін миграция шектеулерін келісу пайдалы: қабылданатын тоқтап тұру терезесі (немесе тоқтаусыз талап), ауысу тәртібі және RPO/RTO мақсаттары. Мысалы, RPO «жарияланған бір де бір пакет жоғалтылмайды» синхрондау және жариялауды уақытша тоқтатуды талап етеді, ал RTO «жинақтар бір сағат ішінде қайта жұмыс істеуі тиіс» DNS, айна және кері қайтару сценариін дайындауды талап етеді.

Open source баламалар: таңдаудан бұрын не салыстыру керек

Nexus-ты open source-қа ауыстыруды жоспарласаңыз, бірінші өнімнің атына емес, нақты қажеттіліктер картасына қараңыз. Бір шешім Maven-ді жақсы жабуы мүмкін, бірақ Docker/OCI үшін ыңғайсыз болуы мүмкін. Біреуі интерфейс жағынан ұнайды, бірақ құқықтарды баптауға көп уақыт талап етеді.

Алдымен қазір қандай пакеттер бар екенін және алдағы 6–12 айда қандай пакеттер пайда болады екендігін нақтылаңыз. Әдетте бұл Maven, npm, PyPI, NuGet және Docker/OCI контейнерлері, кейде сирек форматтар шығады. Тізім нақты болған сайын миграция кезінде тосынсыйлар азаяды.

Жұмыс режимдері мен үйлесімділік

Қандай режимдер қажет екенін және оларды таңдалған шешімде қалай атайтынын тексеріңіз. Nexus-та бұл proxy, hosted және group. Open source аналогтарында атаулар өзгеше болуы мүмкін, бірақ мәні бір: сыртқы көздерді кэштеу, өз пакеттерді сақтау және клиенттерге бірегей мекенжай беру.

Продқа орналастырмас бұрын негізгі нәрселерді салыстырыңыз: қолдайтын форматтар мен ерекшеліктер (әсіресе npm және NuGet), proxy/hosted/group режимдерінің болуы, командаларға баптау ыңғайлығы, құқықтар моделі (рөлдер, топтар, гранулярлық, кездейсоқ жариялауды қорғау), сенімділік (кластер немесе қалпына келтіру мен бэкап жоспары), сондай-ақ UI мен CI интеграциялары.

Контейнерлер туралы бөлек

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

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

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

Инвентаризация: қазір не бар

Nexus-ты open source-қа алмастырмас бұрын қазіргі жағдайды басқа командаға тапсыратындай сипаттап алу пайдалы — бұл күндер үнемдейді: тосынсыйлар мен откаттар азаяды.

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

Келесі қадам — көлемдер мен өсімді бағалау. Жалпы диск өлшемі жеткіліксіз: нақты қай жерде кеңейтетініңізді білу керек. Көбінесе 20% репозиторий 80% орынды алады — бұл тасымалдау стратегиясы мен сақтау ережелерін анықтайды.

Кім және қалай жариялайтынын тіркеңіз. Ағындарды CI (мысалы, commit бойынша жинақтар), қолмен жүктеулер, IDE-ден жариялау, жеке командалар немесе мердігерлер деп бөліңіз. Қолмен жүктеулер жаңа орнында құқықтар мен атау ережелерін реттеу қажеттігін көрсететін жиі сигнал.

Жинақтауға ыңғайлы минималды деректер:

• репозиторий, түрі (release, snapshot, proxy, local) және иелері
• қазір көлемі, айлық өсімі, ең «ауыр» жобалар
• жариялау әдістері (пайплайндар, токендер, аккаунттар)
• маңызды интеграциялар (Jenkins немесе GitLab CI, IDE, Kubernetes, осалдық сканерлері)
• прокси арқылы өтетін сыртқы көздер және себебі

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

Мақсатты схема: жаңа репозиторий қалай көрінеді

Мақсатты схема миграцияға дейін болуы керек. Әйтпесе пакеттерді көшірген соң адрес, құқықтар және сақтау ережелерін қайта құруға тура келеді. Алдын ала әзірлеушілер әр ортада (dev, stage, prod) қалай жариялайтынын және жүктейтінін сипаттау ыңғайлы.

Орталары бойынша репозиторийлер: dev, stage, prod

Жай жүйе — орта бойынша бөлу, сонда dev-тегі кездейсоқ жинақ prod-қа түсіп қалмайды. Әдетте жеткілікті:

• dev: жиі жариялаулар, snapshots, эксперименттік пакеттер
• stage: релиз кандидаттары, қайталанушылықты тексеру
• prod: тек релиздер, жариялауға минималды құқықтар

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

Домейндер мен URL: ескі ме, жаңа ма

CI, Docker, Maven және npm бұрыннан ескі адрес бойынша бапталған болса, URL сақтау тәуекелді айтарлықтай азайтады. Оны DNS-алиас немесе ескі сұрауларды жаңа сервиске бағыттайтын кері прокси арқылы істейді.

Жаңа URL-дер тәртіп орнатуға және біркелкі атауларға көшуге ыңғайлы болса, оларды енгізу орынды — бірақ онда CI мен әзірлеушілердің конфигтерін жаңарту үшін уақыт керек.

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

Бастапқыда көп сатылар локалды дискпен бастаса да, оңай өсу шегіне тап болады. Желілік сақтау көлемді ұлғайту мен бэкапты жеңілдетеді. Объектілік сақтау (S3-үйлесімді) арзанырақ көлем қажет болса және S3-практика болса тиімді.

Қолжетімділік бойынша минимумды таңдаңыз: бір түйін жақсы бэкаптармен немесе бірнеше түйін және балансировка. Өсу күтілсе, репозиторий қай жерде болатынын (мысалы, сіздің дата-орталықта GSE S200 деңгейіндегі серверде немесе бар платформада) және 12–18 айға қажетті CPU, жад пен диск қоры қандай болатынын жоспарлаңыз.

Пакеттерді тосынсыйсыз көшірудің кезең-кезең жоспары

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

Қадамдар тәртібі

Тесті стендтен бастаңыз және әр пакет түрі үшін нақты тізбекті сынап көріңіз: жариялау, жүктеу, метадеректер жаңарту, снапшоттармен жұмыс, кэш тазалау. Қателер көбіне оқу емес, жариялау мен артефакттарды қол қою кезінде шығады.

Келесі кезеңдер:

• Ауыстыру стратегиясы мен «мұздату» күнін анықтау (қашан ескі репозиториге жариялау тоқтатылады).
• Сыртқы көздерге прокси орнатып, критикалық тәуелділіктер үшін кэшіні алдын ала жылытуды ұйымдастыру, сонда алғашқы жинақ тосынсый болмайды.
• hosted-репозиторийлерді көшіру: алдымен жалпы кітапханалар, кейін сервистер, соңында сирек пакеттер.
• метадеректер мен нұсқалар тегтерін синхрондап, содан кейін CI-тен жаңа репозиториге тестілік жариялауды қосу.
• Клиенттерді ауыстыру: CI, әзірлеушілер машиналары, кластерлер. Оны орталықтандырылған айнымалылар мен конфигурациялық шаблондар арқылы оңайлату тиімді.

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

Шынайы жұмыс істейтін кері қайтару жоспары

Откат алдын ала тексерілген және минуттар ішінде орындалатындай болуы керек:

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

Осылайша Nexus-ты open source-қа ауыстыру алдын ала болжанатын болады: жүйе өзгерсе де, жинақтау мен релиз процесі бұзылмайды.

Құқықтар: рөлдерді көшіру және жариялауды қорғау

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

Алдымен қолжетімділік моделін жазыңыз: локалды пайдаланушылар, LDAP/AD топтары, рөлдер, сондай-ақ токендер (user tokens, access tokens, API keys). Айрықша белгілеңіз — CI роботтары не қолданатынын және қай репозиторийлерге сыртқы командаларға рұқсат берілгенін.

Жаңа шешімде құқықтарды сәйкестендіру

Көп репозиторийлерде құқықтар келесі әрекеттер жиынтығына түсіріледі. Ыңғайлы рөлдерді келісіңіз (reader, publisher, maintainer, admin) және оларды рұқсаттармен сәйкестендіріңіз:

• Read (download) және Browse — көпшілік әзірлеушілерге
• Write (publish) — тек релиз пайплайндары мен жауапты командаларға
• Delete — тар шеңберге процесске сәйкес
• Admin — мүмкіндігінше минималды адамдар тобына

CI сервис-аккаунттарын жеке етіңіз және жеке тұлғалардан бөлек жасаңыз. Оларға минималды құқық беріңіз: нақты hosted-репозиторийге жариялау және тек қажетті proxy/group оқу.

Токендерді мерзімі шектеулі етіп жасаңыз, CI құпияларында сақтаңыз, айналымды қосыңыз (мысалы, 30–90 күнде бір рет) және қызметтен кеткенде немесе мердігер ауысқанда оларды өшіріңіз.

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

Логтар мен аудит

Оқиғаларды және тексерулерді талдау үшін не журналдауды шешіңіз. Минимум:

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

Осылай қателерді тауып алуға және өтініштерді тексеруге оңай болады.

Ретеншен саясаты: нұсқалар арасында батпаққа батып қалмау

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

Алдымен артефакттарды мағынасына қарай бөлу. Продқа шыққан релиздер әдетте ұзақ сақталады және сирек жойылады. Уақытша артефактілер (feature-тар, nightly, эксперименттер) шектеулі уақыт өмір сүруі тиіс.

Жақсы старт — жеңіл түсінікті ережелер:

• релиздер үшін соңғы N нұсқаны сақтау (мысалы, 20) және LTS деп белгіленгендерді ұстап қалу
• уақытша жинақтарды жасқа қарай жою (мысалы, 14–30 күннен үлкендер)
• тегтер немесе префикстер бойынша ерекшеліктер жасау (keep-, release-, hotfix-)
• тазалаудан бұрын критикалық артефактілерді бекіту
• кездейсоқ атаулардың орнына түсінікті тегтер мен нұсқаларды талап ету

Docker/OCI үшін бөлек ережелер қажет. latest өзі ештеңе айтпайды — ол жай ғана көрсеткіш. Әдетте main және release-тегтерді ұзақ сақтау, feature/* және nightly-ді тез тазалау, және әр сервис үшін соңғы 5–10 образды сақтау ыңғайлы. Сондай-ақ кластерде немесе деплой манифесттерінде әлі пайдаланылып жатқан образдарды жоймауды тексеріңіз.

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

Командалармен келісімді нақты сценарийлер арқылы жүргізген дұрыс. Егер әзірлеуші екі апта бұрынғы нұсқаға кері оралуын қаласа және сіз 7 күннен кейін жою ережесін орнатсаңыз — қайтару сәтсіз болады. Онда порогтарды өзгерту немесе staging-ке түскендерді кем дегенде 30 күн сақтау тәртібін енгізу керек.

Диск орнын бақылау және техникалық қызмет

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

Шектеулер мен мониторинг

Порогтар мен нақты ескертулерден бастаңыз. Алертті бір админ ғана емес, нақты жауапты адамдар көруі керек.

• 70% толған кезде: ескерту, өсу мен жақын релиздерді бағалау
• 85%: ретеншен ережелері бойынша жедел тазалау, артық жариялауды тоқтату
• 95%: апатты режим, push-ты уақытша тыйып, техникалық қызмет терезесін тағайындау

Апта сайын тұтыну есебін алып отырыңыз: ең үлкен репозиторийлер, ең ірі проекттер, ең үлкен артефактілер. Бұл nightly жинақтардың релиз сияқты жариялануы немесе гигабайттық debug-символдардың мерзімсіз сақталуы сияқты проблемаларды жылдам анықтайды.

Тазалау және бэкап

Тазалау тұрақты және болжамды болуы тиіс. Автоматты тазалауды қосқанда, копияда немесе бір репозиторийде алдымен ережелерді тексеріңіз, әйтпесе қажет нұсқаларды жою қаупі бар.

Прокси кэштер мен уақытша файлдарды қауіпсіз тазалауға болады: кэш қайта-қайта жүктеліп қалпына келеді, ал локалды жарияланған артефактілер — жоқ. Уақытша жүктеу каталогтары мен аяқталмаған сессиялардың орналасуын білу маңызды.

Бэкап «ми мен денені» қамтуы керек:

• метадеректер (дерекқор, конфигтер, пайдаланушылар/рөлдер, баптаулар)
• бинарниктер (blob-хранилище, артефактілер)
• жиілік: метадеректер күнделікті, бинарниктер сіздің RPO бойынша (көп жағдайда күнделікті инкремент және апталық толық жеткілікті)

Егер прокси-репозиторий айына жүз гигабайтқа өссе, ал локалды релиздер мүлде өзгермесе, көбінесе себеп — кэш. Сол кезде TTL, пайдаланылмаған пакеттерді жүйелі жою және «не жүктеледі, бірақ қолданылмайды» есептері көмектеседі.

Орташа жоба үшін миграция сценарийінің мысалы

Орташа өнімді елестетейік: 3–4 команда, CI-де жинақтар, Maven (Java), npm (frontend) және тест/прод үшін Docker-образылар қолданылады. Мақсат — Nexus-ты open source-қа ауыстыру релиздер тоқтаусыз және артефактілер жоғалусыз.

Алдымен жаңа репозиторий бөлек ортада орнатылады және Maven Central, npm registry, базалық Docker-образылар сияқты сыртқы көздерді проксилеу бапталады. Бұл интернетке тәуелділікті азайтады және кэштеуді тексеруге мүмкіндік береді.

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

Мысалы тәртібі:

• Күн 1–2: жаңа репозиторийді орнатып, прокси мен негізгі репозиторийлерді баптау (maven-releases, maven-snapshots, npm, docker).
• Күн 3–4: релиз артефактілер мен образдарды көшіру, хэштер мен тегтердің сәйкестігін тексеру.
• Күн 5: снапшоттарды және веткалық жинақтарды көшіру, бастапқы ретеншен саясатын қосу.
• Күн 6: бір жобаны CI-де жаңа репозиторийге жариялауға ауыстырып, бақылау.
• Күн 7: қалған жобалар мен командаларды ауыстыру.

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

Қорытындыда: әзірлеушілердің конфигтері жаңартылады (settings.xml, .npmrc, docker login), жүктеу жылдамдығы мен диск жүктемесі өлшенеді, және ескі репозиторийді 2–4 апта read-only режимінде ұстау қажет болады. Осы аралықта релиздер жаңа сақтау орнында тұрақты қайталанғанда ғана ескі сервер ажыратылады.

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

Nexus-ты open source-қа ауыстырудағы ең қымбат қате — «оңайынан» бастау: толық картинаны түсінбей көшіру. Көпшілік кейде сирек қолданылатын репозиторийлерді (ескі npm немесе жеке Docker registry секілді) байқамай қалады — олар айына бір рет қолданылса да релизді бұзады. Шешім: көшірмес бұрын форматтар, репозиторийлер, прокси, тазалау кестелері және нақты клиенттер (CI, әзірлеушілер, агенттер) тізімін бекіту.

Екінші жиі проблема — CI құқықтарының тым кең болуы. Егер сборка токені жоюға, қайта жазуға немесе релиз репозиторийіне жариялауға мүмкіндік берсе, бір қате тег жеткілікті болып, сақтау орнына деген сенімді жояды. Құқықтарды бөліңіз: CI snapshots (немесе staging) жариялайды, ал releases-ке көтеру жеке рөл және бөлек пайплайн қадамы болсын.

Ауыстыру күні жинақтарды бұзбау үшін

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

Ретеншен мен бэкап: автоматикаға сақ болыңыз

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

Бастамас бұрын тексеріңіз:

• бэкапта тек blobs қана емес, метадеректер (индекстер, база) бар ма
• қалпына келтіру тесті стендте жасалды ма
• диск өсімі өлшенді және оповещения бар ма
• DNS/URL ауыстыру тәртібі және кері қайтару хаттамасы жазылды ма
• байқалмайтын клиенттер (ескі агенттер, скрипттер, cron) тіркелді ме

Егер Maven жобасы бір settings.xml арқылы жылдар бойы жиналған болса, репозиторий атауын өзгертпей DNS алиасын қоспай ауыстыру жинақты бұзуы ықтимал, тіпті барлық артефактілер көшірілген болса да.

Қысқа чеклист және кейінгі қадамдар

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

Тексеру тізімі:

• Форматтар мен көздер бекітілді: қандай пакеттер сақталады (Maven, npm, Docker), қандай репозиторийлер қажет және әрқайсының иесі
• Құқықтар сипатталды: кім оқиды, кім жариялайды, кім әкімшілік етеді және не «прод» саналады (мысалы, релиздерді қайта жазуға тыйым)
• Сақтау саясаты келісілді: қанша нұсқа сақтаймыз, не жоямыз, қандай ерекшеліктер керек (реттеуші талаптар, «алтын» образдар)
• Диск бақылауы бапталды: порогтар, алертер, жоспарлы тазалау және толғанда іс-қимыл процедурасы
• Тесті жүгірту өткізілді: пакеттердің бөлігі стендке көшірілді, жинақтар тексерілді және документтелген откат жоспары бар

Одан әрі қадамдар:

• cutover күнін бекітіп, миграция күніндегі қысқа регламент дайындау
• командаларға нұсқаулықтар дайындау: адрестер, токендер, жариялау ережелері
• финалдық сәйкестікті жүргізу: сақтау өлшемі, жылдамдық, құқықтар, ретеншен, алертер
• пост-миграциялық аудит 1–2 аптадан кейін: көлем қайда өсті, не тазалау керек, қай жерде шектеулер жеткіліксіз

Көмек керек болса, жүйелік интеграторды тартуға болады. Мысалы, GSE.kz (gse.kz) инфрақұрылымдық бөлікті — сервер таңдау мен жеткізу, шешімді орнату және 24/7 қолдауды жапсыра алады.