Роман на протяжении всей карьеры инженера-разработчика ПО работает с ведущими ИТ-компаниями, в том числе с EPAM. Его заслуги отмечены на международных конкурсах, а профильные хакатоны стараются заполучить специалиста в качестве жюри.
Мы встретились с Романом и обсудили, в чем основные принципы проектирования отказоустойчивых систем, какие условия необходимы для развития современных облачных систем и в чем особенность работы с крупными финтех-компаниями. В интервью Роман эксклюзивно делится своей разработкой — платформой Mockachu, за которую 3 декабря он получил награду как ИТ-инноватор на втором всероссийском конкурсе «Эра Инноваций».
— Роман, вы более 10 лет работаете над проектированием отказоустойчивых систем, в том числе создавали проекты для таких компаний как ВТБ — одного из ведущих банков в России. В чем заключаются главные принципы внедрения технологических инноваций в такой крупной компании?
— Во-первых, я задаю себе вопрос «Зачем?». Здесь важны инсайты от внутренней аналитики и фокус на ценности для пользователя и компании. Не менее важна поддержка от самого бизнеса. Она может быть на разных уровнях, от менеджера проекта и до руководства всей разработки или директора по продукту.
И заканчивается все вопросом «Как?». Я выбираю быстрые эксперименты и прототипы (так появилась созданная мной платформа Mockachu), управление рисками проекта и взаимодействие с другими командами.
— Вы разработали платформу Mockachu, инновационный инструмент для Java-разработчиков, который повышает качество и надежность сервисов. Расскажите, какие задачи она решает?
— Mockachu — это платформа для автоматизированного мокирования и тестирования API, ориентированная на Java-разработчиков и команды, создающие распределенные системы.
Платформа сокращает время разработки и тестирования API за счёт мгновенной генерации mock-сервисов на основе OpenAPI-спецификаций, а также быстрого создания и изменения моков прямо во время функционирования системы. Снижение времени на создание моков составляет от 50% (при отсутствии готовой OpenAPI-спецификации) до 90% при ее наличии, а риск ошибки устраняется вовсе.
Если говорить проще, сервис устраняет один из ключевых барьеров в Java-разработке — сложность интеграционного тестирования в условиях отсутствующих или нестабильных внешних систем.
Mockachu одновременно поддерживает мокирование и привычных API и Kafka, что делает его особенно важным для команд, работающих с event-driven архитектурами и высоконагруженными Java-системами. Платформа снижает стоимость тестирования, ускоряет time-to-market и уменьшает риски ошибок интеграции — факторы, критически важные для современной enterprise-разработки.
— Звучит впечатляюще, а есть ли примеры интеграции платформы в реальные проекты?
— Да, безусловно. Решение уже доказало свою ценность на проекте для ВТБ как инструмент, повышающий качество разработки, скорость поставки и надежность сервисов. Была задача создать сервисно-ориентированное финтех решение. Но после старта разработки мы поняли, что сервисы, от API которых мы зависим, не будут реализованы в срок, и дедлайны нашего проекта тоже будут сдвигаться.
Поэтому мы создали моки внешних сервисов. Это решение оказалось очень своевременным, так как позволило нам полностью забыть о графиках других команд. В итоге система была создана вовремя. Более того, я получил ценный опыт применения Mockachu на реальном проекте. Если бы на данном проекте мы не применяли моки, то отставание сроков проекта могло бы составить до 6 месяцев, до 40%.
Также платформа Mockachu была применена в компании Солар на одном из проектов для решения аналогичной проблемы. Сервис, с которым шло взаимодействие, еще не был готов. Чтобы не тормозить разработку, наша команда создала моки на основе контракта API (без готовой OpenAPI документации) буквально за 10 минут. В результате мы реализовали проект быстрее и смогли избежать ограничений во время разработки. Экономия времени для данного этапа проекта составила около 10%.
— Вы много лет работали в международной IT компании EPAM и управляли разработкой на проекте для Atlassian. Какие фреймворки использовали, чтобы повысить производительность?
— Это был интересный проект, в результате которого удалось создать систему восстановления после сбоев (Data Recovery). Мы использовали Java 11, фреймворк Spring, базу данных Postgres, платформы AWS (я являюсь AWS Certified Developer) и Databricks. В итоге удалось создать мощное облачно-ориентированное решение. Также в рамках проекта у меня в команде был QA инженер, 2 дата-инженера, SRE-инженер и 3 BE.
Основная сложность заключалась в том, чтобы система смогла перемещать огромные объемы данных (несколько петабайт) согласно оговоренному SLA. Потребовался анализ нескольких отраслевых решений и подходов, в результате которого было представлено несколько вариантов архитектуры с их плюсами и минусами.
Еще одним осложняющим фактором стало требование минимизировать риски намеренной порчи данных внутри компании. Для этого мне пришлось изучить все предоставляемые внутренними платформами инструменты.
— Мы всегда надеемся, что оборудование и инфраструктура будут работать чётко, надёжно, и без поломок. Тем более в компаниях, где сбои ведут к большим финансовым потерям. Но без ошибок современные сервисы практически не бывают. В чем главные принципы построения отказоустойчивых систем?
— Главными принципами я считаю простоту и понятность архитектуры, мониторинг (нельзя управлять тем, что нельзя измерить), избыточность (дублирование критичных компонентов), автоматическое восстановление и выстраивание методик тестирования систем.
Простота и понятность архитектуры поможет совершить меньше ошибок при развитии системы. Мониторинг дает возможность научиться предсказывать отказ системы, или показывает факт ее отказа и последовательность событий.
Избыточность — это фундамент любой отказоустойчивой системы. Не зря в самолетах все критичные системы имеются минимум в трех экземплярах. Автоматическое восстановление сокращает время возможного отказа и экономит ресурсы. А тестирование системы на прочность позволяет заранее найти потенциально слабые места, снизив риск сбоев в те моменты, когда это может нанести наибольший урон.
— Какие условия необходимо соблюдать для разработки масштабируемой системы? Какие самые частые ограничения вам приходилось преодолевать?
— В масштабируемой системе критически важно с самого начала заложить правильную архитектуру данных и процессов. Она должна быть с четкими компонентами, понятными принципами горизонтального масштабирования и отказоустойчивостью.
В моей работе с масштабируемыми системами чаще всего я сталкивался с решениями на монолитной архитектуре, в которых можно выделить несколько тесно переплетенных компонентов. Также были проекты с накопленным техническим долгом, который не позволял системе эволюционировать.
И, конечно, база данных как точка отказа из-за отсутствия возможности горизонтального масштабирования и сложности миграции накопленных данных.
— В каких сферах сложнее всего создавать отказоустойчивые и масштабируемые системы?
— Чем выше нагрузка, требования к работе в реальном времени и цена ошибки, тем сложнее будет создать систему. Это сферы, связанные с здравоохранением, финансами (в том числе высокочастотной торговлей) и критическими для функционирования общества системами и инфраструктурой. Там требуется максимальная точность в решениях, поскольку любая ошибка сказывается на миллионах пользователей или ведет к финансовым потерям.
— Вы как-то отмечали, что предпочитаете оставаться Hands-on инженером и стараетесь оставлять время на разработку кода. При этом вы неоднократно участвовали в хакатонах как жюри (Good for tech, Summit Fall 2025), состоите в ассоциации AITEX…Как удается совмещать профессиональную деятельность с развитием индустрии?
— Да, приходится тратить заметную часть свободного от работы времени. Но, хочу отметить, что для меня есть понятная цель и мотивация — уменьшать ограничения разработки в целом и улучшать работу команды. Поэтому дополнительная нагрузка — это не еще одна «работа», а хобби.
Для меня это не две разные роли, а одна логичная экосистема. Я лучше чувствую реальные боли разработки, ограничения и контексты, в которых живут команды. Это позволяет быть полезным не только в коде, но и при оценке идей, продуктов и команд на хакатонах или в профессиональных сообществах.
Участие в жюри, ассоциациях и конкурсах к тому же расширяет кругозор: я вижу, куда движется рынок, какие подходы и технологии появляются. Могу осознанно привносить знания в свою работу.
