Дмитрий Магазеев — выдающийся разработчик и технический лидер с более чем пятнадцатилетним опытом работы в сфере программной инженерии. Его профессиональный путь начался ещё в студенческие годы, когда он разрабатывал встроенные системы, и наглядно демонстрирует, как страсть к разработке и постоянное стремление к совершенствованию могут преобразовать подходы к цифровой трансформации. Дмитрий Магазеев демонстрирует, как грамотное техническое лидерство и инновационный подход к реструктуризации устаревшей инфраструктуры позволяют не только повысить производительность и снизить затраты, но и усилить конкурентоспособность компаний на международном рынке цифровых технологий.
Дмитрий, расскажите, пожалуйста, о своём карьерном пути: как Вы пришли к роли ведущего разработчика, что стало отправной точкой в Вашей профессиональной жизни и, как более чем
Мой путь в программной инженерии начался ещё во время обучения в МГТУ им. Н.Э. Баумана на факультете робототехнических систем в 2013 году. Я тогда устроился работать в стартап, связанный с разработкой лифтового оборудования, и, можно сказать, уже в университете погружался в практическую разработку. Первое время я занимался встроенным программным обеспечением для дисплеев лифтовых кабин, но, по сути, именно тогда осознал, что сфера создания ПО — это то, что заставляет меня постоянно учиться и развиваться.
В итоге, за более чем 15 лет профессиональной деятельности, я прошёл путь от разработки встроенных систем до крупных серверных приложений. Примерно 10 лет я посвятил созданию ПО в области Optical Transport Networks (OTN), где работал в тесном контакте с высокоскоростными телекоммуникационными системами и сетевыми решениями. Уже затем мой фокус сместился на разработку бэкенд-приложений, где последние 7 лет я занимаюсь архитектурой и руководством командой разработчиков.
Такой широкий профиль, где я совмещал навыки встраиваемой разработки, сетевых технологий и создания серверной инфраструктуры, позволил мне вырасти до роли Tech Lead и Solution Architect. Постоянный переход от небольших «железных» проектов к крупным корпоративным сервисам дал мне необходимую гибкость в выборе инструментов и подходов, что важно для позиций, связанных с архитектурой и технологическим лидерством.
Вы занимаете позицию Software Architect (Tech Lead) в EPAM и успели реализовать два больших проекта для мирового финансового гиганта. Не могли бы Вы подробнее рассказать, в чём заключались эти проекты (Client Service и Research), а также объяснить, каким образом их успешная реализация помогла достичь стратегических целей этого клиента и укрепить репутацию EPAM, в чём, безусловно, проявилась Ваша личная заслуга?
Компания-клиент EPAM является крупной финансовой компанией, которая предъявляет крайне высокие требования к качеству и стабильности решений. Для EPAM это серьёзный заказчик, определяющий репутацию на рынке аутсорс-разработки. Когда я присоединился к проекту, меня назначили Tech Lead’ом на два основных направления:
- Client Service. Это поддержка основного клиентского сайта и бэкенд-системы для финансового анализа. В рамках этого проекта требовались оптимизация работы сайта и повышение производительности аналитического модуля. Скорость отклика и стабильная работа были важны.
- Research. Проект более масштабный, связанный со сборкой и выполнением модулей финансового анализа, которые непосредственно используются трейдерами для операций на бирже. Здесь я занимался оптимизацией кеширования, реорганизацией системы хранения данных и выводом из эксплуатации части legacy-инфраструктуры, что снизило стоимость облачных ресурсов.
Оба проекта имели принципиальное значение для репутации EPAM. Данный клиента ― это своего рода «лакмусовая бумажка»: если ты смог продемонстрировать надёжность и эффективность решений в рамках такого строгого заказчика, то это повышает доверие и других потенциальных клиентов к компании.
Насколько нам известно, именно Вы смогли предложить и внедрить решения, которые устранили существующие проблемы на проекте Client Service, включая оптимизацию скорости загрузки графиков и уменьшение расходов на тестирование. Могли бы Вы подробнее описать, насколько критичны были проблемы, и какие конкретные шаги Вы предприняли, чтобы их решить?
Основной фокус в Client Service заключался в быстродействии и оптимизации расходов на инфраструктуру. Когда я пришёл в команду, система уже существовала, но:
- Медленная загрузка некоторых страниц из-за того, что некоторые скрипты финансового анализа для получения данных могли исполняться до 60 секунд, что негативно сказывалось на пользовательском опыте. Как выяснилось, «узким местом» стали запросы к базе данных. Для решения мы внедрили кеширование результатов, а также оптимизировали сами запросы в базе. В итоге, нам удалось ускорить исполнение ряда запросов в 10 раз и более.
- Высокая стоимость тестирования (CI/CD): на каждый небольшой коммит запускался комплексный набор тестов (end-to-end, performance, diff, integration, unit), занимавший около 4 часов. Мы реорганизовали процесс, избавившись от повторяющихся проверок и избыточных сцен: благодаря разграничению тестов по приоритетам удалось снизить количество ресурсов на 10 раз и сократить общее время вдвое.
Кроме того, одной из самых заметных доработок было обновление HTTP библиотеки (или точнее, её замена на альтернативу с открытой лицензией), что обеспечило как устранение потенциальных уязвимостей, так и экономию на лицензировании. Также мы обновили версию языка Scala с 2.12 до 2.13, чтобы получить прирост производительности и безопасность, а заодно упростить жизнь финансовым аналитикам, писавшим скрипты.
Дмитрий, Ваша работа над проектом Client Service принесла впечатляющие результаты и способствовала ускорению выполнения некоторых финансовых скриптов более чем в 5 раз, а также снижению ежедневных расходов на серверные ресурсы. Какие решения, на Ваш взгляд, были самыми эффективными и как Вы добивались согласования своих идей с менеджментом клиента?
Из всех внедрённых решений я бы выделил несколько наиболее эффективных. Во-первых, это разделение монолитной системы на микросервисы, в данном случае мы вынесли функционал компиляции кода и контроля доступа в отдельные сервисы, что позволило гибко масштабировать узкие места и упростить обновления. Во-вторых, это кеширование и оптимизация работы с базой данных, в данном случае многие модули финансового анализа непрерывно читали большой объём данных; кеширование позволило сократить время выполнения отдельных финансовых задач с 60 до 6 секунд. В-третьих, это оптимизация CI/CD, где, сократив лишние тестовые сценарии и разделив большие тест-комплекты на модули, мы уменьшили не только время, но и стоимость тестов (уменьшение ресурса на 10 раз).
Что касается взаимодействия с менеджментом компании-клиента, то у них довольно четкая вертикаль: у меня был прямой контакт с Engineering Manager со стороны клиента. Я предоставлял регулярные отчёты о ходе работ, объяснял план по улучшениям, описывал ожидаемый эффект и потенциальные риски. Поскольку наш клиент ― технологически «продвинутая» компания, так что согласование шло через дизайн-ревью, демо-версии и затем уже получало «зеленый свет» от руководства.
Проект Research, над которым Вы работали, позволил компании-клиенту EPAM сократить затраты на облачные сервисы — речь идёт о миллионах долларов экономии в год. Как Вам удалось найти такие подходы к оптимизации кеширования, архитектуры хранения данных и вывода из эксплуатации legacy-системы, и что в этих решениях было наиболее сложным?
Research ― это сложная система, где ежедневно исполняются тысячи модулей анализа, генерирующих сотни гигабайт данных. Такая нагрузка в облаке всегда обходится дорого. Я и моя команда поставили цель снизить затраты за счёт:
- Улучшенного кеширования. В данном случае, мы оптимизировали размер нескольких кешей, объединили кэши для сервисов разных доменов, пересмотрели политику жизни объектов в кеше. Количество нод кэширующих сервисов сократилось на 30% без заметного ущерба производительности.
- Обновленной структуры хранения файлов. Мы обновили библиотеку для работы с ORC-файлами (и перевели компрессию на ZSTD), что существенно снизило объём данных, отправляемых в хранилище, а также объём занятого места на диске. За счёт этого снижения мы сэкономили ещё несколько сотен тысяч долларов ежегодно.
- Поэтапного вывода legacy-системы. Исторически у компании-клиента была монолитная система по хранению данных с ветвящейся структурой наподобие Git. Мы разбили её на 20 функциональных микросервисов, устранив необходимость содержать массив дополнительных индексов и таблиц.
Из вышесказанного, очевидно, что Ваша роль для EPAM была крайне важной, так как Вы помогли сохранить и укрепить позицию компании перед самыми респектабельными клиентами, такими как крупнейшая хедж компания. Однако нам интересно, как Вы сами оцениваете свой вклад и считаете ли, что подобные проекты повысили конкурентоспособность EPAM на международном рынке?
Я считаю, что в аутсорс-разработке успех часто измеряется «позитивным опытом» заказчика: если для клиентов мы решаем действительно критические задачи, снижаем колоссальные затраты и повышаем производительность, то эта репутация переходит и на всю компанию. Репутация EPAM напрямую связана с тем, насколько эффективно мы можем поддерживать и развивать системы подобного масштаба.
Дмитрий, насколько нам известно, Вы также реализовали не менее значимый проект в компании ИРЭ-Полюс, а именно разработали программное обеспечение Network Management System (NMS), благодаря которому новое поколение оборудования «Горизонт» смогло конкурировать с продукцией Nokia, Aricent, Ciena и др. Расскажите, пожалуйста, как появилась идея создания NMS и каковы были основные этапы её разработки?
Практически все вендоры телеком-оборудования поставляют собственную систему управления (NMS), ведь когда в сети задействовано несколько сотен шасси, каждая из которых содержит десятки модулей, без централизованного интерфейса не обойтись. Компания ИРЭ-Полюс до этого имела линейку оборудования «ПУСК», но оно морально устарело и не соответствовало современным техническим требованиям, особенно в части отказоустойчивости и функционала мониторинга.
Идея NMS пришла естественным образом:
- Сформировали партнерство с интеграционной компанией HCL, чтобы быстро запустить разработку.
- Собрали требования от потенциальных заказчиков и прописали функционал, необходимый для участия в тендерах.
- Разработали архитектуру, которая была бы масштабируема и могла бы автоматически определять характеристики нового оборудования.
- Запустили совместную работу с HCL, однако в какой-то момент контракт был приостановлен, и проектная команда в ИРЭ-Полюс взяла на себя основную часть доработки.
- Завершили систему собственными силами, адаптировав её под российский рынок и требования крупных операторов.
В итоге за счёт этого продукта «Горизонт» получил необходимую управляемость, без которой сложно позиционироваться на серьезном рынке телеком-оборудования.
Подскажите, какие у Вас дальнейшие планы и проекты, которые, по Вашей оценке, могут стать столь же важными, как решения для клиентов в EPAM или система NMS и «Горизонт» в ИРЭ-Полюс?
Часть планов связана с дальнейшим развитием платформы Research: там ещё немало возможностей по оптимизации и расширению функционала, особенно в направлениях машинного обучения и больших данных. Интересно будет оценить потенциал масштабируемых облачных решений (серверлесс-архитектуры и контейнеризация), чтобы ещё сильнее сократить операционные расходы.
Что касается телеком-направления, я вижу большой потенциал в развитии новых модулей для «Горизонта», повышении скоростей передачи данных (400G, 600G), а также в создании интеллектуальной системы управления сетью ― с элементами AI, которые могут автоматически адаптировать маршруты трафика под реальные условия и аварии.
Также я не исключаю сотрудничество с другими крупными игроками финансового сектора или телекоммуникаций.
