Эксплуатация TradeJS на собственной инфраструктуре

TradeJS поставляется как набор npm-пакетов, а не как управляемый торговый сервис. Рабочая установка запускается в вашей среде и использует ваши Redis и PostgreSQL/Timescale.

Размещение

Соберите и запустите веб-приложение из своего проекта:

npx tradejs-app build
npx tradejs-app start

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

В официальной схеме TradeJS-Project хранит набор пакетов, tradejs.config.ts, безопасные настройки по умолчанию и образ приложения. TradeJS-Deploy хранит Compose, TLS, постоянные тома, SSH, ограничения ресурсов и секреты. Project передаёт Deploy тег версионированного образа и ревизию проекта; Deploy не пересобирает исходный код. Подробнее: Владение репозиториями и пакетами.

Изменение конфигурации и развёртывание

• Полные настройки развёртываний и стратегий храните в tradejs.config.ts.
• Точные версии npm храните в lock-файле и manifest образа. Не ведите ручную карту runtime-версий: строгая проверка Project вычисляет strategyRevision и deploymentCompositionId из разрешённой композиции.
• Фиксируйте один точный framework cohort: каноническую stable-версию либо одну проверенную версию x.y.z-beta.N, общую для всех framework-пакетов. Base, Strategy Kit и пакеты стратегий оставляйте stable-only. Каждое обновление проверяйте в изолированном окружении до сборки образа.
• Push в Project ничего не публикует и не развёртывает. Запускайте публикацию образа явно после проверок; тот же workflow должен завершить неизменяемую передачу в Deploy.
• После развёртывания выполните runtime-control verify.
• Redis хранит счета, паузу, журнал аудита, состояние процесса, сигналы, расчёты и сделки, но не является источником конфигурации стратегии.
• Веб-интерфейс показывает конфигурацию без редактирования и позволяет только ставить новые входы на паузу или возобновлять их.
• В официальной схеме сервер ежедневно формирует runtime evidence, а затем воспроизводит закрытое окно в изолированном read-only окружении на точном image digest из evidence. Не пересоздавайте этот feedback run из текущего локального checkout.

Ежедневные проверки

1. Проверьте состояние сервисов через docker compose ps или оркестратор.
2. Выполните npx @tradejs/cli doctor в рабочем окружении.
3. Проверьте доступность API и основных страниц веб-приложения.
4. Проверьте Redis/PostgreSQL, свободное место, память и нагрузку.
5. Убедитесь, что свечи обновляются, а торговый процесс отправляет признак жизни.
6. Просмотрите ошибки циклов, отклонения ордеров и состояние открытых позиций.

Диагностика инцидента

1. Определите проблемный слой: приложение, коннектор, Redis, PostgreSQL, ML или внешний AI-сервис.
2. Сохраните журналы до перезапуска, если ситуация не требует немедленной остановки.
3. Определите масштаб: все стратегии и инструменты либо конкретная комбинация.
4. При риске неконтролируемых входов поставьте новые входы на паузу. Управление уже открытыми позициями должно продолжаться.
5. Внесите минимальное изменение и проверьте результат.

Типичный порядок перезапуска

1. Хранилища данных: Timescale и Redis.
2. Сервис ML, если он используется.
3. Веб-приложение и торговые процессы.
4. Reverse proxy или ingress, если требуется.

Откат

• Храните предыдущие теги образов приложения и ML-сервиса.
• При необходимости поставьте новые входы на паузу и разверните предыдущий образ приложения.
• Откатывайте приложение и используемую ML-модель независимо, если это предусмотрено архитектурой.
• После отката запустите doctor, runtime-control verify и проверку основных пользовательских сценариев.