Эксплуатация и предоставление доступа

Программное обеспечение «Пантано» предоставляется по сервисной модели (SaaS): экземпляр программного обеспечения разворачивается и эксплуатируется на технических средствах правообладателя, пользователи получают доступ к нему через сеть Интернет. Установка программного обеспечения на технические средства пользователя не требуется и не производится. Настоящий документ описывает порядок развёртывания, эксплуатации, обновления и восстановления системы на серверах правообладателя, а также порядок предоставления доступа пользователям.

Архитектура развёртывания

Размещение

Система размещается в центре обработки данных на территории Российской Федерации (Санкт-Петербург), у российского провайдера облачной и серверной инфраструктуры Selectel. Оборудование за пределами Российской Федерации не используется. Персональные данные пользователей и гостей обрабатываются и хранятся в пределах этой инфраструктуры.

Состав серверных ролей

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

Роль	Что выполняет
Сервер приложения (основной)	процессы серверной части (ядра), обработчики фоновых очередей, сборщик ошибок, контур журналов
Сервер данных и публикации	СУБД PostgreSQL, документная СУБД MongoDB, Redis, менеджер процессов Node.js-приложений (витрина, кабинет), сервер обмена в реальном времени, средства защиты периметра, тестовый и демонстрационный контуры
Сервер сборки и наблюдения	сервер репозиториев и конвейеров сборки, система метрик и панелей наблюдения, горячий резерв СУБД и Redis, дополнительный процесс серверной части
Сервер вспомогательных сервисов	служба структурированного журналирования, служба единого входа и внутренняя база знаний, тестовая СУБД
Сервер резервных копий	приём и хранение резервных копий со всех серверов кластера, изолированная учётная запись только на запись копий
Сервер сборки мобильных приложений	сборка iOS- и Android-приложений предприятий (macOS-хост, требуется для iOS)

Каждая ключевая роль имеет назначенный резерв на другом сервере кластера: СУБД PostgreSQL, MongoDB, Redis и менеджер процессов Node.js развёрнуты в схеме «основной — резерв», внешний адрес публикации переключается на резервный сервер. Порядок переключения описан в разделе 6.

Прикладной состав

• Серверная часть (ядро) — приложение Ruby on Rails под сервером приложений Unicorn: доменная модель, бизнес-правила, все программные интерфейсы.
• Обработчики фоновых задач — Sidekiq поверх Redis: отложенные и регулярные задания (начисление и сгорание бонусов, пересчёт уровней и сегментов, триггерные сценарии, синхронизация меню с кассами, выгрузки на площадки, рассылки, обслуживание доставки), включая планировщик по расписанию.
• Сервер обмена в реальном времени — Faye: доставка изменений корзины, заказа и сессии на открытые экраны кабинета и витрины.
• Клиентские приложения — витрина заказа и личный кабинет: Node.js-приложения Nuxt под менеджером процессов PM2 в кластерном режиме; витрина работает с серверным рендерингом страниц.
• Реляционная СУБД — PostgreSQL с расширением PostGIS: основная модель данных, геометрия зон доставки и геозапросы.
• Документная СУБД — MongoDB в схеме репликации: корзины, журналы обмена, объёмные слабоструктурированные данные.
• Хранилище ключ-значение — Redis: очереди фоновых задач, кэш, распределённые блокировки.
• Объектное хранилище и CDN — S3-совместимое хранилище провайдера и сеть доставки содержимого: изображения меню и содержимого сайтов, пакеты обновления мобильных приложений.

Масштабирование

• Горизонтальное по приложению. Процессы серверной части и Node.js-приложений запускаются на нескольких серверах кластера и включаются в балансировку; добавление сервера сводится к развёртыванию роли и включению его в балансировку.
• По числу процессов. Число рабочих процессов Unicorn и число процессов PM2 в кластере задаётся конфигурацией на каждом сервере и подбирается по числу ядер.
• По очередям. Фоновые задания разнесены по именованным очередям с раздельными лимитами параллельности; узкое место расширяется добавлением обработчиков нужной очереди, не затрагивая остальные.
• По данным. PostgreSQL реплицируется на резервный сервер (реплика используется и как горячий резерв); MongoDB работает набором реплик; Redis — в схеме «основной — реплика».
• По статике. Изображения и пакеты обновления мобильных приложений раздаются из объектного хранилища через CDN и не нагружают серверы приложений.

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

Требования к окружению

Серверное окружение

Компонент	Требование
Операционная система серверов	Ubuntu Server LTS
Язык и платформа ядра	Ruby, каркас Ruby on Rails
Сервер приложений ядра	Unicorn
Платформа клиентских приложений	Node.js, npm
Каркас клиентских приложений	Nuxt (Vue, TypeScript), сборщик Vite
Менеджер процессов Node.js	PM2
Реляционная СУБД	PostgreSQL с расширением PostGIS
Документная СУБД	MongoDB, режим набора реплик
Хранилище ключ-значение	Redis
Обмен в реальном времени	Faye
Учёт часовых поясов	системная база часовых поясов, обновляется вместе с ОС

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

Дополнительно на серверах требуются: ImageMagick (обработка изображений), wkhtmltopdf (формирование печатных форм и накладных), утилиты архивации и передачи резервных копий.

Окружение сборки мобильных приложений

Компонент	Требование
Хост сборки iOS	macOS с установленным Xcode и инструментами командной строки, CocoaPods
Хост сборки Android	JDK, Android SDK и Build Tools, Gradle
Оболочка приложения	Capacitor
Платформа сборки клиентского кода	Node.js

Требования к рабочим местам пользователей

• Личный кабинет и витрина — современный браузер (Chrome, Safari, Firefox, Edge) актуальной или предыдущей версии, разрешение экрана от 1280 точек по ширине для кабинета; витрина работает и на экранах телефонов.
• Мобильное приложение — iOS 15.0 и выше, Android 7.0 и выше (минимальный уровень API 24; сборка ведётся под уровень API 36).
• Установка дополнительного программного обеспечения на рабочие места не требуется.

Порядок развёртывания и обновления

Хранение исходного кода и конвейер

Исходный код хранится в системе управления версиями GitLab, развёрнутой на собственном сервере правообладателя. Сборка и развёртывание выполняются конвейерами GitLab CI/CD. Конфигурация конвейеров хранится вместе с кодом; параметры окружений и секреты — в защищённом хранилище переменных GitLab и в конфигурационных файлах на целевых серверах, в репозиторий не попадают.

Модель ветвления: основная ветка соответствует производственному окружению; для ядра дополнительно ведётся ветка разработки. Предусмотрены окружения production (боевое), staging (предпродакшн) и development (разработка).

Стадии конвейера

1. Проверка. Статический анализ и проверка типов, автоматические тесты. Для ядра — набор тестов RSpec, запускаемый параллельно; для клиентских приложений — линтеры, проверка типов и модульные тесты. Непройденная проверка останавливает конвейер.
2. Сборка. Для клиентских приложений — сборка производственного пакета; для мобильных приложений — сборка iOS- и Android-пакета на выделенном хосте сборки с подстановкой параметров конкретного предприятия.
3. Развёртывание. Для ядра — Capistrano: выкладка новой ревизии в отдельный каталог, применение миграций базы данных, переключение символической ссылки, перезапуск процессов приложения и обработчиков очередей. Для витрины и кабинета — развёртывание средствами PM2 с последующей сборкой на целевом сервере. Для вспомогательных сервисов — Kamal (развёртывание контейнеров).
4. Публикация мобильного пакета. Пакет обновления клиентской части мобильных приложений выкладывается в объектное хранилище и раздаётся через CDN; манифест, указывающий на актуальный пакет, публикуется последним — до его публикации приложения продолжают работать на прежней версии.

Развёртывание в производственное окружение выполняется по завершении проверок; для ядра запуск производственного развёртывания — ручное действие ответственного инженера.

Контроль корректности выкладки и откат

Выкладка клиентских приложений выполняется по схеме, исключающей обслуживание запросов недособранной версией:

1. новая версия собирается в отдельный каталог, действующая версия при этом продолжает обслуживать пользователей;
2. собранная версия запускается на служебном порту и проверяется контрольным запросом («дымовой» тест серверного рендеринга); неуспех останавливает выкладку, в работе остаётся прежняя версия;
3. каталоги меняются местами одной операцией, процесс перезапускается без разрыва обслуживания;
4. после перезапуска выполняется проверка работоспособности боевого процесса; при неуспехе автоматически возвращается предыдущая сборка, а выкладка помечается неуспешной.

Откат к предыдущей версии выполняется повторным развёртыванием предыдущей ревизии; для ядра предыдущие ревизии сохраняются на сервере и переключаются символической ссылкой.

Изменения схемы данных

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

Обновление мобильных приложений

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

Резервное копирование

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

Состав резервных копий:

• базы данных PostgreSQL (все базы производственного контура);
• база данных MongoDB производственного контура;
• снимок Redis;
• конфигурации системного и прикладного программного обеспечения, включая конфигурации публикации и TLS-сертификаты;
• содержимое каталогов веб-приложений и загруженных файлов;
• задания планировщика и описания процессов менеджера PM2;
• образы и тома контейнеризованных вспомогательных сервисов.

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

Цикл	Периодичность	Глубина хранения
Ежесуточный	каждые сутки	четыре последние копии
Еженедельный	раз в неделю	две последние копии
Ежемесячный	раз в месяц	одна копия

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

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

Мониторинг и журналирование

Мониторинг

• Метрики и панели наблюдения — Prometheus и Grafana: метрики хостов (процессор, память, диск, сеть), метрик служб (СУБД, Redis, очереди заданий) и прикладных показателей. Панели и правила оповещения ведутся вместе с конфигурацией.
• Сбор ошибок приложений — Sentry, развёрнутый на собственных серверах: необработанные исключения ядра, витрины, кабинета и мобильных приложений с привязкой к версии выпуска и восстановлением исходных позиций по картам кода.
• Профилирование производительности — средства прикладного мониторинга производительности для ядра.
• Контроль доступности — проверка ответа боевых процессов после каждой выкладки (раздел 3.3) и постоянные внешние проверки доступности контура.

Журналирование

• Системные и прикладные журналы — журналы серверов приложений, обработчиков очередей и менеджера процессов на каждом сервере, с ротацией средствами ОС.
• Централизованные журналы — контур сбора и поиска журналов на выделенном сервере.
• Структурированное журналирование бизнес-событий — отдельная служба, принимающая события от ядра: обмен с внешними системами, отправка сообщений, платёжные операции. События доступны по поиску и по идентификатору сущности (заказ, организация).
• Журнал интеграций в продукте — часть личного кабинета: сотрудник предприятия видит ленту обмена с кассой, агрегатором, службой доставки — как по организации в целом, так и по конкретному заказу.
• Журнал действий с заказом — история изменений и комментариев в карточке заказа с указанием, кто и когда внёс изменение.

Обеспечение отказоустойчивости и восстановление

Для каждой критичной роли определён резервный сервер и письменная процедура переключения. Процедуры покрывают отказ сервера данных и публикации как наиболее нагруженной роли и включают:

1. восстановление конфигураций публикации и TLS-сертификатов на резервном сервере из резервной копии или синхронизацией с основного, перенос внешнего адреса;
2. перевод реплики PostgreSQL в режим основного сервера;
3. развёртывание каталогов веб-приложений из резервной копии либо синхронизацией;
4. перевод реплики Redis в режим основного;
5. запуск процессов Node.js-приложений на резервном сервере из сохранённого описания процессов;
6. включение средств защиты периметра на резервном сервере;
7. восстановление заданий планировщика.

Процедуры оформлены пошагово, с командами, и хранятся вместе с описанием инфраструктуры. Регламент предусматривает два режима: плановый перенос (основной сервер доступен) и аварийный (основной сервер недоступен, восстановление идёт из резервных копий).

Безопасность эксплуатации

• Доступ к серверам — только по протоколу SSH с аутентификацией по ключам; парольная аутентификация отключена. Доступ сотрудников к внутреннему контуру — через VPN.
• Разграничение прав в системе — ролевая модель для сотрудников предприятий (раздел 2 функционального описания); внешние программы работают от имени учётной записи сотрудника и получают ровно её права.
• Изоляция данных предприятий — все запросы выполняются в границах организации, определяемой доменным именем запроса либо учётной записью.
• Защита периметра — система обнаружения и блокировки вредоносной активности (CrowdSec) с блокировкой на уровне межсетевого экрана.
• Защита от автоматических обращений — ограничение частоты запросов кода подтверждения в нескольких временных окнах одновременно, раздельно по адресу источника и по номеру телефона; подключаемая защита от автоматизированных обращений на форме входа.
• Шифрование канала — TLS на всех внешних контурах. Сертификаты для служебных доменов выпускаются и продлеваются автоматически (протокол ACME); сертификаты для собственных доменов предприятий выпускает и продлевает сама система при подключении домена.
• Секреты — реквизиты подключений к внешним системам хранятся на стороне сервера, в интерфейсе показываются маской и наружу не отдаются; секреты конвейеров хранятся в защищённом хранилище переменных с маскированием в журналах сборки.
• Карты исходного кода клиентских приложений публично не раздаются: после передачи в систему сбора ошибок они удаляются из состава производственной сборки.

Порядок предоставления доступа пользователям

Подключение предприятия

1. Предприятие обращается к правообладателю; заключается договор на использование программного обеспечения по выбранному тарифному плану.
2. Сотрудник правообладателя заводит организацию: реквизиты, часовой пояс, валюта, набор подключённых возможностей, первая точка.
3. Создаётся учётная запись владельца — с адресом электронной почты в качестве логина; владелец далее самостоятельно заводит остальных сотрудников и назначает им роли.
4. Организации назначается ознакомительный период либо тарифный план. Состояние организации (ознакомительный период, приближение предельного срока, блокировка за неоплату) отображается в кабинете и, в случае блокировки, останавливает приём заказов.

Адрес витрины и белая маркировка

Витрина предприятия публикуется по доменному имени. Предусмотрены два варианта:

• поддомен в служебной доменной зоне платформы — выдаётся сразу при подключении, сертификат выпускается автоматически;
• собственный домен предприятия — предприятие направляет домен на адрес системы; домен вносится в конфигурацию публикации, система выпускает и продлевает для него сертификат.

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

Доступ гостей

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

Техническая поддержка

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

Регламент обслуживания

• Обновления производственного контура выкладываются по мере готовности изменений, без остановки обслуживания: перезапуск процессов выполняется по схеме с постепенной сменой рабочих процессов.
• Плановые работы, требующие недоступности (обновление основной СУБД, переключение ролей), выполняются в согласованное окно с предварительным уведомлением.
• Резервные копии формируются автоматически по расписанию, без участия оператора.
• Мониторинг работает постоянно; оповещения направляются дежурному инженеру.