Після перенесення життя в онлайн багато хто став не тільки частіше мити руки і більше часу проводити з сім’єю, але й ідеально освоїв покупки в онлайні. Чи це одяг, взуття, корм для тварин або доставка їжі з улюблених ресторанів. І навіть тут команда NIX виявилася першою. Тому що вона займалася розробкою додатка для доставки їжі ще задовго до того, як це стало мейнстримом :). І ця історія успіху якраз про це.

І ось вам трохи спойлерів: це був крутий проект зі складними завданнями та оригінальними способами їх вирішення.  Сьогодні він перетворився вже на новий проект з розробки окремої програми з великими навантаженнями на API.  За два роки Ніксовій команді з 9 людей вдалося вразити замовника, змінити роль саппортера на роль одного з ключових розробників, а також зробити ще багато чого, про що ви дізнаєтеся сьогодні.

Клієнт NIX – один з найбільших у Європі онлайн-реалізаторів доставки продуктів, а також їжі з кафе та ресторанів різних міст. Він може похвалитися партнерством з Uber, аудиторією, що постійно зростає, величезним охопленням міст і регіонів. Коли два роки тому Ніксова команда зайшла на цей проект, він представляв собою невеликий сайт з локальною доставкою, а сьогодні це величезна програма з великої кількості компонентів у кількох датацентрах, яка покриває десятки різних міст.

Команді NIX належало забезпечити працездатність системи при повному завантаженні та реалізувати бездоганну інтеграцію зі сторонніми API.  Згодом завдання структурно трансформувалися і перейшли на більш мікросервісну архітектуру — хлопцям належало розробити окремий сервіс інтеграції, який сьогодні вже готовий до ливу, але давайте про все по порядку.

Ми з Філіпом були першими, хто зайшов у цей проект із Ніксів. І зайшли ми до команди інтеграцій. На думку замовника це була найбільш чорнова робота з усіх, адже на той момент проект був тільки-но викуплений, а жодного вибухового зростання його популярності не було.

Загалом усередині проекту був чіткий поділ команди. Хтось займався окремою системою управління ресторанами, яка була (і є) окремою великою системою менеджменту всього ресторану (кухня, замовлення, меню та багато іншого – щось схоже на R-Keeper). Була команда, яка займалася фронтендом сайту, команда з розробки додатка для кур’єрів, бекендери, які теж ділилися на підрозділи за напрямками: адмінка, логістика кур’єрів, замовлення, інтеграція, АПІшка. Ми з Філіпом займалися інтеграцією нашої системи та абсолютно різноманітних систем ресторанів-партнерів. Нам доводилося багато спілкуватися з технічними та нетехнічними спеціалістами з боку ресторанів.

Діма, Tech Lead

Сама система додатку дуже велика, тому постійно перебуває у стані оптимізації та покращення, знятті метрик та інших процесів. Курує роботу та розставляє пріоритети сторона клієнта, вона ж займається менеджерством. Тому й завдання перед Ніксовою командою стояли не найпростіші:

— Стороння інтеграція. Необхідно було налаштувати підтримку інтеграції та взаємодії системи із сторонніми API партнерів та забезпечити стабільну роботу.

— Високі навантаження. Включали забезпечення високого завантаження системи та її інтеграцію з мобільним додатком.

— Структуризація системи. Складалася з адаптації структур партнерських систем та циклу існуючої платформи, що забезпечує надання статистики та звітності.

Величезні масштаби проекту та велика кількість зовнішніх учасників накладали відбиток на ефективність роботи та швидкість реалізації завдань команди NIX. Навіть через невелику чужу помилку всім розробникам проекту доводилося мобілізовувати сь і всім разом займатися усуненням несправностей. Проте, як це впливає на командний дух та настрій “один за всіх і всі за одного”!

Ніксівці застосували велику кількість асинхронних / фонових процесів для забезпечення високої робочої ефективності додатку. Їм потрібно було внести сотні точних виправлень, тому з кожним днем зростала кількість модульних та інтеграційних тестів, які зрештою допомогли досягти високих результатів.

Моя головна порада: у всіх питаннях будьте параноїком. А це означає відслідковувати буквально все: місце на дисках, завантаження ЦП та ОЗП всіх запущених процесів, вхідний та вихідний трафік. Проблеми можуть прийти звідусіль: ви можете в будь-який момент зазнати DDoS-атаки, самі розробники можуть написати неоптимальний запит і створити високе навантаження на базу даних, запустити безліч конкуруючих процесів, які заважають один одному. І таких прикладів можна навести дуже багато. За всім цим слід стежити і стежити автоматизовано. Тому технічні (інфраструктурні) метрики та оповіщення – це must have. Про це варто замислитися ще до початку проекту та зробити якомога раніше. Вони допоможуть не тільки в ливі, а й на перших етапах розробки, стануть відмінним показником, а чи не зробили ви гірше.

Що стосується бізнес-метрик, то для них повинні бути створені бізнес сутності, і саме з ними мають працювати бізнес-процеси. Забудьте про ефемерні запити, повідомлення в розподілених системах та все інше короткочасне і невловиме. Все те, що допомагає заробляти гроші, особливо довготривалі процеси, має бути чітко відображено в базі даних. І лише це можна вимірювати тими чи іншими метриками.

Філіп, Senior Developer

Робота над цим проектом стала особливим досвідом для Ніксових хлопців. Вони не тільки використали максимум своїх знань, але і здобули крутий досвід, яким готові поділитися з іншими у вигляді списку корисних рекомендацій.

— Визначте конкретні метрики для вимірювання рівня зручності інтерфейсу

Зробити це за допомогою об’єктивних метрик вам навряд чи вдасться — доведеться розробити набір утиліт для збору метрик користувачів: на що вони дивляться, які кнопки натискають, чи достатньо місця для досягнення мети в інтерфейсі.

— Не забувайте про інтерфейс адміністратора

Адміністративний інтерфейс та утиліти є основними інструментами, про які дуже часто забувають.  Важливо постійно його розвивати та вдосконалювати.  Той факт, що ви можете заощадити пару секунд для певної операції, може здатися не вражаючим, але уявіть, що ця цифра множиться на кількість співробітників кол-центру.  Це досить амбітний показник, який може дати можливість отримувати, обробляти та доставляти замовлення швидше, ніж конкуренти.

— Грамотно визначайте технічні метрики

Метрики такого типу допоможуть не тільки у майбутньому, а й на перших етапах розробки.  Ви зможете визначити, чи ваші дії будуть покращувати, а не погіршувати проект.

— Логуйте все

Записуйте все, що робить додаток, тому що іноді це єдиний інструмент для діагностики проблеми.  Реєструйте те, що ви відправляєте через мережу, що ви отримуєте з мережі, призначайте цим даним унікальні ідентифікатори, щоб пов’язати відправлення та отримання, логуйте розгалуження в алгоритмах — це допоможе зрозуміти, чому додаток зробив саме те, що зробив, а не навпаки. 

— Враховуйте високе навантаження

Ніколи не забувайте, що сервіс неминуче відчуватиме раптовий приплив реальних користувачів (привіт, карантин), який впливатиме на все: продуктивність серверів та серверного програмного забезпечення, мережеве обладнання, трафік, квоти ресурсів, здатність додатку обробляти конкурентні запити.  Розробники повинні поставити собі кілька запитань: що робити, якщо два оператори завантажують одну й ту саму сторінку?  А якщо вони обидва відправлять ту саму форму редагування страви?  Що, якщо два клієнти замовляють один і той самий товар?  Відповідь проста —будьте параноїком.

Сам по собі проект непростий, але водночас і дуже крутий, тому що це живий продукт, який не “пиляється” в тиші протягом півроку, і лише потім виходить у лив, а вже перебуває в активному користуванні, постійно зростає та кидає нові виклики.  Ніксова команда зайшла на проект, коли замовник мав близько 200 000 замовлень на день, а сьогодні ця цифра перевищує 1 000 000 замовлень на день!  Сервіс постійно зростає, і деви, напевно, відчувають вагоме навантаження від того, що вони “пилять” живий проект з усіма його раптовими складнощами та проблемами, які періодично з’являються при викатуванні оновлень.  У ці “спекотні моменти” доводиться несолодко, але такими є реалії будь-якого великого продукту з мільйонами користувачів.  Саме такі випадки вчать розробників оперативно і ефективно реагувати, брати відповідальність за свої рішення і з гідністю виходити з будь-яких негараздів:).  Мені здається, що завдяки цьому Ніксова команда дуже виросла за цей час і експертно, і комунікаційно.  Ніксівці перейшли на інший рівень самостійності, залученості.  Думаю, вони навіть стали мислити категорією продукту, а не категорією проекту.  А це високий рівень професіоналізму для будь-якого розробника :).

Рената, Project Manager

— Майте на увазі, що проекти мають тенденцію зростати

 І разом із цим збільшуватиметься і команда.  А це — більше різноманітності у підходах до реалізації коду та більше часу на його інтерпретацію.

— Регулярно проводьте перегляд (рев’ю) коду

 Адекватний та аргументований перегляд коду забезпечує обмін досвідом та практикою, узагальнює підхід до вирішення завдань.

 — Переконайтеся, що ваш код легко видалити, а не налаштовувати

У подібних проектах часто буває необхідно адаптуватися до змін вимог як усередині проекту, так і у зовнішніх сервісах, чи то платіжна система або стороння ресторанна система.  Такі зміни зазвичай відбуваються раптово.  Тому не пишіть код, що легко налаштовується — пишіть код, що легко видаляється.  Що простіше викинути старий код і написати новий, то швидше команда адаптується до змін.  Код, що настроюється, все одно не буде адаптований до всіх ситуацій, з якими йому доведеться працювати, але вже з самого початку буде складнішим.

— Приділіть увагу документації

Чим більше людей залучено до проекту, тим критичнішою стає відсутність технічної документації.  Команди можуть втратити не лише години, а й дні, намагаючись зрозуміти, про що йдеться.  Те саме відбувається, коли документація відсутня, або, що ще гірше, коли вона застаріла.  Для цього в NIX є ефективна практика — для кожного великого функціоналу створювати +1 завдання з оновлення документації.

За останніми даними, цей додаток вже доступний в 33 містах і охоплює 17 000 ресторанів, включаючи міжнародні франшизи на кшталт McDonald’s і TGI Fridays.  Постійне зростання кількості користувачів і партнерів додатку говорить про те, що він має адаптуватися до нових систем і мати можливість інтегрувати їх у велику систему.  А значить, попереду у Ніксівців ще буде над чим попрацювати :).

Зараз ми розробляємо окремий сервіс (раніше був лише один сервіс – моноліт), який виконуватиме завдання інтеграції окремо від основного функціоналу.  Для нас це нове завдання — розробити власний, стабільний і швидкий додаток, який буде працювати під високим навантаженням, і інтегрувати його з основним додатком.  Спілкування виходить на новий рівень, з новими умовами та обмеженнями.  Наше завдання зробити краще, ніж було, і ми обов’язково впораємося.

Філіп, Senior Developer

Упевнені, що Ніксова команда впорається з будь-якими викликами, тому бажаємо їй більше натхнення, сил та можливостей для легкої реалізації поставлених завдань:).