Jitsi on-prem бейнебайланыс филиалдар үшін: желі, TURN, жазу

Филиалдардағы бейнебайланыс мәселелері қайдан басталады

Көбіне шағымдар платформада емес, жергілікті желі мен жағдайларда басталады: бір кеңседе Wi‑Fi жүктелген, басқа жерде қатаң NAT, үшіншісінде кездесу бөлмесі шуылмен толы. Нәтижесінде «дыбыс үзіліп жатыр», «барлығы баяулаған», «әр 10 минут сайын шығып қалады» деген сөздер естілетін болады.

On‑prem Jitsi‑да бұл ерекше көрінеді, өйткені бұлттық сервис‑тағы «ішінде қалып кеткен» жауапкершілік сізде: серверлер қайда тұр, олар интернетке қалай шығады, қандай порттар ашық, кім жаңартулар мен логтарды бақылайды. Бөлек қауіп аймағы — периметр: firewall, прокси, NAT және филиалдар арасындағы қауіпсіздік ережелері.

Таралған компанияда типтік симптомдар:

• пакет жоғалтулар мен jitter салдарынан сөйлеудің үзілуі және «робот» секілді бұрмалану
• арнаның немесе Wi‑Fi‑дың жүктелуінен дыбыс пен бейне кешігуі
• NAT/firewall ережелері сәйкес келмегенде «қара экран»
• сырттан келген қонақтардың қосылуы тұрақсыз болуы
• жазба қосылғанда сапаның кенет нашарлауы

Бастапқы келісім-шартта қандай үміттерді белгілеген дұрыс

Пилотқа дейін базалық сценарийлер бойынша келісіңіз: типтік қоңырауда қанша адам болады (және максимум қанша), сырттан қатысушылар қажет пе, жазба бола ма, арнайы жабдықталған кездесу бөлмелері бар ма. 40 адамдық жазбалы жиналыс пен 6–8 адамдық қоңыраулар әртүрлі каналдар, серверлер және қолдау тәсілдерін қажет етеді.

Сәттілік критерийлері

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

Филиалдары бар ұйымға арналған типтік Jitsi on‑prem архитектурасы

Схемада бәрі қарапайым көрінгенімен, филиал желісінде детальдар шешіледі: медиатрафик қай жерде өтеді, WAN арқылы қалай жүреді және арналар жүктелгенде не болатыны. Сигнализация кешігуге төзімді болуы мүмкін, ал медиа (аудио мен видео) — жоқ.

Негізгі компоненттер мен рөлдер

Пилотта рөлдерді бір серверге қою жиі кездеседі, бірақ филиалдық модельде олар әдетте бөлінеді:

• Jitsi Meet (веб‑интерфейс және статика)
• Prosody (XMPP): бөлмелер, авторизация, кездесулер оқиғалары
• Jicofo: конференцияны басқару
• JVB (Jitsi Videobridge): медиамост, аудио мен видеоны қабылдап таратады

Көбіне JVB ең жүктелетін түйінге айналады және оның орналастырылуы байланыс сапасына ең қатты әсер етеді.

Қайда орналастыру және қанша түйін жасау керек

Әдетте біреуі таңдалады: барлық сервис басты офистің ЦОД‑ында, бөлек нейтралды ЦОД немесе кейбір сервис орталықтандырылған, ал JVB‑ны филиалдарға жақын қоюшы гибрид. Бір жалпы кластерді ұстау оңайырақ, бірақ филиалдар алыс болса кешігулер өседі.

Мысалы, басты офис Алматыда, ал филиалдар Атырау мен Өскеменде болса, бір орталық түйін пайдаланушыларға әртүрлі тәжірибе беруі мүмкін.

Көп жағдайда «километрлерден» гөрі нақты маршрутизация мен желінің жағдайы әсер етеді: пиковые сағаттардағы WAN жүктемесі, асимметрия (upload көбінесе download‑тан әлсіз), пакет жоғалту мен джиттер (олар әсіресе дауысқа қатты әсер етеді).

Сондықтан пилот үшін жиі бір түйіннен бастайды, кейін өлшемдер проблемаларды көрсеткен жерлерге аймақтық JVB қосады.

Желі және өткізу қабілеті: не есептеу және не өлшеу

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

Шамамен ағындарға қарай есептеңіз. Аудио (Opus) әдетте ондаған кбит/с алады, ал видео мегабиттерді талап етеді: 720p көбінесе бір жіберушіге шамамен 1.5–2.5 Мбит/с, 1080p — 3–4+ Мбит/с сұрауы мүмкін. Экранды көрсету өзгермелі жүктеме береді: слайдтар оңай, алайда экран ішіндегі видео битрейті кенет өсіреді.

1:1 және 10–30 адамдық жиналыстың айырмашылығы — топта әрқайсысының кіріс трафигі өседі: сіз бір ағын жібересіз, ал бірнеше ағын аласыз. Филиалдарда жиі Wi‑Fi және қолданушыға дейінгі арна бұзылады, ал орталық нүктеде — барлыққа ағын тарататын түйіннің исходящий каналы.

WAN‑да тек жылдамдықты емес, сапаны өлшеңіз: пакет жоғалтулар (тіпті 1–2% естілетін болады), джиттер, кешігулер (RTT), upload/download арасындағы асимметрия, уақыт бойынша просадкалар және сол бір бөлмеде сым мен Wi‑Fi арасындағы айырмашылық.

QoS тек сіз кезектерді басқара алатын жерде мағынасы бар: филиал және орталық шекара маршрутизаторларында және корпоративтік Wi‑Fi‑да. Ол интернетті «жылдамдата» қоймайды, бірақ дауысты және видеоны резервтік үлкен жүктемелерден (бережный резервтер, кэштегі копиялар) қорғайды.

Проблема провайдерде ме, әлде серверлік бөлікте ме екенін қалай түсіну: бір және сол сервер белгілі филиалдардан жақсы жұмыс істеп, ал басқалардан нашар; метрикалар дәл сол проблемалы бөлімде пакет жоғалту мен джиттердің өскенін көрсетеді. Мысал: 50/10 Мбит/с арнасы бар филиалда он қатысушы әдетте жақсы сөйлеседі, бірақ егер екі адам экран бөлісе бастаса, әлсіз upload пен кешігу секірістері «робот» дыбыс пен сөз үзілуін береді.

NAT, firewall және қол жеткізу ережелері: алдын ала не дайындау керек

WebRTC көп жағдайда серверлерден емес, желіден «бұзылады». Медиа мүмкіндігінше клиент пен медиамост арасында UDP арқылы жүруге тырысады, ал NAT пен қатаң firewall UDP‑ны кесіп тастауы, адрестерді алмастырауы немесе тек «әдеттегі» веб‑порттарды өткізуі мүмкін. Нәтижесінде «қосылу» деген көрсетіледі, бірақ дыбыс үзіліп қалуы немесе мүлде дыбыс болмауы мүмкін.

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

Порттар бойынша әдетте келесі қажет: TCP 443 — веб-интерфейске және сигнализация компоненттеріне, UDP 10000 — JVB үшін (сапаға маңызды), TCP 4443 — JVB‑ға резерв ретінде, егер UDP қиылатын болса (бірақ кешігу мен сапа әдетте нашар болады). Қатаң NAT‑ты айналып өту жоспарланған болса, TURN үшін порттарды алдын ала келісіңіз.

Егер филиалда тек шығыс қосылым рұқсат етілсе, әр филиалдан кем дегенде TCP 443 шығатынын және шығыс UDP‑ға мүмкіндік бар-жоғын тексеріңіз. UDP толықтай тыйым салынғанда, байланыс жиі TCP‑ге ауысып, айтарлықтай нашарлайды.

Желі администраторларымен минималды тексерістер:

• әр филиалдан серверге TCP 443‑ке тікелей қол жетімділік бар ма
• JVB‑ның публичды адресіне UDP 10000 рұқсат етілген бе
• NAT шығыс UDP сессияларын бұзбай ма (қысқа таймауттар, агрессивті инспекция)
• MTU/VPN бойынша шектеулер жоқ па, медиаға әсер ететін себептер бар ма
• ең «қиын» филиалдан жұмыс уақытында тесттік қоңырау жасалған ба

TURN: қашан қажет және тосын сыйсыз қалай жоспарлау керек

WebRTC ICE жинайды: клиенттен клиентке немесе медиамостқа қалай жету түрлі нұсқаларды сынайды. STUN сыртқы адрестерді анықтауға көмектеседі және жиі жеткілікті болады, егер желі қалыпты жүрсе.

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

TURN әдетте симметриялық NAT, қатаң firewall (тек шектеулі шығыс порттар), мобильді желілер және қонақ Wi‑Fi‑да, сондай‑ақ серіктес желілерінен қосылғанда қажет.

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

Практикада coturn жиі қолданылады: long‑term credentials (логин мен пароль) қосып, realm орнатады, 3478 (UDP және TCP) ашылады және қажет болғанда TLS үшін 5349 бапталады. Relay‑порттардың диапазонын алдын ала анықтап, firewall‑мен келісіңіз.

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

Дыбыс сапасы: эхо, шу және сөз үзілістері

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

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

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

Акустика ережесі қарапайым: микрофон сөйлеп тұрған адамға неғұрлым жақын болса, эхо аз болады. Кездесу бөлмесінде бөлек спикерфон немесе бағытталған микрофон әдетте ноутбуктың ішкі микрофонынан жақсы жұмыс істейді. Жұмсақ беттер (перделер, кілем, акустикалық панельдер) шағылысуды айтарлықтай төмендетеді. Көбірек әйнек пен бос қабырғалар болса, дыбыс желі тамаша болғанымен де «қыпшаңдап» қала береді.

Жылдам диагностика 10 минут алады. Қысқа тест жазбасын жасап, қашан эхо пайда болатынын тыңдаңыз. Сосын құрылғыны бір‑бірлеп ауыстырып көріңіз (ішкі микрофон → гарнитура), басқа бөлмеде сынап көріңіз және мүмкін болса басқа желіні (кабель орнына Wi‑Fi емес) тексеріңіз. Егер мәселе желіні ауыстырғанда жоғалса, ары қарай пакет жоғалту, джиттер, Wi‑Fi, VPN және маршрутизацияға қараңыз.

Кездесулерді жазу: жүктеме, сақтау және қол жеткізу ережелері

Жазба әдетте медиамостта емес, бөлек компонентте жасалады. Типтік шешімде Jibri қолданылады: ол жиналысқа жасырын қатысушы ретінде қосылып, көріп және еститінін жазады. Егер жазбалар сирек және тек бір залда болса, бір машина жеткілікті болуы мүмкін. Ал барлық филиалдарда параллель жазбалар керек болса, пул жоспарлаңыз.

Ресурстар бойынша жазба көбіне CPU мен дискке тіреледі. Конференция тұрақты болса да, жазба есептеуден немесе баяу диск жүйесінен «тұрып қалуы» мүмкін. Қанша бір уақытта жазба жүргізілетінін, кодтауға қажетті CPU, диск жылдамдығын және сақтау шегін алдын ала келісіңіз.

Сосын файлдарды қайда сақтау керектігін шешіңіз: локальды ЦОД‑та, файлдық сақтау жүйесінде немесе құжаттар жүйесінде. Қандай рөлдер бар екенін анықтаңыз: кім қарай алады, кім жүктеп ала алады, кім өшіре алады. Қате — «сілтемемен ортақ пайдалану» орнатылып, файл сыртқа шығуы мүмкін.

Сақтау саясаты мен құқықтық талаптарды қауіпсіздік және заң бөлімімен келісіңіз: сақтау мерзімі (30/90/365 күн), ұзарту негізі және автоматты жою. Қатысушыларды жазба басталар алдында міндетті түрде ескертіңіз: индикатор, модератордың сөзі және жазба тек жүргізушінің айқын келісімімен басталатыны туралы ереже.

Кездесу бөлмелері: жабдық және ыңғайлылық

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

4–6 адамдық шағын бөлме үшін әдетте сапалы USB‑камера және үстелге қойылған спикерфон жеткілікті. 12–20 адамдық үлкен бөлмеде негізгі фактор — дыбыс: бір «таблетка» ортасында жеткіліксіз, шеттегі адамдар әлсіз естілуі және эхо артады. Мұндай бөлмелерге қуаттырақ спикерфон, қосымша микрофондар немесе микрофон массиві және кең бұрышты немесе PTZ камера жоспарлаңыз.

Кездесуді жиі «бұзатын» байқалмайтын себептер: USB өшіп қалуы, нашар HDMI, қашқан пульт, кіріс порттардың шатасуы, ПК‑ның автономды режимі, кенет ОС жаңартуы немесе браузер микрофонға қол жеткізуді жоғалтуы.

Нұсқа: адам бөлмеге кіріп 10 секунд ішінде не істеу керектігін түсінуі тиіс. Оған 3–4 қадамдық қысқа нұсқаулық үстелде және «бір батырма» сценариі (мысалы, бөлмедегі бөлінген ПК‑да алдын ала ашылған конференция беті немесе күнтізбе арқылы іске қосу) көмектеседі.

Алғашқы аптаның алдында негізгі жиынтықты тексеріңіз:

• бөлме үшін бөлек ПК/мини‑ПК, артық программасыз және автоматты ұйқысыз
• сапалы USB/HDMI кабельдер және қосымша комплект
• камера көз деңгейінде және порттар белгіленген
• бөлменің ең шалғай орнынан микрофонның тесті
• модератордың рөлі: кім кездесу бастайды және сыртқы қонақтарды кіргізеді

Қолдау «қалай көмектеседі» сұрағына нақты жауап болғанда жұмыс істейді. Кәдімгі схема — IT дежурный және әр филиалда бір жауапты адам. Оларға қысқа қалпына келтіру сценариі керек: вкладканы қайта жүктеу, микрофонды тексеру, USB‑ны қайта қосу, ПК‑ны қайта жүктеу және содан соң ғана эскалациялау.

Егер переговорлер мен инфрақұрылымды «ключке дейін» тапсыратын болса, бір мердігер жабдық стандартын да, бүкіл желі бойынша сервисін де қамтамасыз етсе ыңғайлы. Қазақстанда мұндай жобаларды жиі GSE.kz деңгейіндегі жүйелік интеграторлар жүргізеді.

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

On‑prem Jitsi «бізді естімейді» деген айғайға айналмас үшін, идеал жағдайларды емес, нақты филиалдарды— әртүрлі провайдерлер, NAT, VPN, жүктелген арналар мен эхосы бар бөлмелерді тексеріңіз.

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

Содан кейін қадамдап жүріңіз:

• филиалдар картасын жасаңыз: подсеттер, NAT, firewall шектеулері, рұқсат етілген порттар және кім оларды өзгерте алады
• 1–2 филиалда пилот бастаңыз және сапаны өлшеңіз: кешігу, пакет жоғалтулар, сөйлеудің «тұрып қалуы», қайта қосылулар жиілігі
• ең нашар желілерді тексеріп, алдын ала TURN және қауіпсіздік саясатын баптаңыз
• пилотта жазбаны қосып, жүктемені бағалаңыз: CPU, диск, желі және сақтау орнына қол жеткізу
• переговор бөлмелерін дайындаңыз: микрофондар, акустика, орналасу, пайдаланушыларға қысқа нұсқаулық

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

On‑prem Jitsi іске қосудағы жиі қателер

Көпшілік қате — жүйені «солай» дата‑орталыққа немесе басты офиске орнатып, содан кейін филиалдардан шағымдар келе бастағанда таңғалуы. Идеалды арнада тест өткізу ештеңе дәлелдемейді, егер филиалдарда басқа провайдер, басқа NAT және басқа Wi‑Fi болса.

Көбіне мәселе келесі себептерден шығады:

• пилот тек жақсы арнада өткізіліп, кейін кешкі уақытта бір филиалда аплинк құлдырайтыны анықталмайды
• қауіпсіздікті және диагностикаға кедергі келтіретін артық порттар ашылады
• TURN орнатып, оны шектеусіз және аутентификациясыз қалдырады
• JVB мен әсіресе жазбаға түсетін жүктемені төмен бағалайды (жазба қосылғанда CPU мен диск тез таусылады)
• переговор бөлмені «бар дүниеден» жинап, эхо басу мен қалпына келтіру сценариін тексермейді

Жақсы тәжірибе: әр филиалда қысқа тест сценарийін жұмыс уақытында қайталау. Мысалы, 3 қатысушы филиалдан, 3 — бас кеңседен, 10 минут экран бөлісу, 10 минут жазба және 5 минут қалыпты әңгіме. Осыдан кейін әдетте тар жер көрінеді: Wi‑Fi, провайдердің аплинкі, NAT немесе сервер.

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

Барлық филиалдарға масштабтаудан бұрын қысқа чек‑лист

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

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

Масштабтаудан бұрын минималды тексерістер:

• филиалдар арасындағы негізгі арналар бойынша пакет жоғалту мен джиттердің өлшемдері бар (таңертең және түстен кейін)
• NAT пен firewall практикалық түрде тексерілген: UDP ережелері келісілген және UDP‑блок болғанда Б жоспары бар
• TURN «қиын» желілерден тексерілген: қонақ Wi‑Fi, симметриялық NAT, мобильді операторлар
• бірнеше кездесудің тесттік жазбалары жасалған: жүктеме бағаланып, диск орнын ысырап болмайтыны анықталған
• переговор бөлмелер үшін қысқа нұсқаулық және резервтік сценарий әзірленген (мысалы, «2 минутта бөлмені қайта жүктеу»)
• қолдау контактілері мен жауап уақыты тағайындалған: кім инцидент қабылдайды, кім журналдарды қарайды, кім пайдаланушыларға жауап береді

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

6 филиалды компания үшін мысал және әрі қарай не істеу

Мысал: басты офис және әрқайсысы өз провайдерін қолданатын 6 филиал. Кейбір жерде тікелей интернет, басқаларында тек корпоративтік VPN. Бірінде белсенді (white) IP бар, басқасында қатаң NAT және жабық firewall. Пайдаланушыларға қарапайым схема керек: бөлме жасадың, ноутбуктан немесе переговор бөлмеден кірдің, және дыбыс үзіле алмайды.

Jitsi мен TURN орналастыруды ең әлсіз бөлімнен бастап таңдаңыз. Егер 1–2 филиал қатаң NAT немесе мобильді интернетте жиі отырса, TURN‑ды бірден есепке алыңыз, әйтпесе «жұмыс істейді‑жоқ» тәртібі қалыптасады. Көп жағдайда орталық кластер Jitsi (Сіздің ЦОД немесе басты офис) және сол жақта TURN орналастыру пайдаланушыларға тұрақты маршрут береді.

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

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

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

Егер жобаны «ключке дейін» беру қажет болса (серверлер, интеграция, баптау және дежурная қолдау), Қазақстанда тәжірибесі бар жүйелік интеграторды қосу мағыналы: GSE.kz сияқты компаниялар сервер өндіруден бастап интеграцияға және қызмет көрсетуге дейін қамтиды.