Серверлік көшіруді үзіліссіз өткізуге арналған runbook: жоспар және бақылау нүктелері

Көшу кезінде не нәрсе құрылады және «үзіліссіз» деген не білдіреді

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

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

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

Көшуге ең сезімтал сервистер әдетте сыртқы байланыстары көп және уақытқа қатал талаптары бар: AD/LDAP, DNS және DHCP, деректер базалары мен кезектер, телефония және VDI, төлем және интеграциялық шлюздер, сондай-ақ мониторинг пен резервті көшіру (әсіресе олар барлықымен бірге көшірілсе).

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

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

Инвентаризация және тәуелділіктер картасы

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

Біртұтас стойкалар бойынша жабдықтың регистрін жинаңыз: серверлер, СХД, коммутаторлар, UPS, KVM, SFP модульдері, патчкордтар және стойканы көтеруге қажет басқа «ұсақ-түйектер». Сериялық нөмірлерді, порт сызбаларын, қуат (қанша желі және қай розеткалар), сондай-ақ есте сақтауда қиын болатын қазіргі прошивка нұсқалары мен баптауларды тіркеңіз.

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

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

Тәуелділіктер картасында кемінде келесі мәліметтер болуы керек:

• әр қызмет үшін RTO/RPO және рұқсат етілген қолжетімділік терезелері
• дереккөздер мен жазу бағыттары (репликация, бэкаптар, кезектер)
• желілік тәуелділіктер: VLAN, подсетьтер, ACL, VIP, DNS, NTP
• пайдаланушыға қолжетімді нүктелер: офис, филиалдар, сыртқы клиенттер, интеграциялар
• ағымдағы күй: конфигурациялар, қосылу схемалары, нұсқалар, есептік жазбалар мен рұқсаттар

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

Жұмыс терезесі және хаоссыз коммуникация

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

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

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

Хабарламаларда батқаннан аулақ болу үшін қысқа статус форматтары туралы келісіңіз:

• START: қадам басталды, күтілетін аяқталу уақыты
• DONE: қадам аяқталды, не тексерілді
• HOLD: тоқтату, себеп, жалғастыру үшін не қажет
• ROLLBACK: кері қайту, қандай бақылау нүктесі және кім орындайды

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

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

Жаңа алаңның дайындылығы және негізгі инфрақұрылым

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

Алдымен физикалық базаны тексеріңіз. Бұл формальность емес: «жиді» қуат желісі немесе әлсіз салқындату көбіне тек жүктеме астында, көшу соңынан кейін көрінеді.

• Қуат: екі тәуелсіз желі (қажет болса), қуат есебі, нагрузка астындағы ATS/UPS тесті
• Салқындату: ыстық нүктелердегі температура өлшемдері, салқындық резерві, ауа ағыны анықтылығы
• Стойкалар: бекітулер мен бағыттағыштар, бос юниттер, салмақ пен тереңдік шектеулері
• Жерге қосу: бірыңғай схема, өлшемдер, «қолма-қол» қоспалар жоқ
• Кабель жолдары: лотоктар, кірістер, иілу радиустары, белгілеуге орын

Содан кейін желі мен адресация. VLAN, маршруттар және қосылу нүктелерінің келісіміне келіңіз, сонда сервер қосылғанда IP немесе ережелерді «тізеүстінен» өзгертудің қажеті болмайды. DNS және DHCP (немесе статикалық адресация), админ рұқсаттары, ACL/фаерволдар және тікелей жұмыс терезесінде қажет қашықтан қолжетімдікті бөлек тексеріңіз.

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

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

• Қажетті ұзындықтағы патчкордтардың қоры, SFP/DAC, стяжкалар, липучкалар, тығындар
• Белгілеу: принтер/этикеткалар, порттар мен кабельдердің атауларының схемасы
• Орналасу жоспары: әр стойка қайда тұратыны және қуат/желі желілері қайда баратыны
• Порт бойынша резерв: коммутаторларда және PDU-да бос порттар, қосымша розеткалар
• Авариялық мини-жиынтық: консоль кабельдері, адаптерлер, қосымша желдеткіштер/Қуат көздері (маңыздығына қарай)

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

Жақсы runbook қалай құрылады: құрылым, рөлдер, ережелер

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

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

Рөлдерді лауазымдар арқылы емес, жауапкершілік арқылы сипаттаған жөн. Міндетті минимум:

• Жұмыстар жетекшісі: уақытты басқарады, бақылау нүктелері бойынша шешім қабылдайды
• Желілер: арналар, маршруттау, DNS, балансирлеу
• Серверлер мен виртуализация: хосттар, СХД, кластерлер, резервті көшіру
• Ақпараттық қауіпсіздік: рұқсаттар, сегментация, журналдар, өзгерістерді бақылау
• Қызмет иесі: қызметтің "қалай жұмыс істеуі керек" екенін растайды

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

Қадам шаблоны

Чтобы шаги были предсказуемыми, используйте один и тот же формат:

Цель: что именно должны получить
Действия: 2-6 коротких команд/операций
Ожидаемый результат: что изменится
Проверка: как убедиться за 1-3 минуты
Откат: как вернуть исходное состояние

Уақыт және шешім нүктелері

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

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

Қадам бойынша миграция жоспары: дайындықтан іске қосуға дейін

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

1) Дайындық (күндер бұрын, сағаттар емес)

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

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

2) Өзгерістерді тоқтату

24–72 сағат бұрын change freeze енгізіледі: жаңартулар, желі ережелерін өзгерту, қолданба релиздері, домен/сертификат өзгерістері және кез келген «жедел түзетулер» тыйым салынады. Себебі: runbook-та көрсетілмеген кез келген өзгеріс болжамды бұзады және артқа қайтуды түсініксіз етеді.

3) Алдын ала ауысу

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

4) Өшіру және орау

Өшірудің қатал тәртібі керек: жоғарғы сервистен төменгіге (қолданба -> кезектер -> БД -> сақтау/виртуализация, қолданылса). Кабельдер мен порттар міндетті түрде белгіленіп, коммутацияның фотофиксациясы және әр қорапқа не кететінінің тізімі болуы тиіс.

5) Тасымалдау және монтаж

Жаңа алаңда олар алдын ала келісілген тәртіппен орналастырады: қуат пен жерге қосу, содан кейін желі (uplink, басқару), содан кейін есептеу және сақтау. Әр қадамда тез тексеру болуы тиіс: линк көтерілді, басқаруға қосылу бар, уақыт синхрондалған.

6) Іске қосу

Қосу төменнен жоғары қарай: қуат/UPS -> желі -> гипервизорлар/хосттар -> сақтау -> дерекқорлар -> қолданбалар -> фондық тапсырмалар. Әр деңгейден кейін қысқа тексеру («ДБ байланыстарды қабылдайды», «негізгі API 200 қайтарады», «кіру сәтті өтеді») және кейін ғана келесі қадам.

Бақылау нүктелері және артқа қайту критерийлері

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

Көбінесе төрт нүкте жеткілікті:

• Өшіруден немесе ауыстырудан бұрын: бэкаптар расталды, тәуелділіктер картасы өзекті, терезе келісілді, шешімге жауапты тағайындалған.
• Жаңа алаңда монтаждан кейін: қуат, желі, порттар белгіленгені, басқару консольдері мен қашықтан қатынас тексерілген, критикалық кабельдер мен модульдер орнында.
• Іске қосқаннан кейін: серверлер қатесіз көтерілді, сервистер дұрыс тәртіппен старт алды, мониторинг хосттарды көреді.
• Тексеру аяқталғаннан кейін: пайдаланушылар мен интеграциялар негізгі сценарийлерді өтеді, деректер орындарында, қателер өсімсіз.

Табыстылық критерийлерін сандармен анықтау және «норма» ретінде алдын ала бекіту жақсы. Мысалы: кідірістер базалық деңгейден 10–15%-дан артық болмауы, қолданба 5xx қателері қалыпты деңгейден жоғары болмауы, бүтіндікті тексеру (хештер, санау салыстыру, таңдамалы транзакциялар) айырмашылықсыз.

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

• Деректер бүтіндігі тексерісінде сәйкес келмеуі.
• Қателер порогынан жоғары және 10–15 минут ішінде төмендемесе.
• Негізгі тәуелділікпен (ДБ, DNS, AD) байланыс жоқ және тез айналма жол жоқ.
• Терезенің соңына дейін кері қайту лимиті қалмады.

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

Көшу кейінгі тексерулер және қабылдау

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

Алдымен инфрақұрылымның негізгі «гигиенасын» өтіңіз. Бұл жылдам тексерістер көптеген мәселелерді ұстайды: желі (VLAN, маршруттар, MTU), DNS (ішкі аттардың шешімі), домен (кіру және саясаттар), рұқсаттар (VPN, bastion, админ панельдер), мониторинг (агенттер мен алертер), журналдар (оқиғалар жинағышқа келеді ме). Егер компанияда 24/7 қолдау болса, дежурная сменаның жаңа хосттарды көріп, дұрыс идентификациялай алатынын тексеріңіз.

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

Іске қосудан кейін «пост-старт бақылауын» 2–24 сағатқа жоспарлаңыз. Инфрақұрылым және қолданба бойынша жауапты тағайындап, қандай метрикаларды қарайтыныңызды алдын ала келісіңіз.

Қабылдау формалды болуы тиіс:

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

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

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

Тіпті жақсы runbook кейде ешкім маңызды деп санамайтын ұсақ-түйектерден сәтсіздікке ұшырайды.

Жоспарды жиі бұзатындар

Мәселелер әдетте ауыр темірден емес, ұйымдастыру мен тәуелділіктерден басталады:

• Тек «негізгі» жүйелерді ескереді де, DNS, NTP, лицензиялау, бэкап агенттері, мониторинг, баспа, 1С немесе медициналық жүйелер сияқты базалық заттарды ұмытады.
• Артқа қайту критерийлерін алдын ала тіркемейді. Қателік болғанда «тағы 10 минут күтеміз» немесе «ораламыз» деп дау шығып, уақыт жоғалтады.
• Нашар белгілеу. Орнында патчкордтардың бәрі бірдей болып шығады, порттар ауысып кеткен және схема шындықпен сәйкес келмейді.
• Буферсіз жұмыс терезесі. Тексеру, прогрев, синхрондау және тұрақтандыруға уақыт қалмайды.
• Жалғыз координатор жоқ. Командалар параллель жұмыс істеп, жолда баптауларды өзгертеді, және бақылау нүктелері бақылау нүктесі болудан қалады.

Практикалық шағын мысал

Виртуализациясы бар стойканы тасымалдайды: хосттар көтерілді, ВМ-дар басталды, бірақ пайдаланушылар кіре алмай отыр. Себебі қарапайым: ескі алаңда уақыт қызметі қалған және Kerberos сағат айырмашылығынан қателіктер тудырды. Егер runbook-та «жаңа желіден NTP қолжетімді және сағат айырмашылығы X секундтан кем болу керек» пункті болса, мәселені минуттарда тауып, шешкен болар едіңіз, ал емес кезде өтініштер толып жатты.

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

Қысқа чеклист: көшуге дейін және қосқаннан кейін

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

Шығу алдында және өшіру алдында

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

• Қалпына келтіру үшін бэкаптарды тексеріңіз: кем дегенде бір тесттік restore, нәтижені және уақытын тіркеңіз.
• Байланыс және дежурлықтарды жинаңыз: қызмет иесі, желі, қуат, қауіпсіздік, тасымалдаушы, алаң бойынша жауапты.
• Рұқсаттарды растаңыз: VPN, есептік жазбалар, гипервизор/кластер рұқсаттары, iLO/iDRAC/консоль парольдері.
• Өшіруден бұрын «соңғы күй жазбасын» алыңыз: репликация статусы, тапсырмалар кезегі, диск бос көлемі, соңғы синхрондау уақыты.
• Өзгерістерді тоқытыңыз: деплойларды тоқтатыңыз, қолмен түзетулерді тыйыңыз, өзгерістер терезесін журналда тіркеңіз.

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

Қосу алдында және қосқаннан кейін дереу

Жаңа алаңда алдымен базаны тексеріңіз: қуат, желі және темірге қолжетімділік, одан кейін қолданбалар.

• Жүктеме бермей тұрып қуат пен желіні тексеріңіз: фазалар/UPS, VLAN, порт жылдамдықтары, uplink, DNS/NTP.
• Консоль және қашықтан басқаруға қолжетімділік барын тексеріңіз, бір баптау үшін стойкаға жүгіріп жүрмес үшін.
• Іске қосқаннан кейін негізгі сценарийлер бойынша критикалық сервистерді растаңыз (кіру, дерекқорға жазу, хабар кезегі), тек «пинг бар» деп емес.
• Мониторингті тексеріңіз: метрикалар, алертер, журналдау, резервтік көшіру, диск бос жері.
• Біріккен жұмыс журналы жүргізіңіз: не істелді, қашан, кім растады, не бұзылды және қандай шешім қабылданды.

Мысал: критикалық сервисі бар стойканы көшіру

Жағдай: бір стойкада екі виртуализация хосты, ортақ сақтау (немесе vSAN), файл сервис және 1С бар. Бизнес 4 сағаттық түнгі терезе береді, таңертең бәрі қалыпты жұмыс істеуі тиіс. Runbook-тың негізгі мақсаты — «ісігіп үлгеру» емес, нақты не істелетіні, қай тәртіппен және қай кезде артқа қайту шешімі қабылданады дегенге алдын ала келісу.

Тәуелділіктер картасын тым күрделі 20 блоктық схемаларсыз қарапайым сөздермен жазған дұрыс. Мысалы: 1С AD, DNS, уақыт (NTP), маршруттар, файлдық ресурстарға қолжетімділік, лицензиялау және баспаға тәуелді. Файлдық сервис AD мен желіге тәуелді. Виртуализация қуат, салқындату, uplink және басқару желісіне тәуелді.

Іске қосу тәртібі осылай бекітілуі мүмкін:

• Негізгі желіні көтеріп, негізгі подсетьтерге маршруттардың жұмысын тексеру.
• AD/DNS/NTP-ны көтеру (немесе олардың жаңа алаңда қолжетімді екенін растау).
• Сақтауды қосып, бүтіндікті/репликацияны тексеру.
• Виртуализация хосттарын қосып, ВМ-дарды іске қосу: алдымен файлдық сервис, содан соң 1С.
• Пайдаланушы қолжетімділігі мен фондық тапсырмаларды тексеру (алмасулар, регламенттер).

Процесте даудың шығуын болдырмау үшін алдын ала бақылау нүктелерін қойыңыз. Мысалы: «желі қосылғаннан кейін 10 тесттік түйінге ping және DNS-resolve бар», «файлдық сервистен үш бақылау папка ашылады және құқықтар дұрыс», «1С іске қосылғаннан кейін 5 минуттың ішінде тест базаға кіру өтеді».

Артқа қайту нақты әрекет ретінде сипатталсын: стойканы ескі алаңға қайтарып қою немесе сервистерді ескі IP/маршруттарға қайта қосу және кім бұйыратыны. Уақыт лимитін де көрсеткен пайдалы: мысалы, T+120 минутқа дейін 1С тесттерін өтпесе, артқа қайтамыз, ал физикалық қайтару үшін алаң бойынша қозғалысты ескеріп 60–90 минут қоямыз.

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

Келесі қадамдар: көшу қалай ұйымдастырып, кімге тапсыру керек

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

Негізді жинап, оны бір құжатқа (кемінде кесте) тіркеңіз, содан кейін runbook-қа айналдырыңыз:

• Инвентаризация: стойкалар, серверлер, желілік жабдық, қуат желілері, порттар, сериялық нөмірлер, өндірушілер контактілері.
• Тәуелділіктер картасы: қандай сервистер деректер базасына, DNS-қа, AD-ға, желіге, сақтауға, лицензияға тәуелді.
• Табыстылық критерийлері: соңында не жұмыс істеуі керек (метрикалар, қолжетімділіктер, RTO/RPO, тексерулер тізімі).
• Артқа қайту критерийлері: қашан артқа қайтамыз және қалай ескі алаңға ораламыз.
• Runbook жобасы және қысқа репетиция: бір тест қадам (мысалы, екінші дәрежелі сервис) уақытын және мәселелерді тіркеу.

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

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

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