сотрудничества с читателями.
Эта статья сугубо техническая и предназначена в первую очередь для трейдеров-управляющих, но может быть интересна также и инвесторам, интересующимся каким образом всё устроено на той стороне инвестиционного процесса, которая для инвестора является, как правило, чёрным ящиком.
Исходя из моего опыта работы, сразу могу сказать, что при управлении большими средствами управляющему, помимо разработки самой торговой системы, необходимо решить ещё целую массу сопутствующих инфраструктурных и программных проблем, о которых инвесторы имеют смутное представление, или даже никогда не задумывались об их существовании. На пути получения ожидаемого результата от торговой стратегии стоят, кроме торгово-рыночных, ещё и так называемые операционные проблемы, требующие своего обязательного решения. В некоторых случаях именно операционные проблемы могут вносить весьма существенные коррективы в торговый результат по некоторым сделкам, что может привести к неожиданно большому расхождению итогов торговли. Хотя расхождения случаются не всегда только в отрицательную сторону, тем не менее, при работе с деньгами все заинтересованы в получении заранее ожидаемом результате от имеющейся торговой системы. По мере роста средств в управлении стоимость отдельной ещё не решённой управляющим операционной проблемы растёт соответствующим образом.
Постановка задачи
В ходе своей деятельности успешным управляющим, как правило, приходится увеличивать количество управляемых счетов. Например, у управляющих возникают новые торговые идеи, которые нужно проверить на новом счёте, чтобы не испортить уже годами наработанную статистику старых счетов. Также инвесторы и управляющие компании могут попросить взять в управление счета, открытые ими на выбранных торговых площадках. Или же размер сумм в управлении на старом счёте уже достиг определённого предела, после которого брокер отказывается давать кредитное плечо более 1:25, что накладывает жёсткие ограничения по лотности открытых позиций и высокорисковые счета уже не могут работать в точном соответствии с торговым алгоритмом. Одним словом существует масса ситуаций, когда установка и настройка нового терминала МТ4 является единственно возможным решением поставленных задач. И как результат количество обслуживаемых терминалов МТ4 со временем начинает исчисляться десятками, накладывая на управляющего определённые требования по их операционному обслуживанию. Например рабочий стол торгового сервера с 32 терминалами МТ4 может выглядеть вот так:
Конечно же, некоторые умники, присутствующие, например, на форуме Альпари, могут заявить, что, дескать, “нужно сразу писать правильный код советника”, “вы просто не умеете программировать робастных советников” или же тому подобный бред, приходящий в голову первым при обсуждении внешних (по отношению к торговому советнику) систем мониторинга. Но я на основании своего 4-х летнего опыта управления инвесторскими средствами могу заявить, что данные умники КАТЕГОРИЧЕСКИ НЕПРАВЫ! И в моей практике было достаточно много случаев, когда какие-то сбои и непредвиденные ситуации могли бы были быть замечены заблаговременно автоматически благодаря разработанной мониторинговой системе. Как говорят в армии, воинский устав написан кровью, ну а здесь моя мониторинговая система была написана по результатам ежедневной практики наблюдения за работой терминалов и разрешения множества нештатных ситуаций, регулярно возникающих на счетах по разным причинам.
И нельзя сказать сейчас, что данная работа полностью завершена и в будущем ничего такого нового нештатного не появится, что не потребовало бы доработки предлагаемой ниже мониторинговой системы. Поэтому приведённое ниже техническое решение является лишь только текущей версией системы мониторинга, которой пользуюсь в настоящий момент я. Но с течением времени в неё будут вноситься и другие дополнительные параметры для мониторинга, расширяя список проверок. Поскольку каждый управляющий имеет свои торговые системы, то предлагаемый код будет перерабатываться каждым управляющим в соответствии с его видением необходимости мониторинга того, или иного параметра его торговой системы, а также каких-либо иных системных параметров типа загрузки процессора, наличия интернета и т.д. Главная цель данной статьи — это продемонстрировать возможное техническое решение задачи мониторинга. И оно никоим образом не претендует на абсолютную грамотность или оптимальность самого подхода, поскольку я не являюсь каким-то профессиональным программистом и многие вещи грамотной реализации программных продуктов просто никогда не изучал. Поэтому это решение “As it is” без каких-либо гарантий того, что оно полностью подойдёт управляющим для решения именно их задач по мониторингу счетов, находящихся в управлении. В общем, представляю вниманию трейдерской публики решение задачи мониторинга, которое удалось реализовать мне в рамках имеющегося у меня опыта программирования.
Блок-схема мониторинговой системы и примеры информационных сообщений
На каждый терминал выделено по одной строке, содержащей время последней проверки, параметры ближайших ордеров и название счёта. Если все мониторинговые проверки прошли успешно, то строка имеет краткую запись зелёным шрифтом. Если же на счёте проблемы, то сразу же вываливается более подробный мониторинг красным шрифтом, где отображено какая проверка была провалена (смотрите статус false). Теперь я из любого места с мобильного телефона проверяю состояние терминалов за 5 секунд максимум. Прикиньте сами, сколько вам потребуется времени для просмотра по диагонали вот этой вот страницы, если большую часть времени она вся зелёная?
В этом расширенном информационном разделе есть ссылка на скриншот экрана мониторинга в терминале. Ниже приведены скриншоты при нормальном прохождении проверок и при провале одной из проверок.
Сразу отмечу, что зелёный и красный прямоугольник на скриншотах к самой торговле никакого отношения не имеют. Он остался от прошлого времени, когда я все проверки состояния терминалов только начинал автоматизировать, и просматривал каждый такой экран персонально пару раз в день утром и вечером. Большое цветовое пятно на экране просто ускоряет проверки, поскольку требует лишь только бокового зрения. Цвет квадрата говорит о двух возможных состояниях — пройдены ли все проверки успешно или нет. Сам размер прямоугольника неважен. Главное что он достаточного размера, чтобы сразу понять ситуацию с мониторингом при беглом взгляде на экран терминала без чтения статуса FINAL_CHECK_RESULT, на основании которого выбирается цвет прямоугольника.
Рассмотрим более подробно что я вижу в своих автоматических проверках. В состоянии ОК (зелёная строка) я вижу время последней проверки. Проверка проходит раз в час. Далее парочку информационных параметров, отвечающих за ближайшие ордера. И завершает строку название ПАММ/МАМ/личного счёта.
По информационным параметрам ордеров я отслеживаю насколько на каждом из терминалов отложки разошлись у разных брокеров, и могу при необходимости вручную поправить глобальные переменные, чтобы параметры ордеров везде совпадали с флагманским счётом. Отличие в информационных параметрах ордеров на разных счетах может быть обусловлено различием в котировках у разных брокеров. Например, причиной тому может быть порванная история котировок из-за проблем на стороне сервера брокера. Также в начале недели эти параметры могут различаться из-за того, что на AlfaForex торговля на открытии рынка начинается на 1 час раньше, чем в среднем у остальных, а на NPBFX наоборот на 1 час позже. А поскольку для торгового эксперта входной информацией являются котировки, то он может принимать разные торговые решения. И мониторинговая система как раз легко помогает отследить такие расхождения и своевременно вмешаться в процесс торговли. Например, подкачать котировки для заполнения разрыва, или просто вручную скорректировать некоторые глобальные переменные терминала, если всё дело только в разнице времени начала/окончания торговли у разных брокеров.
В состоянии FAILED я вижу результаты всех проверок, которые этот FAILED сформировали (красный шрифт), а именно название счёта, название версии мониторингового советника, время последней автоматической проверки, название версии торгового советника, разрешение автоторговли в терминале, разрешение торговли в самом советнике, подключение терминала к брокеру, разрешение торговли экспертами со стороны брокера, разрешение торговли для счёта со стороны брокера, признак отсутствия в последних 22 строчках логов сообщений об ошибках, запускался ли прогон советника в последние 7 минут, проверка риска/лотности ордеров, запускалась ли функция анализа ошибок в последние сутки, параметры для синхронизации ордеров по разным брокерам, и в конце ФИНАЛЬНЫЙ РЕЗУЛЬТАТ проведённых выше проверок.
В целом было потрачено огромное количество времени, но зато теперь весь цикл проверки состояния всех терминалов занимает менее 5 секунд вместо 10 минут месяцем ранее. А это, на мой взгляд, неимоверно КРУТО, поскольку создана легко масштабируемая система мониторинга терминалов МТ4. И теперь удвоение имеющегося количества терминалов после первоначальных затрат времени на конфигурацию всей системы увеличивает время периодических проверок через веб-сайт совсем незначительно по сравнению с текущими 5 секундами времени.
Программная реализация
- Время запуска мониторинговой проверки;
- Версия релиза торгового советника;
- Разрешение на авторторговлю в терминале;
- Наличие подключения к брокеру;
- Разрешение автоторговли на стороне брокера;
- Наличие в логах торгового советника подстроки “EM:”, говорящей об ошибках в работе торгового эксперта;
- Время последнего прогона кода торгового советника (оно должно быть не позже 14 минут назад);
- Результат проверки объёма отложенных ордеров (осуществляется торговым советником с занесением результата проверки в глобальные переменные);
- Проверка времени последнего запуска функции расшифровки ошибок торговых операций (оно должно быть более суток назад для прохождения проверки);
- Финальный результат всех вышеперечисленных проверок.
Заключение
Пару слов от Домоседа
Я так же создаю мониторинговую систему следящую за управляемыми мной торговыми счетами основываясь на решениях Андрея описываемых в этой статье.