Поделиться
Денис Исаев, Mail.Ru: Как одновременно обеспечить скорость разработки и стабильность системы
При разработке нового продукта большую роль играет скорость — необходимо быстро вывести его на рынок, протестировать и сделать выводы о жизнеспособности. Однако если планируется сразу подключать к нему несколько тысяч пользователей, нужно позаботиться и о стабильности. Денис Исаев, руководитель направления backend и frontend разработки в Mail.Ru, рассказал о своем опыте разработки нового сервиса корпорации — BeepCar — где одновременно были необходимы быстрая разработка и надежность системы.
CNews: Денис, вы возглавляете направление backend и frontend разработки BeepCar в Mail.ru Group. Расскажите подробнее о вашей роли и в целом о том, как вы пришли в профессию.
Денис Исаев: Еще со школьных времен я интересовался разработкой — самостоятельно разбирался в этой теме и программировал. Поэтому я поступил в МГТУ им. Баумана на факультет «Информатика и системы управления». Во время учебы я принял участие в образовательном проекте «Технопарк» — он был создан Mail.ru Group для поиска стажеров среди талантливых студентов. Мне удалось попасть в первый поток в 2012 году, и уже через полгода я захотел попробовать себя в реальных проектах. Чтобы не терять время, я нашел человека, который отвечал за найм в компании и стал настойчиво просить рассмотреть мою кандидатуру — так я попал на стажировку в Mail.Ru.
Несколько лет я работал в Почте Mail.Ru, а потом мне предложили позицию backend разработчика на проекте BeepCar — продукт задумывался как российский аналог французского гиганта BlaBlaCar, онлайн-сервиса для поиска попутчиков. В то время сфера шеринга авто в России только развивалась, поэтому перед нами стояла задача практически с нуля собрать логику и продумать инфраструктуру продукта. В итоге нам удалось запустить BeepCar на пользователей всего за 4,5 месяца. На старте я отвечал за бэкенд, а затем еще и за фронтенд сервиса.
CNews: С чего началось строительство архитектуры BeepCar? Какие принципы вы закладывали в систему с самого начала, чтобы она могла масштабироваться и выдерживать рост нагрузки?
Денис Исаев: Главным принципом стала скорость — нужно было быстро создать и протестировать MVP и развивать продукт дальше. Нам это удалось — 4,5 месяца от старта до реализации можно считать очень хорошим сроком по меркам крупных ИТ-компаний.
Также нужно было предусмотреть гибкость разработки. Product-Market-Fit нового сервиса еще не был найден, поэтому предполагалось, что мы будем корректировать продукт по мере тестирования и исследований, добавлять новые функции и менять логику.
Третьим принципом стало качество. BlaBlaCar можно было улучшить по целому ряду критериев: интерфейс, функции, логика. Поэтому мы сразу стремились создать по-настоящему качественный сервис.
Что касается технических вопросов, то мне удалось убедить руководство использовать язык Go, с которым в Mail.Ru практически никто не работал. Я выбрал именно этот язык, потому что он обеспечивал скорость, простоту и стабильность разработки — и на него стали переходить во многих крупных компаниях. Чтобы не прописывать значительную часть логики вручную, мы использовали фреймворк Bigloo. А чтобы ускорить процесс итераций, мы с самого начала внедрили автотесты.
Самым большим челленджем в разработке стало добавление слоя географии — экспертизы в этой задаче не было практически ни у кого в Mail.Ru. За основу мы взяли открытые картографические данные Open Street Maps — но нужно было выделить из них страны, где работал наш продукт. При этом мы должны были предусмотреть быстрое добавление стран, и в итоге мы добились возможности делать это за один день.
Чтобы слой географии отвечал нашим требованиям, пришлось написать много кастомного кода. В результате мы построили целую систему обработки географической информации.
Из функций труднее всего было реализовать прогноз стоимости на сложном маршруте с промежуточными точками. Например, если водитель едет из Москвы в Санкт-Петербург, приложение может предложить ему заехать по пути в Тверь и подобрать еще одного пассажира, чтобы больше заработать. Расчет цены требует применения алгоритмов обхода графа, которые могут работать до 5-10 секунд — и с каждой точкой длительность возрастает. Чтобы ускорить работу функции, мы применили алгоритм A*, добавили серверную память для его расчета и использовали несколько технических хаков. В результате удалось сократить время до 500-700 мс.
CNews: Какие инструменты вы выбрали, и как они вписались в более широкую инфраструктурную стратегию Mail.ru Group и ваши собственные стандарты надежности?
Денис Исаев: OpenStreetMap — одно из самых популярных и простых в реализации решений. Это, можно сказать, best practice мировых компаний. Поэтому, чтобы ускорить разработку, мы тоже решили использовать этот ресурс. Однако каждая компания писала поверх OpenStreetMap еще некоторое количество сложной логики, которая позволяла адаптировать решение под определенные нужды — и нам пришлось делать так же.
После изучения продуктов, похожих на наш, я также решил использовать Elasticsearch. Инструмент позволяет осуществлять быструю фильтрацию и сортировку геоточек по множеству критериев за счет обратной индексации. В нашей компании не было экспертизы по Elasticsearch, поэтому ее нарабатывали с нуля.
Еще в начале проекта я настоял на том, чтобы при необходимости смягчить для нас гайдлайны Mail.Ru в части применяемых технологий. Ведь на тот момент мы были стартапом, и запуститься в короткие сроки было крайне важно. То есть план был в том, чтобы искать наиболее оптимальные решения, и уже потом, когда стартап взлетит, мигрировать на технологии Mail.Ru. Было нелегко отстоять свою точку зрения, но я смог привести нужные примеры и доказать, что свобода действий позволит нам намного быстрее воплотить продукт.
CNews: Расскажите подробнее, как вы добивались высокой устойчивости сервиса. Что оказалось самым сложным — архитектура, DevOps-процессы или человеческий фактор?
Денис Исаев: Устойчивость стала одним из наших основных критериев — и ее было довольно легко реализовать, потому что наша команда состояла из инфраструктурных специалистов, которые применили в работе свои лучшие практики. Обычно в продуктовой разработке устойчивость не ставят во главу угла — но благодаря вектору нашей команды удалось создать не только производительный, но и надежный сервис.
Например, моим критерием была устойчивость при запуске, потому что многие крупные приложения «падают» в первый день, когда ими резко начинают пользоваться многочисленные юзеры. Также мы довольно мощно подогревали нашу аудиторию и рассылали десятки миллионов пушей — а это большая нагрузка на систему. Наше приложение и здесь показало себя с лучшей стороны, достойно выполнив все задачи.
Чтобы добиться таких показателей, мы реализовали несколько уникальных для Mail.Ru решений — например, построили отказоустойчивую очередь, которая использовала два независимых кластера базы данных Tarantool. Если не удавалось записать очередь в один кластер, он писался во второй — и однажды эта механика нам очень пригодилась, когда первый кластер отказал.
Так как у меня уже была экспертиза в построении отказоустойчивых систем, команде под моим руководством удалось реализовать несколько простых, но неочевидных решений стабильности системы — благодаря этому мы построили один из самых надежных продуктов Mail.Ru.
CNews: Как вы строите культуру разработки в своей команде? Есть ли у вас внутренние стандарты или практики, которые вы считаете обязательными для больших продуктовых команд?
Денис Исаев: Мой главный стандарт — это скорость. Необходимо как можно быстрее запустить стартап или MVP, чтобы протестировать идею и развивать ее при положительном результате. Поэтому в работе над BeepCar я максимально создавал условия для быстроты разработки. В результате топ-менеджмент несколько раз отмечал нашу команду как выдающуюся по скорости.
Мой второй стандарт — это прозрачность для стейкхолдеров. Чтобы обеспечить скорость, приходится допускать технический долг в производительности, поддерживаемости, надежности. Долг со временем накапливается и может стать неприятным сюрпризом для стейкхолдеров. Чтобы такого не случилось, я всегда веду открытый диалог с топ-менеджерами — например, мы можем запустить новую функцию, но появится долг, который придется закрывать 4 недели. И затем мы решаем совместно, реализуем эту функцию или нет.
CNews: Учитывая работу в крупной экосистеме, как вам удается сохранять гибкость стартапа, быстро экспериментировать и внедрять новые решения, не теряя при этом надежности?
Денис Исаев: Главной задачей было договориться с командой и руководством об ускоренных сроках разработки — если бы мы работали в привычном для крупных компаний темпе, то ничего бы не получилось. Поэтому я запросил у руководства ряд особых условий для нас: выделенную команду эксплуатации, учащенный объем релизов, отступление от гайдлайнов по технологиям.
CNews: Как вы находите баланс между работой и личной жизнью? Или для вас инженерия — это не просто профессия, а образ жизни?
Денис Исаев: У меня есть своя философия менеджмента: построить систему, которая максимально уменьшит объем хаоса в команде. Главная задача здесь — сделать процессы стабильными, предсказуемыми и управляемыми. Это позволяет избежать ситуаций, когда команда работает в режиме тушения пожаров. Придерживаясь этой философии, довольно легко соблюдать work-life balance — без переработок и выгорания.
CNews: Если отвлечься от текущих задач — какой технологический проект или инфраструктурное решение вам хотелось бы реализовать «для себя», без оглядки на бизнес и сроки?
Денис Исаев: Если честно, сейчас я погружен именно в рабочие проекты, так что на отвлеченные проекты пока нет времени. Но идеи, конечно, есть. Например, при тестировании нашего проекта мы использовали линтеры — программы-анализаторы, которые выявляют потенциальные ошибки, стилистические нарушения и другие недочеты. Они позволяли быстрее проводить тесты, чем вручную, но все равно последовательная проверка функций с помощью всех линтеров длилась довольно долго — около 3 минут.
Чтобы ускорить процесс, я думаю о разработке металинтера. В будущем мне было бы интересно построить полноценный статический анализатор, основанный на фундаментальных научных принципах. Например, меня очень вдохновляет решение Coverity, которое было разработано учеными из топовых американских институтов. Темой моих дипломных работ в университете был статический анализ, поэтому я интересуюсь этой сферой уже давно.
Короткая ссылка
