Компьютеры -> Видео -> Камера недоступна: диагностика видеонаблюдения

Камера недоступна: диагностика видеонаблюдения

Понедельник, 8:20. Склад на окраине города, сорок две камеры, регистратор пишет двадцать девять. Остальные тринадцать — серые прямоугольники в клиенте. Охранник говорит «вчера всё работало», начальник склада говорит «мне нужно до обеда», а ты сидишь перед монитором и понимаешь, что сейчас придётся объяснять людям разницу между «камера сломалась» и «сеть легла». И то, и другое выглядит для них одинаково.

Хорошая новость: в девяти случаях из десяти эту разницу можно установить минут за пятнадцать, не выезжая на объект, и без мистики. Плохая — придётся перестать смотреть в клиент видеонаблюдения и начать смотреть в сеть.

Видеонаблюдение давно перестало быть «слаботочкой»

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

Сейчас всё иначе. IP-камера — это полноценный сетевой узел. У неё есть MAC-адрес, IP, веб-интерфейс, прошивка с известными CVE, DHCP или статика, PoE-питание, RTSP-поток и, если совсем не повезло, вендорское облако с подпиской. Она потребляет трафик, греется, пишет логи и иногда перезагружается сама по себе. То есть ведёт себя ровно как любой другой сетевой прибор — и ломается по тем же законам.

Отсюда первое правило, которое я советую выучить всем, кто унаследовал объект с камерами: симптом «нет картинки» не говорит ни о чём. Он одинаково описывает сгоревший PoE-порт, отвалившийся патч-корд, конфликт IP-адресов, переполненный накопитель, грозовой разряд, запотевший объектив и банально отключённую в веб-интерфейсе камеру. Задача не в том, чтобы угадать, а в том, чтобы разделить пространство поиска на слои и отбрасывать их по одному.

Слой первый: сеть и питание

Начинать всегда стоит с электричества и линка, потому что это быстро и дёшево.

Первое — PoE-бюджет. Почти каждый раз, когда мне говорят «половина камер на одном коммутаторе пропала», виноват не коммутатор, а его бюджет мощности. На корпусе написано «48 портов PoE, 370 Вт», а камер на нём висит 40 штук по 8–12 Вт в ИК-режиме. Днём всё хорошо, ночью включается подсветка, потребление подскакивает, и часть портов уходит в защиту. Утром камеры возвращаются, днём снова работают — и так по кругу, пока кто-нибудь не догадается посмотреть график потребления. Лечится либо сменой коммутатора, либо переносом части камер на отдельный PoE-инжектор.

Второе — кабель. Наружная трасса, солнце, мороз, мыши, влага в коннекторе, «временная» скрутка, сделанная монтажниками три года назад. RJ-45, залитый силиконом на морозе, трескается, внутрь попадает конденсат, контакты окисляются. Камера при этом может даже отдавать линк, но 100 Мбит превращаются в 10 Мбит с чудовищным количеством ошибок — и поток просто рассыпается. Смотрим ethtool -S на порту коммутатора, ищем CRC-ошибки и дропы. Если счётчики растут на глазах — вопрос не к камере, а к кабелю.

Третье, о чём забывают чаще всего, — конфликт адресов. Кто-то воткнул в сеть новый прибор с заводским 192.168.1.64, и он честно перехватывает ARP-запросы. Диагностируется arp -a с двух разных машин плюс сверка с таблицей MAC. Заодно неплохо проверить, что DHCP-сервер не выдал адрес камеры принтеру.

И четвёртое — MTU и VLAN. Если камеры живут в отдельном сегменте, а смотреть их хотят из офиса через туннель, то «камера недоступна» может означать «пакеты не влезают». ping -f -l 1472 и последовательное уменьшение размера — грубый, но быстрый тест.

Слой второй: сеть поверх сети

Камера пингуется, веб-интерфейс открывается, а в регистратор поток не идёт. Здесь начинается прикладной уровень, и он почти всегда про совместимость.

Стандартный сценарий: объект расширили, купили камеры другого вендора, добавили их по ONVIF, и через неделю половина отвалилась. Причина обычно в профиле ONVIF, который регистратор не понимает: камера отдаёт H.265, регистратор ждёт H.264, транскодировать не умеет — вот и тишина. Или в аутентификации: после смены пароля на камере регистратор продолжает стучаться со старым и получает 401, а в логе пишет просто «ошибка потока».

Проверять это надо не в клиенте, а руками. RTSP-поток открывается в VLC, ONVIF-устройства ищутся через ONVIF Device Manager, порты 554, 80, 8000, 37777 проверяются nmap. Если поток в VLC идёт, а в регистраторе нет — проблема в интеграции, и вендорские форумы тут полезнее любых гаданий. Если не идёт нигде — возвращаемся на слой выше, к сети и питанию.

Отдельная песня — прошивки. У камер есть привычка обновляться «сами» через вендорское облако, и примерно раз в год очередное обновление ломает что-нибудь важное: то ONVIF отключится по умолчанию, то пароль потребует усложнения, то сменится формат потока. Поэтому на объектах, где я отвечаю за сеть, автобновление на камерах выключено, а версии прошивок зафиксированы в документации. Скучно? Да. Но куда скучнее объяснять заказчику, почему архив за прошлую неделю не читается.

Слой третий: запись и хранение

Бывает, что камеры работают прекрасно, а «пропадает картинка» — это не камеры вовсе, а запись.

Классика: HDD в регистраторе сыпется по секторам. Он ещё крутится, регистратор его видит, но запись уходит в дыры, а старые фрагменты архива не отдаются. SMART покажет Reallocated_Sector_Ct и Current_Pending_Sector — если они не нулевые, диск надо менять, а не «чистить архив». Диски для видеонаблюдения (WD Purple, Seagate SkyHawk и аналоги) стоят дороже обычных не из вредности: у них другая прошивка под постоянную запись. Ставить в регистратор самый дешёвый десктопный диск — верный способ вернуться на объект через полгода.

Второе — арифметика. Восемь камер по 4 Мбит/с круглосуточно — это около 1,4 ТБ в сутки, то есть 10 ТБ на неделю. Если в регистраторе стоит 4 ТБ и «настроено на месяц», он будет затирать архив каждые три дня, и никакие настройки тут не помогут. Пересчитывать нужно по реальному битрейту из потока, а не по надписи на коробке.

Третье — переполнение буфера событий и журналов. Мелочь, но на дешёвых регистраторах журнал забивается и устройство начинает подтормаживать в интерфейсе, что легко принять за проблемы с сетью.

Слой четвёртый: оптика, корпус, улица

А теперь та часть, где заканчивается администрирование и начинается физика. И где, честно говоря, сетевику делать уже нечего — тут нужен специалист по видеокамерам, потому что дальше идут разборка корпуса, юстировка оптики и замена компонентов на плате.

Признаки, что пора звать человека с паяльной станцией и стендом, довольно характерные. Картинка есть, но мутная и «в молоке» — почти всегда конденсат внутри кожуха или помутневший от ультрафиолета пластик. Ночью изображение белое или, наоборот, полностью чёрное, днём нормальное — выгорели или отклеились ИК-светодиоды, либо сработала механическая шторка ICR. Появились вертикальные полосы, «снег», пропала цветность — деградировала матрица или шлейф. Камера греется так, что рука не терпит — высохла термопаста, а это прямой путь к отвалу процессора. Из корпуса слышен писк — дохнет импульсный преобразователь.

Отдельно стоят грозовые повреждения. Один разряд рядом с мачтой — и в камере выгорает PoE-модуль, причём внешне она выглядит целой и даже иногда отвечает по сети, просто не выдаёт изображение. Такие случаи не лечатся перезагрузкой и не лечатся заменой патч-корда.

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

Слой пятый: люди и документация

Самый недооценённый слой. Половина инцидентов, которые я разбирал, заканчивалась фразой «а кто это менял?».

Нет схемы адресации — ищешь камеру наугад. Нет учётных записей — сбрасываешь устройство кнопкой и теряешь настройки. Нет пароля от регистратора — а он, как назло, нужен для восстановления архива по запросу службы безопасности. Нет подписанного акта приёмки — и непонятно, кто виноват в том, что камера на воротах смотрит в забор.

Поэтому минимальный комплект документации по видеонаблюдению, который стоит завести на любом объекте: таблица IP и MAC, схема PoE-портов с потреблением, список моделей и версий прошивок, отдельный сейф для паролей, регламент хранения архива с указанием глубины и объёма. Полдня работы, которые окупятся на первом же ночном звонке.

Короткий чек-лист на выезд

Если свести всё к последовательности, получается примерно так.

Пингуется ли адрес камеры из той же подсети. Есть ли линк на порту, горят ли индикаторы, растут ли ошибки. Сколько реально ватт выдаёт PoE и не упирается ли он в бюджет. Открывается ли RTSP в плеере. Совпадают ли кодек, профиль и пароль между камерой и регистратором. Есть ли место на дисках и что говорит SMART. И только после этого — лезть на стремянку смотреть объектив и корпус.

Такая последовательность экономит не только время, но и нервы. Потому что когда ты приходишь к руководителю и говоришь не «камера сломалась», а «на девятом порту растут CRC-ошибки, кабель в лотке перетёрт, нужен монтажник», разговор сразу идёт в другом тоне.

Что в итоге

IP-видеонаблюдение — это обычная ИТ-инфраструктура, просто с объективом на конце. У неё есть сеть, питание, прошивки, накопители и физический износ, и каждый из этих слоёв ломается по своим, вполне предсказуемым правилам. Администратору не нужно уметь паять матрицы — ему нужно уметь быстро отделять «ещё не сеть» от «уже не сеть», а железо отдавать тем, кто занимается железом профессионально.

И главное: заведите себе привычку записывать, что именно вы проверили. Через полгода, когда та же камера снова отвалится, эти три строчки в тикете сэкономят вам час жизни.

Опубликовано: 02.11.2026г.