Разработка системы видеонаблюдения: программная архитектура, хранение, аналитика и эксплуатация

1) Введение

Разработка системы видеонаблюдения — это не только подбор камер и прокладка сети. В масштабируемых проектах (десятки, сотни, тысячи камер) решающим становится программный контур: как принимать видеопотоки, как их писать и хранить, как обеспечивать поиск по архиву, как организовать доступ и аудит, как интегрировать аналитику и внешние системы, и как поддерживать всё это 24/7.

Если аппаратная часть задаёт “качество картинки” и физические ограничения, то программная часть определяет:

• предсказуемость задержки просмотра и перемотки;

• глубину архива и стоимость хранения;

• отказоустойчивость при обрывах связи и падениях узлов;

• скорость расследований за счёт событий и метаданных;

• безопасность (кто что смотрел, что выгружал и когда);

• удобство эксплуатации (мониторинг, обновления, масштабирование).

2) Базовая модель системы видеонаблюдения

В программно-ориентированной модели систему удобно разложить на слои.

2.1. Источники видео

Чаще всего это IP-камеры, которые отдают поток по стандартным механизмам:

• RTSP (передача медиапотока),

• ONVIF (обнаружение устройств, управление и события, если камера их поддерживает),

• иногда — дополнительные профили/протоколы производителей.

С точки зрения ПО камера — это endpoint, который может:

• отдавать один или несколько потоков (основной/субпоток),

• генерировать события (движение, саботаж, тревоги),

• принимать команды (PTZ, пресеты, настройки качества).

2.2. Транспорт и сеть

Программная часть напрямую зависит от сетевых условий:

• пропускная способность и потери пакетов влияют на качество записи;

• NAT и сегментация осложняют доступ;

• VLAN/QoS важны, если видео трафик конкурирует с рабочим.

На практике сеть — это “невидимая часть ПО”: проблемы в сети проявляются как “прыгающий fps”, “рассыпание картинки”, “дырки в архиве”.

2.3. Серверная роль: VMS/NVR

VMS (Video Management System) в логическом смысле включает:

• приём потоков (ingest),

• запись (recording),

• хранение (storage),

• индекс/метаданные (events/index),

• воспроизведение (playback/streaming),

• управление устройствами (control plane),

• пользователей и права (authZ),

• наблюдаемость (logs/metrics/alerts).

2.4. Клиенты

• рабочее место оператора (desktop/web),

• мобильный клиент,

• видеостена/мультивью.

Клиент — это не “плеер”, а часть системы, которая требует:

• авторизации,

• получения списков камер,

• гибких режимов просмотра,

• таймлайна архива,

• экспорта фрагментов с фиксацией события.

2.5. Хранилище

Ключевой узел стоимости владения. Возможные варианты:

• локальные диски на сервере записи,

• сетевое хранилище,

• объектное хранилище (для больших архивов и распределённых систем).

3) Требования и проектирование (software-first)

До архитектуры и кода нужно формализовать требования так, чтобы их можно было “посчитать”.

3.1. Параметры видео

• количество камер;

• разрешение и fps;

• кодек (H.264/H.265 и т.п.);

• битрейт (CBR/VBR) и его профиль;

• основной поток и субпоток (субпоток критичен для экономии при мультипросмотре).

3.2. Глубина архива и сценарии доступа

• сколько дней хранить видео;

• как часто смотрят архив и на какие периоды;

• нужен ли быстрый поиск “за минуту”, или допустимо ждать;

• нужен ли экспорт для доказательной базы.

3.3. Режимы записи

• постоянная запись 24/7;

• по движению (камера или серверная детекция);

• по событию (входы/выходы, тревоги, расписания);

• комбинированные режимы (например, 24/7 на низком качестве + высокий поток по событию).

3.4. SLA и отказоустойчивость

• допустимый простой системы;

• RPO/RTO (сколько данных можно потерять и как быстро восстановиться);

• требования к непрерывности записи при обрывах связи.

3.5. Безопасность и аудит

• роли и доступ (RBAC);

• аудит просмотра и экспорта;

• ограничения по выгрузке;

• шифрование и управление ключами (если требуется).

4) Программная архитектура VMS: из каких компонентов состоит

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

4.1. Ingest: приём потоков

Задачи ingest-слоя:

• подключиться к источнику (камера/энкодер);

• стабильно принимать RTSP/RTP поток;

• контролировать состояние (потери, разрыв, реконнект);

• выбирать профиль (основной/субпоток);

• при необходимости синхронизировать время (таймстемпы).

Типичные сложности:

• нестабильные RTSP-сессии;

• разные реализации протоколов у производителей;

• “плавающее” качество при потерях пакетов;

• некорректные таймкоды и дрейф времени.

4.2. Recorder: запись и сегментация

Запись обычно организуют через сегменты (чанки) фиксированной длительности, например условно 1–5 минут (конкретный размер — решение архитектуры). Это позволяет:

• быстро адресовать архив по времени;

• упрощать удаление по политике ретенции;

• уменьшать риск потери больших фрагментов при сбое.

Recorder решает:

• запись потоков в контейнер;

• контроль целостности;

• ротацию сегментов;

• формирование “карты архива” по таймлайну.

4.3. Transmux/Transcode: когда нужно преобразование

Два разных класса операций:

• Transmux — перепаковка потока в другой контейнер без пересчёта видео (дешевле по CPU).

• Transcode — перекодирование (дороже, увеличивает задержку и требует ресурсов).

В идеале запись делается без перекодирования (минимум затрат), а трансляция в клиент может требовать transmux/transcode в зависимости от формата, требований к задержке и совместимости браузеров/клиентов.

4.4. Storage Manager: управление хранением

Задачи:

• хранение сегментов;

• политики ретенции (удаление старых данных);

• перемещение между уровнями (tiering), если есть “горячее/холодное” хранение;

• репликация или интеграция с системой резервного копирования.

4.5. Index/Metadata: метаданные и поиск

Поиск “по времени” — это минимум. Для практичной системы нужны метаданные:

• события (движение, тревога, саботаж, пересечение линии);

• статусы камеры (offline, низкий fps, потери);

• данные аналитики (объекты, треки, классы);

• привязка к пользователям и действиям (кто выгружал фрагменты).

Метаданные хранятся отдельно от видео, чтобы:

• быстро строить таймлайны;

• фильтровать по событиям;

• ускорять расследования.

4.6. Playback/Streaming: доставка видео клиенту

Сервер воспроизведения должен:

• отдавать live и архив;

• обеспечивать перемотку и скачки по времени;

• работать в разных сетевых условиях.

Варианты доставки (как архитектурные подходы):

• сегментные протоколы (удобно для масштабирования, но задержка может быть выше);

• низколатентные подходы (когда критична “почти реальная” картинка).

Выбор влияет на:

• задержку live,

• нагрузку на CPU,

• сложность инфраструктуры,

• совместимость клиентов.

4.7. Control plane: управление конфигурацией и состоянием

Отдельный контур:

• регистрация камер и учётных данных;

• управление профилями потока;

• health-check камер;

• политики записи и расписания;

• централизованные настройки и массовые операции.

4.8. AuthN/AuthZ: пользователи, роли, ACL

Для видеонаблюдения критично разграничение:

• доступ к камерам (на уровне отдельных камер и групп);

• доступ к архиву (возможность просмотра и глубина);

• экспорт (разрешение, лимиты, водяные знаки);

• администрирование и управление настройками.

Нормальная модель включает:

• RBAC (роль → набор прав),

• ACL (на объекты: камеры, группы, площадки),

• аудит действий (просмотр, поиск, экспорт, удаление).

4.9. Observability: логи, метрики, алерты

Без наблюдаемости VMS не эксплуатируется. Минимум:

• метрики по каждой камере: fps, bitrate, drops, reconnects;

• метрики записи: скорость записи, ошибки, заполнение дисков;

• метрики задержки воспроизведения;

• логи событий и корреляция по идентификаторам;

• алерты: камера offline, превышение latency, заполнение хранилища, массовые разрывы.

5) Хранение видео: форматы, сегменты, таймкоды и “стоимость перемотки”

5.1. Контейнеры и сегментация

На уровне концепции запись почти всегда делается в контейнеры, пригодные для:

• хранения фрагментов,

• воспроизведения,

• экспорта.

Ключевой механизм — сегментация по времени. Она влияет на:

• гранулярность удаления (retention);

• скорость восстановления после сбоя;

• удобство экспорта.

5.2. GOP и keyframes: почему перемотка может быть “тяжёлой”

Для быстрого скраббинга по таймлайну нужны опорные кадры (keyframes). Если ключевые кадры редкие, перемотка и “быстрый просмотр” усложняются:

• нужно декодировать больше фрагментов до нужного момента;

• выше нагрузка на сервер/клиент.

Это связывает программную часть с настройками камеры (интервал I-frame) и режимом записи.

5.3. Файловая система vs объектное хранилище

• Файловая система проще для небольших установок и локальных NVR.

• Объектное хранилище удобнее для масштабирования и распределённых сценариев, но требует продуманной схемы индексирования и доступа, а также контроля стоимости операций.

6) События и аналитика: как строится программный слой “не просто запись”

6.1. Детектор движения: на камере или на сервере

Варианты:

• детекция на камере: камера генерирует событие, сервер фиксирует и пишет/помечает.

  • плюсы: меньше серверной нагрузки,

  • минусы: качество и гибкость зависят от камеры, бывают ложные срабатывания.

• детекция на сервере: сервер анализирует поток.

  • плюсы: единый алгоритм, гибкость, единые настройки,

  • минусы: CPU/GPU нагрузка и необходимость стабильного декодирования.

В крупных системах часто комбинируют: базовые события берут с камер, а углублённую аналитику считают централизованно.

6.2. Событийная модель

События могут поступать из разных источников:

• камера (motion, tamper, line crossing),

• внешние датчики и системы (СКУД, пожарка),

• оператор (ручная отметка инцидента).

События должны:

• иметь таймстемп,

• ссылку на камеру,

• тип и параметры,

• связь с архивом (чтобы быстро открыть фрагмент “за 30 секунд до события”).

6.3. AI/ML пайплайн (если требуется аналитика)

Типовая схема:

• декодирование кадров (или выборка кадров);

• очередь задач инференса;

• инференс модели (детекция объектов/лиц/номеров — в зависимости от требований и правовых ограничений);

• трекинг и постобработка (объединение детекций во времени);

• запись результатов в хранилище метаданных;

• поиск и фильтры в UI.

Даже если аналитика простая, важно проектировать её как отдельный сервис, чтобы не “ломать” ingest/recording из-за вычислительной нагрузки.

7) Клиентские приложения и UX: что нужно оператору

Ключевые сценарии:

• live просмотр 1–16–64 камер (мультивью);

• быстрое переключение групп камер;

• таймлайн архива с “пробелами” и событиями;

• поиск по событиям;

• экспорт фрагмента с отметкой времени и водяными знаками;

• быстрый переход “по тревоге”.

Для программной части важно:

• отдавать субпоток для мультивью (экономия трафика и CPU);

• уметь быстро поднимать основной поток по клику;

• обеспечивать стабильную перемотку по таймлайну без зависаний.

8) Интеграции: почему без API система быстро становится “островом”

Интеграции обычно нужны с:

• СКУД (вход/выход → событие и привязка видео);

• пожарной сигнализацией (тревоги);

• охранными датчиками;

• SIEM/службой безопасности (аудит и экспорт событий);

• Service Desk (заявки на неисправности камер).

Программно это решается через:

• API (для получения камер, архива, событий),

• webhooks/шину событий,

• коннекторы и правила корреляции.

9) Безопасность (программная): модель угроз и практические меры

Типовые угрозы:

• компрометация камер (слабые пароли, уязвимые прошивки);

• перехват потоков в сети;

• несанкционированный доступ к архиву;

• утечка экспортированных фрагментов;

• внутренние злоупотребления (оператор “смотрит не то”, что должен).

Практические меры на программном уровне:

• строгая модель ролей и прав (RBAC/ACL);

• аудит просмотров и экспортов;

• ограничения экспорта (по ролям, по времени, лимитами);

• защита админ-доступа (MFA/политики, где это возможно);

• сегментация сети камер и серверов;

• шифрование “на хранении” и контроль ключей (если требуется).

10) Масштабирование и отказоустойчивость

10.1. Горизонтальное масштабирование ingest/recording

В крупных системах ingest/recording масштабируют горизонтально:

• камеры распределяются по узлам записи (шардирование по камерам);

• балансировка учитывает битрейт и нагрузку на диски/CPU;

• при отказе узла нужна стратегия восстановления.

10.2. Репликация метаданных и хранилища

Даже если видео хранится “как файлы”, метаданные должны быть отказоустойчивы:

• база метаданных в HA-конфигурации;

• события не теряются при сбоях;

• есть контроль консистентности таймлайна.

10.3. Edge-recording и backfill

Для площадок со слабой связью применяют edge-подход:

• запись на краю (в регистраторе/на камере/на локальном узле),

• при восстановлении связи система “догружает” фрагменты на центральное хранилище (backfill).

Это снижает потери архива при обрывах.

11) Тестирование и эксплуатация

11.1. Нагрузочное тестирование

Тестируют не “камеры отдельно”, а систему целиком:

• суммарный битрейт ingest;

• запись на диск (IOPS/throughput);

• одновременные просмотры live и архива;

• экспорт фрагментов.

11.2. Тесты деградации сети

Проверяют:

• потерю пакетов;

• jitter;

• обрывы RTSP;

• восстановление после разрыва.

11.3. Мониторинг ключевых метрик

Минимальный набор:

• online/offline камер,

• fps/bitrate/drops/reconnect,

• заполнение дисков и темпы роста архива,

• ошибки записи,

• задержка воспроизведения,

• SLA по доступности.

11.4. Обновления без простоя

Для сервисной архитектуры применяют:

• rolling update,

• blue/green,

• канареечные релизы (часть камер переводится на новый узел).

Цель — обновлять компоненты без потери записи и с минимальным влиянием на клиентов.

12) Технологический стек: что обычно используют в разработке

Выбор технологий зависит от масштаба и команды, но отраслевые паттерны устойчивы.

12.1. Языки

• C/C++ — медиа-слой, высокопроизводительные части, интеграции с низкоуровневыми библиотеками.

• Go / Rust — сервисы ingest/control plane/metadata, высокая производительность, удобство деплоя.

• Java/Kotlin / .NET — enterprise-уровень, интеграции, богатая экосистема.

• Python — аналитика и ML-инференс, прототипирование, обработка событий.

12.2. Медиа-инструменты

Типовые библиотеки и фреймворки медиа-обработки:

• FFmpeg (декод/энкод/трансмультиплексирование),

• GStreamer (пайплайны обработки потоков).

12.3. Очереди и кэш

• очереди сообщений для событий и задач аналитики (Kafka/RabbitMQ как примеры классов решений);

• кэш (например, Redis) для сессий, быстрых индексов и rate-limits.

12.4. Хранилища данных

• реляционная БД для конфигурации и прав (часто PostgreSQL-класс);

• колоночные/аналитические хранилища для событий и метрик (в зависимости от объёма);

• объектное хранилище для видеоархивов при больших масштабах.

12.5. Контейнеризация и оркестрация

Для масштабируемых систем используют:

• контейнеры (Docker-класс),

• оркестрацию (Kubernetes-класс),

• инфраструктурный мониторинг и алертинг.

13) Плюсы и минусы разработки собственной VMS по сравнению с готовыми решениями

Плюсы

• Точная адаптация под процессы безопасности и эксплуатации конкретной организации.

• Контроль над архитектурой хранения, метаданными и интеграциями.

• Возможность встроить аналитику и события как “первый класс”, а не отдельный модуль.

• Оптимизация под конкретные условия сети и инфраструктуры.

• Независимость от лицензий и ограничений готовой платформы (при зрелой команде).

Минусы

• Высокая стоимость разработки и сопровождения 24/7.

• Сложность медиа-стека: разные камеры и протоколы дают нестабильные edge-кейсы.

• Требуются компетенции по storage, network, security, observability.

• Риски качества и сроков: зрелая VMS — это продукт, а не “проект на пару месяцев”.

• Постоянная ответственность за обновления безопасности (камеры, серверы, библиотеки, клиенты).

14) FAQ

Как считать объём архива и диски?

Нужно знать битрейт каждой камеры, режим записи и срок хранения. Затем считать общий объём: суммарный битрейт × время хранения, плюс запас на служебные данные, пики и фрагментацию. В крупных системах дополнительно учитывают репликацию и overhead хранилища.

Что выбрать для low-latency просмотра?

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

Где лучше делать детекцию движения?

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

Как защититься от компрометации камер?

Программные меры не заменяют сетевые, но обязательны:

• отдельная сеть для камер,

• строгие учётные данные и политика паролей,

• минимизация открытых портов,

• ограничение доступа к VMS по ролям,

• аудит действий, особенно экспортов.

Как организовать multi-tenant (мультиобъектную) систему?

Нужны:

• строгая изоляция по тенантам на уровне БД и ACL,

• отдельные ключи/политики доступа,

• раздельные квоты хранения и лимиты просмотра,

• аудит по тенанту и возможность независимого экспорта/удаления.