Денис Терехов, тимлид в Яндекс Еде, рассказал на митапе для разработчиков в Новосибирске о том, как его команда помогла курьерам быстрее доставлять заказы.
Всем привет! Меня зовут Денис Терехов и сегодня расскажу о том, как мы помогли курьерам доставлять больше заказов.
В 2024 году начал ощущаться дефицит курьеров, особенно зимой. Чтобы наш сервис работал как обычно, нам нужно было привлечь новых или повысить эффективность уже существующих — то есть сделать так, чтобы они могли доставлять больше заказов за меньшее время. Так мы дали курьерам велосипеды, и я расскажу, что из этого вышло.
Идея моего доклада во многом в том, что даже в таких больших и устоявшихся корпорациях, как Яндекс, есть внутренние стартапы со всеми атрибутами переделываний и сомнений. Когда мы бежим куда‑то, что‑то отметаем, ищем, постоянно изучаем новые технологии.
Из чего состоит цикл заказа в Яндекс Еде
Посмотрим на цикл заказов в Яндекс Еде: сначала вы открываете приложение, выбираете, что хотите поесть, и нажимаете «Заказать». Мы видим этот заказ, в ресторане начинают его готовить. Пока еда готовится, система ищет курьера. Курьер приходит в ресторан, забирает заказ и доставляет его клиенту.
Выглядит очень просто, но поиск курьера (dispatch) — большой и сложный процесс. Курьеров может не быть на точке, или они не успевают к назначенному времени доставить заказ. А ещё они пользуются своим приложением, которое называется PRO и с которым тоже нужно связать все процессы.
Но именно оптимизация скорости доставки может помочь нам сделать счастливее всех участников процесса доставки: если курьеры смогут быстрее доставлять заказы, то у них, у нас и у ресторанов будет больше прибыли, а люди станут ещё более сытыми и довольными.
Итак, мы поняли, что нужно ускорять цикл, и стали выдвигать гипотезы, как же нам помочь курьерам доставлять заказы быстрее и удобнее.
Идея первая: самокаты
Мы подумали: «О, у нас же есть уже сервис аренды самокатов! Можно выдать самокаты курьерам, и так они смогут доставлять заказы быстрее». Пошли к ребятам из сервиса, договорились о скидке для наших курьеров‑партнёров, быстренько собрали MVP и выпустили в прод.
Как это работает. Курьер заходит в приложение PRO, нажимает нужную кнопку, сообщая о готовности принимать заказы и развозить их. После этого открывает приложение Go и ищет доступный самокат. Эти две системы связываются между собой в бэкенде, и курьер может арендовать самокат за специальную цену — рубль в минуту.
Но у плана были серьёзные недостатки: на самокате приходится всё время стоять, а это неудобно, особенно с термосумкой на спине. А ещё самокаты не работают зимой. Стало ясно, что идея не подходит и надо что‑то менять.
Идея вторая: электровелосипеды
Решили попробовать сделать для курьеров электровелосипеды и стали представлять, каким этот электровелосипед должен быть.
Чего бы нам в целом хотелось от умного электровелосипеда:
управлять им из стандартного приложения для курьеров (PRO);
удалённо отслеживать его состояние (заряд аккумулятора, текущая скорость, местонахождение);
встроить его в цикл заказа (представьте, курьер везёт вам пиццу и на дисплее велосипеда видит подсказки, куда поворачивать, а также таймер, когда пицца остынет);
быстро и просто менять севший аккумулятор на полностью заряженный в определённых точках (своеобразные пит‑стопы);
и ещё кучу всего.
Поставили IoT‑модуль с самоката на велосипед, и стало возможным управлять ими через единое приложение. То есть курьеру необязательно открывать Яндекс Go — можно арендовать велосипед в PRO. Но возникла проблема — софт, на котором работают самокаты, — это софт в третьем поколении, созданный для управления машинами, из которого сначала сделали Яндекс Драйв, а потом уже адаптировали для самокатов. И мы ещё прикрутим велосипеды — получится Франкенштейн.
Справа велосипед или самокат, слева — какая‑то бизнес‑логика, которая управляет всем, и посередине телематика. Телематика — это набор сервисов, которые умеют транслировать наши команды и «общаться» с велосипедами. То есть в сервис приходят какие‑то высокоуровневые команды, и он умеет отправлять их на велосипеды.
Проблема в том, что IoT проприетарный, на жутко проприетарном протоколе. А протокол работает поверх TCP. То есть велосипед устанавливает TCP‑соединение с телематикой и туда начинает отправлять короткие, в несколько байтов, пакетики с флагами, признаками и так далее.
Протокол нерасширяемый, мы ограничены форматом этого пакета. Но больше всего смущает то, что это TCP. То есть велосипед устанавливает соединение с одним сервисом телематики, а на сервисе телематики ограничено количество TCP‑сессий. Соответственно, нужно делать несколько сервисов‑телематик. Чем больше велосипедов, тем больше сервисов.
Нужна дополнительная логика в бизнес‑части схемы для того, чтобы знать, к какому инстансу сервиса телематики сходить, чтобы «поговорить» с конкретным велосипедом. То есть несколько велосипедов подсоединяются к одному сервису телематики, но непосредственно к определённому велосипеду мы пойти сразу не можем. Для начала нужно понять, к какому сервису коннектится велосипед, и только потом можно будет отдать команду. Казалось бы, ничего сложного, но это построение лишней логики над всей системой. Да и есть риск, что пока мы выясняем, куда подсоединён велосипед, он может уже потерять связь или переподключиться к другому сервису.
Мы посмотрели, что можно сделать, и выбрали Yandex Cloud и сервис в нём, который называется IoT Core. Это набор инструментов для того, чтобы программировать Internet of Things, маленькие устройства, которыми можно управлять. И в этом наборе инструментов есть имплементация протокола MQTT. Как раз легковесный протокол на основе брокера, с помощью которого можно обмениваться сообщениями с велосипедом.
И вот мы пристроили в схему этот кусочек, который на рисунке отмечен серым, — это как раз облако. В MQTT можно организовывать топики: каждый велосипед получает топик, чтобы ему поступали команды, а через единый топик велосипеды могут «отвечать». И есть специализированный топик, через который велосипеды шлют телеметрию. Телеметрия — текущее состояние велосипеда, информация о том, где он находится, какой заряд аккумулятора, скорость, сколько килограмм он сейчас перевозит.
Серые значки сверху на схеме — структура самокатов, жёлтые внизу — наша инфраструктура. Получился наш небольшой прототип сервиса менеджмента, в который мы прикрутили свой биллинг.
Встроили свой сервис, запустили и потестили — всё работало отлично. Кроме одного нюанса: велосипеды просто не успели сделать в срок:)
Идея третья: агрегатор велосипедов
Когда мы поняли, что идея с электровелосипедом пока откладывается, стали думать, что можно сделать здесь и сейчас. Посмотрели: а ведь курьеры уже ездят на велосипедах, значит, арендуют их где‑то. Решили собрать все пункты аренды велосипедов в одном агрегаторе и дать курьерам доступ сразу ко всем возможным сервисам проката.
Выглядеть это должно было примерно так:
Курьер заходит в приложение PRO, открывает карту и выбирает точку, на которой есть доступные велосипеды. Затем он открывает слот, и появляется запрос на подтверждение бронирования.
Мы стали воплощать эту идею: отмели всё, что делали раньше, и собрали агрегатор. Он проще, чем наше первое приложение, — в нём остались только менеджмент и биллинг.
Вывод
Что можно сказать по итогу всех наших приключений? Не стоит бояться менять планы и адаптироваться к обстоятельствам. У нас была цель — сократить время доставки, и пока мы думали, планировали и пробовали её воплотить, менялись многие обстоятельства: оказывалось, что нужно писать новые протоколы, отложить идею с электровелосипедами, придумать новый агрегатор. И это нормально: даже в крупном бизнесе важно уметь маневрировать и не бояться этого, не думать, что что‑то не так, если ваша задумка не получилась сразу.
