Блог компании ЦИАН
Как мы в ЦИАН цифровизируем рынок недвижимости
Привет, Хабр! Меня зовут Алексей Чеканов, я технический директор ЦИАН. Разработка определяет успехи нашего проекта, и чем дальше, тем заметнее. Чтобы расти, нам нужно больше IT-специалистов — и для решения нетривиальных задач, и для поддержки существующих сервисов. Ниже я расскажу, как устроен отдел разработки в ЦИАН, чем он занимается, и что ждет того, кто к нам попадет.
За последние пять лет команда ЦИАН выросла с 37 до 500 человек, IT-инфраструктура стала сложной. За это время мы сделали много интересного и решили поделиться лучшими находками (и фейлами) с Хабром.
На октябрь 2019 года у сервиса 14,3 млн уникальных посетителей в месяц и 1,2 млн в день. Инфраструктуру, на которой держится весь highload, обслуживают 300 физических серверов. На фронт-серверы приходится ~8k RPS.
Каждую неделю команда разработки делает 180 задач в микросервисах и 10 релизов в монолитах, а также выкатывает два билда в мобильные сторы.
Коротко об основных наших технологиях. Бэкенд-языки: Python, C#, Java, PHP. На фронтенде — Node.JS и React. Базы и хранилища данных: MS SQL, PostgreSQL, Cassandra, MySQL, ElasticSearch. В числе инфраструктурных решений — RabbitMQ, Memcache, Redis, Nomad, Consul, стек Hadoop. Часть решений — общие, часть используется в отдельных направлениях, например, ElasticSearch — в поиске.
Как устроена разработка
Для обычного потребителя услуг сервис представляет собой единый продукт, доступный на разных устройствах. Существует сайт Cian.ru и два приложения — на iOS и Android.
Внутри разработка делится по направлениям. Каждое из них закреплено за каким-то сегментом аудитории или технологически значимым решением, и каждое закрывает фулстек-команда.
Главные направления:
• застройщики — первичный рынок недвижимости;
• риелторы и собственники — вторичный рынок;
• аудитория — те, кто хочет купить или снять жилье;
• модерация — качество базы и защита от мошенников;
• оценка и аналитика — оценка реальной стоимости продажи квартиры и инвестиционной привлекательности покупки новой;
• финансы — маркетплейс ипотечного кредитования с формированием решения от банков всего за несколько минут.
• застройщики — первичный рынок недвижимости;
• риелторы и собственники — вторичный рынок;
• аудитория — те, кто хочет купить или снять жилье;
• модерация — качество базы и защита от мошенников;
• оценка и аналитика — оценка реальной стоимости продажи квартиры и инвестиционной привлекательности покупки новой;
• финансы — маркетплейс ипотечного кредитования с формированием решения от банков всего за несколько минут.
Внутри каждого направления мы постоянно делаем что-то новое. Например, для первичного рынка построили «квартирографию»: благодаря ей можно изучить актуальную планировку строящихся зданий по этажам и квартирам. Для вторичного рынка запустили аукцион: ранжирование объявлений, которые размещают риелторы, зависит от ставок на этом аукционе.
Мы стараемся сконцентрировать экспертизу так, чтобы команды могли довести любую идею до продакшена. Это позволяет принимать самостоятельные решения внутри направлений и предотвращает избыточное взаимодействие между командами. Например, недавно завершилась трансформация пула iOS- и Android-разработчиков: раньше это была отдельная группа мобильных разработчиков, теперь специалисты распределены по продуктовым командам.
В направлениях работает по 30–40 человек. Чтобы управление не стало слишком громоздким, мы формируем команды по 5-8 человек. Часто они стабильны по составу, но могут и меняться от проекта к проекту. Бывает, люди по собственной инициативе переходят в другую команду ради более интересных задач. А некоторые даже меняют профиль (например, переквалифицируются из QA в бэкендеры).
Кто сейчас работает в IT-департаменте ЦИАН
Есть у нас команды, которые работают со всеми направлениями сразу.
Например, команда «аудитория». Благодаря им и коллегам из ML пользователи получают более точные рекомендации по результатам ранее проведенного поиска, а ранжирование объявлений «умнеет». Еще эти ребята обеспечивают генерацию «добивок» — расширений параметров поиска на случай, если заданы чересчур узкие критерии и по ним найдено мало объявлений.
Например, команда «аудитория». Благодаря им и коллегам из ML пользователи получают более точные рекомендации по результатам ранее проведенного поиска, а ранжирование объявлений «умнеет». Еще эти ребята обеспечивают генерацию «добивок» — расширений параметров поиска на случай, если заданы чересчур узкие критерии и по ним найдено мало объявлений.
Есть команда DI. Она отвечает за инфраструктуру для разработки и бета-тестирования, инструменты для выкладки и деплоя, Continuous Integration / Continuous Deployment, а также интеграции с JIRA.
Команда платформы бьется за uptime и доступность инфраструктуры. Они создают инструментарий для остальных разработчиков: шаблоны микросервисов, общие библиотеки, средства логирования и отладки (Jaeger). Плюс сами занимаются отладкой и профилированием, а также логированием проблем. В платформе логирование идет в кластер ELK. В сутки ~4 Тб логов и ~3.8 млрд. записей.
Дата-инженеры из ML собирают данные и события с сайта, из приложений и других источников и делают их доступными для потребителей внутри компании: дата-сайентистов, BI-специалистов и продуктовых команд. Для BI строят аналитические витрины, а дата-сайентистам отдают предагрегаты. А это сложно, если учесть объемы информации: сегодня платформа аккумулирует 500 Тбайт данных и обрабатывает около 25 тыс. событий в секунду.
Команда модерации контролирует качество объявлений. Следит, чтобы за каждым стояло реальное предложение, причем с теми параметрами сделки, которые в нем указаны. Недавно нам удалось привязать ее работу к бизнес-задачам. Например, к KPI по числу снятых неактуальных объявлений и найденного фрода. Также вся команда генерит гипотезы как достичь целей.
С чем работают в ЦИАН, или Что любопытного есть в IT-инфраструктуре
Изначально ЦИАН был написан одним человеком на PHP и в таком виде просуществовал до 2014 года. Пять лет назад началось бурное развитие проекта с целью стать ресурсом № 1 по поиску недвижимости в России. Попутно ЦИАН объединили с другим проектом, в основе которого лежал C#.
Монолиты C# и Python оказались в фундаменте ЦИАН по историческим причинам. Они по-прежнему работают, но новое мы пилим в микросервисах. Собираемся вынести из монолитов важные куски системы.
Старый (2.7) Python мы используем только в монолите. Во всех микросервисах — «тройка» в комбинации с Tornado. В C# новые микросервисы пишем на .NET Core 2.2 и запускаем в Linux. В планах — переезд на .NET Core 3.
Мы стремимся своевременно обновляться до мажорных версий. Особенно в случае с такими опорными для инфраструктуры решениями, как ElasticSearch и RabbitMQ.
Чтобы управляться с микросервисами, мы используем контейнеризацию на базе Docker, а оркестровку обеспечивает Nomad. Также у нас свои библиотеки-надстройки над стандартными средствами трех языков — C#, Python и Node.JS — для организации общеархитектурных процессов, таких как Circuit Breaker, Service Discovery, OpenTracing, телеметрия и т. д. Возможно, вы даже знаете о разработках, например, о системе runtime settings, из наших докладов на конференциях.
Continuous Integration / Continuous Deployment мы автоматизируем с помощью самописной системы, которая функционирует в связке с Jenkins. Нам нужно было решение, заточенное под наши процессы, которое обеспечивало бы не только автоматизированную сборку и выкладку кода, но и контроль над жизненным циклом задачи. А значит, требовалась тесная интеграция с внешними системами (мониторинга, алертинга, оркестрации и т. д.). Плюс необходимость добавлять новую логику и вносить ветвления в процессы.
Сейчас наша система автоматически проводит задачу по всем статусам, за исключением самой разработки и перевода в ревью (в монолите также перевод в ready for build проходит вручную — по клику тестировщика). Человек вмешивается, только когда что-то идет не так. Система сама назначает ревьюеров, запускает тесты и, если надо, отправляет задачу на ручное тестирование. Еще отслеживает процесс выкладки задачи в прод: сначала она выкатывается на небольшую часть аудитории, далее, по апруву разработчика, на 100%. При повышении фона ошибок релиз автоматически откатывается.
Реализовав CI/CD по своей схеме, мы в пять раз ускорили доставку кода в прод.
На всех этапах CI/CD участники команд получают уведомления в Slack и по почте. Система тесно связана с JIRA и обеспечивает движение по workflow, автоназначение задач, подбор ревьюеров, сбор и подготовку нужных артефактов.
Мы движемся в русле современных IT и от проприетарных решений постепенно переходим к Open Source.
Как у нас принимают решения
Конечно, в IT-подразделении ЦИАН существует иерархия технического руководства. Однако глобально мы за короткие связи между людьми. Идеал, к которому мы стремимся, — совокупность зрелых команд. Такая команда понимает цели, которые перед ней ставит бизнес, разделяет эти цели и достигает их самостоятельно. А значит, тимлид фокусируется на развитии и мотивации людей и не тормозит решения, сгенерированные командой.
За квартал, помимо продуктовых проектов, команда делает несколько чисто технических проектов. Но при планировании мы учитываем и требования бизнеса. В итоге выполняем продуктовые задачи, не забывая о качестве и поддерживаемости кода.
Когда мы решаем, перепиливать компонент или нет, то смотрим:
- на число багов в нем;
- на степень их критичности;
- на скорость работы сервиса, зависящего от компонента;
- на ресурсоемкость изменений;
- на частоту внесения изменений.
Работа IT в ЦИАН опирается на гибкие методологии. Мы живем в режиме недельных спринтов. Команды регулярно проводят митинги, демо, планирования, ретроспективы. В целом модель работы похожа на Scrum, но у каждой команды своя специфика организации процессов. Если команда видит неоптимальный или плохо организованный процесс и хочет его изменить, она меняет его без бюрократических помех и цепочки согласований.
Главное же то, что мы уходим от логики «заказчик — исполнитель». В центре работы — цель, к которой идет команда. Делать ошибки не страшно, важно минимизировать стоимость этих ошибок. Поэтому мы движемся вперед короткими итерациями: достигаем результата, получаем обратную связь, корректируем маршрут к цели и меняем фичи на основании новых данных.
С чем мы справились
Было бы здорово написать, что у нас нет проблем и мы — образец для подражания, но это не так, и так в IT никогда не бывает. За 18 лет у нас в разработке набралось много странностей и сложностей.
Из-за расширения и усложнения разработки однажды перед нами встала проблема: мы увязли в менеджменте. Ходила шутка, что нам нужен регламент по изменению регламентов и департамент регламентов.
Мы справились за счет того, что дали больше автономности в принятии решений как тимлидам, так и разработчикам. Звучит просто, но это потребовало кардинальных изменений в организации разработки. В результате мы перешли от директивного управления к управлению через ценности. И всегда готовы объяснить, на какие правила и принципы опирается компания, принимая решения, как вовлечь всех членов команды в развитие продукта, зачем делается та или иная фича. Мы всегда пытаемся понять причины факапа и избегать подобного в будущем.
Также мы практически доукомплектовали штат девопсов. Так что ребята переходят из аврального режима к нормальной проектной работе, разбирая завалы, которые возникли у нас на фоне стремительного роста и нехватки людей. От того, насколько мы тут успешны, напрямую зависит uptime нашего сервиса.
Еще один вызов, с которым мы справились, — усиление мобильной разработки. К 2018 году мы поняли, что отстаем по части приложений, и те не отвечают потребностям наших пользователей. Мы стали продумывать продуктовые решения для всех платформ и даже часть фич запускать только на мобильных платформах. Меньше чем за полгода нам удалось почти полностью отрефакторить оба приложения, пересмотреть workflow. Мы утроили число мобильных разработчиков, и теперь их команды независимо вносят изменения в приложения и стабильно выпускают новые релизы раз в неделю.
С чем нам справиться предстоит
Самые большие вызовы сейчас стоят перед фронтендом. Раньше мы отдавали разработку многих компонентов аутсорсерам. В итоге появились изрядные массивы legacy-кода. Теперь в тех точках, контроль над которыми мы на время ослабили, страдает time-to-market, да и UX тоже. Лишь недавно мы внедрили на фронтенде unit-тесты, которые хотим сделать повсеместными.
Фронтенд-команд у нас много, а продукт один и тот же. Попадаются экраны интерфейса, где они сталкиваются: в поисковой выдаче, в карточках объектов. Каждая команда хочет добавить туда свое. Нам нужно не блокировать работу друг друга и быстро распространять изменения общих компонент (например, с помощью виджетов).
Вскоре мы начнем полностью переделывать мобильный сайт. Туда заходит 60–70% нашей аудитории, а он морально и технически устарел.
Еще у нас до сих пор нет единого UI kit (он в планах на 2020 год), а он ускорил бы процессы во фронтенд-разработке и удешевил ее.
Кто нам нужен
На текущий момент у нас около 30 вакансий. Потребности в новых людях растут быстрее, чем мы успеваем пополнять штат.
Главная задача найма сейчас — найти senior дата-сайентиста, который знает алгоритмы машинного обучения, способен принять бизнес-задачу, разобраться в потоке данных, понять их физический смысл, обучить модель, вывести ее на прод, разобраться, что с ней не так, и переобучить ее — причем в сроки, которые заложил себе изначально.
Также мы нуждаемся в крепких фронтендерах, питонистах, разработчиках под iOS и Android — миддлах и сеньорах. Джуниоров пока не берем, но налаживаем систему наставничества, чтобы в 2020 году попробовать.
Так уж сложилось, что наши тимлиды и техлиды вырастают внутри ЦИАН. Сейчас в каждом направлении разработки есть тимлид, пришедший из разработчиков.
С недавнего времени тимлиды участвуют в финальных интервью с соискателями и вместе с HR решают, принимать людей в команду или нет. А зависит решение не только от профессионализма человека, но и от того, готов ли соискатель разделить наши ценности.
Ценности у нас простые и, кажется, разумные, так что мы строго их придерживаемся.
• «Базовый минимум: честность и открытость». Мы поддерживаем в компании атмосферу взаимного доверия. Если вы чувствуете дискомфорт, или что-то не получается — говорите без боязни показаться смешным или быть уволенным.
В ЦИАН ошибки — это хорошо. Плохо, когда они повторяются.
- «Меняйся, границы только в твоей голове». Ландшафт IT трансформируется настолько быстро, что мы не можем работать по одним и тем же лекалам, принимать одни и те же решения. Нужно адаптироваться к новым ситуациям, процессам, людям. Тому, кто привык работать строго по протоколу, будет сложно перестроиться. Поэтому мы ищем людей, способных принимать решения без регламента и строгих указаний.
- «Давай результат». Это не то же самое, что «умри, но сделай». Речь о том, что нужно уметь расставлять приоритеты, формулировать цели, определять свою зону ответственности, находить проблемы и предлагать решения по их преодолению, не забывая о цели. Сюда же относится ответственность. Если разработчик принял задачу и обещал ее сделать, мы ждем, что он ее сделает. А если что-то не будет получаться, не станет тянуть до последнего, а придет и скажет, что именно у него не получается. Причем придет с каким-то сценарием дальнейших действий.
- «Играй в команде». Мы ориентируемся на общий результат, поэтому взаимопомощь у нас — норма. Если ты попросил кого-то о содействии, а это вовсе не его задача и даже не его фронт работ, он даст тебе наводку на нужного человека или ресурс, отведет куда нужно и все покажет.
- «Цени клиента». Под клиентами мы понимаем не только наших партнеров, но и внутренних заказчиков. Мы слушаем своих собеседников и стараемся конструктивно разрешать конфликты.
На ваши вопросы мы постараемся ответить в комментах. А если вас заинтересуют какие-то отдельные аспекты нашей разработки (например, CI/CD) — оставьте свои пожелания там же.
Комментарии (10)
semindm
04.10.2019 19:19Получается, Ваше приложение состоит из 2-х монолитов и ряда микросервисов? и все они между собой взаимодействуют через RabbitMQ?
FuriCuri
04.10.2019 20:01Http вызовы + сообщения очередей — это основные каналы взаимодействия, да. И в обоих каналах приложения должны придерживаться объявленного контракта (request/response схемы или model события). У нас также есть система (пока она работает только для api вызовов), которая валидирует при выкладке, что не произошло breaking change в принимаемых api или вызываемых среди всех монолитов и микросервисов (мы умеем по коду автоматически найти схемы request / response приложения).
jreznot
04.10.2019 20:02У них на PyCon было подробнее рассказано pycon.ru/2018/program/content/mazaev
maxim_ge
04.10.2019 22:49>В платформе логирование идет в кластер ELK. В сутки ~4 Тб логов и ~3.8 млрд. записей.
Можно поподробнее про это? 8k RPS => 700 млн. записей в день, откуда берется 3.8 млрд и что делаете с такими объемистыми логами?Aleksey_Chekanov
04.10.2019 23:34Думаю подробнее расскажем в отдельной статье. Вкратце, логируем не только акцесслоги, но и события в микросервисов, цепочки вызовов, ошибки, ворнинги и т.д. Все это позволяет мониторить и отлаживать систему. Также на базе этих логов строим siem систему
Orange11Sky
А почему у компании такое токсичное название — это как-то помогает продавать недвижимость?
CactusKnight
Цифровизация — это, конечно, хорошо. Но почему при поиске квартир с активированным фильтром «тип дома: кирпич, монолит» ЦИАН иногда подкидывает квартиры в панельных домах, у которых это даже написано в разделе «О доме»?
one-two
Слоган над космонавтом — норм)