В Сбербанк-Технологиях занимаются целым рядом интересных задач — от унификации интерфейсов громадного банка до прототипирования blockchain. В большинстве случаев разработка ведётся на Java: её в компании считают лучшим выбором для больших корпоративных систем, ценя возможность скомпоновать решение из сторонних продуктов и внутренних разработок.
На конференциях спикеры «Сбертеха» рассказывают как непосредственно о своём опыте, так и об общих выводах, которые можно из него сделать. Но в формат докладов укладывается не всё, и накануне Joker мы отдельно задали вопросы троим сотрудникам компании, выступающим на Java-конференциях. Нам ответили:
- Сергей Владимиров (выступит на Joker 2016)
- Александр Маторин (выступал ранее на Joker, JPoint и JBreak)
- Максим Зелинский (выступал ранее на JPoint и JBreak)
Сергей Владимиров (руководитель разработки в ЦК платформы поддержки развития бизнеса)
— Примерно год занимался разработкой новой системы учёта терминалов приёма карт в торговых точках. Проект заменяет устаревшую систему, написанную на C, работавшую с прямым соединением с базой данных и имевшую большое количество ручных и полуручных взаимодействий с другими системами. Наше приложение будет частью новой платформы Сбербанка 2018+ (целевая платформа с 2018 года). Оно написано как «честное» серверное Java-приложение (с браузером в качестве клиента), с использованием клиенто-ориентированной архитектуры хранения данных (на основе технологии Apache Ignite / GridGain) и единой корпоративной модели данных. Тут куча умных слов, но за каждым из них кардинальное изменение если не в том, как надо думать, то уж точно в том, как надо разрабатывать приложения для бизнеса.
В этом проекте завершена первая фаза, мои коллеги продолжат над ним работать, а сам начинаю заниматься новым проектом по организации пользовательского интерфейса. Опять же, это будет не просто переписывание кода с HTML на JavaScript, а внедрение новых подходов к взаимодействию frontend и backend.
— Вы преподаёте защиту информации и криптографию — это связано с работой в Сбертехе, или ими интересуетесь отдельно? Сбербанк начал прототипировать blockchain — имеете ли отношение к этому?
— Увлекаться защитой информации я начал ещё со школы (как и программировать), но это всегда шло параллельно и напрямую не связано. Но влияние они оказывают друг на друга постоянно. Как минимум, ловишь себя на том, что на одну и ту же проблему начинаешь смотреть с двух сторон: «как я бы сделал это как разработчик» и «где у этой системы слабые места, если я захочу её сломать». Особенно это касается сложных систем уровня предприятия. Очень плохо, если «учёт безопасности» при проектировании систем состоит в том, что уже готовое решение вынужденно меняется под давлением сотрудников безопасности, а не наоборот — когда следование правилам безопасности закладывается в принципы построения системы, и тот, кто систему разрабатывает, понимает и «чувствует» это принципы. Очень полезная штука.
Не говоря уже о том, что меня как программиста не испугать страшными словами «сертификат», «цифровая подпись» или «хеш-сумма».
Что касается blockchain, к сожалению (действительно сожалею), у Сбербанка столько интересных проектов, что не просто нельзя успеть поучаствовать во всех интересующих, но иногда даже узнаёшь о них из новостей и СМИ. Про тот же blockchain с удовольствием сходил на лекцию, которую организовал Сбербанк для своих сотрудников, узнал, что же такое blockchain с точки зрения бизнеса, но, видимо, в ближайший год сам лично в этом проекте принять участие не успею. Как, к сожалению, не успею принять участие и в проекте «Фабрика данных» (проект анализа больших данных).
— Вы любите open source — а насколько активно при работе в Сбертехе его используете?
— Можно не любить open source, но его очень сложно не использовать :-) Если вы программист на Java и разрабатываете решение для бизнеса — значит, у вас в classpath лежит не один десяток open source библиотек, начиная от логгера до библиотек работы с XML или JSON. В Сбербанк-Технологиях мы не только используем open source, но и стараемся быть активной частью сообщества. Самый яркий пример — это, конечно, участие в работе над Apache Ignite.
Open source оказывается не просто дешевле. Он оказывается быстрее с точки зрения «time to market». Используя платный продукт с закрытым кодом, вы можете два-три года ждать от разработчика исправлений или доработок по нужному вам функционалу. А можете взять open source решение, исправить в нём какие-то недочёты (если они там были и их никто не заметил), а когда нужно что-то добавить или поменять, просто брать и менять. Пусть на это требуется квалификация, пусть она немного не свойственная вашим сотрудникам, но это будет работать, грубо говоря, уже через неделю в production, а не через 2-3 года, когда выйдет новая версия закрытого продукта. В Сбербанк-Технологиях это не теория, а реальные случаи, когда вынуждены менять какую-то технологию или решение просто потому, что дорабатывать существующее или слишком дорого, или, что обычно важнее, слишком долго.
— Вы выступаете перед публикой в разных форматах: и как преподаватель в МФТИ, и с научпоп-лекциями, и на конференциях. Чем формат конференций для вас отличается?
— Если сравнивать лекции и выступления на конференциях, то последние всегда сложнее и интереснее. У докладчика нет способа заставить людей придти на его рассказ — двойку на экзамене он не поставит. Нельзя просто выйти перед аудиторией и рассказать материал — люди пришли не конспектировать, не просто узнавать новое и познавательное, а люди пришли получать те знания, которые помогут стать профессионалами в своей области. И если какой-то доклад не даёт что-то полезное, что человек может применить на практике (пусть даже в будущем), человек встанет и уйдёт.
То есть цель студента — сдать экзамен. Цель слушателя научно-популярной лекции — узнать что-то интересное в своё свободное время. Сходить на лекцию как на экскурсию. А вот цель слушателя профессиональной конференции — профессиональный (и карьерный) рост. И если доклад не способствует этой цели, его не будут слушать.
— О чём расскажете на предстоящем Joker?
— Презентация для Joker долго дорабатывалась с организаторами, было несколько предварительных прослушиваний, и в итоге решили немного сместить акценты. Раньше предполагалось, что в ней будет несколько примеров оптимизаций на уровне алгоритмов, когда несложными действиями (и точно без новых библиотек и инструментов) мы получаем значительный выигрыш в производительности. Но в итоге решили взять один из самых ярких моментов и рассмотреть его с нескольких сторон.
Поэтому на student edition вас ждёт рассказ о такой структуре данных, как trie, или нагруженное (префиксное) дерево. И будет показан реальный пример из рабочего опыта, в котором с помощью этой структуры достигли роста производительности отдельной узкой задачи в тысячу раз.
Александр Маторин (главный руководитель разработки в ЦК развития риск систем)
Я работаю в отделе, который занимает разработкой систем управления рисками на финансовых рынках. Есть системы, которые собирают сделки, совершаемые трейдерами от лица Сбербанка. Другие системы могут подписываться на получения событий о новых сделках, чтобы посчитать определенные риск-метрики, или проверить сделку на предмет мошенничества.
Самый простой пример отслеживания мошенничества — поиск «парных сделок». То есть трейдер покупает определенный финансовый инструмент и через некоторое время продаёт его по более низкой цене, возможно, тому же самому контрагенту. Например, трейдер купил доллары по 70 рублей, и через день продал по 60, рассчитывая, что часть разницы вернется ему другим каналом.
Другие тесты для определения мошенничества считают более сложные метрики, например, Implied Volatility для FX-опционов методом Black-Scholes. То есть тут интересная предметная область и много финансовой математики.
— Какие инструменты/технологии используете?
В нашем отделе разрабатывается порядка 15 различных систем, которые, взаимодействуют друг с другом по разным протоколам. Тут очень хорошо подходит микросервисная архитектура, которую мы начали использовать примерно 4 года назад, ещё до того, как это стало мейнстримом. Расчёт каждой риск-метрики или агрегатор сделок — это отдельный сервис. Сейчас наши системы разбиты примерно на 100 микросервисов, которые запускаются в нескольких дата-центрах. Мы пишем на Java 8, везде используется Spring. Разные сервисы используют разные технологии и базы. Часть того, что мы используем: Cassandra, MongoDB, Coherence, GridGain, RabbitMQ, Oracle DB, TomCat.
— Также вы участвуете во внутренних конференциях компании — а можете ли рассказать о них?
— Уже два года подряд в «Сбербанк-Технологиях» проводятся внутренние конференции Dev & QA days. На последний Dev Day в Москве пришло порядка 150 человек, примерно 300 смотрело online-трансляцию. Было примерно 20 докладов в 3 потока. Я участвовал как спикер и как участник программного комитета. У нас, как и на Joker, любой желающий мог подать заявку на доклад. После заявка рассматривается программным комитетом. Если заявка принята, с докладчиком проводят один или несколько репетиций доклада. Надеюсь, эти конференции будут развиваться и дальше.
— Вы преподаёте на кафедре «Сбертеха» в МФТИ — а для вас это дополнительная деятельность, не сказывающаяся сильно на основной, или вы ощущаете, что преподавая другим, в итоге сами начинаете при работе в Сбертехе выполнять задачи лучше?
— Я преподаю в магистратуре СБТ в МФТИ больше 2 лет. Также, в СБТ пару месяцев назад открылась Java-школа, там я тоже читаю лекции.
Основная задача моего курса по Java, которую я ставлю перед собой — не просто добиться того, чтобы студенты сказанное мной, а передать им свою увлечённость джавой, чтобы они уже сами с интересом углубляли свою экспертизу. Лучшим студентам кафедра каждый год предоставляет возможность посещать конференции Joker и JPoint.
Во втором семестре читаю курс по распределённым системам. Рассказываю CAP, FLP теоремы, алгоритмы распределённых транзакций, протоколы консенсуса, понятие времени в распределенных системах, что может сломаться и как обеспечивать отказоустойчивость, архитектуры NoSQL баз данных.
Второй курс помог мне самому узнать много нового, структурировать свои знания и часть из этого применить в своих проектах.
Для студентов курса уже 2 года проводится соревнования по алготрейдингу. Студенты должны реализовать на Java интерфейс стратегии алготрейдинга. Потом загрузить этот исходный код на сайт игры. Стратегия компилируется, запускается в отдельной JVM и в реальном времени начинает торговать с решениями от других участников. Можно заливать новые версии стратегий неограниченное число раз. В прошлом году один из участников к концу игры загрузил примерно 160 версий. Но победил другой :)
Максим Зелинский (начальник отдела в ЦК Развития фронтальных систем)
— Чем именно вы занимаетесь?
— Я участвую в создании Единой Фронтальной Системы (ЕФС), а именно отвечаю за создание и развитие Платформы для разработчиков, реализующих непосредственно бизнес-функциональность в рамках ЕФС.
Единая Фронтальная Система в будущем будет обслуживать абсолютно всех клиентов Банка через все доступные каналы (интернет-банки, мобильные приложения, АТМ, колл-центры, отделения и т.д.). Её задача — унификация и переиспользуемость решений. Конечно, у разных каналов есть своя специфика, но в целом суть программы в том, чтобы один раз инвестировать в реализацию чего-либо, и сделать эту реализацию аналогичной для разных каналов.
Учитывая огромные масштабы ЕФС, для создания качественных и надёжных решений требуется единый набор технологий и сервисов, чтобы сократить time to market новых решений, а также гарантировать единый уровень сервиса с точки зрения надёжности и производительности. Этими вопросами (единый стек, сервисы, архитектура) и занимается моя команда в рамках Платформы ЕФС.
— Вы специализируетесь на вещах вроде распределённых систем — почему тогда занимаетесь фронтальной системой, а не бэкендом?
— В нашем случае фронтенд с точки зрения производительности, отказоустойчивости и надёжности даже интереснее, чем бэк: там требования вида «аптайм 99,99%». А если бэкенд в какой-то момент не работает, клиент этого даже не заметит. Его платежи не исполнятся моментально, но можно будет занести их в систему, можно будет получить выписки из кэша.
Но по бэкенду в Сбербанк-Технологиях есть другая большая программа: Программа поддержки развития бизнеса. Это попытка трансформировать технологические решения с помощью In-Memory Data Grid. Сначала были попытки сделать автоматическое шардирование данных на базе Oracle или PostgreSQL. Был пилот, он дал и положительные результаты, и негативные. По итогам пилота было решено «текущие технологии не совсем актуальны для масштабов банка, давайте смотреть в будущее». Выбрали IMDG, и коллеги теперь занимаются переносом бэковских массивов данных в память.
— С такими гигантскими масштабами, как у вас, возникают ли ситуации, когда одно технологическое решение приводит к очень большому выигрышу в ресурсах?
— Яркий пример – выбор технологий для web-презентационного уровня JS SPA и React. Один только перенос презентационной логики с сервера приложений на клиента позволил сэкономить нам ~200 серверов приложений, которые изначально планировалось использовать для классического server-side web-презентационного уровня. То же самое касается сокращения трафика между клиентом и сервером, который очевидно снижается благодаря тому, что обмен идет только данными, а не HTML’ем.
— У вас есть опыт реверс-инжиниринга — а оказывается ли он практически полезен при работе в Сбертехе?
— Очень даже. Особенно часто приходится заниматься reverse engeneering’ом при работе с IBM WebSphere Application Server, начиная от IBM JVM, где команда, с которой я ранее работал до ЕФС, нашла критичный дефект, приводящий к дедлоку внутри JVM при работе с аннотациями под нагрузкой, заканчивая Java-драйверами для IBM WebSphere MQ, когда пришлось долго изучать проблему, почему комбинация IBM WAS + IBM MQ + Spring JMS Templates не работает с неперсистентными очередями под нагрузкой.
— Спасибо. Будем ждать на Joker доклад Сергея Владимирова, а пока вспомним предыдущие доклады от «Сбертеха» на Java-конференциях:
Комментарии (0)