Хостел: шахматка мест, замки и гостевой Wi-Fi — что реально влезает на один сервер

MAATRIX

Открываете хостел на 30-40 коек и быстро понимаете: нужна шахматка мест, чтобы видеть, кто где и до какого числа, нужны электронные замки на входных дверях и шкафчиках, чтобы не менять личинки после каждого потерянного ключа, и нужен гостевой Wi-Fi, потому что без него бронирований будет вдвое меньше. Три задачи — и очень легко решить каждую отдельным облачным сервисом с отдельной подпиской, отдельным логином и отдельным счётом в конце месяца. На деле все три системы по нагрузке настолько скромные, что спокойно живут на одном недорогом сервере — если разложить их аккуратно, а не валить в одну кучу без разбора.

Три задачи — три подрядчика и три счёта в конце месяца

Так обычно и получается на старте. Шахматку берут в облачном PMS для хостелов и мини-отелей — тариф часто привязан к числу активных коек или номеров, и с ростом хостела он растёт вместе с бизнесом. Замки заказывают у поставщика оборудования, и вместе с самими замками продают доступ к его облачному приложению — обычно тоже помесячно, иногда с привязкой к числу дверей. Гостевой Wi-Fi поднимают через готовый хот-спот-сервис или встроенный портал у провайдера интернета, который тоже берёт деньги за авторизацию гостей и статистику подключений.

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

Сколько на самом деле весят эти три системы

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

• Шахматка мест — это, по сути, календарная сетка с формами бронирования и панелью администратора. Одновременно с ней работают 1-3 человека персонала плюс редкие обращения с виджета бронирования на сайте. База данных — это записи о гостях, датах, ценах и статусах уборки, для хостела на 30-60 коек за год это тысячи, не миллионы строк. Пиковая нагрузка — заезд/выезд утром и вечером, и даже тогда это веб-запросы, а не что-то ресурсоёмкое.
• Замки — событийная система: открытие двери происходит редко относительно времени работы сервера, и каждое событие — это короткое сообщение «замок такой-то открыт кодом таким-то в такое-то время». Хаб или шлюз замков почти всё время простаивает, ожидая события.
• Гостевой Wi-Fi — здесь важно разделить два разных потока. Сама авторизация гостя (форма портала, проверка номера комнаты или кода) — это лёгкие короткие запросы, десятки в день. А вот трафик, который гость потом гоняет — видео, соцсети, звонки — идёт через роутер напрямую в интернет и вообще не касается вашего сервера с приложениями. Сервер не «раздаёт интернет», он только решает, кого пускать в сеть.

Если сравнивать по нагрузке с типичными задачами, под которые люди обычно берут отдельный VPS — небольшой интернет-магазин, чат-бот с активной аудиторией, панель мониторинга — все три системы хостела вместе едва ли сравняются с одной такой задачей средней руки. Проблема никогда не в производительности, а в том, чтобы аккуратно развести сервисы, сети и данные так, чтобы они не мешали друг другу и не открывали один другому лишний доступ.

Общая архитектура: как разложить всё, не свалив в кучу

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

/opt/hostel/
├── docker-compose.yml
├── pms/              # шахматка мест, своя БД
├── locks/            # zigbee2mqtt + брокер MQTT для замков
├── wifi-portal/       # captive-портал и учёт сессий
└── proxy/             # reverse-proxy + TLS

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

services:
  proxy:
    image: caddy:2
    ports: ["80:80", "443:443"]
    volumes: ["./proxy/Caddyfile:/etc/caddy/Caddyfile", "caddy_data:/data"]
    restart: unless-stopped

  pms:
    build: ./pms
    environment: ["DATABASE_URL=postgres://pms:pms@pms-db:5432/pms"]
    mem_limit: 512m
    cpus: 0.5
    restart: unless-stopped

  pms-db:
    image: postgres:16
    volumes: ["pms_data:/var/lib/postgresql/data"]
    mem_limit: 256m
    restart: unless-stopped

  mqtt:
    image: eclipse-mosquitto:2
    volumes: ["./locks/mosquitto.conf:/mosquitto/config/mosquitto.conf"]
    mem_limit: 128m
    restart: unless-stopped

  wifi-portal:
    build: ./wifi-portal
    mem_limit: 256m
    restart: unless-stopped

volumes:
  caddy_data:
  pms_data:

Ключевые моменты: у каждого сервиса своя база или своё хранилище, никто не лезет в чужие таблицы напрямую; у каждого — лимит по памяти и CPU через mem_limit/cpus, чтобы аномалия в одном контейнере (например, зависший запрос к БД шахматки) не забрала всю память сервера и не уронила замки или Wi-Fi; reverse-proxy на входе разводит поддомены (pms., wifi. и так далее) и держит TLS-сертификаты в одном месте.

Отдельно — про сеть. Гостевой Wi-Fi физически должен идти на роутере или управляемом коммутаторе в отдельный VLAN, изолированный от сети, где висит сам сервер и панель управления шахматкой. Гость, подключившийся к Wi-Fi, не должен даже теоретически «увидеть» административный интерфейс замков или базу бронирований — только портал авторизации и выход в интернет. Спутать эти сети на старте — обычная и недешёвая ошибка: без проверенной разводки VLAN гостевое устройство иногда оказывается в той же сети, что и сервер с шахматкой.

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

Шахматка мест: календарная сетка занятости

Суть шахматки простая — таблица «место × дата» с цветовой раскраской: свободно, забронировано, заселено, требует уборки, заблокировано на ремонт. Для хостела важно, чтобы эта сетка показывала не номера, а именно койко-места внутри комнат — то есть уровень детализации мельче, чем у обычной гостиничной PMS, которая привыкла оперировать номерами целиком.

Что стоит закладывать в шахматку с самого начала:

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

Синхронизация шахматки с внешними площадками бронирования (Booking.com, Ostrovok и подобные) — отдельная и не самая тривиальная тема: у каждого агрегатора свой протокол обмена, свои квоты запросов и свои особенности с ценами и минимальными сроками проживания. Здесь этого разбора нет — но важно понимать: даже с интеграцией агрегаторов шахматка остаётся лёгким веб-приложением, интеграция добавляет периодические фоновые задачи (раз в несколько минут опросить API, отправить обновление квот), а не постоянную высокую нагрузку.

Электронные замки: локальное управление без завязки на облако вендора

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

Многие современные замки для внутренних дверей и локеров используют беспроводные протоколы вроде Zigbee — а значит, ими можно управлять локально, через свой шлюз, без обязательной привязки к облаку производителя. Если у вас уже есть на сервере Zigbee2MQTT, поднятый по шагам на Ubuntu 24.04, добавить туда замки — это то же самое сопряжение устройства с координатором, что и для любого другого Zigbee-датчика. Замок публикует события в MQTT-топик, ваше приложение шахматки или отдельный небольшой скрипт подписывается на этот топик и пишет журнал: кто, когда, каким кодом открыл какую дверь.

Что стоит проверить у оборудования до покупки партии замков на весь хостел:

• Работает ли замок при пропадании интернета на сервере — остаётся ли у гостя физический способ попасть в комнату (мастер-ключ, аварийный код, скважина). Полагаться только на «облако вендора всегда онлайн» для входной двери — рискованная стратегия.
• Есть ли у замка локальный протокол вообще, или производитель заставляет работать исключительно через свой облачный сервис — тогда вы просто переносите ту же зависимость в другое место.
• Как долго держит заряд батарея и что происходит при её разрядке — обычно замок уходит в аварийный режим и требует механического ключа, об этом должен знать администратор смены.

Журнал событий по замкам стоит хранить рядом с шахматкой, а лучше — связать их логически: при заселении гостя система выдаёт временный код или карту, привязанные к сроку брони, и автоматически аннулирует их в момент планового выезда. Это не облачная магия, а обычный скрипт, который слушает MQTT и дёргает API PMS.

Гостевой Wi-Fi: своя сеть, простая авторизация, без сюрпризов

Для гостевого Wi-Fi задача на 90% решается на уровне сети, а не приложения. Отдельный SSID для гостей, отдельный VLAN на управляемом коммутаторе или Wi-Fi-контроллере, и жёсткое правило firewall: трафик из гостевого VLAN может идти только в интернет и на порт капчал-портала, и никуда больше во внутреннюю сеть хостела.

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

Отдельный вопрос — хранение логов подключений гостевого Wi-Fi. Требования к тому, что и как долго нужно хранить (MAC-адреса, время сессий, иногда — сопоставление с личностью гостя), в разных странах регулируются по-разному, и это тема отдельного разговора с юристом или как минимум отдельной статьи, а не то, что стоит додумывать самостоятельно. Что можно сказать точно на уровне инфраструктуры: если логи придётся хранить дольше, чем «пока гость не выехал», закладывайте под это отдельный том с ротацией и понятным сроком хранения, а не бесконечно растущий файл на общем диске.

Бэкапы и что делать, если сервер откажет в разгар сезона

Три системы — три разных по важности набора данных, и бэкапить их стоит по-разному:

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

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

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

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