Ночной клуб хотел знать, сколько людей реально проходит за смену

Задача и рамки

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

• Камеры не трогать. Две точки: входная группа и барная зона. Обзор сверху под углом: лица видно плохо, затылки отлично.
• Запись идёт на компьютер с Windows 7, он стоит в кабинете и ночью пишет обе камеры. Ничего тяжёлого на нём запускать нельзя.
• Видеокарта только дома, RTX 2060 в личном ПК. Клуб и дом связывают интернет и арендованный сервер.
• Бюджет на железо ноль. Всё собрано на том, что уже работает.
• Записи хранятся сутки. Так требует клуб: ничего старше 24 часов ни на одной из трёх машин.

Как устроен конвейер

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

Что делает движок с кадром

• Детекция людей на YOLOv8. Разрешение подбирал по замерам скорости и полноты на реальных ночах.
• Трекинг через ByteTrack: человек получает номер и ходит под ним, пока его видно.
• Счёт проходов по зонам. Линию на пороге я не ставил, зон две: «улица» и «зал». Проход засчитывается, только когда трек побывал в обеих. Так те, кто курит и топчется у двери, не накручивают счётчик.
• Лица через insightface: на каждом третьем кадре трека ищем лицо и сравниваем с базой персон и с эталонами сотрудников. Иначе охрана и бармены считались бы гостями.
• База персон в SQLite: персона, её снимки лица, визиты, роль. Отсюда и берутся «новые» и «постоянные» гости.

Панель

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

Ночь как график

Сколько людей в зале, считаю нарастающим итогом входов и выходов с шагом пять минут. По кривой видно, как зал наполняется и когда начинает пустеть. На графике пятница 19 сентября 2026 года, пик 296 человек около трёх ночи.

человек в зале, шаг 5 минут источник: журнал событий движка за ночь 19.09.2026

Что ломалось после запуска

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

Как выглядит сторож тишины

# процесс живой, пока пишет в лог; замолчал надолго — значит завис
$beat = [hashtable]::Synchronized(@{ last = Get-Date })
$onData = {
  if ($null -ne $EventArgs.Data) {
    [Console]::Out.WriteLine($EventArgs.Data)
    $Event.MessageData.last = Get-Date
  }
}
Register-ObjectEvent -InputObject $p -EventName OutputDataReceived -Action $onData -MessageData $beat

while (-not $p.HasExited) {
  $now    = Get-Date
  $silent = ($now - $beat.last).TotalMinutes
  if ($silent -gt $STALL_MIN) { $p.Kill(); $rc = 125; break }   # завис
  if ($now -gt $deadline)     { $p.Kill(); $rc = 124; break }   # не уложился
  Start-Sleep -Seconds 10
}

Два кода возврата я развёл нарочно: 125 значит «молчит», 124 значит «не уложился в лимит». Первый перезапускается сам, второй разбираю руками.

Журнал докачки

# каждый доехавший кусок — строка в журнале; размер файла ничего не доказывает
with open(out, "r+b") as f:
    f.seek(offset)
    f.write(chunk)
    f.flush(); os.fsync(f.fileno())
with open(out + ".parts", "a") as j:
    j.write("%d %d\n" % (offset, len(chunk)))

# файл готов, только если сошлись все куски
if missing:
    sys.exit(2)
os.remove(out + ".parts")

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

Что сошлось и что врёт

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

Расхождение здесь показывает, насколько «в зале» уходило в минус за ночь. Ноль значит, что кривая ни разу не провалилась ниже пустого зала и входы с выходами сошлись. На 13 ночах из 14 провал не больше шести человек.

А пересчёт проходов в людей врёт

Проход и человек не одно и то же. Один гость за ночь выходит покурить четыре раза, охранник мотается туда-сюда всю смену. Сырые 1062 прохода в субботу вовсе не значат 1062 гостя. Пересчёт я сделал через повторность: сколько проходов в среднем приходится на одного опознанного человека. И он, по-честному, не работает:

• Будни завышены. В понедельник система насчитала 126 «гостей» при пике 17 человек в зале. Так не бывает: в тихую ночь персонал ходит столько же, что и в людную, а гостей мало, вот доля мусора и растёт.
• Выходные занижены. Владелец, который видит зал своими глазами, говорит: в субботу людей заметно больше, чем показывает отчёт.
• Причина нашлась в опознании. Сравнение лица с базой брало лучшее совпадение по одному снимку из восемнадцати. Хватает одного случайного попадания, и человек «приклеивается» к чужой карточке, а карточка растёт как снежный ком. Замерил по базе: внутри одной «персоны» схожесть снимков падает до нуля при пороге 0,45. Значит, в одной карточке сидят разные люди.

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

Что случилось в субботу 20 сентября

Это единственная ночь, где счётчик сорвало. С 22:00 до 22:11 система показала до 59 выходов в минуту и увела зал в минус 245 человек, а дальше вся ночь считалась нормально. Модель тут ни при чём. Запись начинается в 22:00, счётчик присутствия стартует с нуля и не знает, что в зале уже есть люди. Все, кто вошёл до начала записи, выходят «в минус», и пик ночи считается от съехавшего нуля. Лечится калибровкой старта по минимуму кривой. На остальных тринадцати ночах минимум и так нулевой, поэтому всплыло это только раз.

Чему этот проект меня научил

• Считать надо то, что можно проверить. Баланс входов и выходов бесплатно показывает, не врёт ли счётчик, и ловит ошибку раньше, чем её заметит заказчик.
• Молчаливые поломки дороже громких. Упавший скрипт видно сразу. А скрипт, который два часа греет видеокарту вхолостую, можно не замечать неделю.
• Непроверенную красивую цифру заказчику не пишу. Проще всего было написать «точность 95%». Я сел с посекундными раскадровками и пересчитал вход руками: по проходам расхождение 10–15%, по людям гораздо хуже. Так и записал в документации проекта.
• То, что код заработал, ещё не значит, что всё готово. Автоматизацию можно считать сделанной, когда система неделю живёт без тебя. По дороге к этому вылезло ещё шесть неочевидных багов.