Всем привет! Меня зовут Александр Чуркин, и я руковожу Управлением корпоративной инфраструктуры Национального клирингового центра (НКЦ).

НКЦ входит в Группу «Московская Биржа». Напомню, мы выполняем функции клиринговой организации и центрального контрагента на финансовом рынке. То есть, берем на себя риски по заключаемым участниками в ходе биржевых торгов сделкам, выступая посредником между сторонами: продавцом для каждого покупателя и покупателем для каждого продавца.

В середине прошлого года мы объявили о квалификационном отборе поставщиков лицензий коммерческой версии СУБД на основе PostgreSQL, а в конце февраля этого года завершили тестирование и определились с выбором в пользу решения – Digital Q.DataBase от компании «Диасофт».

Теперь расскажем о том, как мы проводили предварительный отбор, тестировали отобранные решения, сделали свой выбор и готовимся к переходу на опенсорсную СУБД. Надеемся, что наш опыт поможет и вам!

Добрый день! Мы – команда сопровождения банковских телекоммуникаций Национального Расчетного Депозитария (Группа «Московская Биржа»). В НРД мы отвечаем за сопровождение информационных сервисов, которые используются на ежедневной основе при отправке платежей/сообщений через каналы SWIFT и СПФС, сдачи отчетности, взаимодействию со Федеральными органами исполнительной власти и других не менее важных направлений.

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

Мы планируем переезд! Новый офис будет современнее, удобнее, красивее и больше. Хорошая новость для сотрудников, но непростая – для айтишников. 

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

В конце 2023го года в рамках работ по импортозамещению основным корпоративным мессенджером Московской Биржи вместо MS Teams стал eXpress.

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

Перед командой Ситуационного Центра Московской Биржи встала задача: перенести все настроенные интеграции, рабочие процессы и оповещения Zabbix в eXpress

Всем привет! Меня зовут Ренат Дасаев и в прошлой статье Автоматизация Е2Е-тестирования сквозных БП интеграционных проектов Операционного блока было рассказано о том, как устроено e2e-автотестирование. Сегодня хочу рассказать о том, как используется camunda в автотестировании бизнес-процессов (далее БП). На практических примерах рассмотрим, что и как мы делаем в своих тестах.

Всем привет! На связи Срочный рынок Московской биржи. Будем вместе исследовать увлекательный мир на стыке финансов и технологий. Независимо от того, являетесь ли вы профессионалом в области финансов, энтузиастом технологий или хотите быть в "модной" теме инвестиций, знакомство с новым сервисом Московской биржи будет полезно.

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

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

Что умеет калькулятор?

Как управляют лицензиями на софт в Группе MOEX и получают уверенность в том, что расходы на них эффективны?

Всем привет!

Меня зовут Сергей Максимов и я руковожу разработкой в Центре Управления Процессами (ЦУП) Московской Биржи. В статье я хочу рассказать о нашем опыте автоматизации бизнес-процессов (БП), когда система должна быть не только удобной бизнес-пользователям снаружи, но и надежной внутри.

Бизнес Биржи, с одной стороны, похож на обычный банковский финтех, но имеет ряд важных особенностей. Чтобы лучше представить специфику нашей работы, я приведу метафору. Представьте, что каждое утро с вашего корпоративного космодрома в космос отправляется ракета. В течение дня космический корабль автономно выполняет работу на орбите, а вечером возвращается на базу. В полёте связь с кораблем очень ограничена и успех его полёта на 99% определяется качественной подготовкой. Всё должно отработать точно и в срок. Досрочный спуск корабля с орбиты технически возможен, но влечет за собой огромные репутационные потери с отчетом регулятору и новостями в федеральных СМИ.

Мы — SQL команда Срочного рынка Московской Биржи, занимаемся разработкой и сопровождением бэкофиса торгово-клиринговой системы Spectra с момента ее возникновения. Срочный рынок Московской Биржи — это более 500 фьючерсных и 30000 опционных инструментов, несколько миллионов сделок в день.

Торгово-клиринговая система Срочного рынка (ТКС Spectra) изначально строилась на основе MS SQL, и за пару десятков лет прошла сложный путь от нескольких серверов БД до огромной системы с сервис-ориентированной архитектурой. Долгое время вся бизнес-логика системы разрабатывалась в программном слое на серверах MS SQL: и матчинг заявок, и расчет обеспечения, и управление клиентами были реализованы на T-SQL.

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

В этой статье мы хотим рассказать об эволюции нашей системы разработки на SQL.

Привет, уважаемые читатели Хабра!

На связи Лаборатория инноваций Московской биржи

Хотим поделиться с вами нашим опытом разработки чат-бота для 1-й линии поддержки на базе корпоративного мессенджера eXpress.

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

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

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

В данной статье я расскажу про платформу цифрового опыта (Digital Experience Platform, DXP), ее состав и роль в производстве ценностей для компании.

Всем привет! Решили рассказать вам, уважаемые читатели Хабра, историю процесса внедрения E2E-автотестов в бизнес-процессы Московской Биржи.

Для начала вкратце разберемся, что такое E2E-автотест. Это вид тестов, который проверяет бизнес функционал от момента его начала до завершения.

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

Мы в MOEX рассматриваем платформу как внутренний продукт, и в ходе разработки ориентируемся главным образом на “боли” и потребности команд. Platform engineering, или развитие платформ в нашем понимании – это процесс создания и предоставления удобных сервисов самообслуживания командам и инженерам, с целью ускорения потока создания ценностей, снижения объема нецелевых активностей команд, а также повышения качества, надежности и безопасности создаваемых решений.

В статье, мы собрали для вас пять наиболее любопытных платформенных фич, которые ускоряют наши процессы.

Наверное, многим знакомо ощущение, когда приходит время переделывать хорошо отлаженный продукт. Он работает, стабилен, предсказуем и знаком, но что-то изменилось в воздухе, выросла сложность решаемых задач, разрослась инфраструктура, появились новые вызовы, и вот приходится решительно садиться и все переделывать. В этой статье мы расскажем про эволюцию нашей системы генерации отчетов aka Отчетницы, которая прошла долгий путь за последние 15 лет. Хочется похвастаться тем, что, невзирая на соблазн взять и переделать все с нуля, вопреки эпиграфу и благодаря ряду удачных решений, развитие системы оставалось эволюционным. Участки системы, ответственные за бизнес-логику работы нашей промышленной системы, сохранялись, и это спасало человеко-месяцы и годы тестирования для другой полезной работы.

Разберемся с тем, что из себя представляют отчеты для участников рынка. Ежедневно на Московскую Биржу отправляются десятки миллионов торговых заявок, совершается несколько миллионов сделок. По результатам торговых и клиринговых сессий наши участники получают больше двух сотен отчетов об итогах торгов, оценке обеспечения, выполнении обязательств маркет-мейкеров и др. Отчеты бывают в основном торговые и клиринговые, и, соответственно, несут информацию о торгах или клиринге. На каждом из наших рынков они отличаются, хотя структурно могут хранить информацию одного типа. Отчеты рассылаются отдельно каждому участнику торгов\клиринга (включая самого главного из них – Банк России). На заре времен отчеты представляли из себя текстовые файлы с таблицами, нарисованными в псевдографике. Сейчас это XML файлы со схемами и стилями на нескольких языках. Кстати, забавный факт –  по историческим причинам один из наших отчетов до сих пор отправляется в псевдографике. Ради привычки наших клиентов, которым данный формат наиболее удобен – функционал отрисовки таблиц пришлось заботливо пронести сквозь все метаморфозы системы подготовки отчетов. Впрочем, не будем забегать вперед.

Центральной частью биржи являются торговые системы и их торговые ядра, в которых происходит matching заявок участников рынка и формируется order_log

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

Если в двух словах описать эти процессы: они долгие и сложные.

Почему так?

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

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

Привет, Хабр! На этапе выбора темы статьи было много идей: написать про DevOps или про платформы, а может про продуктовые команды или про практики SRE? Но пришли к выводу, что нет ничего интереснее, чем реальная увлекательная история трансформации. Мы, команды платформы разработки MOEX и экосистемы Финуслуги.ру, в лице Карапета Манасяна, Александра Барыкова, Антона Квашёнкина и Юлии Лутковской, расскажем практически про весь путь изменений и про их подводные камни. Важно отметить, что в статье затрагивается довольно много тем, местами даже будут блоки со скриптами ?. Поехалиии!

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

ОPEN SOURCE + КОМАНДА = ХРАНИЛИЩЕ НА 7+ МЛН ДОКУМЕНТОВ

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

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

Но что делать, если вы приходите в проект, в котором исторически применялся подход «мороженки» тестирования, когда основную часть проверок закрывали ручным тестированием? При этом компания проходит трансформацию, и от вас ждут, что вы приведёте процессы в соответствие современным практикам и ускорите их?

Меня зовут Максим Бугров, я больше 8 лет работаю в тестировании ПО. На Московскую Биржу я пришел летом 2021 года на позицию начальника отдела тестирования. Наш департамент преимущественно разрабатывает софт, который связывает клиентов и торгово-клиринговые системы Биржи. И я расскажу, как мы начали превращать мороженку в пирамиду — нас ждал огромный ледник задач.

За почти четырнадцатилетнюю историю использования Jira и Confluence на Московской бирже в них накоплен огромный объем данных: у нас более 350 проектов в Jira и более 200 пространств в Confluence. Не будет преувеличением сказать, что в этих продуктах сейчас работает вся Биржа, а не только айтишники. Оперблок ведет в Confluence чеклисты регламентных операций, бизнес и аналитики пишут и согласовывают функциональные задания. В Jira недавно перевели проектный портал, которым заведует Проектный офис. Фактически продукты Atlassian у нас используются в режиме, приближенном к 24*7. Поэтому вопросы резервного копирования, восстановления в случае сбоя и времени вынужденного простоя уже давно стояли для нас весьма остро. В прошлом году мы сделали теплый резерв Jira и Confluence буквально на коленке, о чем и расскажем в этой статье. Ничего уникального, но тем выше шанс, что наш подход принесет пользу кому-то еще – увы, Atlassian уже начала отзывать лицензии, и неизвестно, что будет дальше.