История успеха: приложение по доставке еды с миллионом пользователей

12 ноября 2020

После переноса жизни в онлайн многие стали не только чаще мыть руки и больше времени проводить с семьей, но и идеально освоили покупки в онлайне. Будь то одежда, обувь, корм для животных или доставка еды из любимых ресторанов. И даже здесь команда NIX оказалась первой. Потому что она занималась разработкой приложения для доставки еды еще задолго до того, как это стало мейнстримом :). И эта история успеха как раз об этом.

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

Клиент NIX — один из крупнейших в Европе онлайн-реализаторов доставки продуктов, а также еды из кафе и ресторанов разных городов. Он может похвастаться партнерством с Uber, постоянно растущей аудиторией, огромным охватом городов и регионов. Когда два года назад Никсовая команда зашла на этот проект, он представлял из себя небольшой сайт с локальной доставкой, а сегодня это огромное приложение из большого количества компонентов в нескольких датацентрах, которое покрывает десятки разных городов.

1_2yp4-0f8xaqf8cpi0gfhrw

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

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

Вообще внутри проекта было четкое разделение команды. Кто-то занимался отдельной системой управления ресторанами, которая была (и есть) отдельной большой системой менеджмента всего ресторана (кухня, заказы, меню и многое другое — что-то похожее на R-Keeper). Была команда, которая занималась фронтендом сайта, команда по разработке приложения для курьеров, бекендеры, которые тоже делились на подразделения по направлениям: админка, логистика курьеров, заказы, интеграции, АПИшка. Мы с Филиппом занимались интеграцией нашей системы и совершенно разнообразных систем ресторанов-партнеров. Нам приходилось много общаться с техническими и нетехническими специалистами со стороны ресторанов.

Дима, Tech Lead

photo_2019-07-06_21-49-15

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

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

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

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

Огромные масштабы проекта и большое количество внешних участников накладывали отпечаток на эффективность работы и скорость реализации задач команды NIX. Даже из-за небольшой чужой ошибки всем разработчикам проекта приходилось мобилизоваться и всем вместе заниматься устранением неисправностей. Зато как это влияет на командный дух и настроение «один за всех и все за одного»!

Никсовые ребята применили множество асинхронных/фоновых процессов для обеспечения высокой рабочей эффективности приложения. Им предстояло внести сотни точных исправлений, поэтому с каждым днем росло количество модульных и интеграционных тестов, которые в конечном результате помогли добиться высоких результатов.

1_7kcibnd_bxewkmdtvliyvw

Мой главный совет: во всех вопросах будьте параноиком. А это означает отслеживать буквально все: место на дисках, загрузку ЦПУ и ОЗУ всех запущенных процессов, входящий и исходящий трафик. Проблемы могут прийти отовсюду: вы можете в любой момент подвергуться DDoS-атаке, сами разработчики могут написать неоптимальный запрос и создать высокую нагрузку на базу данных, запустить множество конкурирующих процессов, которые мешают друг другу. И таких примеров можно привести очень много. За всем этим следует следить, и следить автоматизированно. Поэтому технические (инфраструктурные) метрики и оповещения — это must have. Об этом стоит задуматься еще до начала проекта и сделать как можно раньше. Они помогут не только в ливе, но и на первых этапах разработки, станут отличным показателем, а не сделали ли вы хуже.

Что касается бизнес метрик, то для них должны быть созданы бизнес сущности, и именно с ними должны работать бизнес процессы. Забудьте об эфемерных запросах, сообщениях в распределенных системах и прочем короткоживущем и неосязаемом. Всё то, что помогает зарабатывать деньги, особенно долгоиграющие процессы, должно быть четко отражено в базе данных. И только это можно измерять теми или иными метриками.

Филипп, Senior Developer

Работа над этим проектом стала особым опытом для Никсовых ребят. Они не только использовали максимум своих знаний, но и приобрели крутой опыт, которым готовы поделиться с другими в виде списка полезных рекомендаций.

— Определите конкретные метрики для измерения уровня удобства интерфейса

Сделать это с помощью объективных метрик вам вряд ли удастся — придется разработать набор утилит для сбора метрик пользователей: что они смотрят, какие кнопки нажимают, достаточно ли места для достижения цели в интерфейсе.

— Не забывайте об интерфейсе администратора

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

— Грамотно определяйте технические метрики

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

— Логируйте все

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

— Учитывайте высокую нагрузку

Никогда не забывайте, что сервис неизбежно будет испытывать внезапный приток реальных пользователей (привет, карантин), который будет влиять на все: производительность серверов и серверного программного обеспечения, сетевое оборудование, трафик, квоты ресурсов, способность приложения обрабатывать конкурентные запросы. Разработчики должны задать себе несколько вопросов: что делать, если два оператора загружают одну и ту же страницу? Что если они оба отправят одну и ту же форму редактирования блюда? Что, если два клиента заказывают один и тот же товар? Ответ простой — будьте параноиком.

1_rxw4-ihu4s7tmrfmrsigsg

Сам по себе проект непростой, но в то же время и очень крутой, потому что это живой продукт, который не пилится в тишине на протяжении полугода, и только потом выходит в лив, а уже находится в активном пользовании, постоянно растет и бросает новые вызовы. Никсовая команда зашла на проект, когда у заказчика было около 200 000 заказов в день, а сегодня эта цифра превышает 1 000 000 заказов в день! Сервис постоянно растет, и ребята наверняка ощущают весомую нагрузку от того, что они пилят живой проект со всеми его внезапными сложностями и проблемами, которые периодически  появляются при выкатке обновлений. В эти «жаркие моменты» приходится несладко, но таковы реалии любого крупного продукта с миллионами пользователей. Именно такие случаи учат ребят оперативно и эффективно реагировать, брать ответственность за свои решения и с достоинством выходить из любых передряг :). Мне кажется, благодаря этому Никсовая команда очень выросла за это время и экспертно, и коммуникационно. Ребята перешли на другой уровень самостоятельности, вовлеченности. Думаю, они даже стали мыслить категорией продукта, а не категорией проекта. А это — высокий уровень профессионализма для любого разработчика :).

Рената, Project Manager

— Имейте в виду, что проекты имеют тенденцию расти

И вместе с этим будет увеличиваться и команда. А это — больше разнообразия в подходах к реализации кода и больше времени на ее интерпретацию.

— Регулярно проводите ревью кода

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

— Убедитесь, что ваш код легко удалить, а не настраивать

В подобных проектах часто бывает необходимо адаптироваться к изменениям требований как внутри проекта, так и во внешних сервисах, будь то платежная система или сторонняя ресторанная система. Такие изменения обычно происходят внезапно. Поэтому не пишите легко настраиваемый код — пишите легко удаляемый код. Чем проще выбросить старый код и написать новый, тем быстрее команда адаптируется к изменениям. Настраиваемый код все равно не будет адаптирован ко всем ситуациям, с которыми ему придется работать, но уже изначально будет более сложным.

620x462_1_b83e37af3eb5c7d39d937b7c1263224c1000x745_0xac120003_9447082041584040360

— Уделите внимание документации

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

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

Сейчас мы разрабатываем отдельный сервис (ранее был только один сервис — монолит), который будет выполнять задачи интеграции отдельно от основного функционала. Для нас это новая задача — разработать собственное, стабильное и быстрое приложение, которое будет подвержено высокой нагрузке, и интегрировать его с основным приложением. Общение выходит на новый уровень, с новыми условиями и ограничениями. Наша задача — сделать лучше, чем было, и мы обязательно справимся.

Филипп, Senior Developer

Уверены, что Никсовая команда справится с любыми вызовами, поэтому желаем ей побольше вдохновения, сил и возможностей для легкой реализации поставленных задач :).