Development системы управления несколькими торговыми ботами
Когда ботов становится больше двух, ручное управление каждым — это операционный кошмар. Один бот на Binance, второй на OKX, третий арбитражный, четвёртый на DEX — каждый со своей конфигурацией, логами, статусом. Система управления несколькими ботами решает задачу централизованного контроля, агрегации данных и координации.
Architecture оркестратора
Система управления — это не просто дашборд. Это оркестратор, который:
- Запускает и останавливает боты по расписанию или условию
- Распределяет капитал между ботами
- Агрегирует P&L и риск-метрики в единый portfolio view
- Координирует действия ботов (не открывать противоположные позиции по одному инструменту)
Bot Orchestrator
├── Bot Registry — реестр всех ботов, их конфигурации
├── Capital Allocator — распределение капитала
├── Risk Aggregator — агрегация риска
├── Coordination Layer — предотвращение конфликтов
└── Monitoring Engine — health checks, alerting
↕ (Control API)
├── Bot Instance 1
├── Bot Instance 2
├── Bot Instance 3
└── Bot Instance N
Каждый бот — независимый процесс/контейнер со своим Control API. Оркестратор общается с ботами через этот API, не влезая в их внутренности.
Service discovery и health monitoring
При масштабировании до десятков ботов ручная регистрация неудобна. Используют service discovery: боты регистрируются в Consul или etcd при старте, публикуют свой endpoint и метаданные. Оркестратор автоматически обнаруживает новые боты.
Health check: оркестратор периодически проверяет /health каждого бота. Если бот не отвечает N секунд — статус UNHEALTHY, alert операторам, опциональный автоматический перезапуск через supervisor (systemd, Docker restart policy).
Распределение капитала
Самая сложная задача — умное распределение капитала между ботами с разными стратегиями и риск-профилями.
Статическое распределение: каждому боту выделяется фиксированная сумма. Простейший подход, требует ручной ребалансировки.
Dynamic allocation: капитал распределяется пропорционально производительности. Боты с лучшим risk-adjusted return (Sharpe ratio) получают больше. Ребалансировка по расписанию или при достижении threshold deviation.
Kelly Criterion: математически оптимальный размер ставки для каждой стратегии на основе исторического win rate и payoff ratio. Часто используют фракцию Kelly (half-Kelly, quarter-Kelly) для снижения волатильности.
| Стратегия | Win Rate | Avg Win/Loss | Kelly | Аллокация |
|---|---|---|---|---|
| Trend Following | 45% | 2.5x | 17.5% | 35% |
| Mean Reversion | 62% | 1.4x | 23.8% | 25% |
| Arbitrage | 78% | 1.1x | 12.2% | 20% |
| Market Making | 85% | 0.9x | 12.0% | 20% |
Предотвращение конфликтов
Если два бота открывают позиции по одному инструменту в разных направлениях — это самохеджирование с двойными комиссиями. Coordination layer предотвращает это.
Реализация: перед открытием позиции бот запрашивает у оркестратора position lock — эксклюзивное право на позицию по инструменту. Оркестратор проверяет, нет ли конфликтующих намерений, и выдаёт или отказывает в lock.
Альтернатива: агрегированный view позиций. Оркестратор знает net exposure по каждому инструменту и не позволяет ботам открывать позиции, которые приводят к net neutral при ненулевых transaction costs.
Агрегированный мониторинг
Portfolio-level метрики
Сумма P&L всех ботов — это не вся картина. Нужны:
Correlation analysis: если все боты лонгуют BTC коррелированными стратегиями — реальная диверсификация нулевая. Матрица корреляций доходностей помогает увидеть это.
Portfolio VaR: Value at Risk на уровне всего портфеля, с учётом корреляций. Сумма VaR отдельных ботов переоценивает риск при негативной корреляции.
Drawdown attribution: какой бот вносит наибольший вклад в текущую просадку? Это определяет приоритет в ручном вмешательстве.
Unified log aggregation
Логи десятков ботов нужно агрегировать в одном месте. Стандартный стек: Loki (хранение логов) + Prometheus (метрики) + Grafana (визуализация). Каждый бот пишет структурированные JSON-логи, Promtail собирает и отправляет в Loki.
Конфигурационный менеджмент
Когда ботов много, версионирование конфигураций критично. Изменение параметра должно быть:
- Версионировано (откат при проблемах)
- Аудитируемо (кто, когда, что изменил)
- Атомарно (либо применилось полностью, либо нет)
Хранение конфигураций в Git — прагматичный подход. Infrastructure as Code для торговых стратегий. Изменение параметров через pull request с code review.
Деплой и оперирование
Kubernetes: каждый бот — отдельный Pod. Orchestrator — Deployment с autoscaling. ConfigMaps для конфигураций, Secrets для API ключей. HPA (Horizontal Pod Autoscaler) для масштабирования при высокой нагрузке.
Rolling updates: обновление бота без остановки торговли. Новый Pod стартует, дожидается healthy state, старый останавливается. Требует graceful shutdown — бот должен корректно завершать текущий цикл перед остановкой.
Система управления несколькими ботами — это проект уровня сложности маленькой trading platform. Срок разработки production-ready решения — 3-5 месяцев.