Чому інтеграція Freqtrade впирається в інфраструктуру
Алгоритмічна торгівля ламається не на стратегії. Сигнал рахується миттєво, а підтвердити, що заявка реально стала в ордербук, пережити розрив зв’язку й не втратити позицію — це вже завдання інфраструктури.
Інтеграція Freqtrade починається рівно там, де закінчується перевірка стратегії на історії: на стику торгової логіки й реального рахунку.
Перше вузьке місце — обрив з’єднання з біржею. Поки канал живий, розрахунковий стан позицій і фактичний на рахунку збігаються. Варто зв’язку зникнути на кілька секунд, і надісланий ордер залишається висіти, а рушій вважає, що заявка не пішла.
На наступній ітерації логіка ухвалює рішення за неправильним балансом — і відкриває другу позицію там, де мала бути одна.
Друге — розбіжність позицій після ручних входів у угоду. Трейдер бачить можливість і заходить руками, а автоматика про цю угоду не знає. Її розрахунок ризику, стопів і середньої ціни стає неправильним, і будь-яке автоматичне закриття перетворюється на лотерею.
Третє — відсутність контролю над виконанням. Часткові виконання, зняті заявки, зміна лімітів на боці біржі зсувають фактичну позицію щодо розрахункової.
Тому підключення торгової системи до біржі — це насамперед звірка стану, обробка мережевих збоїв і розмежування ручних та автоматичних дій, а не запуск процесу.
Розбираємо, як це закривається.
Що дає пов’язана торгівля: ефект у вимірюваних величинах
Пов’язаний контур — це коли стратегія, виконання й контроль ризику працюють як одна система, а не як набір ручних операцій. Нижче — що саме змінюється у вимірюваних величинах і за якими метриками це приймається.
- Доля автоматичних рішень. Автоматика закриває весь шлях від сигналу до заявки й супроводу позиції; вручну залишаються лише зміна ризик-лімітів і виведення коштів.
- Швидкість реакції на ринкову подію. Сигнал перетворюється на заявку за частки секунди — там, де людина реагує хвилинами й зазвичай уже після руху ціни.
- Час відновлення після збою. Контур піднімається з відновленням стану відкритих позицій за хвилини, а не за години ручної звірки.
- Зниклий клас відмов. Пропущений сигнал через зайнятість, помилка в обсязі заявки, втрата зв’язку з біржею без оповіщення — ці збої перестають бути можливими як клас.
- Прозорість виконання. Журнал угод і відхилення фактичної ціни виконання від розрахункової видно в одному місці, а не збираються за вивантаженнями.
Щоб ефект автоматизації торгівлі був перевірним, на старті фіксуємо цільові значення за кожним рядком — інакше залишаються гасла. Контур збираємо на Freqtrade, обв’язку й правила ризику пишемо під ваш регламент.
Режими роботи: біржа напряму, проміжний шлюз, власний сервер
Режим підключення визначає не швидкість запуску, а поведінку системи під час розриву зв’язку. Торгова логіка може жити на тому самому хості, де лежать ключі біржі, на виділеному сервері поруч із біржею або за проміжним шаром, який приймає сигнали й передає їх на виконання.
Різниця видна в момент збою: де зберігається стан позиції, чи повториться ордер після реконекту і хто першим помітить розбіжність.
Інтеграція Freqtrade починається саме з вибору цієї схеми — від неї залежать і структура стратегії, і моніторинг. Нижче варіанти, між якими реально вибирають під час запуску алготоргівлі.
| Режим роботи | Коли підходить | Обмеження |
|---|---|---|
| Пряме підключення до біржі, локальний запуск стратегії | Одна стратегія, один ринок, швидкий старт і тестовий прогін без реальних ордерів | Ключі лежать поруч із ботом; у разі падіння хоста відкрита позиція залишається без керування; немає черги сигналів і повторного надсилання ордера |
| Проміжний шлюз сигналів | Кілька стратегій або бірж, потрібно розвести розрахунок і виконання | Додається затримка на передачу сигналу; потрібен контроль черги й захист від дублів під час перезапуску; відкат зачіпає два сервіси |
| Власний сервер виконання поруч із біржею | Постійний режим, ліміти за частотою запитів, вимога тримати позиції в ринку | Потрібні обслуговування, оновлення й чергування; резервування стану робиться окремо; вищі вимоги до захисту ключів |
Загальне обмеження в усіх режимів одне: торговий стан має відновлюватися після перезапуску без дублювання ордерів.
Тому в конфігурації фіксуємо, чим звіряється фактична позиція, як обмежується частота запитів до біржі і що вважаємо аварійним завершенням — бот або доводить позицію за правилами, або закриває її та зупиняється.
Етапи впровадження інтеграції Freqtrade: від аудиту до передачі
Етапи впровадження вибудовуємо так, щоб кожна сходинка спиралася на результат попередньої: спочатку фіксуємо стан торгової логіки й доступів, потім збираємо схему підключень і лише потім вважаємо стратегію готовою до реальних коштів.
- Аудит торгової логіки. Розбираємо правила входу й виходу, роботу зі стопами та розмір позиції, поведінку на різких рухах. На виході — перелік припущень, які не можна переносити в автоматичний режим без перевірки.
- Схема підключень. Фіксуємо джерела ринкових даних, спосіб доступу до біржі, місця зберігання конфігурацій і логів. Ключі видаємо з обмеженими правами, без можливості виведення коштів.
- Налаштування середовища. Розгортаємо бота в ізольованому контурі: окремий екземпляр, свої каталоги даних, збереження стану угод між перезапусками. Тестовий запуск не перетинається з бойовим.
- Перевірка на історичних даних. Прогоняємо стратегію на довгому відрізку котирувань з урахуванням комісій і прослизання, дивимося просадку й розподіл угод. Слабкі за співвідношенням прибутку до ризику повертаємо на доопрацювання.
- Перевірка на тестовому контурі. Переводимо в режим сухого запуску з живими котируваннями: спрацювання ордерів, ліміти біржі, поведінка під час обриву зв’язку й відновлення після збою.
- Передача в експлуатацію. Піднімаємо бойовий контур, поетапно збільшуємо обсяг позицій, налаштовуємо оповіщення про збої та регламент аварійної зупинки, передаємо документацію щодо конфігурації й відновлення.
Кожен етап закривається звітом: що перевірили, які обмеження знайшли, що залишилося на контролі. Повернутися на крок назад дешевше, ніж розбирати поведінку бота на живих угодах.
Конфігурації, ключі доступу й регламенти: що передаємо після здачі
За підсумками інтеграції Freqtrade передаємо не «працюючого бота», а комплект, за яким ваша команда запускає, змінює й обслуговує систему без нас. Нижче — що вирушає в репозиторій і внутрішню базу знань у день здачі.
- Файли конфігурації — окремі профілі для тестового й робочого контуру, ключі лише через змінні середовища, шаблон з описом кожного параметра.
- Розмежування прав доступу — ролі «спостерігач», «оператор стратегій», «адміністратор»; оператор не змінює ліміти ризику й розмір позиції.
- Ротація ключів — ключі бірж без права виведення коштів і з прив’язкою до адреси, графік планової заміни й сценарій відкликання в разі витоку.
- Документація щодо стратегій — для кожної: логіка входу й виходу, індикатори, на якому відрізку історії перевірялася, за яких умов вимикається.
- Регламент обслуговування — щоденні перевірки свіжості даних і статусу ордерів, щотижневі — повнота історії угод і резервні копії, порядок дій під час зупинки процесу.
- Схема взаємодії — компоненти, потоки даних, точки відмови й порядок ручного втручання.
- Журнал змін — що і коли правилось, щоб у разі розбору інциденту був відновлюваний весь ланцюжок рішень.
Завершуємо передачею доступів і контрольним прогоном на тестовому контурі: робочий контур ви запускаєте самі, а ми залишаємося на зв’язку за узгодженим регламентом.
Кейс: як ручну торгівлю перевели на автоматичні правила
До перенесення торгівлю вів один чоловік: 5–6 інструментів, сигнали рахувалися за індикаторами в терміналі, вхід і вихід — руками.
На тритижневому відрізку з 40+ сигналів третина залишилася без відпрацювання: частина припадала на ніч і вихідні, частина губилася, поки трейдер вів іншу угоду.
Середня затримка між сигналом і входом — хвилини, і правило вже не давало того співвідношення ризику й прибутку, під яке рахувалося.
Правила описали формально: умова входу й виходу, стоп, розмір позиції, ліміт одночасних угод. Їх перенесли в конфігурацію Freqtrade і прогнали на історії — так відсіялися правила, які в ручному режимі «працювали», а на довгому відрізку давали просадку.
Потім автоматику запустили паралельно з ручною торгівлею в режимі спостереження й розбирали розбіжності за журналом, поки рішення не збіглися.
Після перенесення частка відпрацьованих сигналів — 100% замість 65–70%, затримка входу — секунди замість хвилин, ручних дій за день — з 25–30 до 2. Змінився й клас помилок: входи поза правилами зникли, бо кожна угода пишеться в журнал разом із причиною.
Журнал дав побічний ефект: видно, яке правило тягне результат униз, тому вимикається одна умова, а не вся стратегія.
Метрики знімали до й після на одному відрізку і за однією методикою — число угод, частка відпрацьованих сигналів, затримка входу, максимальна просадка по кожній парі.
Що робити, якщо торгову систему вже розгорнуто на власному сервері?
Працююча система — це не лише код стратегії, а її стан: відкриті позиції, виставлені й невиконані ордери, історія угод, знімок балансу й параметри керування ризиком.
Тому перенесення починається не з копіювання файлів, а зі зняття узгодженого знімка цього стану прямо під час торгівлі.
Зупиняти бота для цього не потрібно. Ми фіксуємо знімок стану й конфігурації, розгортаємо Freqtrade поруч на цільовому сервері й запускаємо в режимі без виставлення реальних ордерів: система читає ті самі ринкові дані й генерує сигнали.
Звірка сигналів із поточним контуром за кілька торгових сесій показує, чи збігаються розрахунки індикаторів, таймфрейми й логіка входів.
Якщо розбіжностей немає, починається поетапне перемикання: нові угоди відкриває вже нова система, а позиції, набрані на старій, доводяться до закриття за попередніми правилами.
Розділення йде за торговими парами або за обсягом, інакше та сама позиція відкриється двічі — це головний ризик паралельного запуску.
Доступи переносимо окремо: ключі до біржі видаються з правом торгівлі, але без права виведення коштів, а попередній контур залишається в гарячому резерві.
Якщо перші угоди показують відхилення від очікуваної поведінки, повернення займає хвилини — історія, позиції й звітність зберігаються в обох системах.
Технічні сумніви: навантаження, доступи до біржі, обриви зв’язку
Сам Freqtrade — один процес, який веде десяток торгових пар: на сервері це майже непомітно, вузьке місце не в процесорі, а в лімітах біржового API.
Число запитів за хвилину на один ключ обмежує раніше, ніж ресурси машини, тому частоту опитування свічок і балансу задаємо окремо від частоти виставлення ордерів.
Доступи тримаємо поза репозиторієм: ключ лише з правом торгівлі, без виведення коштів і переказів, з прив’язкою до IP сервера.
Стан — відкриті позиції, стопи, історія угод — пишеться в локальну базу, тому після обриву зв’язку або перезапуску процес відновлює позицію з неї, а не відкриває дубль.
Що буде, якщо зв’язок із біржею обірветься на кілька хвилин?
Торговий цикл переходить в очікування й повторює підключення з наростаючою паузою. Щойно канал повернувся, стан звіряється з біржовим: які позиції реально відкриті, які ордери виконалися. Захисні стопи на цей час залишаються на боці біржі, тому позиція не залишається без нагляду.
Як переконатися, що стратегія працює, а не підігнана під історію?
Спочатку прогін на історичних даних за кілька ринкових циклів — з різкими падіннями, періодами низької ліквідності, комісією та прослизанням.
Потім торгівля в режимі спостереження без реальних ордерів: розбіжність між розрахунковими й фактичними сигналами показує різницю між моделлю та живою біржею. Реальний рахунок вмикаємо з мінімальним обсягом на угоду й звіряємо фактичне виконання з очікуваним.
Опишіть задачу — повернемося з оцінкою та планом робіт
Щоб обговорити задачу й повернутися з оцінкою строків і планом робіт з інтеграції Freqtrade, готове техзавдання не потрібне — достатньо описати задум і долучити те, що вже є.
Чим конкретніші вихідні дані для оцінки, тим менше припущень ми закладаємо в план, а отже, тим чесніша оцінка.
- Торгова логіка: правила входу й виходу, індикатори або події, за якими стратегія ухвалює рішення.
- Ринки та інструменти: біржі, спотові або ф’ючерсні пари, чи потрібен облік плеча й комісій.
- Режим роботи: лише розрахунок на історії, торгівля в тестовому режимі або виведення угод на реальні кошти.
- Доступи: тестові ключі біржі без права виведення коштів і доступ до репозиторію, якщо напрацювання вже є.
- Управління ризиками: ліміт на розмір позиції, стоп-лос, допустима просадка, поведінка під час обриву зв’язку з біржею.
- Інфраструктура та повідомлення: де запускається бот, чи потрібен моніторинг стану й оповіщення в месенджер.
Якщо частина даних поки не визначена — це не блокер: зафіксуємо припущення в плані й уточнимо їх до старту. На виході ви отримуєте розбивку робіт за етапами, оцінку строків і перелік перевірок, які підтвердять працездатність стратегії до виведення її на реальні кошти.
