Контроль торгового бота: мониторинг, Stop и перезапуск

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

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

Проверяйте четыре разных состояния

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

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

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

Пишите правила, которые называют действие

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

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

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

Пример паузы и сверки заявок

Пусть учебный счёт начинает день с 10 000 USDT, а правило требует проверки при падении стоимости на 2%. Порог равен 9 800 USDT. Если текущий капитал составляет 9 750, наблюдаемое снижение равно 250 / 10 000 = 2,5%. Условие проверки сработало.

Предположим, действие только запрещает новые входы. На счёте остаётся 0,01 BTC и неисполненная заявка на покупку 0,005 BTC по 60 000 USDT. Такая покупка означает ещё 300 USDT потенциального объёма позиции. Пауза сама по себе не отменяет заявку и не продаёт имеющиеся 0,01 BTC.

Если запрос отмены завершился таймаутом, статус неизвестен до сверки с биржей. Покупка всё ещё может исполниться. Освобождать предусмотренный под неё риск только по истечении локального таймера нельзя. В документации REST API Binance отдельно объясняется, почему некоторые ошибки не означают подтверждённый отказ исполнения.

Разделите запрет входа, отмену и выход

Запрет входа блокирует новые решения о покупке. Отмена относится к неисполненным заявкам, которые уже находятся на бирже. Выход отправляет заявку с целью уменьшить существующую позицию. Это три операции с разными последствиями и ошибками.

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

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

Проверочный список для возобновления работы

Перед разрешением новых входов:

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

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

В процессе Clerix показана подготовка стратегии и анализа. Движки тестирования и live-исполнение разрабатываются; сайт не подтверждает работающий биржевой механизм аварийной остановки. Используйте критерии выбора бота, чтобы выяснить доступные средства контроля у поставщика и проверить их поведение до использования.

Частые вопросы

Stop всегда закрывает всё?

Нет. Запрет входов, отмена и выход из позиции — разные операции. Открытые биржевые заявки не отменяются автоматически, а позиции не продаются принудительно только из-за запрета новых входов.

Как часто смотреть на панель?

Универсального интервала нет. Опирайтесь на требования стратегии ко времени реакции и проверенные автоматические уведомления. Ручной просмотр сам по себе не гарантирует обнаружение ошибки между проверками.

Нужно автоматически запускаться после лимита потерь?

Только при явно заданных условиях. Смена суток не устраняет неизвестную позицию и не объясняет инцидент. Сначала сверьте состояние и выполните записанные критерии возобновления.