В начале — питч и архитектура платформы MATRIX. Дальше — ответы по рынку скинов CS2, Морфеусу, инфраструктуре, таймингу сделок и модели аналитики.
готово01
Платформа MATRIX
Enterprise-решение для алгоритмической торговли цифровыми активами. Масштабируемость, скорость и абсолютный контроль — не надстройка над скриптом, а отдельная инфраструктура.
Независимых сервисов20+
Кластера платформы2
Ручной труд в сделке0%
Рынок игровых предметов — Steam, DMarket, Buff, TM — огромен, но устроен неэффективно. Выигрывает не тот, у кого больше людей у экрана, а тот, у кого инфраструктура успевает за миллисекундами.
Фрагментация
Десятки изолированных площадок со своими правилами и API. Единой точки входа нет: каждый рынок — отдельный диалект цен, комиссий и лимитов.
Скорость решает всё
Выгодные предложения появляются и исчезают за миллисекунды. Человек или простой скрипт на этом окне всегда проигрывает.
Стеклянный потолок
При росте объёмов монолитные боты не держат нагрузку: теряют транзакции, получают баны аккаунтов и замораживают капитал.
Что из этого следует
Масштаб здесь упирается не в идею стратегии, а в способность системы пережить отказ одной площадки и не смешать чужие балансы.
MATRIX — не «торговый бот», а высоконагруженная микросервисная инфраструктура банковского уровня: больше 20 независимых сервисов.
01
Полная автоматизация
От сканирования рынка до финансового клиринга сделки — без ручного труда. Решение, резерв средств и исполнение идут по цепочке сервисов.
02
Омниканальность
Одновременная торговля на ключевых биржах через унифицированные адаптеры. Новая площадка — новый ship, а не переписывание ядра.
03
Big Data и готовность к AI
Сбор и анализ рыночных данных в реальном времени, чтобы на накопленной истории строить предиктивные модели, а не только реагировать на текущий стакан.
«Мы создали не скрипт, который кликает по маркету, а фундамент, на котором можно наращивать оборот, не переписывая систему с нуля.»
Система разделена на два кластера. Они работают в симбиозе: один смотрит на рынок, второй решает и исполняет.
Matrix_3 · SATI
Глаза и уши
Подсистема сбора данных.
Непрерывно парсит рынки.
Обходит блокировки через proxy-инфраструктуру.
Отдаёт в ядро уже очищенные данные и сигналы о ценах.
Matrix_2 · торговое ядро
Мозг и руки
Принимает решения.
Контролирует финансы и лимиты.
Исполняет сделки через ships.
Не смешивается с парсингом: отказ сборщика не роняет казначейство.
Поток идёт снаружи внутрь и обратно наружу: рынки отдают цены, ядро возвращает сделки.
Steam, TM, Buff
Proxy
Воркеры-грабберы
SATI API и Trigger
Сигналы о ценах
Trainman, Sovet
Treasury, Skinhub
Ganesha, Ikarus
Слева направо · данные
Внешние рынки → proxy → воркеры сбора → SATI. Наружу из этого контура уходит подписка на цены, внутрь ядра — сигнал, что цена стала интересной.
Дальше · решение и сделка
Оркестрация ставит задачу, казначейство держит лимиты, исполнители ходят в API площадки. Парсинг и сделка — разные стрелки, не один процесс.
готово02
Финансы, сделка и предложение
Виртуальные активы в MATRIX учитываются как реальные деньги: резерв до сделки, изолированные ключи, лимиты аккаунтов. Предложение инвестору — масштабировать капитал на уже собранном фундаменте.
Treasury
Казначейство. Строгий контроль балансов: перед любой сделкой средства резервируются через систему авизо. Двойная трата исключена — деньги нельзя потратить дважды, пока резерв не снят или не проведён.
Skinhub
Единое хранилище инвентаря на PostgreSQL и ClickHouse. Операционный учёт предмета и мгновенная аналитика по нему живут рядом, а не в разных таблицах «на глаз».
Masterkey и Trinity
Изолированное хранение токенов доступа и жёсткое разграничение прав: кто может торговать, на каком рынке и с каким аккаунтом.
Hooly
Автоматический контроль лимитов аккаунтов. Защита от банов со стороны бирж, когда объём или частота упираются в правила площадки.
Идеальная сделка — эстафета, а не один бот. Поиск находит цену, радар подтверждает, оркестратор командует, казна резервирует, исполнитель выкупает.
Поиск · Choi — подписка на актив. Система уже смотрит конкретный предмет, а не весь каталог вслепую.
Радар · SATI — сигнал: цена выгодная. Окно не ждёт, пока его заметят глазами.
Оркестратор — команда на покупку уходит в контур решения.
Казна — резерв средств, авизо. Без одобрения резерва выкупа нет.
Бот · Ikarus — инструкция на выкуп и API-запрос покупки на биржу.
Изоляция отказов. Упало API Steam — торговля на DMarket и Buff продолжается. Площадки не делят одну точку отказа.
02
Масштабирование площадок. Новая биржа — один плагин, ship. Ядро системы остаётся прежним.
03
Аналитический центр · Persephone. Торговые события из Kafka сливаются в OLAP на ClickHouse. Тренды видны по всей истории событий, а не по одному графику маркета.
MATRIX — не отдельный алгоритм под одну связку, а инфраструктурный фундамент для маркетмейкера на рынке цифровых активов.
Технологическая база спроектирована и реализована.
Архитектура готова к кратному росту торговых оборотов.
Следующий шаг — масштаб капитала, чтобы забирать долю рынка, и предиктивные AI-модели на уже накопленной big data.
«Следующий шаг — не переписать систему, а наполнить её капиталом и моделями, которым уже есть на чём учиться.»
готово03
Карта платформы Matrix
Платформа делится на две логические группы — Matrix_2 и Matrix_3. Ядро ведёт бизнес-логику и деньги. SATI смотрит на рынки, прокси и сессии. В справочнике Морфеус — рабочий контур оператора; в этой карте srv-morpheus — его оркестратор и API-шлюз внутри Matrix_2.
SATI API и Trigger — единая точка доступа к лотам и событиям.
Воркеры — Infograbber, SessionChecker.
Proxy — Master, Server, IP Manager.
Steam — Zion / Tank: trade offers и API keys.
Как группы связаны
Внешние рынки
Matrix_3 · SATI
Matrix_2 · ядро
Сделка на площадке
Подписка на цены — ядро говорит SATI, какие предметы слушать.
Запрос данных рынка — поиск и аналитика забирают уже собранные лоты и ордера.
Торговые операции — ships ходят в API площадок отдельно от парсинга.
Площадки контура — Steam, TM, Buff, DMarket.
готово04
Торговое ядро Matrix_2
Бизнес-логика, балансы, инвентарь и исполнение. Сервисы ядра не ходят в маркет «сами по себе»: оркестратор ставит задачу, казна разрешает деньги, ship делает одну операцию на одной площадке.
Кто принимает решение и кто имеет право его исполнить.
srv-morpheus
Центральный оркестратор и API-шлюз веб-интерфейса.
srv-trainman
Оркестратор бизнес-задач: проводит решения от постановки до результата.
srv-sovet
Координатор предобработки решений и «корабельной логики» — какой ship и на каких условиях получит инструкцию.
srv-komandor
Оркестратор торговых операций на внешних платформах, шипах. Маршрутизирует команду на нужный маркет.
srv-trinity
Пользователи, группы и доступ к рынкам.
srv-masterkey
Хранение и управление торговыми аккаунтами.
auth
Библиотека-обёртка над gRPC-авторизацией.
Деньги, предметы и намерения. Сделка не стартует, пока казна не зарезервировала сумму, а лимиты аккаунта это позволяют.
srv-treasury
Казначейский сервис финансовых операций. Резерв (авизо) и списание — его зона.
srv-skinhub
Централизованное хранилище игровых активов: PostgreSQL и ClickHouse.
srv-hooly
Намерения и контроль лимитов хранилищ, чтобы аккаунт не упёрся в бан из-за объёма.
srv-futures
Фьючерсные намерения — обязательства, которые ещё не стали немедленной сделкой.
srv-merovingen
Комплексные бизнес-операции: саги и транзакции, которые состоят из нескольких шагов и должны сойтись целиком.
Исполнители изолированы: каждый ship делает одну роль на биржах. Падение адаптера продажи не обязано останавливать покупку на другой площадке.
srv-ganesha-*
Продажа предметов на маркетах: TM, Steam, Buff, DMarket.
srv-ikarus-*
Заказ покупки предметов на маркетах.
srv-logos-*
Покупка предметов на маркетах.
Почему это отдельные сервисы
Заказ покупки, сама покупка и продажа — разные контракты с площадкой. Общий ship на все действия смешал бы ошибки и лимиты. Здесь у каждой операции свой адаптер, ядро вызывает его по имени маркета.
Поиск лучшей цены и разбор того, что уже произошло. Choi смотрит вперёд по стакану, Persephone — назад по событиям.
srv-choi
Поиск наилучших цен и лотов, уведомления, когда связка стоит внимания.
srv-persephone
Аналитика и отчётность на ClickHouse.
srv-neo
API отчётов по сделкам.
tracer
Отправка бизнес-событий в Kafka — сырьё для аналитического контура.
srv-logist
gRPC API событий логистики: где предмет находится по пути сделки.
alarm
Библиотека алармов и уведомлений.
готово05
Сбор данных Matrix_3 · SATI
Парсинг, прокси, сессии и курсы. SATI не торгует: он поставляет лоты, ордера и факт, что сессия или IP ещё живы. Торговое ядро подписывается на результат, а не ходит в HTML площадки само.
srv-api
API лотов, ордеров и аккаунтов. Унифицированный доступ для ядра.
srv-trigger
События лотов и ордеров через AMQP. Подписчик узнаёт об изменении, а не опрашивает базу вслепую.
model
Словарь данных и контракты для плагинов. Все маркеты говорят с SATI на одной модели предмета.
srv-infograbber
Ядро сбора. Задания на информацию о лотах и ордерах проходят через него.
srv-sessionchecker
Фоновая проверка невалидных сессий и банов.
srv-updatechecker
Планировщик обновления рыночных данных.
srv-mhnsearcher
Обнаружение новых предметов на площадках.
srv-currency
Курсы валют, чтобы цены разных маркетов можно было сравнивать.
srv-pinger
Периодические ping-запросы к TM, чтобы сессия площадки не засыпала.
Запросы к площадкам не выходят с одного IP. Пул распределяет нагрузку и помнит, какой адрес уже в блоке.
srv-master
Распределение запросов по IP, балансировка.
srv-server
Отдельный прокси-узел со своим rate limit.
srv-master-external
Автономный gRPC-шлюз для пула прокси-серверов.
srv-ip-manager
Менеджер IP-адресов и кастомных блокировок.
У каждой площадки свой SDK и свои коды ошибок. Ядро не знает, как устроен HTML Steam: это знает библиотека маркета.
lib-m1
SDK Steam Market.
lib-m2
SDK market.csgo.com.
lib-m3
SDK Buff.
lib-m4
SDK DMarket.
lib-*-errors
Общие коды ошибок для каждого маркета, чтобы ядро реагировало на класс сбоя, а не на текст площадки.
Рядом со сбором
srv-steam-account
Регистрация новых аккаунтов Steam.
srv-inventory-csv
Экспорт инвентаря Steam в CSV.
srv-zion-v2
Создание и принятие предложений обмена, trade offer.
qa-cli-tool
Инструмент для QA: проверка контура без ручного прохода по сервисам.
готово06
Поток данных одной сделки
Пример покупки: SATI замечает цену, Trainman открывает решение, Sovet проверяет логику, Treasury резервирует деньги, Komandor отдаёт команду в Ikarus, площадка подтверждает выкуп, казна списывает резерв.
Choi
SATI · Trigger
Trainman
Sovet
Treasury
Komandor
Ikarus
Рынок
Подписка — Choi подписывается на предмет (MHN) через триггер SATI.
Сигнал — SATI присылает уведомление: найдена выгодная цена.
Решение — Trainman создаёт decision на покупку.
Бизнес-логика — Sovet обрабатывает условия сделки.
Резерв — Treasury резервирует средства, авизо. Ответ: средства зарезервированы.
Инструкция — Sovet отправляет команду на покупку.
Маршрут — Komandor направляет её на Ikarus нужного маркета.
Исполнение — Ikarus делает HTTP или gRPC-запрос покупки на внешний рынок.
Успех — площадка подтверждает, статус становится «куплено».
Клиринг — статус поднимается обратно по цепочке, Treasury списывает зарезервированные средства.
Закрытие — Trainman фиксирует: решение выполнено успешно.
Где здесь деньги
Между сигналом и запросом на биржу стоит резерв. Ikarus не покупает, пока Treasury не ответил, что сумма занята. После успеха списывается именно резерв, а не «ещё одна» сумма с баланса.
готово07
Длинные успешные инвестиции
Историческая динамика кейсов CS: покупка в апреле 2022 и цена на декабрь 2025. Средний профит по выборке — 612%, среднегодовые — 193%.
Предмет
Цена 04.22
Цена 12.25
Профит
Годовые
Средняя
612%
193%
в работе08
Перечень маркетплейсов
Планируется список ~50 площадок для интеграции: название, ссылка и объём торгов (Steam Helper / открытые источники).
Раздел готовится
Сбор данных поручен, после проверки появится интерактивная таблица объёмов и приоритетов интеграции.
готово09
Что такое скины и чем они отличаются
Скины CS2 — торгуемые цифровые активы внутри экосистемы Steam с собственной ликвидностью, редкими модификаторами и многомиллиардным оборотом.
Капитализация рынка~$7,69 млрд
Годовой оборот~$4,2 млрд
Выручка Valve с CS2~$1,16 млрд
Float Value
Число износа от 0 до 1. Скин не ухудшается от игры. Категории: FN → MW → FT → WW → BS. Редкие float дают коллекционную премию.
Pattern Seed
Индекс 0–1000 задаёт сдвиг текстуры. У Case Hardened паттерны Blue Gem поднимают цену с сотен долларов до сотен тысяч.
Модификаторы
StatTrak™ (+20–100%+), сувенирные турнирные версии, легендарные стикеры (Katowice 2014 и др.).
Жизненный цикл
Релиз → стабилизация → редкий пул → инвестиционная фаза роста на фоне сжатия предложения.
готово10
Что влияет на стоимость скина
Цена — сумма редкости, состояния, паттерна, модификаторов и внешних шоков мета/киберспорта/Valve.
30%
Базовая версия стандартного качества
55%
Версия со StatTrak™
80%
Топ Float или редкий Pattern
100%
Раритетные наклейки (Katowice 2014 и сопоставимые)
Мета оружия — AK / M4 / AWP дают основной игровой спрос; ножи и перчатки — 95% топ-ценника.
Баффы и нерфы — мгновенно двигают спрос.
Мейджоры — хайп стикеров и просадок перед турниром.
Распродажи Steam — типичная просадка 5–15%.
Статус «контрабанда» / уход кейса из дропа — долгосрочный рост на сжатии предложения.
готово11
Как зарегистрироваться
Ручная регистрация Steam, вход на маркеты через OpenID и архитектура нашего автоматического регистратора аккаунтов.
Email и страна — подтвердите почту, выберите регион (влияет на валюту и цены).
Письмо Valve — подтвердите адрес по ссылке из письма.
Логин и пароль — уникальный логин ≠ публичный никнейм; пароль от 8 символов.
Готово — скачайте клиент и войдите.
Если не приходит SMS
Подождите 10–15 минут, перезагрузите телефон.
Проверьте международный формат номера (+7, +380…).
После серии запросов возможен кулдаун до 24 часов.
Надёжнее — Steam Guard в мобильном приложении: коды без SMS.
Сторонние маркеты авторизуют через Steam OpenID («Войти через Steam»).
Пароль не передаётся сайту-партнёру.
Партнёр получает только публичные SteamID64, аватар и имя.
Всегда проверяйте адресную строку: должен быть steamcommunity.com.
Микросервис-регистратор — автоматизированный модуль (бот/парсер), который имитирует действия реального пользователя или использует API-запросы для массового создания учётных записей Steam.
Очередь задач
Микросервис-регистратор
БД / сессии
Генерация учётных данных — уникальный логин и надёжный пароль; выделяется временный или постоянный почтовый ящик через API собственного почтового сервера либо сервисов временной почты.
Антифрод-окружение — каждая регистрация (или небольшая пачка) идёт через чистые резидентские или мобильные прокси. Подменяются User-Agent, Accept-Language и параметры браузера (fingerprint), чтобы Steam не связывал аккаунты между собой.
Запрос и captcha — формируется запрос на store.steampowered.com/join/createnewaccount. При reCAPTCHA / hCaptcha токен берётся через API внешних сервисов (CapMonster, 2Captcha, Anti-Captcha) и передаётся в Steam.
Автоподтверждение email — микросервис подключается к ящику по IMAP или API, находит письмо от Steam, извлекает ссылку/код и подтверждает адрес.
Финализация — завершающий запрос с логином и паролем; сервис получает cookies сессии (sessionid, steamLoginSecure) и публичный SteamID64.
Сохранение — готовый аккаунт (логин, пароль, почта, cookies, SteamID, при необходимости maFile) пишется в БД или уходит в основную систему через REST API / брокер сообщений (RabbitMQ, Kafka).
Почему не приходит SMS при авто-привязке номера
Если модуль привязывает номера через SMS-Hub, 5SIM, OnlineSIM и т.п., SMS часто «не доходит» из‑за защиты Valve:
Virtual / VOIP — Steam фильтрует виртуальные номера: запрос как будто принят, но SMS фактически не уходит.
Чёрный список IP — регистрация и привязка с одного «подозрительного» прокси попадают под спам-фильтр Valve.
Rate limit — частые запросы к одному оператору/диапазону номеров дают кулдаун 24–48 часов.
Как решаем в архитектуре
Мобильные прокси той же страны, что и привязываемый номер.
После активации Steam Guard — мобильный аутентификатор (SDA / Steam-Auto-Cloud): физический SMS нужен в основном на этапе Guard; дальше коды считаются из Shared Secret (.maFile) через SteamTotp.
готово12
Как покупают скины: пользователь и Морфеус
Полный путь покупки «для гражданина» через Steam Market и алгоритмическая закупка через ордера платформы. Ручной сценарий — база правил Valve; Морфеус поверх него автоматизирует объём, ценовой коридор и контроль исполнения.
Типовой путь частного покупателя на Торговой площадке Steam — от допуска к рынку до попадания скина в инвентарь.
Допуск к торговле — аккаунт должен соответствовать требованиям Valve: включён Steam Guard (минимум 15 дней), за последние 12 месяцев есть хотя бы одна покупка в Steam (но не новее 7 дней), нет временных блокировок обмена.
Пополнение кошелька — «Об аккаунте» → «Пополнить баланс»: карта, подарочные карты Steam или поддерживаемые платёжные системы.
Поиск скина — в списке игр выбрать Counter-Strike 2; искать по названию (например, AK-47 | Ice Coated) или через «Показать параметры поиска»: тип оружия, качество (FN / MW / FT / WW / BS), наличие StatTrak™.
Проверка лота — на странице предмета: график цен, список лотов продавцов; наведение на иконку показывает стикеры и патчи.
Оформление покупки — два режима:
Купить мгновенно — кнопка «Купить» у самого дешёвого лота → согласие с Соглашением подписчика Steam → «Заказать».
Запрос на покупку (автопокупка) — «Купить…» под графиком: желаемая цена и количество; система купит, когда кто-то выставит скин по этой цене.
Получение — предмет сразу в инвентаре Steam; в CS2 — «Инвентарь» → «Заменить для обеих команд» (или T / CT).
Trade Hold · 7 дней
Скин появляется в инвентаре сразу, но на него накладывается 7-дневный бан на обмен: нельзя передать другому игроку и нельзя продать на сторонних площадках, пока hold не снимется. Это ключевое ограничение, которое закладывается и в тайминг сделок Морфеуса.
В Морфеусе закупка — это не ручной клик по лоту, а решение (лот / ордер) с жёсткими параметрами и автоматическим исполнением.
Создание решения
Параметры ордера
Алгоритм ищет и покупает
Прогресс и закрытие
1. Инициализация
Пользователь (оператор) создаёт новое решение на закупку активов — лот / ордер в платформе.
2. Параметризация ордера
Предмет
Точное наименование скина (индивидуальный предмет или конкретная позиция каталога).
Количество
Объём закупки в рамках одного ордера — сколько единиц нужно набрать.
Диапазон цены
Границы Min / Max: система имеет право покупать только внутри коридора. Защита бюджета от резких скачков рынка.
Маркет и аккаунт
Целевая площадка (где искать ликвидность) и аккаунт-получатель, на инвентарь которого зачисляются предметы.
3. Автоматическое исполнение
Алгоритмический поиск — Морфеус в реальном времени сканирует выбранный маркет на офферы внутри заданного ценового диапазона.
Прозрачный прогресс — на одном экране: процент выкупа, средняя цена покупки, статусы транзакций.
Закрытие ордера — по достижении заданного количества предметов ордер автоматически закрывается, активы отображаются на балансе аккаунта.
Кратко для слайда
Создание ордера — новый лот в системе.
Условия — предмет, объём, ценовой коридор, маркет, целевой аккаунт.
Исполнение — алгоритм ищет лучшие офферы и закупает без ручного вмешательства.
Контроль — статус и прогресс сделки в реальном времени.
Пользователь · Steam
Один скин / один клик (или buy-order по цене).
Решения принимает человек у экрана.
Только Steam Market и кошелёк Steam.
Нет контроля средней цены по большой партии.
Trade Hold 7 дней — обязателен.
Морфеус · ордер
Объёмная закупка пакетом по параметрам.
Алгоритм исполняет в коридоре Min/Max.
Выбор маркета и торгового аккаунта.
Средняя цена, % выкупа и статусы на одном экране.
Тот же hold Valve учитывается дальше в жизни сделки.
«Ручной путь показывает правила рынка Valve. Морфеус не отменяет их — он масштабирует закупку: задаёте рамки, система набирает объём и не даёт цене уйти за пределы бюджета.»
готово13
Полный процесс жизни сделки
От ордера на покупку до финансового отчёта после продажи.
Фиксация — каждый предмет учитывается сервисами Морфеуса.
Hold 7 дней — ожидание снятия ограничения Valve.
Продажа — ордер с ценовым диапазоном, маркетом и сроком.
Отчёт — ROI и чистая прибыль по сделке.
ещё нет14
Как будут заводиться деньги на аккаунт
Схема пополнения — в совместной проработке.
Черновик
Опишем каналы ввода, лимиты и контрольные точки.
ещё нет15
Вывод денежных средств
Процедура вывода — ещё не зафиксирована в доке.
Черновик
Появятся маршруты вывода, сроки и комиссии.
готово16
Обоснование темпа интеграции
Темп 2 маркета в месяц (~2 недели на площадку) балансирует масштабирование и защиту капитала. Подключение — не просто вызов API, а сквозная интеграция из 6 этапов: от исследования механик до безопасного включения в авто-торговлю.
01
Парсинг и унификация данных
Что делаем
Настраиваем стабильный сбор цен, объёмов и глубины стакана; названия, float, паттерны и наклейки приводим к единому формату платформы.
Зачем инвестору
Площадки используют разные наименования и стандарты. Без жёсткой унификации алгоритм сверяет «яблоки с апельсинами» — ложные арбитражные связки и убыточные сделки.
02
Анализ данных и модель
Что делаем
Включаем маркет в математическую модель поиска спредов, расчёта комиссий, ликвидности и прогнозирования времени продажи.
Зачем инвестору
У каждой площадки своя специфика комиссий (ввод / вывод / сделка) и скорость пролива. Алгоритм должен считать чистую прибыль, а не грязную маржу.
03
Сквозная интеграция в микросервисы
Что делаем
Встраиваем маркет во все внутренние сервисы: исполнение ордеров, балансы, инвентарь, логирование и системы оповещений.
Зачем инвестору
Надёжность экосистемы. Ошибка в одном сервисе не должна «вешать» работу с новым маркетом.
04
Инфраструктура аккаунтов
Что делаем
Регистрируем, прогреваем и настраиваем сетку торговых аккаунтов (для сделок) и парсер-аккаунтов / прокси (для сбора данных).
Зачем инвестору
Защита от банов и блокировки ликвидности. Агрессивный или плохо настроенный доступ быстро даёт бан-пейджи, CAPTCHA или блокировку Steam Web API / торговых ботов.
05
Нюансы и API площадки
Что делаем
Настраиваем обработку специфических механик: таймауты трейдов, hold-периоды, особые методы авторизации и особенности API.
Зачем инвестору
У каждого маркета свои «подводные камни» (P2P vs боты, разное время подтверждения трейдов). Их игнор ведёт к зависанию средств на этапе передачи скина.
06
Тестирование и отладка
Что делаем
Стресс-тесты, проверка обработки ошибок (что делает система, если маркет «упал» mid-deal) и тестовые микро-сделки в sandbox и на живом балансе.
Зачем инвестору
Предотвращение прямых финансовых потерь на реальном капитале до полного включения маркета в авто-контур.
Что будет, если ускорить процесс
Риск при форсировании
Последствия
Impact на ROI
Ошибки парсинга / унификации
Покупка неликвида или переоценённых лотов из‑за сбоя сопоставления ID
Прямой убыток
Недостаточный прогрев аккаунтов
Массовые баны парсеров и торговых аккаунтов Steam / маркета
Заморозка оборотного капитала
Пропущенные edge cases
Зависание сделок, сбои при отмене ордеров во время скачков рынка
Потеря арбитражного окна
«Срок в 2 недели на один маркет — это не время разработки UI, это полный цикл от исследования механик площадки до её безопасного погружения в контур авто-торговли. Такой темп гарантирует, что каждый новый маркет приносит профит, а не создаёт новые точки отказа.»
в работе17
Интерфейс рабочего кабинета
Собрать скриншоты и оформить презентацию с описанием экранов.
Раздел готовится
После сборки визуального пакета здесь появится галерея кабинета.
ещё нет18
Видеозапись работы системы
Скринкаст возможен только при работающей системе в боевом/демо-контуре.
Пока недоступно
Запись экрана добавим после стабильного демо-контура исполнения сделок.
в работе19
Анализ избыточного спроса
Методика и примеры — в работе у аналитики.
Раздел готовится
Появится описание сигналов спроса и примеры разборов.
готово20
Сколько мы мониторим
Полная база ~24 000 уникальных скинов CS2. Всё покрывает суточный batch; в реальном времени — только предметы активных решений. Сбор и аналитика крутятся на прод-сервере Сати.
Уникальных скинов в базе~24 000
Batch по всей базераз в 24 ч
Стаканы по активныммин → сек
В CS2 порядка 24 000 уникальных предметов. Держать по каждому живой стакан с частотой в секунды — бессмысленно дорого и упирается в rate limits площадок. Поэтому мониторинг двухуровневый.
Мониторим широко · вся база
~24 000 скинов — полный каталог CS2.
Раз в сутки: история продаж со всех подключённых маркетов.
Медианы, волатильность, объёмы, ретро-тренды.
Нужно, чтобы видеть рынок целиком и отбирать кандидатов в стратегии.
Мониторим глубоко · активные решения
Только предметы, которые входят в живые стратегии / ордера.
Постоянный парсинг стакана: sell- и buy-ордера.
Частота от «раз в несколько минут» до «каждые несколько секунд» — по приоритету решения.
Именно здесь ловятся арбитражные окна и дешёвые лоты.
Почему не всё в real-time
Экономика запросов — у маркетов жёсткие лимиты; гонять всю базу каждую секунду = баны и CAPTCHA.
Нет сигнала — по неликвиду и предметам вне стратегий секундная глубина не даёт ROI, только шум и стоимость инфраструктуры.
Фокус капитала — ресурсы Сати и прокси тратятся на то, чем система реально торгует прямо сейчас.
Сати — прод-сервер аналитики: на нём крутится сбор, агрегация и подготовка данных для моделей и кабинета. Это «глаза» платформы по рынку скинов.
Маркеты
Сати · сбор
ETL / каталог
Алгоритмы
1. Фоновый сбор · Batch
История продаж — каждые 24 часа со всех поддерживаемых площадок: завершённые сделки по каждому из ~24 000 предметов.
Что считаем — медианные цены, волатильность, объёмы торгов, ретроспективные тренды для аналитики и отбора стратегий.
2. Глубина рынка · Order Books
Только активные решения — стаканы (лоты на продажу и ордера на покупку) парсятся постоянно, а не раз в сутки.
Гибкая частота — от минут до секунд в зависимости от приоритета конкретного решения/стратегии.
3. Как подключаемся к маркетам
HTTP / REST · Polling
Классический опрос API или страниц по расписанию с учётом rate limits площадки. Базовый режим, если потока нет.
WebSocket · Stream
Если маркет отдаёт WS — принимаем сделки и изменения стакана в реальном времени, без задержки регулярного опроса.
У каждой площадки свои названия, ID, комиссии и формат полей. Без унификации алгоритм сравнивает «яблоки с апельсинами».
Что парсим — цены, объёмы, глубину стакана, комиссии ввода/вывода/сделки, характеристики скина: Float, Pattern Index, наклейки / патчи.
Master Catalog — единый внутренний справочник предметов CS2. Все входящие лоты сопоставляются с ним, а не живут «в диалекте» маркета.
Нормализация — цены, объёмы и атрибуты приводятся к одной схеме; комиссии площадок закладываются в расчёт чистой маржи.
Data Lake / DWH — очищенные данные уходят в аналитический слой: одна «версия правды» для моделей, триггера и отчётов.
«Сати собирает рынок. ETL делает его сравнимым. Алгоритмы торгуют уже по единому каталогу, а не по сырому API каждой площадки.»
Микросервис «Триггер» — это «сторож у стакана»: он не ищет стратегию сам, а мгновенно сигналит исполняющему модулю, когда по подписанному предмету что-то изменилось.
Новое решение
Подписка в Триггере
Изменение стакана
Событие → исполнение
Подписка — при создании решения система регистрирует нужные предметы в «Триггере».
Наблюдение — сервис слушает WS или результаты частого опроса по этим предметам.
Событие — появился лот ниже рынка, сняли ордер, изменился объём → сразу генерируется оповещение.
Исполнение — сигнал уходит в торговый модуль за доли секунды: окно арбитража не «протухает», пока человек смотрит в график.
Простыми словами
Batch раз в сутки отвечает на вопрос «как выглядит весь рынок». Стаканы по активным решениям — «что можно купить/продать прямо сейчас». Триггер — «эй, цена только что стала интересной — действуй».
готово21
Природа рыночных данных
Цены предметов на маркетах — случайный временной ряд: покупают, когда захотели. Отсюда неравномерный шаг, пропуски, выбросы и участки, где прогноз по ряду ломается. Рабочая версия методики — 04.08.2026. Источник расчётов — база Sati-db на сервере Сати.
Аналитика не забирает страницу маркета «в момент решения». Она работает с уже собранными рядами в Sati-db. Как именно цена попала с сайта в базу (API или web-scraping), в этой методике не разбирается: здесь важно, что ряд в базе совпадает с рынком.
Что проверяли
Стоимость предмета на сайте маркета М1 (Steam) и те же точки в Sati-db.
Сверка графическая: чёрное поле — сайт, белое — база.
Погрешность не считают: соответствие либо есть, либо его нет.
Заключение
Парсинг по предмету проведён качественно.
Полное совпадение с учётом пересчёта курса валют.
Дальше модель можно строить на рядах Sati-db, а не на «сыром» сайте.
Зачем этот блок инвестору
Рекомендация на покупку опирается на историю в базе. Если база расходится с маркетом, модель считает чужой рынок. Сверка со Steam показывает, что для М1 этого разрыва нет.
Ряд стоимости — не котировка с ровным шагом. Сделка случается, когда кто-то купил. Для большинства предметов на большинстве маркетов это даёт четыре рабочих ограничения.
Нет ровного шага
Выборка по времени неравномерна. Исключение — активные предметы на М1 (Steam): там по популярным позициям возможна почасовка.
Пустые дни подряд
Покупок может не быть не только в отдельные дни, но и в идущих подряд. Особенно критичны самые последние дни ряда — как раз те, по которым судят о развороте.
Дыры надо заполнять
Внутри ряда — интерполяция. К моменту анализа — экстраполяция, если у предмета нет конечных точек.
Нельзя просто выкинуть
Предметы без хвоста ряда не отбрасывают: на части маркетов так выпадет слишком большая доля каталога.
«Случайные данные с временной зависимостью: когда захотели — тогда и купили. Модель обязана жить с пропусками, а не ждать идеальный ряд.»
Выбросы и дубли
Выбросы — часто много и с большой амплитудой относительно медианы дня, иногда на порядок.
Дубли во временной точке — и из парсинга, и из того, как маркет отдаёт сделки. Сейчас для текущего контура проблема снята, предобработка оставлена для других площадок.
Волатильность
Участки высокой волатильности — не выбросы и не сезонность. Их двигают новости и слухи: ажиотаж, страх потерять деньги, желание быстро заработать. Чем выше волатильность, тем шире колебания цен.
На длинную дистанцию (больше нескольких дней) в такой период работать не рекомендуется.
Волатильность раздувает полосу Боллинджера через стандартное отклонение от скользящего среднего — и вместе с ней ширину рекомендованных поддиапазонов купли-продажи.
Bull Trap · бычья ловушка
Почему 7 дней здесь опасны
Временный рост на несколько дней — как правило, не дольше запрета торговли после покупки — и затем разворот вниз. Это не выброс и не сезон. Восходящий кусок убеждает алгоритм, что тренд сменился на бычий: в таблицу попадает «хорошая прибыль», а через 7 дней сделка в убытке.
Форс-мажор правил площадки
Маркет может изменить правила так, что текущие ряды и сам формат выдачи данных перестают быть продолжением прошлого. Пример: 23 октября 2025 стоимость предмета на Steam выросла в 12 раз после изменения правил площадки.
Что с этим делает модель
Такой день — полный форс-мажор для любого прогноза по временному ряду. В методике заложено дальше отслеживать такие события AI-агентами с совещательным голосом, чтобы решение принималось быстрее, чем это успеет сделать только расчёт ряда.
Первичная обработка — снятие выбросов до того, как ряд попадает в прогноз. Фильтр считается отдельно по каждому дню.
Сырой ряд — почасовая стоимость из Sati-db, вместе с выбросами.
День — по почасовке за этот день считают скользящее среднее и стандартное отклонение.
Отсечение — выбрасывают точки, которые лежат дальше чем на два стандартных отклонения вверх или вниз от скользящего среднего.
День как одна точка — отфильтрованную почасовку сжимают до дневного значения, ориентир — медиана дня.
Сырая почасовкаПосле фильтраМедиана дня
«В прогноз идёт не каждый тик покупки, а очищенная дневная медиана. Иначе один аномальный лот двигает и тренд, и полосу Боллинджера.»
готово22
Двухэтапный прогноз купли и продажи
Направление тренда за 7 дней после покупки с большой вероятностью успевает смениться. Поэтому поддиапазон продажи считают в два этапа: сразу — на следующий день и на 7-й, затем — коррекция уже купленного предмета на 6-й день. Второй этап в общую стратегию ещё не включён.
Этап 1 · покупкадень +1
Этап 1 · продажадень +7
Этап 2 · коррекциядень +6
TPP (Trade Protection Period) — официальный срок Steam, когда купленный предмет нельзя продать. В обиходе это 7-дневный трейдбан, или холд. Модель строится вокруг этого окна, а не вокруг «удобной» даты.
Ряды всех предметов
Этап 1 · пара маркетов
Таблица рекомендаций
Этап 2 · уже купленное
Этап 1 · в работе
Покупка завтра, продажа через 7 дней
Берут ряды стоимости и вспомогательные параметры всех сканируемых предметов в паре маркетов: М1М2, М2М1 и другие комбинации.
На выходе — поддиапазон покупки на 1-й день прогноза и поддиапазон продажи на 7-й день. Предметы ранжируют по максимальной маржинальности в процентах и отдают в отдел решений «Таблицей рекомендаций».
Этап 2 · ещё не включён
Пересчёт продажи на 6-й день
Через 6 дней после покупки ряд пересчитывают только по уже купленным предметам, добавляя точки внутри TPP.
Новый поддиапазон продажи считают на 7-й день по каждому целевому маркету и снова ранжируют по марже. Для конкретного предмета берут площадку с максимальной маржинальностью. Так ловят смену тренда за дни холда и при необходимости меняют маркет продажи.
Что уже считается, а что ещё нет
Этап 1 формирует таблицу, по которой принимают решение о покупке. Этап 2 — коррекция продажи и площадки после холда — в общую стратегию пока не введён. Без него рекомендованный диапазон продажи чаще оказывается чуть заниженным: предмет проще продать, маржа скромнее, чем могла бы быть после пересчёта.
Поддиапазоны покупки и продажи считают и статистикой, и машинным обучением. Горизонт прогноза медианы — не дальше 11 дней от покупки. Полоса Боллинджера здесь — диапазон, в который при двух стандартных отклонениях от скользящего среднего попадает около 95% значений стоимости.
Экспресс-фильтр — сразу отбрасывают предметы с устойчивым нисходящим трендом. Это экономия машинного времени, а не оценка «плохого» скина.
Стационарность — отдельно отмечают предметы, у которых нет компоненты маржи от роста тренда.
Скользящее среднее за рассматриваемый период и стандартное отклонение от него.
Прогноз медианы стоимости на ближайшие дни.
Полоса Боллинджера — границы и ширина на тот же горизонт.
Поддиапазоны внутри полосы — сколько их и какой ширины. Именно они становятся Min…Max в таблице рекомендаций.
На одном участке стратегии два алгоритма считают дневные медианы параллельно: оба видят тренд и сезонность, но по-разному взвешивают последние дни. Совпадение повышает уверенность, расхождение — повод не верить одному только «гладкому» тренду.
1-й · основной
Машинное обучение на рассматриваемом диапазоне цен.
До этого — обучение и тест на ряде в классической пропорции train/test, с кросс-валидацией.
Уверенно берёт тренд и сезонность.
Стабильнее по тренду: последние точки меньше дёргают прогноз.
Его числа идут в таблицу как основные поддиапазоны для решения.
2-й · дополнительный
Статистическая обработка того же ряда.
Экспоненциальное сглаживание: чем свежее покупка, тем выше её вес.
Быстрее реагирует на смену направления тренда.
Менее стабилен: последние дни могут оказаться шумом, волатильностью или сезоном — алгоритм всё равно даёт им больший вес.
В таблицу попадает как категория-подсказка, не как основной коридор цены. Числа используют для внутренних сравнений и графической перепроверки.
«Первый алгоритм говорит, в каком коридоре работать. Второй — в какую сторону коридор может уехать, если последние дни считать всерьёз, а не случайным шумом.»
График предмета собирают в два масштаба. Сначала — история до алгоритмов: сиреневая кривая — сырая почасовка, синяя — дневные медианы уже отфильтрованного ряда. Затем — окно анализа с прогнозом (в разборе — до 22.05.2025 и 9 дней вперёд): выбросы сняты, справа добавлен жёлтый период прогноза.
Синяя ломаная
Исходные медианные значения стоимости за день.
Чёрная → жёлтая середина
Скользящая средняя. В периоде прогноза она становится средней линией полосы Боллинджера.
Красная с точками
Нелинейный add-тренд на рассматриваемом периоде.
Красная с кружками
Линейная регрессия всего диапазона, с заходом в прогноз.
Красная с треугольниками
Та же регрессия, но с увеличенным весом последней недели покупок.
Голубая с кружками
Прогноз дневных медиан 2-го алгоритма: по тренду, с сезонными колебаниями, внутри полосы.
Сиреневая с треугольниками
Прогноз дневных медиан 1-го алгоритма. По ним ставят поддиапазон купли или продажи.
Жёлтые границы
Верх и низ полосы Боллинджера в будущем: сплошная — верх, пунктир — низ.
Зелёные отрезки
Рекомендованные поддиапазоны на 1-й, 4-й и 7-й дни прогноза. На рисунке методики они увеличены вдвое относительно чисел в таблице — только для чтения глазом.
Как выглядит согласие алгоритмов
В показанном разборе голубая ломаная (2-й алгоритм) идёт чуть выше сиреневой (1-й), но остаётся внутри полосы Боллинджера, которую задаёт первый. Тренд и сезонность совпали. Подсказка в таблице: если купить по коридору 1-го дня, прибыль на 7-й день может оказаться выше рассчитанной маржи — но без коррекции на 6-й день эту разницу не забирают.
готово23
Таблица рекомендаций
Итог этапа 1 — одна таблица на отдел решений. Строка — предмет в конкретной паре маркетов. Сортировка — по верхней границе прибыли в процентах. Второй алгоритм не переписывает коридор цены: он добавляет цветную подсказку, стоит ли ждать маржу первого.
Метки маркетов в паре — не фиксированные площадки навсегда. М2М1 значит: покупаем на М2, продаём на М1. В контрольном тесте М2 — CSGOTM, М1 — Steam.
Предмет
Название, общее для всех маркетов.
Комбинация
Какая площадка покупает и какая продаёт. Например, М2М1.
Индекс
Идентификатор предмета на каждом конкретном маркете.
Покупка Min…Max
Рекомендованный диапазон цены покупки на М2 на следующий день после анализа.
Продажа Min…Max
Рекомендованный диапазон продажи на М1 через заданное число дней, в базовом контуре — на 7-й.
Комиссия
Диапазон комиссионных сборов на маркете продажи в день продажи.
Прибыль, RUB
Диапазон прибыли трейдера в рублях.
Прибыль, %
Диапазон Min…Max. По максимальной границе в процентах ранжируется вся таблица.
Валюта
Расчётная валюта строки.
Даты
Календарный день покупки и календарный день продажи.
Коридора цены недостаточно, чтобы решить, брать ли предмет. В ту же строку добавляют объём и мнение второго алгоритма.
Сколько продаётся
Общее число проданных единиц за период и среднее / медиана в день.
Сколько денег прошло
Общая сумма затрат на предмет за период и среднее / медиана в день.
Подсказка 2-го алгоритма
Категория: если работать по коридорам 1-го алгоритма, второй видит шанс большей прибыли, совпадение или риск недобрать и уйти в минус.
Почему параметров всё больше
Каждый новый признак полезен для решения и плохо помещается в ручной просмотр. Таблица уже шире, чем удобно читать глазами по каждой строке.
Подсказка второго алгоритма сравнивает его медиану в день продажи с коридором и полосой Боллинджера первого. Цвет — для человека, столбец P&L_N — то же самое числом для автоматизации.
HighProfit+2
Медиана 2-го алгоритма в день продажи выше прогноза 1-го и лежит выше его полосы Боллинджера. Шанс прибыли больше рассчитанной.
Profit+1
Выше прогноза 1-го, но всё ещё внутри его полосы. Больше маржи возможно, выход за модель первого не требуется.
NetProfit0
Медиана 2-го попала в рекомендованный диапазон продажи 1-го. Предсказания совпали — «чистая» согласованная прибыль.
Loss−1
Ниже прогноза 1-го, но внутри полосы. Это не приговор к убытку: предупреждение, что по коридору первого можно получить меньше, ноль или минус.
HighLoss−2
Существенно ниже прогноза 1-го и под его полосой Боллинджера. Если идти по трендовому коридору первого, есть вероятность убытка.
Руками свести растущий набор дополнительных полей уже не получается. В методике два следующих слоя — оба пока как путь, не как включённый контур.
Повторяемый контур
Нечёткая логика
На последнем шаге — аппарат Fuzzy Logic: таблица правил, которую эксперты задают по группам параметров. В одной группе от 2 до 4 признаков — столько ещё можно удержать при составлении правила.
На выходе переменная «целесообразность сделки» по предмету. Её пишут отдельным столбцом и по ней уже ранжируют таблицу. Два представления сразу: лингвистическое («как звучит целесообразность») и число [0, 1] для точной сортировки и автоматизации. Одинаковые входы дают один и тот же выход.
Совещательный контур
Локальный AI-агент
Агент, обученный локально на сопоставлениях и пожеланиях команды. Ошибок ожидается немного, советы полезны.
Повторяемости нет: те же входные данные не обязаны давать тот же текст совета. Поэтому агент не заменяет столбец целесообразности, а стоит рядом — так же, как второй алгоритм не заменяет коридор первого.
готово24
Проверка модели и рост маржинальности
Совместную работу двух алгоритмов сверили с уже известными медианами: прогноз на первую неделю декабря 2025 против того, что рынок показал потом. Отдельный резерв маржи — не покупать «завтра» и не продавать в ту же фазу недели, что и покупка.
День покупки · выборка186
День продажи · выборка132
Потолок маржи в тестедо 30%
Сравнивали предсказанные дневные медианы с теми, которые потом реально получились на маркетах. Интервал теста специально спокойный: после октябрьского скачка правил и до предновогодних распродаж.
История для расчёта
Ноябрь 2025, с 01.11 по 30.11.
Горизонт прогноза
Первые 7 дней декабря 2025, с 01.12 по 07.12.
Пара маркетов
М2М1: покупка на CSGOTM, продажа на Steam. В этой паре на порядок больше предметов с допустимой маржинальностью.
Порог маржи
Только предметы, у которых диапазон маржинальности по коридорам 1-го алгоритма доходит до 30% с учётом комиссий М1.
Фильтр 2-го алгоритма
Оставляли HighProfit, Profit и NetProfit. Loss и HighLoss отбрасывали, даже если первый алгоритм показывал достаточную маржу.
Объём выборки
186 предметов на 1-й день прогноза и 132 — на 7-й.
На гистограмме дня покупки смотрели, куда попала реальная дневная медиана относительно рекомендованного диапазона покупки из таблицы.
Серый — медиана внутри коридораЗелёный — факт выше коридораКрасный — факт ниже, купить можно было дешевле
Заключение по дню покупки
Распределение не противоречит нормальному закону. Для такой выборки гистограмма достаточно симметрична. Смещения от центра небольшие — с учётом того, какие это данные. Случаев «купили бы заметно дешевле рекомендованного» мало.
Та же проверка на 7-й день — день продажи. Цвета те же: попадание в коридор, факт выше, факт ниже.
Форма снова визуально не противоречит нормальному распределению.
Есть асимметрия в сторону более высоких реальных медиан, чем было в предсказанном диапазоне продажи.
Часть предметов можно было продать дороже. Коррекции диапазона на 6-й день (этап 2) в этом тесте не было — она как раз сдвинула бы коридор продажи вверх по тем предметам, где ряд за дни TPP это позволяет.
«Без коррекции на 6-й день рекомендованный диапазон продажи часто чуть занижен. Зато предмет с большей гарантией находит покупателя — пусть и с меньшей маржой, чем после пересчёта.»
Эффект стробоскопичности
Если убрать две уже понятные компоненты маржи — движение по восходящему тренду и разницу цен между двумя маркетами — остаётся недельная сезонность. Пример: по понедельникам предмет дороже, по четвергам дешевле. Покупка и продажа ровно через 7 дней холда попадают в одну и ту же фазу недели. Эта компонента маржи выпадает. Тот же эффект режет маржу и на восходящем тренде: желание быстрее провернуть деньги уменьшает результат.
Холд длиннее 7 дней
Например, 10 дней — покупка и продажа в разных фазах.
Ненадёжно само по себе.
Имеет смысл, только если покупка всегда приходится на фиксированный дешёвый день недели или соседний с ним.
Min-TPP-Max
После прогноза ищут день ближайшего минимума стоимости.
Продажа — в день ближайшего максимума, но уже после TPP.
Отказ от схемы «купили на следующий день после анализа и продали сразу, как снялся холд», даже если у такой пары дат маржа формально достаточная.
Где Min-TPP-Max даёт деньги
Стационарные предметы — их много, выбрасывать не стоит, но маржи от тренда у них нет.
Слабый восходящий тренд — маржа от движения есть, но она чуть ниже допустимой. Такие ряды как раз стабильнее и реже попадают в бычью ловушку.
Сделка на одном маркете (М1М1, М2М2) — нет компоненты «дешевле здесь, дороже там». Если нет и тренда, Min-TPP-Max остаётся единственной маржой.
Восходящий тренд на любой паре — стратегия добавляет ещё одну компоненту сверху, а не заменяет спред площадок.
Пример на одном маркете
Стационарный предмет, сделка на одной площадке — самый немаржинальный случай. Ближайший минимум к дню анализа — 13.07.2023 (четверг), ближайший максимум после TPP — 24.07.2023 (понедельник). Между куплей и продажей 11 дней: $1,55 − $1,31 = $0,24. На средней цене периода $1,42 это 17% — заметно при объёмах в несколько тысяч единиц. Та же схема «любой следующий день и продажа сразу после холда» не покажет маржу: покупка и продажа остаются в одной фазе.
ещё нет25
Почему этот бизнес интересен
Свод мнений команды и инвестиционный тезис — в подготовке.
Черновик
Раздел заполнится после сборки тезисов от команды.
ещё нет26
Стратегия инвестиций
Описание стратегий (хантер и др.) — ещё не оформлено.
Черновик
Здесь появятся профили стратегий, горизонты и риск-параметры.
ещё нет27
Критерии безопасности объёма на аккаунте
Группы аккаунтов в Тринити: до $1 · $1–30 · от $30 · инвест-аккаунты. Детальный список критериев — в работе.
Черновик
Зафиксируем лимиты и правила ротации по группам.
ещё нет28
Замена аккаунта для избежания блокировок
Жизненный цикл аккаунта и правила ротации — ещё не описаны.
Черновик
Опишем триггеры замены и процедуру миграции инвентаря.
ещё нет29
Живой диалог · сценарий 4-го месяца
Варианты предложений инвестору, если прибыли нет, но и убытка нет. Критерии и пути выхода — в работе.
Черновик
Согласуем критерии «жёсткого сценария» и коммуникационный плейбук.
готово30
Сервера для запуска
5 мощных машин: 56–84 ядра, 128–256 ГБ RAM, SSD/NVMe 1–2 ТБ в RAID. Запас на первые ~2 месяца при ежемесячной докупке сервера.
01StagingОбновления и гипотезы
02Prod · СатиАналитические данные
03Prod · CoreОсновной функционал
04InfraРепозитории, мониторинг, логи, прокси
05BackupsЕжедневные бэкапы
Конфиг
Спека
Цена
A
2× Xeon 6254 Gold, 192 GB
250к / 300к с НДС
B
2× Xeon E5-2699v4, 128 GB
125к / 152к с НДС
Диски
SSD 0.5–1 ТБ · NVMe 1–2 ТБ
22–32к
Итого готовый
в зависимости от комплектации
~216к или ~364к
ещё нет31
Кабинет для инвестора
Состав экранов и метрик — на обсуждении.
Черновик
Зафиксируем, что именно увидит инвестор в личном кабинете.
ещё нет32
Показатель баланса активов в моменте
Описание метрики — ещё не заполнено.
Черновик
Появится методика расчёта и частота обновления.
ещё нет33
График изменения капитализации
Визуализация динамики капитала — в планах.
Черновик
Добавим интерактивный график после фиксации методики.