На картинке в delivery notification есть опция Webhook, при этом в самой документации найти не удалось. В результате, есть ли возможность при инциденте отправлять запрос из nxs-anomaly в кастомный сервис? Принимать ACK из кастомного сервиас вроде как можно.
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 позволено то, что не позволено другим) Но тем не менее, пользователей это не должно беспокоить, поэтому принимается, тут не всё идеально, будем улучшать.
Спасибо! Не хватает информации в TRIGGER_WEBHOOK о том, кого именно оповестить, учитывая эскалации.
На картинке в delivery notification есть опция Webhook, при этом в самой документации найти не удалось. В результате, есть ли возможность при инциденте отправлять запрос из nxs-anomaly в кастомный сервис?
Принимать ACK из кастомного сервиас вроде как можно.
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 позволено то, что не позволено другим) Но тем не менее, пользователей это не должно беспокоить, поэтому принимается, тут не всё идеально, будем улучшать.