Критикалық базаларға арналған All-flash СХД: пилот және салыстыру метрикалары

Неліктен критикалық базаларға пилот өткізу керек

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

Осындай жүйелерге сақтау шешімін «паспорттық IOPS» бойынша таңдау көбіне жұмыс істемейді. Өндіруші идеал профильдегі жүктеме, таза стенд және алдын ала бапталған параметрлер үшін көрсеткіштер береді. Шынайы өмірде бәрі күрделі: оқу мен жазудың араласуы, әртүрлі блок өлшемдері, фондық тапсырмалар, шифрлау, репликация, снапшоттар және сол инфрақұрылымдағы көрші сервистер. Сондықтан ұқсас «IOPS» көрсеткіші бар екі СХД нақты базалар үшін маңызды параметр — задержка мен оның тұрақтылығы — тұрғысынан мүлде әр түрлі әрекет етуі мүмкін.

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

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

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

Dell PowerStore, HPE Alletra және IBM FlashSystem: нені салыстыру керек

Dell PowerStore, HPE Alletra және IBM FlashSystem жүйелерін брошюрадағы атаулар мен сандарға емес, сіздің жүктеме астында жүйенің қалай әрекет ететініне қарай салыстырыңыз. All-flash СХД үшін басты сұрақ: ол қажетті задержканы тұрақты ұстай ала ма және сұраныс профилі өзгергенде «плавацияға» түседі ме.

Бастау үшін міндетті түрде тапсырмаларды үш классқа бөліңіз.

OLTP әдетте шағын блоктарда төмен задержканы және өткір пиктерді талап етеді. Аналитика ұзақ оқулар мен үздіксіз ағындарды береді. Аралас жүктеме — күндіз OLTP, түнде есептер мен бэкаптар, плюс СХД-ның өз фондық жұмыстары — көбіне ең қиын болады.

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

Пилоттың қорытындысы жиі «таза IOPS»-тан гөрі функциялар мен олардың задержкаға және эксплуатацияға әсері бойынша анықталады. Снапшоттар мен клондарды тексеріңіз (жылдамдық, базаның әсері және орын), репликацияны (RPO/RTO және байланыс үзілісінде мінез-құлық), шифрлауды (қалай қосылады және задержкаға әсері бар ма), QoS (қоршаған жүйелерден базаны қорғай ала ма) және мониторингті (қосымша баптаусыз қандай графиктер мен алерттер бар).

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

Пилотқа дайындық: талаптар, рольдер, шектеулер

All-flash СХД-ны салыстырмас бұрын кіріс деректерді бекітіңіз. Олай болмаса пилот әдемі графиктер жинағына айналып, сіздің сервиске сай немесе сай еместігі туралы жауап бермейді.

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

Алаң шектеулерін тексеріңіз. Қағазда бәрі жылдам көрінеді, бірақ пилот базалық нәрселерге ұшырайды: қуат пен салқындату, стойкадағы бос юниттер, желі типі және порттардың қолжетімділігі (FC, iSCSI, Ethernet), қазіргі коммутаторлар мен HBA-мен үйлесімділік және рұқсаттар. Алдын ала қайсысы уақытша есептік жазбаларды беретінін, қажетті VLAN/zone ашатынын және ИБ-пен өзгерістерді келісетінін шешіңіз.

Пилот форматын тәуекел мен уақытқа қарай таңдаңыз. Орауыталған жеке стенд бақылауға оңай және продқа тимейді, бірақ нақты желі мен хосттардағы тар жерлерді қайталамауы мүмкін. Тесттік контур өмірге жақынырақ, әсіресе онда ОС, гипервизор мен СУБД нұсқалары продтағыдай болса.

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

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

Пилот дизайны: сценарийлер, baseline және сәттілік критерийлері

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

Көбіне аптаның ішінде шынайы болатын 3–4 сценарий жеткілікті:

• Пиковая транзакциялық жүктеме (жұмыс уақыты, жоғары сұраныс)
• Түнгі пакеттік өңдеу (ұзақ оқулар, сортировкалар, жаппай жаңартулар)
• Бэкап және репликация терезелері (аралас профиль, жазу шарықтары)
• Апаттық режим (нодтың істен шығуын немесе DR-ға ауысуды имитациялау)

Бастама алдында ағымдағы жүйенің baseline-ын тіркеп қойыңыз. Орташа мәндермен қатар «құйрықтарды» — 95p және 99p задержкаларын, IOPS шарықтарын, оқу/жазу профильін, блок өлшемін, кезек тереңдігін алыңыз. Шарттарды міндетті түрде жазып қойыңыз: СУБД нұсқасы, сақтау параметрлері, қосылым саны, джобтардың кестесі. Олай болмаса нәтижелер «жүзіп», даулар баптаулар жайлы болады.

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

Сәттілік критерийлерін алдын ала және жазбаша түрде келісіп қойыңыз. Мысалы: негізгі транзакциялар бойынша 99p задержка пикте X мс-тан аспауы, аралас жүктеме кезінде N сағаттан кейін деградация болмауы, бэкап пен қалпына келтіру RTO/RPO шеңберінде болуы, өлшем және компрессия әсері түсінікті әрі қайталанатын болуы.

Пилот қадамдары: қайталанатын жоспар

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

Әр платформа үшін бірдей жоспарды ұстанған ыңғайлы:

1. Ағымдағы жүйенің baseline-ын алыңыз. Конфигурацияны тіркеңіз (модель, firmware, RAID/пулдар, протокол, multipath) және типтік пиковтарды сағат/күн бойынша бекітіңіз.

2. Тест стендін орналастырып, хосттарды қосыңыз. Хосттарда, желіде және СХД-да метрикаларды бірден жинауды қосыңыз. Қай параметрлерді өзгертпеу керектігін келісіңіз (мысалы ОС пен драйвер нұсқасы).

3. Калибреу үшін синтетикалық тесттерді іске қосыңыз. Олар I/O жолының жұмысын, желідегі тар жердің жоқтығын және очередтер мен multipath-тың дұрыс бапталғанын көрсетеді. Осы тесттер бойынша «жеңімпазды» таңдамаңыз.

4. Жүйелік жүктеме немесе прод-трафикті реплей жасаңыз. Мысалы, Oracle/PostgreSQL көшірмесімен таңертеңгі есеп және түнгі пакет жүктеме. Орта мәндермен қатар задержка «құйрықтарын» салыстырыңыз.

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

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

Өнімділік метрикалары: нені жинау және қалай оқу

Пилотта маңызды — әдемі сандар емес, жүктеме пиктерінде сақтау жүйесі сіздің SLA-ны ұстай ала ма.

Дерекқорлар үшін басты метрика — задержка. Перцентилдерді қараңыз: 50p «әдеттегі», 95p «жаман минуттар», 99p — пайдаланушы көретін пиктер. Оқу мен жазуды бөлек алыңыз: OLTP көбіне жазуға сезімтал, аналитика — оқуға.

IOPS пен өткізу қабілеті (MB/s) блок өлшемімен бірге оқылады. 50 000 IOPS 4K-та және 50 000 IOPS 64K-та — мүлде әртүрлі режимдер. Сондықтан профильді тіркеңіз: блок өлшемі, оқу/жазу қатысы, кезек тереңдігі.

Әр прогоныңда (СХД және хост жағында) логтауға тиісті минималды метрикалар:

• Оқу мен жазу бойынша задержка 50p/95p/99p
• Блок өлшемін көрсете отырып IOPS және MB/s
• Кезек тереңдігі және хосттағы I/O күту уақыты
• Серверлердегі CPU мен жад жүктемесі (тар жерді шатастырмау үшін)
• СХД-дағы фондық жұмыстар оқиғалары (снапшоттар, ребилд, скраб)

"Насығу" моментін табу үшін жүктемені кезең-кезеңімен өсіріп, IOPS баяу өсетін және 95p/99p задержка күрт өсетін нүктені белгілеп отырыңыз. Бұл — SLA бұзылатын шекара.

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

Емкость пен тиімділік метрикалары: қате жасамау үшін

Өнімділікті тез көруге болады, ал емкостьпен қате жылдарға созылуы мүмкін. Пилотта тек "қанша терабайт сатып алынғаны" емес, қорғаныс пен өсім жағдайында нақты қанша дерек сиятынын есептеу маңызды.

Raw (SSD физикалық емкость) көбіне usable-ға тең болмайды. Бір бөлігі RAID/erasure coding, ребилд резерві, метадеректер, журналдар, снапшоттар үшін кетеді. Пилотта алдын ала резерв ережесін қойып алыңыз (мысалы 20–30% бос орын) және 70–80% толғандағы мінезін тексеріңіз.

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

Тиімділік метрикаларын бір уақытта салыстырыңыз:

• Raw, usable және нақты пайдаланылған емкость
• Data reduction ratio және бөлек дедуп/компрессия көрсеткіштері
• Снапшоттар мен қызметтік деректер үлесі
• Пулдар/томдар бойынша өсу динамикасы (ГБ/тәулік немесе апта)
• Толтыру дәрежесі задержкаға қалай әсер етеді (50%, 70%, 80% при latency)

Тақырыпша — write amplification және SSD тозу. Жазбалы интенсивті базалар үшін бұл нақты тәуекел. Сондықтан дискі моделдері мен шарттарға қатысты нақты сұрақтар қойыңыз:

• TBW немесе DWPD және бұл мәннің өмір сүру мерзіміне қалай есептелетіні
• Сіздің профиліңізге тән write amplification, зертханалық емес нақты мән
• Random write жоғары болғанда не болады
• Жүйе ресурстың болжамын және ескертуін қалай көрсетеді

Практиялық TCO-фактор — энергия және стойкадағы тығыздық. Пилотта тұтынуды (ваттта) тыныштықта және жүктеме кезінде тіркеп, стойкаға және бір терабайт usable-ға есептеңіз. Кейде екі массив бірдей IOPS береді, бірақ біреуі әлдеқайда көп орын және энергия алып, ЦОД үшін бұл жабдық бағасынан да қымбатқа түсуі мүмкін.

Сенімділік және қалпына келтіру: өткізіп жібермейтін тексерістер

All-flash СХД үшін өнімділік маңызды, бірақ бастысы — не болады ештеңе істемей қалған кезде немесе қалпына келтіру қажет болғанда. Пилотта бір рет көрген артық — брошюраға сенгеннен жақсы.

Ақаулар кезіндегі қолжетімділік: бөлшектеп тексеру

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

Минималды тексерістер жиынтығы (секунд бойынша тіркеу): контроллердің істен шығуы немесе нодтың қайта жүктелуі; диск алынып, ребилдтің latency-ге әсері; FC/Ethernet порт үзілуі және multipath дұрыс жұмыс істеуі; коммутатор не ISL сәтсіздігі және балама жолдың болуы.

Тіркеуде тек "тұра алды/тұра алмады" емес, қалай болғанын жазыңыз: задержка пикі, I/O қателері болды ма, деградация қанша уақытқа созылды — себебі қысқа деградация да транзакцияларды немесе таймауттарды бұзуы мүмкін.

Оновления тоқтаусыз түрде: фактіні тіркеу

Егер вендор non-disruptive upgrade деп көрсетсе, пилотта жаңартуды (немесе бақылаулы сервис қайта жүктеуін) өткізуін сұраңыз. Нұсқаны, қадамдарды, желі мен хост жағындағы талаптарды, логтардағы ескертпелерді тіркеңіз. DBA-дан қолмен әрекеттер қажет болды ма — бөлек жазып қойыңыз.

Репликация, DR және бэкап: нақты RPO және RTO өлшеу

DR үшін мақсатты RPO/RTO-ны алдын ала келісіп, оларды продқа ұқсас тест сервисінде тексеріңіз. Кәдімгі сценарий: база жүктеме жасайды, сіз DR-ға ауыстырып, консистенттікті және пайдаланушылардың қайта жұмысқа оралу уақытын тексересіз.

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

DBA-пен келісіп журнал жүргізу режимдерін және консистенттікті талқыңыз: write-back cache-пен не істейміз, application-consistent snapshot керек пе және қалпына келтіруден кейін бүтіндікті қалай тексереміз.

Эксплуатация: енгізуден кейін күнделікті не болады

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

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

Виртуализация мен ОС-пен интеграция үшін multipath (policy, жол басымдықтары, SCSI таймауттары мен ретраи) мұқият бапталуы керек. Қате құлаулардың жиі себебі — қысқа таймауттар, олар уақытша жол ауысуында дерекқордың қателігіне әкелуі мүмкін. Виртуализацияда queue, datastore ережелері мен storage vMotion кезінде мінез-құлықты келісіңіз, күтпеген задержка шарықтары болмас үшін.

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

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

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

Пилоттағы жиі қателіктер және оларды қалай болдырмау

Негізгі тұңғиық — бәрін бір санға түсіргісі келу. Критикалық базалар үшін орташа IOPS немесе орташа задержка емес, әртүрлі профильдердегі мінез-құлық маңызды: кішкентай кездейсоқ жазбалар, оқу шарықтары, аралас операциялар, журнал жұмысымен қарым-қатынас, шарықтарға реакция.

Жұмыс тәсілі — алдын ала 2–3 сценарийді жазып алу, олар күнделікті шындыққа сай: таңертеңгі OLTP-пик, күндізгі есептер, түнгі регламенттік тапсырмалар. Осылай All-flash СХД нақты іс бойынша салыстырылады, әдемі графика бойынша емес.

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

Нәтижелер дауға айналмасын десеңіз, тест алдында ортаны қалпында тіркеңіз: firmware пен драйвер нұсқалары, желі схемасы мен порт жылдамдығы, MTU және VLAN, хост пен дерекқор параметрлері (очередьтер, тереңдік, баптаулар), томдардың толтырылуы және қосылған сервистер, тест жиынтығы мен кестесі.

Пилот барысында «ручкаларды өзгерту» қауіпті. Егер блок өлшемін, кэш саясатын немесе QoS параметрлерін өзгертсеңіз, не өзгерткеніңізді, не үшін және нәтиже қалай өзгергенін міндетті жазып отырыңыз.

Және жиі кейінге қалдыратын нәрсе — бэкаптар, репликация және жаңартулар. СХД-ның бэкап кезіндегі мінезін, қалпына келтіру жылдамдығын және жаңартулардың задержкаға әсерін тестілеңіз. Бұл "идеал" бір сағаттық тесттен гөрі эксплуатацияға жақын.

Жылдам чек-лист және пилоттан кейінгі қадамдар

Пилотты жаппас бұрын барлық жүйелер бірдей шарттарда салыстырылғанына және қорытындыларды ИБ мен қаржыға қорғауға болатындығына көз жеткізіңіз. All-flash СХД үшін ең маңыздысы — максималды сандар емес, нәтижелердің қайталануы мен анықталған тәуекелдер.

Тексеріңіз: baseline салыстырмалы кезеңнен алынған ба (әдеттегі және пиковый күн), сәттілік критерийлері алдын ала жазылған ба (задержка порогтары, RPO/RTO, қызмет көрсету терезелері, шифрлау және журнал талаптары), мониторинг жұмыс істейді ме және метрикалар уақыт бойынша синхрондалған ба, сценарийлер қайталанатын ба (сол сұраныстар, деректер көлемі, ағын саны, кэшт прогрев), шектеулер мен параллель фондық жұмыстары тіркелген бе.

Метрикалардың сапасын бағалаңыз. Орташа задержка жақсы көрінуі мүмкін, бірақ маңыздысы — құйрықтар мен уақыт бойынша мінез-құлық. Перцентильдерді (ең болмағанда p95 және p99), минуттық графиктерді және фондық тапсырлардың әсерін қараңыз: бэкаптар, ребилд, дедуп, түнгі ETL.

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

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

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