Продукт и архитектура

IZI X — это операционная система для компьютерного клуба.

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

Основные части продукта

Backend и интерфейсы

Компонент	Для чего нужен
API	Основной backend IZI X. Хранит бизнес-логику, работает с клубами, сессиями, заказами, оплатами, устройствами и пользователями
CRM	Рабочий интерфейс клуба и саппорта: касса, смены, устройства, клиенты, продажи, настройки
Mobile Widget	Приложение/виджет для игрока: авторизация, баланс, сессии, действия клиента

ПО на игровых ПК и устройствах

Компонент	Для чего нужен
Desktop client	Клиент на игровом ПК. Управляет состоянием ПК, блокировкой, запуском сессии и связью с платформой
Device client	Агент устройства. Сверяет желаемое состояние с фактическим и сообщает телеметрию
Pod	Клиент для IZI Pod. Помогает управлять устройствами и состояниями, которые связаны с железом клуба

Кассовый ПК

На кассовом ПК обычно не требуется отдельный IZI-клиент. Для работы нужны:

• браузер с CRM;
• KkmServer.exe;
• kkm-watcher;
• доступ к кассе и локальной инфраструктуре клуба.

Железо клуба

В инфраструктуре клуба участвуют:

• игровые ПК;
• кассовые ПК;
• IZI Pod;
• ККМ;
• сетевое оборудование;
• серверы или хранилища, если они используются в клубе.

IZI Boot

IZI Boot — это система сетевой загрузки и централизованного управления запуском ПК в клубе.

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

Платформенные сервисы

Сервис	Зачем нужен
PostgreSQL	Основная база данных
RabbitMQ	Очереди и события между сервисами
Redis	Кэш и быстрые служебные данные
EMQX	MQTT-сообщения для устройств
MeshCentral	Удалённый доступ и управление ПК
TrueNAS	Хранилище и образы, если клуб использует IZI Boot
Grafana / Dash0	Мониторинг, логи, метрики и диагностика

Операционные сервисы

Компонент	Для чего нужен
Fleet	Контроль устройств, телеметрии и состояния ПК
Fleet enricher	Дополняет данные по устройствам и состояниям
Windbg analysis	Помогает разбирать BSOD и дампы
Cron jobs	Регулярные фоновые задачи
E2E tests	Автотесты основных сценариев CRM

Основные модули API

Модуль	За что отвечает
organizations	Организации
clubs	Клубы и их настройки
devices	ПК, Pod и другие устройства
sessions	Игровые сессии
catalog	Тарифы, товары и услуги
orders	Заказы и позиции заказа
billing	Баланс, оплаты и списания
players	Игроки и их данные
schedules	Расписания и тарифные окна
automations	Автоматические действия
analytics	Отчёты и показатели
support-integration	Интеграции для саппорта
platform	Общие платформенные функции
users	Пользователи и роли
izi-boot	Управление IZI Boot
monitoring	Мониторинг и диагностика

Ключевые сущности

Сущность	Что означает
Organization	Юридическая или управленческая организация
Club	Конкретный клуб
Device	ПК, Pod или другое устройство
Player	Игрок
Session	Игровая сессия
DeviceHold	Удержание или блокировка устройства
Tariff	Тариф игрового времени
Order	Заказ
OrderItem	Позиция заказа: тариф, товар, комбо или услуга
Schedule	Расписание действия тарифа или цены
Ledger	Финансовые движения по балансу
DesiredState	Какое состояние система хочет получить на устройстве
ObservedState	Какое состояние устройство фактически прислало

Как части системы общаются между собой

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

Для запросов, где нужен ответ сразу, используется API. Например: CRM просит создать заказ, открыть сессию или показать список устройств.

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

Обработчики событий должны быть устойчивыми к повторной доставке. Если событие пришло второй раз, система не должна создать дубль или сломать состояние.

Роли в системе

Роль	Кто это
PLAYER	Игрок или клиентское приложение
CRM	Действие из интерфейса клуба или саппорта
DEVICE	Действие от устройства
SYSTEM	Автоматическое системное действие

Что важно понимать саппорту

1. CRM показывает не «магическую картинку», а данные из API и связанных сервисов.
2. Если в CRM что-то выглядит странно, нужно проверять сущность: заказ, сессию, устройство, оплату, расписание или удержание.
3. Устройство может иметь желаемое состояние и фактическое состояние. Они могут временно отличаться.
4. Не каждую проблему видно в одном месте. Иногда нужно сверять CRM, логи, аудит, устройство и кассу.
5. Перед эскалацией нужно собрать конкретику: клуб, ПК, время, действие, ошибку, скриншоты и ссылку на переписку.

Проверочные вопросы

1. Для чего нужен API?
2. Чем DesiredState отличается от ObservedState?
3. Что такое DeviceHold?
4. Почему заказ и сессия — не одно и то же?
5. Где саппорт смотрит фактическое состояние ПК?
6. Почему нельзя делать вывод только по одному экрану CRM?