Настройка торгового бота на облаке (AWS, DigitalOcean, Hetzner)

Настройка торгового бота: где ломается инфраструктура

Торговый бот на сервере — это процесс с открытыми позициями в реальном времени: незакрытая сделка живёт ровно до следующего сетевого разрыва. Обрыв связи с биржей приходит в самый неудачный момент — на резком движении, когда заявка уже ушла, а подтверждение не вернулось, и бот не знает, существует ордер или нет.

Вторая точка отказа — перезапуск процесса. Плановое обновление, ошибка конфигурации, исчерпание памяти: если состояние позиций живёт только в оперативной памяти, потеря ордера при сбое почти неизбежна. После старта бот видит остаток на счёте иначе, чем биржа, и первые минуты торгует по неверной картине.

Третья — лимиты частоты запросов. На росте волатильности поток запросов растёт, биржа отвечает отказами, часть заявок отклоняется. Простой бота измеряется не временем падения, а временем работы вслепую, когда бот считает позицию открытой, а её уже закрыл стоп.

Четвёртая — отсутствие резервного узла и логирования. Один сервер, нет следа об отказах — и разбор инцидента превращается в догадки. Настройка торгового бота начинается с того, что каждая из этих точек закрывается до первого запуска: разбираем, как это устроено.

Измеримый эффект настройки: отклик, простой, восстановление

Время реакции на рыночное событие меняется первым. На локальной машине тик обрабатывался с задержкой в несколько секунд: мешал нестабильный канал, фоновые процессы, очередь заявок на одном ядре. В облаке, в зоне AWS, отклик укладывается в доли секунды — в новостные импульсы, когда цена уходит на 2–3% за секунды, бот успевает выставить и снять заявку без проскальзывания.

Простой торгового бота измеряется отдельно. Падение домашнего провайдера или отключение питания давали 6–8 часов без торговли в месяц — как правило, в самые волатильные дни. Автоматический перезапуск процесса по правилу «нет признаков жизни N циклов — поднимаем заново» сокращает незапланированный простой до 10–15 минут в месяц.

Время восстановления задаёт не скорость перезапуска, а целостность состояния. Снимки диска по расписанию и журнал ордеров позволяют собрать позиции заново и сверить их с биржей: 30–40 минут ручной сверки с риском задвоить ордер превращаются в 3–5 минут автоматического прогона с отчётом о расхождениях.

Закрывается и класс отказов, который раньше просто не отслеживался: рассинхрон состояния с биржей после частичного исполнения, зависший без перезапуска процесс, единая точка в виде одной машины и одного канала. Доля потерянных по техническим причинам ордеров в наблюдаемых периодах уходит к нулю — сбой либо не даёт простоя, либо виден в моменте.

Режимы размещения: сервер, контейнер, кластер

Выбор площадки определяется тремя вещами: сколько стратегий крутится одновременно, насколько критична задержка между сигналом и ордером и что происходит при падении узла. Поэтому размещение торгового бота — это не «где дешевле», а какой класс отказов вы готовы принять.

Переход между вариантами не требует переписывать стратегию: логика сигналов, риск-контроль и работа с биржевым программным интерфейсом выносятся в отдельный слой, а размещение становится сменным параметром. На контейнерной площадке это даёт быстрый откат к предыдущему образу, в кластере — автоматический перезапуск пода на другом узле и резервный узел без ручного вмешательства. Для аренды сервера под бота мы отдельно прописываем health-check, автоподъём процесса и вынос состояния на внешний диск, чтобы падение узла не означало потерю позиций.

Порядок работ: аудит, схема, развёртывание, проверка

Развёртывание торгового бота — это не копирование файлов на сервер, а последовательность шагов с проверкой на каждом: логика работает с реальными заявками, и ошибка на этом уровне обходится дороже, чем время, потраченное на подготовку. Порядок ниже одинаков и для нового бота, и для переноса уже работающего.

1. Аудит схемы бота. Разбираем, откуда приходят рыночные данные, как формируются и отправляются заявки, где хранятся ключи доступа и состояние позиций. Результат — карта точек отказа: обрыв связи с биржей, рассинхронизация времени, повторная отправка заявки после перезапуска.
2. План развёртывания. Выбираем площадку под нагрузку и требования к задержке, определяем схему изоляции процессов, распределение прав, порядок работы с секретами и резервное копирование состояния.
3. Настройка окружения. Ключи доступа выпускаем с минимально нужными правами и без вывода средств, выносим параметры в переменные окружения, синхронизируем время, задаём лимиты ресурсов, чтобы бот не вытеснял соседние сервисы.
4. Тестовый контур. Прогоняем стратегию на исторических данных и на тестовом контуре биржи, затем — на минимальных объёмах. Отдельно проверяем сценарии сбоя: потеря связи, отклонённая заявка, частичное исполнение.
5. Контроль состояния и защита. Настраиваем журналы и метрики, оповещения о расхождении позиции с биржей и аварийную остановку по заданным условиям — она срабатывает без участия человека.
6. Передача в эксплуатацию. Отдаём документацию по окружению, регламент обновлений и перезапуска, схему доступа для вашей команды и порядок отката на предыдущую рабочую конфигурацию.

Комплект передачи: конфигурации, схемы, регламенты

Комплект передачи собираем так, чтобы ваша команда могла поднять и сопровождать бота без нашего участия. Всё, что входило в настройку торгового бота на облачных площадках, ложится в репозиторий и базу знаний, а не в переписку и не в голову отдельного инженера. Ниже — что именно остаётся у вас на руках.

• Файлы конфигурации — параметры запуска, торговые пары, лимиты на позицию и суточный оборот, адреса биржевых интерфейсов; версионируются, откат к прошлому набору занимает минуты.
• Схема инфраструктуры — задействованные узлы, связи между ними, точки отказа, маршруты метрик и логов, порядок перехода на резервный узел.
• Права доступа к ключам — матрица ролей, раздельные ключи на чтение и на торговлю, отключённое право вывода средств, порядок ротации и место хранения секретов.
• Регламент дежурства — кто и в какие часы отвечает на оповещение, предельное время реакции, порядок экстренной остановки бота.
• Документация на бота — логика, поддерживаемые режимы, проверки перед стартом, расшифровка типовых ошибок по записям в логах.
• Инструкции по запуску и восстановлению — развёртывание с нуля, подъём после сбоя узла, перенос на другую облачную площадку.
• Чек-лист приёмки — сценарии, по которым вы проверяете работоспособность своими руками.

Комплект считаем переданным, когда ваш инженер поднимает бота по инструкции с нуля и восстанавливает работу после намеренно погашенного узла — без обращения к нам.

Кейс: бот перестал терять ордера при сбоях

Что было

Бот торговал с одной виртуальной машины, а очередь ордеров держал в памяти процесса: снимок на диск уходил раз в несколько минут. Перезапуск или переезд машины на другой физический хост стирал всё, что не успело сохраниться, — за месяц набиралось 12–15 сбоев, 6–8 из них с потерей ордеров. Восстановление шло вручную: сверка позиций с биржей по журналам, до 40 минут простоя и часть сделок по цене хуже запланированной.

Что изменили в схеме

Перевели бота на две ноды Hetzner в разных зонах доступности: состояние очереди пишется в журнал синхронно, до подтверждения от биржи, а на каждый ордер ставится уникальный ключ — повтор при обрыве связи не создаёт дубль. Переключение на резерв автоматическое, по проверке доступности, около десяти секунд; зависшее соединение с биржей перезапускает сторожевой процесс, а повторы идут с ограничением частоты, чтобы не попасть под блокировку по лимитам запросов.

Что стало

Потерянных ордеров — ноль: каждый либо подтверждён, либо безопасно отменён по ключу. Число сбоев упало с 12–15 до 1–2 в месяц, простой сократился с 40 минут до секунд, а расхождение позиций с биржей, которое раньше вычищали вручную, больше не возникает. Отказы перестали быть регулярными: настройка бота теперь сводится к плановым обновлениям, а не к ночным разборам инцидентов.

Технические сомнения: связь, ключи, лимиты, надёжность

Инженерные сомнения по боту сводятся к четырём узлам: где лежат ключи биржи, как не упереться в лимиты запросов, что происходит при обрыве канала связи с биржей и как узнать о сбое раньше, чем он станет убытком. Ниже — короткие ответы, как это устроено в наших конфигурациях.

Что будет, если бот упрётся в лимиты запросов биржи?

Лимиты считаются и на IP, и на ключ, поэтому бюджет запросов планируется под стратегию заранее: справочники кэшируются, баланс и позиции запрашиваются пачками, поток ордеров идёт через очередь с ограничением частоты. При ответе биржи об ограничении бот уходит в паузу с нарастающим интервалом, а не повторяет запрос — иначе временная блокировка превращается в длительную.

Канал до биржи оборвался — бот наторгует лишнего?

Поток котировок может замереть молча, поэтому держим heartbeat и реконнект с восстановлением подписки, а после переподключения сверяем локальное состояние с биржевым. Ордера помечаются собственными идентификаторами, так что повторная отправка не создаёт дубли, а перезапуск процесса продолжает работу с последнего подтверждённого состояния.

Как устроен мониторинг бота и уведомления?

Снимаем задержку потока, долю отказов, расхождение между локальными и биржевыми позициями и время простоя. Пороги настраиваются под стратегию: алерт приходит в рабочий мессенджер, а отдельный сторожевой сигнал ловит ситуацию, когда процесс жив, но данные не обновляются. Дальше — безопасный режим: остановка открытия новых заявок или снятие активных, по вашему выбору.

Обсудим задачу — вернёмся с оценкой и планом работ

Настройка торгового бота — работа, где ошибка в конфигурации видна сразу по сделкам: разрыв связи с биржей ночью, потерянный стоп или дублирующий ордер стоят дороже самой инфраструктуры. Чтобы вернуться с оценкой работ и планом внедрения, а не общими словами, нам нужно увидеть вашу схему целиком.

Пришлите по задаче:

• Описание стратегии: логика входа и выхода, рабочие интервалы, набор инструментов, лимиты по позиции и риску на сделку.
• Текущую схему запуска: где бот работает сейчас, какие есть скрипты и файлы настроек, что вы делаете руками при перезапуске.
• Перечень площадок и типов счетов: спотовые, срочные, тестовые контуры бирж, а также как хранятся ключи доступа.
• Требования к отказоустойчивости: допустимый простой, нужна ли горячая замена узла, поведение бота при обрыве связи с площадкой.
• Режим дежурства: кто и как получает уведомления, нужна ли круглосуточная реакция или достаточно рабочих часов.
• Ограничения по размещению: требования к юрисдикции, резервному копированию состояния и порядку доступов для наших инженеров.

С этим набором мы собираем план внедрения: переносим бота на облачный контур, разводим секреты и сборку по средам, настраиваем мониторинг и автоматический перезапуск, прогоняем на тестовом контуре и только потом выполняем запуск бота в работу. Опишите задачу — вернёмся с оценкой и планом работ.

Бот на сервере или на домашней машине: что выбрать?

Если бот торгует постоянно, бот на домашней машине — самый слабый элемент схемы. Локальный запуск бота удобен, пока вы отлаживаете логику, но как только позиции открываются без вашего участия, любая пауза превращается в незакрытую сделку. Поэтому домашняя машина остаётся инструментом разработки, а рабочий контур живёт на серверной площадке.

Риски домашнего размещения складываются из бытовых мелочей. Перезагрузка после обновления системы, спящий режим, перебои питания, обрыв канала у провайдера, динамический адрес за роутером — каждое из этих событий останавливает процесс. Диск без резерва и снимков состояния означает, что после сбоя вы восстанавливаете вручную и самого бота, и историю ордеров.

На выделенной площадке эти точки отказа закрываются по отдельности: процесс поднимается автоматически после перезапуска, снимок возвращает конфигурацию и состояние к последней рабочей точке, внешний мониторинг сообщает о падении, а доступ по ключам ограничивает круг людей с правами на торговые операции.

Локальный запуск при этом не становится лишним. Прогон стратегии на исторических данных, проверка логики на тестовом контуре, подготовка конфигурации — это быстрее делать на своей машине, где есть прямой доступ к логам. Отдельный случай — требования к хранению ключей: если политика запрещает выносить их на чужую площадку, часть контура остаётся локальной.

Разница проявляется не в скорости сделок, а в предсказуемости: домашняя машина даёт удобство отладки, серверная площадка — непрерывность. Рабочая схема обычно гибридная — логика готовится локально, торговая часть работает на площадке, а перенос конфигурации между ними описан и повторяем.