Автоматизация торговли: советники, скрипты MQL, cBot и VPS

Автоматизация передаёт повторяющиеся задачи программе, но ответственность за её поведение остаётся на вас. Советнику или cBot нужна определённая среда выполнения: терминал, VPS либо облачный сервис. Мы объясняем различия этих сред, диагностику ошибок и защиту счёта после обрыва связи или перезапуска. Статья также рассматривает стоимость хостинга, задержку исполнения и проверки перед запуском программы на счёте, где торгуют с использованием маржи.

1. Где на самом деле работает робот: советник, терминал, сервер брокера

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

При любом разборе сбоя полезно помнить такую цепочку:

Код советника → терминал (среда выполнения) → сервер брокера → проверка заявки → исполнение или отказ → ответ сервера → журнал и состояние советника

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

События, на которые реагирует код. В MT4 и MT5 торговая программа управляется событиями. OnInit() вызывается при запуске: здесь следует проверять входные параметры и готовить состояние. OnTick() вызывается при очередной котировке инструмента, к которому прикреплён робот. OnDeinit() вызывается при удалении программы с графика, изменении параметров или закрытии терминала. OnTimer() предназначена для периодических действий, а OnChartEvent() — для взаимодействия с графиком. Обе функции существуют в обоих языках; документация MQL4 приводит их полные сигнатуры рядом с OnInit(), OnTick() и OnDeinit() [10]. Разница между средами — в торговом слое: MT5 добавляет события, которых в MQL4 нет вообще, — OnTrade() и OnTradeTransaction() для реакции на изменения состояния счёта [14]. Отдельно, уже вне торгового слоя, в MT5 есть также OnBookEvent() — событие рыночных данных, которое документация описывает как обработку изменений глубины рынка, то есть книги заявок [14]. Оно работает только там, где глубина рынка вообще предоставляется. Доступность книги заявок зависит от инструмента и брокера, а на розничных forex-счетах её часто просто нет. Это не курс программирования, а минимум для понимания того, когда ваш код вообще получает возможность действовать.

Практическое следствие неудобно: OnTick() — не часы. Число вызовов зависит от входящих котировок и обработки очереди событий. В MQL5 новое событие NewTick не добавляется, пока такое событие уже находится в очереди или обрабатывается[25]. Два брокера по одной паре могут давать заметно разное число тиков, поскольку по-разному фильтруют поток и используют разные источники ликвидности. Логика, предполагающая «более или менее постоянную» частоту вызовов, на деле зависит от брокера и типа счёта. Между брокерами она переносится хуже, чем можно ожидать по одинаковому коду.

Что остаётся, когда терминал выключен

Это различие спасает счета, и именно здесь снова возникает неверное упрощение: «В MT4 всё на стороне клиента».

Уровни Stop Loss и Take Profit, прикреплённые к позиции или отложенной заявке, хранятся на сервере брокера и работают независимо от того, запущен ли терминал. Встроенный в интерфейс MetaTrader трейлинг-стоп работает наоборот: рассчитывается локально по входящим котировкам и перестаёт передвигать стоп при закрытии платформы. Это относится и к MT4, и к MT5, но каждая платформа подтверждается отдельным источником. Справка MetaTrader 4 описывает трейлинг-стоп как механизм, работающий в клиентском терминале, а не на сервере, и прекращающий работу после выключения терминала [8], а справка MetaTrader 5 повторяет то же правило: трейлинг-стоп выполняется в платформе, а не на сервере, как Stop Loss [11]. Здесь нужны два уточнения, без которых утверждение становится неверным. Первое: закрытие терминала прекращает передвижение уровня, но не отменяет последнюю модификацию, которую терминал успел отправить. Она остаётся на сервере и продолжает защищать позицию. Второе: это описание нельзя распространять на все платформы. В cTrader механизм устроен иначе: справка производителя гласит, что «все средства защиты работают во всех приложениях cTrader и остаются активными после окончания сеанса» [22], а страница панели Trade Watch прямо говорит о самой функции: «Трейлинг-стоп-лосс работает, даже когда приложение cTrader закрыто или отключено» [23]. Значит, условие поддерживается вне пользовательского приложения и не требует его работы. Одинаковое название функции, две разные модели работы. Именно поэтому привычки одной платформы нельзя переносить на другую; граница между серверной заявкой и локальной функцией подробнее разобрана в статье 11.4 [по состоянию на 2026-08-22; состав функций конкретного брокера подтверждайте в его документации].

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

Полная и частичная автоматизация

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

Однако предпосылка у обоих вариантов одна: правила должны допускать однозначную запись. Если вход, выход и риск требуют оценки «качества» ситуации, у вас не система для автоматизации, а мнение о рынке. Автоматическая система выполнит дефектную спецификацию столь же последовательно, как хорошую, только быстрее и без перерывов. Имеют ли правила положительное математическое ожидание вообще, рассматривает материал о преимуществе и математическом ожидании; здесь мы разбираем лишь безопасный запуск такой спецификации.

2. Индикатор, скрипт, советник и cBot: четыре разных класса инструментов

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

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

В cTrader разделение другое и не сопоставляется один к одному. Аналог советника — cBot, аналог индикатора — индикатор. Отдельной категории «скрипт» нет: однократную операцию выполняет cBot, который делает работу в стартовом методе и сам останавливается.

Три ошибки, отнимающие время:

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

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

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

СТРУКТУРНАЯ СХЕМА - диагностика среды перед написанием робота
Ориентировочная запись для MQL4. Это не полный компилируемый код.

точка входа: OnStart() - однократная, заканчивается вместе с функцией

1. symbol   := Symbol()
   Не задавайте имя жёстко: суффикс брокера его меняет.

2. bid, ask := MarketInfo(symbol, MODE_BID / MODE_ASK)
   point    := MarketInfo(symbol, MODE_POINT)
   spread   := if point > 0 then (ask - bid) / point
               иначе: показание не установлено
   Нулевой point означает сбой чтения спецификации, а не нулевой
   спред; эти случаи должны давать разные записи журнала.

3. lotMin   := MarketInfo(symbol, MODE_MINLOT)
   lotStep  := MarketInfo(symbol, MODE_LOTSTEP)
   Свойства инструмента у конкретного брокера, не константы языка.

4. в журнал: symbol, bid, spread, lotMin, lotStep,
   OrdersTotal(), AccountFreeMargin()

5. tradePossible := IsTradeAllowed()
   Метка в журнале: торговля возможна в данный момент.
   Не: автоматическая торговля разрешена; см. абзац ниже.

чего схема не содержит и не должна содержать:
   вызовов OrderSend, OrderClose или OrderModify.

Три элемента этой схемы возвращаются в каждом следующем роботе: имя символа, прочитанное из среды, а не заданное жёстко; шаг объёма из спецификации; явная проверка возможности торговли в данный момент. Последний пункт требует исправить популярное упрощение. IsTradeAllowed() отвечает не только на вопрос разрешения автоматизации. Документация MQL4 описывает проверку того, «разрешено ли советнику торговать и не занят ли торговый контекст» [15]. Поэтому результат false может означать отсутствие разрешения либо занятый торговый контекст — временное состояние, которое пройдёт само. Записывайте отдельно результат функции и причину, установленную дополнительной проверкой. Иначе диагноз «торговля отключена» получит состояние, в котором она вовсе не отключена. Раздел об эксплуатационных сбоях возвращается ко всем трём показаниям.

3. MQL4 и MQL5: две среды, а не две версии одной

Популярное упрощение «MQL5 — это MQL4 с большим числом функций» неверно именно там, где важно на практике: в модели заявок и позиций. Сразу уберём и второй миф. MQL4 — не чисто процедурный язык: документация MetaQuotes описывает для него классы, наследование, виртуальные функции и шаблоны [1]. Значит, различие не в парадигме программирования, а в торговом интерфейсе, способе чтения индикаторов и представлении открытой экспозиции платформой.

Торговый слой. В MQL4 одна функция, OrderSend(), открывает позицию, а OrderSelect() переключает контекст на следующий элемент списка, где отложенные заявки и открытые позиции находятся рядом. В MQL5 понятия разделены: заявка, позиция и историческая сделка различаются. Отправить запрос — значит заполнить структуру и проверить возвращённую структуру с кодом ответа сервера. Классы стандартной библиотеки, такие как CTrade, — удобная оболочка этого механизма, а не отдельный режим работы [2].

Слой данных. В MQL4 вызов индикатора возвращает значение для заданной свечи. В MQL5 тот же вызов возвращает дескриптор, создаваемый один раз, обычно в OnInit(); значения затем копируются в массив функцией копирования буфера. Буквально переписанный код создаёт новый дескриптор на каждой котировке вместо использования существующего. Компилятор об этом не сообщит: ошибка в месте создания дескриптора, а не в синтаксисе. Это классическая ловушка переноса именно потому, что проявляется не сразу.

Строка о режиме учёта заслуживает отдельного пояснения: она вызывает неожиданные сбои. Неттинг означает одну чистую позицию на инструмент. Встречная заявка не открывает вторую позицию, а сокращает или разворачивает существующую. Робот, перенесённый с MT4 и предполагающий множество независимых позиций по одному символу, начнёт в этом режиме закрывать собственные входы. Режим счёта задаёт брокер, поэтому это не «поведение MT5 по умолчанию», а свойство конкретного счёта. Его нужно проверить до запуска, желательно также прочитать из кода.

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

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

4. cTrader Algo: C#, Python, локальная и облачная работа

Здесь проще всего повторить устаревшее описание продукта. Старые материалы называют среду автоматизации cTrader именами cAlgo и cTrader Automate и представляют её как исключительно локальную и поддерживающую только C#. Сегодня оба утверждения неверны.

Согласно официальной документации Spotware среда называется cTrader Algo и поддерживает создание алгоритмов на двух языках: C# и Python [3]. cBot могут исполняться локально или в облаке. Документация облачных функций прямо говорит, что cBot работает в изолированной среде, предоставленной cTrader. Пользовательское приложение — Windows, Mac, мобильное или браузерное — не обязано оставаться открытым либо подключённым к интернету [4]. Это меняет весь расчёт хостинга, рассматриваемый далее.

Ограничения облачного выполнения на 2026-08-22. Документация допускает на реальном счёте до десяти одновременно работающих непрерывных экземпляров, а на демосчёте — один экземпляр, автоматически останавливающийся не позднее чем через семь дней. Также отмечено, что правила могут отличаться у разных брокеров, а cBot с внешними пакетами работают в облаке при выполнении дополнительных условий [4]. Считайте эти числа состоянием продукта на дату публикации и проверьте снова, прежде чем строить на них архитектуру.

Структура cBot. Программа наследует базовый класс робота. Стартовый метод соответствует знакомой по MQL инициализации, обработчик очередной котировки — OnTick(), а метод остановки — деинициализации. Практически полезное отличие — встроенная обработка события закрытия свечи. В MetaTrader это условие нужно определять самостоятельно, сравнивая время открытия текущей свечи с сохранённым.

Open API — не REST. Это стоит записать точно: во вторичных материалах встречается упрощение «у cTrader есть REST API». Документация Spotware описывает обмен данными в Open API через объекты JSON или Google Protocol Buffers [5]. FIX API — отдельный сервис. Права, доступность и условия подключения зависят от брокера, поэтому интеграцию нужно планировать после изучения документации конкретного поставщика, а не общего описания платформы.

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

Вебхук как мост к другим системам

Второй путь автоматизации не проходит через код внутри платформы. Событие внешней системы, например оповещение графической платформы, отправляет HTTP-запрос на согласованный адрес. Лишь затем промежуточное приложение превращает его в вызов API брокера. Цепочка выглядит так: событие → вебхук → промежуточное приложение → API брокера → проверка → заявка → ответ сервера. Вебхук отвечает ровно за одно звено: отправку запроса. Доставка — не исполнение. Правильно полученный вебхук ничего не говорит о соответствии объёма спецификации, наличии свободной маржи или принятии заявки сервером брокера. Каждый промежуточный узел добавляет задержку и собственный вид отказа, включая повтор того же запроса после восстановления соединения. Адрес вебхука нужно защищать, но знание адреса не заменяет авторизацию: посредник обязан проверить отправителя, свежесть запроса и уникальный идентификатор. Настройка оповещений на стороне графической платформы относится к отдельной статье; здесь важны лишь место этого моста в цепочке исполнения и отсутствие гарантии исполнения.

5. Права, компиляция, журналы и распознавание своих позиций

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

Компиляция и размещение файлов

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

Три уровня разрешения автоматической торговли

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

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

СТРУКТУРНАЯ СХЕМА - проверка прав и нормализация объёма
Ориентировочная запись для MQL5. Это не полный компилируемый код.

A. РАЗРЕШЕНА ЛИ ТОРГОВЛЯ - четыре показания, каждому своя запись

   TerminalInfoInteger(TERMINAL_TRADE_ALLOWED)
      false -> алгоритмическая торговля отключена в платформе
   MQLInfoInteger(MQL_TRADE_ALLOWED)
      false -> торговля отключена в свойствах программы
   AccountInfoInteger(ACCOUNT_TRADE_ALLOWED)
      false -> торговля заблокирована на стороне счёта
   AccountInfoInteger(ACCOUNT_TRADE_EXPERT)
      false -> брокер не разрешает здесь автоматическую торговлю

   Торговля разрешена только при всех четырёх значениях true.
   Журнал должен показывать неудачную проверку, иначе диагноз
   заканчивается словами «робот не торгует».

B. ПРИВЕДЕНИЕ ОБЪЁМА К СЕТКЕ ШАГА

   вход:   symbol, vol
   выход:  кратное шагу либо 0.0, означающий «не отправлять»

   B1. if not MathIsValidNumber(vol) or vol <= 0.0
          -> записать ошибку и вернуть 0.0
       Обычные сравнения ненадёжно отклоняют NaN. До арифметики
       явно проверяйте конечность входа, иначе результат может
       остаться недопустимым.

   B2. прочитать спецификацию вариантом, возвращающим статус:
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MIN,  vmin)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MAX,  vmax)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_STEP, vstep)
       любое показание false либо vstep <= 0.0
          -> записать _LastError и вернуть 0.0
       Вариант только с числом при ошибке молчит и возвращает
       ноль, неотличимый от настоящего нуля.

   B3. TOL   := 1e-8            допуск двоичного деления
       steps := MathFloor(vol / vstep + TOL)
       result := NormalizeDouble(steps * vstep, 8)

       Обещанное постусловие функции, и только оно:
         результат кратен целому числу шагов,
         превышение входа не больше
         TOL * vstep.
       Она не обещает никогда не превышать вход.

   B4. if result > vmax
          -> result := NormalizeDouble(MathFloor(vmax / vstep + TOL) * vstep, 8)
       if result < vmin
          -> return 0.0
       Порядок важен: минимум и максимум проверяются только
       на значении, уже приведённом к сетке шага.

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

Две детали заслуживают пояснения: обе относятся к классу ошибок из абзаца о предупреждениях компилятора, когда код работает, но результат молча отличается от рассчитанного. Первая: объём получается подсчётом целых шагов и умножением на шаг, а не округлением до заранее заданного числа десятичных знаков. Округление до двух знаков превратило бы 0,003 в ноль на инструменте с шагом 0,001, встречающимся на центовых счетах и некоторых CFD. Вычисление числа знаков через логарифм шага ломается там, где шаг не является степенью десяти: при шаге 0,25 объём 1,75 округлится до 1,8 — значения, не кратного шагу. Сервер отклонит его точно так же, как объём без нормализации вообще. Вторая деталь: деление с плавающей точкой может дать число чуть меньше целого. Без небольшой поправки округление вниз незаметно отнимет один шаг: 0,3, делённое на 0,1, получается меньше трёх, и позиция откроется меньше расчёта риска. Поэтому минимум и максимум проверяют только в конце, на значении, уже приведённом к сетке шага. Округление вниз может увести ниже ранее соблюдённого минимума, а ограничение максимумом должно попасть на ту же сетку, что и остальной результат.

У той же поправки есть обратная сторона, которую нужно назвать явно, не обещая большего. Поскольку перед округлением вниз что-то добавляется, результат может чуть превысить вход: для объёма 0,2999999995 при шаге 0,1 функция вернёт 0,3, то есть на пять десятимиллиардных лота больше исходного. Для шагов этого примера разница ничтожна, но гарантия должна быть точной: результат кратен шагу и превышает вход не больше принятого допуска. Это сознательная граница: без неё тот же код теряет целый шаг на объёме 0,3. Два случая нужно останавливать отдельно: неконечный вход, который обычные сравнения ненадёжно отклоняют, и неудачное чтение спецификации. Поэтому схема использует MathIsValidNumber() на входе и вариант SymbolInfoDouble(), возвращающий статус, вместо варианта только с числом. Последний при ошибке даёт ноль, неотличимый от настоящего нуля.

Журналы — основной диагностический след после сбоя

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

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

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

Распознавание собственных позиций

Робот должен отвечать на вопрос «Эта позиция моя?». На счёте могут одновременно быть сделки, открытые вручную, другим роботом или той же стратегией на другом символе. Для распознавания служит числовой идентификатор, присваиваемый заявке при отправке, — magic number в обеих средах MetaTrader, — а также поле комментария. Правило простое: каждый цикл по позициям фильтрует одновременно по идентификатору и символу, никогда только по символу.

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

6. Каталог сбоев в эксплуатации: от переподключений до изменения спецификаций символа

Часть сбоев автоматизации относится к среде выполнения, а не к правилам стратегии. Обычный бэктест воспроизводит не все такие ситуации; некоторым нужны отдельные испытания отказов. Это не каталог экзотики, а случаи, к которым нужно готовиться при работе робота несколько месяцев.

Сценарий для самостоятельного воспроизведения: дублирование заявки после переподключения

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

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

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

Как проверить самостоятельно. Вручную выключить сетевую карту «сразу после отправки» — лотерея, а не процедура. Вы не контролируете, успел ли запрос дойти до сервера. Если не успел, воспроизводится другой случай — обычная неудачная заявка. На демосчёте можно управляемо прервать связь правилом межсетевого экрана или диагностическим инструментом, но подтверждение отправки ещё не доказывает исполнение. Этот сценарий состоялся только тогда, когда серверная история подтверждает исполнение, а терминал не получил ответа. Тестер стратегий такую ситуацию не воспроизводит, поэтому испытание ручное и именно поэтому требует записи. Зафиксируйте всё перечисленное ниже: без любого пункта результат ничего не устанавливает и несопоставим с другим испытанием:

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

Нужно исправить и второй пункт, часто повторяемый как готовый рецепт. Magic number определяет стратегию, а не отдельное намерение отправить заявку: у двух запросов одного робота он одинаков. Одного его недостаточно, чтобы решить, «уже ушла именно эта заявка или нет». Нужен постоянный идентификатор отдельного решения, присвоенный и записанный до отправки и хранимый вне памяти процесса. Только он позволяет при сверке состояния различить «не отправлял» и «отправил, но не знаю исхода». Поле комментария — естественное место передачи идентификатора в заявку, но сервер иногда обрезает или заменяет его. Считайте его подсказкой, а решение основывайте на сопоставлении своей записи с серверной историей.

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

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

7. Непрерывность работы: компьютер, VPS, хостинг платформы и расчёт затрат

Классической системе MetaTrader нужен работающий терминал. Только поэтому обсуждается хостинг: не ради скорости или «профессионализма», а потому, что выключенный процесс ничего не вычисляет. Исключение — облачный путь из раздела cTrader Algo: cBot, соответствующему условиям облака, внешний VPS может вообще не понадобиться. Оговорка важна: та же экосистема допускает локальный запуск, и тогда вопрос хостинга возвращается полностью. Число экземпляров ограничено типом счёта и брокером, а cBot с внешними пакетами работают в облаке лишь при дополнительных условиях.

Что добавляет домашний компьютер. Отключение электричества, перезапуск после обновления, отказ линии интернет-провайдера, зависание системы. Каждое событие выключает среду выполнения, а значит, всю логику робота. Оно не выключает уровни SL и TP на сервере брокера. Эту границу нужно знать для оценки реальных потерь во время отказа.

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

Два разных продукта под одним названием

Словом «VPS» называют два решения с совершенно разным администрированием.

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

Встроенный хостинг платформы устроен иначе. Сервис MetaTrader VPS запускается из самой платформы, а среда переносится одной командой. Он размещает работающие системы и подписки на копирование сигналов, не требуя администрирования Windows или подключения по удалённому рабочему столу [6]. У простоты есть цена: произвольное ПО установить нельзя, ресурсы ограничены.

Расчёт стоимости инфраструктуры на явном примере

Беру цены выше, чтобы пример можно было проверить, а не просто представить. При годовой оплате затраты равны 12 × 10 USD = 120 USD в год. При ежемесячной оплате 12 × 15 USD = 180 USD в год.

Вывод ограничен этим примером. На счёте порядка 2 000 USD один хостинг съедает несколько процентов капитала в год ещё до спреда и комиссии, конкурируя с реалистично ожидаемым результатом. На счёте в десять раз больше тот же сервис составляет десятую долю этого процента капитала. Отсюда не следует, что VPS кому-либо ещё «выгоден» или «невыгоден». Следует лишь необходимость считать стоимость инфраструктуры относительно своего капитала, а не цены на странице поставщика.

Выбор параметров и развёртывание

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

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

Контрольный список развёртывания хостинга:

1. Запустите всю конфигурацию на демосчёте и держите не заданное число дней, а до прохождения трёх событий: принудительного перезапуска машины, потери и восстановления связи, закрытия и открытия рынка после выходных. Только затем меняйте счёт
2. Задайте окно обновлений вне торговых часов и проверьте последствия принудительного перезапуска
3. Настройте автозапуск платформы и восстановление графиков с прикреплёнными программами
4. Отдельно проверьте включение автоторговли после перезапуска: запуск платформы этого не гарантирует
5. Включите независимый мониторинг доступности машины и отдельно процесса платформы: один ping не обнаружит зависшее приложение
6. Отключите гашение экрана и сон, настройте ротацию журналов, контролируйте свободный диск
7. Защитите удалённый доступ сильным уникальным паролем и многофакторной аутентификацией, если она доступна; по возможности ограничьте адреса подключения
8. Копируйте шаблоны графиков и наборы параметров. Не храните учётные данные счёта в конфигурационных файлах и заметках: для этого есть менеджер паролей
9. Спланируйте потерю машины: откуда и за какое время восстановите конфигурацию

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

8. Задержка: что именно вы измеряете и чего измерение не показывает

«Ping 2 мс» не означает «заявка исполнена за 2 мс». Стоит прочитать дважды: продажа торговой инфраструктуры опирается на размывание этой границы. Задержка цепочки исполнения состоит из нескольких участков, измеряемых отдельно, разными инструментами и с разной точностью.

Заявления хостеров почти всегда относятся к первому или второму участку. Когда MetaQuotes сообщает, что из инфраструктуры MetaTrader VPS доступ к 96% серверов брокеров занимает менее 10 мс [6], речь о сетевом участке. Отсюда ничего не следует о сроке фактического заключения вашей сделки брокером. Он зависит от политики исполнения, доступной ликвидности и текущей загрузки сервера.

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

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

Для оценки чувствительности самой логики есть тестер стратегий MetaTrader 5. Он позволяет эмулировать задержку исполнения и использовать разные модели генерации тиков, включая реальные тики брокера [7]. Это не измерение вашего соединения, а проверка, переживает ли стратегия худшие условия исполнения вообще. Полная методология таких тестов относится к статье о тестировании стратегий.

Когда это вообще важно

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

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

Параметры защиты от плохих условий исполнения

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

Второй часто называют универсальным пределом цены исполнения, но это неверно. Максимальное допустимое отклонение цены при отправке относится лишь к одному режиму. Справка MetaTrader 4 ограничивает это одной фразой: «Отклонение цены при размещении заявок используется только в режиме немедленного исполнения» [18]. Там же описана работа поля — наоборот привычному «это защита от проскальзывания»: «Если отклонение меньше или равно заданному параметру, заявка исполнится по новой цене без дополнительного уведомления. Иначе брокер вернёт новые цены, по которым заявка может быть исполнена» [18]. Значит, изменение в пределах лимита исполняется по новой цене без уведомления, а реквот — возврат новых цен для подтверждения — возникает только за пределами. В рыночном режиме поля вообще нет. Справка MetaTrader 5 описывает параметр для Instant Execution, а о Market Execution говорит противоположное: «В этом режиме брокер решает, по какой цене исполнить заявку, без дополнительного обсуждения с трейдером». И прямо добавляет: «Отправка заявки в таком режиме означает предварительное согласие на исполнение по этой цене» [11]. Здесь цену задаёт брокер, отправка означает согласие заранее, а в форме на этом месте находится Fill Policy, не отклонение.

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

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

9. Аварийная остановка, лимиты и минимальный стандарт запуска

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

Набор лимитов каждой системы на реальном счёте:

1. Лимит просадки средств. При превышении заданного падения от пика средств робот закрывает свои позиции, чтением счёта подтверждает, что ничего не осталось, и только затем останавливается. Если что-то осталось, сохраняет активность и подаёт тревогу. Порог определяется принятым планом риска — методика его выбора относится к материалу о риске; здесь важно наличие порога в коде и проверка до логики стратегии
2. Дневной лимит убытка. Счётчик обнуляется в заданный час сервера и после перезапуска восстанавливается из истории сделок, а не хранится лишь в памяти
3. Лимит открытых позиций. Жёсткий максимум независимо от логики входа
4. Лимит размера одной позиции. Верхняя граница для результата расчёта размера позиции, чтобы арифметическая ошибка не стала заявкой несоразмерного объёма
5. Фильтр спреда и, если режим символа позволяет, максимальное отклонение цены. Оба описаны в предыдущем разделе
6. Часовой фильтр. Окна, в которых робот не открывает позиции
7. Реакция на проблемы связи. При обрыве или устаревших котировках робот блокирует новые позиции, но не закрывает имеющиеся вслепую: закрытие по старой цене иногда хуже ожидания

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

условие остановки: текущие средства < пиковые средства × (1 − допустимая просадка) → записать журнал → закрыть свои позиции → пересчитать свою экспозицию → удалить программу только при нуле позиций и ошибок закрытия → иначе подать тревогу и остаться активной

Ниже последняя структурная схема статьи и единственная, затрагивающая закрытие позиций. Поэтому у неё две защитные ступени, обе в значениях по умолчанию, а не комментарии. Первая: dry-run изначально включён. Программа не отправляет операций, а пишет, что закрыла бы. Вторая: до первой котировки считывается тип счёта, и на любом недемонстрационном счёте инициализация отклоняется, пока читатель не задаст отдельное явное согласие. MQL4 предоставляет это чтение через AccountInfoInteger(ACCOUNT_TRADE_MODE), а документация различает демонстрационный, конкурсный и реальный счёт [16]. Предупреждение в комментарии — не защита. Защита — значение по умолчанию, которое нужно сознательно изменить, чтобы что-либо произошло.

СТРУКТУРНЫЙ ЭСКИЗ - аварийная остановка при просадке средств
Условная запись для MQL4. Это не полный код, готовый к компиляции.

ВХОДНЫЕ НАСТРОЙКИ - первые две определяют безопасность

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

   LiveAccountConsent := FALSE                значение по умолчанию
      Без этого разрешения программа отказывается запускаться
      на счёте, отличном от демонстрационного. Такое согласие
      нельзя дать случайно.

   MagicNumber    - идентификатор собственных позиций
   MaxDrawdownPct - допустимая просадка от пиковых средств
   MaxDeviation   - действует только в одном режиме исполнения;
                    см. абзац под эскизом

ЗАПУСК - OnInit()

   mode := AccountInfoInteger(ACCOUNT_TRADE_MODE)
   if mode != ACCOUNT_TRADE_MODE_DEMO
         and not LiveAccountConsent:
      записать в журнал: счёт не демонстрационный, согласия нет
      завершить инициализацию с ошибкой (INIT_FAILED) - на этом всё
   peak       := AccountEquity()
   stopped    := FALSE
   lastAlert  := 0          метка времени последнего уведомления

КАЖДАЯ КОТИРОВКА - OnTick()

   if stopped:
      remaining := CountOwnPositions()
      if remaining > 0
            and TimeCurrent() - lastAlert >= 3600:
         записать в журнал: остановленное состояние, remaining
         отправить уведомление человеку
         lastAlert := TimeCurrent()
      завершить обработку этой котировки
         программа сама не повторяет закрытие - следующую
         попытку человек решает выполнить вручную
   equity := AccountEquity()
   if equity > peak: peak := equity
   threshold := peak * (1 - MaxDrawdownPct / 100)

   if equity >= threshold:
      эта ветвь пуста - эскиз только следит за порогом
      и вообще не содержит логики входа

   иначе:
      stopped := TRUE
      записать в журнал: equity, threshold, peak, метка времени
      errors    := CloseOwnPositions()
      remaining := CountOwnPositions()
      if remaining == 0 and errors == 0 and not DryRun:
         ExpertRemove()          удаление только после успеха
      иначе:
         записать в журнал: errors, remaining
         отправить уведомление человеку
         lastAlert := TimeCurrent()
         НЕ удалять программу - она остаётся активной, ничего
         нового не открывает, повторяет уведомление и ждёт человека

ЗАКРЫТИЕ - CloseOwnPositions() возвращает число ошибок

   errors := 0
   for i from OrdersTotal() - 1 down to 0:

      if not OrderSelect(i, SELECT_BY_POS, MODE_TRADES):
         errors := errors + 1
         записать в журнал: позиция i, GetLastError()
         перейти к следующей            здесь нельзя молчать об ошибке

      if OrderType() > OP_SELL: пропустить
                                     отложенные ордера отдельно
      if OrderMagicNumber() != MagicNumber
            or OrderSymbol() != Symbol(): пропустить
                                     оставить чужие и ручные

      RefreshRates()
      price := MarketInfo(OrderSymbol(),
                          MODE_BID для OP_BUY, MODE_ASK для OP_SELL)
      if price <= 0:
         errors := errors + 1
         записать в журнал: нет котировки, GetLastError()
         перейти к следующей

      ticket := OrderTicket()
      volume := OrderLots()

      if DryRun:
         записать в журнал: ЗАКРЫЛ БЫ ордер, volume, price
         перейти к следующей         на сервер ничего не отправляется

      if not OrderClose(ticket, volume, price, MaxDeviation):
         errors := errors + 1
         записать в журнал: номер ордера, GetLastError()

   return errors

ПОДТВЕРЖДЕНИЕ - CountOwnPositions()

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

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

Одна деталь выглядит хорошей практикой, но ею не является. RefreshRates() возвращает логическое значение, но считать false ошибкой было бы неверно. Документация MQL4 говорит, что true возвращается при обновлении данных, и сразу объясняет: «единственная причина невозможности обновить данные — то, что это уже текущие данные клиентского терминала» [17]. Следовательно, false означает, что данные и так актуальны. Проверить нужно другое: положительна ли прочитанная после обновления цена. Нулевая цена — неудачное чтение спецификации или отсутствие котировки; запрос закрытия по ней закончится отказом.

Остаётся параметр отклонения, и оговорка здесь важнее значения. MaxDeviation — не универсальный предел цены исполнения. Он относится только к Instant Execution и внутри лимита означает исполнение по новой цене без уведомления. Лишь за пределами сервер возвращает цены для подтверждения. Механизм и исходные цитаты разобраны в разделе о задержке, а подробнее — в статье о платформах; здесь важно одно последствие. Величины порядка трёх пунктов, то есть 0,3 пипса на пятизнаковом счёте, бездумно копируют из примеров. Они выбраны для спокойного входа, а не аварийного выхода. Аварийное закрытие по определению происходит при широком спреде и проскальзывании. С узким пределом сервер вместо исполнения вернёт новые цены; программа без обработки реквотов останется с позицией и ошибкой. Поэтому отклонение для аварийного выхода должно быть заметно свободнее, чем для входа. Это нужно назвать точно: не усиление защиты, а предварительное согласие закрыться по худшей цене, чем при решении, ради большей вероятности прохождения запроса. Выбор между худшей ценой и открытой экспозицией, а не безопасностью и риском. Если символ работает в Market Execution, поля нет: цену задаёт брокер, отправка — согласие заранее, остаётся запись отклонения цены закрытия от цены решения.

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

Три слоя защиты

Одного недостаточно: каждый отказывает в своём сценарии.

1. Код робота. Описанные лимиты. Работают только при запущенной программе
2. Сервер брокера. Уровни SL и TP позиции, margin call и автоматическое закрытие на stop-out. Работают независимо от вашей среды. Поэтому у каждой позиции системы должна быть защита на этой стороне, а не только в переменной
3. Человек. Уведомления на телефон об открытии, закрытии, остановке и ошибках плюс проверенная возможность закрыть позицию вручную из мобильного приложения брокера. Последний слой при отказе первых двух

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

Защиту тоже нужно тестировать

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

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

Готовая система стороннего автора

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

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