Коворкинг: доступ, переговорки и печать — своя инфраструктура за один месяц

MAATRIX

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

Три подписки, три админки — с чего начинается боль запуска

Типичный путь запуска коворкинга выглядит так: сначала находят производителя электронных замков с облачным сервисом управления — платите за каждую дверь или за каждого резидента в месяц. Потом ищут систему бронирования переговорных — отдельный SaaS с оплатой за место или за организацию, часто в долларах или евро. Потом решают вопрос с печатью — либо ставят МФУ с открытым доступом (и тогда любой гость распечатает что угодно бесплатно), либо подключают управляемую печать по подписке за страницу.

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

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

Контроль доступа резидентов: что реально нужно от системы

Для коворкинга контроль доступа — это не про видеонаблюдение и не про «умный дом», это конкретный набор требований:

• карта (RFID/NFC) или мобильное приложение как ключ, без физических ключей, которые теряются и не отзываются;
• разграничение зон — общая зона, приватные кабинеты, серверная/техническое помещение, у каждой свой список допущенных карт;
• гостевые пропуска с ограничением по времени — на день или на несколько часов;
• журнал проходов — не для слежки, а чтобы разбирать споры («меня не пустили», «карта не сработала») и синхронизировать доступ со статусом оплаты;
• автоматическая блокировка карты, если резидент не продлил абонемент — вручную такие вещи забывают отключать.

На своей инфраструктуре это выглядит так: на каждой двери — контроллер с Wiegand- или OSDP-считывателем (бюджетный вариант — платы на базе ESP32 с открытыми прошивками для RFID-доступа, промышленный — готовые контроллеры типа Mercury/HID, которые говорят по тому же протоколу). Контроллеры включены в локальную сеть коворкинга (лучше — в отдельный VLAN, изолированный от гостевого Wi-Fi) и стучатся в центральный сервис на вашем сервере, который хранит список карт, зоны доступа и журнал событий.

Минимальный стек на сервере — Postgres для базы карт и событий, небольшой сервис (свой на Python/Go либо готовый открытый проект уровня ESP-RFID для более простых инсталляций) и брокер сообщений между дверями и сервером, если контроллеров много:

# docker-compose.yml (фрагмент)
services:
  access-db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: access_control
      POSTGRES_USER: access
      POSTGRES_PASSWORD_FILE: /run/secrets/access_db_pass
    volumes:
      - access_db_data:/var/lib/postgresql/data
    networks:
      - internal

  access-api:
    build: ./access-api
    restart: unless-stopped
    depends_on:
      - access-db
    environment:
      DATABASE_URL: postgres://access:${ACCESS_DB_PASS}@access-db:5432/access_control
    networks:
      - internal
      - doors

Двери общаются с access-api только внутри своей сети doors, наружу этот сервис не смотрит вообще — управление доступом не должно быть доступно из интернета. Административная панель для выдачи карт открывается только через VPN/тейлнет, отдельно от гостевого и резидентского Wi-Fi. Похожая модель — карта резидента как единый ключ ко всему, включая доступ по абонементу, — разобрана в статье про контроль доступа по абонементам в фитнес-клубе: там та же связка «карта = статус оплаты = право прохода», только для другого бизнеса.

Переговорные комнаты: бронирование без пересечений и без Excel

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

На своём сервере это решается системой бронирования, которая живёт рядом с базой резидентов и точно так же не требует оплаты за каждое место. Практичный вариант — self-hosted система бронирования ресурсов (класс Booked Scheduler или self-hosted развёртывание Cal.com) в отдельном контейнере, с базой резидентов из того же Postgres, что и контроль доступа, — чтобы бронировать могли только действующие резиденты, а не кто угодно с интернета.

Что закрывает такая система на практике:

• календарь по каждой переговорке отдельно, с проверкой пересечений на уровне базы, а не на глаз;
• автоматическое освобождение слота, если встреча не подтверждена за N минут до начала (простое правило, а не искусственный интеллект);
• синхронизация с личным календарём резидента через CalDAV — бронь появляется в его Google Calendar или Outlook без ручного дублирования;
• экран или e-ink табличка у двери переговорной, которая тянет статус напрямую с сервера и показывает «занято до 15:30» без участия администратора.

CalDAV-мост проще всего поднять тем же Nextcloud (о его развёртывании на VPS есть отдельный разбор в блоге) — Nextcloud Calendar умеет отдавать ресурсы бронирования по протоколу, который понимают обычные почтовые клиенты, и не требует от резидентов ставить отдельное приложение. Похожий подход — свой календарь вместо стороннего сервиса бронирования — разбирается в статье про бронирование залов через свой календарь: там для фотостудии, здесь для переговорных, логика бронирования ресурса на своей инфраструктуре не меняется.

Печать и сканирование: без очереди и без бесконтрольного расхода бумаги

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

На своей инфраструктуре печать — это классический CUPS (Common Unix Printing System) на том же сервере или на отдельной лёгкой машине рядом с принтерами, с учётными записями резидентов (локальными или через LDAP, если вы уже завели каталог пользователей для доступа и бронирования). Сетевые принтеры подключаются по IPP, каждое задание печати логируется в /var/log/cups/page_log — этого достаточно, чтобы посчитать, сколько страниц напечатал каждый резидент за месяц, и включить это в его счёт как отдельную строку, а не подарок за счёт коворкинга.

# добавить сетевой принтер на сервере печати
lpadmin -p meeting-room-printer -E \
  -v ipp://192.168.10.55/ipp/print \
  -m everywhere

# включить учёт страниц по пользователям
cupsctl --enable-printer-accounting

# пример разбора page_log для подсчёта страниц резидента за месяц
grep "coworker_ivanov" /var/log/cups/page_log | awk '{print $7}' | \
  awk -F- '{sum+=$1} END {print "Страниц напечатано:", sum}'

Более продвинутый вариант — «печать по бейджу»: задание ставится в очередь и распечатывается только после того, как резидент приложил карту к считывателю у принтера. Это решает проблему забытых на лотке документов с чужой перепиской, но требует контроллера у самого принтера — по сути того же RFID-считывателя, что и на дверях, только подключённого к серверу печати вместо access-api. Это уже усложнение сверх базового месячного плана, и добавлять его стоит не в первую волну запуска, а когда база из трёх систем уже работает стабильно.

Архитектура на одном сервере и разворачивание за месяц

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

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

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

Сколько это экономит по сравнению с готовыми SaaS

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

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

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