Мекеме үшін резервтік сервер: екі деректер орталығысыз минималды архитектура

Ақауды нақты қандай жағдайлардан өткізу керек

Бастапқыда жағдайды нақты атаған жөн: ақау — тек «сервер өлді» деген жағдай емес. Шағын мекемеде (әдетте 5–50 жұмыс орны) бір-екі сервис бар, оларсыз жұмыс тоқтап қалады: есеп жүйесі немесе дерекқор, құжат айналымы, пошта, ортақ файл ресурсы, арнайы реестрлерге қолжетім.

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

Ақаулар белгілері бойынша ұқсас көрінуі мүмкін, бірақ салдары мүлде әр түрлі:

• Сервердің толық бұзылуы (плата, жад, контроллер) — сервистер бірден тоқтайды.
• Диск немесе сақтау жүйесінің істен шығуы — деректер болуы мүмкін, бірақ жүйе жүктелмейді.
• Қуат мәселелері (автомат сөнді, «просадка», ИБП істен шығу) — кенеттен өшіру және деректер зақымдалу қаупі.
• Қосылым жоғалту (провайдер, маршрутизатор, VPN) — сервер жұмыс істейді, бірақ оған жету мүмкін емес.
• Адам қатесі (дерекқорды жою, сәтсіз жаңарту, шифрлаушы) — шыныша құрал-жабдық бүтін, бірақ жұмыс мүмкін емес.

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

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

Минималды талаптар: RTO және RPO күрделі терминсіз

Резерв шынымен көмектессін десеңіз, алдымен темір-жабдық туралы емес, мақсаттар туралы келісіңіз: нені сақтаймыз және қанша уақыт ішінде қайта жұмысқа келтіреміз. Шағын мекемеде бұл әсіресе маңызды: бюджет шектеулі, ал ИТ-тен күту «әрдайым жұмыс істесін» дегенге келіп тіреледі.

RTO — сервис істен кейін қанша уақыт қолжетімсіз бола алады. Қарапайым: «қанша уақыт шыдай аламыз, қайта қосылсын». RPO — қанша деректі жоғалтуды қабылдайсыз. Қарапайым: «уақыт бойынша қаншаға дейін артқа шегінуге болады».

Практикалық қадам: 3–5 маңызды сервисті таңдап, бизнес тарапынан иелерін тағайындаңыз (бұлар тек ИТ емес). Мысалы: пошта, файл сақтау, 1С немесе бухгалтерия, домен және аутентификация, ведомстволық есеп жүйесі. Иелерімен нақты сандарға келісу оңайырақ болады.

Әр сервис үшін екі сұраққа жауап беріңіз:

• Максималды үзіліс (RTO): 30 минут, 4 сағат, 1 күн.
• Максималды деректер жоғалту (RPO): 15 минут, 1 сағат, 24 сағат.

Содан кейін сервистерді деңгейлерге бөліңіз. Осылайша барлығына бірдей қорғаныс салмайсыз:

• Міндетті: болмаса жұмыс тұра қалады (қысқа RTO, шағын RPO).
• Қалау бойынша: кедергі келтіреді, бірақ бірнеше сағатқа шыдауға болады.
• Күтсе болады: келесі күні қалпына келтіруге рұқсат.

Мысал: домен үшін RTO 1–2 сағат және RPO 1 сағат; файл архиві үшін RTO 1 күн және RPO 24 сағат; бухгалтерия үшін RTO 4 сағат және RPO 4 сағат (құжаттар пакетпен енгізілетін болса).

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

Резерв қай жерде орналастырылады: қасында, филиалда немесе серікте

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

Практикада көбіне үш варианттың бірі таңдалады:

• В том же здании. Қызмет көрсетуге және келісуге оңай, арзан. Негізгі сервердің апаты, жаңарту қателері және кейбір қуат мәселелерінен сақтайды (егер резерв бөлек желіде және ИБП-мен болса). Бірақ өрт, су тасқыны, ұрлық, ғимараттың толық өшіруі немесе бір шкафтағы барлық трафик сияқты жағдайлардан қорғамайды.
• Басқа ғимарат немесе филиал. Тәуекелдер бойынша жақсырақ: бөлме мен жергілікті электрмен байланысты проблемаларды және кейбір қауіпсіздік оқиғаларын аулақтауға мүмкіндік береді. Бағасы көбіне желі және әкімшілікше қамтамасыз етуде болады: тұрақты канал керек және жабдықты қызмет көрсетуге мүмкіндік болуы тиіс.
• Серіктегі орналастыру. Сенімді серіктес пен формальды негіздері болса жарайды. Ғимарат тәуекелдерін жабады және ұялырақ қауіпсіздік пен қуат шарттарын береді. Бірақ қолжетімділік, стойкаға кіру, түнгі уақытта жабдыққа жету сияқты ұйымдық мәселелер шығады.

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

Шешім қабылдамас бұрын тексеріңіз:

• ИБП-ге арналған бөлек қуат және орын бар ма;
• площадкалар арасындағы байланыс қаншалықты тұрақты және кім жауапты;
• серверге физикалық кім қол жеткізеді және бұл қалай тіркеледі;
• апат болғанда жабдыққа жету қанша уақыт алады;
• көшірмелер резервтен бөлек қайда сақталады.

Егер жергілікті түрде жабдық сатып алсаңыз (мысалы, резервтік площадкаға S200 деңгейіндегі серверлер), тек «темірді» ғана емес, орналастыру шарттарын да есепке алыңыз. Көп жағдайда осы шарттар схеманың шынайы апатты өткере алуын анықтайды.

Минималды архитектура: бір хост, виртуалды сервистер, ИБП

Егер бюджет пен орын екінші толыққанды ЦОД ұстауға мүмкіндік бермесе, ең практикалық нұсқа — виртуализация үшін бір физикалық сервер. Оның үстінде бірнеше виртуалдық машинаны алдын ала дайындап қояды, сонда негізгі түйін істен шыққанда қажетті VM-дерді тез қосып, негізгі сервистерді қайтарып алуға болады.

Виртуализацияның мәні — сіз «темірді» емес, дайын сервистерді тасималдап жатырсыз. Негізгі сервер істен шыққанда резервтегі хостта қажетті VM-дерді қосып, жұмысты жеңілдетілген режимде жалғастырасыз.

Қай VM-дерді бөлек ұстау керек

Бір функция істен шыққанда қалғандарға әсер етпеуі үшін рөлдерді VM-дерге бөліңіз. Минимум әдетте үш VM жеткілікті:

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

Егер арнайы жүйелер болса (құжат айналымы, есеп жүйесі), апатта қайсысы бірінші тұратынын алдын ала анықтаңыз.

Дискі мен қуат: жиі қателесетін екі жер

Дискілер бойынша минимум: бір диск істен шықса аман қалатын RAID және деректердің айқын бөлінуі. Практикалық тұрғыдан резервтік көшірмелерді жұмыс файлдарынан және виртуалды дискілерден бөлек томда ұстау пайдалы.

Қуат үшін міндетті түрде ИБП керек. Маңыздысы — тек «10–15 минут ұстайды» емес, ұзақ өшіру болса жүйені дұрыс аяқтауды қамтамасыз ету. ИБП сигналынан хост пен VM-дерді автоматты түрде өшіруді орнатыңыз, әйтпесе файлдар мен базалардың зақымдану қаупі жоғары.

Мысал: 40 қызметкері бар бөлім резервтік хостты офис шкафтарына қойып, 2–3 VM-ді алдын ала дайындайды. Апат кезінде алдымен домен мен файлдарды қосып алады, ал қолданбаны кейін қосады, қуат пен желінің тұрақтылығына сенгенде. Мұндай хост үшін жергілікті өндіріске және сервистік қызметке басымдық беретін GSE S200 сияқты платформаларды жиі таңдайды.

Бэкапы және көшірмелерді сақтау: шын мәнінде қалпына келу үшін

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

Жақсы негізгі схема — 3-2-1 ережесі: деректердің үш көшірмесі, екі түрлі тасымалдағышта және кемінде бір көшірме алаңнан тыс жерде. Шағын серверлік үшін бұл әдетте: локальды көшірме, съемный тасымалдағыш немесе бөлек NAS, және басқа жерде (филиал, серіктес площадка немесе қорғалған қашықтағы сақтау) тағы бір көшірме.

Бэкап жиілігін деректер түріне және жоғалту құнына сай орнатыңыз:

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

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

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

Минималды тексерулер:

• дерекқор/папкалар ашыла ма, файлдар бүлінбеген бе;
• соңғы сәтті көшірменің уақыты RPO талаптарына сай ма;
• қалпына келтіру қанша уақыт алған (RTO);
• журнал бар ма: кім бэкапті бастаған, қателер болды ма, көшірмелер қайда кеткен.

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

Желілік қолжетімділік: пайдаланушылар қалай жұмысын жалғастырады

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

Площадкалар арасында почта, құжат айналымы, файлдар мен қашықтан жұмыс үшін күнделікті трафикке төтеп беретін арна керек. Шағын мекеме үшін 100–300 Мбит/с көбіне жеткілікті, егер ауыр VDI немесе үлкен дерекқорлар тасымалданбайтын болса. Бірақ қағаздағы «мегабиттер»дан гөрі тұрақтылық маңызды: пакет жоғалтулары мен просадкалар жұмысты жылдам өлтіреді. Егер бюджет рұқсат етсе, екінші тәуелсіз арнаны (басқа провайдер немесе LTE/5G) кемінде негізгі сервистер үшін қосып қойған дұрыс.

Резерв площадкаға қолжетімдікті VPN арқылы беріп, «біреу ғана керек» принципін ұстаныңыз. Кәдімгі схема:

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

Пайдаланушылар ауыстырғанда «жаңа адрес іздемесін» десеңіз, DNS пен адресация жөнінде алдын ала ойланыңыз. Ыңғайлы шешім — қызметтердің тұрақты атаулары (мысалы, portal, mail, files), апатта тек DNS жазбасы жаңа IP-қа ауысады. TTL-ды ескеріңіз: өте үлкен TTL көшу кешігулерін береді, тым кіші TTL DNS-ке жүктеме қосады.

Басты желіде мәселе шыққанда әкімшілікке жеке қолжетімділік қалдырыңыз: жергілікті консоль, әкімшілер үшін бөлек интернет-арна немесе желі жабдығына out-of-band қолжетімділік. Бұл «қосалқы есік» апат кезінде көмектеседі.

2–6 аптада енгізу бойынша қадамдық жоспар

Жоспар қысқа және тексерілетін болуы керек. Мақсат — апатта негізгі сервистер шын мәнінде қосылып, кезекшіліктегі қызметкер үшін бәрі түсінікті болуы.

Бастапқы қадам — инвентаризация: қандай сервистер бар (AD, файл ресурстары, 1С, пошта, ведомстволық жүйе, VPN), деректер қайда сақталады және кім пайдаланады. Содан кейін приоритеттерді бекітіңіз: не бірінші көтеріледі, не күте алады және қай деректер 2–4 сағат ішінде жоғалмауы тиіс.

Келесі — «минимум» площадканы дайындау: бір хост — CPU мен RAM-да қор болуы, дисктік подсистема, ИБП, бөлек желілік порт/канал. Практикада бірден 2–3 VM шаблонын дайындап қою ыңғайлы (Windows Server, Linux, «боса» VM қосымша үшін), сонда қалпына келтіру қолмен жинауға айналмайды.

Параллельде бэкаптар орнатылады: кесте, сақтау, қалпына келтіру тексерісі. Мағынасы болса, критикалық VM немесе деректерді резервтегі хостқа репликациялаңыз, бірақ бәрін репликациялауға тырыспаңыз.

2–6 апта аралығында уақытты былай бөлсе болады:

• Апта 1: инвентаризация, приоритеттер, RTO/RPO келісімі.
• Апта 2: хост жеткізу және орнату, базалық виртуализация, VM шаблондары.
• Апта 3: бэкаптар, файл мен бір VM-дің бақылау қалпына келтіруі, қателер журналы.
• Апта 4: ауысу сценарийі (кім не істейді), контактілер, қолжетімділіктер, «15 минутта шықпаса — келесі қадам» ережесі.
• Апта 5–6 (қажет болса): тар жерлерді сынау, кезекшілерді оқыту, регламентті бекіту.

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

Шағын мекеме үшін мысал сценарий

20 қызметкері бар мекемені елестетейік. Күнделікті олар есеп жүйесінде жұмыс істейді (дерекқор), құжаттарды файл архивінде сақтайды және ПК-ға домен арқылы кіреді. Интернет бар, бірақ тұрақсыз болуы мүмкін, сондықтан тек бұлтқа сену қауіпті.

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

Екінші толық ЦОД-сыз схема былайша көрінеді: филиалда немесе басқа ғимаратта виртуализация, ИБП және бөлек дисктік сақтауы бар бір резервтік сервер. Негізгі VM-дер (есеп, домен, файлдар) осы узелге жүйелі түрде көшіріледі. Көшірмелер кестемен жасалады, ал тоқсан сайын қалпына келтіру тесті өткізіледі.

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

Операциялық тәртіп бір бетте жақсы тұрады:

• Кезекші инцидентті тіркеп, ИТ жетекшісіне хабарлайды.
• ИТ жетекшісі шешім қабылдайды: жерде қалпына келтіреміз бе немесе филиалдағы резервті қосамыз ба.
• Резервтік серверде есеп жүйесінің VM-і мен домен қосылады, сосын файл қызметі.
• Тексереді: есептік жазба арқылы кіру, дерекқор ашылады ма, тесттік құжат басып шығарылады, ортақ папкаға қол жетімді.
• Пайдаланушыларға хабарланады — жұмыс авариялық режимде жалғасуда, және RTO бойынша есепке уақыт тіркеледі.

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

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

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

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

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

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

Техникалық тұзақ тағы: бір VM-ге бәрін жинап қою — AD, пошта, файл, 1С, мониторинг. Ақау кезінде басты нәрсені тез көтеру мүмкін емес болады, өйткені бәрі «тең дәрежеде маңызды». Приоритеттер керек: не бірінші 2 сағат ішінде қосылады, не кейін күте алады.

Ақырында, қолжетімділіктер. Егер гипервизор, бэкап жүйесі және админ аккаунттардың парольдері бір адамда болса, бұл дәл бір диск сияқты single point of failure.

Қай жағдайлар қалпына келтіру жоспарын сындырады:

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

Егер интегратордан жабдық алсаңыз, мысалы GSE.kz, тек спецификация емес, 1–2 беттік қарапайым қалпына келтіру жоспарын сұраңыз. Ол көбінесе тағы бір «запас диск»тан қымбатқа тұрады.

Іске қосар алдындағы қысқа чек-лист

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

Минимум жазып алу қажет нәрселер:

• сынғыш сервистер тізімі және олардың иелері бекітілген (мысалы: домен, файл, 1С/СЭД, пошта, VPN). Әр сервис үшін деректерге кім жауап береді және қалпына келтіруден кейін «жұмыс істейді» дегенді кім растайды анық болсын.
• RTO және RPO келісілген және басшылыққа түсінікті: офис қанша уақыт «қолмен» жұмыс істей алады және ұйым қанша деректі жоғалтуды қабылдайды.

Содан кейін физикалық мүмкіндікті тексеріңіз:

• кем дегенде екі тәуелсіз дерек көшірмесі бар және біреуі негізгі площадкадан тыс жерде сақталған; «алыс жерде» — сол сервердегі басқа папка емес, бөлек құрылғы немесе сақтау орны болуы керек.
• 1–2 беттік қысқа ауыстыру нұсқасы бар: не өшіріп, не қосу, қай сервистер бірінші көтеріледі, қай жерде адрес/маршрут өзгертіледі, пайдаланушыға қолжетімдікті қалай тексеру керек. Жанында — жауаптылар контактілері: ИТ, байланыс/провайдер, қауіпсіздік және ауыстыру шешімін беретін басшы.

Және соңғысы: жобаны нақты тестсіз іске қоспаңыз.

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

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

Келесі қадамдар: схеманы жұмыс істейтін шешімге айналдыру

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

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

Шешімді қарапайым ережелермен бекіту пайдалы:

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

Содан кейін пилот жоспарлаңыз, «бәрін бірден» емес. Бір критикалық сервис таңдап, толық циклды отрепетируйте: бэкап, қалпына келтіру, резервтік хостта іске қосу, пайдаланушылардың қолжетімдігін тексеру, штаттық режимге қайтару. Маңыздысы — тек «қосылды» деген факт емес, уақыт, артық қадамдар, құқықтардың жетіспеуі немесе нұсқаулықтың кемшілігін анықтау.

Пилот нәтижесінде қуаты, ИБП сенімділігі немесе сервистік қолдаудың жетіспеушілігі анықталса, жабдық пен қолдауды таңдау кезеңіне өтіңіз. Мемлекеттік ұйымдар үшін жеткізу мен сүйемелдеудің болжамдылығы маңызды. Мұнда жергілікті өндірілген серверлер мен GSE.kz интеграциясын қарастыру орынды болуы мүмкін: компания Қазақстанда компьютерлер мен серверлер шығарады, жүйелік интеграция жасайды және сервис желісі арқылы 24/7 техникалық қолдау ұсынады.

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