СКУД пен желі үшін бейнебитрейт пен архив көлемін есептеу

Неліктен бейнебақылау (ВН) мен СКУД-ты инфрақұрылым ретінде қарастырған дұрыс

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

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

Тәжірибеден мысал: поликлиникада дәліздер мен кірістерге камера қояды, архив 30 күн қажет. Алғашында бәрі жұмыс істейді. Кеңейтімнен кейін қарау баяулайды, ал бірнеше айдан соң сақтау жоспадан тез толатыны белгілі болады — себебі сапаны көтеріп, жазуды 24/7 қылған. Нәтижесінде жедел сатып алулар мен тоқтап қалу шығады.

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

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

Есептер үшін қажет бастапқы деректер

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

Камералар бойынша тек саны ғана емес, шешім қабылдау маңызды. Разрешение мен FPS базалық жүктемені анықтайды, бірақ кодек (H.264 немесе H.265), битрейт режимі (VBR немесе CBR) және сахна жағдайы соңғы орташа мәнді қатты өзгертеді. Бір камера тыныш дәлізде мен адамдар ағымы бар кірісте әртүрлі орташа битрейт береді. Түнде, жаңбырда немесе қарда «шу» көбейіп, битрейт өседі.

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

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

Сатып алудан бұрын анықтап алған жөн: типтік сахналар мен кесте (күн/түн, дала), тұлға мен нөмірлердің оқылу талаптары, алаңдар арасындағы байланыс каналдарының шектеулері, орналастыру жағдайлары (қуат, ИБП, шкафтағы орын, температура).

Жай ориентир: филиал мен орталық сервер арасында бар-жоғы 50 Мбит/с болса, 4 Мбит/с болатын 20 камера каналды толтырады. СКУД пен қызметтік трафик «сикіре» бастайды. Мұны монтаждан бұрын бастапқы деректер кезеңінде көру жақсы.

Битрейт қалай есептеледі: түсінікті схема және түзетулер

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

Қарапайым формула:

Битрейт жүйесі = камера битрейті (орташа) x камера саны x запас коэффициенті.

Шынайы ағынға ең қатты әсер ететіндер — FPS, разрешение, кодек (H.264/H.265) және «сахна күрделілігі»: желдіреген жапырақтар, қар, адамдар ағымы, түнгі фаралар. Сондықтан бірдей камералар әртүрлі орындағы орташа және шың битрейтте елеулі айырмашылық бере алады.

Паспорттық цифрларға көзіңізді жұмбаңыз. Дәл болу үшін тест жасаңыз: қажетті баптауларды қойып (разрешение, FPS, күн/түн режимі, VBR/CBR), 10–20 минут типтік уақытта және бөлек «ауыр» уақытта (шаңақ шап, түн, қар) жазып, орташа және шың битриттерін қараңыз.

Тағы бір жиі қате — накладные шығындарды ұмыту. Видеоға аудио (бар болса), аналитика метадеректері, қызметтік трафик және қозғалыс болғандағы «шипоноқтар» қосылады, әсіресе VBR кезінде.

Қор ретінде қарапайым ережелер қолданылады. Тыныш сахналар үшін 10–15% қызметтік трафик пен ауытқуға жетеді. Егер сахналар динамикалы болса, 20–30% салған дұрыс. 30%-дан асатын резерв белгісіз шарттарда немесе қатал талаптарда орындалады, әйтпесе артық төлемге әкеледі.

Мысал: 48 камера, тест бойынша орташа битрейт 4 Мбит/с. База: 48 x 4 = 192 Мбит/с. Динамика мен шыңдарға 25% қосқанда: шамамен 240 Мбит/с. Осы санды желі өткізу қабілетімен және жазу мүмкіндіктерімен салыстыруға болады.

Архив көлемін күндер бойынша қалай есептеу

Архив көлемі жазу битрейтінің жиынтық мәнінен есептеледі. Ыңғайлы тізбек: Мбит/с -> ГБ/күн -> ТБ N күнге. Практикалық ереже: 1 Мбит/с шамамен 10.5–11 ГБ/күн береді.

Формула бір камера үшін:

ГБ/сутки = (битрейт, Мбит/с * 86400) / 8 / 1024
ТБ на N дней = (ГБ/сутки * N) / 1024

Мысал: 30 камера, әрқайсысы 4 Мбит/с, жазу 24/7, сақтау 14 күн. Жиынтық битрейт 120 Мбит/с. Күндік көлем шамамен 120 * 10.55 = 1266 ГБ (шамамен 1.24 ТБ). 14 күнге шамамен 17.4 ТБ пайдалы архив шығады.

Қозғалыс бойынша жазу үнемді көрінеді, бірақ үнем әрдайым кепілдік емес. Егер камера адам көп дәлізге, аулада немесе жолға қараса, қозғалыс жетерлік болады. Түнде «матрица шуы» мен фаралар да срабатывание береді. Сондықтан есептеуде нақты үміт емес, белсенділік коэффициенті (мысалы 30–60%) алып, оны тестте тексерген дұрыс.

Пайдалы көлемге накладные шығындарды қосыңыз: файлдық жүйе мен VMS метадеректері (әдетте 10–20%), отказоустойчивтік үшін жоғалған сыйымдылық (RAID, hot spare). Егер репликация қажет болса, архив көлемі фактически 2 еселенуі мүмкін.

Өсімді бастаптан жоспарлау оң. Камераларды қосу, разрешение немесе FPS арттыру битрейтті күткеннен тез өсіреді. Көбінесе 20–30% бос сыйымдылық қалдыру және кеңею жолын анықтау дұрыс.

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

Видео мен СКУД үшін желі: сатып алудан бұрын не тексеру керек

Тіпті битрейт пен архивтің дәл есебі де желі жүктемені көтермесе нәтиже бермейді. Камералар, контроллерлер мен серверлерді сатып алмас бұрын тек порт жылдамдығын ғана емес, трафиктің толық жолын тексеріңіз: PoE-коммутатордан бастап ядроға және архивтің орналасқан жеріне дейін.

Міндетті тексерістер

Желі картасын бастап, видео мен СКУД ағындарының қай жерде тоғысатынын белгілеңіз. Содан кейін типтік тар орындарды қарап шығыңыз: аплинк пен магистраль өткізу қабілеті, агрегация нүктелері (трафикті қайда жинау және қандай топология қажет), PoE-бюджет (ИК-жарық пен «суық старқа» тағы), түйіндердің қуаты (шкафтағы ИБП, ядро, NVR/VMS), сондай-ақ «соңғы мили» сапасы (ескі кабельдер, ұзындық, кедергілер, далаға арналған гроза қорғанысы).

Қараулар желіні қалай жүктейді және оны қалай жеңуге болады

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

Мұнда юникаст пен мультикаст қай жерде қолданылатындығын түсіну маңызды. Егер ондаған клиент бірдей ағынды юникаст арқылы қарайтын болса, коммутаторлар мен аплинктердегі жүктеме еселенеді.

Видео бизнес-трафикті ығыстырмауы үшін алдын ала QoS және лимиттер белгілеңіз: критикалық сервистерге приоритет, бір уақытта қарауларға шектеулер, бейнебақылау мен СКУД-қа бөлек VLAN, қарауға құқық беру саясатының түсініктілігі.

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

Қолжетімділікті сегментациялау және құқықтарды басқару

Видеосистема мен СКУД-тың көбісі аппараттық ақаудан емес, қолжетімділіктен «ұшып кетеді». Бір пароль «барлығына» және офис желісімен араласқан орта жүйені қауіп-қатерге ұшыратады. Сондықтан құқықтар мен сегментация жобаның бөлігі болуы тиіс.

Рөлдер және минималды құқықтар

Күні бойы кім не істейтінін және оған не қажет еместігін анықтаңыз. Әдетте бірнеше рөл жеткілікті, оларды алдын ала жазған дұрыс. Мысалы: күзет (тірі бейнені қарау және оқиғалар бойынша іздеу, баптауларды өзгерту құқығы жоқ), өткізу қызметі (СКУД жүргізу және есептер), ИТ/ИБ администраторы (жаңартулар, есептер, желілік ережелер, резервтік көшірмелер), бөлім басшылары (тек өз аймағын оқуға), мердігерлер (уақытша қолжетімділік тапсырма үшін).

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

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

Желі және қашықтан қолжетімділік

Желі сегментациясы киберқауіптер мен «кездейсоқ» ақауларды азайтады. Міндетті минимум: камералар бөлек, СКУД бөлек, сақтау және басқару серверлері бөлек, оператор жұмыс орындары бөлек. Олардың арасында тек қажетті бағыттар ғана ашық болсын.

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

Мысал: күзет 40 камера көре алады, бірақ архивты экспорттау тек аға сменаға рұқсат, әр экспорт журналда тіркеледі. ИТ администраторы VMS пен контроллерлерді жаңартса да, СКУД аймақтарын «жымысқы» түрде өзгерту мүмкін болмайды — бәрі журналда жазылады.

Бейнебақылау мен СКУД-тың киберқауіптері және оларды төмендету

Камералар, СКУД контроллері және видеосерверлер — ноутбук пен принтер сияқты желілік құрылғылар. Егер оларды басып алса, салдары тек видеоға ғана емес: өтуді өшіру, оқиғаларды бұрмалау, объект карталарын алу және желіде плацдарм пайда болуы мүмкін. Сондықтан жүктеме есептерін қауіпсіздік талаптарымен толықтырыңыз.

Қайда жиі «сырттықтар» болады

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

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

Жұмыс істейтін минималды қорғаныс жиынтығы

Дисциплинаны бастаңыз. Көп жағдайда жеткілікті: пароль саясаты және бірегей есептік жазбалар (админдерге MFA мүмкін болса), қажетсіз порттарды жабу және артық сервистерді өшіру, нақты рөлдер мен құқықтар (күзет өзіне, ИТ өзіне, мердігер уақытша ғана), жаңартулар кестесі (1–2 құрылғыда тест және қызмет көрсету терезесі), конфигурациялардың резервтік көшірмелері (VMS/NVR баптаулары, карталар мен құқықтар тізімі, желі параметрлері).

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

Отказоустойчивтілік: талаптар мен компромистер

Отказоустойчивтік: ең алдымен не «қызметтен шығу» деп есептейтіндеріңізді анықтаңыз. Күзет үшін — «маңызды камералардан бейне жоқ», ИТ үшін — «архив жазылмайды», қауіпсіздік қызметі үшін — «СКУД картасымен өткізбейді». Сондықтан талаптарды қабаттар бойынша қалыптастырыңыз: камера және оның қуаты, коммутатор, байланыс каналы, VMS/NVR сервері, дискілер, СКУД базасы.

Сақтау көбіне баға мен тәуекел арасындағы басты компромиссқа айналады. RAID дискінің бұзылуын сақтайды, бірақ деректерді өшіруден, шифрлаудан немесе сервер бөлмесінің өртінен қорғамайды. Горячий резерв серверді тез қалпына келтіреді. Репликация мен бөлінген архив үлкен апаттарды еңсеруге көмектеседі, бірақ орын мен күрделілікті ұлғайтады.

Тапсырыс берушіге шешім қабылдауды жеңілдету үшін талаптарды түсінікті параметрлерге аударыңыз: RPO (қанша деректі жоғалтсақ болады, мысалы «5 минуттан көп емес»), RTO (қанша уақытта жүйе қалпына келуі тиіс, мысалы «критиалық постта 30 минут»), приоритеттер (қай камералар мен өту нүктелері «қызыл», қайсысы тоқтағанға шыдайды), сценарийлер (арна, сервер, СКУД базасы құлағанда не істейміз).

Қуатты жиі бағаламайды. N+1 маңызды жерлерде орындалуы тиіс: серверде қорек блогы, екі енгізу, шкафтар мен серверлік бөлме үшін ИБП, этажтардағы шкафтар үшін бөлек қорғаныс. Бірақ ИБП уақыт автономиясын есептемей қойса, бұл тек «қалпақша» ғана болады.

Қажет мониторинг. Дежурныйға не істен кеткені көрінуі тиіс: камера ма, коммутатор порты ма, диск орнында ма, RAID күйі, жазудың кешігуі, СКУД дерекқордың қолжетімділігі. Егер диск деградацияда болса және архив дерлік толы болса, жүйе формальды жұмыс істей береді, бірақ деректер жоғалып жатыр — оповещение болмаса, кеш байқалады.

Мұндай талаптарды ТЗ-ға енгізіп, қабылдау кезінде тексеру ыңғайлы.

Серверлер мен сақтау жүйесін таңдау

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

VMS серверіне қарағанда тек CPU емес, желі (әдетте кемінде 2x1GbE, ал ондаған камерада 10GbE ыңғайлы), RAM және дискілік подсистема маңызды. Жүктемеге 20–30% запас қосқан ыңғайлы: камералар сапасын көтеруі, аналитика модульдері қосылуы, архивті қарайтын пайдаланушылар саны артуы мүмкін.

Сақтауды үш көрсеткіш бойынша таңдайды: сыйымдылық, жазу жылдамдығы және параллель ағындар саны. Архив үшін HDD жиі қолайлы, бірақ жүйе, VMS базасы және кэш үшін SSD болу пайдалы (перемотка мен іздеуді жеделдетеді). RAID диск ақауын өткізбей жазуды жалғастыру үшін қажет. Массивтің 24/7 жазуды және бір уақытта оқу кезінде шыдайтынына көз жеткізіңіз.

СКУД ресурстық талаптары жеңілірек, бірақ үлкен өту нүктелері, оқиға саны және интеграциялар кезінде дерекқорға жүктеме келуі мүмкін (мысалы, AD-пен интеграция болса). Оны бөлек сервер немесе виртуал машина, дерекқордың резерві және журналдарға орын жоспарлау қажет.

Сатып алудан бұрын VMS/СКУД лицензия шектеулерін тексеріңіз: арналар саны, сервер саны шектеулері, серверге рұқсат етілген максималды битрейт, аналитика және пайдаланушы қолжетімділігі. Кейде «темір» жеткілікті болады, ал кеңейту лицензияларда тұрып қалады.

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

Нақты объектіге есеп сценарийі

Объект: 2 ғимарат, барлығы 60 IP-камера (36 іште, 24 далада) және 8 СКУД өту нүктесі. Ғимараттар арасында бір байланыс каналы. Архив талаптары: 30 күн.

Болжаулар (ТЗ-ге дейін нақты сценадан тестпен растау қажет): ішкі — 4 Мп, H.265, 15 fps; сыртқы — 8 Мп, H.265, 20 fps, қозғалыс пен детальдар көп.

1. Битрейт типтері бойынша. Ішкі: 36 x 3 Мбит/с = 108 Мбит/с. Сыртқы: 24 x 6 Мбит/с = 144 Мбит/с. Барлығы шың 252 Мбит/с.

2. Желідегі трафик сегменттері. Қызметтік трафик, VBR шыңдары және бір уақытта қарау үшін +20–30% қосыңыз. Шамамен 300–330 Мбит/с болады. Содан кейін шешіңіз: архив әр ғимаратта локалды жазыла ма, әлде бір жерде жазыла ма. Егер орталықта жазылса, канал екінші ғимараттың деректерін жергілікті аудандағыдай көтеруі тиіс.

3. 30 күнге архив. Көбіне пик емес, орташа ағынды алады. Мысалы, орташа 70% деп алған: 252 x 0.7 = 176 Мбит/с. Бұл күн сайын шамамен 1.9 ТБ және 30 күнге ~57 ТБ пайдалы архив береді. Өсу, қызметтік деректер және массив деградациясы үшін +20–30% қосқанда — шикізат сыйымдылығы ретінде шамамен 70–75 ТБ жоспарлау дұрыс. Диск қателігін жеңу үшін RAID 6 жиі таңдалады.

4. Қолжетімділік пен тұрақтылық. Камералар мен СКУД-ты VLAN-дарға бөліп, қолжетімділікті аймақтар бойынша беріңіз: күзет бәрін көреді, басшылар тек өз этаждарын қарайды, мердігерлер тек таңдалған камералар мен уақытқа ғана кіреді. Барлық әрекеттер журналданады. Егер ғимараттар арасындағы канал құласа, әр ғимарат локалды түрде жазуды жалғастырады, ал орталық пост тек қолжетімді ағындарды көреді.

Жобаны қымбаттатын жиі қателіктер

Ең қымбат қате — бейнебақылауды «шамалап» есептеп, кейін желіні, дискілер мен лицензияларды нақты іске қосқанда сатып алу. Тіпті мұқият есептер де эксплуатациялық детальдарды ұмытып қалса, үлкен сандарға айналады.

Бірінші қате — Мбит/с пен Мбайт/с-ты араластырып алу және накладные шығындарды елемеу. «Таза» ағынға күрделі сахнадан (ұлғайған халық, қар, ағаш жапырақтары) туатын шыңдар, қызметтік трафик, кейде қарауға арналған қосымша ағындар қосылады. Нәтижесінде 1 Гбит/с линк кенеттен толып қалады.

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

Үшінші — камералар мен СКУД контроллерлерін офис желісіне араластырып қою. Бір жұққан жұмыс станциясы бүкіл объектіні тоқтатуы мүмкін.

Төртінші — дискіні тек терабайтқа қарай таңдау. Жазу ресурсы, жылдамдық пен параллель ағындар саны маңызды. Кейін 40–60 камерада кадр өткізіп алу және архив деградациясы басталуы мүмкін.

Бесінші — жаңартулар мен конфигурациялардың резервтері жоқ. Сервер алынып тасталғанда қолданушыларды, кестелерді, құқықтарды және карталарды қайта құрастыруға уақыт кетеді.

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

ТЗ және сатып алу алдында қысқа чек-лист

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

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

• Камералар мен режимдер: разрешение, FPS, кодек, типтік сахна (күн/түн), дыбыс пен аналитика қажет жерлер. Бөлек — сақтау мерзімі және қолжетімділік рөлдері.
• Желі және қуат: шкафтегі аплинктер жылдамдығы, алаңдар арасындағы арналар, PoE-бюджет, порттарға запас, не нәрсе ИБП-дан қоректенеді және қанша минутқа.
• Есептермен запас: жиынтық кіріс трафигі, шыңдар, күндік архив көлемі және мерзім, плюс резерв (әдетте 20–30%). Бірден RAID қажет пе және диск істен шыққанда қандай жоғалтуға рұқсат етіледі.
• Қауіпсіздік: камералар, VMS/NVR және СКУД үшін бөлек VLAN/сегменттер, бірегей есептер, пароль саясаты, прошивкаларды жаңарту, журналдар мен олардың сақтау мерзімі.
• Отказоустойчивтік және қалпына келтіру: сервер/диск/арна істен шыққанда не жұмыс істеуі керек, қабылданатын тоқтау уақыты, резервтік конфигурациялар қайда және кім жауапты.

Егер жоба «ключ бойынша» жасалса, тапсырыс берушіден жеткізушіден осы тармақтарды жеткізіп беруін талап етіңіз.

Келесі қадамдар: есептен енгізуге өту

Формулалар цифр бергеннен кейін оларды нақты жоспарға айналдыру маңызды. Әйтпесе есептер кестеде қалады, ал объектіде желі жүктеліп, дискілер толып, құқықтар дау тудырады.

Нәтижелерді ИТ, қауіпсіздік және эксплуатация бірдей оқитын құжатқа жинаңыз. Саннан басқа допущения (кодек, FPS, сахналар, сақтау күндері, шың жүктемелер) және отказоустойчивтік талаптары көрсетілуі тиіс.

Практикалық қадам — қысқа пилот. 1–2 типтік аймақты (мысалы кіріс және қойма) таңдап, нақты битрейтті, жазуға және қарауға жүктемені өлшеңіз. Көбінесе дәл осы жерде түнгі «шум», ағынның өсуі және диск толу жылдамдығы байқалады.

Сатып алу мен монтаждан бұрын операциялық ережелерді келісіңіз: кім камераларды, СКУД, VMS/NVR және желіні басқарады; қалай қолжетімділік беріледі және журнал жүргізіледі; жаңартулар қалай қойылады және кім тоқтауларды қабылдайды; инцидент деген не және жауап уақыты қандай; архив пен резервтердің жұмыс қабілеті қалай тексеріледі.

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

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