Open source виртуализациясы мемлекеттік ұйымға: ТЗ және қабылдау

ТЗ-де әдетте не ұмытылады және қабылдау неліктен сәтсіз болады

Виртуализация жобаларын мемлекеттік ұйымдарға open source негізде тапсыру кезінде қабылдаудың ең жиі бұзылуы — талаптардың анық еместігі. ТЗ-де «отказоустойчивость қамтамасыз ету» немесе «қолайлы басқару» деп жазылса, әркім оны әртүрлі түсінеді. Нәтижесінде мердігер жұмысты аяқталған деп санайды, ал тапсырыс беруші басқа нәрсені күткенін дәлелдей алмайды.

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

Қабылдау әділ және қайталанатын болу үшін алдын ала қандай нәрселерді құжаттап растайтыныңыз туралы келісіңіз. Әдетте бұл үш блок болады:

• Функционалдық: ВМ толық өмірлік циклі (жасау, клондау, миграция, снимоктар, жою).
• Төзімділік: қандай қателерге төтеп беру керек және қызметті қандай уақытта қалпына келтіресіз.
• Басқарылғыштық: кім және қалай әкімшілік етеді, қандай есептіліктер, журналдар, хабарландырулар бар.

Логика қарапайым: ТЗ өлшенетін талаптар қояды, олардың негізінде ПМИ жазылады (немесе қалай тексерілетіні), кейін нәтижелер бойынша сынақ протоколы мен қабылдау акты толтырылады. Егер ТЗ-де сандар мен сценарийлер болмаса, ПМИ «көзбен тексерілді» дегенге айналады, ал акт даулы құжатқа ұқсайды.

Түбі бір типтік қате: қабылдауда 5 ВМ іске қосылған, ал аптадан кейін хост құлаған кезде ВМ-дер автоматты түрде көтерілмейтіні анықталды. «HA» еш жерде уақыт критерийлерімен тексерілетін сценарий ретінде жазылмаған болып шығады.

Тапсырыс берушінің бастапқы талаптары — нені тіркеу қажет

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

Бірінші тіркеуге тұрарлық нәрсе — сервистердің критикалық деңгейлері мен тұтыну мен деректер жоғалтудың өлшенетін көрсеткіштері. RTO және RPO-ны жүйе топтары бойынша көрсетіңіз, «кластер бойынша орташа» деп жазбаңыз. Мысалы: ведомстволық пошта үшін RTO — 1 сағат, тест стендтер үшін RTO — 24 сағат; дерекқорлар үшін RPO — 15 минут, файл архиві үшін RPO — 24 сағат. Осылай ПМИ дәл сол талаптарды тексере алады.

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

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

Қабылдауда дау туғызбау үшін ТЗ-да әдетте жетіспейтін пункттер:

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

Бұл апталар бойы келісу уақытын үнемдейді және сынақтарды әділ етеді.

Шешім құрамасы және жеткізу шекаралары: ТЗ-да нені жазу керек

Қабылдау «бұл кірді ме» немесе «бұл бөлек» деген дауға айналмасын десеңіз, шешім құрамын және нақты не жеткізіледі екендігін алдын ала бекітіңіз.

Компоненттер тізімін атаулармен емес, рөлдермен сипаттау дұрыс: әдетте жеткілікті:

• Виртуализация қабаты (гипервизор) және орнатудың қолдайтын нұсқалары.
• Басқару жүйесі (консоль, API, рөлдер бойынша қолжетімділік).
• Узелдегі қызметтер және қосымша инфраструктура (мониторинг, журналдар, жаңарту репозиторийлері).
• Мердігер баптайтын желі және сақтау компоненттері (виртуалдық желілер, драйверлер, multipath және т.б.).
• Жауапкершілік шекаралары: мердігер не істейді, тапсырыс берушінің ИТ-қызметі неге жауапты.

Содан соң түйіндердің минималды сипаттамаларын және сәйкестігін көрсетіңіз: CPU, RAM, жүйе мен ВМ-дегі дискілер, порттар саны, 10G/25G талаптары, қолдайтын контроллерлер мен желі карталары. Бұл серверлік базаға (мысалы, GSE S200 Series сияқты реттік серверлерге) байланған кезде өте маңызды: ТЗ-да қабылдауды «жылдам болуы керек» дегеннен гөрі өлшенетін сипаттамаларға байлаңыз.

Кластер туралы жеке тармақ: түйіндер саны, ақау домендері (стойка, қуат, коммутатор), резервтеу схемасы және «кворум» қандай жағдайда саналады.

Open source шешімдерде де жиі аралас компоненттер болады (прошивка, драйверлер, басқару ОС, СУБД, бэкап). ТЗ-да кім және қалай лицензияларды, кілттерді, репозиторийлерге қолжетімділікті алады және қабылдаудан кейін тапсырыс берушіге не қалады — бәрін нақты көрсетіңіз.

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

Функционалдық талаптар: негізгі операциялар және ВМ өмірлік циклі

Функционалдықты тексерілетін әрекеттер ретінде және нәтижесімен сипаттаған жөн. Әртүрлі дистрибутивтер мен панельдер функцияларды әртүрлі атауы мүмкін, сондықтан нәтиженің өзіне тексеру қажет.

ВМ өмірлік циклін шаблоннан жоюға дейін бекітіңіз. ТЗ-де қандай рөлдер ВМ жасай алады, қандай шаблондардан, әдепкі параметрлер (CPU, RAM, диск, желі) және сәтті операцияның не екені көрсетілуі тиіс.

Сынақтарда өткізуге тұрарлық минималды операциялар:

• Берілген параметрлермен шаблоннан ВМ жасау және ОС-тың іске қосылуын тексеру.
• ВМ-ді клондау (толық және шаблоннан) — атау/ID бірегейлігін және желі баптауларын бақылау.
• ВМ-ді түйіндер арасында миграциялау — үзіліссіз немесе рұқсат етілген үзіліспен (секундтарда).
• ВМ-ді жою: тек ВМ немесе ВМ мен дискілерді бірге жою, ресурстардың босатылғанын растау.
• Снимоктар: жасау, орау, жою және шектеулер (максималды снимоктар саны және сақтау мерзімі), чтобы снимоктар шексіз өспесін.

Ресурс пулдары мен квоталарды (мысалы, бөлімшелер бойынша) бөлек рәсімдеңіз. Қабылдауда бұл оңай тексеріледі: CPU/RAM/диск бойынша квотаны асырауға тырысып, дұрыс қателік пайда болуын тіркеу.

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

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

Желі және сақтау: тесттер пайдалы болуы үшін қажет талаптар

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

Алдымен трафик ағындарын бөліңіз. Кластерде әдетте бөлек контурлар қажет: басқару (management), ВМ трафигі (VM traffic), сақтау (storage) және резерв (репликация/бэкап). Қай жерде физикалық бөліну міндетті (бөлінген порттар немесе адаптер), қай жерде логикалық (VLAN) жеткілікті екенін көрсетіңіз. Площадкадағы желілер арасындағы ережелерді жазыңыз: қай VLAN-дар байланыса алады, қандай бақылау құралдары арқылы (ACL немесе брандмауэр), гипервизор, сақтау, бэкап және мониторинг үшін қандай порттар ашылуы тиіс.

Сынақтар қайталанатын болуы үшін ТЗ-ға минимум артефактілер қосыңыз:

• VLAN кестесі және сегменттердің тағайындалуы (management/storage/VM/резерв).
• Қосылу картасы: сервер порты — коммутатор порты — жылдамдық — режим (LACP, trunk/access).
• MTU, QoS талаптары (қажет болса) және көпарналық талаптар (bonding, multipath).
• Сақтаудың түрі (локальды, SAN, SDS) және жауапкершілік шегіне не кіретіні.
• Мақсатты көрсеткіштер: типтік жүктеме үшін IOPS, латенттік және өткізу қабілеті.

ПМИ-да өнімділік тестінің әдістемесін жекелеп сипаттаңыз: жүктеме профилі (мысалы, 70/30 оқу/жазу, 4K және 64K блоктар), прогрев ұзақтығы, құрал, ВМ саны және «нақты өмірдегі» сценарий (бірнеше қосымша серверлері мен бір ВМ-де дерекқор). Нәтижелер протоколда тіркелсін: өлшенген латенттік және бір жолдың (линк, контроллер, түйін) сәтсіздігі кезіндегі құлдыраулар.

Төзімділік: HA-ны қалай сипаттап, оны нақты қалай тексеру керек

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

Қандай қателер тексерілетінін бекітіңіз: есептеу түйінінің құлауы, диск немесе пулдың істен шығуы, желілік линктің үзілуі, басқару компонентінің (API, планировщик, веб-консоль) сәтсіздігі, сондай-ақ архитектурада болса дерекқордың немесе кворумның қолжетімсіздігі. Әр сценарий үшін ТЗ-де күтілетін жүйелік әрекеттер және рұқсат етілген уақыт шектер көрсетілуі тиіс.

Күтілетін мінез-құлықты қалай сипаттау керек

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

Қалай нақты тексеруге болады

ПМИ-да тесттерді және протоколға не жазылатынын көрсетіңіз. Ведомстволық кластер үшін тұрмыстық тексерістер әдетте келесі қатаң сынақтардан тұрады:

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

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

Бэкап және апатты қалпына келтіру: қабылдау критерийлері

Көбінесе бэкап бір жолмен жазылады, ал қабылдауда көшірмелер бар екенімен олардан қалпына келтіру мүмкін еместігі анықталады. ТЗ-де бірден нені резервтеу керектігін (гипервизор мен кластер конфигурациясы, ВМ, дискілер, снимоктар, шаблондар, метадеректер), көшірмелердің физикалық қайда сақталатынын және кімнің қолы бар екенін бекітіңіз.

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

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

DR үшін площадкалар арасында ең алдымен қай сервистер тұруы тиіс екенін бекітіңіз (мысалы: DNS/AD немесе басқа каталог, NTP, мониторинг жүйесі, прокси/шлюз, 1–2 негізгі қолданбалы сервис). Егер екінші площадка жоқ болса, баламалы сценарий: сол ЦОД ішіндегі альтернативті кластерге қалпына келтіру.

Қабылдау критерийлерін формальды түрде былай қою ыңғайлы:

• N ВМ бэкаптан T уақыт ішінде қалпына келтірілді (қызметтің жұмыс істеуі расталғанмен).
• ТЗ-да көрсетілген RPO және RTO әр критикалдық топ үшін орындалды.
• Көшірмелер өндіргіш деректерден бөлек сақталады және шифрланған.
• Қалпына келтіру нұсқаулық бойынша орындалды, қадамдар қайталанады.
• Қалпына келтіруді тұрақты түрде тестілеу регламенті бекітілген (мысалы, тоқсан сайын) және нәтижелері протоколда тіркеледі.

Қауіпсіздік және аудит: ТЗ-ға және сынақтарға нені қосу керек

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

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

Әрекеттер журналдарын бөлек нәтиже ретінде сипаттаңыз: қандай оқиғалар жазылады (кіру, ВМ өзгерістері, желі, сақтау, құқықтар), формат, сақтау мерзімі (мысалы, кемінде 1 жыл), уақытты синхрондау (NTP), сыртқы оқиғалар есебіне экспорт және журналдардың жалпы рөлдермен жойылуына қарсы қорғаныс.

Қолжетімділік талаптары: каталогпен интеграция, пароль саясаты, құпия сөз қателесу кезінде құлыптау, артықшылықты әрекеттерге MFA. Басқару мен API үшін — шифрлау (TLS), сертификат талаптары және оларды жаңарту тәртібі.

Қабылдауда тексеруге пайдалы пункттер:

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

Басқарылғыштық және эксплуатация: уақыт үнемдейтін талаптар

Функционалдық тесттер өткен болса да, қабылдау жиі эксплуатацияда сәтсіз болады: метрикалар жоқ, ескертпелер дежурға жетпейді, жаңартулар «түнде қолмен» жасалады. ТЗ-де жай «панель болуы керек» емес, жұмыс ережелерін және оларды қалай тексеруге болатынын жазыңыз.

Мониторингте не жиналатынын және қанша уақыт сақталатынын сипаттаңыз. Міндетті минимум:

• Түйіндер мен ВМ-дердің CPU және RAM жүктемесі, oversubscription-ты қоса алғанда.
• Сақтау күйі: латенттік, IOPS, толымдылық, сыйымдылық болжамы.
• Желінің жағдайы: жоғалтулар, кешігулер, порт қателері, арналарының жүктемесі.
• Кластер оқиғалары: миграциялар, сервис құлаулары, деградациялар.
• Тенденциялар мен айлық/тоқсандық есептер (мысалы, 30–90 күн).

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

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

Қабылдау критерийлерін регламентті операциялар мен орындалу уақыты арқылы қою ыңғайлы:

• Шаблоннан ВМ жасап іске қосу — N минутқа дейін.
• Снимок жасап орау — N минутқа дейін.
• Диск қосып ФС ұлғайту — N минутқа дейін.
• ВМ миграция жасау (үзіліссіз) — N минутқа дейін.
• Емкость және инциденттер бойынша айлық есеп беру — N минутта дайын.

Әкімшілерді оқыту және тіркеу уақыты туралы бөлек тармақ қосыңыз: бұл болмаса жақсы шешім бір адамға тәуелді болады.

Қадамдар бойынша: ПМИ-ні қалай құру керек

ПМИ әрбір ТЗ тармағын өлшенетін тестке айналдыру үшін қажет: не істейміз, немен растаймыз, қандай нәтиже «сәйкес» саналады. Анық дәлелдерсіз қабылдау оңай дау болады.

Талдауды сәйкестік кестесінен бастаңыз: ТЗ талабы — тест сценарийі — өту критерийі — артефактілер. Содан кейін ПМИ-ді қадам-қадам орындауға және сол стендте қайталауға болатын етіп құрыңыз.

ПМИ-ның негізгі құрылымы

Әдетте бес блок жеткілікті:

• Стенд құрамасы мен шекаралары: түйіндер, желі, СХД, ПО нұсқалары, рөлдер, сынаққа кіретін және кірмейтіндер.
• Шығыс деректері: ВМ шаблондары, тест есептері, жүктеме профилдері, «эталон» баптаулар.
• Сынақ қадамдары: оператордың нақты әрекеттері, екіұдайдықсыз.
• Күтілетін нәтиже: нақты мәндер (ауысу уақыты, кластер статусы, миграцияның сәтті болуы, журналда оқиға пайда болуы).
• Нәтижені тіркеу: дәлелдер қайда және қалай сақталатыны, кім қол қоятыны.

«Жұмыс істейтінін тексеріңіз» деген формулировкалардан аулақ болыңыз. Оның орнына: «шаблон X-тен ВМ жаса, іске қос, IP ал, кіріп шығып, уақытты тірке, журналда Y оқиға сақтау» сияқты нақты әрекеттер жазыңыз.

Нәтижелерді не арқылы растаймыз

Комиссия үшін алдын ала келісілген артефактілер тізімін анықтаңыз:

• Негізгі экрандардың скриншоттары (статустар, қателер, нұсқалар).
• Кластер мен желінің конфигурациясының шығару файлы.
• Сервис журналдары мен аудит жазбалары.
• Тест кезеңіндегі метрикалар (CPU/RAM/IOPS/латенттік).
• Оператор әрекеттерінің уақыты мен командалар протоколы.

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

ТЗ мен қабылдау протоколындағы жиі кездесетін қателер

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

Кейін қымбатқа түсетін қателер:

• Метрикаларсыз талаптар: қолжетімділік, қалпына келу уақыты, ең үлкен үзіліс, рұқсат етілген деректер жоғалту бойынша сандар жоқ.
• Деңгейлердің араластыруы: бір бөлімде виртуализация платформасына және ведомстволық қосымшаларға қойылатын талаптар араласып кетеді. Нәтижесінде комиссия не тексеретінін нақтыламайды.
• «Функционалды тексердік — бәрі жақсы»: ВМ іске қосылып, миграцияланып кетсе де түйін, желі және сақтау ақауларын тексермейді, қалпына келтіру критерийлерін тіркемейді.
• Рөлдер мен құқықтар жазылмаған: кім ВМ жасайды, кім желіні өзгертеді, кім журналды қарайды, кім өзгерістерді бекітеді — анық емес.
• Жаңартулар сыртта қалған: патчтарды орнату тәртібі, жұмыс терезелері, откат жоспары және үйлесімділікті тексеру жоқ.

Осыдан сақтану үшін ПМИ-ға міндетті сценарийлер енгізіңіз: хосттың сәтсіздігін имитациялау және ВМ-нің автоматты іске қосылуы, бэкаптан қалпына келтіру, әрекеттер журналын тексеру және откатпен жаңарту тесті. Жүйелік интеграция жобаларында мұндай сценарийлер алдын ала келісілген жағдайда қабылдау «демонстрация» емес, нақты нәтиже болып қабылданады. Мысалы, GSE.kz-та мұндай тексерістер жұмыс басталардан бұрын тіркеледі, сонда комиссия қабылдауды дау емес, факт ретінде қабылдайды.

ТЗ мен қабылдауға дейінгі қысқа чек‑тізім

Алдын ала не «жұмыс істейді» есептелетіні және оны қалай дәлелдеу керектігін келісіңіз. Төмендегі чеклист құжаттар мен тесттердегі олқылықтарды тез табуға көмектеседі.

ТЗ-ні келісер алдында

ТЗ-де өлшенетін талаптар мен жеткізу шекараларының болуы:

• Шешім құрамы мен шекарасы: не кіреді (хосттар, желі, сақтау, ПО, қолдау), не кірмейді.
• ВМ өмірлік циклінің функциялары: жасау, іске қосу, тоқтату, миграция, клондау/шаблондар, снимоктар, жою.
• Метрикалар мен праговтар: қуаттылық (ВМ, vCPU, RAM, сақтау), мақсатты өнімділік көрсеткіштері, RTO/RPO және рұқсат етілген тоқтау уақыты.
• Қауіпсіздік және аудит: рөлдер, минималды құқықтар, әкімшілер әрекеттерінің журналдануы, журналдарды сақтау және экспорт талаптары.
• Қабылдау құжаттары: ПМИ, протокол форматы, актуға қосылатын артефактілер тізімі (конфигтер, журналдар, есептер).

Әр тармақ «тексерілетін» түрде жазылуы тиіс: тест, күтілетін нәтиже және «өтті/соқ» критерийі.

Қабылдау актісін қол қою алдында

Қабылдауда тек «жүгіру» емес, «басқару» тексерілсін:

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

Егер қандай да бір тармақ құжатпен немесе қайталанатын тестпен расталмаса, оны қол қоюдан бұрын түзеткен жөн.

Ведомстволық кластерге арналған шынайы қабылдау мысалы

Сынақтың бастапқы шарттары осылайша сипатталуы мүмкін: 4 түйінді кластер (3 жұмысшы + 1 кворум немесе резерв), 30 виртуалды машина. Олардың 10-ы критикалы (есеп жүйелері, каталог, пошта), 15-і орташа (веб‑қызметтер, ішкі есептер) және 5 тесттік. ТЗ-де алдын ала қай ВМ қателіксіз қалуы тиіс, қайсысы қысқа үзіліске жол береді — бекітіңіз.

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

• Жұмыс жүктемесі бар кезде ВМ-ді түйіндер арасында тірі миграциялау: байланыс үзілмей, миграцияның орташа уақыты келісілген шекке сәйкес болуы.
• Бір түйіннің құлауы (қуатты өшіру): критикалы ВМ-дер автоматты түрде басқа түйіндерде көтерілуі, әр ВМ үшін тоқтау X минуттан аспауы, оқиғалар журналда және хабарламаларда тіркелуі.
• Бэкаптан ВМ қалпына келтіру: нұсқаулық бойынша қалпына келтіру орындалады, сервис бақылау сынақтарынан өтеді, нақты RTO және RPO ТЗ-дағыдан нашар болмайды.
• Рольдік қолжетімділік және аудит: админ, оператор және аудитор әртүрлі құқықтарға ие, тыйым салынған әрекеттер бұғатталады, конфигурация өзгерістері журналға түседі.

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

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

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

Осы жобалардағы басты қауіп — пилот пен қабылдаудың эксплуатациядан бөлек өмір сүруі. ТЗ мен ПМИ жобасының алғашқы нұсқасынан кейін қысқа, бірақ шынайы пилот стендінде тексеріс жасаңыз.

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

Соңғы қарапайым жоспар:

• Пилотты орналастырыңыз (2–3 түйін де жеткілікті) және ПМИ-ны негізгі партияны сатып алмас бұрын жүргізіңіз.
• Минималды метрикаларды келісіңіз: ВМ жасау уақыты, критикалды сервис үшін RTO/RPO, түйін сәтсіздігіндегі ауысу уақыты.
• Ақау тесттерінің жиынтығын бекітіңіз: хостты өшіру, желіні үзу, сақтау деградациясы, басқарудың жоғалуы.
• Құжаттар пакетін дайындаңыз: эксплуатациялық регламент, рөлдер матрицасы, жаңарту жоспары, аудитке арналған есеп шаблондары.
• Оқыту жоспарын жасаңыз: әкімшілер, дежурлық команда, ИБ және «02:00-де не істеу керек» қысқа сценарий.

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