IT директорына арналған Open Source-қа көшу картасы: қабаттар мен тәуекелдер

Неге көшу картасы керек және ол болмаса бәрі неге ұзарады

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

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

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

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

Инвентаризация: нақты не ауыстырып жатырсыз және кім зардап шегеді

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

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

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

• өнім және оның нақты функциялары (бүгін қалай қолданылып жатқанын, «қолданылуы тиіс» емес)
• иесі, негізгі қолданушылар және инцидент кезіндегі кезекшіліктер
• интеграциялар: AD/LDAP, пошта, файл ресурстары, резервтік көшіру, мониторинг
• маңыздығы және рұқсат етілген тоқтау терезелері (не тоқтатылмайды, не кезең-кезеңмен ауыстырылуы мүмкін)
• негізгі метрикалар: аптайм, инцидентке реакция уақыты, деректер көлемі, пошталық жәшіктер/ВМ саны

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

Қабаттар бойынша бөлу: тәуелділіктер, тәртіп және кері қайтару нүктелері

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

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

• жабдық және прошивкалар
• желі (VLAN, маршрутизация, DNS)
• ОС және базалық конфигурация
• виртуализация және сақтау
• идентификация (аккаунттар, топтар, MFA)

Сосын тәуелділіктерді жазыңыз. Мысалы, пошта мен бірлескен жұмыс DNS, дұрыс уақыт (NTP) және сертификаттар тізбегіне тәуелді. Мониторинг пен логтау желі және рұқсаттардан, деректерді қай жерде сақтау және қанша уақыт сақтау керектігінен тәуелді.

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

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

Алдын ала қабылданған болжамдарды келісіп қойыңыз: қай жерде гибрид рұқсат етіледі (мысалы, кейбір ВМ әлі ескі платформада қалады), ал қай жерде толық өту қажет — реттеуші талаптар немесе қолдау себебінен. Бұл дау-дамайларды азайтып, мерзімдерді ұстауға көмектеседі.

Табыстың критерийлері: миграцияның сәтті болғанын қалай өлшеуге болады

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

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

Тексерілетін метрикалар

Аптасына өлшенетін бірнеше нақты санды таңдаңыз:

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

Нәтикті кім қабылдайды

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

Қадамдық жұмыс жоспары: пилоттан өндірістік эксплуатацияға дейін

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

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

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

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

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

ОС қабаты: стандартизация, қауіпсіздік және жұмыс орындарының қолдауы

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

Стандартты образдан бастаңыз: бір-екі ОС нұсқасы, драйверлар жиынтығы, біртекті базалық қауіпсіздік баптаулары (шыфрлау, экранды құлыптау, артық құқықтарды шектеу). Варианттар аз болған сайын қолдау мен оқыту оңайырақ.

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

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

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

Виртуализация қабаты: кластерлер, сақтау және ВМ-дерді көшіру жоспары

Виртуализация көбіне бәрін ұстап тұрады: іскерлік қосымшалар, тест орталар, резервтік көшіру, апаттан қалпына келтіру. Сондықтан бұл қабатты «гипервизорды ауыстыру» емес, платформа ретінде сипаттау жақсы: гипервизор + кластер + желі + сақтау + бэкап.

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

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

Платформаны таңдаудан бұрын тексеретіндер

• сіздің жабдық пен драйверлерді қолдайтыны (HBA/RAID, желі карталары, қажет болса GPU)
• сақтау архитектурасы: өнімділік, кешігулер, репликация, снапшоттар
• желі: өткізу қабілеті, трафик оқшаулауы, беріктік
• ВМ резервтік көшіру: жиілік, қалпына келтіру гранулярлығы, қалпына келтіру тесті
• ресурстар қоры: жүктеме өсуі, репликация, қызмет көрсету терезесі

ВМ-ді көшіру жоспарын сценарий ретінде жазыңыз. Дискі форматтарының және миграция тәсілдерінің үйлесімділігін, қай жерде «жанды» миграция мүмкін екенін, қай жерде тоқтататынын анықтаңыз. Әр ВМ топқа арналған тоқтау терезесі, тәртіп, кері қайтару критерийлері және көшіруден кейінгі өнімділік тесті көрсетілуі тиіс.

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

Пошта және бірлескен жұмыс қабаты: сценарийлер, көшіру және коммуникация

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

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

Ауыстырудан бұрын почтаға қатысты сыртқы баптауларды дайындаңыз: DNS жазбалары, SPF/DKIM/DMARC, сертификаттар, антиспам және маршрутизация ережелері. Оны соңғы күні жасау жеткіліксіз — жеткізу проблемалары мен шағымдар қаупі жоғары.

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

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

Егер 24/7 қолдау ресурсыңыз аз болса, ауыстыру күндеріне сыртқы қолдауды алдын ала келісу орынды — болмаса бұл күндер қолмен өшіру-жоғалтуды басу күніне айналуы мүмкін.

Мониторинг пен логтау қабаты: көшуны соқыр өткізбеңіз

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

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

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

Дашбордтарды аудиторияларға бөліңіз: басшылыққа — негізгі сервистердің қолжетімділігі, инциденттер саны және SLO орындалуы; инженерлерге — CPU, жад, диск, кешігулер, қателер, тапсырмалар кезектері мен тәуелділіктер.

Логтарды сақтау туралы бөлек ойлаңыз: сақтау мерзімдері, қолжетімділік құқықтары, сезімтал деректерді маскілеу және сақтау орны (мемсектор мен қаржы секторында бұл әсіресе маңызды). Практикада бұл нақты құралды таңдаудан гөрі маңыздырақ болады.

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

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

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

Ыңғайлы формат — тәуекелдер кестесі. Әр тармақ үшін алты өріс жеткілікті:

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

Қабаттар бойынша типтік тәуекелдер жиі қайталанады.

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

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

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

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

IT-директорлардың Open Source-қа өту кезінде жасайтын типтік қателіктері

Миграцияның сәтсіздігі көбіне технология емес, әрекет тәртібінің дұрыс болмауынан болады. Open Source көптеген опция береді, бірақ ұйымдастыруда қателесуге болатын орындар да көп.

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

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

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

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

Типтік қателер жинағы:

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

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

Бастамас бұрын және әр кезең алдында қысқа чек-лист

Бастамас бұрын

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

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

Әр толқын алдында

Әр көшіру алдында (екінші немесе үшінші қабатта болса да) мына сұрақтардан өтіңіз:

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

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

Мысал сценарий: орташа компания және қабаттар бойынша қаһармандықсыз миграция

500 қызметкері бар, екі локациясы (бас офис пен филиал) бар компанияны елестетіңіз. Сервер жағы — коммерциялық виртуализация, корпоративтік пошта және бірнеше бөлшектелген мониторинг жүйелері. IT-директордың міндеті — адамдар өзгерісті байқамай, IT түнгі ерліктер режиміне көшпей, Open Source-қа көшу картасын жасау.

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

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

Табыстың критерийлерін цифрлармен бекіткен дұрыс, әйтпесе тапсыру күні даулар басталады:

• критикалық сервистердің тоқтауы ауыстыру терезесінде X минуттан артық болмауы
• қолдаудың инцидентке реакциясы — Y минут ішінде (тикет пен қоңырау бойынша)
• домен ішіндегі пошта жеткізілуі — Z минутқа дейін, жоғалтусыз
• бір ВМ-ді бэкаптан қалпына келтіру — N сағаттан ұзақ емес

Көбіне үш тәуекел шығады. Жұмыс орындарында — периферия (принтер, сканер, токендер, арнайы драйверлер). Поштада — архивтер мен жылдар бойғы ережелер, қоса заңдық сақтау талаптары. Локациялар арасында — өткізу қабілеті: ВМ және пошта ящиктерін көшіру жұмыс уақытында арнаны бітіріп жіберуі мүмкін.

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

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

Карта дайын болса, оны басқарылатын жобаға «түсіріңіз». Жақсы белгі — кез келген IT басшысы карта бойынша не істейтінін, не үшін, табыс қалай өлшенетінін және қай жерде кері қайту мүмкін екенін түсінуі.

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

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

Картаны тоқсандық жоспарға айналдырыңыз:

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

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

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

Жай басқару ережесі: әр толқын пилот табысының критериялары жабылғаннан және тәуекел картасы жаңартылғаннан кейін ғана басталсын.