Багосимулятор в алготрейдинге

Сегодня у нас были очередные пожарные учения. К слову сказать, это уже третьи за год. Уже выработался набор правил, что нужно сделать в терминале/ах, прежде чем покинуть помещение.
Вообще это интересная тема. Судя по тому, что у нас иногда происходит в стаканах, не все алгоритмисты посвящают этому большое внимание. Говорю я сейчас про разработанный набор инструкций при возникших исключительных ситуаций в вашем алго. Если алготрейдер давно уже на рынке, то наверное знает, а если не знает, то поделюсь своим мнением, что набор стандартных типичных багов в алго несколько ограничен. А ситуаций, возникающих в следствии этих багов, еще меньше, но они есть и скорее всего и будут. Ну на вскидку, наверное можно вспомнить 8-10 типичных критических ситуаций, к которым может привезти исключительная ситуация.
Я в свое время начал их конспектировать, по мере получения опыта. Потом записывать процедуры поведения, шаг за шагом. А потом их еще проговаривать периодически, чтобы отложилась в памяти. Все это может вылиться в некий тестовый стенд, на котором можно будет оттачивать мастерство поведения при критических ситуациях. Это очень полезно. Это как пилоты оттачивают свое мастерство на реальных симуляторах.
Кто узнал себя, всем привет, кто не узнал, прошу в комментарии поглагольствовать, как нужно писать правильный код =)))

баги ошибки алготрейдинг

Андрей К

Калиниград

488

9 675

с 24 декабря 2013

46 Комментариев

Тарас Громницкий
27 ноября 2018, 16:57
Правильный код — это модульная, низкосвязанная конструкция.
Использующая паттерны и реализующая набор структур, описывающих бизнес-сущности.
Пишется, тестируется и наращивается постепенно.
+3
- Андрей К
  27 ноября 2018, 17:01
  Тарас Громницкий, я не спорю. Но вы еще наверное не сталкивались с ситуациями, обработка которых не заложена в ваших кодах.
  Такие ситуации обычно описаны в документациях биржи, где то глубоко и разорвано и разраб о них по началу никогда не задумывается. Только когда это уже все пройдет в бою
  0
  - Тарас Громницкий
    27 ноября 2018, 17:07
    Андрей К, ошибки, которые не обрабатываются в коде отлавливаются при помощи исключений.
    Стек и дополнительная информация пишется в лог.
    Таким образом место возникновения и примерная причина бага становится ясна.
    Далее либо пытаемся воспроизвести ошибку, либо ожидаем её нового появления и собираем больше информации.
    Такими образом любая ошибка рано или поздно оказывается локализована и устранена.
    0
    - _sg_
      27 ноября 2018, 23:18
      Тарас Громницкий,
      «ошибки, которые не обрабатываются в коде» — такого вообще быть не должно.
      На первых порах везде где только можно необходимы try-catch и логирование.
      В любой программерской команде ЕДИНАЯ система расстановки try-catch должна существовать. Без этого никак.
      Если такой системы нет, то со временем ее необходимо разработать
      
      На собеседовании при найме на работу я всегда задавал самый главный вопрос не про классы, а как и где соискатель ставит try-catch. И наблюдал растерянные лица у людей с красными дипломами.
      К сожалению этому не учат, а зря.
      0
      - Тарас Громницкий
        28 ноября 2018, 08:48
        _sg_, такое есть почти всегда.
        Это просто неизбежно.
        И чем больше проект, тем больше таких мест.
        Слишком часто лепить try catch — это не самая лучшая идея.
        Даже по системе.
        Достаточно сделать глобальный обработчик в точке запуска программы.
        Он отловит любое исключение.
        0
        _sg_
        28 ноября 2018, 09:51
        Тарас Громницкий,
        я Вам говорю про правильные технологии программирования, а Вы мне про некоторый тактический прием, который, как бы, все решит.
        Почитайте у Microsoft статьи на эту тему. Где, как и когда применять try catch. Библиотеки на эту тему есть.
        Если Вы хотите писать Приложения уровня Enerprise, которые работают 24/7, то придется эти технологии применять.
        Мои Приложения уровня Enterprise могут работать Годами без перезапуска и это благодаря выработанной временем технологии применения Try catch.
        0
        Тарас Громницкий
        28 ноября 2018, 10:06
        _sg_, пусть так.
        Простите, но про «годы без перезапуска» не верю.
        0
        Андрей К
        28 ноября 2018, 10:10
        _sg_, кстати, try catch не очень применим для скоростных алго. Правда речь про c++. уж лучше писать изначально так, чтобы их не было. В таких алго основные ошибки — это работа с памятью. Так что надо на это упор сделать.
        0
        _sg_
        28 ноября 2018, 10:23
        Андрей К,
        уж лучше писать изначально так, чтобы их не было
        
        не получиться. Потому, что Вы в своих алго-проектах работаете с внешними библиотеками ( коннекторами итд) сторонних разработчиков. Что и как внутри этих библиотек Вы не знаете по определению. Как они ведут себя в критических ситуациях? — Правильно. Генерят Exception. И самая распространенная ошибка начинающих: НЕ СТАВИТЬ try catch при вызове методов библиотек сторонних разработчиков. Это только один из примеров.
        0
        Андрей К
        28 ноября 2018, 10:30
        _sg_, в таких алго как правило не использует ничего чужого. Потому что не актуально. За исключением библиотек для специфичного железа.
        есть статья у америкосов, try catch изнутри. Там показывается и рассказывает как он устроен. Что сильно взаимодействует с ОС. А это в таких алго вообще категорически запрещено. Во первых портится постоянно боевой кеш, во вторых никак не получается точно прогнозировать память. В связи с этим скорость исполнения алго выходит из под контроля и разброс результатов во времени очень сильный, а это недопустимо.
        
        0
        _sg_
        28 ноября 2018, 10:34
        Андрей К,
        незначительное замедление работы Приложения гораздо лучше, чем Приложение, которое падает.
        0
        Андрей К
        28 ноября 2018, 10:38
        _sg_,
        незначительное замедление работы Приложения гораздо лучше, чем Приложение, которое падает.
        несомненно в быту да.
        Но зачастую, тогда просто деньги не заработаешь. Раньше пользователь uralpro часто писал о результатах. Он открыто говорил, что разброс скорости у них лежит в диапазоне 2-8 мксек. Я с ним болтал немного, получилось, что все результаты тяготеют чаще к 8, чем к 2. В таких алго это совершенно не нормально. На его примере, нормально, это когда скорость лежит в дипазоне 2-2.2мксек в 90% трейдов. Для этого и приходится так все кастомизировать.
        0
        _sg_
        28 ноября 2018, 10:48
        Андрей К,
        много софтверных проектов полегло в погоне за скоростью, игнорируя устойчивость и надежность софта.
        Как правило, авторы после этого говорят: «Хотели как лучше, побыстрее». А получилось как всегда.
        0
        Андрей К
        28 ноября 2018, 10:52
        _sg_,
        много софтверных проектов полегло в погоне за скоростью, игнорируя устойчивость и надежность софта
        мой топик именно про это =)) Что у нас на рынке периодически кто то прилег. И на этот случай, нужно отрабатывать технику чрезвычайных ситуаций =)
        0
        _sg_
        28 ноября 2018, 11:04
        Андрей К,
        Знакомый лозунг: «Пока гром не грянет ...».
        
        Надо изначально учиться писать надежное ПО и выпускать надежную продукцию, и тогда не будет необходимости «отрабатывать технику чрезвычайных ситуаций»
        0
        Андрей К
        28 ноября 2018, 11:06
        _sg_,
        теперь я уже не знаю что вам ответить =). Вы не занимались скоростями, а у меня не получается до вас донести с чем приходится сталкиваться. Во всем остальном я с вами согласен
        0
Antishort
27 ноября 2018, 17:10
У меня был один баг. Набор позиции был довольно сложный, одновременно выставлялись стопы. Робот не всегда вовремя получал данные от сервера об уже выставленных стопах и периодически на одной цене мог поставить 5-6 стопов. В результате позиция не закрывалась, а переворачивалась, иногда удваиваясь. В результате просмотра сделок создавалось впечатление, что торговал какой-то идиот во все стороны. Баг всплывал не всегда, а только периодически, поэтому отловить и вытравить заразу заняло какое-то время.

+1
- Тарас Громницкий
  27 ноября 2018, 17:12
  Antishort, всё верно.
  Чем логичнее/проще структура программы, тем легче предположить место ошибки.
  Особенно если есть надёжные модули, которые можно исключить из подозрения.
  0
- Андрей К
  27 ноября 2018, 17:18
  Antishort,
  У меня был один баг. Набор позиции был довольно сложный, одновременно выставлялись стопы.
  ну да, баги кода это отдельная каста геморроя =)). Кстати на этот счет я тоже отработал набор инструкций как нужно действовать.
  
  Но писал я чуть не об этом. Иногда могут возникнуть такие ситуации, о которых даже не подозреваешь. Ну например биржа пришлет по определенным канал связи не ту котировку. Из последнего что помню, примерно с год назад, биржа решили перезагрузить часть серверов во время торгов, к слову сказать, именно эти серваки они вообще никогда не перезагружали. В итоге на рынке целый ряд алго нахвтали ошибок и начали вываливать огромный объемы в стаканы, неся очень не малые убытки. На этот случай у трейдера счет идет на секунды, чтобы он предпринял самые правильные действия. И репетировать их, я считаю необходимо. Либо хотя бы разработать алгоритм действий
  0
  - Тарас Громницкий
    27 ноября 2018, 17:23
    Андрей К, а как в реальном времени понять, что котировка кривая ?
    Для этого как минимум нужно её с чем-то сравнивать и следить за каждым тиком.
    Геморой короче.
    Тут скорее робот откроет неправильно позу, получит стоп и тогда уже трейдер обратит внимание на ситуацию.
    А косяк будет ясен позже.
    Когда собранные котировки прошлого дня автоматически сравнят с историческими данными.
    +1
    - Андрей К
      27 ноября 2018, 17:27
      Тарас Громницкий,
      а как можно в реальном времени понять, что котировка кривая
      в реальном очень сложно. Если только отработать самый известный и частый баг — это биржа присылает бид и аск поменянный местами. Это самая главная причина вываливания объемов в стакан.
      поэтому надо уметь реагировать. Такая засада может не вылазить несколько лет у начинающих алгоритмистов, а потом как вылезет, мало не покажется.
      
      +2
      - Тарас Громницкий
        27 ноября 2018, 17:31
        Андрей К, иными словами невозможно.
        Нет чётких критериев кривой котировки.
        0
        Андрей К
        27 ноября 2018, 17:33
        Тарас Громницкий, ага, именно так
        0
      - Cheshire Cat
        27 ноября 2018, 22:19
        Андрей К, а как это бид и аск поменянные местами? От биржи идет приходит же заявка с флагом покупка/продажа. Имеется ввиду неправильный флаг?
        0
        Андрей К
        27 ноября 2018, 23:57
        Cheshire Cat, ага, примерно так и есть. Но программистам, торгующим из под терминала, других я тут практически не заметил, это не грозит. Львиную долю решения багов берут на себя терминалы, они не доходят до программистов.
        0
- Alpinist573
  27 ноября 2018, 18:06
  Antishort, и как вылечили?
  
  квик иногда может по несколько минут не «отдавать» таблицы или вообще лечь на часок другой
  0
Jame Bonds
27 ноября 2018, 17:26
На это можно целую книгу написать.
Пока нет времени только отрывочные мысли.
1) Учиться, учиться и учиться.
2) Везде и всюду проверять на ошибки.
3) Тотально логгировать все события, вплоть до каждого изменения цены, с указанием точного времени.
4) Вести учет всех сбоев, регулярно осуществлять анализ сбоев и модификацию кода для предотвращения их повторения.
5) Иметь в коде защиту от критических рыночных событий.
6) Не писать на Lua…
+1
- Тарас Громницкий
  27 ноября 2018, 17:28
  Jame Bonds, главное не усложнять, а то код для поиска ошибок будет сам источником ошибок.
  Вы пропустили один важный пункт:
  7) Не нанимать криворуких студентов.
  +2
  - Jame Bonds
    27 ноября 2018, 17:37
    Тарас Громницкий, тогда уж:
    7а) все делать самому.
    0
    - Тарас Громницкий
      27 ноября 2018, 17:42
      Jame Bonds, к сожалению это работает только в мелких проектах.
      Что-то более серьёзное в одно лицо не потянуть.
      0
- Alpinist573
  27 ноября 2018, 18:09
  Jame Bonds, чем луа-то не угодил?
  
  позволяет вполне надежно исполнять и писанины не так много, можно даже со слабым скилом навертеть вполне работоспособного робота
  0
  - Jame Bonds
    27 ноября 2018, 18:37
    Alpinist573,
    — отсутствие проверок на элементарные опечатки;
    — возможность вызова необъявленных функций (мгновенное прерывание выполняемой процедуры) и использования необъявленных переменных (нет ошибки даже при выполнении);
    — отсутствие симулятора, на котором можно выявить глюки порожденные пунктами выше (это было бы не так критично, если бы не пункты выше);
    — низкая скорость работы.
    Резюме: можно писать только относительно простых роботов, при условии их полной отладки в присутствии оператора в реальном времени (то есть медленно).
    +1
    - Igr
      12 марта 2019, 15:59
      Jame Bonds,
      "— возможность вызова необъявленных функций (мгновенное прерывание выполняемой процедуры)"
      не понял в чём тут проблема, ну можно не объявлять функции и что?
      
      низкая скорость работы именно программы написанной на луа?
      
      0
      - Андрей К
        12 марта 2019, 16:08
        Igr, наверное речь про то, что если вызвать необъявленную функцию, скрипт посыпится.
        Был бы компилятор, он бы выдал ошибку на этом моменте и не запустил бы скрипт.
        0
        Igr
        12 марта 2019, 16:11
        Андрей К, не, в луа не нужно объявлять функцию
        
        про компилятор то понятно, из-за этого сколько раз застревал пока не находил ошибку, например скобки не поставил)) при том скобки не поставлены в одном месте, а квик указывает на ошибку строкой ниже
        0
Gillan
27 ноября 2018, 18:35
Привет, Андрей!
Сегодня у нас были очередные пожарные учения.… что нужно сделать в терминале/ах, прежде чем покинуть помещение.
А почему вы не запускаете терминалы на выделенных серверах в датацентре? Это же очевидно надежнее, к тому же, как я понял у вас алготрейдинг, т.е. просто поглядывать как работает надо?

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

Отдельный вопрос: какие терминалы/приводы/ПО вы используете? Какие нарекания по надежности? Вот тут пишут про Quik, Lua, есть еще целое коммьюнити разрабов под MetaTrader. А у вас что?
0
- Андрей К
  27 ноября 2018, 18:40
  Gillan,
  А почему вы не запускаете терминалы на выделенных серверах в датацентре?
  Так и есть. Только без присмотра определенные алгоритмы оставлять нельзя. Поэтому часть выключается, часть остается само работать. Только потом на пожарный выход =).
  0
- Андрей К
  27 ноября 2018, 18:54
  Gillan,
  А напиши, интересно почитать, на что натыкаются опытные трейдеры
  самое самое основное, это:
  1) биржа в силу каких то действий прислала кривые котировки
  2) код робота из за ошибки не правильно оценил котировки/объемы
  только триггером к подобным ситуациям может быть много чего: сбой биржи, планки, какие то плановые работы биржи, какие то нюансы работы биржи, о которых просто не прочитал и тд… когда алгоритмы имеют не правильные представления о текущих котировках могут пойти в разнос сильнейшей и лить как из ведра. Периодически это происходит у нас на forts, это видно.
  +2
cfree0185
27 ноября 2018, 19:17
Эмулировать работу алгоритмов в рандомных условиях — создать имитационное окружение и подавать с него на вход алго любые комбинации и состояния подключения. Можно еще задать проверку состояния робота после совершения действий — это фактически тесты.
+1
- Тарас Громницкий
  27 ноября 2018, 19:34
  cfree0185, здорово, но сделать подобное на порядок сложнее, чем написать робота.
  +3
bwc
21 марта 2019, 23:10
а если так?
есть торговый алгоритм — сложный, асинхронный, с заточкой на экстремальное быстродействие
рядом — поток с контролирующим простым алгоритмом, который проверяет некоторые метрики торгового.
+1