Детектор аномальных объёмов — анализируем спрос и предложение с помощью платформы TKSBrokerAPI

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

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

Следующий скриншот иллюстрирует стакан цен с объёмами предложений продавцов и покупателей, которые трейдер визуально может принять за аномалии:

Но как же их определять автоматически?

Как сделать +16% на бирже за 2 часа? Помогут роботы!

Всем привет! Недавно я упоминал про REST API от Тинькофф Инвестиции и про платформу ⚙️TKSBrokerAPI на Python, для упрощения автоматизации работы с биржей через брокера Тинькофф. Сам я тоже использую эту платформу: для получения кастомных отчётов и автоматизации трейд-роботов и различных ботов-оповещалок.

На этой неделе очень порадовал $KROT, который последние дни невероятно волатилен (в том числе из-за новостей об ограничениях биржи на бумаги третьего эшелона), но зато хорошо подходит для тестов, спасибо ему за это! А также порадовал алгоритм моего нового торгового робота в основе которого используется ⚙️TKSBrokerAPI: впервые удалось протестировать его на сильных движениях и заметить в телеметрии, что он достаточно неплохо поймал второй откат на пятиминутках, самостоятельно вошёл в позицию, дождался хорошей возможности и вышел в плюс (изобразил это на графике ниже).

На одном лоте получилось более +16% прибыли, 280 рублей разницы в цене и 2800 руб. профита 🙂 Неплохой результат, так как до этого рынок был, в основном, спокойный и удавалось поймать роботом не более +0.5-1.5% за сделку. Поэтому я долгое время не знал, как он себя поведёт при сильных движениях, сможет ли дождаться большей прибыли и устоит ли на волатильном рынке. Сейчас убедился на тестовом счёте, что сможет 😊

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

• 10:25 UTC "message": "BUY-стоп выставлен по цене первого покупателя: [1695 rub], лотов: [1]"
• 12:04 UTC "message": "SELL-маркет исполнен по [1975 rub], ср. [1695 rub], лотов [1], профит 16.52%"

Конечно же, любому роботу нужна (авто-)оптимизация, потому что далее через пару часов, если посмотреть график $KROT за 9.02.2023, можно было выйти ещё рублей на 200 выше, но робот этого уже не дождался.

Подписывайтесь на меня в Пульсе (профиль: TimurGilmullin), буду рассказывать там про автоматизацию на бирже и разработку торговых роботов.

Если вы хотите упростить свои рутинные операции на бирже — закажите автоматизацию у меня, пишите, обсудим вашу задачу и чем я могу помочь. Контакт в Телеграм: @tgilmullin.

TKSBrokerAPI Trade Automation Platform: release-1.5.120

Опубликован очередной релиз платформы TKSBrokerAPI: v1.5.120. Рассмотрим основные изменения.

Release notes (in english)
Issues included in the release

PyPI: 1.5.120 (2022-11-21)

Дайджест

В новой версии TKSBrokerAPI в отчёте о портфеле пользователя появилась новая секция с календарём платежей по облигациям (сам календарь, возможность обогащения облигаций данными и множество других интересных фич появились в предыдущей стабильной версии v1.4.90, о них я писал в прошлом посте). 

TKSBrokerAPI: демонстрация некоторых возможностей торговли на бирже через Python API

Поддержать проект: https://yoomoney.ru/to/410015019068268

В прошлой статье я рассказал про опенсорс разработку — платформу TKSBrokerAPI — это Python API для работы с Tinkoff Open API через REST протокол. Также этим инструментом можно пользоваться из консоли или встраивать его в CI/CD-системы, для автоматизации рутинных операций на бирже, через брокера Тинькофф Инвестиции.

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

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

Схема разработки с помощью TKSBrokerAPI очень простая:

1. Вы придумываете гениальный торговый алгоритм.
2. Записываете его пошагово в виде некоторого плана или торгового сценария.
3. Автоматизируете сценарий на Python при помощи TKSBrokerAPI.
4. TKSBrokerAPI берёт на себя всю работу с инфраструктурой брокера Тинькофф Инвестиции.
5. Профит!

Как работает команда DevOps в Positive Technologies

Всем привет! Меня зовут Тимур Гильмуллин, я работаю в отделе технологий и процессов разработки Positive Technologies. Внутри компании нас неформально называют DevOps-отделом. Мы занимаемся автоматизацией внутренних процессов и помогаем разработчикам и тестировщикам. В прошлой статье я уже писал, как выстроен карьерный рост у инженеров, а сегодня хочу рассказать про «внутреннюю кухню» — о том, что делают DevOps-инженеры у нас в компании. Вы узнаете, что лежит в основе идей DevOps, какие плюсы дает бизнесу работа по принципам DevOps и как при этом изменяется процесс разработки.

Личный опыт: карьерный рост в DevOps-отделе компании разработчика ПО

Всем привет! Меня зовут Тимур Гильмуллин, я заместитель руководителя отдела технологий и процессов разработки в компании Positive Technologies. Сегодня расскажу, как я попал в профессию, как в нашем отделе мы видим карьеру DevOps-инженера, что такое карта компетенций и как она помогает обеспечивать рост сотрудников.

Статья написана по материалам рассказа для митапа (2020-01-20), на который нас любезно пригласили коллеги из Hays для обмена опытом (можно посмотреть презентацию и текст).

Управление хаосом: наводим порядок с помощью технологической карты

Всем привет! На Хабре вышла наша совместная, с коллегой из DevOps (Сашей Паздниковым), статья "Управление хаосом: наводим порядок с помощью технологической карты".

Мы — инженеры-автоматизаторы из компании Positive Technologies и занимаемся сопровождением разработки: поддерживаем весь сборочный конвейер от коммита строчки кода разработчиками до публикации готовых продуктов и лицензий на серверах обновлений. Неформально нас называют DevOps-инженеры. Мы хотим рассказать вам про технологические этапы процесса производства ПО, как мы их видим и как классифицируем.

x

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

Подробнее по ссылке.

Тестирование в общем сборочном конвейере: решение организационных проблем

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

Статья может быть полезна тест-архитекторам, руководителям команд и отделов QC и QA, CI-инженерам, а также всем, кто сталкивался с проблемами внедрения процесса тестирования в разработку ПО.

AutoIt: автоматизация работы с интерфейсом Windows программ

AutoIt — это бесплатное приложение для автоматизации работы с Windows UI. Его можно использовать для имитации действий пользователя в ОС Windows, открытия и закрытия окон, перемещения мыши, нажатия кнопок клавиатуры и мыши, получения статусов элементов окон, открытия программ и управления ими. 

Моделирование производственных процессов в ИТ-компании

Моделирование производственных процессов — это очень сложная и кропотливая работа: нужно собирать, анализировать и обрабатывать множество данных по различным отделам и производственным цепочкам. В статье я расскажу вам о моделировании процесса производства программных продуктов на примере компании Positive Technologies, где я работаю. Тема достаточно сложная и обширная, тем не менее я попытаюсь доступным языком объяснить, из каких крупных этапов состоит разработка и представлю так называемую технологическую карту производственных процессов. Надеюсь, что после этого рассказа у вас сформируется достаточно общее представление о производстве программных продуктов и о роли DevOps в обеспечении непрерывной работы конвейера по производству и доставке продуктов заказчикам.

Статья может быть полезна продуктовым менеджерам, руководителям команд и отделов, а также всем, кому интересно как устроен типовой процесс разработки программных продуктов, как выглядит технологическая карта и основные этапы Continuous Integration и Continuous Delivery.

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

Как мы в Positive Technologies внедряли идеи DevOps

Всем привет! Недавно на Хабре опубликовали мою статью "Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps" и интервью в журнале Системный администратор "Тимур Гильмуллин: «DevOps в современных ИТ уже давно выделился в самостоятельную инженерную дисциплину»".

В этой статье расскажу, как мы в Positive Technologies создавали и развивали отдел автоматизации разработки, внедряли идеи DevOps в практику разработки и какие инструменты и технологии для этого использовали, а также как организовали процессы CI/CD. В том числе поделюсь успехами и планами на будущее.

Митап Op!DevOps! 2017

Открытое сообщество
DevOps-разработчиков
Open DevOps Community

Митап Op!DevOps! 2017 прошёл 21 октября в московском офисе компании Positive Technologies. Мы провели приятный субботний вечер и в узком, почти семейном кругу, обсудили проблемы автоматизации, которые удалось решить нашей DevOps-команде за прошедший год. Кроме того, мы рассмотрели некоторые технологии и инструменты, поделились планами развития DevOps в нашей компании.

Немного о докладах, видео и фоточки с митапа ниже.

Митап Op!DevOps! 2016

Митап Op!DevOps! прошёл 7 октября 2016 г. в Москве. На нём в формате фаст-трека были озвучены проблемы в области автоматизации разработки и тестирования, а также предложены методы и средства их решения.

Подробнее по ссылке: https://habrahabr.ru/company/pt/blog/310584/

Миссия выполнима: как развить DevOps в компании со множеством проектов

Открыта регистрация на митап Op!DevOps! 

Оригинал статьи на habrahabr: https://habrahabr.ru/company/pt/blog/310584/ (ссылка на регистрацию внизу статьи)

О пользе внедрения DevOps уже написано множество статей на Хабре и других ИТ-ресурсах, и она не ставится под сомнение. Это понятно: творческому беспорядку с подчас неочевидными зонами ответственности «обычной» разработки, где разные люди отвечают за код, бранчи, тестовые стенды, сборку и деплой и не очень-то хотят лезть на «поляну» коллег, противопоставляется высокий уровень организации.

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

Но мало просто захотеть работать «правильно», нужно еще каким-то образом к этому прийти. А здесь все совсем не так просто.

TeamCity TestRuns on Rails: распараллеливаем тест-раны и агрегируем статистику

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

Использование TeamCity в качестве системы управления запуском функциональных авто-тестов

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

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

Автоматизация нагрузочного тестирования при помощи инструмента Яндекс.Танк

В ходе тестирования некоторых продуктов компании Positive Technologies наша команда тестировщиков-автоматизаторов столкнулась с необходимостью проведения быстрых стресс-тестов для одного http веб-сервиса. Такие тесты должны были быть простыми и быстрыми в разработке, не требовательными к аппаратным ресурсам, должны давать значительную нагрузку однотипными http-запросами, предоставлять статистические данные для анализа системы под нагрузкой.

Для их реализации мы исследовали и опробовали некоторое количество инструментов, среди которых был и Apache JMeter, о котором было рассказано ранее, и даже сделанный нами самодельный инструмент LogSniper, написанный на Python, который выполнял реплей заранее подготовленных серверных логов с http-запросами на цель.

Использование JMeter-а мы отклонили из-за значительной сложности подготовки и проведения тестов, высоких требований к производительности нагрузочного стенда и довольно малых мощностей нагрузки при этом, хотя это и компенсировалось высокой информативностью показателей собираемой статистики. А LogSniper был отклонён из-за малой мощности генерируемой нагрузки и даже простота подготовки нагрузочных http-пакетов не могла стать большим преимуществом. Другие инструменты также были отклонены по тем или иным причинам.

В итоге мы с моим коллегой Олегом Каштановым остановились на инструменте Яндекс.Танк (yandex-tank), о котором узнали побывав на конференции YAC-2013 и пообщавшись со специалистами Яндекса на эту тему. Этот инструмент полностью отвечал всем нашим требованиям к простоте подготовки теста и к генерируемой нагрузке.

Pairwise testing: добиваемся оптимального покрытия различных тестовых комбинаций

В тестировании программ очень часто встаёт задача проверки комбинаций входных параметров, от которых зависит итоговый результат программы. Типичный пример - диалоговое окно печати файла: оно имеет множество настроек, полей ввода, различных взаимозависимых опций, от включения или выключения которых итоговый результат может сильно различаться. Если бы даже все опции имели только два режима работы (вкл/выкл), а всего опций было бы 10, то это уже даёт 2¹⁰ = 1024 их комбинаций.

Конечно, чтобы убедиться в работоспособности программы, в идеале нужно проверить все тестовые наборы, состоящие из всех возможных комбинаций параметров, так как для одной из них она может работать некорректно. Но, во-первых, таких тестовых наборов может получиться достаточно много и будет трудоёмко их все проверить. Во-вторых, при тестировании обычно желают получить не сочетания всех параметров со всеми, ведь в этом случае будет труднее локализовать дефект и воспроизвести проблему, а проверить отдельные пары значений параметров, которые могут привести к проблеме. Для упрощения подбора таких пар используют методику Pairwise testing, которая позволяет выделить комбинации уникальных пар проверяемых значений и одновременно уменьшить число тестовых наборов, по сравнению с полным перебором.

Crawljax: Автоматизация краулинга web-приложений

Crawljax: Crawling Ajax-based Web Applications - это Java-инструмент с открытым исходным кодом, которое позволит вам протестировать ваше web-приложение фактически имитируя действия пользователя по браузингу сайта. Crawljax может исследовать сайт использующий технологию ajax, при этом автоматически создавая динамический граф состояний DOM.

Для тех кому требуется проводить инвентаризацию сайта, может понравиться возможность снятия скриншотов каждого состояния и странички сайта так, как это выглядит в реальном браузере. Crawljax использует для этого движки реальных браузеров, работая через Selenium WebDriver.

Нагрузочное тестирование при помощи JMeter

Структура статьи:

1. Основные понятия нагрузочного тестирования.

2. План нагрузочного тестирования.

3. Проведение тестирования при помощи JMeter.

    3.1. Установка и настройка JMeter.

    3.2. Снятие показателей нагрузки.
            3.2.1. Настройка jp@gc-плагина для использования PerfMon Metrics Collectors.

            3.2.2. Настройка стандартного монитора состояния сервера Monitor Results.

            3.2.3. Распределенное многопоточное тестирование нагрузки при помощи JMeter bot-net.

    3.3. Подготовка тест-плана JMeter.

           3.3.1. Рекомендуемый минимальный набор модулей для тест-плана.

    3.4. Отладка, тестирование и сохранение результатов.

4. Профили нагрузки и измеряемые показатели.

5. Акт выполненных работ по нагрузочному тестированию.