Секреты работы с AWS: что стоит за успешными проектами Романа Дубинина

Российский рынок ИТ-специалистов последние годы переживает заметные трансформации. С одной стороны, спрос на разработчиков остаётся стабильно высоким — цифровизация охватывает всё больше сфер, от финансов и телекоммуникаций до промышленности и госсектора. В 2024 году в России насчитывалось около 1 млн ИТ-специалистов, что на 13% больше, чем годом ранее. С другой стороны — рынок стал более конкурентным: компании активно борются за сильных инженеров, поскольку в достаточном количестве на рынке есть только джуны.

Фото: Фото из личного архива Романа Дубинина

Инженер, архитектор и тимлид Роман Дубинин

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

Именно поэтому мы решили пообщаться с Романом Дубининым — инженером, архитектором и тимлидом с 20-летним опытом, который успешно работал и в крупнейших российских компаниях (МТС, ВТБ24, Solar Security), и на международных проектах (EPAM, Atlassian).

— Роман, добрый день! У вас большой опыт с Java и Spring. Какие современные фреймворки или подходы в Java-экосистеме вам кажутся наиболее перспективными?

— Весь мой опыт разработки в экосистеме Java в основном связан со Spring/Spring Boot. Я до сих пор остаюсь при мнении, что этот фреймворк позволяет писать самый простой и читаемый код, а также обладает самым большим комьюнити. Поэтому если у проекта (особенно на старте или для Proof of Concept) нет специфичных требований, то Spring 6/Spring Boot 3 остаются отличным выбором.

Другое дело, если для проекта критично время запуска приложения, его "легковесность”, можно посмотреть в сторону Quarkus и GraalVM. А если приложение строится для работы в event-driven архитектуре, с высокой нагрузкой, стоит смотреть в сторону Reactive (что не мешает использовать удобство Spring).

— Вы часто работали с AWS. Какие сервисы оказались самыми полезными в реальных проектах и почему?

— С AWS мне удалось поработать в течении двух лет подряд, а в целом три с половиной года, сначала в России, а затем за рубежом.

Полезность сервиса безусловно зависит от специфики проекта. Первым сервисом в будущей экосистеме AWS стал S3 (Simple Storage Service) — объектное хранилище данных, и он оказался фундаментален для нескольких проектов на которых я работал из-за возможности хранить огромные объемы данных произвольного формата. Другие базовые сервисы, которые я считаю должным упомянуть, это EC2 — веб-сервис, на базе которого строятся целые кластеры (ECS/EKS), а также RDS — в наше время никуда без реляционных баз данных. Наконец, сервис DynamoDB — отличная NoSQL база данных (пригодилась мне на 4 проектах из 5), сервис IAM — контроль доступа/идентификация.

— В Atlassian вы работали над системой восстановления после сбоев (Disaster Recovery) для огромного хранилища данных в 30 петабайт. Как вам удалось построить такую систему и какие были главные трудности?

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

Представьте библиотеку на миллионы книг. Если она сгорит, восстановить всё за раз невозможно. Поэтому мы сделали так, чтобы копии постоянно обновлялись маленькими порциями и всегда были под рукой. Самым сложным оказалось не настроить копии, а регулярно проверять, действительно ли они работают. Многие компании считают, что раз есть бэкап — значит, всё хорошо. На практике, если не тестировать восстановление, в критический момент можно остаться с пустыми руками.

— Во время работы на одну из крупнейших финтех компаний на рынке ВТБ24 вы внедряли практики SDLC. Какие из них оказались самыми полезными?

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

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

— Вы несколько раз строили ИТ-команды "с нуля". На что в первую очередь обращаете внимание при наборе разработчиков?

— Больше всего обращаю внимание на "инженерное мышление”, интерес к профессии, готовность меняться и учиться, а также коммуникативные навыки. Нанимать джуна — это не плохо: я много раз наблюдал как при должном менторстве инженеры растут за полгода до мидла, а за полтора-два года до senior уровня.

Также смотрим на желание учиться и инициативность. Технологии устаревают очень быстро, поэтому ценнее человек, который умеет быстро разбираться в новом. Я часто задаю кандидатам вопрос: "Что бы вы делали, если бы у вас не было ТЗ и дедлайна?" Ответ показывает, интересен ли человеку сам процесс или он работает только по инструкции. Второе — это умение работать вместе. Одинокий гений редко вытаскивает команду.

— Роман, вы упоминали, что менторили более 10 разработчиков, и некоторые из них стали тимлидами. Как вы помогаете людям расти?

— Стараюсь давать задачи чуть сложнее, чем они привыкли, и быть рядом, когда нужна поддержка. Человек растёт именно в тот момент, когда понимает: "Я думал, что не смогу, но справился".

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

— Вы говорили, что предпочитаете оставаться hands-on инженером. Как вам удаётся совмещать роль руководителя и непосредственную работу с кодом?

— Я не хочу быть таким "бумажным" лидером. Поэтому я всегда оставляю часть времени на работу с кодом и проектированием систем.

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

— Что для вас значит "красота" в инженерных решениях? Важна ли она для работы и инноваций?

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