От скриптов к собственной платформе: как мы автоматизировали разработку в ЦИАН

[KYuri]

Ждем предложений, что осветить детально, пишите в комментариях.

Осветите, пожалуйста, детально, как у вас принимаются решения (и оцениваются последствия) об изменении пользовательского опыта?

На моей памяти было как минимум два переезда с одного домена на другой страницы ввода логина/пароля, из-за чего сохраненный в менеджере пароль не подхватывался, а т.к. имена этих самых доменов не коррелировали с «ЦИАН»/«cian», то и ручной поиск в менеджере паролей превращался в интересный квест.

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

Но у меня как у пользователя уже возникает вопрос «Стоит ли мне напрягаться, если а) потом снова всё сломают поменяют и б) появились неплохие альтернативы?».

[Aleksey_Chekanov]

Домены мы никогда не меняли на всей протяженности жизни с 2001 сайт был и остается на домене cian.ru, возможно речь идет о нашем же уже закрывшемся проекте realty.dmir.ru, который полностью слился с основным cian.ru и зеркало было закрыто, что бы не путать пользователей и поисковых ботов. А возможно, вы стали жертвой фишинга.
Касаемо включения двухфакторной авторизации, включили ее на фоне уплывшей базы пользователей одного крупного стороннего сервиса. А так как многие пользователи имеют на разных сайтах одинаковые пароли, мы столкнулись с проблемой взлома аккаунтов наших пользователей. Что бы их защитить сделали дополнительную проверку. Кстати, это защищает пользователей и от другого рода мошенников. Если номер телефона утерян, доступ легко восстановить через клиентскую службу, как уже сделали многие.
Изменения продукта проходят сначала через интервью наших пользователей и клиентов, на которых исследователи и продукт-менеджеры выясняют боли и потребности пользователей и вырабатывают решения, которые дальше запускаются через A/B тесты. Думаю, мы еще напишем и про процесс исследований и про нашу систему A/B.

[roller]

Что такое queue size == 1.5 на первой картинке?

[alex_kor]

Если вопрос про график «Watcher queue size», то он отображает число выкладок, за которыми наблюдает сервис мониторинга выкладок. Иногда там могут отображаться дробные значения, т.к. эта метрика пишется через statsd, плюс еще может влиять выбранный временной диапазон для графика.

[Age1mar]

Подскажите, «внедрили автоматический мониторинг фона ошибок с автоматическим реагированием на его превышение» — вам не подошел функционал того же Sentry?

[alex_kor]

Только Sentry нам не хватило бы, т.к. мы наблюдаем как за ошибками «из приложений», так и за кодами ответов API микросервиса + отслеживаем все ли контейнеры поднялись. В планах есть идеи начать наблюдать за потреблением CPU/RAM и временем ответа сервиса.

[JuriM]

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

[alex_kor]

Я в целом согласен, что избыточная автоматизация вредна, но считаю, что мы оптимальный предел автоматизации еще не достигли.

Автоматизация с одной стороны помогает, защищая от «человеческого фактора», а с другой иногда сама их создает, запрещая определенные действия с точки зрения конвейера. Примером тому может быть ситуация, когда нужно выкатить изменение одного конфигурационного файла в проекте. Конвейер автоматизации требует прохождения тестов (это не всегда быстро), но если ждать нельзя (Prod лежит, например) и есть 100% уверенность в безопасности изменений, то можно запустить вручную сборку и последующий деплой этих изменений в обход конвейера.

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

[max-petrovich]

Расскажите про Ваш опыт с Keycloak — он используется только для меж сервисного общения, либо аутентификация на web так же на нем реализована? Последнее время активность релизов keycloak совсем слабенькая, баги не фиксятся

[alex_kor]

Мы используем Keycloak для аутентификации и базовой авторизации сервисов и пользователей. Работаем через Open ID Connect (OIDC), синхронизируемся с Active Directory.

Каких-либо серьезных нареканий нет, местами не очень удобный UI, но в целом он нас вполне устраивает. Релизы, кажется, довольно частые (последние 3 релиза с интервалом 1-2 месяца).

[max-petrovich]

На вашем сайте заметил аутентификацию через номер телефона — это тоже работает через keycloak? И вопрос по деплою keycloak — на данный момент у keycloak нет способа деплоить приложение без обрыва сессий пользователей (так как сессии они хранят в памяти приложения) — как с этим боролись?

[alex_kor]

Мы не используем Keycloak на сайте ЦИАН, он используется во внутренних сервисах. Возможно я неправильно понял вопрос, но Keycloak сам не деплоит приложения, он используется для аутентификации/авторизации внутри приложений.

У нас есть два сценария использования:
1) если потеря сессии не важна, то просто ничего не делаем. При входе в сервис пользователь получит редирект, уйдет в Keycloak и там авторизуется (в т.ч. автоматически, если в Keycloak сессия еще не протухла), далее редиректом вернётся обратно в сервис уже аутентифицированным. Этот работает только в случае, когда у вас один инстанс приложения, в противном случае будут постоянные редиректы с разных инстансов и все сломается.
2) если сессия важна, то в этом случае подключается распределенный кеш (в нашем случае Ignite), в котором хранятся все сессии пользователей. В этом случае любая сессия будет известна всем инстансам/сервисам, подключенным к кешу. Для корректной работы этого сценария все сервисы должны использовать куки одного и того же домена.