HPE SimpliVity 380 өңірлік площадкаларға: узелдерді таңдау

Неліктен өңірлік офистерге HCI қажет және қандай міндеттерді шешеді

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

Филиал үшін HCI-ды таңдайтын басты себеп — компоненттер мен сәтсіздік нүктелерінің азаюы. «Серверлер + SAN + бөлек контроллерлер» байланысының орнына есептеу мен сақтау бірге жұмыс істейтін узелдер кластерін аласыз. Басқару қарапайым операцияларға түседі: узел қосу, пулды кеңейту, ВМ-ды көшіру, жоспарлы микропрограммаларды жаңарту.

Практикада HPE SimpliVity 380 өңірлік площадкаларда күнделікті «тұрақты жұмыс» болуы тиіс негізгі міндеттерді жабады: инфрақұрылымдық ВМ (AD/DNS, басып шығару, мониторинг, локалдық қолданбалар), файлдық сервис пен құжат алмасу, шағын топтарға арналған VDI немесе терминалдық орындар, сондай-ақ болжамды жүктемелі шағын дерекқорлар мен есеп жүйелері.

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

Мысал: филиалда 2–3 критикалық сервис пен ондаған қосалқы ВМ бар. Оларды HCI кластеріне біріктіріп, түсінікті отказоустойчивость схемасын жасаумен сіз «барлығын құлататын» бір нүктеден тәуекелді азайтасыз және қолдауды оңайлатасыз, тіпті жергілікті мықты инженер болмаса да.

Конфигурация таңдауға дейін қажетті бастапқы деректерді жинау

HPE SimpliVity 380 таңдамас бұрын ағымдағы жүктемелер туралы нақты фактілерді жинаңыз. Олай істемесеңіз, «біршама үлкенірек алып қоюға» немесе, керісінше, пиктерді дұрыс есептемей ресурстар тапшылығына тап болуға болады.

ВМ тізімінен бастаңыз. Әр ВМ үшін рөлін (AD, файлдық, 1С, VDI, бейнебақылау және т.б.), ОС, сервис иесін және критикалдылығын белгілеңіз. Бөлекте түрде тоқтату терезесін және тәуелділіктерді жазып қойыңыз: не бірінші рет жүктелуі керек, қай ВМ-дар бір-бірімен сөйлеседі, қай сервистер сыртқы каналға тәуелді.

Сосын нақты ресурстарды тұтынуды жинаңыз, «выделено» емес. Қажет: CPU өлшемдері (орташа және пиктер), RAM (жұмыс жиынтығы, пиктердегі өсу), диск (бос орын, күн/апта бойынша өсім, IOPS және кешігулер), желі (пик трафик, жиі қиындықтар). Көбіне 2–4 апталық мониторинг жеткілікті. Егер маусымдық өзгеріс бар болса, ауыр кезеңді қамтыңыз.

12–36 айға болжамды есептеп қойыңыз: жаңа сервистер, штаттың өсуі, бейнебақылау жобалары, дерекқорлардың ұлғаюы. Тіпті жуық есеп те орынды қор қалдыруға көмектеседі.

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

Орын орналастыру шарттарын да тексеріңіз:

• стойкаға қолжетімділік және физикалық қауіпсіздік
• электрмен жабдықтау және резерв (ИБП, енгізулер)
• салқындату және бөлме температурасы
• рұқсат етілген шу деңгейі
• қызмет көрсету шектеулері (кім және қаншалықты тез бара алады)

Мысал: филиалда 25 ВМ бар, оның 6-сы критикалық (AD, файлдық, есеп жүйесі, басып шығару, VPN). Есеп жүйесі айдың соңында диск бойынша пик береді және тоқтату терезелері тек түнде. Бұл CPU/RAM қорын және диск пен отказоустойчивость талаптарын бірден өзгертеді.

Узелдер саны және N+1 қоры: базалық тәсіл

Өңірлік площадкада екі негізгі сұрақ: пилотқа қанша узел және продакшнға қанша қажет. HCI үшін минималды «жұмыс істейтін» конфигурация көбіне бір узелдің өшуін көтеретін кластерден басталады. Сондықтан базалық нұсқа — N+1 қағидасы: маңызды ресурстар бір узел өшкенде де қолжетімді болуы тиіс.

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

• тұрақты жүктемелер (AD/DNS, файлдық сервистер, 1С, терминалдар)
• пиктік жүктемелер (ай соңындағы есептер, резервтік көшірулер)
• кешігулерге сезімтал (VDI, дауыс, кейбір дерекқорлар)
• RAM бойынша ауырлар (in-memory, үлкен кэштер, аналитика)
• қызметтік (мониторинг, жаңартулар, тесттік ВМ)

Кейінгі логика қарапайым: тұрақты және критикалық ВМ-дардың CPU/RAM/диск тұтынуын қосасыз, реалистік пик қосасыз және N+1 қалдырасыз. Мысалы, үш узелдік кластерде бір узел жоғалғанда қалған екі узелде міндетті жүктеме сыйып кетуі тиіс.

Қай жерде CPU жиілігі маңызды, ал қай жерде ядролар саны — бұл ВМ мінез-құлқына байланысты. Жиілік жауап уақыты маңызды сервистерде, ал ядролар саны — көп параллельді тасқындама бар жүйелерде.

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

Мысал: 35 ВМ бар филиал үшін пилотқа минимум узелдер алып, миграция мен бір узелдің сөнуін тестілеу қажет. Продакшнда RAM пен диск бойынша N+1 қалдырады, өйткені филиалдарда көбіне жад пен дисктің шектеулері кездеседі.

CPU таңдау сценарийі: ядролар мен жиілікті қалай дұрыс таңдау

HPE SimpliVity 380 үшін CPU таңдау көбіне нақты ВМ пиктеріне байланысты. Ағымдағы метрикаларды орташа және пик бойынша бөліп қарастырыңыз және қай кезеңде қолданушылар баяулайды соны анықтаңыз.

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

Қате жібермеу үшін тексеріңіз:

• хосттарда немесе жеке ВМ-да жұмыстық уақыттағы 70–80%-дан жоғары тұрақты пиктер бар ма
• қандай да бір қолданба бір ядроға шектелген бе (ондайда жиілік маңызды)
• ВМ-лар CPU Ready немесе процессор күту белгілеріне жиі тап болып жүр ме
• гипервизор және кластер қызметтік компоненттері қанша резерв жейді

Мысал: 35–45 ВМ бар офис, орташа CPU жүктемесі 25–35%, бірақ таңғы 10:00 және 16:00-де есептер мен антивирустық тексерулер себебінен 75%-ға дейін пик бар. Бұл жағдайда ядролар санын көбейту көмектесуі мүмкін. Бірақ егер басты «тормоз» біржіпалы процесс болса, жоғары жиілікті CPU және фондық тапсырмаларды кестеге қою тиімдірек.

Өсу саясатын алдын ала келісіңіз: жыл ішінде +20% пайдаланушылар болса, узел қосасыз ба немесе CPU қуаты жоғары модельге ауыстырасыз ба — бұл сатып алу алдында бекітілгені жақсы.

RAM таңдау сценарийі: пиктер, қор және ауыр ВМ шектеулері

HCI-де жад көбіне CPU мен дисктен бұрын таусылады, әсіресе филиалдарда «сақтық үшін көп» ұстанатындар көп. HPE SimpliVity 380 үшін орташа емес, пиктерге сүйенген дұрыс — олар күндізгі жұмыс пен бір узелдің өшуін қаншалықты көтеретінін анықтайды.

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

«Ауыр» ВМ-ларды бөліп алыңыз: үлкен кэшті дерекқорлар, жадқа тәуелді қосымшалар, жоғары VDI тығыздығы. Олар үшін оверсабскрайб қолдану орынсыз немесе қатаң шектеу керек.

Қарапайым ережелер:

• N+1 қорын есептеңіз: бір узел жоғалғанда жад жеткілікті болуы тиіс, ВМ-дар свопқа түспеуі керек
• критикалық ВМ-да RAM-ды оверсабскрайб қолданбаңыз немесе қатты шектеңіз
• некритикалық сервистерге үмерлі оверсабскрайб рұқсат етіңіз, бірақ пиковер мониторингпен
• 12–18 айға өсуге лимит қойыңыз
• резервтеу мен лимиттерді тексеріңіз: олар нақты суретті бұрмалауы мүмкін

NUMA мәселесін де ескеріңіз: үлкен ВМ-ды екі NUMA доменіне шашыратып қою өнімділікті түсіруі мүмкін. Практикада ауыр ВМ жадты бір NUMA доменінде ұстайтындай етіп конфигурациялау ұсынылады.

Мысал: 35 ВМ бар филиалда орташа 5–6 ГБ жад қолданылса да, 6 ВМ дерекқорлары мен есептер 32–48 ГБ дейін пик береді. Орташа бойынша есептесеңіз бәрі өтеді, бірақ пик пен N+1 есептелгенде бір узелдің өшуі кезінде своп басталып, қолданушылар тоқтаусыз баяулайды.

Диск таңдау: сыйымдылық пен өнімділік қарапайым тәсілмен

Филиалдарда диск жиі тосыннан мәселе береді: құжат бойынша орын жеткілікті, ал шын мәнінде кешігулер мен күтпеген өсім кедергі болады. HPE SimpliVity 380 үшін метрикаларға және нақты қорға сүйенген дұрыс.

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

Практикалық есептеу тәртібі:

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

Қарапайым тексеріс:

• қай ВМ кешігулерге сезімтал (DB, VDI, 1С, терминалдық фермалар)
• қай жерде IOPS маңызды, қай жерде тұрақты төмен кешігулер маңызды
• «ыстық» мәліметтер көлемі қандай және қаншалықты жиі өзгереді
• 12–24 айға деректер өсімі және қалаған қор
• ауыр операцияларға қай терезелер бар (бэкап, репликация, қызмет көрсету)

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

Пилот: жоспарлау және миграцияға дейін тексеретіндер

Пилот негізгі миграцияға дейін тәуекелдерді азайту үшін қажет: HCI-дің нақты байланыс пен жүктеме жағдайындағы мінезін және қанша ресурстың шын мәнінде керек екенін көру. Өңірлерде персонал мен байланыс шектеулі болғандықтан бұл әсіресе маңызды.

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

Пилот моделін таңдаңыз: орындық шағын кластер (нақты жағдайды көрсетеді) немесе ЦОД-тағы стенд (қол жетімділігі оңай). Мысалы, егер филиал қашықта орналасқан болса, жерде пилот қосымшалардың жауап уақытын шын мәнінде көрсетеді.

Қысқа тест матрицасын және жұмыс терезесін жасаңыз:

• бір узелдің сөнуін имитациялау және сервистердің сақталуын тексеру
• диск проблемасын имитациясы және жүйенің реакциясы
• узелді жұмыс уақытында қайта жүктеу
• тесттік ВМ-ды бэкаптан қалпына келтіру
• әкімшілік операцияларды тексеру: ВМ жасау, снапшот, көшіру

Нәтижелерді рәсімдеу: сәттілік критерийлері мен кім бекітетіні (ИТ, бизнес, қауіпсіздік) алдын ала анықталсын. Көбінесе 3–4 өлшенетін көрсеткіш жеткілікті: қалпына келтіру уақыты, өнімділік тұрақтылығы, күнделікті операциялардың ыңғайлылығы, есептердің түсініктілігі.

Қандай метрикалар жазылатынын, нәтижелерді қайда сақтайтынын және кім соңғы протоколға жауапты екенін келісіңіз.

ВМ миграция жоспары: дайындықтан откатқа дейінгі қадамдар

Табысты миграция тәртіп пен дайындықта. Инвентаризациядан бастаңыз: ВМ-дар, иелері, тәуелділіктер (DB, файл шарлары, лицензиялар), рұқсат етілген тоқтату терезелері. Көшіру алдында ескі снапшоттарды алып тастаңыз және қонақ ОС-дағы ескі конфликтілі драйверлер мен агенттер жоқ екенін тексеріңіз. VMware Tools немесе баламаларын және ОС жаңартуларын теңестіріп қойған жөн.

Миграция әдісін қауіп пен тоқтату уақытынан таңдап алыңыз. Өңірлерде әдетте екі тәсіл жұмыс істейді: ВМ-дарды топпен (мысалы, 10–20 ВМ терезеге) көшіру немесе сервис бойынша (қолданба, оның DB-сы және қосалқы түйіндері бірге). Егер тоқтату өте қымбат болса, қысқа өшіру терезесімен алдын ала келісіп, көшіруден кейін міндетті тексерулер жасаңыз.

Практикалық көшіру тәртібі:

• некритикалық ВМ-дар (тесттік, қосалқы) — процесті отшашу үшін
• негізгі инфрақұрылымдық рөлдер (AD/DNS, файлдық сервистер) — ең ауыр жүктемелерсіз
• критикалық қосымшалар мен дерекқорлар — алдын ала келісілген терезеде

Откат жоспары бірінші көшіруге дайын болуы тиіс. Не сәтсіздік болып саналады (мысалы, 2–3 негізгі тексеруден өтпесе, қолданба қатесі арсауы, қабылданбайтын кешігулер), кім шешімді қабылдайды және қызметті қанша минутта қайтаруға болатынын белгілеңіз. Откат үшін әдетте бұрынғы хостқа оралу немесе сақталған қалпынан қайтару жеткілікті. Нәтижелерді қысқа протоколда тіркеңіз: не көшірілді, қандай тексерістер жасалды, нәтижелері қандай.

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

Пилотта отказоустойчивость тесті: қарапайым тексеру сценарийі

Пилотта ВМ-дардың жүктелгенін көру жеткіліксіз — площадка апаттарды және жоспарлы жұмыстарды қалай көтеретінін тексеру маңызды. Өңірлік филиалдарда жиі жергілікті дежурный жоқ болғандықтан сервистер қолжетімді болуы керек.

Тесттер алдында қатысатын ВМ-дар мен қосымшаларды, алынатын метрикаларды (қолжетімділік, кешігу, қалпына келтіру уақыты) және сәттілік критерийлерін бекітіңіз. Қызмет иелерін ескеріп, қауіпсіз терезені таңдаңыз.

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

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

RTO және RPO-ны секундомер мен логтар арқылы өлшеңіз. Әр тесттен кейін қысқа протокол жасаңыз: не жасалды, нәтижелері қандай, қай жерде қиындықтар болды (желі, DNS, қосымша тәуелділіктер), қандай өзгерістер енгізілді және түзетулерді тексеру үшін тесті қайталаңыз.

Узел таңдау мен миграциядағы типтік қателіктер

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

CPU, RAM және диск таңдау қателері

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

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

Барлық жүктемені тәртіпсіз орналастыру — тағы бір қате: 1–2 ауыр ВМ (1С, SQL немесе VDI) қалған сервистердің жауап уақытын нашарлатады.

Нені алдын ала тексерген дұрыс:

• RAM-ның нақты пиктері және N+1 сценарийіндегі жұмыс
• қай ВМ «ауыр» және оларды қай жерде орналастыратыныңыз
• дедупликация төмен шықса қандай диск қоры қалатыны

Пилот пен миграция қателері

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

Екінші қате — пилотқа сәттілік критерийлерін орнатпау. Егер алдын ала метрикалар (қолжетімділік уақыты, рұқсат етілген тоқтату, RPO/RTO) белгіленбесе, кейін шешім қабылдау және бюджет қорғау қиын болады.

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

Сатып алу және жұмыс бастар алдында қысқа чеклист

HPE SimpliVity 380 сатып алмас бұрын фактілер мен келісімдерді бір бетке жинаңыз. Бұл узелдердің «таза» болмай шығуын және миграцияның күтпеген тәуелділіктерден ұзарып кетуін азайтады.

Алдымен ВМ-дардың нақты картасын жинаңыз: саны ғана емес, ролдері де маңызды: домен контроллері, файлдық сервис, 1С, VDI, бейнебақылау, локалдық дерекқорлар. Көшіру кезінде не бұзылады — IP байлаулары, лицензиялар, интеграциялар, бэкаптардың кестелері — бәрін жазып қойыңыз.

Содан кейін қолжетімділік ережелерін келісіңіз. N+1 қор керек пе (бір узелдің өшуін критикалық сервистер деградациясыз шығарып жіберуі), әлде «апатты көтеріп, кейін қалпына келтіру» моделі жеткілікті ме — бұл узел саны мен CPU/RAM/диск қорына тікелей әсер етеді.

Бастапқы тексеру минимум:

• ВМ инвентаризациясы дайын: иелері, тәуелділіктер, критичность және тоқтату терезелері келісілген
• 2–4 апталық метрикалар бар: CPU және RAM пиктері, қолданылған орын, деректер өсімі, диск жүктемесі
• қолжетімділік пен сыйымдылық мақсаттары қабылданған: N+1 ережесі, өсуге қанша кор қалдыру
• пилот жоба ретінде сипатталған: сәттілік критерийлері, тексерістер матрицасы, отказоустойчивость тесті
• миграция толқындарға бөлінген: көшіру тәртібі, коммуникация және откат жоспары анық

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

Филиалға арналған мысал сценарий: пилоттан типтеуіне дейін

Мысалы, өңірлік офис 35–60 ВМ-мен: екі критикалық жүйе (мысалы, 1С/SQL және домен/DNS), қалғандары — файлдық ресурс, басып шығару, терминалдық қызмет, кішігірім қосымшалар. Мақсат — бір узелдің өшуін HPE SimpliVity 380 офис жұмысын сақтап өтуі және келісілген тоқтау лимитіне сай болуы.

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

ВМ-дарды толқындар бойынша көшіру жақсы:

• 1-ші толқын: екінші дәрежелі сервистер (тесттік, көмекші) және 5–10 ВМ — процессті жылжыту үшін
• 2-ші толқын: негізгі инфрақұрылымдық рөлдер (AD/DNS, файлдық сервис), бірақ ең ауыр жүктемелерсіз
• 3-ші толқын: критикалық қолданбалар мен дерекқорлар, алдын ала келісілген терезеде

Әр толқыннан кейін фактілерді тіркеңіз: көшіру уақыты, кешігулер өзгерісі, қосымша қателер, қолданушылардан түскен шағымдар, CPU/RAM/IOPS ауытқулары. Бэкап пен қалпына келтіруді да тексеріңіз.

Пилот нәтижелерін қысқа және нақты түрде беріңіз: «болған/болғаннан кейін» кестесі, тәуекелдер тізімі (мысалы, желі тарлығы немесе RAM жетіспеушілігі) және доработкалар тізімі жауаптылармен және мерзімдерімен. Тираждау осы шаблон бойынша жүреді: бірдей толқындар, бірдей тесттер және бірдей есеп форматы. Егер пилот интегратормен болса, жауапкершілік аймағын алдын ала келісіңіз.

Пилоттан кейінгі келесі қадамдар: эксплуатация, қолдау және масштабтау

Пилот сәтті өткеннен кейін нәтижені бекіту маңызды. Пилот шешімнің жұмысын көрсетті — енді эксплуатация мен қолдау айқын болуы керек.

Бірінші шешім — күнделікті қолдауды кім жүргізеді. Кей филиалдар үшін орталық команда жеткілікті, жергілікті деңгейде қарапайым ауыстырулар мен қайта жүктеулер үшін «ақылды қол» жеткілікті. Қаншалықты критикалық филиал болса, орталық бақылау плюс жергілікті жауапты модельі жиі таңдалады.

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

• ағымдағы схема: узелдер, желілер, сервис тәуелділіктері
• рөлдер мен қолжетімділіктер: кім ВМ-ды тоқтата/қалпына келтіре алады, саясаттарды өзгерте алады
• қысқа процедуралар: жаңарту, кеңейту, компонент алмастыру, резервтен қалпына келтіру
• авариялық әрекеттер: «5 минутта не істейміз», «1 сағат ішінде не істейміз»

Қолдау және запас бөлшектер

Өңірлерде үзілістер көбіне бөлшектер мен келісім күтуден болады. Алдын ала жаңарту терезелерін, эскалация тәртібін және минималды запас ЗИП-ты анықтаңыз.

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

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