DR-оркестрациясы: құралды таңдау, runbook және жаттығулар

Неліктен DR-оркестрация қажет, егер бэкаптар бар болса

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

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

Әртүрлі тәсілдер арасындағы айырмашылық қарапайым:

• Бэкап — файлдар немесе VM-ді уақыт нүктесіне қайтару, көбінесе кешігумен.
• Репликация — жүйенің көшірмесін жақын ұстап, жылдам көтерілуге мүмкіндік беру.
• DR-жоспар — жауапты тұлғалар, әрекеттер тәртібі және тексерістер көрсетілген кезең-кезеңімен ауысу сценарийі.

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

Оркестрация қажет болады, егер бірнеше критикалық сервис бар болса, қатал RTO/RPO талаптары болса, реттеу ережелері әсер етсе немесе қолмен түнгі жұмысқа мүмкіндік жоқ болса. Мысалы, егер бухгалтерия, клиент порталы және телефония бір-біріне тәуелді болса, автоматтандырылған іске қосу және тексерілетін runbookсыз тіпті жақсы бэкаптар болса да ұзақ тоқтап қаласыз.

Негізгі ұғымдар: нені қамтамасыз етеміз

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

RTO (Recovery Time Objective) — бизнес жүйенің қайта іске қосылуын қанша уақыт күте алатынын көрсетеді. RPO (Recovery Point Objective) — уақыт бойынша қанша деректі жоғалтуға болады, мысалы 5 минут немесе 4 сағат. Бұл екі көрсеткіш құралға және қандай деректер репликацияланатынына тікелей әсер етеді.

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

Қолданбалар жалғыз мақсаппен өмір сүрмейді. Типтік жиынтық: дерекқор, қолданба, хабарлар кезегі, файлдық сақтау, домен қызметтері және DNS. Бір компонентті ғана көтерсеңіз, қалғандары қате тәртіпте қосылып, тәуелділікті таба алмауы немесе деректерді бүлдіруі мүмкін. Сондықтан DR-да әр қабат үшін қосу тәртібі, тексерістер және дайындық нүктелері маңызды.

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

Көп жағдайда бірнеше рөл қатысады: ИТ (инфрақұрылым, қолданбалар, желі), қауіпсіздік (рұқсаттар, сегментация, журналдар), сервис бизнес‑қожасы (қызметтің жеткілікті жұмыс істейтінін қабылдайды) және мердігерлер/вендерлер (мысалы, СХД, гипервизор немесе резервтік ЦОД бойынша). Рөлдер алдын ала бөлінбесе, жақсы оркестрация да созылмалы телефон қоңырауына және дауға айналады.

Қайдан бастау: талаптар мен шекаралар

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

RTO және RPO‑ны барлық жүйе үшін бірдей санмен емес, топтар бойынша белгілеңіз. Почта мен файлдар әдетте биллинг немесе тіркеу жүйесінен көбірек кешігіс көтереді. «Жұмыс істейді» деген не екенін нақты айтыңыз: сайт қолжетімді, төлемдер өтіп жатыр, құжаттар басылып жатыр, негізгі қолданба ашылады.

Дизайнға кіріспес бұрын қысқа сұрақтар тізімін бекітіңіз:

• Қай 5–10 сервис бірінші қалпына келтірілуі керек және ауысуды кім шешеді.
• RTO және RPO топтар бойынша (критикалық, маңызды, қосымша).
• DR кезінде рұқсат етілген деградация (есептерсіз, аналитикасыз, тек негізгі операциялар).
• Жаттығулар терезесі және өндіріс үшін рұқсат етілген тәуекел.
• Есеп талаптары: кім, қашан және қандай түрде нәтижені растайды.

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

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

Мысал: клиника DR жоспарлайды. Регистратура мен лаборатория үшін RTO 1 сағат, RPO 15 минут; пациенттер порталы үшін 4 сағат; суреттер архиві үшін тәуліктік. Жаттығулар кварталда бір рет «қорапшада», ал жылына бір рет дежурлық смена қатысатын шынайы тексеру өткізіледі.

Шешім кластарі: Zerto, Veeam Replication және ішкі құралдар

Практикада DR-оркестрация үш санатқа сығылады: арнайы өнімдер, backup‑платформа құрамындағы репликация және гипервизор, СХД немесе бұлттың ішкі механизмдері. Әр санаттың өз тәсілі бар — таңдау атауға емес, сіздің сценариіңізге және нағыз ауыстырылатын нәрсеге сай болуға тиіс.

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

Veeam Replication көбіне Veeam бэкап үшін қолданылып жүрген жерде пайда болады — DR‑ды жақын және күрделілігі аз жолмен алғысы келетіндер үшін. Бұл типтік виртуалдық орта үшін түсінікті жол: ВМ репликациясы, жоспарлы ауысу және базалық тестілеу. Бірақ күрделі тәуелділіктерді оркестрациялау және басқару қосымша ручной қадамдарды және runbook тәртібін талап етуі мүмкін.

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

Шешімнің дайындық деңгейін мына белгілер арқылы бағалауға болады:

• Оркестрация бар ма, тек репликация емес пе.
• Тестілеуді өндірістің қауіпсіздігіне зиян келтірмей орындауға бола ма.
• Есептер бар ма: не қорғалған, не қорғалмаған, соңғы тест қашан болған.
• Өзгерістер қалай өңделеді: жаңа сервер қоссаңыз немесе желіні өзгертсеңіз не болады.
• Ваша желі, каталогтар, мониторинг және сервис‑дескпен қаншалықты оңай интеграцияланады.

Егер екі ЦОД, әртүрлі типтегі сайттар және қатал регулятор талаптары болса, әдетте тұрақты тесттер мен дәлелденетін есептерді беретін шешімге қарау логикалық. Ал егер тапсырма қарапайым (бірнеше негізгі ВМ және түсінікті іске қосу тәртібі), онда ішкі құралдар немесе Veeam жеткілікті болуы мүмкін. Интеграция жобаларында бренд емес, таңдалған құралдың сіздің желіге, сақтау жүйесіне, қолданбаларға және команданың процесіне қаншалықты сай келетіні жеңеді.

Мысал сценарий: типтік ұйым үшін DR

Екі сайт (негізгі және резерв) бар, виртуалдық инфрақұрылым, бірнеше негізгі жүйелер және әртүрлі приоритеттер бар типтік ұйымды елестетейік. Критикалық сервистер: Active Directory/DNS, пошта немесе корпоративтік коммуникация, ERP/бухгалтерия, дерекқор, қызметкерлер порталы. Қосымша: файл архивтері, тест орталар, кейбір есептер.

Мақсат прагматикалық: критикалық сервистер үшін RTO‑ға сыйып, барлық пайдаланушылар үшін үлкен тоқтату тудырмау. Сондықтан ауысу мүмкіндігінше автоматтандырылған, ал ручной әрекеттер қысқа әрі анық болуы тиіс.

Көбінесе автоматтандыру виртуалдық машиналарды ғана емес, олардың айналасын да қамтиды: іске қосу тәртібі (алғаш AD және деректер, сосын қолданбалар, ал кейін фронтендтер), резервтік сайт үшін желілік профильдер мен рұқсат ережелері, DNS жаңарту немесе жазбаларды/күндерді ауыстыруды басқару, дайындық тексерістері (порт ашықтығы, тесттік қолданушымен кіру, тест транзакция), сондай-ақ қайтару жоспарлары (failback) критерийлерімен.

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

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

Құралды таңдау: RTO және ортаға қарай қадамдар

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

Біріншіден инвентарь жинаңыз: сервиске қандай ВМ‑дер мен дерекқорлар қатысады, қандай тәуелділіктер бар (DNS, AD, балансировщик, кезектер), әр компоненттің иесі кім және тоқтау туралы шешімді кім қабылдайды. Кейбір тәжірибеде 100 ВМ емес, 10–15 бизнес‑сервис сипаттау ыңғайлы: бухгалтерия, портал, медсистема, колл‑центр.

Содан кейін қалпына келтіру топтарына бөліңіз. Топ — бірге және дұрыс тәртіппен көтерілуі тиіс компоненттер жиынтығы. Әр топқа приоритет пен мақсатты RTO/RPO қойыңыз. Мысалы: клиент порталы — RTO 30 минут, архив — RTO 24 сағат. Бұл сіздің мақсаттарыңызға сай келмейтін шешімдерді жылдам алып тастайды.

Келесі — қарапайым критерий матрицасы, әдетте бес пункт жеткілікті:

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

Содан кейін пилот қажет — бірден толық енгізбеу. 1–2 критикалық тізбекті алыңыз (мысалы, веб‑қолданба + дерекқор + AD тәуелділігі) және орындаңыз: жоспарлы тесттік ауысу, кері қайтару, қайталап тест. Уақытты сервистің қолжетімділігіне дейін өлшеп, барлық ручной қадамдарды тіркеңіз.

Ақырғы шешімді пилот нәтижесі бойынша қабылдаңыз және DR-оркестрацияның иесін тағайындаңыз (бөлім емес, нақты рөл). Ол тәуелділік схемаларын жаңартып, ортадағы өзгерістерді бақылайды және жаттығуларды жоспарлайды. Иесі жоқ болса, жақсы оркестрация уақыт өте сәйкес келмей қалады.

Runbook қалай құру керек: құрылымы мен детализация деңгейі

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

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

• Мақсаты мен шекарасы: қай сервистер қамтылған, қандай RTO және RPO қабылданады.
• Алдын ала шарттар мен тәуелділіктер: рұқсаттар, аккаунттар, DNS, желілер, сертификаттар, кілттер, лицензиялар.
• Ауысуды іске қосу триггерлері: кімде ауысуды жариялау құқығы бар және қандай жағдайда.
• Рөлдер мен контактілер: дежурный, қолданба иесі, желі инженері, ҚҚ, бизнес‑өкілі.
• Қай уақытта қызмет дайын саналады: қандай тексерістер орындалуы тиіс.

Содан кейін runbook‑ты сценарийлерге бөлу керек. Міндетті минимум — үш сценарий: ішінара ақау (бір сервис немесе кластер құлайды), толық сайттың құлауы және жоспарлы жұмыстар (тест немесе миграция). Әр сценарийдегі қадамдар нақты: не іске қосылады, қайда батырма басады, қандай параметр енгізіледі, нәтижені қалай тексереміз. "Қолданбаны тексеріңіз" деп жазудың орнына нақты жасаңыз: X бетін ашыңыз, 200 код алыңыз, тест транзакцияны орындаңыз.

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

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

Интеграциялар, оларсыз DR іске аспайды

DR-оркестрация Zerto немесе Veeam таңдаудан гөрі айналасындағы ұсақ‑тегіс нәрселерде бұзылады: желі ауыспай қалды, DNS дұрыс бағыттамады, сертификат мерзімі өткен. Бұл интеграцияларды алғашқы жаттығуға дейін ойластырып, runbook‑та бекіткен дұрыс.

Желілік және қолжетімділік

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

Алдын ала кім не өзгертетінін тексеріңіз:

• VLAN және IP‑жоспары: адрестер сақталады ма немесе өзгереді ме.
• Маршрутизация және VPN: DR режимінде маршруттар қалай бағытталады.
• Firewall және NAT: DR сегменті үшін ережелер жиынтығы, соның ішінде шығатын трафик.
• Балансировщиклар: VIP, health‑check және трафик бағыттау сценарийлері.
• Сыртқы тәуелділіктер: пошта шлюздері, мемлекеттік немесе банк интеграциялары.

Атаулар, аккаунттар және сенім

DNS пен Active Directory көбіне жасырын тәуелділікке айналады. Егер AD негізгі сайтта қалса, көптеген қолданбалар аутентификациядан өте алмайды, сервис аккаунттары басталмай қалуы мүмкін.

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

Деректер, тәртіп және мониторинг

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

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

Тұрақты жаттығулар: қауіпсіз өткізу

DR жаттығулары тек көрнекілік үшін емес. Олар оркестрация уақытты үнемдей ме, әлде сізде стресс кезінде үзіледі ме сол жерді көрсетеді.

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

• Настольды (tabletop): қадамдарды, рөлдерді, тәуелділіктерді және шешім қабылдау нүктелерін ауызша талқылау.
• Частичные: бір критикалық сервис немесе бір сайтты ауыстыру, басқасын қалдыру.
• Полные: инцидентті толық имитациялау, коммуникация және failback кіріктірілген.

Әр тест алдын‑ала қауіпсіз тереземен жоспарлансын. Өндірістік кластерлер мен СХД бар жерде тесттік желінің өндірістік желімен кесілмеуін қамтамасыз ету, әйтпесе тест пайдаланушыларға әсер етуі мүмкін.

Алдын ала тексеру минимумы: оқшаулау (бөлек VLAN/сегменттер, жабық маршруттар), тесттік аккаунттар мен кілттер продқа құқықтары жоқ болсын, сервис иелері, ҚҚ, қолдау және дежурныйлармен келісім, сондай‑ақ қандай жағдайда жүйені қайтару керек екенін нақты анықтау.

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

Жаттығудан кейін қысқа әрі нақты разбор жасаңыз: қай қадамдар қолмен істелді, қандай скрипттер істемеді, қандай тәуелділіктер ұмытылды. Содан кейін runbook‑ты жаңартыңыз. Инфрақұрылым өзгерсе (жаңа сервер, firewall ережесі, қолданба нұсқасы), бұл өзгеріс қадамдар мен тексерістерге енгізілуі тиіс.

Ауыстыру және жаттығулар алдындағы тез чеклист

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

Адамдар мен ақпаратты дайындаңыз

30–60 минут бұрын келесі пункттерді тексеріңіз:

• Инвентарьды салыстырыңыз: қандай сервистер қатысады, қайда орналасқан, бизнес пен ИТ иесі кім. Егер иесі белгісіз болса, приоритеттер ілгерілемейді.
• Қалпына келтіру топтары сервер атаулары бойынша емес, бизнес‑функция бойынша анықталғанына көз жеткізіңіз (мысалы, "төлем қабылдау", "электрондық пошта") және тәуелділіктер белгіленген.
• Авариялық командаға қолжетімдіктерді тексеріңіз: аккаунттар, MFA, виртуализация мен сақтау жүйелеріндегі құқықтар, желілік құрылғылар. Дежурлар мен мердігерлер контактілері өзекті болсын.
• Нақты не істелетінін тіркеңіз: тест па, әлде нақты ауысу. Жаттығыларда тесттік сегмент продпен IP, DNS, маршрутизация және пошта домендері бойынша қиылыспау керек.
• Есеп пен метрикалар шаблонын даярлаңыз: жоспарланған және фактический RTO, қадамдар, кешігулер, істен шыққандар, шешім қабылдаған тұлға. Кімге және қашан есеп жіберілетіні көрсетілсін.

Соңғы тез бақылау

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

DR-да жиі жасалатын қателіктер

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

Екінші қате — тәуелділіктерді елемеу. Темір мен ВМ көтерілгенімен, DNS, Active Directory, маршрутизация, лицензияларға қолжетімсіздік немесе кілттер мен сертификаттардың болмауы сияқты «жұқа» мәселелер сервис жұмысын бұзуы мүмкін. Мысалы, филиалдар жаңа сайтты көреді, бірақ пайдаланушылар кіре алмайды, себебі домен контроллері дұрыс сетьте болмаған немесе DNS жазбалар жаңармаған.

Үшінші тәуекел — кері қайтару жоспарының болмауы. Апат кезінде барлығы failover туралы ойлайды, бірақ кейін қалай қауіпсіз қайту керек деген сұрақ туындайды. Failback алдын ала ойланбаса, деректер түсіп қалу немесе ұзақ тоқтап қалу қаупі бар.

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

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

Кішкентай тексеріс жаттығудан бұрын:

• Runbook иесі және дежурлық ролдер тағайындалған.
• Тәуелділіктер (DNS, AD, маршруттар, сертификаттар, лицензиялар) сипатталған.
• Әрекетті тоқтату критерийлері бар кері қайтару жоспары бар.
• Тест оқшауланған контурда немесе нақты шектеулермен өткізіледі.
• Жаттығудан кейін түзетулер мен олардың енгізілу мерзімі тіркеледі.

Келесі қадамдар: 30–60 күнге жоспар және кімге жүктеу

Алғашқы 30 күнге жоспар

Бастапқыда бүкіл ЦОД‑ты емес, минимумнан бастаңыз: 5–10 ең маңызды сервис таңдаңыз және 1–2 тәуелділік тізбегінде бірінші пилотты жинаңыз (мысалы, AD/DNS + файл сервис немесе дерекқор + қолданба). Пилот желі, құқықтар, іске қосу тәртібі немесе қарапайым байланыстардағы тар жерлерді жылдам көрсетеді.

Пилотта жетістік критерийін бекітіңіз: пилотта қандай RTO керек, бүтіндікті қалай тексересіз және нәтижені кім бекітеді.

Алғашқы айдың жұмысы әдетте мыналардан тұрады:

• Инвентаризация: сервистер, иелері, тәуелділіктер және мақсатты RTO/RPO тізімі.
• Оркестрация құралының таңдауы мен жоспар бекітуі: енгізу, оқыту, қолдау.
• Пилоттық тізбектер үшін runbook жобасын жазу және коммуникация тәртібін келісу.
• Минималды DR‑площадка дайындау: есептеу ресурстары, желі, сақтау, қолжетімділіктер, мониторинг.
• Бірінші қауіпсіз режимдегі тест және қысқа есеп.

60 күнге жоспар

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

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

Кімге жүктеу: DR‑бағдарламасының иесі (әдетте ИТ‑операциялар), инфрақұрылымға жауапты тұлға, негізгі қолданба иелері, қауіпсіздік бөлімі (рұқсаттар мен журнал жүргізу) және сервис‑деск (коммуникациялар және уақытты тіркеу).

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