Русский
Русский
English
Статистика
Реклама

Engineering culture

Вначале был монолит как мы меняем нашу архитектуру, не мешая бизнесу

18.09.2020 16:04:09 | Автор: admin


Всем привет! Меня зовут Игорь Наразин, я тим-лид команды в направлении логистики Delivery Club. Хочу рассказать, как мы строим и трансформируем нашу архитектуру и как это влияет на наши процессы в разработке.

Сейчас Delivery Club (как и весь рынок фудтеха) растёт очень быстро, что порождает огромное количество вызовов для технической команды, которые можно обобщить двумя самыми важными критериями:

  • Нужно обеспечивать высокую стабильность и доступность всех частей платформы.
  • Одновременно с этим держать высокий темп разработки новых фич.

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

Но нам удаётся (пока) и то, и другое. О том, как мы это делаем, и пойдет речь далее.

Во-первых, я расскажу про нашу платформу: как мы её трансформируем с учетом постоянно растущих объемов данных, какие критерии предъявляем к нашим сервисами и с какими проблемами сталкиваемся на этом пути.

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

Начнём с платформы.

Вначале был монолит


Первые строчки кода Delivery Club были написаны 11 лет назад, и в лучших традициях жанра архитектура представляла собой монолит на PHP. Он в течение 7 лет всё больше и больше наполнялся функциональностью, пока не столкнулся с классическими проблемами монолитной архитектуры.

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

  • любой отказ или проблема в монолите отразится на абсолютно всех наших процессах;
  • монолит жёстко завязан на определенный стек, который нельзя менять;
  • с учетом роста команды разработки вносить изменения становится сложно: высокая связанность компонентов не даёт быстро доставлять фичи;
  • монолит невозможно гибко масштабировать.

Это привело нас к (сюрприз) микросервисной архитектуре про её достоинства и недостатки уже много сказано и написано. Главное, что она решает одну из наших основных проблем и позволяет добиться максимальной доступности и отказоустойчивости всей системы. Я не буду на этом останавливаться в текущей статье, вместо этого расскажу на примерах, как мы это сделали и почему.

Наша основная проблема заключалась в размере кодовой базы монолита и слабой экспертизе команды в ней (платформу мы так и называем old). Конечно, сначала мы хотели просто взять и распилить монолит, чтобы полностью решить вопрос. Но очень быстро поняли, что на это уйдёт не один год, причем количество изменений, которые туда вносятся, не позволят этому закончиться никогда.

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

Экосистема


Как рассказывал Андрей Евсюков в статье про наши команды, у нас выделены главные направления по доменным областям: R&D, Logistics, Consumer, Vendor, Internal, Platform. В рамках этих направлений уже сосредоточены основные доменные области, с которыми работают сервисы: например, для Logistics это курьеры и заказы, а для Vendor рестораны и позиции.

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

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

Низкие нагрузки, синхронные запросы, всё работает круто.

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


Высокие нагрузки, синхронные запросы: страдают все, даже пользователи абсолютно других доменов курьеры.

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

Шина данных


Таким образом, у нас получилась масса узких мест, где за данными мы обращались в синхронном режиме. Эти места были очень опасными с точки зрения роста нагрузки.

Вот пример. Кто хоть раз делал заказ через Delivery Club, знает, что после того, как курьер забрал заказ, становится видна карта. На ней можно отслеживать передвижение курьера в реальном времени. Для этой фичи задействовано несколько микросервисов, основные из них:

  • mobile-gateway, который является backend for frontend для мобильного приложения;
  • courier-tracker, который хранит логику получения и отдачи координат;
  • logistics-couriers, который хранит эти координаты. Они присылаются из мобильных приложений курьеров.



В первоначальной схеме это всё работало синхронно: запросы из мобильного приложения раз в минуту шли через mobile-gateway к сервису courier-tracker, который обращался к logistics-couriers и получал координаты. Конечно, в этой схеме было не всё так просто, но в итоге всё сводилось к простому выводу: чем больше у нас активных заказов, тем больше запросов на получение координат приходило в logistics-couriers.

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

Транспорт


Мы уже использовали RabbitMQ, в том числе для общения между сервисами. Но в качестве основного вида транспорта мы остановились на уже хорошо зарекомендовавшем себя инструменте Apache Kafka. Про него мы напишем отдельную подробную статью, а сейчас я бы хотел кратко рассказать о том, как мы его используем.

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

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

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

Для решения этой проблемы мы написали обёртку микросервис на Go, который скрыл Kafka за своим API. Это добавило два преимущества:

  • валидация данных в момент отправки и приёма. По сути, это одни и те же DTO, поэтому мы всегда уверены в формате ожидаемых данных.
  • быстрая интеграция наших сервисов с этим транспортом.

Таким образом, работа с Kafka стала максимально абстрагированной для наших сервисов: они лишь работают с верхнеуровневым API этой обёртки.

Вернёмся к примеру


Переводя синхронное взаимодействие на шину событий, нам необходимо инвертировать поток данных: то, за чем мы обращались, должно теперь само попадать к нам через Kafka. В примере речь идёт о координатах курьера, для которых теперь мы заведём специальный топик и будем продюсить их по мере получения от курьеров сервисом logistics-couriers.

Сервису courier-tracker остаётся аккумулировать координаты в нужном объёме и на нужный срок. В итоге наш эндпоинт становится максимально простым: взять данные из базы сервиса и отдать их мобильному приложению. Рост нагрузки на неё теперь для нас безопасен.



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

Eventually consistency


В этом примере всё работает круто, за исключением того, что координаты курьеров будут не всегда актуальными по сравнению с синхронным вариантом: в архитектуре, построенной на асинхронном взаимодействии, встаёт вопрос об актуальности данных в каждый момент времени. Но у нас не так много критичных данных, которые нужны держать всегда свежими, поэтому нам эта схема идеально подходит: мы жертвуем актуальностью какой-то информации ради увеличения уровня доступности системы. Но мы гарантируем, что в конечном счёте во всех частях системы все данные будут актуальны и консистентны (eventually consistency).

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



Таким образом, мы четко разделяем наши сервисы на те, что являются мастерами данных и те, кто использует эти данные. По сути, это headless commerce из evolutionary archicture у нас четко отделены все витрины (сайт, мобильные приложения) от производителей этих данных.

Денормализация


Ещё пример: у нас есть механизм таргетированных уведомлений курьерам это сообщения, которые придут им в приложение. На стороне бэкенда есть мощное API для отправки таких уведомлений. В нём можно настраивать фильтры рассылки: от конкретного курьера до групп курьеров по определённым признакам.

За эти уведомления отвечает сервис logistics-courier-notifications. После того, как он получил запрос на отправку, его задача сгенерировать сообщения для тех курьеров, которые попали в таргетинг. Для этого ему необходимо знать нужную информацию по всем курьерам Delivery Club. И у нас есть два варианта для решения этой задачи:

  • сделать эндпоинт на стороне сервиса мастера данных по курьерам (logistics-couriers), который по переданным полям сможет отфильтровать и вернуть нужных курьеров;
  • хранить всю нужную информацию прямо в сервисе, потребляя её из соответствующего топика и сохраняя те данные, по которым нам в дальнейшем нужно будет фильтровать.

Часть логики генерации сообщений и фильтрования курьеров не является нагруженной, она выполняется в фоне, поэтому вопроса о нагрузках на сервис logistics-couriers не стоит. Но если выбрать первый вариант, мы столкнёмся с набором проблем:

  • придётся поддерживать узкоспециализированный эндпоинт в стороннем сервисе, который, скорее всего, понадобится только нам;
  • если выбрать слишком широкий фильтр, то в выборку попадут вообще все курьеры, которые просто не поместятся в HTTP-ответ, и придётся реализовывать пагинацию (и итерировать по ней при опросе сервиса).

Очевидно, что мы остановились на хранении данных в самом сервисе. Он автономно и изолированно выполняет всю работу, никуда не обращаясь, а только аккумулируя все нужные данные у себя из топика Kafka. Есть риск, что мы получим сообщение о создании нового курьера позднее, и он не попадёт в какую-то выборку. Но этот недостаток асинхронной архитектуры неизбежен.

В итоге у нас сформулированы несколько важных принципов к проектированию сервисов:

  • У сервиса должна быть конкретная ответственность. Если для его полноценного функционирования нужен ещё сервис, то это ошибка проектирования, их нужно либо объединять, либо пересматривать архитектуру.
  • Критично смотрим на любые синхронные обращения. Для сервисов в одном направлении это допустимо, но для общения между сервисами разных направлений нет
  • Share nothing. Мы не ходим в БД сервисов в обход них самих. Все запросы только через API.
  • Specification First. Сначала описываем и утверждаем протоколы.

Таким образом, итеративно трансформируя нашу систему согласно принятым принципам и подходам, мы пришли к такой архитектуре:



У нас уже есть шина данных в виде Kafka, которая уже имеет существенное количество потоков данных, но всё ещё остаются синхронные запросы между направлениями.

Как мы планируем развивать нашу архитектуру


Delivery club, как я говорил вначале, быстро растёт, мы релизим в прод огромное количество новых фич. А ещё больше экспериментируем (подробно об этом рассказал Николай Архипов) и тестируем гипотезы. Это всё порождает огромное количество источников данных и ещё больше вариантов их использования. А правильное управление потоками данных, которые очень важно грамотно выстроить это и есть наша задача.

Дальше мы будем продолжать внедрять выработанные подходы во все сервисы Delivery Club: строить экосистемы сервисов вокруг платформы с транспортом в виде шины данных.

Первоочередная задача добиться того, чтобы информация по всем доменам системы поставлялась в шину данных. Для новых сервисов с новыми данными это не проблема: на этапе подготовки сервиса он будет обязан стримить данные своего домена в Kafka.

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

Поэтому для старых сервисов мы решили использовать Debezium, который позволяет стримить информацию напрямую из таблиц на основе bin-log: в итоге получается готовый топик с сырыми данными из таблицы. Но они непригодны для использования в исходном виде, поэтому через трансформеры на уровне Kafka они будут преобразованы в понятный для потребителей формат и запушены в новый топик. Таким образом, у нас будет набор приватных топиков с сырыми данными из таблиц, который будет трансформироваться в удобный формат и транслироваться в публичный топик для использования потребителями.



Получится несколько точек входа на запись в Kafka и разные типы топиков, поэтому дальше мы реализуем на стороне хранилища права доступа по ролям и добавим валидацию схем на стороне шины данных через Confluent.

Дальше из шины данных сервисы будут потреблять данные из нужных топиков. И мы сами будем использовать эти данные для своих систем: например, стримить через Kafka Connect в ElasticSearch или в DWH. С последним процесс будет сложнее: чтобы информация в нём была доступна для всех, её необходимо очистить от любых персональных данных.

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

Как заниматься таким рефакторингом прозрачно для клиентов


Расскажу на ещё одном примере: каталоге ресторанов. Очевидно, что это очень нагруженное место, и мы решили выносить его в отдельный сервис на Go. Для ускорения разработки мы поделили вынос на два этапа:

  1. Сначала внутри сервиса ходим напрямую в реплику базы нашего монолита и получаем оттуда данные.
  2. Затем начинаем стримить нужные нам данные через Debezium и аккумулировать в базе самого сервиса.



Когда сервис готов, встаёт вопрос о том, как его прозрачно встроить в текущий рабочий процесс. Мы использовали схему со сплитом трафика: с клиентов весь трафик шёл в сервис mobile-gateway, а дальше делились между монолитом и новым сервисом. Изначально мы продолжали весь трафик обрабатывать через монолит, но часть дублировали в новый сервис, сравнивали их ответы и записывали логи о расхождениях в наши метрики. Этим мы обеспечили прозрачность тестирования сервиса в боевых условиях. После этого оставалось только постепенно переключать и наращивать на нём трафик, пока новый сервис полностью не вытеснит монолит.

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

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

Архитектурный комитет


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

Это порождает как реальные проблемы (сервис не выдерживал нагрузки из-за неправильного проектирования), так и концептуальные (а давайте здесь ходить синхронно, нагрузка же маленькая).

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

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

В итоге, проблему с контролем крупных изменений мы закрыли, остаётся вопрос общего подхода к качеству кода в Delivery Club: конкретные проблемы кода или фреймворка в разных командах могут решаться по-разному. Мы пришли к гильдиям по модели Spotify: это объединения неравнодушных к какой-то технологии людей. Например, есть гильдии Go, PHP и Frontend.

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

Код на прод


Кроме того, что крупные изменения проходят через архитектурный комитет, а за культурой кода в целом следят гильдии, у нас ещё есть важный этап подготовки сервиса к продакшену: составление чек-листа в Confluence. Во-первых, составляя чек-лист, разработчик ещё раз оценивает свое решение; во-вторых, это требование эксплуатации, так как им нужно понимать, что за новый сервис появляется в продакшене.

В чек-листе обычно указывается:

  • ответственный за сервис (это обычно тех-лид сервиса);
  • ссылки на дашборд с настроенными алертами;
  • описание сервиса и ссылка на Swagger;
  • описание сервисов, с которым будет взаимодействовать;
  • предполагаемая нагрузка на сервис;
  • ссылка на health-check. Это URL, по которому служба эксплуатации настраивает свои мониторинги. Health-check раз в какой-то период дёргается: если вдруг он не ответил с кодом 200, значит, с сервисом что-то не так и к нам прилетает алерт. В свою очередь, health check может дёргать такие же URLы критичных для него сервисов, а также обязательно включать проверку всех компонентов сервиса, например, PostgreSQL или Redis.

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

Для примера можно взять уже рассмотренный выше сервис courier-tracker, отслеживающий курьеров на карте. Одна из основных метрик в нём это количество курьеров, у которых обновляются координаты. Если вдруг какие-то маршруты долго не обновляются, приходит алерт что-то пошло не так. Может быть, где-то за данными не сходили, или неправильно зашли в базу, или отвалился какой-нибудь другой сервис. Это не техническая метрика и не продуктовая, но она показывает жизнеспособность сервиса.

Для метрик мы используем Graylog и Prometheus, строим дашборды и настраиваем алерты в Grafana.

Несмотря на объём подготовки, доставка сервисов в прод достаточно быстрая: все сервисы изначально упакованы в Docker, в stage выкатываются автоматически после формирования типизированного чарта для Kubernetes, а дальше всё решается кнопкой в Jenkins.

Выкатка нового сервиса в прод заключается в назначении задачи на админов в Jira, в которой предоставляется вся информация, которую мы подготовили ранее.

Под капотом


Сейчас у нас 162 микросервиса, написанные на PHP и Go. Они распределились между сервисами примерно 50% на 50%. Изначально мы переписали на Go некоторые высоконагруженные сервисы. Дальше стало ясно, что Go проще в поддержке и мониторинге в продакшене, у него низкий порог входа, поэтому в последнее время мы пишем сервисы только на нём. Цели переписать на Go оставшиеся PHP-сервисы нет: он вполне успешно справляется со своими функциями.

В PHP-сервисах у нас Symfony, поверх которого мы используем свой небольшой фреймворк. Он навязывает сервисам общую архитектуру, благодаря которой мы снижаем порог входа в исходный код сервисов: какой бы сервис вы ни открыли, всегда будет понятно, что и где в нём лежит. А также фреймворк инкапсулирует слой транспорта общения между сервисами, для разработчика запрос в сторонний сервис выглядит на высоком уровне абстракции:
$courierResponse = $this->courierProtocol->get($courierRequest);
Здесь мы формируем DTO запроса ($courierRequest), вызываем метод объекта протокола конкретного сервиса, который является обёрткой над конкретным эндпоинтом. Под капотом наш объект $courierRequest преобразуется в объект запроса, который заполняется полями из DTO. Это всё гибко настраивается: поля могут подставляться как в заголовки, так и в сам URL запроса. Далее запрос посылается через cURL, получаем объект Response и обратно его трансформируем в ожидаемый нами объект $courierResponse.

Благодаря этому разработчики сосредоточены на бизнес-логике, без подробностей взаимодействия на низком уровне. Объекты протоколов, запросов и ответов сервисов лежат в отдельном репозитории SDK этого сервиса. Благодаря этому, любой сервис, который захочет использовать его протоколы, получит весь типизированный пакет протоколов после импорта SDK.

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

В итоге, изменения в протоколе сервиса могут превратиться в несколько пулл-реквестов: в сам сервис, в его SDK, и в сервис, которому нужен этот протокол. В последнем нам нужно поднять версию импортированного SDK, чтобы туда попали изменения. Это часто вызывает вопросы у новых разработчиков: Я ведь только изменил параметр, почему мне нужно делать три реквеста в три разных репозитория?!

В Go всё сильно проще: у нас есть отличный генератор кода (Сергей Попов написал об этом подробную статью), благодаря которому весь протокол типизирован, и сейчас даже обсуждается вариант с хранением всех спецификаций в отдельном репозитории. Таким образом, если кто-то меняет спеку, все зависящие от неё сервисы сразу начнут использовать обновлённый вариант.

Технический радар




Кроме уже упомянутых Go и PHP мы используем огромное количество других технологий. Они варьируются от направления к направлению и зависят от конкретных задач. В основном, на бэкенде у нас используются:

  • Python, на котором пишет команда Data Science.
  • Kotlin и Swift для разработки мобильных приложений.
  • PostgreSQL в качестве базы данных, но на некоторых старых сервисах всё ещё крутится MySQL. В микросервисах используем несколько подходов: для каждого сервиса своя БД и share nothing мы не ходим в базы данных в обход сервисов, только через их API.
  • ClickHouse для узкоспециализированных сервисов, связанных с аналитикой.
  • Redis и Memcached в качестве in-memory хранилищ.


При выборе технологии мы руководствуемся специальными принципами. Одним из основных требований является Ease of use: используем максимально простую и понятную технологию для разработчика, по возможности придерживаясь принятого стека. Для тех, кто хочет узнать весь стек конкретных технологий, у нас составлен очень подробный техрадар.

Long story short


В итоге от монолитной архитектуры мы перешли к микросервисной, и сейчас уже имеем группы сервисов, объединенных по направлениям (доменным областям) вокруг платформы, которая является ядром и мастером данных.

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

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

На этом у меня всё, спасибо, что дочитали!
Подробнее..

Зачем нам 170 разработчиков

21.07.2020 14:09:04 | Автор: admin
image

Привет, Хабр! Меня зовут Андрей Евсюков, я заместитель CTO в Delivery Club. Наша компания устроена сложнее, чем может показаться, когда представляешь себе сервис по доставке еды. Даже когда примерно знаешь, что там может быть под капотом.

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

В каждой из статей я подробно опишу, как мы работаем в DC Tech. При этом каждая из этих статей будет логичным следствием того, как устроен рынок FoodTech в России и какие ограничения он накладывает. В первую очередь, рынок влияет на культуру компании, а следовательно, и на инженерную культуру. Особенности культуры диктуют нам те решения, к которым мы пришли. Вот про эти особенности и поговорим. Поехали!

Начну со статьи про особенности индустрии foodtech, которые напрямую влияют на то, как всё организовано внутри Delivery Club. И в процессе постараюсь объяснить, для чего нам 170 разработчиков и почему это не может быть просто outsource.

Особенности FoodTech в России и отличия от классического e-commerce


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

Доставка еды сильно отличается от большинства других доставок


Давайте рассмотрим доставку канцелярии, книг или одежды: заказ сформирован, собран в коробку, лежит на складе. Автоматически формируется маршрутный лист, даже если это same day delivery это не происходит мгновенно. Курьер забирает заказы и развозит их по списку: одному клиенту, другому всё по порядку. Всё заранее известно. Если происходит задержка в небольшом диапазоне времени, это не так критично все товары останутся целыми, клиент, как правило, готов немного подождать. А если диапазон хотя бы часовой, то точное время доставки доподлинно неизвестно.

С едой всё не так.

  • Мы должны контролировать время! Когда пользователь делает заказ, он голоден. Он не может ждать. Еда должна быть горячей, каждая минута на счету.
  • Невозможно составить маршрутный лист. В Delivery Club только 2% предзаказов. А в остальном никто не заказывает еду заранее это всегда происходит on demand.

  • Процесс работы курьеров динамичный. Ситуация меняется каждые 5-15 минут. Когда начинается дождь или снег, всегда повышается спрос. А когда на улице солнечно и не хочется сидеть дома, спрос снижается. В праздничные и выходные дни профиль спроса отличается от будней. Дорожная ситуация и пробки также вносят свои коррективы, особенно в тех зонах, где превалируют авто/мото-курьеры.

Давайте ещё раз посмотрим на ситуацию на рынке:

  1. Рынок быстро меняется. Появляются новые вертикали и направления. Представьте, Delivery Club уже 10 лет. С 2009 по 2016 мы были маркетплейсом. В 2016-м начали развивать логистику. За последние полгода мы запустили доставку продуктов, доставку из аптек, Takeaway и начали предоставлять сервис экспресс-логистики сторонним компаниям (Связной). Мы видим ещё много ниш, в которых мы можем упростить жизнь пользователей.
  2. Ожидания от уровня сервиса меняются быстро. Ещё пару лет назад мы заказывали суши по телефону и были готовы ждать пиццу три часа. Сегодня пользователь привык получать бургер и любимый боул с авокадо через 40 минут, сделав пару кликов в смартфоне. FoodTech это одна из тех индустрий, где сегодня создаются новые потребительские привычки, и происходит это прямо сейчас!
  3. Количество заказов продолжает расти с колоссальной скоростью. Представьте: за весь 2018 год мы выполнили 4 миллиона заказов, в то время как только за один сентябрь 2019-го 3 миллиона, а уже в марте 2020-го вышли на показатель в 1 миллион заказов в неделю!
  4. С другой стороны, нам нужно быстро реагировать на новые возникающие потребности пользователей. В период пандемии нужно было быстро катить обновления. Организовать быструю доставку продуктов в период самоизоляции. Вводить новые меры для профилактики коронавирусной инфекции, обеспечить безопасность курьеров, клиентов и партнеров. Отменить расчёт наличными.

Почему в России всё по-другому


Конечно же, мы смотрим на опыт компаний на тех рынках, где foodtech более развит в Европе, Юго-Восточной Азии, Индии. Но этот опыт невозможно использовать as is, так как у них другая география и топология, условия, покупательская способность. У нас крупнейшая страна мира по площади, организовать здесь логистику уникальная задача. Инфраструктура наших городов тоже отличается: другое разделение на авто/мото/пешую доставку, другая плотность расположения ресторанов (много ТЦ и отдельных маленьких кафешек).

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

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

Как мы с этим справляемся

Маршрутные листы нам заменяет прогнозирование спроса. Мы знаем погоду, день недели, месяц, составляем зоны доставки и смены. Для коммуникации с курьерами мы сделали мобильное приложение RiderApp.

Для контроля ситуации мы построили системы, которые отслеживают изменения в реальном времени. Например, когда погода меняется пошел дождь и увеличился спрос мы сразу это увидим на мониторингах, изменятся вводные, а наша система может внести коррективы в параметры алгоритмов. А вот более прогнозируемые изменения уже зашиты в работу таких систем. Например, утренние, дневные и вечерние часы имеют разный профиль спроса. Всё это ещё и адаптировано к разным часовым поясам. Подробно об этом рассказали Денис Горев в докладе Автоназначение курьеров в Delivery Club и Николай Архипов в докладе Как мы побеждаем неопределенность в Delivery Club.

При разработке новой функциональности мы используем гипотезы. Мы оцениваем, как изменения в продукте будут влиять на пользователя, проводим исследования, подкрепляем эти результаты теми аналитическими данными, которые у нас уже есть. Делим разработку на этапы, чтобы понять, где можно сделать проще, и быстрее выпустить MVP. Это особенно актуально при выходе на новые вертикали рынка. Чтобы собрать всё это вместе, мы внедрили отдельный процесс построения и проверки гипотез. Про это я подробно расскажу в отдельной статье GIST фреймворк верификации гипотез в Delivery Club.

Структуры команд мы поделили по продуктовым направлениям и провели продуктовую трансформацию. Все команды у нас отвечают за свой продукт или value stream внутри отдельно взятого продукта. Стратегию продуктовых изменений определяет Product Manager. Это позволяет, во-первых, командам более четко фокусироваться на поставленной задаче и добиваться результата в ожидаемые сроки. Во-вторых, позволяет разработчикам лучше понимать конечных пользователей и быть вовлеченными.

Сама трансформация у нас началась в конце 2018 года, а новый процесс разработки закрепился в начале 2019 года. С середины 2019-го у нас идет активный найм. За это время мы выросли в 4 раза, а это +120 человек. Поэтому я бы сказал, что процесс трансформации продолжается до сих пор. О нём я расскажу в отдельной статье.

За десять лет Delivery Club стал лидером доставки еды в России с присутствием более чем в 150 городах, 22 тысячами ресторанов-партнеров и более 5,5 млн заказов ежемесячно. Чтобы быстро реагировать на все изменения, скорость роста количества заказов и новые вызовы, и при этом оставаться лидерами, мы должны понимать свою аудиторию, быть гибкими и адаптивными, ориентироваться на результат и строить такие процессы внутри, которые помогли бы достигнуть этих целей. Всё это находит отражение в нашей культуре.

Особенности культуры Delivery Club Tech


Давайте подытожим, какие есть особенности у современного рынка FoodTech в России:

  • Опыт не всегда можно скопировать.
  • Появляются новые вертикали, рынок быстро меняется.
  • Один из самых быстрорастущих сегментов e-commerce.
  • Формирование новых потребительских привычек.
  • Нужно быстро реагировать на возникающие пользовательские потребности.

Из этих особенностей и строятся основные принципы нашей культуры:



Инженерная культура, в свою очередь, является субкультурой естественным продолжением культуры компании. В ней отражены не только принципы работы, но и то, как мы выбираем технологии, строим архитектуру, нанимаем людей и строим команды. Сейчас я остановлюсь только на одном аспекте: in-house разработке!

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

Я убежден, что это достижимо только, когда люди мотивированы, правильно погружены в контекст и заряжены на результат. В этом и проявляется в полной мере сила и важность in-house разработки.

Но приложение же работает нормально, зачем вам 170 человек?


Как я писал выше, e-com похож на айсберг, со стороны всегда видна лишь малая верхняя часть. Вся операционная деятельность, которая в основном сосредоточена в оффлайне, скрыта от глаз обычного пользователя.

В основе бизнеса Delivery Club лежат четыре самых важных вектора:

  1. Клиент, который покупает еду.
  2. Доставщик.
  3. Партнёр (ресторан/магазин).
  4. Техподдержка: call-центр и диспетчеры, которые контролируют процесс.

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

В прошлом году мы сформировали ещё два направления: R&D и Platform. Направление R&D решает наукоёмкие задачи, работает с зоной низкой определенности, которая сейчас в основном сосредоточена вокруг логистических задач. Ребята вместе с отделом Операций оптимизируют бизнес-процессы и автоматизируют ручные и рутинные действия.

Команда Platform занимается технологическими улучшениями платформы, меняет архитектуру, чтобы мы могли справляться с возрастающим количеством заказов и нагрузками. Рост заказов настолько стремительный, что мы выросли в целых три раза по сравнению с предыдущим годом. И теперь представьте, как важно поэтапно пересматривать архитектуру, чтобы справляться с постоянно возрастающими нагрузками.

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

Выводы


Рынок быстро меняется, поэтому важно так же быстро адаптировать процессы и технологии под него. Вот, что делаем мы:

  • сохраняем гибкость и меняемся вместе с рынком;
  • генерируем много гипотез и умеем их измерять;
  • делаем процессы прозрачными, чтобы вся команда понимала, что мы делаем и зачем, и как именно фичи влияют на конечных пользователей;
  • непрерывно оптимизируем процессы разработки и релизного цикла, чтобы снизить Time to Market.

Для этого мы выбрали путь in-house разработки. А все особенности рынка FoodTech отразили в своих принципах инженерной культуры. Кстати, вот они, взгляните: tech.delivery-club.ru/culture.

Инженерная культура, в свою очередь, нам подсказывает, какие Soft Skills важны для сотрудников IT-отдела Delivery Club. Эти качества стали основой нашего фреймворка найма.

Я почти ничего не рассказал о том, как выглядят команды изнутри. Об этом пойдет речь в следующей статье, рассказывающей о том, с чего всё начиналось, какие этапы трансформации мы прошли, как обстоят дела прямо сейчас и с каким новыми вызовами нам приходится сталкиваться.

Технические аспекты мы также не пропустим. Отдельную статью посвящу Платформе и Архитектуре. А также отдельно поговорим про Go-Swagger и Kafka Connect.

Надеюсь, мне удалось погрузить вас в контекст foodtech-рынка и объяснить, зачем Delivery Club 170 разработчиков.

Спасибо, что дочитали!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru