Комментарии 12
Ждем предложений, что осветить детально, пишите в комментариях.
Осветите, пожалуйста, детально, как у вас принимаются решения (и оцениваются последствия) об изменении пользовательского опыта?
На моей памяти было как минимум два переезда с одного домена на другой страницы ввода логина/пароля, из-за чего сохраненный в менеджере пароль не подхватывался, а т.к. имена этих самых доменов не коррелировали с «ЦИАН»/«cian», то и ручной поиск в менеджере паролей превращался в интересный квест.
А теперь вы зачем-то без спроса включили двухфакторную авторизацию. У меня с момента первоначальной регистрации изменился номер телефона. Решить можно — заполнить анкету и обратиться в службу поддержки.
Но у меня как у пользователя уже возникает вопрос «Стоит ли мне напрягаться, если а) потом снова всё
Касаемо включения двухфакторной авторизации, включили ее на фоне уплывшей базы пользователей одного крупного стороннего сервиса. А так как многие пользователи имеют на разных сайтах одинаковые пароли, мы столкнулись с проблемой взлома аккаунтов наших пользователей. Что бы их защитить сделали дополнительную проверку. Кстати, это защищает пользователей и от другого рода мошенников. Если номер телефона утерян, доступ легко восстановить через клиентскую службу, как уже сделали многие.
Изменения продукта проходят сначала через интервью наших пользователей и клиентов, на которых исследователи и продукт-менеджеры выясняют боли и потребности пользователей и вырабатывают решения, которые дальше запускаются через A/B тесты. Думаю, мы еще напишем и про процесс исследований и про нашу систему A/B.
Что такое queue size == 1.5 на первой картинке?
Автоматизация с одной стороны помогает, защищая от «человеческого фактора», а с другой иногда сама их создает, запрещая определенные действия с точки зрения конвейера. Примером тому может быть ситуация, когда нужно выкатить изменение одного конфигурационного файла в проекте. Конвейер автоматизации требует прохождения тестов (это не всегда быстро), но если ждать нельзя (Prod лежит, например) и есть 100% уверенность в безопасности изменений, то можно запустить вручную сборку и последующий деплой этих изменений в обход конвейера.
Наша автоматизация это скорее помощник для команд и разработчиков, в одних ситуациях мы просто подсвечиваем проблему, в других ставим запреты на определенные действия. Но всегда есть альтернативный путь, когда мы сознательно можем срезать часть процесса и в ручном режиме выполнить определенные операции (доступно, естественно, только определенным людям). Это позволяет нам поддерживать баланс между автоматизацией и ее ограничениями.
Каких-либо серьезных нареканий нет, местами не очень удобный UI, но в целом он нас вполне устраивает. Релизы, кажется, довольно частые (последние 3 релиза с интервалом 1-2 месяца).
Мы не используем Keycloak на сайте ЦИАН, он используется во внутренних сервисах. Возможно я неправильно понял вопрос, но Keycloak сам не деплоит приложения, он используется для аутентификации/авторизации внутри приложений.
У нас есть два сценария использования:
1) если потеря сессии не важна, то просто ничего не делаем. При входе в сервис пользователь получит редирект, уйдет в Keycloak и там авторизуется (в т.ч. автоматически, если в Keycloak сессия еще не протухла), далее редиректом вернётся обратно в сервис уже аутентифицированным. Этот работает только в случае, когда у вас один инстанс приложения, в противном случае будут постоянные редиректы с разных инстансов и все сломается.
2) если сессия важна, то в этом случае подключается распределенный кеш (в нашем случае Ignite), в котором хранятся все сессии пользователей. В этом случае любая сессия будет известна всем инстансам/сервисам, подключенным к кешу. Для корректной работы этого сценария все сервисы должны использовать куки одного и того же домена.
От скриптов к собственной платформе: как мы автоматизировали разработку в ЦИАН