Ми всі знаємо 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.
Автор інтерв’ю: Єлізавета Лобанова
