VK Teams — защищенное пользовательское суперприложение для совместной работы сотрудников с любого устройства. Оно помогает компаниям организовывать коммуникацию, совместную работу команд, обмен данными и не только. Но так было не всегда — решение изначально имело небольшую функциональность и создавалось в качестве внутреннего мессенджера для сотрудников внутри VK.
Меня зовут Евгений Макархин. Я архитектор VK Teams. В этой статье я расскажу, как мессенджер VK Teams прошел путь от внутреннего решения до супераппа и как менялась его архитектура.
VK Teams сейчас
Этот инструмент объединяет в едином цифровом пространстве более десяти готовых приложений: мессенджер, видеоконференции, почту, календарь, диск, задачи, оргструктуру, опросы, профили, боты, мини-приложения для автоматизации HR-процессов и многое другое. Причем их можно дополнять своими решениями, расширяя возможности.
С помощью VK Teams команды могут получить в контуре одного супераппа всё, что им нужно.
VK Teams доступен в двух версиях:
сервис в облаке (software as a service, SaaS);
On-Premises-решение, развертываемое на инфраструктуре клиента.
Причем обе версии продукта востребованы. В самой крупной инсталляции приложения работают около 500 тысяч пользователей. При этом, разрабатывая On-premises инсталляцию, мы ориентируемся как на достаточно небольшие компании в 200 человек, так и на самые крупные корпорации на рынке, имеющие более 700 тысяч сотрудников.
Подробнее о мессенджере
Прежде чем говорить о супераппе, вернемся к тому, с чего всё начиналось — к мессенджеру.
Мессенджер представляет собой сложный «комбайн» из сотен разных функциональностей, подчас даже неочевидных — папки, закрепы, архивы, черновики, метки просмотра и так далее.
Проектируя систему, мы могли бы пойти по хорошо изученному пути, создавая классическую трехуровневую архитектуру, разделив клиентские приложения, бизнес-логику и базы данных. Ключевой момент тут в обеспечении их горизонтального масштабирования, чтобы справиться с любой нагрузкой. Таким образом у нас был бы слой stateless-сервисов, количество которых можно менять динамически под нагрузку, и один или несколько кластеров СУБД, которая «под капотом» позволяла бы нам масштабировать запись по средствам шардинга.
Причем шардинг — ключевая технология в такой реализации, которая позволяет распределять данные и, как результат, балансировать общую нагрузку.
При этом разделение на шарды не влияет на «слаженность и синхронность» потоков данных — если сообщение отправителя попало в шард №3, то и сообщение получателя в дальнейшем также попадает в шард №3. То есть все переписки в рамках одного чата хранятся на одном шарде — при обращении к чату, он не будет собираться из разных частей, а будет доступен сразу.
Есть и альтернативный вариант проектирования, при котором экземпляр сервиса и базы данных формируют единую, неделимую «ячейку», компоненты которой зависимы, в том числе совместно масштабируются. В таком случае экземпляр сервиса является не промежуточным звеном, после которого запрос маршрутизируется к нужной БД, а фактически является «ключом» к нужному шарду БД. При этом каждая ячейка отвечает исключительно за небольшое подмножество всех данных сервиса.
Именно подобным образом организована наша система. Фактически мы решаем задачу шардирования не на уровне БД, а на уровне управления трафиком между сервисами.
Причем для нас не критично, что с каждым экземпляром сервиса поднимается полноразмерный экземпляр БД, что в других проектах может быть избыточно. Главное, что мы существенно повышаем удобство управления продуктом или системой — при обслуживании нагрузки от миллионов пользователей для нас это приоритетнее.
Примечательно, что изначально мы планировали выделять подобные ячейки на каждый отдельный сервер, т.е. одну большую ячейку на один сервер или ВМ. Но со временем столкнулись с тем, что поддерживать большие ячейки сложно и дорого, поэтому в результате пришли к реализации с множеством ячеек небольшого размера. Причем при большой нагрузке на ячейку и «перегреве» сервера, где развернута ячейка, нам достаточно просто перенести ячейку на другой сервер. Сценариев, при которых нужен решардинг (а это весьма дорогая операция), в таком случае минимум. Отчасти это похоже на принцип работы VShard в Tarantool.
Что под капотом у нашей системы
В момент создания VK Teams еще в качестве внутреннего корпоративного мессенджера (около 10 лет назад), для него было создано самописное хранилище KUST (Customizable Storage). Это Embedded persistent key-value read-optimized data store. Оно чем-то напоминает RocksDB, но оптимизировано под чтение и работу с HDD-дисками, выполняет дамп логов потоково, а не по расписанию.
KUST и сейчас позволяет нам надежно хранить терабайты данных, но со смещением фокуса на on-prem нам было важно, чтобы не только мы, но и наши клиенты могли управлять СУБД, находящимися «под капотом». К тому же в ряде сценариев мы хотели повысить скорость и улучшить пользовательский опыт. Поэтому мы начали смотреть в сторону готовых вендерских решений.
Поэтому уже сейчас большинство внутренних сервисов переведено на Tarantool — решение класса Middleware for data, которое сочетает в себе сервер приложений, гибридное хранилище с гибкой схемой данных и мощные средства масштабирования.
Миграция на Tarantool (который также входит в экосистему VK) дала нам возможность без снижения надежности хранения существенно повысить скорость работы хранилища, получить лучшую управляемость, что особенно важно для On-premises-решений, управление которыми в большей степени остается на стороне пользователя.
Базу данных мы выбрали. Следующий вопрос — как обеспечить коммуникацию сервисов?
Для коммуникации сервисов внутри VK Teams мы взяли за основу бинарный протокол обмена сообщениями IPROTO (созданный Mail.ru) и добавили к нему контроллер Ctlr, который позволил нам реализовать функционал Service Discovery и обеспечить контроль над потоками данных между сервисами. Так появился IPROS.
Контроллер хранит разряженную карту шардирования. Его задача:
мониторить состояние всех ячеек;
управлять ими: менять топологию, разделять, переносить и так далее.
Примечательно, что через контроллер не идет трафик. Поэтому, например, если во время решардинга контроллер станет недоступен, это не скажется на работоспособности всей системы — решардинг завершится и без него, а запросы к старому экземпляру сервиса будут автоматически (этим же старым экземпляром) перенаправляться к новому. Таким образом постепенно все сторонние сервисы, которым нужны переехавшие данные, узнают о том, что они теперь находятся по новому адресу. Это гарантирует надежность системы.
Теперь об обеспечении отказоустойчивости.
Пара «экземпляр сервиса — БД» неделима и всегда имеет реплику, которая находится в активном состоянии и готова в любой момент взять на себя нагрузку. Такая реализация гарантирует доступность и устойчивость в разных сценариях. Например, при переносе ячейки с одного сервера на другой:
реплика ячейки в фоне переносится на новый сервер (необязательный шаг);
контроллер дает команду flip основной ячейке;
основная ячейка переключает базу в режим Read Only, все входящие запросы блокируются (здесь мы полагаемся на прозрачную политику ретраев, согласно которой, рано или поздно запрос будет обработан);
основная ячейка отправляет во вторичную команду sink с идентификатором лога, который пришел последним;
при получении лога с указанным идентификатором ячейка-реплика на новом сервере переводит свою базу в readwrite, отправляет команду flop в контроллер, и подтверждение исходной ячейке, которая, в свою очередь, тоже отправляет flop в контроллер.
После этого ячейка-реплика остановится основной и начинает принимать все входящие запросы. На весь процесс уходит всего несколько сотен миллисекунд.
Важно, что даже сбой на уровне контроллера не снизит отказоустойчивость системы — если запросы придут в старую ячейку, она их перенаправит в новый главный узел.
Что нам дает работа с ячейками
Работа с ячейками, несмотря на упомянутую избыточность в некоторых моментах, дает нам ряд существенных преимуществ.
Простота управления. Управлять одной сущностью проще. К тому же, в нашей реализации всего одна степень свободы (при необходимости увеличения достаточно выполнить шардирование), что исключает разночтения.
Локализованность контекста и проблем. Всегда известно, куда в каждом конкретном случае поступает запрос. В случае поломки или сбоев, всегда понятно, где локализуется проблема — не надо исследовать весь кластер. Более того, при такой реализации любая ошибка потенциально затрагивает только очень ограниченное количество пользователей или чатов.
Минимизация влияния сетевой инфраструктуры. Экземпляр сервиса и база данных находятся близко друг к другу, что исключает влияние любых сетевых эффектов на доступность или скорость компонентов ячейки.
Повышенная безопасность данных. В связи с физической «развязанностью» системы, при взломе системы злоумышленник теоретически получает доступ только к одной ячейке, которая хранит очень ограниченный набор информации и не имеет доступа ко всем данным. Это уменьшает потенциальный ущерб.
От мессенджера к супераппу
Сейчас наш мессенджер всё также доступен, но уже в качестве отдельного приложения в рамках супераппа, из окна которого можно, не теряя контекста, обмениваться файлами, назначать встречи, ставить задачи и определять ответственных, делиться событиями и не только.
Архитектура супераппа значительно сложнее — помимо прочего, она включает и приложения звонков, оргструктуры, почты, календаря и другие.
Естественно, при переходе к супераппу, с ростом функциональности решения, изменились пул задач, который нам приходится решать, и архитектура инструмента, особенно в части возможностей интеграции с системами заказчика.
Сейчас мы делаем фокус на модульность и расширяемость при неизменной стабильности и масштабируемости.
Перед изменением архитектуры мы прошли организационные изменения — сделали команды модульными и независимыми, по-новому выстроили коммуникации внутри команд, унифицировали подходы и стек, согласовали общие практики.
Это повлекло и изменения на уровне архитектуры. Так, если раньше мы смотрели исключительно в сторону нагрузки, трафика и отказоустойчивости, то сейчас, наряду с обеспечением упомянутых параметров, в пул задач наших архитекторов также стало входить:
корректное выстраивание доменов;
помощь продактам в корректном распределении бизнес-инициатив по командам;
выстраивание взаимодействия между командами на техническом уровне через API, шины и другие компоненты.
То есть видение архитектора сильно меняется.
Выводы на основе нашего опыта
При построении приложения важна не только закладываемая в него функциональность, но и архитектура, которая во многом предопределяет возможности расширения, интеграции, модернизации, параметры стабильности и отказоустойчивости всей системы. На своем опыте мы убедились, что не всегда стоит идти по общепринятому, типовому пути. Архитектура — это всегда компромиссы, и нужно внимательно смотреть, можно ли с ними мириться в каждом конкретном случае.
Более того, важно понимать, что оптимизация должна затрагивать не только приложение — новые вызовы, требования и возможности должны учитываться и на уровне команд. Так, коммуникации должны меняться (привет закону Конвея), и мы как архитекторы должны иначе смотреть на свою роль.
Отчасти именно совместная адаптация продукта и команды помогли нам пройти путь от внутреннего корпоративного мессенджера до супераппа, которым пользуются сотни команд и миллионы людей.
Комментарии (24)
kozlov_de
15.04.2024 09:30На 2м слайде должно быть указано не Сервис А, Сервис Б, а Интсанс 1, Инстанс 2.
Инстанс = экземпляр сервиса
Принцип "database per service pattern" не относится к инстансам, они могут и в один экземпляр БД
Что делается когда надо запустить новый инстанс? Старый перегружен, чат должен переехать на новый сервис вместе со всеми данными чата, как?... На 5м слайде перенос (move) а не копирование (copy) и количество инстансов не меняется.
Запускаете новый инстанс, а где БД для него?
Видимо, создание нового инстанса это не быстрый процесс в такой схеме.
Expr0mt Автор
15.04.2024 09:30Идея как раз в том, чтобы заранее с избытком напилить инстансы, чтобы по ходу эксплуатации было проще балансировать нагрузку между серверами (заранее мы не предугадаем где будет чат будет на 200 человек, а где канал на 200 тыс.) просто перекидывая ячейки между ними. Этот процесс достаточно быстрый, занимает обычно от сотни миллисекунд до 1 секунды, и зависит прежде всего от нагрузки. Мы обычно проектируем так, чтобы не было больше 10к RPS на одну ячейку, даже если фактически она может и на порядок больше переварить.
Если всё же есть потребность "распилить" ячейку, то создаётся ещё одна пара "экземпляр сервис-БД" (плюс реплика для неё) и данные потихоньку начинаю мигрировать в неё. Т.е. происходит решардинг, это более трудоёмкая и длительная операция, но она также происходит без остановки обслуживания.Expr0mt Автор
15.04.2024 09:30Добавлю, что в кубере сама БД разворачивается сайдкаром к сервису внутри пода.
2malex
15.04.2024 09:30Под капотом все та же Jitsi meet? Или подошли к тому, чтобы написать полностью свою библиотеку?
Expr0mt Автор
15.04.2024 09:30Нет, в тимсе мы не используем Jitsi, у нас во многом свои наработки. Для того, чтобы не было путаницы, VK Звонки и звонки в VK Teams имеют разную технологическую базу.
Valenti_na
15.04.2024 09:30+2@kozlov_deБольше года вынужденно пользуюсь VK Teams и страдаю. Продукт абсолютно сырой. Такое ощущение что в Убежище 4 скрещивали Skype (как мы помним, лучший файлообменник), Microsoft Teams, ICQ, Телеграм и возможно пролетающую мимо муху в ходе чего получился VK Teams. Из болей: в мессенджере (если это можно так назвать) нет базовых инструментов для работы, пользоваться им каждый деть по 100 раз больно. На задачи по доработки служба поддержки VK Teams или HOLD'ит или отвечает "есть в планах" либо просит использовать костыли. Из таких примеров: VK Teams отсутствует возможность вести треды в личных сообщениях. Обсуждая параллельно несколько вопросов диалог превращается в кашу и разобрать что-то по прошествии длительного времени будет сложно. На что поддержка VK Teams предложила мне использовать функционал "Задачи" в личных сообщениях чтоб внутри нее вести диалог (топ предложение и ориентированность). От VIP поддержи только название, по сути за год пользования продуктом в нем кроме добавления папок (которые также криво работают и полностью скопированы от Телеграма) не изменилось НИ-ЧЕ-ГО! Реализация группировки по папкам весьма глупая идея: а) находясь в папке ты теряешь фокус с новых сообщений, которые приходят б) папки не переносятся на другие устройства (т.е. на каждом устройстве где находится программа нужно снова вводить настройки). Архивация чатов - чтобы заархивировать чат его нужно добавить в папку, а затем зайти в нее и оттуда архивировать. Зачем столько ненужных телодвижений? Про API больно даже говорить (вы видели когда-нибудь API icq, посмотрите на API VK Teams и узрите. Если написать бота на API VK Teams то его функции будут урезаны функционалом icq (если в icq нельзя было ботам писать в треды - в VK Teams будет именно так. Про постоянные вылеты, сбои, проблемы с подключением к звонку по ссылке я умолчу. Большая боль это отсутствие каких либо уведомлений для windows. Если приложение закрыто и его значек в трее скрыт под стрелочку - ты можешь пропустить сообщение. Просто не увидишь всплывающее сообщение и все. Если ты написал сообщение, а в тред к нему ответили или ты поучаствовал в обсуждении и в нем далее появились комментарии, или ты просто выбрал "Подписаться на все обсуждения" - НИЧЕГО ТЕБЕ НЕ ПРИДЕТ. Пуш уведомления на ios и Android аналогично не информируют о новых записях в тред.
Самое интересное, по данным от работников VK, внутри компании они не используют данный продукт, а предпочтение отдают Телеграм (за достоверность данного факта не ручаюсь).Valenti_na
15.04.2024 09:30@Expr0mt Немного тегом ошиблась, текст для автора поста.
И немного дополню про API.
В официальных документах VK Teams указаны следующие библиотеки для создания ботов:
* Python (PIP)
* Golang
* Java
Пройдя по ссылке Python (PIP) попадаем на сайт https://pypi.org/project/mailru-im-bot/ (мм mail.ru повеяло их "лучшим" мессенджером QIP (если что-то его застал в далеких 2000. Он кстати работал с ICQ, но в 2018 после отключения поддержки старых протоколов перестал). Ну собственно текст внизу страницы подтверждает теорию квинтэссенции всего наихудшего:
Но для пущей уверенности зайдем еще на GitHub. И оказывается что эта библиотека = бот mail.ru (оставлю ссылочку https://github.com/mail-ru-im/bot-python )
Таким образом 12 лет команда скрещивала ужа с ежом и получилось нечто.
Expr0mt Автор
15.04.2024 09:30+2Постараюсь прокомментировать, хотя больше отвечаю не за продуктовую, а за техническую сторону вопроса
Действительно сложно сравниться с продуктами, которые значительно старше, но тем не менее мы действительно видим и знаем как выстроить классную корпоративную платформу для коммуникаций. Из забавного как-то слышал, как один представитель бизнеса упрекал российский продукт аргументом "Даже в Exchange это есть". Нужно время.
Если сравнивать, например со Slack, то действительно треды реализованы иначе и, пожалуй, действительно мы не уделяем им сегодня столько времени, сколько хотелось бы, но это прежде всего связано с тем, что корпоративные заказчики видят другой функционал куда более приоритетным. И тут мы, как и большинство игроков на российском рынке, находимся ПОКА в догоняющей позиции, т.к. пользователи привыкли к лучшим мировым решения, а создать действительно взрослый аналог за несколько лет нереально.
По папкам спорно, лучше с продактами такое обсуждать, но а) они и предназначены для фокусировки внимания б) они хранятся на сервере и точно синхронизируются между устройствами в) для архивации чата не нужно его добавлять в папку, можно точно так же сделать и в основном списке. Опять же массово таких проблем точно не было, возможно какие-то частные случаи, надо разбираться.
По мессенджеру действительно появилось не так много. Зато из больших обновлений - появление оргструктуры в On-premises версии, значительное улучшение ВКС во всех инсталляциях и ряд других функций. В мессенджере появились папки, закрепы, архивы и отложенные сообщения. Всё это заехало за последние пол года. Как я вкратце упомянул в статье, новый подход к архитектуре и приложению в целом заставил нас значительно пересмотреть внутреннюю структуру команды, чтобы дальше мы бежали значительно быстрее.
Апи для ботов опять же развиваем. Безусловно оно не идеально и конечно есть планы его значительно улучшить. Тут, как говорится, следите за обновлениями. Многие клиенты им активно пользуются и свою функцию оно точно выполняет. Нарекания к нему в основном в контексте увеличение функциональности, знаем и делаем.
По поводу отсутствия уведомлений в винде странно, возможно какой-то баг или на уровне системы отключены уведомления, так как это точно работает даже когда "приложение закрыто и значок скрыт под стрелочкой". С уведомлениями в тредах действительно есть неудобство, но о тредах я писал выше уже.
Допускаю, что какие-то команды в VK могут и не использовать Тимс, не смотря на то, что он является официальным мессенджером для корпоративных коммуникаций компании. DAU чуть меньше, чем численность штата всего VK. Каждую минуту отправляется 1-1,5 тыс сообщений. Так же у нас вокруг Тимса и ботов построено много автоматизации, от заведения заявок до регулирования освещения на рабочем месте. Так что тезис, что в VK не используют Тимс не совсем корректен.
Ну и самое главное, мы любим мессенджер, вкладываемся в него, меняем его как технически, так и функционально. Ежедневно получаем предложения по его развитию и действительно слышим пользователей, да, в чём-то нужно банально время, привет "закон Брукса". Ну и по чесноку, сказать, что пользоваться им больно у меня язык точно не повернётся.
Valenti_na
15.04.2024 09:30Отвечу вам на комментарии:
В сентябре 2019 года корпорация Mail.ru (VK) запустила корпоративный мессенджер MyTeam как часть платформы Mail.ru для бизнеса. В 2021 году, в рамках ребрендинга компании Mail.ru в VK Group, корпоративный мессенджер получил новое название — VK Teams. - таким образом за 5 (а то и более) лет вы не сделали качественный и стабильный продукт? Сколько еще времени вам необходимо на приведение его в чувства?
-
Так раз пользователи привыкли к лучшему может нужно делать срзу Х О Р О Ш О? Почему нельзя брать лучшие "фишки" от конкурентов, а не худшие? (риторический вопрос).
Если сравнивать, например со Slack, то действительно треды реализованы иначе и, пожалуй, действительно мы не уделяем им сегодня столько времи, сколько хотелось бы, но это прежде всего связано с тем, что корпоративные заказчики видят другой функционал куда более приоритетным. - В своей работе я и мои коллеги часто ведем диалог в треде. Т.е. если задала вопрос в чате и начался тред я не узнаю о нем потому что пушей нет, уведомлений нет (пока меня не тегнут). Тегирование оппонента при каждом ответе - супер ужасная затея!
Тут же вы привели Slack - в нем есть тоже ряд спорных моментов, но часть функционала в отличии от VK Teams более удобная.
а) Если у меня есть папка "Отдел финансов" с чатами финансов, а другие чаты не распределены. Находясь в этой папке я не вижу общей картины. Сообщения от генерального директора не менее важны, но находясь в папке я просто этого не замечу. Красный круглик где-то в левой верхней части приложения обычно не попадает в поле зрения и не акцентирует на этом внимания. б) тут вы правы, однако, используя версию 24.2 на Windiws и версию 24.2.0 на ios - список закрепленных чатов не синхронизуется между ними в) а тут неправы вы, только что перепроверила: я создатель чата, нажимаю на него правой кнопкой в общем списке и пункта с архивацией нет. Переходя в папку где есть этот чат проделываю аналогичные действия - пункт появляется. Странное поведение не так ли? Один и тот же чат в разных "папках" ведет себя по разному (вы попробуйте) (в общей свалке чат закреплен, в папе нет - воспроизведите, у вас получится?)
Зато из больших обновлений - появление оргструктуры в On-premises версии, значительное улучшение ВКС во всех инсталяциях и ряд других функций. - тут сложно что-то сказать, так как не используем сие нововведение.
В мессенджере появились:
*папки - о них отписала выше
* закрепы - не синхранизуются, нельзя менять положения закрепленных чатов (если только переоткреплять и в нужном порядке закреплять, что не есть удобно)
* архивы - тоже отписала выше относительно добавления в них
* отложенные сообщения - в своей работе не использую данный функционал, могу лишь сказать, что это сомнительная функция и можно было потратить ресурсы на что-то более стоящее (но опять же спорный момент).Спасибо, тут будем следить за развитием. Но знаете камень подпирающий дверь тоже выполняет функции, но лучше когда дверь работает исправно.
-
Ваше приложение просто не попадает в список "Уведомления и действия" в разделе "Пуск" - "Параметры" - "Уведомления и действия" (возможно из-за этого). Первое мое предположение было что политики на рабочем устройстве могли что-то "сломать", но проверим на домашнем поняла, что нельзя сломать то, что не работает. (приложу скриншот раздела про который была речь тут, по понятным причинам наполнение показать не могу, но можете проверить у себя)
Спасибо, что пролили тут лучик света.
Ну и критикуешь-предлагай! К сожалению, на текущий момент только я лично оставила пару десятков запросов с багами и доработками. Описав все с реверансами, но меня активно просили уточнить то, что уже было написано по тексту, что-то просто передали и далее без какого-то информирования (что ждать, кого ждать, сколько ждать). Ну и ряд стандартных отписок "Спасибо что сказали ваше мнение важно ждите когда что-то сделаем".
На текущий момент, мое оценочное суждение относительно продукта: VK Teams достаточно сырой продукт, называть его "суперприложение для совместной работы сотрудников с любого устройства" - нельзя! Клиентоориентированность и профессионализм работников службы поддержки оставляет желать лучшего. Работа Продакт-менеджеров весьма сомнительна. Но это лишь мое мнение, основанное на личном использовании и обсуждении с коллегами.
Спасибо за внимание, возможно мои комментарии дадут вам почву для размышления.
В случае необходимости моя личка всегда открыта для обсуждения и конструктивной критике.Expr0mt Автор
15.04.2024 09:30Пожалуй ни с того начал, прежде всего спасибо за отзыв, это действительно важно.
Мы смотрим на конкурентов, конечно. Про треды повторюсь, что сами понимаем, что они далеко не идеальны, их действительно надо развивать.
Закрепы начнут синхронизироваться с 24.3.
С архивами специально проверял и на компе и на телефоне на 24.2, прежде чем написать. Везде есть прям под пунктом добавить в папку, но я услышал, даже любопытно.
По отложенным сообщения, судя по отзывам, очень востребованная функция оказалась, прежде всего когда хотят коллеге что-то вечером написать так, чтобы с утра к нему пришло сообщение.
Тосты прилетают, но в панель уведомлений на винде действительно не выводятся. Тут согласен, на винде когда-то очень плохо работали системные уведомления, мы делали свои, сейчас есть задача в бэклоге полноценно поддержать системные.
По работе тех поддержки услышал, передам коллегам. Знаю, что они активно вкладываются сейчас и в написание документации, и в различные обучающие программы, прежде всего чтобы в эксплуатации компаний клиентов сформировать нужные компетенции.
Valenti_na
15.04.2024 09:30На вашем скрине я полагаю речь про архив. Но группа "Тест" не закреплена.
Вот мой пример:
Как видно на скриншоте есть кнопка "Открепить" = чат закреплен и нет сообщения "Поместить в архив" (предвещая вопрос версия у меня 24.2). Т.е. я должна открепить чат и потом его в недрах всего искать его чтоб заархивировать.
Обсудив данный пост и наши комментарии с коллегами за обедом, они также накинули ряд проблем VK Teams. Постараюсь чуть тезисно:
1. Если написать пост с использованием форматирования (отступы/жирный текст/курсив/ ссылки) все будет ок, но в момент отправки все слетит. Если его отредактировать, то зайдя в обсуждения к этому тексту и прокрутив до первого сообщения (оно же текст поста) увидишь вариант который был со слетевшим форматированием
2. Предположим, я отправила кому-то в личку не то сообщение, если этот кто-то форварднет его третьему, а я после этого удалю сообщение из лички со вторым, то форварднутое сообщение останется и его можно будет спокойно читать.И это малая часть багов/ошибок и прочего, с чем мы встречаемся при использовании этого божественного мессенджера.
Вероятно, вы не ответите, но возможно же улучшить процесс разработки, приоритизировать список фичей для реализации, выстроить грамотную (тут я говорю не про умение писать правильно, но и это тоже, а про правильный подход к людям, умение считывать настрой обратившегося и желание помочь и предоставить информацию), квалифицированную работу службы поддержки. Как мне кажется это базовое в работе с подобного рода продуктами.
Да пару слов о документации: вы выпускаете новости про обновления и описание изменений. Не всегда пользователи продукта имеют хорошее знание программы и могут сходу понять где что находится. Понятное дело что расписывать куда тыкать и переходить это слишком, но делать чуть более понятное описание было бы неплохо. (Например: история с папками, вы отписали, что они появились, но что вы их всунули в недра программы - нет. И не сразу понятно где и как их искать). Так сказать хочется не искать и догадываться "что сказал автор?", а просто использовать.
Возможно, и скорее всего, по мере использования программы найду или вспомню еще ряд проблем. И надеюсь, что со своей стороны ваша команда и компания прислушается и сделать хоть 10% от того что было отправлено в вашу поддержку.Expr0mt Автор
15.04.2024 09:30Для более понятного описания функционала коллеги выпускаю ролики, сейчас их не так легко найти, но в скором времени это будет значительно удобнее.
Например, про папки - https://biz.mail.ru/docs/on-premises/Teams/rp/rp/index.html#_16
Valenti_na
15.04.2024 09:30Смотрите, я в своих комментариях описываю большое количество замечаний. Но при ответе мне вы, вероятно, намеренно игнорируете и не отвечаете на очень важные. То что у вас что-то находится в недрах я поняла, поверьте, мне, как пользователю, что-то искать и разбираться в ваших документациях, я хочу чтобы программа была по умолчанию интуитивно понятна.
Читая нашу переписку коллеги накинули еще моментов:
Когда у сотрудника меняется имя или фамилия - заводить новый аккаунт в программе (теряя все переписки - ммм... "приятно"). Скорее всего на стороне админа можно менять руками отображаемое имя, но почту , на которую зарегистрирована учетка - нет отсюда проблемы. Ну и дополнительно, к уведомлениям, ставя реакцию (пул которых весьма кастрирован) к сообщениям нет нотификации о них. Тоже супер неудобно.
Вы уже ставили в пример Slack так почему вы не реализуете удобные функции как у него?! (Почему "Житель Убежища 4" взял от начальных программ все то что ужасно?А еще, возможно из-за того что у нас серверная версия, обновления этого "великолепного" мессенджера ручные. Программа не сообщает что пора обновляться и это нужно делать ручками :(
Expr0mt Автор
15.04.2024 09:30Так у вас нет же вопросов, есть комментарии, уверяю, мы их принимаем во внимание.
Подскажите, а на чем вы специализируетесь? Поясню, статья всё же техническая, прежде всего, а темы вы поднимаете и продуктовые, и по UI, и по документации, и по саппорту, и по эксплуатации. И часть моментов весьма дискуссионная, поэтому и хочется более профессионально подойти к теме, мы же на технической площадке общаемся, в конце концов.
Например, вопрос автоматического обновления, это скорее вопрос к эксплуатации внутри вашей компании или службе ИБ. Технически это возможно, но а почему у вас эта возможность закрыта мне тяжело прокомментировать)
Ну или по поводу того, почему нельзя просто взять и сделать как в Slack. Тут тоже не очень понятно как это комментировать. Если вы занимаетесь продуктовой разработкой, интересно было бы узнать, как у вас устроено выставление приоритетов и копирование удачных фич конкурентов. Я тут малость не на свою поляну захожу, но Slack не стал бы столько стоить, если бы его можно было за годик - другой или даже за 5 лет легко скопировать и обогнать. Да и нужно ли это?
Valenti_na
15.04.2024 09:30Относительно темы и комментариев: наткнувших на пост восхваляющий VK Teams и без доли стеснения называющий его "суперприложением для совместной работы сотрудников с любого устройства" посчитала нужным в комментариях для читателе осветить то, что опустили. Возможно техническая часть приложения и крутая, но на выходе пользователь получает (не устану повторять) очень сырой продукт. (Могу ошибаться, но мне кажется в текущей реализации даже нет и части моментов заложенных в MVP версию).
Говоря о комментариях ранее, вы отвечали на ряд описанных проблем, сообщали что у вас не воспроизвелось, но после моих уточнений упустили этот момент, а мне все же хотелось бы от вас подтверждения, что функции работают весьма странно и скорее всего не так, как ожидалось.Отвечая на ваш вопрос о специализации: можете считать, что и я продукт, и разработчик, и отдел поддержки, и UX/UI специалист, и инженер и QA специалист. Если у вас есть профессиональные вопросы - буду рада ответить на них, прокомментировать или даже дать рекомендации.
Отдельно, все же хочу поблагодарить вас за ответы (хоть они весьма не прозрачны и в части вы ловко уходили от конкретного ответа), но все же уделили время их написать :)\
UPD: Slack не стал бы столько стоить, если бы его можно было за годик - другой или даже за 5 лет легко скопировать и обогнать. Да и нужно ли это? - аналогичный вопрос, а нужно ли копировать другие мессенджеры и делать 1 в 1 фичи? (чтоб не быть голословной пример: папки - логика как в телеграме, ограничения по количеству - как в телеграме. Отличие только в том, что в телеграме ограничения можно чуть расширить с премиум подпиской).
Expr0mt Автор
15.04.2024 09:30Касательно поведения, когда чат закреплён и его нужно архивировать, коллеги подсказываю, что идеологически закрепы - это важные чаты и там кнопка архивировать специально скрыта, чтобы пользователь случайно не потерял его.
К сожалению, то что вы пытаетесь анонимизировать себя, не позволят обсудить что-либо профессионально, с точки зрения тех или иных дисциплин(
Valenti_na
15.04.2024 09:30Еще раз уточню относительно архива: Если чат в закрепе мне более не нужен (по каким-то причинам) его, на текущий момент, нужно открепить, потом отыскать в километре скроллов и архивировать. Все это я могу назвать только жутким рукоблудством от которого можно спокойно избавиться - не скрывать функцию для закрепленных чатов.
Относительно вашего комментария об анонимности - я дала вам вполне честный ответ. На своей должности я совмещаю функции всех этих направлений и вполне могу ответить на вопросы. Или какой ответ вы ожидали получить? Узнать мои ФИО?
satas
15.04.2024 09:30Тоже вынужденно пересел на вктимс с другого известного мессерджера, больше года назад. Поначалу было очень грустно. В тот момент в "Обсуждениях" вообще не выводились все треды, в которых участвуешь. Пропустил что-то и все, обсуждение уже не найти. Но ок, в конце концов исправили.
Со временем просто привык к отсутствию тредов в личке, рассиннхрону пушей с десктоп версией (линукс), дичайшим тормозам в звонках (благо есть гугл мит).
Особенно "радует" висящий последние пол года меншон в меню Обсуждения (на всех устройствах). Который никак нельзя убрать (масса коллег с такой же проблемой).
Резюме: есть куда расти. "сотни команд и миллионы людей" конечно пользуются, но мечтают о лучшем.Expr0mt Автор
15.04.2024 09:30По поводу меншона в меню, это старая бага, мы её осенью поправили ещё, видимо у вас старая версия.
Звонки за прошлый год сделали большой рывок вперёд, добавив возможность проводить конференции на 300 человек, модерацию, запись звонка, чаты, работу при условии плохой связи, да и вообще полностью переделали интерфейс. Стабильность зачастую упирается в эксплуатацию и тут мы сейчас делаем этот процесс более прозрачным, но и нам есть куда расти, последние релизы очень активно повышаем именно качество работы звонков и будем это продолжать.
Ну а пуши, это вообще увлекательная тема, возможно на отдельную статью, т.к. самым крупным мессенджерам при работе на iOS/Android позволено то, что не позволено другим) Но тем не менее, пользователей это не должно беспокоить, поэтому принимается, тут не всё идеально, будем улучшать.
satas
15.04.2024 09:30Спасибо, хотя обновления это отдельная история :)
Expr0mt Автор
15.04.2024 09:30+1Есть такое, но в ближайших релизах процедура обновления значительно упростится.
Хотя на нашей практике, когда речь идёт про он-прем, то тут очень много различий между клиентами, как они эксплуатируют свою инфраструктуру, пользуются ли они гитопс практиками или им нужен UI инсталлятор, как выстроена работа ИБ и т.д. В результате, то что у одних может занимать пол дня, у других - недели.
kozlov_de
1й слайд – единая БД с шардированием
2й слайд – MSA (микросервисы для чатов) без шардирования, облако, БД содержит только данные своего экземпляра микросервиса. На схеме бы надо указать что Сервис А и Сервис Б это не разные типы а разные экземпляры одного типа сервиса. И MSA ничего не говорит должны они обращаться к единой БД или по экземпляру БД на экземпляр сервиса.
3й слайд – связи между сервисами через оркестратор типа service discovery (очевидно, уже разнотипные сервисы, т. к. между чатами связи не надо и их не было бы на схеме)
4й слайд – каждая БД имеет slave реплику (горячий резерв без нагрузки) «ячейку». Зеркало занимает место, зато можем клонировать только маленькую базу с данными по 2-3 чатам например. Пожалуй, это удобней чем использовать несколько мастер баз, которые синхронизируются каждый с каждым сложным образом. Также это удобно для переезда на другую ноду.
В общем, прикольно. Только неясно что делать когда создается новый экземпляр сервиса или наоборот - экземпляр отключают. Как данные его БД будут доступны? Миграция какая-то?
Напоминает RAID 01 – объединение зеркалированных данных.
5, 6 слайды – непонятно, что такое superapp и core layer
Корректное выстраивание доменов обычно делают сразу поскольку это влияет на корректность разрезания на микросервисы
Выстраивание взаимодействия между командами «на техническом уровне через API, шины и другие компоненты» в MSA должно быть жестко ограничено и редко меняться. Опять же странно, что только на 2м этапе. Видимо, на 1м только один микросервис (он же монолит), что позволяло об этом не думать.