Разработка сервиса "Экспресс-меню" Азбуки Вкуса

Главное о кейсе

"Экспресс Меню" — это сервис доставки готовых блюд от поваров Азбуки Вкуса. Проект на тысячи часов, с крутой командой и огромным потенциалом. Сайт, мобильные приложения, API, интеграции с Delivery Club и "Яндекс. Едой".

Как проект изменил жизнь пользователей

Быстрые, полезные и вкусные блюда, заказать которые можно через разные каналы. Мы создали платформу, сайт, интегрировали нужные системы, а после тестировали, мониторили, а потом еще раз тестировали.

Для партнерский сервисов Delivery Club и "Яндекс.Еда" разработали интеграционные API. Теперь партнеры работают с реальными остатками и ценами.

Бизнес-задача и ее решение

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

Крафт (мастерство), реализация, технические детали

AIC спроектировали UX и дизайн, Trinity собрали мобильное приложение, коллеги из Азбуки Вкуса занялись анализом и проектированием процессов, а мы в wpp.digital взялись за всю техническую часть проекта — платформа, REST-API, сайт, интеграции, тестирование, мониторинг, тестирование отказоустойчивости etc.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

"Экспресс Меню" — это многокомпонентный проект. Важно было выбрать правильную стратегию управления сложностью, чтобы не допустить ее экспоненциального роста. Если бы мы этого не сделали, то каждая из команд рано или поздно пыталась бы решить бизнес-задачу на своей стороне. Это привело бы к одному из 2-х исходов:

1. задачу никто не решил;

2. ее решили все одновременно и по-разному.

Мы выбрали подходы тонкого клиента на front-end-е и бизнес-логики на back-end-е. Это значит, что:

> сайт и мобильные приложения только отображают данные, а не принимают бизнес-решения;

> API — это транспорт для интеграций;

> платформа — это логика и интеграции.

Мы выбрали именно такую стратегию, потому что продукт неизбежно меняется в ходе разработки. Если логика будет "размазана" по компонентам — стоимость изменений продукта в будущем будет высокой. Такой же высокой станет вероятность ошибки.
Теперь посмотрим под капот. Внутри сервис спроектирован из разных узлов — веб-серверы, система поиска, базы данных, планировщики, кеши etc. И для каждого нужно:

> резервирование — когда выходит из строя основной сервер, нужно прозрачно переключиться на резервный;

> бекап и быстрое восстановление.

В обязательном порядке заложили возможность мониторинга узлов проекта и логирование всех событий. Теперь мы могли понимать, что происходит в каждом узле большой системы: обнаруживать неисправности, понимать, где они, и оперативно их исправлять. Подключили систему мониторинга, которая в реальном времени сообщала, когда что-то на проекте идет не так. Например, вызов API отвечает дольше, чем мы определили в SLA, или заказы отгружаются в систему учета более положенного времени.
Для удобства разделили мониторинг технических показателей серверов и мониторинг бизнес-активности проекта, чтобы ошибки сразу распределялись по релевантным отделам. Так статусы резервного копирования, метрики баз данных и веб-серверов оказались на плечах команды админов, а вся информация о бизнес-показателях на команде поддержки проекта. Последние получали оповещения по E-mail и СМС-каналам.

Так каждое бизнес-событие стало логироваться. Каждую проблему пользователя мы могли детально изучить и после решить.

Скриншоты