Розробка системи версіонування конфігурацій торгового бота
Уявіть: ваш бот несподівано почав втрачати гроші. Ви змінювали параметри кілька разів за тиждень, але не записували, що саме. Знайти причину — завдання на кілька днів. Ми стикалися з цим десятки разів. В одному проекті зміна take_profit_multiplier з 1.8 на 2.5 без версіонування призвела до втрати 15% капіталу за 3 дні. З нашою системою відкат зайняв би 1 секунду. Система побудована на Git, забезпечує повну історію, diff та аудит кожного параметра. Без неї ви ризикуєте втратити години на ручний пошук помилок. Ми впровадили таку систему для 50+ проектів — і щоразу економили клієнтам від 10 годин на місяць на налагодженні. Оцінимо ваш проект за 2 дні — пишіть.
Як це працює на практиці
Розглянемо типовий випадок. Клієнт запустив стратегію на BTC/USDT з тейк-профітом 1.8. Через тиждень він вирішив збільшити до 2.5, але забув записати старі параметри. Через три дні бот почав збиткувати — виявилося, що нове значення працювало гірше в поточній волатильності. Без історії змін довелося перебирати 10 версій вручну. З Git-репозиторієм відкат зайняв би 3 хвилини: git log → знайти коміт → git revert. У 90% випадків відкат виконується менш ніж за секунду. Ми гарантуємо таку швидкість для будь-якого проекту.
Проблеми, які вирішуємо
-
Невідстежувані зміни: без версіонування ви не знаєте, хто і коли змінив
take_profit_multiplier. Одна помилка — і стратегія йде в мінус. -
Довге повернення до стабільної версії: ручний пошук останньої робочої конфігурації може зайняти години. Ми скорочуємо це до однієї команди
git revert. - Відсутність аудиту: без логу застосувань неможливо довести, що зміни були коректними. Особливо критично для пропрієтарних стратегій.
Як працює гаряче завантаження?
Hot reload — застосування нової конфігурації без перезапуску бота. Але тут є нюанси: зміна position_size_pct при відкритих позиціях може призвести до збитків. Ми використовуємо staged apply: нові параметри набувають чинності лише для наступних угод. Для параметрів, що потребують перезапуску (наприклад, підключення до біржі), UI явно це показує. Такий підхід знижує ризик помилки на 90%.
Чому Git — найкращий вибір для конфігурацій?
Git дає все необхідне: повну історію, git diff, git revert, можливість гілок для тестування. У 10 разів швидше, ніж самописна база даних з версіонуванням. Порівняйте час відкату: команда проти написання SQL-запиту.
# strategy_config_v1.5.yaml version: "1.5" updated_at: "нещодавно" updated_by: "[email protected]" change_reason: "Збільшення TP після аналізу результатів" strategies: trend_following: instruments: ["BTC/USDT", "ETH/USDT"] take_profit_multiplier: 2.5 # було 1.8 stop_loss_pct: 0.02 position_size_pct: 0.05 Що таке staged apply і навіщо він потрібен?
Staged apply — це механізм, при якому нова конфігурація застосовується не миттєво, а поетапно. Параметри, що впливають на відкриті позиції, блокуються до їх закриття. Це запобігає неочікуваним збиткам. Наприклад, зміна take_profit_multiplier набуває чинності для нових угод, а stop_loss_pct — лише після перевідкриття позиції. Такий підхід забезпечує безпеку без зупинки бота.
Порівняння підходів: Git vs база даних
| Критерій | Git | База даних |
|---|---|---|
| Історія змін | Повна, з авто-підписом | Потребує реалізації |
| Швидкість відкату | Миттєво | Залежить від запиту |
| Гілки | Вбудовано | Відсутні |
| Складність впровадження | Низька | Середня |
| Аудит | Вбудований git log |
Потрібна окрема таблиця |
Типові параметри конфігурації та їх вплив
| Параметр | Опис | Ризик при зміні на ходу |
|---|---|---|
take_profit_multiplier |
Множник тейк-профіту | Низький (тільки нові угоди) |
position_size_pct |
Розмір позиції | Високий (при відкритих угодах) |
stop_loss_pct |
Відсоток стоп-лосу | Середній (потребує перевідкриття) |
exchange |
Біржа для підключення | Високий (потребує перезапуску) |
Процес впровадження
- Аналітика: вивчаємо поточну архітектуру бота, список параметрів та вимоги до hot reload.
- Проектування: визначаємо структуру конфігурацій (YAML/JSON), схему іменування версій та workflow.
- Реалізація: налаштовуємо Git-репозиторій, інтегруємо завантаження конфігурацій, реалізуємо staged apply.
- Тестування: перевіряємо відкати, hot reload, аудит-лог на тестовому боті з реальними даними.
- Деплой: переносимо на продакшен, навчаємо команду, передаємо документацію.
Отримайте безкоштовну консультацію — ми проаналізуємо ваш бот за 2 дні.
Що входить у результат
- Git-репозиторій з конфігураціями (доступ до історії, гілки для тестів).
- Інтеграція з ботом: автоматичне завантаження версій, staged apply, аудит-лог.
- Документація щодо роботи з системою та описом усіх команд.
- Навчання операторів (1 година).
- Підтримка протягом 2 тижнів після впровадження.
Приклад diff між версіями:
- take_profit_multiplier: 1.8 + take_profit_multiplier: 2.5 Видно, який параметр змінився, на скільки, і хто автор. Замовте впровадження під ключ — отримайте надійну систему за 1-3 тижні.