Спортзал: турникет, абонементы и 900 членов — своя система вместо облачной по картам

MAATRIX

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

Как облачная модель «по картам» работает изнутри

Логика поставщика простая и по-своему честная с его стороны: раз система обслуживает больше активных пользователей, значит она нагружает больше вычислительных ресурсов на его стороне, значит и платить должны больше. На практике это чаще выглядит как тариф с несколькими порогами — условно «до 300 активных карт», «до 700», «до 1500» — и при пересечении границы клуб автоматически переезжает на следующий уровень тарифа. Или как плата за каждый активный абонемент сверх базового пакета, начисляемая помесячно независимо от того, ходит ли этот человек в зал каждый день или заморозил абонемент на два месяца.

Проблема в том, что реальная нагрузка на систему допуска почти не зависит от числа карт в базе. Открыть турникет — это проверить один номер карты по таблице из нескольких тысяч записей, операция, которая занимает миллисекунды даже на скромном железе. База клуба с 900 членами и база клуба с 90 членами создают практически одинаковую нагрузку на сервер в моменте прохода через турникет — разница на уровне объёма хранимых данных, а не вычислений. То есть клуб платит не за реальный расход ресурсов, а за факт своего роста как бизнеса. Число «900 членов» здесь стоит воспринимать именно как иллюстрацию масштаба, при котором разница между двумя моделями становится ощутимой в деньгах, а не как точный порог, после которого что-то ломается.

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

Что должна делать система: турникет, абонементы, учёт членов

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

• Идентификация на турникете. Карта, брелок или QR-код на входе — контроллер турникета должен за доли секунды понять, пускать человека или нет.
• Проверка статуса абонемента. Не истёк ли срок, не заморожен ли, оплачен ли текущий период, не превышено ли ограничение по посещениям, если такое есть в тарифе клуба.
• Учёт посещений. Фиксация времени прохода — нужна и для статистики загрузки зала по часам, и как факт на случай спорных ситуаций с клиентом.
• Управление абонементами. Продление, заморозка, перенос, привязка к тарифу, история платежей клиента.
• Отчётность для персонала. Сколько человек в зале сейчас, кто просрочил оплату, у кого истекает абонемент на этой неделе — это то, что нужно администратору на ресепшене каждый день.

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

Архитектура своей системы: сервер, контроллер и база абонементов

Собственная система строится из трёх слоёв, и важно не путать их друг с другом, потому что от этого зависит, что именно вы арендуете и настраиваете.

Контроллер турникета — физическое устройство у двери, которое непосредственно управляет механикой прохода. Оно есть независимо от того, какую систему учёта вы выберете, и в большинстве случаев умеет работать по стандартному протоколу связи с внешней системой (чаще всего это Wiegand-совместимый интерфейс или связь по сети через простой API), а не требует конкретного облачного сервиса конкретного производителя. При выборе оборудования стоит уточнять у поставщика турникета именно это — открытый протокол интеграции, а не привязку к его собственному облаку. Это единственный пункт, где вам нужно будет свериться с документацией конкретной модели, потому что варианты интеграции у разных производителей отличаются.

Сервер с базой данных и логикой допуска — это то, что вы переносите со стороннего облака на свой VPS или выделенный сервер. Он хранит список активных карт, статусы абонементов, историю посещений и отвечает на запрос «пускать или нет» за то время, за которое человек успевает поднести карту к считывателю.

Панель администратора — веб-интерфейс для ресепшена и менеджеров: продление абонементов, поиск клиента, отчёты. Это обычное веб-приложение, которое работает на том же сервере.

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

Турникет (контроллер СКУД)
        │  Wiegand / сетевой запрос
        ▼
Локальный шлюз доступа (на площадке клуба)
        │  HTTPS-запрос к API
        ▼
Сервер (VPS/выделенный) — API + PostgreSQL
        │
        ├── таблица card_holders (владельцы карт)
        ├── таблица memberships (абонементы)
        ├── таблица access_log (журнал проходов)
        └── веб-панель администратора

Обратите внимание на локальный шлюз доступа на площадке клуба — это не облачный, а локальный компонент (простой мини-компьютер или тот же контроллер турникета с логикой кеширования), который умеет какое-то время работать автономно, если связь с сервером на секунды пропадёт, и синхронизируется, когда соединение восстановится. Это стандартная практика в СКУД-системах любого масштаба, и она снимает главный страх клиентов, переходящих с облака: «а что если интернет ляжет прямо во время прихода клиентов».

Пример структуры базы данных и логики допуска

Чтобы не оставаться на уровне общих слов, вот упрощённая, но рабочая схема таблиц на PostgreSQL, из которой можно расти:

CREATE TABLE members (
    id SERIAL PRIMARY KEY,
    full_name TEXT NOT NULL,
    phone TEXT,
    card_uid TEXT UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT now()
);

CREATE TABLE memberships (
    id SERIAL PRIMARY KEY,
    member_id INTEGER REFERENCES members(id),
    plan TEXT NOT NULL,             -- тип абонемента
    valid_from DATE NOT NULL,
    valid_to DATE NOT NULL,
    frozen_until DATE,              -- заморозка, если есть
    visits_left INTEGER,            -- лимит посещений, если тариф с ограничением
    status TEXT DEFAULT 'active'    -- active / expired / frozen / blocked
);

CREATE TABLE access_log (
    id SERIAL PRIMARY KEY,
    member_id INTEGER REFERENCES members(id),
    checkpoint TEXT NOT NULL,       -- какой турникет/вход
    granted BOOLEAN NOT NULL,
    reason TEXT,                    -- причина отказа, если granted = false
    ts TIMESTAMP DEFAULT now()
);

Логика проверки на проходе — это, по сути, один запрос:

SELECT m.status, m.valid_to, m.frozen_until, m.visits_left
FROM memberships m
JOIN members mb ON mb.id = m.member_id
WHERE mb.card_uid = $1
  AND m.status = 'active'
  AND m.valid_to >= CURRENT_DATE
ORDER BY m.valid_to DESC
LIMIT 1;

Дальше приложение на сервере интерпретирует результат: пусто или просрочено — отказ с причиной, есть активная запись — команда на открытие турникета плюс запись в access_log. При базе в несколько тысяч карт (что покрывает клуб и с 900, и с 9000 членов) такой запрос с индексом по card_uid выполняется практически мгновенно на любом современном VPS — здесь действительно нет технической причины, по которой рост числа карт должен требовать более дорогого тарифа у облачного поставщика.

Экономика: фиксированная цена сервера против растущей платы за карты

Смысл переноса не в том, что облачные СКУД — это плохо спроектированные системы, а в том, что их модель ценообразования привязана к числу абонементов, а не к реальной нагрузке. Собственный сервер устроен иначе: вы платите фиксированную цену за вычислительную мощность и объём хранилища, и эта цена не меняется от того, сколько карт лежит в базе — 300 их или 3000.

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

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

Что учесть при переходе: офлайн-режим, бэкапы и персональные данные

Собственная система снимает одну зависимость, но добавляет ответственность, которую раньше нёс поставщик, и её стоит продумать заранее, а не по факту первого сбоя.

Работа при потере связи. Локальный шлюз на площадке должен кешировать список активных карт и уметь принимать решение о допуске автономно хотя бы на несколько часов, синхронизируя журнал проходов, когда связь с сервером восстановится. Это стандартный принцип для СКУД любого происхождения, не специфика самостоятельного решения — но при своей системе за него отвечаете вы, а не служба поддержки поставщика.

Резервное копирование. База абонементов и журнал посещений — это данные, потеря которых означает, что клуб не сможет доказать, кто оплатил, а кто нет. Регулярный бэкап базы данных на отдельное хранилище — не опция, а обязательная часть эксплуатации с первого дня, а не пункт «сделаем потом».

Персональные данные членов клуба. ФИО, телефон, иногда данные карты оплаты — это персональные данные, и при переносе с облачного поставщика на свой сервер ответственность за их защиту переходит к владельцу клуба напрямую. Разумный минимум — шифрование соединения между шлюзом на площадке и сервером (обычное HTTPS/TLS), ограничение доступа к серверу по SSH-ключам, отдельная учётная запись для панели администратора с паролем, который не хранится в общем чате персонала.

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

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

Частые вопросы