Облачный видеомониторинг на Android: гайд по разработке в 2026

Почему Фора Софт написала этот гайд

Фора Софт почти два десятилетия выпускает облачные продукты для видео и видеомониторинга — cloud-native пайплайны приёма, multi-tenant админки, AI-аналитику движения и Android-клиенты, которыми реально пользуются операторы в поле. Мы построили те части, которые делают облачный видеомониторинг на Android работающим: облачную платформу видеонаблюдения с AI, обрабатывающую более 2 000 клиентских взаимодействий в реальном времени в день на более чем 10 000 объектах, мост SIP–WebRTC для потоков IP-домофонов, Android MDM-платформу, обслуживающую парки в 10 000 устройств, и NetCamStudio-подобный инструмент многокамерного приёма с контролем кодеков.

Этот гайд написан для владельцев продуктов, директоров по безопасности и CTO, которые планируют разработку кастомной облачной VMS на Android, — будь то новый SaaS, облачное дополнение к существующей on-prem VMS или управляемый сервис для реселлеров. Сначала пройдём по коммерческим решениям (архитектура, хранение, идентификация, где живёт AI), затем по модели бюджета и подводным камням. Каждая рекомендация основана на наших проектах, а не на маркетинге вендоров.

Наша команда использует agent-assisted разработку — внутренние пайплайны на Claude и Cursor, — чтобы сжимать рутинную работу в любом проекте облачной VMS: обвязку приёма потоков, админский CRUD, FCM push, базовый UI настроек. Это позволяет тратить бюджет на то, что действительно важно: производительность видео, идентификацию, AI и интеграции, за которые платит клиент. Поэтому оценки на 2026 у нас заметно ниже типичных отраслевых значений 2024–2025, которые вы могли собрать у других подрядчиков.

Облачная VMS против on-prem VMS с Android-приложением

Эти две вещи легко перепутать, и путаница стоит месяцев. В on-prem VMS с мобильным приложением записи, аналитика и слой идентификации остаются на сервере в здании клиента — Android-приложение лишь окно к этому серверу. Облачная VMS размещает всё как SaaS в региональных облаках — Android-приложение становится окном в SaaS, а большая часть инженерной работы переезжает на бэкенд.

Облачная VMS меняет распределение нагрузки. Стоимость хранения становится операционными расходами. AI работает на облачных GPU, которые вы провижените. Идентификация и SSO живут в вашем облаке, а не в LDAP клиента. Онбординг клиента сокращается с дней до минут. Расследования между объектами наконец-то работают, потому что больше не приходится прыгать по VPN между площадками.

On-prem VMS меняет распределение рисков. Записи остаются на территории клиента — сильный аргумент для здравоохранения, оборонки и европейских покупателей. Расходы на трафик минимальны: видео не покидает здания. С суверенитетом данных всё просто. Расплата операционная: каждому клиенту нужен договор на обслуживание, а удалённая поддержка по VPN превращается в ежедневную рутину.

Если вы читаете этот гайд, вы, скорее всего, уже решили, что путь — облако. Хорошо. Следующие разделы — о том, как выбрать правильную архитектуру.

Три облачные архитектуры: чистое облако, гибрид с бриджем, облачное дополнение

Почти каждая облачная VMS на Android, которую мы оценивали, укладывается в один из трёх архитектурных паттернов. Выбирайте осознанно — переключение позже означает шесть месяцев на переделку.

Паттерн A — чистое облако. Камеры стримят напрямую в облако по RTSP-over-TLS или WebRTC. Android-приложение получает поток по WebRTC или LL-HLS из облачного SFU. Примеры: Verkada, Eagle Eye Networks, Rhombus, Avigilon Alta. Это работает, когда трафика хватает, у каждой камеры есть интернет и клиент готов к постоянному облачному аплинку. Лучше всего подходит для SMB и современного ритейла.

Паттерн B — гибридный бридж. На каждом объекте стоит небольшое Linux-устройство (или виртуальная машина), принимает локальные камеры, ведёт запись на месте для хранения и улик, а в облако выгружает только клипы по детектору движения, превью и аналитические события. Android-приложение получает live через бридж и облако, а архив подтягивает локально по запросу. Примеры: Genetec Stratocast, гибридный Rhombus, Network Optix Nx Cloud. Лучше всего для объектов с ограниченным аплинком, большими парками камер или строгими правилами хранения.

Паттерн C — облачное дополнение к on-prem VMS. Клиент сохраняет Milestone, Genetec или Bosch на своей территории. Вы добавляете тонкий облачный слой, который зеркалит метаданные, события тревог и короткие клипы, и Android-приложение, через которое операторы быстро разбираются с инцидентами из любого места. Лучше всего, когда клиент привязан к существующей on-prem VMS и ему нужен только мобильный и удалённый доступ без выкорчёвывания установленной системы.

Рынок облачных VMS в 2026 в цифрах

Если вы внутри компании защищаете идею такой разработки, макрокартина — в вашу пользу. Три цифры делают почти всю работу.

ПО растёт примерно в 2× быстрее оборудования. По обзору Memoori на 2025–2030, мировая выручка от оборудования видеомониторинга растёт с 2,5 трлн ₽ (2024) до 3,5 трлн ₽ (2030) при CAGR около 6%, а ПО для видеомониторинга, аналитика и storage-софт растут примерно по 12% в год. Регулярная выручка от SaaS вытесняет разовые продажи NVR.

Мобильная облачная VMS растёт ещё быстрее. По данным MarketsandMarkets, сегмент мобильных VMS вырастет с 208 млрд ₽ (2025) до 300 млрд ₽ (2030), а сегмент AI и edge-аналитики прибавляет 13,9% в год. На Северную Америку в 2024 пришлось 36% рынка мобильного видеонаблюдения, а АТР — самый быстрорастущий регион.

Консолидация идёт. Memoori насчитала 24 сделки M&A в сегменте VMS с сентября 2023 по август 2025 и около 285 млрд ₽ инвестиций в 38 сделках. Прямые инвестиции перекраивают рынок облачных VMS — партнёр по интеграции, которого вы выбрали сегодня, через год может оказаться у нового владельца. Проектируйте интеграционный слой так, чтобы его можно было заменить.

Облачный пайплайн приёма: от камеры до плитки на Android

Рабочий путь приёма потока в облачной VMS состоит из пяти этапов, и большинство проектов недооценивают второй и четвёртый. Завяжите каждый этап на конкретный сервис, чтобы развивать их независимо.

1. Аплинк камеры или бриджа. RTSP-over-TLS или RTSP-over-WebRTC от камеры до регионального ингест-эндпоинта. Бриджи (паттерн B) на этом этапе сжимают и предварительно фильтруют поток.

2. Медиашлюз. Терминирует RTSP, при необходимости транскодирует, перепубликует как WebRTC или LL-HLS для Android-клиента и сохраняет исходный сегмент в объектное хранилище. Мы используем MediaMTX, Janus и LiveKit в зависимости от масштаба; в крупных установках это, как правило, флот за автоскейлером.

3. Слой хранения. Горячий уровень для последних 24–72 часов (S3 Standard или эквивалент на SSD), тёплый уровень для 7–30 дней (S3 Infrequent Access, B2), холодный архив для всего, что старше 30 дней (Glacier, Archive Storage). Назначайте срок хранения по классам камер, а не по всему парку — не каждой камере нужны 90 дней в 4K.

4. AI и пайплайн событий. Инференс-сервисы (облачные GPU или специализированные инференс-эндпоинты) читают исходный поток, отправляют события в очередь (RabbitMQ, NATS, Kafka) и пишут результаты в поисковый индекс (OpenSearch). Android-клиент подписывается на интересные пользователю события через FCM или WebSocket. Здесь счёт может незаметно разрастись: один всегда включённый инференс YOLO на камеру при 30 fps — не бесплатное удовольствие.

5. Android-клиент и админская веб-панель. Android-приложение отвечает за живую сетку, воспроизведение, push и операторский рабочий процесс. Админка (отдельная) — за управление пользователями и ролями, регистрацию камер, политики хранения и биллинг. Один бэкенд, два клиента. Наш разбор архитектуры безопасной облачной VMS подробно раскрывает дизайн бэкенда.

Математика трафика и хранения: счёт, который никто не считает

Самый быстрый способ утопить проект облачной VMS на Android — недооценить трафик и стоимость хранения. Сделайте расчёт до планирования бюджета, а не после.

Из таблицы три вывода. H.265 при том же качестве вдвое сокращает счёт по сравнению с H.264 — если камера его поддерживает, делайте обязательным. Smart-record (запись по событиям) урезает хранение примерно на 90% против непрерывной; цена — невозможность задним числом посмотреть промежутки, когда ничего не происходило. Egress на мобильные клиенты — отдельный счёт. Каждый оператор, который час смотрит плитку 1080p, вытягивает около 1,8 GB. При 50 ежедневных операторах закладывайте сотни TB исходящего трафика в месяц.

Самые дешёвые счета за облачную VMS, которые мы аудировали, — это гибрид с бриджем, H.265, smart-record, под-поток по умолчанию для Android-сетки и агрессивные политики жизненного цикла (Standard 7 дней, IA 23 дня, Glacier для всего более старого). На таких настройках парк в 100 камер с хранением 30 дней обычно укладывается ниже 60 тыс. ₽ в месяц на всё про всё — на порядок дешевле непрерывного H.264 в чистом облаке.

Сравнительная таблица: 8 платформ облачных VMS

Если вы интегрируетесь с существующей облачной VMS, а не строите её с нуля, вот реалистичный шорт-лист на 2026. Сильные и слабые стороны — те, с которыми мы сталкиваемся в реальных интеграциях.

Если действуют ограничения по NDAA, шорт-лист камер остаётся прежним независимо от облачной платформы: Hanwha, Axis, Bosch, Pelco, Avigilon. Избегайте OEM-перемаркировок, в которых внутри SoC HiSilicon. Подробнее — в разделе про комплаенс.

Что Android-клиент обязан делать хорошо

Облачная VMS живёт или умирает на телефоне оператора. Шесть вещей должны работать, и в трёх из них спотыкается большинство приложений.

Шесть конкретных задач

1. Живое наблюдение с WAN-задержкой. WebRTC через публичный интернет, < 500 мс от стекла до стекла на p95. Сетка из нескольких плиток (4/9/16) с под-потоком по умолчанию. Детализация в полноэкранном режиме за счёт подгрузки основного потока.

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

3. Push-уведомления, которые переживают Android Doze. FCM с high-priority для настоящих тревог, normal-priority для всего остального. Слушайте onNewToken() и пересинхронизируйте с бэкендом. End-to-end задержка < 5 с на p95.

4. Идентификация с интеграцией в SSO клиента. OIDC к Okta, Entra, Google Workspace; MFA через TOTP или push. Матрица ролей по камерам — на сервере, а не на клиенте.

5. Гигиена foreground-сервисов на Android 14/15. Корректно объявляйте foregroundServiceType: mediaPlayback для прямого эфира, camera для записи, specialUse для мониторинга. Неверный тип в рантайме приведёт к ForegroundServiceTypeException.

6. Устойчивость к офлайн-режиму. Кэшируйте превью, последнее известное состояние камер и недавние события. Переподключайтесь с экспоненциальным бэкоффом. Сообщайте оператору, когда кадры устарели, — никогда не показывайте старое видео молча.

Где живёт AI в облачной VMS

В облачной VMS AI может работать в трёх местах. От выбора зависят и счёт за инфраструктуру, и история о приватности данных.

На камере (edge AI). Камеры Hanwha, Axis, Avigilon и Verkada запускают модели детекции объектов и поведения прямо в кремнии. Edge отправляет события — человек, машина, пересечение линии, задержка в зоне, — и в облако приходят метаданные, а не пиксели. Это самый быстрорастущий паттерн, потому что он режет облачный egress и даёт покупателю историю про приватность («видео остаётся на территории, пока не случилось что-то интересное»).

На облачной GPU. Тяжёлые модели — распознавание автомобильных номеров с региональными базами, индексация лиц, gait-аналитика, кросс-камерный трекинг — живут как автоскейлящиеся инференс-сервисы. Они читают тот же RTSP-поток, что видит Android-приложение, и пишут события в поисковый индекс. Цена считается за событие, а не за камеру, и это рычаг для апселла.

На устройстве Android. Только узкие сценарии: размытие посторонних с точки зрения приватности до показа клипа оператору, классификация скачанного клипа на лету, рабочие процессы охранника на планшете с офлайн-устойчивостью. TensorFlow Lite с делегатом NNAPI даёт 5–15 мс на инференс детекции объектов на свежем Snapdragon — нормально для одного-двух потоков, но не для сетки из 16 плиток. Наш гайд по моделям детекции аномалий подробнее раскрывает выбор модели.

Безопасность, идентификация и контроль доступа в облаке

Видео с камер — самые чувствительные данные клиента, а облачная VMS концентрирует их в одном месте сильнее любой on-prem системы. Относитесь к ним соответствующе с первого дня, а не после первого аудита.

Три слоя, которым нужно явное внимание

1. Транспорт. TLS 1.3 до каждого бэкенда. Certificate pinning на FCM, API-сервере и медиашлюзе. Конфиги pinning по сборочным вариантам — debug без pinning, чтобы инженеры могли работать с Charles, release с включённым pinning и CI, который роняет сборку, если pinning отключён.

2. Хранилище и tenancy. Ключи шифрования на каждого арендатора, защищённые KMS (AWS KMS, GCP KMS, Azure Key Vault). Политики бакетов, которые исключают кросс-арендаторные чтения даже при утечке ключей. Row-level security в SQL для БД с метаданными. Кэшированное видео и превью на Android-устройстве лежат в EncryptedFile; учётные данные — в Android Keystore.

3. Идентификация и авторизация. SSO через OIDC, если у клиента он есть; MFA обязателен для администраторских ролей. Матрица ролей по камерам обеспечивается в облачном бэкенде — Android-приложение это UI-слой, а не граница безопасности. Каждый запрос видео и каждая PTZ-команда авторизуется на сервере, даже если UI прячет кнопку.

Сквозное шифрование (end-to-end) — когда облако само не может расшифровать видео — редко встречается в коммерческих облачных VMS, потому что конфликтует с записью, поиском и AI на стороне облака. Если клиент его требует, планируйте его как архитектуру, а не как галочку. Реальное E2EE обычно означает: ключ оператора лежит в аппаратном модуле на территории клиента, Android-приложение получает ключ напрямую, а облако видит только шифротекст. Закладывайте на этот подпроект от четырёх до восьми недель.

Комплаенс: SOC 2, GDPR, HIPAA, BIPA, NDAA

Облачную VMS гоняют через комплаенс-проверки больше, чем любой on-prem продукт. Сделанная заранее работа окупается.

SOC 2 Type II — то, что реально спрашивает корпоративный закупщик. Планируйте окно наблюдения в 6–12 месяцев, отношения с аудитором и примерно 100–200 контролей в скоупе. Инструменты (Vanta, Drata, Secureframe) на порядок снижают расходы на документацию. Без SOC 2 продавать большинству корпоративных покупателей в США невозможно.

GDPR (ЕС/Великобритания) влияет на облачную архитектуру сильнее любого другого регулирования. Срок хранения видео — это data minimisation на юридическом языке: 30–90 дней типично, больший срок надо обосновывать. Субъекты данных могут запрашивать доступ (DSAR) и удаление. С первого дня делайте операторский UI для «экспортировать всё с человеком X» и «удалить всё с человеком X». Трансграничная передача требует Standard Contractual Clauses, если бэкенд за пределами ЕС.

HIPAA (здравоохранение США) вступает в силу, когда камеры наблюдают за пациентами, картами или зонами лечения. Готовьтесь подписывать Business Associate Agreements со всеми облачными и SaaS-вендорами в цепочке. Закладывайте по четыре недели аудита на каждый релиз.

BIPA (Иллинойс) и другие биометрические законы США регулируют распознавание лиц, отпечатков и gait-аналитику. Письменное согласие до сбора биометрии, запрет продажи или передачи биометрических идентификаторов, поток отказа и аппаратный kill-switch для функций по лицам на каждую камеру. Несколько штатов США скопировали шаблон BIPA — считайте это полом, а не потолком.

NDAA Section 889 запрещает федеральным агентствам, подрядчикам и получателям грантов в США использовать оборудование Hikvision, Dahua, Hytera, Huawei и ZTE, включая OEM-перемаркировки с их SoC. Если ваш клиент рядом с любым федеральным контрактом, вы не можете отгружать поддержку этих камер. Документируйте каждого вендора камер, каждый SoC и каждый облачный регион в комплаенс-матрице и подписывайте её у клиента.

Мини-кейс: запуск облачного видеонаблюдения для ритейла с мобильным доступом

Ситуация. Оператор охранных систем в ритейле, который только в 2025 году добавил больше 10 000 объектов, столкнулся с необходимостью мобильного доступа для управляющих магазинами и региональных руководителей по борьбе с потерями. Десктопный клиент работал, но менеджеры таскали отдельные устройства и планшетные приложения; мобильные дашборды на устаревшем стеке были слишком медленными для активных расследований. Целевой KPI — снижение shrink: платформе уже приписывали до 30% сокращения потерь в первом квартале в сетях национальных продуктовых ритейлеров.

Что мы запустили. Рабочий процесс облачной VMS поверх существующего видеопайплайна (FFmpeg, MediaMTX, MongoDB) с паттерном SIP/WebRTC-шлюза, который мы использовали в параллельном проекте облачного видеомониторинга. Мобильный опыт выводил AI-уведомления о движении в течение 30 секунд, сопоставлял POS-транзакции с видеоплитками и позволял менеджерам создавать клипы доказательной базы с верифицируемым хэшем. Мы переиспользовали мост SIP–WebRTC, который собирали для проекта IP-домофона, чтобы удержать задержку под контролем.

Результат. Клиенты из сегмента QSR (быстрого питания) отчитались о снижении инцидентов с уездом без оплаты на 40%. Региональная банковская ассоциация засчитала платформе остановку мошеннических попыток на сумму более 375 млн ₽. Среднее время установки нового объекта сократилось примерно на 60% по сравнению со старым стеком. Главная мобильная победа — менеджеры перестали эскалировать тикеты «не вижу камеру на телефоне»: уведомление и воспроизведение стали в одном тапе друг от друга, а не в трёх приложениях и одном VPN.

Модель бюджета: реалистичные цифры на 2026

Это консервативные диапазоны для senior-агентства в 2026 с использованием agent-assisted разработки. Они предполагают Kotlin/Compose на Android, автоскейлящийся облачный бэкенд и ONVIF+RTSP+WebRTC через медиашлюз. Добавьте примерно 20–30% на федеральные и NDAA-требования, мульти-региональное облако или жёсткие требования по доступности и локализации.

Бюджет редко уходит «на сетку камер». Он уходит на документы комплаенса, надёжность push, нагрузочные тесты приёма потоков, мульти-региональный failover и длинный хвост фрагментации Android-устройств. Закладывайте 25–35% бюджета на QA и пилотную эксплуатацию — это не разработка функций. Облачный opex (AWS/GCP/Azure) — отдельная строка, и расчёты по хранению из этого гайда — правильная стартовая точка.

Multi-tenant архитектура без кросс-арендаторных утечек

Если вы продаёте больше чем одному клиенту, multi-tenant неизбежен. Сделано хорошо — он незаметен. Сделано плохо — вы в одной ошибке от утечки видео одного клиента другому.

Сначала выберите модель арендаторов. Три варианта: общая схема с row-level security (дешевле всего, проще всего, сложнее всего изолировать), схема на арендатора (чистая зона поражения, больше миграций), БД на арендатора (лучшая изоляция, больше эксплуатации). Для большинства облачных VMS мы рекомендуем схему на арендатора для метаданных, единый S3-бакет со строгой изоляцией по префиксам IAM для видео, единый Redis с префиксами ключей по арендатору для горячего состояния.

Шифруйте по арендатору. Ключи данных на арендатора, защищённые KMS. Облако не может расшифровать видео одного клиента, обслуживая другого. Даже выгруженный S3-дамп бесполезен без доступа к ключу нужного арендатора.

Проверяйте на утечку. Регрессионный пакет, который создаёт двух арендаторов, пишет клип в арендатора A и убеждается, что арендатор B получает 403 на каждом API-эндпоинте — URL клипа, поисковый индекс, ленту тревог, экспорт улик. Гоняйте на каждом PR. Это самый высокоокупаемый тест для multi-tenant облачной VMS.

Фреймворк решения — выбираем путь за пять вопросов

Пять вопросов на одном листе — до любого архитектурного созвона.

Q1. Сколько камер на объект, объектов на арендатора, арендаторов? Ниже 30 камер на объект и один арендатор — чистое облако подходит. Выше 100 камер на объект или любой аплинк меньше 50 Mbps — нужен гибрид с бриджем.

Q2. Какой срок хранения? 7 дней против 30 против 90 против «вечно для улик». Срок хранения влияет на уровни хранилища и комплаенс сильнее любой другой переменной.

Q3. Какие режимы комплаенса? SOC 2, GDPR, HIPAA, BIPA, NDAA. Каждый добавляет недели. Недооценка этого — главная причина расползания скоупа в корпоративных проектах облачной VMS.

Q4. Где живёт AI? Edge, облачная GPU или устройство. Решайте по каждой возможности — одно глобальное «где» обычно неверно. От этого зависят и форма расходов, и история о приватности.

Q5. Кто будет это сопровождать следующие три года? Если «агентство, которое мы наймём», закладывайте 15–25% от стоимости разработки в год. Если «наша внутренняя команда», прописывайте в скоуп явную передачу знаний и этапы code review.

Подводные камни

Пять мест, где проекты облачной VMS регулярно жгут недели. Ни одно не экзотическое, и все легко выкинуть из SOW по невнимательности.

1. Писать всё непрерывно, решая про срок хранения потом. Классический убийца счёта в облачной VMS. По умолчанию — smart-record (по движению и событиям), а ценные камеры (кассы, двери) переводите в непрерывную запись отдельно. Правила жизненного цикла с первого дня: 7 дней горячее, 23 дня тёплое, остальное холодное.

2. Egress, про который забыли. Оператор, который час смотрит плитку 1080p, вытягивает 1,8 GB. Мульти-региональная репликация удваивает счёт за хранение. Кросс-региональные read-реплики БД тарифицируются по байту. Аудируйте облачный счёт еженедельно первые три месяца и проставляйте на каждую строку владельца фичи.

3. Пропустить ротацию токенов FCM. Приложения, в которых end-to-end не реализован onNewToken(), тихо перестают получать тревоги на 5–10% устройств в месяц. Пользователь не видит ничего плохого — пока аудит не покажет пропущенные тревоги движения на ключевых камерах.

4. Выключить certificate pinning в debug-сборках и забыть включить. Charles-прокси настраивают для QA, pinning отключают, чтобы прошли тесты, и флаг отключения переезжает в release-сборку. Пентестеры обожают такое. Решение: конфиги по сборочным вариантам и CI, который роняет release-сборку, если pinning выключен.

5. Дрейф парка камер по NDAA. Клиент добавляет OEM-камеру с SoC HiSilicon. Комплаенс ломается молча. Решение: опубликовать allow-list железа, отказываться добавлять камеры, не проходящие проверку SoC, и аудировать парк ежеквартально. Наш разбор ведущих вендоров видеонаблюдения отдельно отмечает, кто публикует свой статус по NDAA понятно.

KPI, которые важны: качество, бизнес, надёжность

Каждой облачной VMS на Android нужен дашборд KPI с первой недели пилота, а не после запуска. Три группы и пороговые значения, которые мы используем как минимум для запуска в прод.

KPI качества. Время до первого кадра < 2 с по WAN. Доля потерянных кадров < 3% при нормальной нагрузке, < 1% для тревог категории security. End-to-end задержка push < 5 с на p95. Холодный старт < 3 с. Мульти-региональный failover < 60 с.

Бизнес-KPI. DAU операторов, среднее число плиток в сессии, тревог, обработанных за смену, экспортов клипов улик в неделю, время до первого действия по тревоге высокой важности, ежемесячная регулярная выручка на камеру, gross margin на активную камеру. Облачная VMS живёт или умирает на юнит-экономике камеры.

KPI надёжности. Доля сессий без сбоев > 99,5% (Crashlytics). Уровень ложноположительных тревог движения < 10% (настраиваемый по камерам). Успешность доставки push > 98%. Успешное переподключение после смены сети > 99%. Аптайм облака > 99,9% на регион; целевой мульти-региональный — 99,95%.

Когда НЕ нужно делать кастомную облачную VMS на Android

Кастомная разработка облачной VMS — это дорого и для многих покупателей просто неверный ответ. Примерно одному из четырёх обращающихся мы говорим, что кастом не стоит этих денег, — и потом нас за это благодарят. Откажитесь, когда:

У вас меньше 200 камер и одна VMS. Verkada, Eagle Eye, Avigilon Alta или Rhombus дадут 95% пользы при 10% инженерных затрат. Ваша задача — интегрироваться, а не строить.

Единственное отличие — брендинг. White-label дешевле кастомного кода. Большинство корпоративных вендоров облачной VMS его предлагают. Если единственная причина — «наш логотип на экране входа», заплатите за white-label.

Вы не сможете финансировать поддержку и SOC 2. Облачная VMS — это постоянные вложения. Планируйте 2,2–6 млн ₽ в год на поддержку плюс бюджет SOC 2. Если на это денег нет, не начинайте.

Срок меньше восьми недель. MVP в восемь недель реален для Android-клиента поверх существующего бэкенда. Полноценная облачная VMS за восемь недель — это перебрендинг чужого приложения, а не настоящий продукт.

FAQ

Сколько времени нужно на разработку кастомной облачной VMS на Android?

Android-клиент поверх существующего облачного бэкенда — 8–12 недель. Облачное дополнение, зеркалирующее метаданные с on-prem VMS, — 14–18 недель. Гибридная облачная VMS с бриджем, multi-tenant и AI-событиями — 20–26 недель. Чистое облако, multi-tenant, white-label SaaS — 26–36 недель. Аудиты по комплаенсу добавляют по четыре недели на каждый режим в скоупе.

Сколько на самом деле стоит облачное хранение для парка в 100 камер?

Непрерывное 1080p H.264 за 30 дней — около 130 TB. На AWS S3 Standard это примерно 225 тыс. ₽ в месяц без учёта egress. Переход на H.265 плюс smart-record плюс многоуровневый lifecycle (Standard 7 дней, IA 23 дня) — и тот же парк падает до 13–20 TB и примерно 37–60 тыс. ₽ в месяц на всё про всё. Egress на мобильные клиенты — отдельная строка.

Чистое облако, гибрид с бриджем или облачное дополнение — как выбрать?

Чистое облако — для SMB, современного ритейла и любого развёртывания, где у каждой камеры стабильный интернет и постоянный облачный аплинк в порядке. Гибрид с бриджем — для корпоративных мультиобъектных сетей с > 50 камер на объект, сроком хранения > 30 дней или любым аплинком меньше 50 Mbps. Облачное дополнение — когда существующая on-prem VMS (Milestone, Genetec, Bosch) уже стоит и клиенту нужен только мобильный и удалённый доступ сверху.

Нужен ли SOC 2 с первого дня?

Если продаёте корпоративным клиентам в США — да. SOC 2 Type II — самый часто запрашиваемый комплаенс-сертификат в закупках security-софта. Планируйте окно наблюдения 6–12 месяцев. Используйте Vanta, Drata или Secureframe, чтобы на порядок сократить расходы на документацию. Пока его нет, ждите, что 30–50% корпоративных сделок будут зависать.

Будет ли Android-приложение работать с существующими бэкендами Milestone, Genetec или Avigilon?

Да, как облачное дополнение (паттерн C). Milestone предоставляет XProtect Mobile SDK и облачный вариант Kite; Genetec — Stratocast и мобильные компоненты Security Center; Avigilon Alta — закрытое облако, интегрируется по документированному REST. Закладывайте две-три недели на каждую VMS для сертификации и полевого тестирования.

Где запускать AI — на камере, в облаке или на телефоне?

Edge AI на камере — для всегда включённых детекторов (человек, машина, пересечение линии, задержка в зоне). Облачная GPU — для тяжёлых моделей (распознавание номеров, индексация лиц, кросс-камерный трекинг, цепочки поведения). На устройстве — только для узких сценариев: размытие посторонних, классификация скачанного клипа на лету, офлайн-рабочие процессы на планшете охранника. Одно глобальное «где» редко правильное; выбирайте по каждой возможности.

Сколько камер одновременно тянет один Android-планшет?

Четыре-девять живых потоков 720p/30fps — комфортно на современном планшете. Шестнадцать плиток — нужно адаптивное разрешение, каждая плитка 480p или ниже. Воспроизведение записей куда легче: тот же планшет нормально листает архивы 100+ камер. Реальный потолок — тепловой троттлинг, а не сеть.

Можно ли развернуть Android-приложение на охранных планшетах в режиме киоска?

Да. Используйте Android Enterprise с управляемым Google Play, плюс DevicePolicyManager для kiosk и lock-task. Отключите home и recents, управляйте app pinning, задайте таймаут экрана и заложите удалённый kill-switch для потерянных или украденных устройств. Добавьте две-три недели на MDM-усиление и пилот.

Что почитать дальше

Готовы планировать кастомную облачную VMS на Android?

Кастомная облачная VMS на Android оправдывает себя, когда вы обслуживаете больше одного клиента или когда AI, multi-tenancy или комплаенс заставляют вас контролировать путь данных. Ниже этой планки готовая облачная VMS — более разумный выбор. В любом случае путь внутри одинаков: выбрать архитектуру (чистое облако, гибрид с бриджем или облачное дополнение) до любых функций, разложить хранение по уровням, следить за трафиком и инструментировать KPI с первой недели.

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