1) Видимо речь про SaaS, там действительно exe. В On-Prem используется msi. Мы прямо сейчас унифицируем подходы, так что будет везде единый msi. 2) Мы также уже разработали, а сейчас внедряем единый SSO, так что позже в этом году и в On-Prem и в SaaS будет иная авторизация. Логин/пароль нужно будет вводить только один раз в рамках супераппа, а ещё будет возможность включить 2FA.
Ну вот аккуратно запускать и ждать не всегда есть возможность, нужно чтобы пользователи не замечали проблем, даже когда отказывает какой-либо из компонент.
Откажет/опустошится кеш, нагрузка пройдёт на базу, а если база не готова к такому, система ляжет. Таким образом, кеш становится критическим узлом системы. Убеждён, что это ошибка архитектуры, такой компромис недопустим. Представьте, что у вас глобальный сбой был и необходимо заново поднять систему, кеш пуст, а миллион пользователей пытается воспользоваться сервисом и кладут базу и по кругу, вы поднимаете, они кладут.
Кеш может пропадать не только и не столько из-за падучести, а скорее из-за каких-либо работ на серверах, не знаю там, переездах между ЦОДами, да банального рестарта или холодно старта сервиса. Система должна всегда быть готова держать нагрузку, иначе, какая-нибудь ошибка с кешем и у вас начнёт падать вся инфраструктура, которая за ним.
Ещё раз повторю, я не против редиса, когда речь о снижении лэтенси идёт, но не стоит на него полагаться, что в хайлоаде он снизит нагрузку, не снизит.
Как раз, когда вы для каждого экземпляра сервиса создали отдельную схему и вынесли её на отдельный инстанс бд, у вас и получается клетка. А шардинг на самом верху, где-то на уровне гейтвея. Но только в своей парадигме клетка может содержать несколько экземпляров разных сервисов.
Редис же в нагруженных системах - это вообще антипаттерн. Его можно использовать только в стремлении к уменьшению лэтенси, но не нагрузки. Т.е. банально в какой-то момент кеш может пропасть и все сервисы за ним получат резкий рост нагрузки, а значит они должны всегда быть готовы её принять. Ну и я молчу, что есть подтвержденные кейсы в российских реалиях, когда большие распределённые кластера редис теряли часть данных.
Проблемы начинаются, когда запись очень большая и нужны сотни тысяч или миллионы rps. Тогда подход "провод в стену" и не важно что там за база, начинает порождать уйму проблем. Как раз становится проще поддерживать множество не сильно загруженных клеток, каждая из которых переваривает, например, 10к RPS, что вполне щадящее.
Ну и повторюсь, что этой "моде" уже лет 15, так точно, а может и побольше.
Мультенантность всё же подразумевает, что сервисы могут быть общими, а данные хранятся отдельно. Тут же аналогичная идея по сути, но немного на более высоком уровне решена. При этом не факт, что прям по тенантам режется, можно и внутри Теннанта разделить на разные клетки, вопрос реализации.
Почему же не бывает, например, какое-нибудь приложение, по типу Miro, где можно явно подмножества пользователей и их пространств работы выделить. Ну и понятно что речь про highload идёт.
Если я правильно понял, то клетки должны быть логически развязаны в идеале. Т.е. шардинг данных должен быть реализован на уровне сервисов или может даже как-то на уровне клиентского приложения.
Идея в том, что разные экземпляры сервиса оперируют разным подмножеством данных. Т.е. одна клетка не знает ничего о данных другой и физически не может получить к ним доступ.
Ну давайте так, касательно работы службы поддержки не готов комментировать, ибо это точно не в моей компетенции. Но тут возможно вам виднее, как надо выстроить. Из того что вы написали, я так понимаю у вас есть опыт, было бы классно почитать, даже отдельную статью.
Важно понимать, что всё же сбор требований и желаний заказчиков в B2B и B2C происходит вообще по разному. Вы написали, что вы продакт, наверное понимаете ключевые моменты в этом. Тоже не вижу смысла комментировать, опять же, если у вас есть видение как вообще нужно выстраивать работу с пользовательскими требованиями в B2B, а особенно, когда они идут вразрез с требованиями заказчиков, было бы классно почитать.
Касательно технической части, про звонки уже писал, ну и точно не согласен с такой оценкой, т.к. пользуюсь ими каждый день, но повторюсь, точно есть что улучшать и прямо сейчас это делаем.
Про масштабируемость, вы видимо не совсем верно понимаете значение этого термина, это не про смену ФИО/email, а про возможность подстраиваться под разную нагрузку.
Ну почему же, у вас своё видение, как должны работать закрепы, это хорошо. Я описал выше из каких моментов мы исходили, когда проектировали текущую логику. А именно то, что архивировать закрепы - не частая операция, а ошибочно архивировать важный чат - должно быть трудно. Так же выше сказал, что закрепы мы вообще переделали в 24.3.
Всё же нормально, не понимаю вашего негодования. То что видение, как лучше сделать тот или иной функционал расходится - ну да, так бывает. Для этого мы регулярно проводим UX исследования на тестовых группах и понемногу такие штуки правим.
Из интересного, у нас сейчас в рассмотрении и проработке 600+ различных фич, так что просто даже, чтобы классифицировать, обработать и ранжировать все приходящие идеи или замечания, без разработки, выстроен отдельный процесс))
Касательно поведения, когда чат закреплён и его нужно архивировать, коллеги подсказываю, что идеологически закрепы - это важные чаты и там кнопка архивировать специально скрыта, чтобы пользователь случайно не потерял его.
К сожалению, то что вы пытаетесь анонимизировать себя, не позволят обсудить что-либо профессионально, с точки зрения тех или иных дисциплин(
Так у вас нет же вопросов, есть комментарии, уверяю, мы их принимаем во внимание.
Подскажите, а на чем вы специализируетесь? Поясню, статья всё же техническая, прежде всего, а темы вы поднимаете и продуктовые, и по UI, и по документации, и по саппорту, и по эксплуатации. И часть моментов весьма дискуссионная, поэтому и хочется более профессионально подойти к теме, мы же на технической площадке общаемся, в конце концов.
Например, вопрос автоматического обновления, это скорее вопрос к эксплуатации внутри вашей компании или службе ИБ. Технически это возможно, но а почему у вас эта возможность закрыта мне тяжело прокомментировать)
Ну или по поводу того, почему нельзя просто взять и сделать как в Slack. Тут тоже не очень понятно как это комментировать. Если вы занимаетесь продуктовой разработкой, интересно было бы узнать, как у вас устроено выставление приоритетов и копирование удачных фич конкурентов. Я тут малость не на свою поляну захожу, но Slack не стал бы столько стоить, если бы его можно было за годик - другой или даже за 5 лет легко скопировать и обогнать. Да и нужно ли это?
Есть такое, но в ближайших релизах процедура обновления значительно упростится.
Хотя на нашей практике, когда речь идёт про он-прем, то тут очень много различий между клиентами, как они эксплуатируют свою инфраструктуру, пользуются ли они гитопс практиками или им нужен UI инсталлятор, как выстроена работа ИБ и т.д. В результате, то что у одних может занимать пол дня, у других - недели.
По поводу меншона в меню, это старая бага, мы её осенью поправили ещё, видимо у вас старая версия.
Звонки за прошлый год сделали большой рывок вперёд, добавив возможность проводить конференции на 300 человек, модерацию, запись звонка, чаты, работу при условии плохой связи, да и вообще полностью переделали интерфейс. Стабильность зачастую упирается в эксплуатацию и тут мы сейчас делаем этот процесс более прозрачным, но и нам есть куда расти, последние релизы очень активно повышаем именно качество работы звонков и будем это продолжать.
Ну а пуши, это вообще увлекательная тема, возможно на отдельную статью, т.к. самым крупным мессенджерам при работе на iOS/Android позволено то, что не позволено другим) Но тем не менее, пользователей это не должно беспокоить, поэтому принимается, тут не всё идеально, будем улучшать.
Пожалуй ни с того начал, прежде всего спасибо за отзыв, это действительно важно.
Мы смотрим на конкурентов, конечно. Про треды повторюсь, что сами понимаем, что они далеко не идеальны, их действительно надо развивать.
Закрепы начнут синхронизироваться с 24.3. С архивами специально проверял и на компе и на телефоне на 24.2, прежде чем написать. Везде есть прям под пунктом добавить в папку, но я услышал, даже любопытно. По отложенным сообщения, судя по отзывам, очень востребованная функция оказалась, прежде всего когда хотят коллеге что-то вечером написать так, чтобы с утра к нему пришло сообщение.
Тосты прилетают, но в панель уведомлений на винде действительно не выводятся. Тут согласен, на винде когда-то очень плохо работали системные уведомления, мы делали свои, сейчас есть задача в бэклоге полноценно поддержать системные.
По работе тех поддержки услышал, передам коллегам. Знаю, что они активно вкладываются сейчас и в написание документации, и в различные обучающие программы, прежде всего чтобы в эксплуатации компаний клиентов сформировать нужные компетенции.
MSI для SaaS теперь доступен для скачивания - https://biz.mail.ru/teams/download/ ;)
Тут есть, что сказать мне)
1) Видимо речь про SaaS, там действительно exe. В On-Prem используется msi. Мы прямо сейчас унифицируем подходы, так что будет везде единый msi.
2) Мы также уже разработали, а сейчас внедряем единый SSO, так что позже в этом году и в On-Prem и в SaaS будет иная авторизация. Логин/пароль нужно будет вводить только один раз в рамках супераппа, а ещё будет возможность включить 2FA.
Ну вот аккуратно запускать и ждать не всегда есть возможность, нужно чтобы пользователи не замечали проблем, даже когда отказывает какой-либо из компонент.
Откажет/опустошится кеш, нагрузка пройдёт на базу, а если база не готова к такому, система ляжет. Таким образом, кеш становится критическим узлом системы. Убеждён, что это ошибка архитектуры, такой компромис недопустим. Представьте, что у вас глобальный сбой был и необходимо заново поднять систему, кеш пуст, а миллион пользователей пытается воспользоваться сервисом и кладут базу и по кругу, вы поднимаете, они кладут.
Кеш может пропадать не только и не столько из-за падучести, а скорее из-за каких-либо работ на серверах, не знаю там, переездах между ЦОДами, да банального рестарта или холодно старта сервиса. Система должна всегда быть готова держать нагрузку, иначе, какая-нибудь ошибка с кешем и у вас начнёт падать вся инфраструктура, которая за ним.
Ещё раз повторю, я не против редиса, когда речь о снижении лэтенси идёт, но не стоит на него полагаться, что в хайлоаде он снизит нагрузку, не снизит.
Как раз, когда вы для каждого экземпляра сервиса создали отдельную схему и вынесли её на отдельный инстанс бд, у вас и получается клетка. А шардинг на самом верху, где-то на уровне гейтвея. Но только в своей парадигме клетка может содержать несколько экземпляров разных сервисов.
Редис же в нагруженных системах - это вообще антипаттерн. Его можно использовать только в стремлении к уменьшению лэтенси, но не нагрузки. Т.е. банально в какой-то момент кеш может пропасть и все сервисы за ним получат резкий рост нагрузки, а значит они должны всегда быть готовы её принять. Ну и я молчу, что есть подтвержденные кейсы в российских реалиях, когда большие распределённые кластера редис теряли часть данных.
Проблемы начинаются, когда запись очень большая и нужны сотни тысяч или миллионы rps. Тогда подход "провод в стену" и не важно что там за база, начинает порождать уйму проблем. Как раз становится проще поддерживать множество не сильно загруженных клеток, каждая из которых переваривает, например, 10к RPS, что вполне щадящее.
Ну и повторюсь, что этой "моде" уже лет 15, так точно, а может и побольше.
Не, как привели пример выше, упрощая, смысл в том, что "один экземпляр сервиса - одна база".
И действительно, это не что-то супер новое, знаю ряд highload продуктов, которые давно живут в такой же парадигме. Да и сами следуем ей.
Мультенантность всё же подразумевает, что сервисы могут быть общими, а данные хранятся отдельно. Тут же аналогичная идея по сути, но немного на более высоком уровне решена. При этом не факт, что прям по тенантам режется, можно и внутри Теннанта разделить на разные клетки, вопрос реализации.
Можно так сказать
Почему же не бывает, например, какое-нибудь приложение, по типу Miro, где можно явно подмножества пользователей и их пространств работы выделить. Ну и понятно что речь про highload идёт.
Если я правильно понял, то клетки должны быть логически развязаны в идеале. Т.е. шардинг данных должен быть реализован на уровне сервисов или может даже как-то на уровне клиентского приложения.
Идея в том, что разные экземпляры сервиса оперируют разным подмножеством данных. Т.е. одна клетка не знает ничего о данных другой и физически не может получить к ним доступ.
Ну давайте так, касательно работы службы поддержки не готов комментировать, ибо это точно не в моей компетенции. Но тут возможно вам виднее, как надо выстроить. Из того что вы написали, я так понимаю у вас есть опыт, было бы классно почитать, даже отдельную статью.
Важно понимать, что всё же сбор требований и желаний заказчиков в B2B и B2C происходит вообще по разному. Вы написали, что вы продакт, наверное понимаете ключевые моменты в этом. Тоже не вижу смысла комментировать, опять же, если у вас есть видение как вообще нужно выстраивать работу с пользовательскими требованиями в B2B, а особенно, когда они идут вразрез с требованиями заказчиков, было бы классно почитать.
Касательно технической части, про звонки уже писал, ну и точно не согласен с такой оценкой, т.к. пользуюсь ими каждый день, но повторюсь, точно есть что улучшать и прямо сейчас это делаем.
Про масштабируемость, вы видимо не совсем верно понимаете значение этого термина, это не про смену ФИО/email, а про возможность подстраиваться под разную нагрузку.
Ну почему же, у вас своё видение, как должны работать закрепы, это хорошо. Я описал выше из каких моментов мы исходили, когда проектировали текущую логику. А именно то, что архивировать закрепы - не частая операция, а ошибочно архивировать важный чат - должно быть трудно. Так же выше сказал, что закрепы мы вообще переделали в 24.3.
Всё же нормально, не понимаю вашего негодования. То что видение, как лучше сделать тот или иной функционал расходится - ну да, так бывает. Для этого мы регулярно проводим UX исследования на тестовых группах и понемногу такие штуки правим.
Из интересного, у нас сейчас в рассмотрении и проработке 600+ различных фич, так что просто даже, чтобы классифицировать, обработать и ранжировать все приходящие идеи или замечания, без разработки, выстроен отдельный процесс))
Касательно поведения, когда чат закреплён и его нужно архивировать, коллеги подсказываю, что идеологически закрепы - это важные чаты и там кнопка архивировать специально скрыта, чтобы пользователь случайно не потерял его.
К сожалению, то что вы пытаетесь анонимизировать себя, не позволят обсудить что-либо профессионально, с точки зрения тех или иных дисциплин(
Так у вас нет же вопросов, есть комментарии, уверяю, мы их принимаем во внимание.
Подскажите, а на чем вы специализируетесь? Поясню, статья всё же техническая, прежде всего, а темы вы поднимаете и продуктовые, и по UI, и по документации, и по саппорту, и по эксплуатации. И часть моментов весьма дискуссионная, поэтому и хочется более профессионально подойти к теме, мы же на технической площадке общаемся, в конце концов.
Например, вопрос автоматического обновления, это скорее вопрос к эксплуатации внутри вашей компании или службе ИБ. Технически это возможно, но а почему у вас эта возможность закрыта мне тяжело прокомментировать)
Ну или по поводу того, почему нельзя просто взять и сделать как в Slack. Тут тоже не очень понятно как это комментировать. Если вы занимаетесь продуктовой разработкой, интересно было бы узнать, как у вас устроено выставление приоритетов и копирование удачных фич конкурентов. Я тут малость не на свою поляну захожу, но Slack не стал бы столько стоить, если бы его можно было за годик - другой или даже за 5 лет легко скопировать и обогнать. Да и нужно ли это?
Есть такое, но в ближайших релизах процедура обновления значительно упростится.
Хотя на нашей практике, когда речь идёт про он-прем, то тут очень много различий между клиентами, как они эксплуатируют свою инфраструктуру, пользуются ли они гитопс практиками или им нужен UI инсталлятор, как выстроена работа ИБ и т.д. В результате, то что у одних может занимать пол дня, у других - недели.
По поводу меншона в меню, это старая бага, мы её осенью поправили ещё, видимо у вас старая версия.
Звонки за прошлый год сделали большой рывок вперёд, добавив возможность проводить конференции на 300 человек, модерацию, запись звонка, чаты, работу при условии плохой связи, да и вообще полностью переделали интерфейс. Стабильность зачастую упирается в эксплуатацию и тут мы сейчас делаем этот процесс более прозрачным, но и нам есть куда расти, последние релизы очень активно повышаем именно качество работы звонков и будем это продолжать.
Ну а пуши, это вообще увлекательная тема, возможно на отдельную статью, т.к. самым крупным мессенджерам при работе на iOS/Android позволено то, что не позволено другим) Но тем не менее, пользователей это не должно беспокоить, поэтому принимается, тут не всё идеально, будем улучшать.
Для более понятного описания функционала коллеги выпускаю ролики, сейчас их не так легко найти, но в скором времени это будет значительно удобнее.
Например, про папки - https://biz.mail.ru/docs/on-premises/Teams/rp/rp/index.html#_16
Пожалуй ни с того начал, прежде всего спасибо за отзыв, это действительно важно.
Мы смотрим на конкурентов, конечно. Про треды повторюсь, что сами понимаем, что они далеко не идеальны, их действительно надо развивать.
Закрепы начнут синхронизироваться с 24.3.
С архивами специально проверял и на компе и на телефоне на 24.2, прежде чем написать. Везде есть прям под пунктом добавить в папку, но я услышал, даже любопытно.
По отложенным сообщения, судя по отзывам, очень востребованная функция оказалась, прежде всего когда хотят коллеге что-то вечером написать так, чтобы с утра к нему пришло сообщение.
Тосты прилетают, но в панель уведомлений на винде действительно не выводятся. Тут согласен, на винде когда-то очень плохо работали системные уведомления, мы делали свои, сейчас есть задача в бэклоге полноценно поддержать системные.
По работе тех поддержки услышал, передам коллегам. Знаю, что они активно вкладываются сейчас и в написание документации, и в различные обучающие программы, прежде всего чтобы в эксплуатации компаний клиентов сформировать нужные компетенции.