Налаштування VPS для бота: де ламається середовище
Налаштування VPS для бота зазвичай починається однаково: код заливається на сервер і запускається вручну з термінала. Поки сесія SSH відкрита, усе працює — а варто закрити вікно або зникнути зв'язку, як обрив сесії надсилає процесу сигнал завершення. Падіння бота відбувається без помилки в логах: він просто перестає реагувати на події біржі.
Окремий клас відмов — перезавантаження сервера. Планові роботи провайдера, оновлення ядра, перезапуск хоста: бот не піднімається сам, бо його немає ні в автозавантаженні, ні під наглядом супервізора.
Типові збої: обрив сесії, перезавантаження, завислі процеси
Разом із процесом втрачається стан, що жив лише в пам'яті — таймери, незакриті позиції, кеш ордерів, — і відновлення перетворюється на ручний розбір за логами.
Завислі екземпляри накопичуються ще непомітніше: після чергового падіння бота піднімають заново вручну, старий процес залишається висіти, тримає з'єднання й порт, а новий не може зайняти той самий ресурс. Симптом завжди один — «бот не відповідає», а причин на цей момент уже три-чотири.
Закривається це перенесенням запуску в systemd-юніт: автозапуск під час завантаження машини, політика перезапуску при аварії, окремий лог на службу. Стан виноситься за межі пам'яті процесу, а осиротілі екземпляри гасяться за ідентифікатором служби, а не пошуком у списку завдань. Далі розбираємо, як це налаштовується крок за кроком.
Що дає кероване середовище: вимірюваний ефект
Кероване середовище відрізняється від запуску бота «в терміналі» не зручністю, а передбачуваною поведінкою при збої. Нижче — те, що рахується до й після, без формулювань «стало надійніше».
Автозапуск і самовідновлення
Юніт systemd з політикою Restart=always піднімає процес після падіння, перезавантаження VPS і обриву з'єднання з біржею; обмеження частоти перезапусків не дає боту піти в нескінченний цикл.
Час відновлення після збою процесу скорочується з хвилин ручної роботи до секунд — оператор дізнається про факт, а не про наслідки.
Практичний ефект: частка відмов, які закриває автозапуск, сягає 80–90% — залишаються помилки конфігурації та вичерпані ліміти API, їх розбирають вручну. Сторожовий таймер перевіряє не «чи живий процес», а чи відповідає бот на запити, і перезапускає завислий екземпляр.
Спостережуваність: логи й оповіщення
Моніторинг бота будується на структурованих логах з ротацією: історія угод і помилок не втрачається при рестарті й не займає диск повністю.
Метрики — затримка відповіді API, частка відхилених заявок, розмір черги — йдуть в оповіщення з порогами, тому про деградацію відомо до того, як вона перетвориться на втрати.
Підсумок: ручні втручання переходять із режиму «кілька разів на тиждень» у «раз на місяць і рідше», а шлях від збою до працюючого сервісу займає секунди замість десятків хвилин.
Варіанти розміщення бота: порівняння режимів
Схему розміщення вибирають не за потужністю машини, а за кількістю ролей у бота: торгове ядро, приймання ринкових даних, зберігання стану й оповіщення дають різний профіль навантаження. Нижче — чотири реальні схеми та їхні межі застосовності.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Загальний хостинг | Пробний запуск, один потік без зберігання стану | Немає постійного процесу, перезапуск за таймаутом |
| Один процес на виділеному сервері | Один торговий контур, стан локально | Падіння зупиняє все, оновлення — через простій |
| Окремі сервіси | Ядро й збір даних з різним навантаженням | Більше зв'язків і точок відмови |
| Ізольовані контейнери | Кілька ботів, різні середовища | Потрібні томи для стану й ліміти пам'яті |
Коли достатньо одного процесу
Один процес з локальною базою виправданий, поки бот обслуговує єдиний торговий контур, а перезапуск займає секунди. Вирішує не потужність сервера, а передбачуваність: короткий старт, відновлення стану з файлу, моніторинг зводиться до перевірки живості й розбору логів. Поки ці умови тримаються, розділення лише додасть зв'язків.
Коли потрібно розділяти ролі й дані
З другим контуром, важким збором ринкових даних або розсилкою оповіщень один процес починає заважати сам собі: збір виїдає ресурси, а перезапуск ядра рве підписки.
Тоді ролі виносять в окремі служби, стан — у зовнішнє сховище, а контейнери фіксують середовище, щоб оновлення однієї частини не зачіпало решту.
Налаштування VPS для бота: етапи інженерних робіт
Порядок робіт вибудувано так, щоб після передачі бот працював без ручного втручання: переживав перезавантаження сервера, обрив зв'язку з біржею й падіння окремого процесу. Починаємо з аудиту поточного запуску — інакше легко втратити стан позицій при першому ж рестарті.
Аудит і схема розміщення
- Аудит запуску: як бот стартує зараз, де лежать ключі доступу, куди пишуться логи, що станеться при перезавантаженні. Фіксуємо ризики — ручний старт, секрети у відкритому вигляді, відсутність лімітів.
- Схема розміщення: розкладаємо ролі — торгова логіка, обробники черг, база стану. Окремо вирішуємо, що зберігається на диску, а що в базі, щоб рестарт не призводив до повторних ордерів.
- Базовий захист: окремий користувач без прав адміністратора, вхід за ключами, закриті вхідні порти крім службового, автоматичні оновлення й fail2ban проти перебору.
Перевірка на відмовостійкість
- Автозапуск: юніт systemd з політикою перезапуску, лімітами пам'яті та окремим файлом середовища, доступним лише власнику. Логи йдуть у journald з ротацією — диск не забивається.
- Моніторинг: метрики процесу, затримка відповідей біржі, перевірка живості за розкладом, оповіщення в месенджер за порогами — падіння, зростання помилок, простій довше заданого.
- Сценарії відмови: гасимо процес, перезавантажуємо сервер, обриваємо мережу, відкочуємо реліз — дивимося, чи відновлює бот з'єднання і чи не дублює ордери. Прогоняємо заново після кожної зміни.
- Передача в експлуатацію: інструкція з оновлення, відкату й типових збоїв, доступи для команди замовника, розбір на живому стенді.
Конфігурації, юніти й регламенти: склад передачі
Передача — це не архів, а робочий стан проєкту: після приймання бот експлуатують без нас, і все, що потрібно для цього, лежить у репозиторії замовника, а не в листуванні.
Склад фіксуємо в акті приймання — за ним же перевіряємо, що збірка на чистій машині піднімається за один прохід.
Що лежить у репозиторії
- Файли конфігурації бота: параметри запуску, адреси підключення, ідентифікатори ринків — настроювальні значення відокремлені від коду й підставляються із середовища, секретів у репозиторії немає.
- Юніт автозапуску менеджера служб: стратегія перезапуску при падінні, ліміти за пам'яттю й процесором, порядок залежностей, логування в системний журнал.
- Політики доступу: мережевий фільтр із закритими вхідними портами, окремий непривілейований користувач для сервісу, обмеження торгових ключів — лише на потрібні операції, без права виведення коштів.
- Ключі й токени — у захищеному сховищі, не в текстових файлах і не в командному рядку: так секрет не залишається в історії процесів і журналах.
- Схема резервного копіювання: що копіюється, з якою періодичністю, де зберігаються копії, як розгортається копія на резервному сервері.
Регламенти: оновлення, ротація ключів, бекапи
- Оновлення — через тестовий контур з прогрівом на історичних даних, вікно робіт і зафіксований порядок відкату на попередню збірку.
- Ротація ключів — за розкладом і позапланово при зміні складу команди; заміна йде без зупинки бота, старий ключ гаситься після підтвердження, що новий у роботі.
- Бекапи — з перевіркою відновлення, а не лише з фактом вивантаження: раз на квартал піднімаємо копію й звіряємо стан позицій і угод.
- Розбір інцидентів: де дивитися журнали, які метрики вважати аварійними, кому й у який термін ескалювати.
Опишіть задачу — повернемося з оцінкою та планом.
Кейс: як бот перестав падати й втрачати стан
Клієнт прийшов із ботом, якого ми прийняли на супровід під робочим іменем Арбітр: торговий алгоритм на віртуальному сервері, що запускався вручну з термінала. Першим ділом розібрали історію зупинок — вона пояснила майже всі претензії до результатів торгівлі.
Що було до
У процесу не було служби-спостерігача: при розриві з'єднання з біржею або необробленому винятку бот завершувався, і до ранку про це ніхто не знав.
За місяць набиралося до семи нічних зупинок по 40 хвилин і більше, а після ручного перезапуску позиції доводилося звіряти з біржею очима. Стан тримався лише в пам'яті, тому кожне падіння означало втрату незакритих угод і розходження обліку.
Що змінилося після
Кейс налаштування звівся до трьох речей: бот оформили як службу systemd з автоматичним перезапуском і обмеженням частоти спроб, стан винесли в локальну базу із записом на диск після кожної угоди, а журнали подій і оповіщення про збої направили в месенджер — сигнал надходить у момент зупинки, а не вранці.
Стабільний запуск перестав бути ручною операцією: частка часу в роботі виросла з 92% до 99,9%, відновлення після збою займає секунди, ручних перезапусків за квартал — нуль, розходжень із біржею за відкритими позиціями — теж.
Що робити, якщо бот уже розгорнутий на загальному хостингу?
Загальний хостинг тримає бота рівно до першого збою: прав на керування службами немає, фонові процеси й таймери урізані, а при перезапуску чужого застосунку бот просто не піднімається.
Стан живе в одному файлі, до якого немає прямого доступу по мережі, — відновити його після аварії нічим.
Спочатку переносять стан, а не код: базу з історією угод і залишками, файл із ключами, налаштування підключення й робочі журнали.
Код розгортається як є й оформлюється службою з автозапуском і перезапуском при падінні — переписувати логіку під новий сервер не потрібно, якщо вона не зав'язана на обмеження хостингу.
Щоб обійтися без простою, нову копію піднімають поряд: вона працює на знімку бази й не виставляє заявки. Потім переводять потоки — спочатку приймання ринкових даних і сигналів, потім виконання. Старий вузол у цей час дозакриває вже відкриті позиції, тому розрив у роботі непомітний.
Перед перемиканням переносять те, що накопичується у фоні: відкриті ордери, лічильники лімітів майданчика, активні сесії, незавершені транзакції. Кожний запис звіряють із журналом за позиціями — розходження навіть в одному рядку призведе до неправильного розрахунку балансу.
Залишити як є можна статику, веб-панель і архіви журналів — на торгівлю вони не впливають. Порядок переходу простий: підготувати середовище, перенести дані, прогнати бота вхолосту, перемкнути приймання даних і лише потім виконання.
Пару днів старий вузол тримають страховкою з вимкненими заявками, і лише після цього закривають до нього доступи.
Технічні сумніви: питання з експлуатації бота
Питання з експлуатації з'являються не на старті, а через кілька тижнів роботи: що буде при перезавантаженні, як дізнатися про падіння, як оновити логіку, не втративши стан.
Кожне з них закривається конфігурацією, а не обіцянками, тому відповідаємо предметно й із межами застосовності.
Що станеться при перезавантаженні сервера?
Процес описано юніт-файлом з автозапуском і політикою перезапуску при збої. Стан тримаємо у зовнішньому сховищі: після старту бот піднімає позиції та незакриті заявки з журналу, ручна збірка не потрібна.
Як я дізнаюся, що бот упав?
Збираємо ознаки роботи, а не лише живість процесу: свіжість останньої угоди, відставання від ринкових даних, помилки з'єднання. При відхиленні надходить оповіщення в месенджер і на пошту — дізнаємося раніше, ніж помітить око.
Чи можна перенести бота без простою?
Піднімаємо другий контур поряд, переносимо дані, перемикаємо навантаження і лише потім гасимо старий. Простій вкладається в хвилини, історія угод і налаштування зберігаються повністю.
Навіщо виносити дані на окремий сервер?
Тоді вивантаження й резервні копії не конкурують із торгівлею за ресурси, а доступ до сховища обмежений окремими обліковими даними. Компрометація бота не відкриває доступ до бази.
Як оновлювати логіку без ризику для робочої версії?
Збірка йде на тестовому контурі з історичними даними, потім випуск на робочий, а попередня версія залишається готовою до відкату. Зміни схеми даних робимо оборотними.
Обговоримо задачу: що надіслати для оцінки та плану
Оцінка робіт із налаштування сервера під торгового бота не буває шаблонною: обсяг залежить від того, у якому стані майданчик зараз і наскільки жорсткі вимоги до безперервності.
Щоб обговорити задачу предметно, а не в загальних словах, достатньо кількох вступних по проєкту — за ними ми збираємо план упровадження без припущень і зайвих питань по ходу.
- Де зараз працює бот: власна машина, хмарний сервер або локальна станція, яка операційна система й як запускається процес — вручну, через супервізор чи службою.
- Які збої вже були: падіння процесу, перезавантаження, обриви зв'язку з біржею, пропущені сигнали — і як ви про них дізнавалися.
- Як зберігаються дані: ключі доступу, стан позицій, історія угод, резервні копії та місце їх зберігання.
- Хто має доступ до сервера: скільки людей, за якими ключами, чи є спільний пароль або вхід через панель керування.
- Вимоги до простоїв: допустимий час недоступності, чи потрібен автоматичний перезапуск і як обробляти розсинхрон із біржею.
- Що має потрапляти в моніторинг: повідомлення про помилки, ключові метрики й хто з чергових реагує.
Надішліть ці вступні — повернемося з оцінкою робіт і планом упровадження: етапи, терміни, точки перевірки. Заодно скажемо, що з поточної конфігурації можна залишити без змін, щоб не переробляти те, що вже працює стійко.
