Электрон архив инфрақұрылымы: сақтау мерзімі, рұқсаттар және сканерлеу

Проблемалар электрондық архивпен неден басталады

Проблемалар жиі бұзылудан емес, күтулерден басталады. Электрондық архивті «сканерлердің папкасы» ретінде іске қосады, ал жарты жыл өткен соң ол қарапайым жүйеден баяу, қымбат және күрделі жүйеге айналады: іздеу құжатты 10–20 секундта ашады, орын аз, бэкаптар түнде бітпейді, ал қолданушылар кімге қандай көрініс керек деген спорға түседі.

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

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

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

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

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

Осы цифрларды алдын ала жинасаңыз, жүйелік интегратор артық «қорларсыз» конфигурацияны таңдай алады.

Архив міндеттерін қарапайым тілмен анықтау

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

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

Содан кейін файл форматын анықтаңыз. PDF немесе PDF/A оқу мен алмасуға ыңғайлы; TIFF ұзақ сақтау және сапа үшін жиі таңдалады; JPEG фотосуреттер мен тез скан үшін кездеседі. Құжаттарға OCR қабаты бола ма — соны бірден шешіңіз. Мәтінді танымайтын болсаңыз, көбіне іздеу карточка мен метадеректермен шектеледі.

Адамдар құжатты қалай табатынын қысқаша сипаттаңыз. Көп жағдайда бұл комбинация болады:

• атрибут бойынша іздеу (номер, ИИН, контрагент, күн);
• құжат ішіндегі мәтін бойынша іздеу (OCR қажет);
• скандағы штрихкод немесе QR арқылы іздеу (пачканы өңдеуді жеделдетеді);
• қарау, жүктеу және басып шығару (жылдамдыққа талаптар маңызды).

Соңғысы — қолжетімділік. "Дүйсенбіден жұмаға, 9:00-18:00" жұмыс істейтін архив пен тәулік бойы қажет архив әр түрлі резервтеу және қолдау деңгейін талап етеді. Есепшілер үшін тоқтау уақыты квартал соңында екі сағатқа созылуы мүмкін — бұл қоймадағы тыныш маусымдағы тоқтаудан маңыздырақ.

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

Сақтау мерзімі: инфрақұрылымға қандай нақты әсері бар

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

Практикада сақтау мерзімдерін үш топқа бөлу ыңғайлы: қысқа (1–3 жыл), орташа (5–10 жыл) және ұзақ (15+ жыл, кейде үнемі). Инфрақұрылым үшін маңыздысы — неше уақыт құжат белсенді болады. Құжат жиі ізделіп, ашылып жатқанда жылдам сақтау қабаты мен жақсы өнімділік қажет.

Жұмыс логикасы әдетте мынадай:

• белсенді құжаттарды жылдам деңгейде ұстаңыз (жиі оқу үшін дискілер);
• "суық" архивті арзанырақ сақтауқа көшіріңіз;
• ұзақ сақтау үшін түсінікті формат пен бүтіндікті бақылауды анықтаңыз;
• сақтау мерзімдері резервтік көшірудің тереңдігі мен қалпына келтіру уақытын анықтайды.

Жою саясаты бөлек мәселе. Архивтегі жою «кімде-кім папкасын өшіру» болмауы керек. Алдын ала кім жоюды мақұлдайтынын, негізін қалай тіркейтінін, кім орындайтынын және жою фактісін қалай жазатынын анықтаңыз. Бұл аудит журналдарын және әкімші құқықтарын сақтау тәсіліне әсер етеді.

Сақтау мерзімінің сыйымдылыққа әсерін қарапайым тестпен тексеріңіз: архив айына 2 ТБ өссе, "ұзақ" категория 5 жылда 120 ТБ болады (бэкаптар есепке алынбаған). Көшірмелер көбіне сыйымдылықты 1x-тен 3x-қа дейін көбейтеді, саясатқа байланысты.

Қол жеткізу рөлдері мен аудит: серверлерге және өнімділікке әсері

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

Рөлдер және ең аз құқық принципі

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

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

Әрекеттер журналдары және сервер ресурстары

Аудит әдетте егжей-тегжейлі журналдарды талап етеді. Тексеру үшін жиі тіркелетін оқиғалар:

• жүйеге кіру және сәтсіз кіру әрекеттері;
• құжатты көру және жүктеу;
• метадеректер мен статустарды өзгерту;
• файлдарды жасау, ауыстыру, жою;
• әкімші құқықтары мен саясаттарды өзгерту.

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

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

Сканерлеу көлемі: оны гигабайтқа және жүктемеге қалай аудару

Көп есептеулер "Біз аз сканерлейміз" деген сөзден басталады. Шын мәнінде орташа күніне келетін беттен бөлек, пиктер (ай соңы, іс аяқтау, қорды жаппай цифрландыру) және қанша сканер параллель жұмыс істейтіні маңызды.

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

Жалпы бағыттар (сығымдау мен PDF түріне қатты тәуелді): қара-ақ 300 dpi беттің салмағы көбіне жүздеген килобайтқа сыйады, сұр — 1–2 МБ-қа жақын, түс — бірнеше мегабайт және одан жоғары. Екі жақты сканерлеу көлемді шамамен екі еселейді.

Одан әрі ағынды есептеңіз:

• күніне беттер (пик күндерін бөлек есептеңіз) = сканерлер × бет/мин × жұмыс минуттары;
• күніне көлем = күніне бет × беттің орташа өлшемі;
• жылдық көлем = күніне көлем × жұмыс күндері (немесе календарлық);
• сақтау мерзімі бойындағы өсім = жылдық көлем × жылдар саны;
• қор = +20–50% перескан, қосындылар және қызметтік файлдарға.

OCR мен индексация көбіне өздері сақтау орнына қарағанда серверді қатты жүктейді. Тану CPU мен жадты жақсы ұнатады, жаппай өңдеулер кезегі пайда болады. Егер бір уақытта сканерлеп, OCR жасап, жүйеге жүктеп және сапаны тексерсеңіз, бұл параллель ағындар. Оларға тұрақты жазу жылдамдығы, жеткілікті сервер өнімділігі және желі өткізу қабілеті керек.

Қарапайым мысал: қалыпты күні 20 000 бет, пикте — 60 000. Пикте OCR-ды бірден іске қоссаңыз, жүйе үш есе жүктемені тоқтаусыз көтеруі тиіс. Мұнда ресурстарды бөлу көмектеседі: OCR үшін бөлек торап (немесе бөлінген қуат), сақтау үшін бөлек контур және нақты өңдеу кезектері.

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

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

1. Кірістерді жинаңыз: түрлер бойынша сақтау мерзімдері, рұқсат рөлдері (кім не көре алады), күтілетін пайдаланушылар саны және SLA (қанша тоқтау рұқсат етіледі және қанша уақытта қалпына келтіру қажет). Пиктерді бөлек тіркеңіз: қашан жаппай сканерлеу және қашан жиі іздейді.

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

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

4. Резервтік көшіру мен қалпына келтіруді ойлаңыз: алдымен не қорғау керек — дерекқор, файлдық сақтау, іздеу индекстері, аудит журналдары.

5. Қосымша мен БД жүктемесіне сәйкес серверлерді таңдаңыз: бір уақытта жұмыс және индексация үшін CPU мен RAM, БД мен индекстер үшін жылдам дискілер, OCR үшін бөлек ресурстар (егер ауыр болса), файл жүктеу мен тарату үшін желі, мониторинг және өсімге резерв.

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

Сервер таңдау: архивте нақты неге назар аударылады

Сервер таңдағанда "бәрін үлкенірек алу" емес, жүйе қай жерде алғаш тар кететінін түсіну маңызды: дерекқор, іздеу, OCR, жүктеу немесе құжаттарды тарату.

Қосымша сервер және БД сервер: бірге ме, бөлек пе

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

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

CPU мен RAM: іздеу және OCR үшін қайсысы маңызды

Дерекқор мен іздеу индекстері үшін көбіне RAM маңызды: неғұрлым көп деректер мен индекстер жадта тұрса, дискіге сұраулар азаяды және жауап жылдам болады. CPU параллель сұраулар көп болғанда, күрделі фильтрлер, есептер және OCR кезінде шешуші болады.

Егер OCR сол серверлерде орындалса, CPU бойынша резерв жасаңыз және жаппай өңдеулер үшін «терезелер» бөліңіз. Әйтпесе жұмыс уақытында пайдаланушылар карточкаларды ашқанда және іздеу жасағанда баяулайды.

Дискілер: белсенді операциялар үшін IOPS және архив үшін сыйымдылық

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

Жылдам дискілер мен жоғары IOPS БД, индекстер және жаппай жүктеу үшін қажет. Үлкен сыйымдылық файлдық сақтауға және нұсқаларға маңызды.

Желі: жаппай жүктеу және тарату кезінде тар жерлер

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

Сақтау және бэкап — ақталмаған үмітсіздікке орын бермеңіз

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

Резервтік көшірмелерді RPO, RTO және бэкап терезесі арқылы қараған жөн.

• RPO — уақыт бойынша қанша деректі жоғалтуға дайынсыз.
• RTO — апаттан кейін архив қанша уақытта жұмысқа келуі керек.
• Бэкап терезесі — көшірме жасау кезінде жүйе қаншалықты төмендеуі мүмкін және осыға қанша уақыт бар.

Көшірмелерді "сол кабинетте" сақтамаңыз. Практикалық схема: бірінші көшірме негізгі жерде, екінші — басқа құрылғыда басқа зонада, үшінші — алаңнан тыс. Көп ұйымдар үшін 3-2-1 ережесі жұмыс істейді: 3 көшірме, екі түрлі медиа, біреуі алаңнан тыс.

Талаптарда кемінде мынаны анықтаңыз:

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

Бүтіндік тексеру көшірме жасаумен бірдей маңызды. Архив жылдар бойы «тірі» көрінуі мүмкін, бірақ қалпына келтіру қажет болғанда көшірме бүлінгені анықталуы мүмкін. Қалпына келтіру жоспары (не, қайдан және қанша уақытта) серверлер мен диск сатып алу жоспары сияқты нақты болуы керек.

Архитектура жобалаудағы типтік қателіктер

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

Ең жиі кездесетін қателіктер:

• Тек "таза" сканер көлемін есептеу. Шын мәнінде орынды резервтік көшірмелер, нұсқалар, индекстер, қызметтік базалар, аудит журналдары «жеп» жатады.
• Сканерлеуді тым жоғары сапада жасау. Барлық құжаттар үшін 600 dpi және түс қауіпсіз көрінуі мүмкін, бірақ көбіне пайдасы жоқ және көлемді 2–4 есе өсіреді. Көп тапсырмалар үшін 300 dpi және сұр жеткілікті, түсті тек ерекшеліктерге қалдырыңыз.
• Бәрін бір сақтау орнында жинау. Белсенді құжаттар мен ұзақ сақтау әр түрлі жүктеме профиліне ие. Қабаттарды бөлмесеңіз, жылдамдық зардап шегіп, шығын өседі.
• Қол жеткізуді "шамамен" баптау. Оңашаланған рөлдер болмаған соң қақтығыстар, артық тексерулер және оқиғаларды зерттеу қиындайды.
• Индексация мен OCR-ды бағаламау. Сканерлеу файл ағымын береді, ал ішіндегі мәтін бойынша іздеу — есептеу ағынын. Оны жоспарламасаңыз, архив шоғырлы сағаттарда баяулайды.

Мысал: бөлім келісімшарттарды "болып қалса" деген үмітпен максималды сапада архивке тасымалдайды. Бір жылдан кейін кей документтерді 5 жыл сақтауы керек, кейбірін 10 жыл, ал ескі құжаттар сирек сұралады. Егер сақтауды және скан сапасын қабаттарға бөлген болса, жылдам дисктердің көлемін азайтып, суық қабатқа көбірек сыйымдылық алуға болатын еді.

Сценарий мысалы: мерзімдерді, рұқсаттар мен сканерлеуді қалай ұштастыру

Бас кеңсесі мен 8 филиалы бар ұйымды елестетейік. Жалпы 200 қолданушы, соның 40-ы күн сайын архивпен белсенді жұмыс істейді. Сканерлеу үзіліссіз жүреді: барлығы күніне 6 000 бет, пик күндері (ай соңы) — 12 000 бетке дейін.

1) Сақтау мерзімі мен қолжетімділікті бөлу

Инфрақұрылым «көбейіп кетпес» үшін құжаттарды сақтау мерзімі мен құқықтарын бірге ескере отырып түрлерге бөліңіз. Мысалы:

• кадрлық құжаттар: 75 жыл, қолжетімділік HR + аудит;
• келісімшарттар: 5–10 жыл, қолжетімділік заңгерлер + қаржы;
• бастапқы бухгалтерлік құжаттар: 5 жыл, қолжетімділік бухгалтерия;
• ішкі өтініштер: 1–3 жыл, қолжетімділік бөлімше;
• анықтамалық материалдар: ауыстырылғанға дейін, қолжетімділік кең.

Осындай бөлініс сақтау саясаты үшін ғана емес, қай құжаттарды жылдам қабатта ұстауды, қай бөлімдерді рұқсат тұрғысынан күшейту керектігін, қай журналдар әдепкі бойынша қосылатынын және қай жерден көп бір уақытта сұраулар күту қажет екенін анықтайды.

2) 3 жылға өсу бағасы және жүктеме пиктері

Жай есептеу үшін «беттен гигабайтқа» аудару жеткілікті. Егер бір бет PDF/A форматында орташа 250 КБ (OCR қосқанда көбірек болуы мүмкін) алатын болса, күніне 6 000 бет шамамен 1,5 ГБ етеді.

22 жұмыс күнін есептесек, айына ~33 ГБ, жылына шамамен 400 ГБ және 3 жылда шамамен 1,2 ТБ. Индекстер, нұсқалар, тіркемелер, қызметтік файлдар және скан сапасының өсуін 30–50% қоссаңыз, 2 ТБ-ға жақындайсыз.

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

Сервер, сақтау және бэкапқа қандай тәсіл сәйкес келеді

Осындай сценарий үшін жиі жұмыс істейтін схема:

• ролдерді бөлу: қосымшаға бөлек сервер және дерекқорға бөлек сервер, сонда пайдаланушылардың пиктері БД-ны «ұстап» қоя алмайды;
• екі қабатты сақтау: соңғы 3–6 айға жылдам қабат және ұзақ сақтау үшін «суық» қабат;
• құжат кластарына бөлек саясат: ұзақ сақтау + қатаң рұқсат = бөлек бөлім және күшейтілген аудит;
• 3-2-1 қағидаты бойынша резервтік көшіру және бэкаптарға бөлек сақтау мерзімдері.

Қысқа чеклист және келесі қадамдар

Серверлер мен сақтау сатып алмас бұрын талаптарды бір-бірімен салыстыру үшін уақыт бөліңіз. Электрондық архивте жиі сәтсіздік технологияда емес, күтулерде: қанша сақтау керек, кім және қаншалықты жиі құжат ашады, күніне қанша скан келеді.

Жедел чеклист:

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

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

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

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