Привет, Хабр! Меня зовут Алексей Чеканов, я технический директор ЦИАН. Разработка определяет успехи нашего проекта, и чем дальше, тем заметнее. Чтобы расти, нам нужно больше 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 пользователи получают более точные рекомендации по результатам ранее проведенного поиска, а ранжирование объявлений «умнеет». Еще эти ребята обеспечивают генерацию «добивок» — расширений параметров поиска на случай, если заданы чересчур узкие критерии и по ним найдено мало объявлений.
Есть команда 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) — оставьте свои пожелания там же.

Комментарии 43

    +2

    Слоган над космонавтом — норм)

      +1
      Получается, Ваше приложение состоит из 2-х монолитов и ряда микросервисов? и все они между собой взаимодействуют через RabbitMQ?
        +1

        Http вызовы + сообщения очередей — это основные каналы взаимодействия, да. И в обоих каналах приложения должны придерживаться объявленного контракта (request/response схемы или model события). У нас также есть система (пока она работает только для api вызовов), которая валидирует при выкладке, что не произошло breaking change в принимаемых api или вызываемых среди всех монолитов и микросервисов (мы умеем по коду автоматически найти схемы request / response приложения).

          +1
          У них на PyCon было подробнее рассказано pycon.ru/2018/program/content/mazaev
          +1
          >В платформе логирование идет в кластер ELK. В сутки ~4 Тб логов и ~3.8 млрд. записей.

          Можно поподробнее про это? 8k RPS => 700 млн. записей в день, откуда берется 3.8 млрд и что делаете с такими объемистыми логами?
            +2

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

              +1
              Интересно: как можно разобраться в 4Тб логов, и на сколько нужно логировать так подробно?
                +1
                Да, можно и больше — это не «rocket science». Filebeat -> Kafka -> Logstash -> Elastic. Логируем мы также логи приложений уровня info и выше + всякие события с других систем: к примеру, в mssql настроены extended events на тяжёлые запросы, чтобы если кто-то нагнул БД, то мы бы смогли ретроспективно посмотреть кто это был.
                  +1
                  Нормальная практика это не смотреть постфактум — кто нагнул, а передавать запрос еще до внедрения спецу по SQL, который разберет его, разложит по полочкам, в какой ситуации и как он будет работать. По своему опыту в 90% разработчики бэкенда такой треш в запросах к базе ваяют, что волосы дыбом встают.
                    +1
                    Не смотря на то, что я согласен, что специально обученный человек смог бы такое замечать, к сожалению, это так не работает, когда у вас столько выкладок в день как у нас. Для «масштабирования» процесса вам просто придётся держать штат таких людей и заставлять их заниматься одним и тем же каждый день. Это приводит к тому, что либо у вас будут джуны на таком сидеть (и качество инициативы сомнительное), либо текучка нормальных спецов (потому что тупеешь, если твоя работа только в постоянно смотреть пулрики).

                    Мы сейчас идём другим путём — хотим, чтобы у каждого микросервиса был, скажем, свой микрокластер postrgre или elastic (на контейнерах, чтобы не получать оверхед от виртуалок). Тогда мы сможем ограничить негативное влияние одного микросервиса на другие.

                    Мы всегда исходим из того, что накосячить могут все и очень разным способом и под каждый способ накосячить невозможно держать отдельного человека, поэтому более стратегически правильно научиться минимизировать взаимовлияние (изоляция + деградация) и время простоя компонент (алерты + автоматизация).
            +3
            А почему у компании такое токсичное название — это как-то помогает продавать недвижимость?
              +2

              :) ЦИАН — это аббревиатура Центральное Информационное Агентство Недвижимости. Наследие истории.

                +1
                Тоже всегда интересовал вопрос почему cian, оказывается все так просто :)
            +4
            Цифровизация — это, конечно, хорошо. Но почему при поиске квартир с активированным фильтром «тип дома: кирпич, монолит» ЦИАН иногда подкидывает квартиры в панельных домах, у которых это даже написано в разделе «О доме»?
              +3
              Потому что у Циана есть спонсоры, которым разрешено добавлять на сайт «заманухи». В первую очередь Инком, но может быть есть и другие.

              Отсюда квартиры в панельных домах при поиске кирпичных, отсюда квартиры с газовыми плитами в электрифицированных домах и так далее. Важно, чтобы вы увидели «замануху», а цифровизация это вторично.
                +1
                Возможно, это реклама (как в поисковиках, когда вот вы искали обои, а вам также предлагают перфораторы). А, возможно, это баг — у нас достаточно серьёзно относятся к разбору вопроов и отзывов пользователей — попробуйте описать проблему через обратную связь.
                +2

                8k rps и 300 серверов… Куда столько? Допустим с десяток фронтов, бэки, очереди, базы, реплики, статика, логи… но куда 300?

                  +1
                  Может по физическому серверу на каждый микросервис + резервирование?
                  Тогда вполне можно понять.
                  Никто ж не писал, что на каждом из серверов топовое железо — может 2/3 на Атомах?
                    +2
                    8к RPS это только «входящие». К примеру, для того, чтобы показать вам (залогиненному пользователю) результаты поиска нужно выполнить гораздо больше запросов в разные микросервисы — показать вам вашу «шапку» с вашим балансом, отметить «сердечком» в результатах поиска те, которые вы отметили ранее, посмотреть доступны ли вам чатики для этих объявлений, да и просто проранжировать под вас выдачу. Там ещё куча всего «под капотом», что отличает обыный список от выдачи современного информационного ресурса. Так что внутри это далеко не 8к RPS :)
                      +1

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

                        +1
                        Мы как раз считаем себя не из тех, кто может просто «заливать железом». Так было бы гораздо проще всё в облаках купить и не морочить себе голову. Но реальность такова, что даже самый дешёвый облачный хостинг будет стоить минимум в два раза дороже того, что мы смогли отстроить.
                        Поэтому, да — занимаемся оптимизацией. Наверное, не так, как если бы у нас было 10 серверов, но всё же активно с этим работаем.
                        И, пожалуй, самое «тяжёлое» по железу это не C#, а machine learning (ибо big data и все дела) и, как ни странно, frontend (nodejs server side rendering) — там много CPU bound операций (парзинг json, рендеринг html), на которые приходится достаточно большой RPS. Но шарп мы тоже активно переводим на .NET Core (и вот скоро приступим к переводу на .NET Core 3).
                          +1

                          Про облака согласен, дорого, и местами теряется контроль.

                    +1
                    >>> оценка и аналитика — оценка реальной стоимости продажи квартиры и инвестиционной

                    Как я понимаю, используете некие математические модели. Но по любому нужно иметь доступ к информации о реальных продажах. У вас есть такой источник?
                      +1
                      да, есть информация по достаточно большому числу сделок, об которые мы валидируем модель
                        +1
                        На Циане вроде калькулятор оценки квартир был. Он еще есть? Если есть, то вы там матмодель, валидированную по реальным ценам используете? Т. е. цену калькулятор дает не по рекламным хотелкам, а прогнозирует реальную (с некой погрешностью, разумеется)?
                          +1
                          Есть, и более того мы недавно зарелизили новую версию, где теперь показывается и точность оценки и расхождение между реальными сделками и рекламными ценами. Последние как правило выше реальных.
                            +1
                            Спасибо. Коррекция модели по реальным ценам — это важно. Но большинство риэлторов, похоже, не в курсе об этой коррекции и считают, что подобные калькуляторы тупо отражают лишь рекламные хотелки.
                              +1
                              Они всё знают ;) Просто так удобнее обосновывать ту цену, которую им нужно, чтобы вы считали правильной.
                                +1
                                Сейчас проверил по вашему калькулятору квартиры, по которым знаю реальные продажные цены (правда трехлетней давности). Да, цену калькулятор дает весьма точную, близкую к реальной. Правда, в конце прошлого года был аномальный всплеск, но его имхо и нет смысла учитывать.

                                >>> Они всё знают ;)

                                Одно дело — просто знать, а другое дело — понимать, как это реально работает. Если бы я был далек от высшей математики, то тоже не доверял бы таким калькуляторам.
                        +4
                        А как вы проверяете юридическую чистоту квартиры? И вообще есть ли модерация объявлений?
                          +1
                          >И вообще есть ли модерация объявлений?

                          А куда же без неё. Мы очень активно боремся за чистоту контента, выявляем различные виды нарушений. Начиная от банальных непреднамеренных ошибок в параметрах объявления, заканчивая намеренным размещением «заманух» (несуществующих привлекательных объявлений с целью получить звонки) и даже «лохотронов» (несуществующих объявлений, размещаемых с целью кинуть пользователей на деньги). Для чего мы разрабатываем различные инструменты (статические алгоритмы, модели ML, интеграции с внешними сервисами), которыми пользуются наши сотрудники-модераторы.

                          Для более глубокого погружения в тему выявления видимых нарушений можно посмотреть наш доклад на PyData в прошлом году: www.youtube.com/watch?v=VAGV7aqani4
                          +1
                          Настраивали систему антиботов и сами себя забанили.

                          lol! просто и со вкусом :)
                          Кстати, а сильно ли мешают боты, и стоило ли оно того?

                            +1

                            Да, прилично. Трафик от ботов, по предварительной оценке, может доходить до 50%. Мы не для них тут сервера покупаем.

                            +1
                            Есть ли разделение по специализациям у мобильных разработчиков, и, если да, то какие?
                              +1
                              Да, деляться на IOS и Android. Внутри технологии поделены по продуктовым командам и живут жизнью продуктовой команды. Но так же есть гильдии IOS и Android, где обсуждают технологические вопросы и развитие платформы.
                                +1
                                Хотел было в вопросе же всё уточнить (и надо было). Сетевой стек, интерфейсы (жилые объекты, коммерческая недвижимость, ...), карты и локация, и т.д.
                              0
                              Почему на ЦИАНе не отображаются авы пользователей? Я загрузил котика, а все видят серый силуэт. Так квартиру не продашь :(
                                0
                                На мой взгляд штаты, инфраструктура и задачи чрезвычайно раздуты. Ну просто нет такого количества клиентов, это какой то искусственно раздутый трафик и искусственно созданные задачи.
                                1,2 миллиона уникальных клиентов в день? — для недвижимости это бред.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    +1
                                    Под таким громким названием поста, зашел почитать как внедрили интеграцию с Госуслугами-Росреестром (минимум логин — максимум получение информации об объектах недвижимости) и отсеяли агентов от реальных собственников недвижимости и не увидел этого.
                                      +2
                                      Первый кто победит агентов по недвижимости захватит рынок реальных покупателей
                                        0
                                        В Китае сильно продвинулись в этом направлении, только врятли вам это понравится.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.