Налаштування торгового бота: де ламається інфраструктура
Торговий бот на сервері — це процес із відкритими позиціями в реальному часі: незакрита угода живе рівно до наступного мережевого розриву.
Обрив зв'язку з біржею приходить у найневдаліший момент — на різкому русі, коли заявка вже пішла, а підтвердження не повернулося, і бот не знає, чи існує ордер.
Друга точка відмови — перезапуск процесу. Планове оновлення, помилка конфігурації, вичерпання пам'яті: якщо стан позицій живе лише в оперативній пам'яті, втрата ордера при збої майже неминуча.
Після старту бот бачить залишок на рахунку інакше, ніж біржа, і перші хвилини торгує за неправильною картиною.
Третя — ліміти частоти запитів. На зростанні волатильності потік запитів зростає, біржа відповідає відмовами, частина заявок відхиляється. Простій бота вимірюється не часом падіння, а часом роботи наосліп, коли бот вважає позицію відкритою, а її вже закрив стоп.
Четверта — відсутність резервного вузла й логування. Один сервер, немає сліду про відмови — і розбір інциденту перетворюється на здогади. Налаштування торгового бота починається з того, що кожна з цих точок закривається до першого запуску: розбираємо, як це влаштовано.
Вимірюваний ефект налаштування: відгук, простій, відновлення
Час реакції на ринкову подію змінюється першим. На локальній машині тік оброблявся із затримкою в кілька секунд: заважав нестабільний канал, фонові процеси, черга заявок на одному ядрі.
У хмарі, у зоні AWS, відгук укладається в частки секунди — у новинні імпульси, коли ціна йде на 2–3% за секунди, бот встигає виставити й зняти заявку без прослизання.
Простій торгового бота вимірюється окремо. Падіння домашнього провайдера або відключення живлення давали 6–8 годин без торгівлі на місяць — як правило, у найволатильніші дні.
Автоматичний перезапуск процесу за правилом «немає ознак життя N циклів — піднімаємо знову» скорочує незапланований простій до 10–15 хвилин на місяць.
Час відновлення задає не швидкість перезапуску, а цілісність стану.
Знімки диска за розкладом і журнал ордерів дозволяють зібрати позиції заново та звірити їх із біржею: 30–40 хвилин ручної звірки з ризиком задвоїти ордер перетворюються на 3–5 хвилин автоматичного прогону зі звітом про розбіжності.
Закривається й клас відмов, який раніше просто не відстежувався: розсинхрон стану з біржею після часткового виконання, завислий без перезапуску процес, єдина точка у вигляді однієї машини й одного каналу.
Частка втрачених із технічних причин ордерів у спостережуваних періодах прямує до нуля — збій або не дає простою, або видно в моменті.
Режими розміщення: сервер, контейнер, кластер
Вибір майданчика визначається трьома речами: скільки стратегій крутиться одночасно, наскільки критична затримка між сигналом і ордером та що відбувається при падінні вузла. Тому розміщення торгового бота — це не «де дешевше», а який клас відмов ви готові прийняти.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Орендований сервер (віртуальна машина) | Одна-дві стратегії, ручне керування, швидке введення в експлуатацію | Автоперезапуск і резервний вузол налаштовуються вручну, простій на час оновлення ядра |
| Виділений хост | Чутливість до затримки виконання, висока частота запитів до біржі | Довге введення в експлуатацію, надлишкова потужність під невелику кількість стратегій |
| Контейнерний майданчик | Кілька стратегій із різними залежностями, часті релізи | Потрібні ліміти за пам'яттю та зовнішнє сховище для стану й ключів |
| Керований кластер | Відмовостійкий кластер, регламент доступності, кілька вузлів | Складніше налагодження, потрібні маніфести, політики й спостережуваність |
| Локальна машина | Налагодження логіки, історичні прогони, тестові сценарії | Залежить від домашнього каналу й живлення, для реальних ордерів непридатна |
Перехід між варіантами не вимагає переписувати стратегію: логіка сигналів, ризик-контроль і робота з біржовим програмним інтерфейсом виносяться в окремий шар, а розміщення стає змінним параметром.
На контейнерному майданчику це дає швидкий відкат до попереднього образу, у кластері — автоматичний перезапуск пода на іншому вузлі та резервний вузол без ручного втручання.
Для оренди сервера під бота ми окремо прописуємо health-check, автопідйом процесу й винесення стану на зовнішній диск, щоб падіння вузла не означало втрату позицій.
Порядок робіт: аудит, схема, розгортання, перевірка
Розгортання торгового бота — це не копіювання файлів на сервер, а послідовність кроків із перевіркою на кожному: логіка працює з реальними заявками, і помилка на цьому рівні обходиться дорожче, ніж час, витрачений на підготовку. Порядок нижче однаковий і для нового бота, і для перенесення вже працюючого.
- Аудит схеми бота. Розбираємо, звідки приходять ринкові дані, як формуються й надсилаються заявки, де зберігаються ключі доступу та стан позицій. Результат — карта точок відмови: обрив зв'язку з біржею, розсинхронізація часу, повторне надсилання заявки після перезапуску.
- План розгортання. Вибираємо майданчик під навантаження й вимоги до затримки, визначаємо схему ізоляції процесів, розподіл прав, порядок роботи із секретами та резервне копіювання стану.
- Налаштування середовища. Ключі доступу випускаємо з мінімально потрібними правами й без виведення коштів, виносимо параметри у змінні середовища, синхронізуємо час, задаємо ліміти ресурсів, щоб бот не витісняв сусідні сервіси.
- Тестовий контур. Прогоняємо стратегію на історичних даних і на тестовому контурі біржі, потім — на мінімальних обсягах. Окремо перевіряємо сценарії збою: втрата зв'язку, відхилена заявка, часткове виконання.
- Контроль стану й захист. Налаштовуємо журнали й метрики, оповіщення про розбіжність позиції з біржею та аварійну зупинку за заданими умовами — вона спрацьовує без участі людини.
- Передача в експлуатацію. Віддаємо документацію щодо середовища, регламент оновлень і перезапуску, схему доступу для вашої команди та порядок відкату на попередню робочу конфігурацію.
Комплект передачі: конфігурації, схеми, регламенти
Комплект передачі збираємо так, щоб ваша команда могла підняти й супроводжувати бота без нашої участі. Усе, що входило в налаштування торгового бота на хмарних майданчиках, лягає в репозиторій і базу знань, а не в листування й не в голову окремого інженера. Нижче — що саме залишається у вас на руках.
- Файли конфігурації — параметри запуску, торгові пари, ліміти на позицію й добовий обіг, адреси біржових інтерфейсів; версіонуються, відкат до попереднього набору займає хвилини.
- Схема інфраструктури — задіяні вузли, зв'язки між ними, точки відмови, маршрути метрик і логів, порядок переходу на резервний вузол.
- Права доступу до ключів — матриця ролей, роздільні ключі на читання й на торгівлю, вимкнене право виведення коштів, порядок ротації та місце зберігання секретів.
- Регламент чергування — хто й у які години відповідає на оповіщення, граничний час реакції, порядок екстреної зупинки бота.
- Документація на бота — логіка, підтримувані режими, перевірки перед стартом, розшифрування типових помилок за записами в логах.
- Інструкції із запуску та відновлення — розгортання з нуля, підйом після збою вузла, перенесення на інший хмарний майданчик.
- Чек-лист приймання — сценарії, за якими ви перевіряєте працездатність своїми руками.
Комплект вважаємо переданим, коли ваш інженер піднімає бота за інструкцією з нуля й відновлює роботу після навмисно погашеного вузла — без звернення до нас.
Кейс: бот перестав втрачати ордери при збоях
Що було
Бот торгував з однієї віртуальної машини, а чергу ордерів тримав у пам'яті процесу: знімок на диск ішов раз на кілька хвилин.
Перезапуск або переїзд машини на інший фізичний хост стирав усе, що не встигло зберегтися, — за місяць набиралося 12–15 збоїв, 6–8 із них із втратою ордерів.
Відновлення йшло вручну: звірка позицій із біржею за журналами, до 40 хвилин простою та частина угод за ціною, гіршою за заплановану.
Що змінили у схемі
Перевели бота на дві ноди Hetzner у різних зонах доступності: стан черги пишеться в журнал синхронно, до підтвердження від біржі, а на кожен ордер ставиться унікальний ключ — повтор при обриві зв'язку не створює дубль.
Перемикання на резерв автоматичне, за перевіркою доступності, близько десяти секунд; зависле з'єднання з біржею перезапускає сторожовий процес, а повтори йдуть з обмеженням частоти, щоб не потрапити під блокування за лімітами запитів.
Що стало
Втрачених ордерів — нуль: кожен або підтверджений, або безпечно скасований за ключем. Кількість збоїв упала з 12–15 до 1–2 на місяць, простій скоротився з 40 хвилин до секунд, а розбіжність позицій із біржею, яку раніше вичищали вручну, більше не виникає.
Відмови перестали бути регулярними: налаштування бота тепер зводиться до планових оновлень, а не до нічних розборів інцидентів.
Технічні сумніви: зв'язок, ключі, ліміти, надійність
Інженерні сумніви щодо бота зводяться до чотирьох вузлів: де лежать ключі біржі, як не впертися в ліміти запитів, що відбувається при обриві каналу зв'язку з біржею та як дізнатися про збій раніше, ніж він стане збитком. Нижче — короткі відповіді, як це влаштовано в наших конфігураціях.
Як зберігаються ключі доступу до біржі?
Ключ створюється з правом торгівлі та без права виведення коштів — це відсікає найдорожчий клас втрат. Сам ключ лежить у сховищі секретів хмарного провайдера й підставляється в середовище процесу при старті; у файлах конфігурації, образах і системі контролю версій його немає.
Доступ до секрету виданий окремій ролі та читається за журналом, ротація — при зміні складу команди або будь-якій підозрі на витік.
Що буде, якщо бот упреться в ліміти запитів біржі?
Ліміти рахуються і на IP, і на ключ, тому бюджет запитів планується під стратегію заздалегідь: довідники кешуються, баланс і позиції запитуються пачками, потік ордерів іде через чергу з обмеженням частоти.
При відповіді біржі про обмеження бот іде в паузу з наростаючим інтервалом, а не повторює запит — інакше тимчасове блокування перетворюється на тривале.
Канал до біржі обірвався — бот наторгує зайвого?
Потік котирувань може завмерти мовчки, тому тримаємо heartbeat і реконект із відновленням підписки, а після перепідключення звіряємо локальний стан із біржовим.
Ордери позначаються власними ідентифікаторами, тож повторне надсилання не створює дублі, а перезапуск процесу продовжує роботу з останнього підтвердженого стану.
Як влаштований моніторинг бота та повідомлення?
Знімаємо затримку потоку, частку відмов, розбіжність між локальними й біржовими позиціями та час простою. Пороги налаштовуються під стратегію: алерт приходить у робочий месенджер, а окремий сторожовий сигнал ловить ситуацію, коли процес живий, але дані не оновлюються. Далі — безпечний режим: зупинка відкриття нових заявок або зняття активних, на ваш вибір.
Обговоримо задачу — повернемося з оцінкою та планом робіт
Налаштування торгового бота — робота, де помилка в конфігурації видна відразу за угодами: розрив зв'язку з біржею вночі, втрачений стоп або дублюючий ордер коштують дорожче за саму інфраструктуру.
Щоб повернутися з оцінкою робіт і планом впровадження, а не загальними словами, нам потрібно побачити вашу схему цілком.
Надішліть щодо задачі:
- Опис стратегії: логіка входу й виходу, робочі інтервали, набір інструментів, ліміти за позицією та ризиком на угоду.
- Поточну схему запуску: де бот працює зараз, які є скрипти й файли налаштувань, що ви робите руками при перезапуску.
- Перелік майданчиків і типів рахунків: спотові, строкові, тестові контури бірж, а також як зберігаються ключі доступу.
- Вимоги до відмовостійкості: допустимий простій, чи потрібна гаряча заміна вузла, поведінка бота при обриві зв'язку з майданчиком.
- Режим чергування: хто й як отримує повідомлення, чи потрібна цілодобова реакція або достатньо робочих годин.
- Обмеження щодо розміщення: вимоги до юрисдикції, резервного копіювання стану та порядку доступів для наших інженерів.
Із цим набором ми збираємо план впровадження: переносимо бота на хмарний контур, розводимо секрети й збірку за середовищами, налаштовуємо моніторинг і автоматичний перезапуск, прогоняємо на тестовому контурі й лише потім виконуємо запуск бота в роботу. Опишіть задачу — повернемося з оцінкою та планом робіт.
Бот на сервері чи на домашній машині: що вибрати?
Якщо бот торгує постійно, бот на домашній машині — найслабший елемент схеми. Локальний запуск бота зручний, поки ви налагоджуєте логіку, але щойно позиції відкриваються без вашої участі, будь-яка пауза перетворюється на незакриту угоду.
Тому домашня машина залишається інструментом розробки, а робочий контур живе на серверному майданчику.
Ризики домашнього розміщення складаються з побутових дрібниць. Перезавантаження після оновлення системи, сплячий режим, перебої живлення, обрив каналу в провайдера, динамічна адреса за роутером — кожна з цих подій зупиняє процес.
Диск без резерву й знімків стану означає, що після збою ви відновлюєте вручну і самого бота, і історію ордерів.
На виділеному майданчику ці точки відмови закриваються окремо: процес піднімається автоматично після перезапуску, знімок повертає конфігурацію й стан до останньої робочої точки, зовнішній моніторинг повідомляє про падіння, а доступ за ключами обмежує коло людей із правами на торгові операції.
Локальний запуск при цьому не стає зайвим. Прогін стратегії на історичних даних, перевірка логіки на тестовому контурі, підготовка конфігурації — це швидше робити на своїй машині, де є прямий доступ до логів.
Окремий випадок — вимоги до зберігання ключів: якщо політика забороняє виносити їх на чужий майданчик, частина контуру залишається локальною.
Різниця проявляється не у швидкості угод, а в передбачуваності: домашня машина дає зручність налагодження, серверний майданчик — безперервність.
Робоча схема зазвичай гібридна — логіка готується локально, торгова частина працює на майданчику, а перенесення конфігурації між ними описане й повторюване.
