Подтверждаю, что у нас тоже есть от бизнеса определенный интерес после реализации. Сейчас будем пробовать реализовывать некий проект с ботом и продвижением подбора персонала.
Схоже также делали эксперимент заведения задач в таск-трекер по команде из чатиков (правда пока не могу сказать, что это популярно).
А вот справки и прочее в бот пока нести не планируем, у нас это есть в корп. мобильном приложении, тут дублирование и еще же не стоит забывать наших друзей из ИБ с которыми мы всегда все согласовываем)
Немного не понял, как имея только user id - определить, что это аккаунт конкретного сотрудника моей компании? Суть ведь пускать в чат/канал - только действующих сотрудников, для этого и запрашиваем мобильный номер аккаунта с которого он пишет (здесь тоже делали проверку, что бы не подставляли чужие номера), а далее по корп базе сверяем, числится он у нас или нет.
Если номер телефона владелец аккаунта прячет (что верно для большинства) - то его без запроса не вытащить.
Добрый день! Как вы верно заметили в уточняющем вопросе, объемы датасетов весьма разные и уровень агрегации также бывает разный, разработчик может вынести большую часть рассчетных показателей на уровень бд и затягивать в FINE BI уже максимально рассчитанные и агрегированные, данные сократив количество рассчетов на лету и сами объемы.
Соотношение SPIDER\DIRECT 90 к 10 в пользу Spider
Для Direct используем Clickhouse
Пример Spider по объему занимаемого места. Название и путь таблиц вынужден закрасить
Добрый день! Наверное, сложно привести что – то именно из продуктовой практики, так как по большей части мы, как команда, сопровождаем и развиваем саму платформу для наших коллеги использующих ее для Self-Service аналитики, хотя периодически мы также создаем отчетность для коллег из функций где SS – не взлетел по каким-либо причинам.
Что можно вспомнить с ходу – это выводы следующие из показателей посещаемости объектов. Нам известны прецеденты внутри компании, когда владелец данных/дашборда, контролировал посещений дашборда с метриками по ключевому проекту, на уровне директоров регионов и макрорегионов, с последующей эскалации команде проекта и ТОП-менеджерам в случае неудовлетворительных показателей. Также владельцы данных использует информацию по пользователям имеющих доступ для информирования в случае доработки дашборда (информирует о внесенных изменениях, поясняет методику расчёта нового или измененного KPI и другое)
Также приведу примеры, что мы смотрим как команда сопровождающая платформу:
Показатели MAU/DAU. Оцениваем востребованность платформы. На текущий момент динамика стабильно-положительная, в востребованности нет сомнений, показатели давно обогнали соответствующие показатели Tableau.
Статус миграции отчетности с других платформ (На вопрос “Как?” сразу отвечу, без ручного труда тут не обходится – отчеты сильно перерабатываются при миграции)
Так как большая часть мигрированной отчетности SS – то и мигрировали ее на новую платформу представители бизнес – подразделений. C нашей стороны поддержка, консультация, мониторинг и эскалация в случает выявления рисков, на уровень комитета по данным(вспомогательный орган управления и принятие решения по вопросам управления данным)
Контроль уволенных пользователей и передача их контента ответственным лицам
Для планирования расширения мощностей и ресурсов. А также оптимизации имеющихся, к примеру, не востребованность ряда объектов позволяет снять с расписания обновления датасет, а возможно и удалить его полностью освободив место на быстрых SSD, которые использует FINE BI
Контроль обновлений по времени. Выявления часов максимальной нагрузки, оценка и анализ возможности оптимизации тасков в ЧНН или переноса их на часы с меньшей нагрузкой на систему
Категоризация отчетности – в соответствии с внутренним процессом, который категорирует отчетность производим контроль и пересмотр и пересмотр
Подтверждаю, что у нас тоже есть от бизнеса определенный интерес после реализации. Сейчас будем пробовать реализовывать некий проект с ботом и продвижением подбора персонала.
Схоже также делали эксперимент заведения задач в таск-трекер по команде из чатиков (правда пока не могу сказать, что это популярно).
А вот справки и прочее в бот пока нести не планируем, у нас это есть в корп. мобильном приложении, тут дублирование и еще же не стоит забывать наших друзей из ИБ с которыми мы всегда все согласовываем)
Немного не понял, как имея только user id - определить, что это аккаунт конкретного сотрудника моей компании? Суть ведь пускать в чат/канал - только действующих сотрудников, для этого и запрашиваем мобильный номер аккаунта с которого он пишет (здесь тоже делали проверку, что бы не подставляли чужие номера), а далее по корп базе сверяем, числится он у нас или нет.
Если номер телефона владелец аккаунта прячет (что верно для большинства) - то его без запроса не вытащить.
Продолжение наших изысканий в следующей статье
FineBI-g brother is still watching: как мы усовершенствовали мониторинг
https://habr.com/ru/companies/tele2/articles/778520/
Добрый день! Как вы верно заметили в уточняющем вопросе, объемы датасетов весьма разные и уровень агрегации также бывает разный, разработчик может вынести большую часть рассчетных показателей на уровень бд и затягивать в FINE BI уже максимально рассчитанные и агрегированные, данные сократив количество рассчетов на лету и сами объемы.
Соотношение SPIDER\DIRECT 90 к 10 в пользу Spider
Для Direct используем Clickhouse
Пример Spider по объему занимаемого места. Название и путь таблиц вынужден закрасить
Табличка на 84 гига в топе на 441,366,877
Добрый день! Наверное, сложно привести что – то именно из продуктовой практики, так как по большей части мы, как команда, сопровождаем и развиваем саму платформу для наших коллеги использующих ее для Self-Service аналитики, хотя периодически мы также создаем отчетность для коллег из функций где SS – не взлетел по каким-либо причинам.
Что можно вспомнить с ходу – это выводы следующие из показателей посещаемости объектов. Нам известны прецеденты внутри компании, когда владелец данных/дашборда, контролировал посещений дашборда с метриками по ключевому проекту, на уровне директоров регионов и макрорегионов, с последующей эскалации команде проекта и ТОП-менеджерам в случае неудовлетворительных показателей. Также владельцы данных использует информацию по пользователям имеющих доступ для информирования в случае доработки дашборда (информирует о внесенных изменениях, поясняет методику расчёта нового или измененного KPI и другое)
Также приведу примеры, что мы смотрим как команда сопровождающая платформу:
Показатели MAU/DAU. Оцениваем востребованность платформы. На текущий момент динамика стабильно-положительная, в востребованности нет сомнений, показатели давно обогнали соответствующие показатели Tableau.
Статус миграции отчетности с других платформ (На вопрос “Как?” сразу отвечу, без ручного труда тут не обходится – отчеты сильно перерабатываются при миграции)
Так как большая часть мигрированной отчетности SS – то и мигрировали ее на новую платформу представители бизнес – подразделений. C нашей стороны поддержка, консультация, мониторинг и эскалация в случает выявления рисков, на уровень комитета по данным (вспомогательный орган управления и принятие решения по вопросам управления данным)
Контроль уволенных пользователей и передача их контента ответственным лицам
Для планирования расширения мощностей и ресурсов. А также оптимизации имеющихся, к примеру, не востребованность ряда объектов позволяет снять с расписания обновления датасет, а возможно и удалить его полностью освободив место на быстрых SSD, которые использует FINE BI
Контроль обновлений по времени. Выявления часов максимальной нагрузки, оценка и анализ возможности оптимизации тасков в ЧНН или переноса их на часы с меньшей нагрузкой на систему
Категоризация отчетности – в соответствии с внутренним процессом, который категорирует отчетность производим контроль и пересмотр и пересмотр
И другое