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

Cobol сильно не в почете, но это интересная вещь – на нем отдельную задачу можно реализовать только одним способом, и соответственно 10 человек напишут одно и то же. Языки типа RPG3 вообще работают по одному встроенному алгоритму, не ошибешься даже если захочешь. Однако когда появились инструменты низкого уровня – Fortran, C – сразу появилась и стратификация в качестве и скорости кода, и кратная разница в эффективности и оплате.
В разных сферах принципы разработки могут быть разными. Например, для биржи или телекоммуникаций необычайно важны скорость и производительность ПО. Очень много инструментария, созданного для повышения производительности труда, нам не подходит – нам важна производительность программ. Ради этого мы готовы нарушать сложившиеся правила и пользоваться приемами программирования, которые в учебниках не упоминаются. Все это вместе складывается в определенный канон - High Performance Computing.

В High-Performance Computing (HPC) оформились свои правила и законы, и люди тоже ищут своего потребителя, свою экономику.

Им тоже хочется получать предсказуемый результат, как и кобольщикам в 90-е. Если к трейдеру с идеями приходят ребята со словами: “Сейчас мы вам сделаем так, как никогда раньше не было”, то основные вопросы неизменны: “Когда? Сколько это будет стоить? Как часто оно будет ломаться?”. Скорость и риск дальнейших изменений являются важными факторами – но в общем, наши приемы кодирования и стиль программирования в области HPC, в общем и целом, датируется серединой 80-х годов – с оговоркой, что это относится только к высокочастотным торговым системам.

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

Python активно используется в финансах, вы правы, но не разработке приложений - в основном во вспомогательных процессах, например, для тестовых фреймворков. При этом вспомогательного кода в разы больше, чем самих приложений. Другой нетипичный инструмент – статический анализатор Coverity, анализатор времени транзакций Corvil, и много чего еще.
Самое нетипичное – наверно наш базовый алгоритм сведения заявок. На любой бирже основной производственный цикл: на биржу приходит две заявки, одна на продажу, другая на покупку. Они выстраиваются в то, что мы называем “стаканом” - order book, где ранжируются по цене и времени (есть и другие методы - это два наиболее распространённых). Однако, то дополнительное что мы делаем с этим процессом на Московской бирже, не существует более нигде в мире – предварительную проверку заявок на риск еще до постановки в стакан.

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

Это очень большие нагрузки. Алгоритм проверки риска Нью-Йорк и Лондон прогоняют раз в сутки в конце дня, Франкфурт — раз в пять минут. Мы делаем это в реальном времени для каждой заявки.
Эффект двоякий: по-настоящему сложных алгоритмов оценки риска у нас возможности использовать пока нет. Однако за “хрестоматийные” 400 микросекунд, которые современная биржа может тратить на обработку заявки, мы успеваем проверить риск и поставить заявку в книгу. Другие биржи просто ставят заявки в книгу за это же время. То есть система работает с постоянными нагрузками со всеми вытекающими из этого последствиями.

Сам процесс сведения заявок и обработки сделок прост и называется “matching engine”. Если заниматься только этим, то получается быстро – Лондон управляется за 120 микросекунд, Нью-Йорк на новом движке называет фантастические цифры (кстати, авторы этого движка наши соотечественники, создавшие свой стартап на Уолл Стрит). Европейские биржи помедленнее – порядка 400-500 микросекунд. Мы примерно на том же уровне что и европейские коллеги, но за это время еще успеваем сделать оценку риска.
Проверить риск и осуществить на базе данной оценки клиринг - это сложно и сильно влияет на нашу надежность. В ПО ломается то, что часто меняется, а ошибки вносятся во время разработки. В нашей области только риск и клиринг имеют тенденцию к изменению, торговый процесс остается неизменным. Поскольку они у нас сопряжены надежность торгов равна надежности часто меняющегося клирингового модуля. Во-вторых, поток транзакций в торгах однороден, а в клиринге сходятся транзакции и действия, существующие на разных временных масштабах.

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

Абсолютно верно. И процесс разработки на бирже требует необычного набора навыков, что снова возвращает нас к тематике HPС. Например, альпинист вверх ногами карабкается по отвесной скале. С одной стороны - он находится на пределе своих человеческих возможностей и условий использования окружающей его среды (порода скалы, наличие выступов), а с другой его задача обеспечить максимальную безопасность — упасть нельзя. Это похоже на то, чем мы занимаемся, потому что такой необычный набор “прав и обязанностей” сложно встретить в других областях разработки.

Со стороны может показаться, что это беспринципные люди, которые сделают что угодно, чтобы “работало быстрее”, но тем не менее, они придерживаются очень строгих принципов и правил.
Вокруг биржи возникает большое количество разнообразной деятельности. Например, нам тоже нужно тестировать код. В тестировании используется и Python, и кое-где Perl, хотя уже меньше, чем раньше. Используются и очень консервативные методики управления и проверки качества. По-английски всё перечисленное обобщается в Software Manufacturing: промышленный производственный процесс, а его главная характеристика — предсказуемый результат.

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

У нас есть места, где мы используем Agile-процессы, примерно 50% разработке используют SCRUM. Но в торгово-клиринговом комплексе этого нет. Отчасти потому, что мы привязаны к экосистеме финансовой отрасли, и не можем ей сказать: “Теперь у нас будут двухнедельные спринты”. Брокеры сойдут с ума. При этом у нас очень мощная команда — 350 человек. А если у стороннего разработчика до 50 человек, то он не сможет за нами угнаться при всем желании.
Поэтому мы работаем в релизном цикле: строим большой релиз, за 2 месяца сообщаем, какие в нём изменения, пишем документацию, создаём тестовые среды. На каждом рынке это происходит приблизительно 3 раза в год, и на самом деле это достаточно высокий темп изменений. По всей бирже выходит около 10 функциональных релизов за год. Плюс у нас есть гигантский пласт индустриального нагрузочного тестирования, когда все подключаются и пытаются нас «завалить». Именно в этот момент мы узнаём цифры нашей пиковой производительности.

Люди понимают под тестированием очень разные вещи. У меня когда-то работал программист, который компилируя программу и видя ошибки, несколько отстранённо смотрел на них, а после пытался скомпилировать код еще раз, видимо, ожидая, что ошибки начнут себя вести как-то иначе. Кто-то даже под этим понимает тестирование.
Все почему-то зациклились на тестировании, хотя тестирование – это самый дорогой способ выявления ошибок, как и проба супа после того как он уже сварен. Мы стараемся делать больший упор на процесс разработки, планирование и управление качеством в процессе, смотрим на ингредиенты еще до того, как они отправляются в кастрюлю. Один из примеров подобного подхода: сидит программист, написал часть кода, нажал “Я готов” и код отправляется другому программисту на ревью. Все изменения у нас проходят такой отбор. Дальше начинается “читка” кода. Когда человек знает, что его ждёт публичное ревью его работы, он вообще по-другому относится к своему делу. Мы начали массово использовать этот подход не так давно, месяца 3-4 назад.

Написать программу не сложно, а вот написать индустриальную программу в одиночку невозможно в принципе. В армии на одного лётчика приходится 50 человек обслуживающего персонала, но высокая ответственность лежит на всех.
Разработка торгово-клиринговой системы: 100 человек, написанием кода занимается 40 человек. Все остальные находятся в системе Software Manufacturing - это люди, обеспечивающие остальные части процесса.
Те, кто не пишут непосредственно код программы, пишут другой код, например, для проверки. Если бы у меня была такая возможность, я бы платил людям за каждую найденную ошибку. Предположим, группа разработки и тестирования присылает программу, утверждая, что она работает безошибочно. Я даю это другой команде и отвожу месяц на то, чтобы “вытрясти” максимум ошибок из неё. Именно так я начинал в Bell labs, где все мы были гордыми программистами. Я отдавал своё “идеальное детище”, а через неделю мне приносили список найденных там ошибок. И эти люди были лучшими разработчиками, так как писали то, что “ломало” наши разработки.
Когда вы говорите с возможным кандидатом и спрашиваете, будет он разработчиком или тестировщиком, все смотрят на последнее с минимальным энтузиазмом. Я с этим категорически не согласен - это та же работа программиста, но с очень важной задачей.

Человек должен быть заинтересован в самой технологии и иметь интерес в этой бизнес-области.
Мне всегда было интересно работать с финансами, потому что мне интересны деньги, как объект реального мира и центральную модель взаимодействия. Кому-то интересно писать микрокод для холодильника, другим для носимых устройств, роботов и так далее. Мне всегда было интересно писать программы и код, которые ворочают миллиардами и триллионами денежных единиц. На мой взгляд, это гораздо более интересно, чем социальные сети, к примеру.
Как правило, человек, который заинтересован в создании или развитии социальной сети, к нам не пойдёт. Booking.com, к примеру, разрабатывает без тестирования, отправляя мгновенные изменения в продакшен. Для их бизнес-модели это совершенно легитимный подход, в котором проще откатить неудачные доработки. Никто на C или Assembler там не будет писать куски продукта — это долго и нудно. А видеть результаты своей работы сразу же — бесценно.

Мы не можем такие результаты мгновенно “показать”. И для части разработчиков, которые привыкли видеть результат своей работы, это тяжело. Человеку будет скучно, нужен определённый склад характера.

Нет, вещь на самом деле очень распространённая, а занимается ею масса людей. Он просто невидим, потому что мы потребляем конечный продукт или услугу. Интернет-телевидение, стриминг — это сравнимая вещь. VoIP, где голос “упаковывается” в зависимости от ширины канала, с какой скоростью обрабатывают аналоговые источники в цифровые - это же фантастика. При этом мы просто говорим по телефону, вообще не понимая, что происходит. Декодинг аудио/видео на компьютере — это фантастические объемы операций на очень быстрых процессорах. А что такое процессор? Это микрокод, запаянный в железо.

Мы всегда ищем места, которые можно повысить эффективность за счёт улучшения архитектуры, качества кода, инфраструктурных решений. Но стараемся не привязываться к железу, и в торгово-клиринговой части такой необходимости нет. Хотя в одном месте мы все же зависим от “аппаратуры”.
Это хранение данных — область, где мы вынуждены использовать чужие решения. 20 000 транзакций в секунду на каждом рынке из трёх, это 60 000 операций в секунду – всё это уходит на “вечное” хранение, к которому всегда должен быть доступ - это требования государства и рынка. Кроме того, данные анализируются и продаются как самостоятельный продукт.
Ни одна реляционная база данных на стандартном оборудовании не соответствует таким требованиям. Только колоночные СУБД и аппаратные ускорители Exadata, которые мы используем. Важно не только хранить, но и быстро извлекать.
На сетевом уровне мы переходим на коммуникационную схему InfiniBand. Мы “ныряем” под стандартный стэк TCP-IP и используем уровень ниже. HPP-комплексы дошли до состояния, когда передача информации занимает меньше времени, чем её обработка на процессоре.
В конечном итоге мы хотим прийти к тому, чтобы наше ПО “заводить” в программные ускорители различных типов. Например, протоколы мы хотим обрабатывать на FPGA-картах. Когда вы обсчитываете алгоритмы риска — это простое вычисление в большом количестве “мест”, участков. GPU отлично справляются с этой задачей. Риск-система немецкой биржи построена на рыночных и совершенно классических графических ускорителях. FPGA это настоящее программирование микроконтроллеров. Раньше себе могли позволить подобное только гиганты, вроде Intel. Сейчас для этого свой завод не нужен.

Мы пока не видим непосредственного применения блокчейн в нашей области. У него масса привлекательных качеств, любая распределённая система интересна. Безусловно, в каких-то областях, в том числе в финансах, она будет работать. Но у неё есть ряд свойств, которые не удовлетворяет наши потребности. Для торгов получается медленно, а для объемов – неразумно гонять всю базу по всем узлам системы.
Кроме того, вопросы безопасности открыты, потому что в блокчейне целостность строится на консенсусе. Сейчас консенсус в биткойне - это китайские фармеры. Вы этому доверяете? Также, блокчейн ничего не шифрует – информация может быть непонятна, но открыта. Data-mining в блокчейне тяжел, массив так устроен, что копаться в нем очень затратно.

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

Я считаю, что Московская биржа - отличное место для заинтересованного человека. Мы используем всё то, что использует большое предприятия, берём эффективное и применяем в своём поле деятельности. Мы резонируем с рынком. При этом мы занимаемся делом, несущим огромную ответственность, быть частью этого, для меня, значит быть частью чего-то большего. Имея опыт работы на бирже, вы сразу же становитесь мифическим и загадочным персонажем, на мой взгляд, это важно.
Если говорить про языки или навыки — мы используем всё, что есть на рынке. C, C++, Java - это классика, от этого не уйти. Exadata и графические карты, сетевой Infiniband — это то, что нельзя попробовать в большинстве компаний, здесь мы в мейнстриме.
Мы используем современные схемы интеграции —например, технологии DataGrid. Мы были первопроходцами в области архитектурной интеграции, использовали сервисные архитектуры, сервисные шины. Интеграция на уровне “человеческого реал-тайма”, на т.н. энтерпрайз-шинах, это то что мы используем на 100%, конкретных коммерческих решений здесь очень много. У нас сейчас собственный Grid, созданный нами, всё это очень круто для интересующегося специалиста. А конкурентов в России в данных областях, мне кажется, у нас пока нет.