Расчет битрейта и архива видеонаблюдения для СКУД и сети

Зачем смотреть на ВН и СКУД как на инфраструктуру

Видеонаблюдение и СКУД часто стартуют с идеи: «поставим камеры и турникет». На практике уже в первые недели проект упирается в сеть, хранение и доступы. Камеры создают постоянный поток данных, СКУД пишет события, а пользователи хотят смотреть видео с телефона, быстро находить архив и при этом не получать лишних прав.

Если относиться к системе как к инфраструктуре, вы заранее считаете нагрузку и понимаете, где будут узкие места. Обычно первыми «ломаются» не камеры, а канал до коммутатора, место на дисках, учетные записи с одинаковыми паролями и хаотичные права доступа (например, когда охрана видит больше, чем должна).

Пример из жизни: в поликлинике ставят камеры в коридорах и на входах, архив нужен на 30 дней. Пока камер мало, все работает. После расширения начинает тормозить просмотр, а через пару месяцев выясняется, что хранилище заполняется быстрее плана, потому что повысили качество и включили запись 24/7. Итог - срочные закупки и простой работ.

До любых расчетов полезно согласовать цели и риски: что именно фиксируем, кто и откуда смотрит, сколько дней хранить, что делаем при сбое питания или сети, какой бюджет допустим на рост.

На старте соберите вводные: план помещений и точки установки, требования к качеству и сроку хранения, схему сети (или хотя бы список коммутаторов и каналов), роли пользователей и правила доступа, требования к отказоустойчивости и поддержке. Тогда проект становится управляемым, а цифры в расчетах начинают совпадать с реальной эксплуатацией.

Исходные данные, без которых расчеты будут мимо

Чтобы расчет битрейта и архива получился близким к реальности, сначала соберите «паспорт» системы. Иначе на бумаге все выглядит красиво, а после запуска сеть или хранилище не выдерживают.

По камерам важно знать не только количество. Разрешение и FPS задают базовую нагрузку, но итог сильно меняют кодек (H.264 или H.265), режим битрейта (VBR или CBR) и сама сцена. Одна и та же камера в пустом коридоре и у входа с потоком людей дает разный средний битрейт. Ночью, в дождь или снегопад из-за «шума» он тоже растет.

По СКУД нужны точки прохода и логика работы: сколько дверей, какие контроллеры, будут ли они работать онлайн или держать доступ офлайн при обрыве связи. Оцените поток событий (проходы, тревоги, попытки доступа) и то, кто и откуда будет этим управлять.

По архиву заранее решите глубину хранения и качество, которое реально нужно для разборов. Частая ошибка - просить «максимум» везде, хотя для части зон достаточно меньшего FPS или более сильного сжатия.

Минимум, который стоит зафиксировать до закупки: типовые сцены и расписание (день/ночь, улица), требования к «читаемости» лиц и номеров, каналы связи между площадками и их ограничения, а также условия размещения (питание, ИБП, место в шкафах или стойках, температура).

Простой ориентир: если между филиалом и центральным сервером всего 50 Мбит/с, то 20 камер по 4 Мбит/с уже упрутся в канал. А СКУД и служебный трафик начнут «прыгать». Это лучше увидеть на этапе исходных данных, а не после монтажа.

Как считать битрейт: понятная схема и поправки

Базовая логика простая: берете средний битрейт одной камеры, умножаете на число камер и добавляете запас. От этой цифры дальше зависят сеть, сервер и хранилище.

Черновая формула:

Битрейт системы = битрейт камеры (средний) 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 Мбит/с, запись круглосуточно, хранение 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 и с многофакторной проверкой для админов, доступ по ролям и по времени (например, на 2 часа под инцидент), запрет прямого доступа к камерам из пользовательских сетей, отдельный канал администрирования для обслуживающих инженеров.

Пример: охрана видит 40 камер, но выгрузка архива разрешена только старшему смены, и каждый экспорт фиксируется. ИТ-администратор обновляет VMS и контроллеры, но не может «тихо» менять зоны доступа в СКУД без следа в журнале.

Киберриски видеонаблюдения и СКУД и как их снизить

Видеокамеры, контроллеры СКУД и видеосерверы - такие же сетевые устройства, как ноутбуки и принтеры. Если их взломают, последствия будут не только про видео: злоумышленник может отключить точки прохода, подменить события, получить карту объекта и удобный плацдарм в вашей сети. Поэтому расчеты по нагрузке стоит дополнять простыми требованиями по безопасности.

Где чаще всего «дырки»

Проблемы обычно бытовые: пароли по умолчанию и одинаковые пароли на десятках устройств, устаревшие прошивки камер/NVR/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, но полезно иметь SSD под систему, базу VMS и кэш (ускоряет перемотку и поиск). 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 ТБ в сутки и около 57 ТБ на 30 дней. Плюс запас под рост, служебные данные и деградацию массива: еще 20-30%. По итогу разумно планировать порядка 70-75 ТБ сырой емкости. Для переживания отказа дисков часто выбирают RAID 6.

4. Доступы и устойчивость. Разделите камеры и СКУД по VLAN, а доступ выдавайте по зонам: охрана видит все, руководители - только свои этажи, подрядчики - только выбранные камеры и на время. Все действия (просмотр, экспорт, изменения) логируются. Если межзданный канал падает, локальная запись в каждом здании продолжается, а центральный пост видит только доступные потоки до восстановления связи.

Частые ошибки, из-за которых проект дорожает

Самая дорогая ошибка - считать видеонаблюдение «примерно», а потом докупать сеть, диски и лицензии уже по факту. Даже аккуратные расчеты могут «поплыть», если забыть про детали, которые в эксплуатации превращаются в большие числа.

Первая ловушка - путаница между Мбит/с и Мбайт/с и игнорирование накладных расходов. К «чистому» потоку добавляются пики из-за сложной сцены (толпа, снег, деревья), служебный трафик, иногда второй поток для просмотра. В результате линк на 1 Гбит/с внезапно оказывается занят.

Вторая - ставка на запись «по движению» как на гарантированную экономию. В ТЗ это выглядит красиво, но после инцидентов службу безопасности часто просят включить постоянную запись или повысить FPS/качество. Если хранилище и сеть рассчитаны впритык, проект резко дорожает.

Третья - оставлять камеры и контроллеры СКУД в офисной сети без сегментации и нормальных прав. Одна зараженная рабочая станция может привести к простоям, срочному выезду подрядчиков и замене оборудования.

Четвертая - выбирать диски только по терабайтам. Важны ресурс записи, скорость и число параллельных потоков. Типичный сценарий: поставили «большие» диски, а на 40-60 камерах начинаются пропуски кадров и деградация архива.

Пятая - нет плана обновлений и резервных копий конфигураций. После сбоя или замены сервера приходится заново собирать пользователей, расписания, права и карты доступа.

Если коротко, перед закупкой стоит: зафиксировать режимы записи и кто может их менять, заложить запас по сети на пики, отделить видео и СКУД в отдельные сегменты с контролем доступа, подбирать диски по нагрузке записи (не только по емкости), настроить бэкапы конфигураций и план обновлений.

Короткий чеклист перед ТЗ и закупкой

Перед тем как писать ТЗ и запрашивать коммерческие предложения, полезно свести требования на одну страницу. Это экономит недели согласований и защищает от сюрпризов, когда выясняется, что сеть не тянет, а архив не помещается.

Зафиксируйте числа и правила:

• Камеры и режимы: разрешение, FPS, кодек, типовая сцена (день/ночь), где нужен звук и аналитика. Отдельно - срок хранения и роли доступа.
• Сеть и питание: скорость аплинков в шкафах, межплощадочные каналы, PoE-бюджет, запас по портам, что питается от ИБП и на сколько минут.
• Расчеты с запасом: суммарный входящий трафик, пики, объем архива на сутки и на срок, плюс резерв (часто 20-30%). Сразу определить, нужен ли RAID и какой уровень допустим по потере диска.
• Безопасность: отдельные VLAN/сегменты для камер, VMS/NVR и СКУД, уникальные учетные записи, политика паролей, обновления прошивок, включенные журналы и срок их хранения.
• Отказоустойчивость и восстановление: что должно работать при отказе сервера/диска/канала, допустимое время простоя, где лежат резервные конфигурации и кто отвечает за восстановление.

Если проект делается «под ключ», попросите подрядчика приложить эти пункты к проекту до поставки.

Следующие шаги: как перейти от расчетов к внедрению

Когда формулы дали цифры, важно превратить их в понятный план. Иначе расчеты останутся в таблице, а на объекте появятся перегруженная сеть, заполненные диски и спорные права доступа.

Сведите результаты в документ, который одинаково читают ИТ, безопасность и эксплуатация. Помимо чисел, в нем должны быть допущения (кодек, FPS, сцены, дни хранения, пиковые нагрузки) и требования к отказоустойчивости.

Практичный шаг дальше - короткий пилот. Выберите 1-2 типовые зоны (например, входная группа и склад) и замерьте реальный битрейт, нагрузку на запись и на просмотр. Часто именно здесь всплывает, что ночью картинка «шумит», поток растет, а диски заполняются быстрее.

Перед закупкой и монтажом согласуйте операционные правила: кто администрирует камеры, СКУД, VMS/NVR и сетевые настройки; кто и как выдает доступы и как ведется журналирование; как ставятся обновления и кто принимает простои; что считается инцидентом и как быстро реагируют; как проверяется работоспособность архива и резервов.

Дальше подбирайте оборудование и схему внедрения под объект, а не «по среднему». Проверьте, что серверы, хранилище и сеть выдерживают пиковые просмотры, одновременный экспорт видео и рост системы.

Если нужен подрядчик, удобнее, когда одна команда отвечает за сеть, серверы, хранилище и ввод в эксплуатацию. В Казахстане GSE.kz закрывает эти задачи как системный интегратор и одновременно производит компьютеры и серверы в Казахстане, что бывает полезно для поддержки и планового расширения инфраструктуры.