Мы все знаем Glovo — сервис, который доставляет еду прямо к нашим дверям, и кажется, что он был с нами всегда. Истинный успех сервиса — в людях, работающих внутри компании, и один из них — украинский инженер Андрей Гуменюк. В этом интервью он объясняет, как помог превратить киевский офис Glovo из только что открытой локации в полноценный инженерный хаб в самом сердце глобальной платформы доставки и стал неотъемлемой частью повседневной жизни людей.
- Андрей, вы были одним из первых инженеров в украинском офисе Glovo. Какие были ваши основные обязанности на старте и с какими вызовами пришлось столкнуться, присоединившись к быстро растущей международной компании?
Когда я присоединился к Glovo, компания уже обслуживала десятки миллионов пользователей примерно в 20 странах, но почти все инженерные процессы все еще были сосредоточены в Испании. Украина только что была избрана новым региональным хабом, и я был одним из первых инженеров, ответственных за то, чтобы превратить это решение в реальный, готовый к продакшену инженерный центр.
Основным вызовом было то, что не существовало четкого «плейбука» для того, как настроить инфраструктуру нового регионального офиса и строить микросервисы, способные масштабироваться глобально. Поэтому нам пришлось адаптировать все — от инструментов деплоя до конфигураций сред — от настроек главного офиса Glovo до нашей новой реальности в Киеве.
Руководство Glovo назначило меня работать непосредственно с командами в Испании, отвечающими за инфраструктуру, заказы, партнеров и продукт. Моя задача заключалась в том, чтобы понять их архитектуру, их конвейеры CI/CD — автоматизированные процессы тестирования и деплоя кода — и их операционные стандарты. Моя цель заключалась в том, чтобы усвоить эти знания и привезти их к киевскому хабу, где они стали фундаментом для дальнейшего масштабного инженерного роста.
- Какие конкретные шаги вы предприняли, чтобы адаптировать глобальные инженерные стандарты Glovo к украинской среде, где инфраструктура и культура разработки значительно отличаются?
Когда мы запускались в Украине, Glovo уже имела хорошо установленные инженерные стандарты в Испании. Но в Киеве мы только строили хаб, и большинство инженеров были новичками во внутренних системах Glovo. Целью было взять эти глобальные стандарты и заставить их работать в совершенно новой среде.
Сначала я сосредоточился на том, чтобы понять, как все работает в Барселоне: как сервисы создаются, деплоятся и мониторятся в продакшене. Я улучшал конфигурации, разрешения и шаблоны под наш региональный облачный стек. Это позволило нашим инженерам в Киеве работать с такими же стандартами стабильности и тем же инструментарием, что и команды в главном офисе.
Вторым ключевым направлением было построение культуры, а не только инфраструктуры. Я организовывал сессии адаптации для первых инженеров, которых мы нанимали, проводя их через принципы продакшен-разработки Glovo.
Мы также внедрили шаблоны CI/CD и стандарты code review, соответствующие HQ, чтобы киевские инженеры могли самостоятельно деплоить и поддерживать сервисы, оставаясь в рамках глобальной системы надежности и безопасности Glovo.
- Насколько мне известно, результаты ваших персональных исследований были применены Glovo и другими компаниями. Какой была эта работа и какие результаты она принесла бизнесу?
Да, это правда. До присоединения к Glovo я был вовлечен в масштабные R&D-проекты в Национальном техническом университете Украины (КПИ), где мы работали над математическими и алгоритмическими моделями для управления и оптимизации облачных ИТ-инфраструктур.
Вместе эти проекты дали более 800 страниц аналитических отчетов. Целью было улучшение того, как большие распределенные ИТ-инфраструктуры распределяют ресурсы, управляют надежностью и реагируют на колебания нагрузки — короче говоря, сделать облачные системы более адаптивными, самооптимизирующимися и предсказуемыми.
Когда я присоединился к Glovo, эти идеи нашли прямое практическое применение. Многие вызовы, над которыми я работал в теории — балансировка нагрузки, оптимизация задержек, координация между кластерами — оказались именно теми проблемами, которые мы решали в продакшене.
Например, микросервис Partner Orders использовал принципы из моих исследований: асинхронную обработку на основе очередей, адаптивную логику повторных запросов и распределенное управление ресурсами. Реализация этих моделей уменьшила задержку обработки партнерских заказов примерно на 40%, снизила уровень ошибок на около 30% и увеличила пропускную способность почти в десять раз.
- Встречали ли ваши идеи сопротивление, и как вы убеждали коллег и руководство в их ценности?
В Glovo я продвигал инициативы, которые изменяли то, как инженерные команды измеряют качество и надежность: внедрение стандартов observability, переход к ответственности, основанной на SLO, и автоматизация потоков коммуникаций между поддержкой и партнерскими системами. Это были не мелкие улучшения — они меняли то, как люди работают и что такое «владение сервисом».
Сначала многие команды работали в реактивном режиме, то есть они реагировали на инциденты вручную, эскалировали проблемы в чатах и закрывали тикеты без четких структурированных метрик. Когда я предложил перейти к подходу в обеспечении надежности, основанном на данных, некоторые инженеры и менеджеры волновались, что это замедлит доставку или создаст лишнюю бюрократию.
Я показал, что на самом деле все было наоборот. Мы смогли уменьшить количество тикетов до партнерской поддержки, упростить эскалационные потоки и сделать решение инцидентов почти полностью автоматическим. Параллельно я работал с командами инфраструктуры и продукта в Испании, помогая им применить такие же инструменты и практики.
Результаты были ощутимыми. Количество партнерских тикетов уменьшилось примерно на 35%, среднее время решения улучшилось примерно на 75%, а удовлетворенность партнеров возросла на 20–25%. Что касается инфраструктуры, команды могли предоставлять услуги и масштабировать ресурсы за считанные минуты вместо часов, тогда как новые стандарты контроля и наблюдения сократили бюджеты на ошибки и улучшили скорость выявления инцидентов. Одновременно мы значительно сократили время обработки партнерских заказов.
Когда эти результаты стали очевидными, скепсис исчез. Стандартизация и автоматизация не замедляют инновации — они делают их масштабируемыми.
- Можете предоставить больше деталей о сокращении времени обработки партнерских заказов? Как это решение было реализовано и какой эффект оно имело на бизнес?
Когда я присоединился к Glovo, одной из самых больших проблем была задержка между тем, как ресторан получал заказ, и тем, как Glovo подтверждала его в системе доставки. Эта задержка создавала реальную операционную проблему: рестораны не могли вовремя начать готовить, курьеры ждали, а клиенты получали заказы позже. Это была не просто техническая неэффективность — она напрямую влияла на доходы, надежность и удовлетворенность партнеров.
Чтобы это исправить, мы спроектировали и внедрили отдельный микросервис Partner Orders, который отделил партнерскую коммуникацию от центральной системы заказов. Такая архитектура позволила обрабатывать обновления от ресторанов параллельно, убрав «узкое место», что замедляло систему.
Результаты были значительными. Задержка обработки снизилась примерно на 40% даже в пиковые часы. Количество ошибочных или сильно задержанных заказов уменьшилось примерно на 30%, что повысило надежность и удовлетворенность партнеров. Пропускная способность возросла почти в десять раз, что позволило подключать сотни ресторанов одновременно без заметной потери производительности.
Быстрое подтверждение заказов улучшило точность доставки, сократило время ожидания клиентов и укрепило доверие партнеров, что привело к более высокой удерживаемости и меньшему количеству отказов.
- Технологии развиваются очень быстро — от облачных платформ до микросервисов и ИИ. Как вы определяете, какие инновации стоит интегрировать в архитектуру, а какие лучше оставить для экспериментов?
В высоконагруженных, критически важных для продакшена системах, таких как Glovo, каждая новая технология должна доказать свою ценность, прежде чем получить место в продакшене. Я всегда считал, что инновации — это не погоня за новейшими инструментами, а выбор правильных — на правильном этапе их зрелости.
Мой подход начинается с трех уровней оценки.
Во-первых, согласованность с бизнесом. Решает ли технология реальную проблему или приносит измеримую ценность — ускорение доставки, снижение задержек, повышение продуктивности разработки или оптимизацию затрат?
Во-вторых, уровень операционной зрелости. Соответствует ли он нашим стандартам надежности, безопасности и наблюдаемости?
В-третьих, жизненный цикл и ответственность. Каждый новый компонент должен иметь четко определенного владельца и реалистичную траекторию долгосрочной поддержки.
- Ваш опыт сочетает создание высоконагруженных систем и управление инженерными командами. Как вы решаете, когда стоит погружаться в код лично, а когда влиять на продукт и процессы на стратегическом уровне?
Для меня инженерное лидерство — это о том, чтобы мыслить на двух уровнях — системном и стратегическом.
Обычно я принимаю решения, опираясь на влияние и рычаги. Когда вызов имеет системный характер — например, перепроектирование зон ответственности сервисов, оптимизация масштабирования кластеров или определение KPI для надежности — я перехожу к более стратегическому уровню влияния.
Но когда мы сталкиваемся с критическими техническими ограничениями — например, деградацией производительности при высокой параллельности, сложными миграциями или серьезными инцидентами надежности в продакшене — я предпочитаю погружаться в работу лично.
- Учитывая ваш опыт работы в международной компании, какие различия в инженерной культуре больше всего бросаются в глаза и чему, по вашему мнению, украинские инженеры могут научиться у глобальных команд?
Работа в глобальной организации, такой как Glovo, дала мне четкое понимание того, как инженерная культура влияет на способность компании масштабироваться. Наибольшая разница, которую я заметил, была не в технических навыках — украинские инженеры чрезвычайно сильны технически — а в том, как команды общаются, документируют и сами берут ответственность за результат.
В глобальных командах, особенно в Западной Европе, существует глубокая культура ясности и ответственности. Инженеры не просто пишут код — они владеют сервисом от начала до конца: его надежностью, метриками и влиянием на пользователя. В Украине инженеры известны скоростью, креативностью и способностью решать проблемы под давлением — качества, которые я очень ценю. Но иногда мы недооцениваем важность процессов и письменной коммуникации.
Если подытожить, я бы сказал так: у глобальных команд мы можем научиться дисциплине, долгосрочному мышлению и полному владению результатом. У украинских команд мир может научиться двигаться быстро, сохранять изобретательность и работать под давлением. Сочетание этих двух ментальностей создает инженерное дело мирового уровня — и именно это нам удалось построить в Glovo.
Автор интервью: Елизавета Лобанова
