Торговый бот для биржи: архитектура, инфраструктура и риски автоторговли

Что такое торговый бот и из каких частей он состоит

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

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

Любой боевой бот состоит из четырёх частей:

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

Дальше разберём, почему эти части разделяют и что это даёт на практике.

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

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

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

Слой исполнения и логирования — то место, куда стекается правда. Не то, что бот хотел сделать, а что биржа ответила. Был случай, когда ответы API писались в файл одной слипшейся строкой из-за попытки преобразовать объект в строку перед разбором и отсутствия форматирования при выводе JSON. Мелочь, но именно из-за неё невозможно понять, терялись ордера или нет.

Бот для биржи: подключение к API и подпись запросов

У нас в практике это самое узкое место на старте: люди берут готовую стратегию, а спотыкаются на первых двух запросах к приватным эндпоинтам.

Подпись устроена одинаково почти везде: собрать строку из параметров, добавить временную метку, посчитать HMAC и положить результат в заголовок. Освоив один раз, вы переносите схему на любую биржу.

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

<?php
// Подпись приватного запроса к Bybit API V5 (HMAC-SHA256)
// $apiKey, $apiSecret — из переменных окружения, не из кода
$apiKey    = getenv('BYBIT_API_KEY');
$apiSecret = getenv('BYBIT_API_SECRET');

$timestamp  = (string) round(microtime(true) * 1000); // миллисекунды
$recvWindow = '5000';
$params     = ['category' => 'spot', 'symbol' => 'BTCUSDT', 'side' => 'Buy', 'orderType' => 'Market', 'qty' => '0.001'];
$payloadJson = json_encode($params);

// Строка для подписи POST-запроса: timestamp + apiKey + recvWindow + payload
$payload  = $timestamp . $apiKey . $recvWindow . $payloadJson;
$signature = hash_hmac('sha256', $payload, $apiSecret);

$headers = [
    'Content-Type: application/json',
    'X-BAPI-API-KEY: '     . $apiKey,
    'X-BAPI-TIMESTAMP: '   . $timestamp,
    'X-BAPI-RECV-WINDOW: ' . $recvWindow,
    'X-BAPI-SIGN: '        . $signature,
];

$ch = curl_init('https://api.bybit.com/v5/order/create-post');
curl_setopt_array($ch, [
        CURLOPT_POST           => true,
        CURLOPT_POSTFIELDS     => $payloadJson,
        CURLOPT_HTTPHEADER     => $headers,
        CURLOPT_RETURNTRANSFER => true,
]);
$response = json_decode(curl_exec($ch), true);
curl_close($ch);

Ключевое здесь — порядок частей в строке подписи. Bybit ждёт ровно timestamp + apiKey + recvWindow + query, и если поменять местами хотя бы два элемента, подпись не сойдётся. Меняется под проект обычно recvWindow: если сервер далеко от биржи и время «плывёт», его увеличивают, чтобы запрос не отбраковался по устаревшей метке. Параметры собираем через http_build_query, потому что биржа подписывает ту же строку, что уйдёт в теле — не пересобирайте её вручную.

Секреты держите в переменных окружения или в менеджере секретов, а не в репозитории и не в init.php. И если ключей несколько (торговый, вывод средств), выдавайте каждому минимально нужные права — тогда утечка одного не обнулит весь аккаунт. Для ротации удобнее RSA-SHA256: библиотека bybit-php поддерживает оба алгоритма, а с RSA вы меняете ключ на стороне биржи, не переписывая подпись в коде.

Торговый бот Bybit: базовый URL, регионы и версия API V5

Распространённая ошибка: считать, что «подключиться к Bybit» — это просто вписать домен в конфиг и забыть. Выбор базового URL и версии API определяет три вещи сразу:какой набор эндпоинтов вам доступен, как формируется подпись запроса и какая версия библиотеки вообще скомпилируется без правок.

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

Читать таблицу стоит не построчно, а как связку решений. Первое — базовый URL: у V5 это https://api.bybit.com, и подменять его на «зеркало» из стороннего туториала не нужно, если вы не решаете отдельную сетевую задачу. Второе — версия: V5 даёт единый интерфейс к спотовым, деривативным и опционным эндпоинтам, поэтому именно её закладывают в новые проекты. Третье — подпись: если у вас ключ типа RSA, выставляйте RSA-SHA256, для обычного секрета — HMAC-SHA256; библиотека bybit-php, по опыту сообщества, поддерживает оба варианта, но конфигурируются они по-разному.

Региональный пункт — самый коварный. Сторонние источники до сих пор путают «базовый URL» и «обязательный метод доступа»: в старых сниппетах x-site-id подаётся как постоянный заголовок, хотя официальный чейнджлог прямо говорит, что для внутренних аккаунтов в Бразилии и Аргентине он больше не требуется. Что менять под себя: домен, версию, алгоритм подписи и наличие x-site-id. И сверять это с официальным чейнджлогом, а не с копипастой из блога.

Автоторговля: как обрабатывать непрерывный поток данных с биржи

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

У нас в проектах разделение на коннектор (читает данные) и процессор (принимает решения) снимает большую часть проблем. Коннектор ничего не знает о стратегии — он просто отдаёт поток наружу. Процессор ничего не знает о транспорте — он читает готовый поток и реагирует. Такая развязка позволяет менять WebSocket на REST-поллинг, не переписывая логику торговли, и наоборот. Дальше покажем, как это выглядит в коде на Python с asyncio.

import asyncio
import json

class ExchangeConnector:
    def __init__(self, ws_url: str, symbol: str):
        self.ws_url = ws_url
        self.symbol = symbol

    async def get_data(self):
        """Асинхронный генератор: отдаёт поток наружу через yield."""
        import websockets
        async with websockets.connect(self.ws_url) as ws:
            await ws.send(json.dumps({
                "op": "subscribe",
                "args": [f"tickers.{self.symbol}"],
            }))
            async for raw in ws:
                msg = json.loads(raw)
                if msg.get("topic", "").startswith("tickers"):
                    yield msg["data"]  # вместо print — передаём наверх

Ключевое здесь — yield вместо print. Коннектор не обрабатывает данные, он их отдаёт. К одному потоку можно подключить несколько потребителей: процессор стратегии, логгер, модуль риск-менеджмента. Если у вас один инструмент и одна стратегия, хватит и одного потребителя. Но запас на будущее стоит закладывать сразу.

Процессор запускается отдельной задачей через asyncio.create_task. Это принципиально: блокировать цикл событий нельзя. Любая синхронная операция внутри async for — тяжёлый расчёт, запись на диск, синхронный HTTP-запрос — останавливает чтение из сокета. Пока процессор считает, буфер WebSocket растёт, а котировки в обработке устаревают. Если расчёт неизбежно тяжёлый, выносите его в run_in_executor или в отдельный процесс.

Что стоит менять под свой проект: адрес ws_url и формат подписки зависят от биржи (у Bybit V5 он отличается от Binance), а фильтр topic — от того, какие каналы вам нужны. Для нескольких символов удобнее держать один коннектор с массивом подписок, чем плодить соединения.

class TradingProcessor:
    def __init__(self, connector: ExchangeConnector, trader):
        self.connector = connector
        self.trader = trader

    async def run(self):
        async for data in self.connector.get_data():
            price = float(data["lastPrice"])
            if price > self.trader.target_price:
                await self.trader.place_order("Sell", price)
            elif price < self.trader.stop_price:
                await self.trader.place_order("Buy", price)

async def main():
    connector = ExchangeConnector("wss://stream.bybit.com/v5/public/spot", "BTCUSDT")
    processor = TradingProcessor(connector, trader)
    await asyncio.create_task(processor.run())
    await asyncio.Event().wait()  # держим цикл живым

asyncio.run(main())

Инфраструктура алготрейдинга: где размещать сервер и как снижать задержку

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

Смотрим, что входит в этот слой:

• Сервер — вычислительная площадка под сам бот, его коннектор и обработчики.
• Сеть — канал до API биржи: маршрут, стабильность, jitter.
• Мониторинг — метрики процесса: задержка запросов, разрывы соединения, ошибки авторизации.
• Резервное питание и связность — чтобы падение одного узла не оставило бота без связи с рынком.
• Хранилище логов и метрик — отдельное от рантайма, чтобы разбор инцидента не зависел от падения сервера.

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

Базовый набор, который закрывает большинство сценариев автоторговли:

• VPS в регионе, близком к инфраструктуре биржи — не «где дешевле», а «где ближе по маршруту».
• Отдельный сервер или контейнер под бэктесты — чтобы прогон истории не тормозил боевой процессор.
• Мониторинг процесса: heartbeat, задержка ответов API, статус WebSocket-подписки.
• Алерты в мессенджер — срабатывают на разрыв коннектора и на серию ошибок авторизации.
• Ежедневные бэкапы конфигов и ключевых файлов состояния — стратегия, ключи, параметры риска.

Что даёт колокация. Московская Биржа предоставляет услугу Colocation — размещение серверов в дата-центре биржи для низкого уровня задержки сетевого соединения. Это официальная услуга MOEX, а не «серая» оптимизация. Для HFT-команд это стандартная практика: сервер ставится физически рядом с торговым ядром, и путь запроса сокращается до минимума.

Для криптобирж аналог колокации недоступен, но принцип тот же. Выбирайте регион VPS рядом с инфраструктурой конкретной площадки. Если бот торгует на Bybit, смотрите на дата-центры в Азии и Европе, а не на ближайший к вам по географии хостинг. Разница между «сервер в том же регионе, что и API» и «сервер за океаном» — это не абстрактные миллисекунды, а реальное количество проскальзываний на быстрых движениях.

Если торгуете одну пару на среднесроке, хватит VPS рядом с биржей и базового мониторинга. Для стратегий, которые ловят короткие движения, колокация у MOEX или региональный VPS у криптобиржи обязательны. Иначе вся работа над логикой уйдёт в сетевую задержку.

Как парсить и логировать ответы API, чтобы данные не слипались в одну строку

Самый частый запрос на эту тему — «вывел ответ биржи, а он одной строкой на километр, ничего не разобрать». На ru.stackoverflow разбирали ровно такой случай: человек начал писать бота для биржи, а скрипт выводил данные в одну строку вместо построчного вывода с отступами. Причина оказалась типовой — объект ответа сначала превращали в строку через str(), и только потом пытались форматировать. После str() это уже не словарь, а плоский текст, и json.dumps с ним ничего осмысленного сделать не может.

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

import json
import logging
from datetime import datetime, timezone
from pathlib import Path

log_dir = Path("logs")
log_dir.mkdir(exist_ok=True)

def log_api_response(endpoint: str, response: dict, level: int = logging.INFO) -> None:
    """Пишет ответ API в лог построчно, с отступами и сортировкой ключей."""
    day = datetime.now(timezone.utc).strftime("%Y-%m-%d")
    logger = logging.getLogger(f"api.{endpoint}")
    logger.setLevel(level)

    if not logger.handlers:
        handler = logging.FileHandler(log_dir / f"{endpoint}-{day}.log", encoding="utf-8")
        handler.setFormatter(logging.Formatter("%(asctime)s %(levelname)s %(message)s"))
        logger.addHandler(handler)

    # объект идёт в json.dumps напрямую — без str() перед этим
    pretty = json.dumps(response, indent=4, sort_keys=True, ensure_ascii=False, default=str)
    logger.info("response:\n%s", pretty)

Ключевое здесь — json.dumps(response, ...) получает словарь как есть. Параметр indent=4 даёт отступы, sort_keys=True фиксирует порядок ключей (удобно диффать два лога между собой), ensure_ascii=False оставляет кириллицу читаемой, а default=str спасает на несериализуемых типах вроде datetime, которые иногда просачиваются из SDK. Если обернуть объект в str() раньше — json.dumps получит строку и выведет её как один экранированный литерал: тот самый эффект «всё в одну строку».

Что стоит менять под свой проект. Разбивку логов по дням мы делаем через дату в имени файла — endpoint-2026-09-27.log. Это упрощает ротацию: старые файлы удаляются по маске, не нужно тащить RotatingFileHandler с хрупкими настройками. Для метрик пишите в лог не только тело ответа, но и retCode, retMsg, время запроса и эндпоинт — по ним потом строится алерт «доля ошибок выше нормы». Если ответ содержит приватные поля (баланс, ключи), вырезайте их из объекта до dumps — в лог они попадать не должны.

Риски автоторговли: что ломает бота и как это ловить заранее

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

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

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

Третий слой — kill-switch: отдельный флаг, который останавливает торговлю и закрывает позиции по одной команде. У нас он вынесен в независимый процесс, чтобы не зависеть от того же цикла, что и сама стратегия. Четвёртый - журнал всех ордеров: не только исполненных, но и отклонённых, с причиной отказа. Без него разбор инцидента превращается в гадание. Как именно парсить и хранить ответы API, мы разбирали выше. Здесь важно, что журнал пишется до отправки, а не после ответа.

Тестирование бота: бэктест, тестовая сеть и запуск в прод

Многие думают, что тестирование бота - это «прогнать стратегию на истории и посмотреть, красивая ли кривая доходности». это три разных проверки, каждая ловит свой класс ошибок. Бэктест проверяет логику: правильно ли бот считает сигналы, не путает ли стороны, не открывает ли вторую позицию поверх первой. Тестовая сеть проверяет интеграцию: проходит ли подпись запроса, соблюдаются ли лимиты, корректно ли бот разбирает ошибки биржи. А прод показывает реальную задержку. Между решением и исполнением всегда есть время, и на волатильном рынке оно стоит денег.

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

1. Прогнать стратегию на исторических данных и зафиксировать метрики. Берём свечи и стакан за репрезентативный период, включая хотя бы один резкий разворот. Считаем не только доходность, но и просадку, число сделок, средний размер прибыли и убытка. Результат сохраняем в файл - к нему будем возвращаться после прода, чтобы сравнить ожидание с фактом.
2. Подключиться к тестовой сети биржи и проверить подпись, лимиты, обработку ошибок. Тестнет даёт те же эндпоинты, что и боевой контур, но с фейковыми деньгами. Здесь ловим всё, что не видно в бэктесте: неверный timestamp, расхождение подписи, превышение rate limit, ответы с кодом ошибки вместо ожидаемых данных. Отдельно проверяем, что бот не падает, а корректно ретраит там, где это безопасно.
3. Запустить в прод с минимальным размером позиции и включённым мониторингом. Не с полным депозитом - с размером, который не жалко потерять на отладке. Мониторинг на этом этапе важнее стратегии: логируем каждый запрос, ответ, факт исполнения и текущий P&L. Если что-то идёт не так - бот должен останавливаться сам, а не ждать, пока мы заметим.
4. Сравнить фактические исполнения с ожидаемыми и скорректировать риск-менеджер. Берём сделки из прода и сопоставляем с тем, что бот планировал: цена входа, проскальзывание, время от сигнала до fill. Если расхождение стабильно в одну сторону - правим не стратегию, а риск-менеджер: лимиты, размер позиции, порог срабатывания стопа.

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

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

Юридическая рамка: что важно знать про листинг и регулирование

Разработчик бота редко задумывается о юрисдикции - до момента, когда бот впервые отправляет ордер. И тут выясняется, что граница между криптоинструментом и ценной бумагой не абстракция из учебника, а вопрос, от которого зависит, законна ли вообще ваша торговля. Токенизированные акции, стейблкоины с доходностью, «цифровые права» на активы - всё это может попадать под регулирование рынка ценных бумаг. Тогда к вашему боту предъявляются совсем другие требования: лицензия брокера, отчётность, KYC. Мы видели проекты, где команда месяцами строила арбитражный бот между двумя площадками, не проверив, что один из инструментов по своей правовой природе - не крипта, а именно ценная бумага. Разбираться с этим до запуска дешевле, чем после первого запроса от регулятора.

Базовый документ, на который стоит ориентироваться в российской рамке, - Федеральный закон № 39-ФЗ «О рынке ценных бумаг» от 22.04.1996. Он регулирует отношения при эмиссии и обращении ценных бумаг, а также деятельность профессиональных участников рынка. Для нас здесь важны два понятия. Первое - эмиссия и обращение: если инструмент, которым торгует бот, признаётся ценной бумагой, то вся цепочка от выпуска до сделки подпадает под закон. Второе - листинг: это включение бумаг организатором торговли в список допущенных к торгам, включая котировальные списки биржи. Проще говоря, листинг - это формальный допуск инструмента к торгам на конкретной площадке, и у каждой биржи свои правила и уровни котировальных списков.

На практике это означает: прежде чем писать коннектор к очередной бирже, стоит проверить, что за инструменты она листит и в каком статусе.

Бот, торгующий только криптовалютами на криптобирже, и бот, работающий с токенизированными акциями, - это два разных правовых режима.

Читайте также: Торговый робот: как написать, протестировать на бэктесте и запустить в прод, ИИ-ассистент для бизнеса: как мы внедряем нейросетевых помощников в Bitrix и 1С.