Планирование реализации Power BI: администрирование клиента

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется интерфейсу Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

В этой статье приводятся основные рекомендации по администрированию клиента Fabric. Эта статья предназначена для следующих целей:

• Администраторы Структуры: администраторы, ответственные за надзор за Структурой в организации.
• ИТ-администраторы и системные администраторы: другие администраторы, которые сотрудничают с администраторами Fabric для контроля и интеграции систем в организации.
• Центр превосходства (COE) и команды бизнес-аналитики: команды, ответственные за надзор за Power BI и поддержку пользователей Power BI в организации. Эти команды принимаются ключевые решения и сотрудничают с администраторами Fabric.

Управление служба Power BI является одним из ключевых аспектов системного надзора. Дополнительные сведения см. в разделе "Системный надзор". Обычные действия, связанные с системным надзором, обычно называются системным администрированием. Действия администрирования системы критически важны для обеспечения постоянного взаимодействия потребителей содержимого и создателей содержимого с Power BI.

Как описано в статье о уровнях зрелости внедрения Fabric, внедрение организации относится к эффективности управления и управления данными для поддержки и включения корпоративной бизнес-аналитики и управляемой самостоятельной бизнес-аналитики. Таким образом, администраторы, которые управляют аналитикой и платформами бизнес-аналитики, могут иметь большое и прямое влияние на успех ваших усилий по внедрению аналитики.

Примечание.

Администрирование емкости Fabric (или емкости Premium) и управление служба Power BI являются разными понятиями. Хотя большинство организаций имеют только один клиент Power BI, организация может подготовить несколько емкостей для разных рабочих нагрузок или бизнес-единиц.

Внимание

Иногда эта статья относится к Power BI Premium или ее подпискам на емкость (SKU). Обратите внимание, что корпорация Майкрософт в настоящее время объединяет варианты покупки и отставает от номера SKU емкости Power BI Premium. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на емкость Fabric (SKU) вместо этого.

Дополнительные сведения см. в разделе "Важные обновления", поступающие в лицензирование Power BI Premium и вопросы и ответы по Power BI Premium.

Определение области обязанностей

Нет единого определения роли администратора Fabric, что означает, что роль и рутинные обязанности администратора Fabric могут отличаться между различными организациями. Что не должно меняться, заключается в том, что роль может (и должна) развиваться со временем, когда приоритеты организации и цели изменяются.

С стратегической точки зрения администратор Структуры должен сосредоточиться на:

• Управление: принятие рекомендаций и политик управления для поддержки корпоративной бизнес-аналитики и управляемой самостоятельной бизнес-аналитики.
• Расширение прав и возможностей пользователей: упрощение и поддержка внутренних процессов и систем, которые позволяют внутреннему сообществу пользователей в максимальной степени соответствовать нормативным требованиям и требованиям организации.
• Внедрение: предоставление более широкого внедрения структуры с эффективными методами управления и управления данными.

Попытка сбалансировать управление, расширение прав и возможностей пользователей и цели внедрения по сути приводит к конкурирующим приоритетам. В идеале это приводит к продуктивным дебатам о приоритетах. Уточняя и сообщая ожидания для различных ролей и обязанностей, можно избежать неприемлемых уровней трений и конфликтов.

Рассмотрим следующие три примера администраторов Fabric.

• Высокий акцент на включении пользователей: Райли является администратором Fabric, который работает в крупной глобальной организации, которая сделала значительные инвестиции в управляемый самообслуживание БИЗНЕС. Чтобы включить возможности самообслуживания бизнес-аналитики для пользователей в организации, Райли тратит много времени на согласование решений и действий с Центром знаний (COE) и другими администраторами. При необходимости Райли выполняет шаги по поддержке существующих решений бизнес-аналитики.
• Высокий акцент на управление и соответствие требованиям: Паркер является администратором Fabric, который работает в строго регулируемых организациях. В этой организации большинство разработчиков бизнес-аналитики обрабатываются разработчиками бизнес-аналитики в централизованной группе бизнес-аналитики . Административные обязанности Паркера в основном сосредоточены на таких областях, как аудит, защита информации и безопасность.
• Высокий уровень участия в создании контента: Морган является администратором Fabric, который работает для небольшой организации, которая только что начинает создавать свою культуру данных. В настоящее время организация имеет только несколько создателей контента. Помимо обязанностей по надзору за системой, Морган является разработчиком бизнес-аналитики, который регулярно создает и публикует содержимое. Иногда Морган участвует в проекте совместного развития для наставничества коллегу, который помогает расти опыт бизнес-аналитики в организации.

Контрольный список . При планировании области обязанностей ключевые решения и действия включают:

• Определите стратегический фокус. Определите, какой стратегический фокус должен быть у администраторов Fabric. Получите ясность в отношении целей и приоритетов, которые следует использовать при принятии решений (и компромиссов).
• Определите определенные роли и обязанности. Определите, какие ожидания ожидают администраторы Fabric. Четко документируйте свои роли и обязанности, а также обновите описания заданий с помощью кадров при необходимости.

Назначение администраторов

Действия администратора Fabric оказывают значительное влияние на взаимодействие с пользователем, усилия по культуре данных , усилия по управлению , которые принадлежат содержимому и управляют содержимым, а также на усилия по внедрению организации. Поэтому важно, чтобы вы назначили нужных людей для ролей администратора.

Ниже приведены некоторые ключевые моменты, которые следует учитывать при выборе администраторов.

• Оставаться осознанным высоко привилегированным характером роли. Роль администратора — это роль с высоким уровнем привилегий, так как она авторизована для управления широким спектром параметров клиента, доступом к рабочей области, личным доступом к рабочей области и может просматривать все метаданные клиента. Дополнительные сведения см. в разделе администрирования Power BI.
• Тщательно выберите, кто хорошо подходит для того, чтобы быть администратором. Администратор часто должен сотрудничать с пользователями и COE. По этой причине они должны понимать понятия бизнес-аналитики и то, что пользователи хотят достичь. Кто-то, кто имеет чрезмерную личность или который имеет тенденцию строго ограничить то, что пользователи могут делать, вероятно, не хорошо подходит для управления платформой самообслуживания бизнес-аналитики.
• Выберите от 2 до 4 администраторов. Так как это роль с высоким уровнем привилегий, назначьте только нескольких администраторов. Настроите правильный баланс: слишком много администраторов повышает риск неутвержденных изменений, в то время как слишком мало администраторов повышает риск того, что система не будет достаточно поддерживаема.
• Разрешить случайным администраторам. Если у вас есть пользователи, которые иногда нуждаются в правах администратора Fabric, рассмотрите возможность реализации управление привилегированными пользователями (PIM). PIM позволяет назначать разрешения роли JIT, срок действия которого истекает через несколько часов. Этот процесс позволяет сбалансировать риск (наличие слишком большого количества администраторов полного времени) и удобство использования (позволяя выполнять ход выполнения). Это особенно верно в крупных децентрализованных организациях. При использовании PIM делегирование роли администратора регистрируется и может дополнительно включать рабочий процесс утверждения для предоставления прав.
• Сделайте администрирование Fabric приоритетом. Часто администрирование платформы бизнес-аналитики является лишь одной из многих обязанностей. Рассмотрим, как вы гарантируете, что пользователи хорошо поддерживаются, и ваша система достаточно управляема.
• Регулярно просматривайте, кто назначен всем связанным ролям. Существует три роли, которым разрешено управлять служба Power BI: администратор Структуры и администратор Power Platform. Важно регулярно проверять членство этих ролей.

Дополнительные сведения см. в О ролях администратора в центре администрирования Microsoft 365.

Контрольный список . При назначении администраторов ключевые решения и действия включают:

• Определите текущих администраторов Fabric: проверьте, кто в настоящее время назначен роли администратора Fabric. Кроме того, в этом обзоре рассматриваются роли администратора Power Platform и глобального администратора.
• Назначение администраторов Fabric: чтобы снизить риск, назначьте 2–4 человека роли администратора Fabric. Если в настоящее время назначено более четырех человек, уменьшите число пользователей, назначенных роли администратора Fabric.
• Используйте PIM для случайных администраторов. Определите, есть ли у вас пользователи, которые законно, но иногда нуждаются в правах администратора Fabric. Реализуйте PIM, чтобы назначить разрешения роли JIT, срок действия которого истекает через несколько часов. Документируйте и сообщайте, как работает процесс, который может включать рабочий процесс утверждения.
• Назначение резервных копий и перекрестное обучение. Проверьте состояние перекрестной подготовки и документации, которая находится на месте для обработки обязанностей администрирования Fabric. Убедитесь, что пользователь резервного копирования обучен таким образом, чтобы приоритетные потребности пользователей могли быть выполнены своевременно и согласованно.
• Регулярно проверяйте администраторов: проверьте, кто назначен роли администратора Fabric регулярно.

Совместная работа с другими администраторами

Хотя администратор Fabric является ролью с высоким уровнем привилегий, она ограничена управлением Fabric. Поэтому иногда вам потребуется сотрудничать с другими администраторами.

Ниже приведены некоторые распространенные причины, по которым администратор Fabric сотрудничает с другими системными администраторами.

• Настройка и установка устройств. Возможно, вам потребуется работать с ИТ- отделом, группой поддержки инфраструктуры или группой поддержки компьютеров для установки, обновления или управления устройствами пользователей.
• Подписки и приобретение лицензий: роль администратора выставления счетов в Microsoft 365 необходима для управления подписками и покупками лицензий. Администратор выставления счетов также может отвечать за анализ затрат и управление ими. Дополнительные сведения о централизованных и децентрализованных (самообслуживании) способах управления лицензиями см. в разделе "Лицензии пользователей".
• Назначение лицензий и управление пользователями. Роль администратора лицензий в Microsoft 365 необходима для назначения лицензий (приобретенных) определенным пользователям. Роль администратора пользователя необходима для управления свойствами пользователя. При планировании реализации автоматизации с учетом свойств пользователей (например, автоматическое назначение лицензий или автоматическое назначение групп) полезно работать с администратором пользователей. Дополнительные сведения см. в разделе Часто используемые роли Центра администрирования Microsoft 365.
• Администраторы Microsoft Entra. Существуют различные причины , по которым необходимо работать с администраторами Microsoft Entra. Часто причины включают необходимость настройки или управления пользователями, группами и субъектами-службами. Дополнительные сведения см. в разделе "Планирование безопасности на уровне клиента".
• Доступ к исходным данным. Возможно, вам придется работать с системным администратором или администратором базы данных, чтобы получить доступ к данным от имени создателей контента. Иногда может потребоваться запросить доступ от имени потребителей контента, когда семантические модели обеспечивают безопасность данных на основе удостоверения потребителей контента.
• Защита от потери данных и классификация данных. Возможно, вам потребуется сотрудничать с администратором Microsoft Purview для управления и защиты информации.
• Интеграция Teams. При интеграции Power BI с Microsoft Teams может потребоваться совместная работа с администратором Teams.
• Интеграция OneDrive и SharePoint. При интеграции Power BI с OneDrive или SharePoint может потребоваться совместная работа с другими администраторами.
• Администрирование рабочей области: может потребоваться совместная работа с администратором рабочей области Fabric для планирования, упорядочивания или защиты содержимого в определенных рабочих областях.
• Управление жизненным циклом. При развертывании и управлении изменениями содержимого может потребоваться совместная работа с администратором конвейера развертывания или администратором Azure DevOps.
• Управление емкостью premium: при управлении емкостью Premium может потребоваться совместная работа с администратором емкости Premium.
• Управление шлюзом данных. Для управления локальным шлюзом может потребоваться совместная работа с администратором шлюза. Дополнительные сведения см. в разделе "Управление шлюзами".
• Администрирование Power Platform: может потребоваться интегрировать решения между Power BI и другими приложениями Power Platform (например, Power Automate или Power Apps).
• Администрирование Azure. Возможно, вам потребуется работать с администратором Azure, чтобы настроить, получить доступ и защитить другие службы Azure, которые требуется интегрировать с Power BI.
• Администрирование безопасности и аудит: у вашей организации могут быть определенные требования к соответствию, безопасности или конфиденциальности. В этом случае может потребоваться сотрудничать с командой безопасности для выявления и устранения рисков.
• Сеть. При подключении к разным источникам данных и системам может потребоваться работать с администраторами сети по соображениям производительности и безопасности.
• Администрирование мобильных устройств. Для управления политиками и безопасностью мобильных устройств может потребоваться совместная работа с администратором Intune.

Внимание

Администратор Структуры не должен принимать решения или принимать меры (например, изменение параметров клиента) самостоятельно. Все ключевые решения следует обсуждать, планировать и документировать. Помимо совместной работы с другими администраторами, не забудьте полностью включить COE и рабочую группу стратегии бизнес-аналитики. Это также может быть уместно для привлечения вашего исполнительного спонсора к стратегическим решениям.

Контрольный список . При совместной работе с другими администраторами ключевые решения и действия включают:

• Определите, кто будет управлять установкой и установкой устройств. Убедитесь, что вы знаете, кто управляет устройствами для вашей организации. Ознакомьтесь со своими процессами и требованиями. Подготовьтесь к работе с ними по мере необходимости.
• Определите, кто будет управлять подписками и лицензиями: убедитесь, что вы знаете, кто управляет подписками и лицензиями для вашей организации. Ознакомьтесь со своими процессами и требованиями. Подготовьтесь к работе с ними по мере необходимости.
• Определите, кто будет назначать лицензии и управлять пользователями, группами и субъектами-службами. Убедитесь, что вы знаете, кто управляет пользователями, группами и субъектами-службами для вашей организации. Ознакомьтесь со своими процессами и требованиями. Подготовьтесь к работе с ними по мере необходимости.
• Определите всех других администраторов, которые следует проконсультироваться: при работе с процессом планирования реализации определите других соответствующих администраторов. Пригласите их на соответствующие встречи и включайте их в соответствующие процессы принятия решений. При необходимости обновите документацию и процессы.

Управление служба Power BI

Управление служба Power BI и управление ими является одной из ключевых обязанностей администратора Fabric. В этом разделе описывается, как управлять множеством распространенных параметров и функций на портале администрирования Fabric и управлять ими.

• Параметры клиента
• Домены
• Рабочие области
• Коды внедрения
• Визуальные элементы организации
• Подключения Azure

Управление параметрами клиента

Параметры клиента — это основной способ управления включенными функциями и возможностями Power BI, для которых пользователи в вашей организации. Управление параметрами клиента является одной из наиболее важных обязанностей администратора Fabric.

Так как создатели контента и потребители содержимого могут легко узнать о доступных функциях и возможностях в Power BI (из документации), это может привести к разочарованию, когда они не могут сделать что-то, что они ожидают. Это также может привести к неудовлетворенности пользователей и менее эффективному внедрению организации, внедрению пользователей и внедрению решений.

Ниже приведены некоторые распространенные вопросы, которые путают и разочарованы пользователями.

• Почему не удается создать рабочую область?
• Почему не удается экспортировать данные?
• Почему не работает пользовательский визуальный элемент?
• Почему я не могу сертифицировать семантику модели?
• Почему не удается назначить метку конфиденциальности?
• Почему я не могу отправить приложение определенным конечным пользователям?

Внимание

Каждый параметр клиента должен соответствовать рекомендациям и политикам управления в организации. Когда администратор Fabric решает самостоятельно включить или отключить параметры, обычно это четкий индикатор, который необходимо улучшить и уточнить процессы управления.

Оставшаяся часть этого раздела описывает следующий процесс для управления параметрами клиента.

1. Просмотр параметров клиента
2. Выбор параметров клиента
3. Обновление параметров клиента
4. Параметры клиента документа
5. Управление настройками клиента
6. Аудит параметров клиента

Шаг 1. Просмотр параметров клиента

Важно проверить каждый параметр клиента, чтобы четко понять текущее состояние клиента. Хотя вы должны просмотреть все параметры клиента, вы можете определить приоритеты определенных критических параметров, чтобы сначала проверить на основе оценки рисков.

Ниже приведены некоторые факторы, которые следует учитывать во время процесса проверки.

• Параметр. Включена или отключена ли конкретный параметр клиента?
• Разрешения. Применяется ли конкретный параметр клиента ко всей организации? Или доступно или запрещено для определенных групп безопасности?

Примечание.

Некоторые параметры клиента включены по умолчанию, а другие отключены по умолчанию.

Текущее состояние параметров клиента можно скомпилировать одним из двух способов.

• Просмотрите состояние параметра клиента на портале администрирования.
• Программное извлечение состояния параметров клиента с помощью REST API получения параметров клиента.

В следующей таблице показано, как записать текущее состояние параметров клиента.

Дата последней проверки	Параметр клиента	Текущее значение	Разрешенные группы безопасности	Группы безопасности не разрешены	Параметр клиента, делегированный другим администраторам
15 октября 2023 г.	Создание рабочих областей	Включена для определенных групп безопасности	Создатели рабочих областей Power BI, администраторы Power BI, coE Power BI, поддержка Power BI	Неприменимо	Неприменимо
15 октября 2023 г.	Экспорт в Excel	Включена для всей организации, кроме определенных групп безопасности	Н/П	Отдел продаж в Европе	Н/П
1 ноября 2023 г.	Использование семантических моделей в рабочих областях	Включена для всей организации	Неприменимо	Н/Д	Неприменимо
1 ноября 2023 г.	Сертификация	Включена для определенных групп безопасности	Службы сертификации Power BI	Н/П	Администраторы домена могут включить или отключить
5 ноября 2023 г.	Разрешить определенным пользователям включить внешний общий доступ к данным	Включена для определенных групп безопасности	Общий доступ к внешним данным Power BI	Неприменимо	Неприменимо

Дополнительные сведения о группах безопасности см. в статье "Планирование групп Power BI".

Дополнительные сведения о допустимых состояниях параметров клиента см. в разделе "Использование параметров клиента".

Внимание

Иногда, когда администратор отслеживает клиент, они обнаруживают ситуацию, которая не является идеальной. Например, они могут видеть слишком много экспортов данных в данных действия пользователя. В этом случае администратор может заманить отключение соответствующего параметра клиента. Однако прежде чем полностью отключить функцию, важно сначала понять, почему пользователи полагаются на определенные методы. Это связано с тем, что запрет функций может привести к разочарованию пользователей, которые могут соблазнить пользователей создавать обходные пути. Используйте вместо этого решение, возможно, потребуется изменить или, возможно, дополнительное обучение пользователей и обучение может снизить проблемы.

Шаг 2. Выбор параметров клиента

После просмотра текущих параметров клиента пришло время изучить процесс принятия решений. Для каждого параметра клиента используйте семинары для активного обсуждения и определения функций и возможностей, которые должны быть разрешены или запрещены, и для которых пользователи.

Помните, что каждый параметр клиента представляет решение по управлению. Таким образом, ожидается совместная работа с другими пользователями, чтобы прийти к правильному решению. В зависимости от ваших обстоятельств процесс принятия решений может включать совместную работу с COE, исполнительным спонсором, командой безопасности, командой бизнес-аналитики или другими (например, заинтересованными лицами или чемпионами).

Совет

Одна из самых больших проблем заключается в принятии решения о том, что делать, когда возникают несоответствия между существующим параметром клиента и вашими целями и целевыми решениями. Будьте готовы устранить эти конфликты при их обнаружении.

Ниже приведены некоторые факторы, которые следует учитывать во время процесса принятия решений.

• Какие решения по управлению уже существуют? По возможности обратитесь к существующим решениям, которые вы приняли. Всегда стремится быть последовательным и эффективным. Кроме того, необходимо учитывать внутренние или внешние требования к соответствию. При необходимости параметры клиента должны соответствовать более широким политикам управления. Например, может быть текущая политика управления, указывающая, когда, кто и как данные могут предоставляться за пределами организации.
• Кто принимает новые решения по управлению? Когда необходимо принять решение о настройке клиента, необходимо включить всех соответствующих сторон в беседу. Как правило, администраторы Структуры не в лучшем положении, чтобы принимать решения о параметрах клиента. Сведения о сборке рабочей группы и выполнении семинаров см . в статье о стратегическом планировании бизнес-аналитики.
• Временно ли решение? Иногда параметр клиента устанавливается только в течение короткого периода времени. Как правило, это делается, чтобы позволить coE, BI и ИТ-командам ознакомиться с новой функцией, прежде чем она будет выпущена более широко во всей организации. Таким образом, можно проверить соответствие рекомендациям по управлению, и сообщество пользователей будет хорошо поддерживаться.
• Будут ли разные бизнес-подразделения или команды обрабатываться по-разному? В крупных организациях один подход редко работает. Для удовлетворения потребностей и навыков разных команд иногда может потребоваться настроить параметры клиента по-разному для разных аудиторий. Всегда старайтесь позволить командам, способным работать с максимальной гибкостью, как это возможно, в рамках рекомендаций по управлению.
• Существует ли процесс утверждения? В зависимости от конкретной темы может потребоваться утверждение. Это особенно верно, если параметр клиента относится к безопасности или соответствию требованиям.
• Что такое расписание повторного рассмотрения каждого решения? Регулярно запланируйте проверку каждого решения о настройке клиента. Два раза в год является хорошим расписанием для этой цели.

В следующей таблице показано, как можно записать решения.

Дата принятия решения	Принятое решение	Участвующие в принятии решений	Решение, утвержденное	Затронутый параметр клиента	Ожидающее действие
15 октября 2023 г.	COE обучит утвержденных создателей контента по рекомендациям по созданию рабочих областей и управлению ими. Утвержденные создатели могут быть из любой бизнес-единицы.	COE и заинтересованные лица	Эллис Тернер (исполнительный спонсор) и Тейлор Филлипс (ведущий COE)	Создание рабочих областей	Просмотр существующих членов группы создателей рабочей области Power BI
15 октября 2023 г.	Экспорт в Excel будет разрешен. COE будет отслеживать действие в журнале действий и обращаться к пользователям, которые перепользовали его. Временное ограничение для группы продаж в Европе существует из-за проблемы, которая в настоящее время находится под следствием.	COE и безопасность	Эллис Тернер (исполнительный спонсор) и Джесси Ирвин (главный технический директор)	Экспорт в Excel	Дальнейшие действия по вопросу Европы в 60 дней
1 ноября 2023 г.	Настоятельно рекомендуется использовать общие семантические модели для поощрения повторного использования данных, минимизации и уменьшения дублирования данных.	КОУ	Эллис Тернер (исполнительный спонсор)	Использование семантических моделей в рабочих областях	Н/П
1 ноября 2023 г.	COE обучит утвержденных создателей контента в процессе и требованиях для сертификации отчетов и ресурсов данных. Утвержденные создатели могут быть из любой бизнес-единицы.	COE и заинтересованные лица	Эллис Тернер (исполнительный спонсор) и Тейлор Филлипс (ведущий COE)	Сертификация	Просмотрите существующие члены группы сертификации SMEs Power BI
5 ноября 2023 г.	Политика общего доступа к данным организации описывает, как данные могут использоваться за пределами организации. Все пользователи должны ежегодно проверять и признать эту политику. Обучение со стороны COE поможет пользователям соблюдать требования во время работы в Power BI.	COE, безопасность и соответствие требованиям	Джесси Ирвин (главный технический директор)	Разрешить определенным пользователям включить внешний общий доступ к данным	Просмотрите существующие члены группы общего доступа к данным Power BI

Рассмотрите возможность включения других контекстных сведений, объясняющих, почему было принято решение. Кроме того, включите ссылки на расположение существующих связанных документов или политик.

Примечание.

Примеры, представленные в таблице, намеренно демонстрируют, как сбалансировать возможности пользователей, соответствие и внутренние требования. Дополнительные сведения см. в разделе "Управление".

Шаг 3. Обновление параметров клиента

Теперь, когда доступны существующие параметры клиента и решения с целью, вы можете обновить параметры клиента.

Рекомендации во время процесса обновления включают:

• Кто будет обрабатывать обновление? Если у вас несколько администраторов Fabric, это идеально подходит для одного или двух администраторов Fabric в первую очередь за обновление параметров клиента. Цель заключается в том, чтобы процесс был согласованным, хорошо понятным и хорошо контролируемым.
• Какой процесс тестирования выполняется? В зависимости от параметра клиента могут возникнуть другие последствия при изменении. Проводите тестирование перед внесением широко распространенных изменений. Пример см. в разделе "Управление использованием семантических моделей в рабочих областях".
• Существует ли процесс управления изменениями? Рассмотрим, как избежать несоответствий между решениями, документацией и результирующей обновлениями. Обмен данными между командами является ключевым фактором успеха в управлении изменениями. В зависимости от требований аудита вы можете сохранить внутренний журнал изменений для отслеживания того, кто сделал изменения, когда и почему (записывать дополнительные сведения за пределами записанных в журнале действий).
• Как будет обрабатываться взаимодействие с пользователями? При внесении изменений, влияющих на то, что пользователи могут сделать, обязательно общаться с этим изменением. Всегда старайтесь избежать разочарования пользователей и ненужных запросов на поддержку.

Шаг 4. Параметры клиента документа

На этом этапе убедитесь, что у вас есть повторяющийся метод для документирования значений параметров клиента. Упрощенный пример см. в таблице на шаге 1 выше, которая посвящена просмотру параметров клиента.

Ниже приведены некоторые аспекты, которые следует учитывать для документации.

• Извлечение данных моментального снимка. При документе значений параметров клиента рекомендуется регулярно создавать новый моментальный снимок на определенный момент времени. Для этого создание моментального снимка один раз в неделю является хорошей частотой. Используйте REST API получения параметров клиента для автоматизации процесса.
• Предоставление администраторам доступа к данным моментального снимка: администраторам, COE и внутренним аудиторам должен быть доступ ко всем данным моментального снимка. Чтобы определить параметры клиента, которые изменились, сравните два моментальных снимка (например, на этой неделе по сравнению с прошлой неделей). Данные из журнала действий дополняют данные моментального снимка, чтобы обеспечить полное представление о том, что изменилось, когда и кем. Дополнительные сведения см. в разделе 6 ниже, в котором описано аудит параметров клиента.
• Укажите сводку по текущим параметрам пользователям: значения параметров клиента — это один из типов документации , которую можно сделать доступной для сообщества пользователей на централизованном портале. Это полезная ссылка для пользователя, который, например, не понимает, почему функция недоступна для них. Документация также может помочь пользователям узнать, какую группу безопасности запрашивать для присоединения, если они хотят использовать функцию. Чтобы уменьшить уровень усилий вручную, последние результаты моментального снимка из REST API можно распространить для пользователей в виде отчета Power BI. В зависимости от потребностей может потребоваться объединить моментальный снимок данных с другими данными, которые хранятся вручную (например, описание параметра клиента, обоснование параметра, ссылки на дополнительные сведения или ссылку на форму для запроса доступа).

Примечание.

Как описано ранее на шаге 2, вы также будете иметь документацию, связанную с процессом принятия решений. Как правило, этот тип документации доступен только для coE и администраторов (а не для всех пользователей Power BI). Упрощенный пример см. в шаге 2.

Шаг 5. Управление параметрами клиента

Параметры клиента требуют внимания на постоянной основе. Ниже приведены некоторые аспекты, которые следует учитывать.

• Новые параметры клиента: как узнать, когда доступен новый параметр клиента? Так как Fabric — это облачная служба, которая продолжает развиваться, вы можете ожидать, что новые параметры клиента будут регулярно представлены. Одним из способов узнать о новых параметрах клиента является просмотр сообщений , объявленных на верхней части страницы параметров клиента на портале администрирования. Другим способом является сравнение данных, извлеченных из текущего моментального снимка, с предыдущим моментальным снимком (описанным ранее на шаге 4).
• Изменения существующих параметров клиента. Как узнать, когда поведение существующего параметра клиента изменилось? Изменения параметров клиента обычно объявляются в блоге Power BI или блоге Fabric. Обязательно следуйте этим блогам, чтобы узнать о любых уведомлениях.
• Текущие запросы пользователей: как управлять запросами пользователей? Например, пользователь, который хочет сертифицировать содержимое, знает, как отправить запрос, чтобы стать членом определенной группы безопасности, которая позволяет ей. Это эффективный рабочий процесс, который можно сделать, публикуя документацию по параметрам клиента, чтобы пользователи ссылались (как описано на шаге 4 выше). Вы можете использовать форму для сбора этих типов запросов. Или вы можете перенаправить запросы через службу технической поддержки.
• Новые группы безопасности: если параметр клиента ограничен определенными группами безопасности, уже существует подходящая группа безопасности? Или необходимо создать новую группу безопасности? Как вы будете координировать получение новой группы безопасности, созданной при необходимости? Дополнительные сведения см. в статье "Стратегия использования групп".

Шаг 6. Аудит параметров клиента

Наконец, важно иметь процесс регулярного аудита параметров клиента. Ниже приведены некоторые действия, которые необходимо определить при аудите параметров клиента.

• Изменен параметр клиента: найдите измененные значения в журнале действий с помощью действия UpdatedAdminFeatureSwitch. Это действие указывает только на то, что что-то было обновлено (было ли оно включено или отключено, или были назначены разные группы безопасности). Чтобы понять, что изменилось, необходимо сравнить текущий моментальный снимок с предыдущим моментальным снимком (описано ранее на шаге 4).
• Добавлен новый параметр клиента: найдите сообщения на портале администрирования или сравните данные, извлеченные из текущего моментального снимка, с предыдущим моментальным снимком (описанным ранее на шаге 4).
• Членство в группе изменилось: в некоторых ситуациях может быть недостаточно, чтобы узнать, какая группа безопасности назначена. Возможно, потребуется определить членство в группе безопасности, которая может содержать отдельных пользователей и субъектов-служб. Данные членства в группах можно использовать с помощью Microsoft Graph. Дополнительные сведения см. в разделе "Пользователи и группы данных".

Кроме того, может потребоваться получать уведомления об оповещениях при обновлении параметра клиента. Вы можете использовать возможности оповещений журнала аудита из Microsoft 365 или Microsoft Defender для облака Приложения, чтобы получать уведомления об изменении параметра клиента и с помощью события журнала аудита UpdatedAdminFeatureSwitch. Дополнительные сведения о включении оповещений см. в разделе аудита на уровне клиента.

Контрольный список . При планировании параметров клиента и управлении ими к ключевым решениям и действиям относятся:

• Просмотрите все текущие параметры клиента: определите текущее состояние, просмотрите все параметры клиента. Определите, какие группы безопасности назначены каждому параметру.
• Определите существующие политики и решения: скомпилируйте существующие политики управления или предыдущие решения, чтобы они были легко доступны.
• Обсудите и решите: запланируйте семинары, чтобы рассмотреть и определить, что должно быть разрешено или запрещено, и для каких пользователей. Убедитесь, что все решения согласованы с целями культуры данных, рекомендациями по управлению и внутренними политиками. Обязательно включите всех соответствующих лиц и заинтересованных лиц для каждой темы. При необходимости получите дополнительное утверждение.
• Создайте расписание для повторного рассмотрения решений: настройте расписание для повторного просмотра решений и параметров клиента на регулярной основе (например, дважды в год).
• Внесите обновления: обновите параметры клиента на основе решений, принятых в семинарах.
• Извлечение данных моментального снимка с помощью API. Используйте REST API получения параметров клиента, чтобы сделать процесс более эффективным, потенциально автоматив создание моментальных снимков на запланированной основе.
• Создание документации для пользователей: создание документации по параметрам клиента для сообщества пользователей. Опубликуйте документацию на централизованном портале. Включите группы безопасности, к которым пользователь должен принадлежать для доступа к функции или возможности.
• Создайте процесс для обработки запросов пользователей: настройте процесс для того, как пользователи могут запрашивать доступ к функции или возможности.
• Настройте процесс для обычного управления параметрами клиента: создайте расписание, чтобы можно было определить новые параметры клиента как можно скорее.
• Настройка аудита. Создайте процесс аудита, чтобы отслеживать изменение параметров клиента и по которым.

Управление доменами

Домены используются в Fabric для группировки двух или нескольких рабочих областей с аналогичными характеристиками. Например, можно создать домен для группировки всех рабочих областей продаж и другого домена для финансовых рабочих областей. Домен представляет одну границу управления. Использование доменов также может облегчить ответственность за владение рабочей областью и управление, которые распределяются по всей организации.

Дополнительные сведения о планировании доменов см. в разделе "Домены рабочей области".

Совет

Домены Fabric, описанные в этом разделе, отличаются от доменов в Microsoft 365.

Шаг 1. Проверка доменов

Первым шагом является проверка существующих доменов и среды клиента, чтобы понять текущее состояние. Ниже приведены некоторые факторы, которые следует учитывать во время процесса проверки.

• Домены: какие домены, если есть, существуют? Четко ли указано имя и описание каждого домена?
• Разрешения. Кто является администраторами домена для каждого домена? Кто является участником домена для каждого домена? Все назначенные администраторы и участники соответствуют целевой цели домена?
• Назначенные рабочие области: какие рабочие области назначаются каждому домену? Соответствуют ли все назначенные рабочие области целевому назначению домена?
• Делегированные параметры клиента: какие параметры клиента делегированы администратору домена (или администратору емкости), чтобы они могли переопределить параметр по умолчанию?

Шаг 2. Выбор доменов

После проверки доменов пора изучить процесс принятия решений.

Для существующих рабочих областей рассмотрим, как их можно сгруппировать для формирования единой границы управления. Дополнительные сведения и способы организации связанных рабочих областей см. в разделе "Домены рабочей области".

Ниже приведены некоторые факторы, которые следует учитывать во время процесса принятия решений.

• Какие решения по управлению уже существуют? По возможности обратитесь к существующим решениям. Стремитесь к настройке рабочей области и домена, которая является согласованной и эффективной.
• Насколько децентрализовано владение и управление контентом? Рассмотрим, как в настоящее время осуществляется владение контентом и управление ими в организации. Иногда децентрализованные подходы называются распределенной, федеративной или архитектурой сетки данных. Фактор в этой информации при анализе потребностей в организации рабочих областей в доменах.
• Какие группы доменов будут работать хорошо? Существует множество способов группировки рабочих областей в одну границу управления. Например, можно упорядочение доменов по темам, группе, подразделению или проекту. Помните, что рабочая область может быть назначена только одному домену. Дополнительные сведения см. в разделе "Домены рабочей области".
• Кто должен быть разрешен для администрирования каждого домена? В идеале администраторы домена — это пользователи , которые непосредственно принадлежат и управляют содержимым для домена. Кроме того, администраторы домена должны быть знакомы с внутренними, региональными и государственными правилами для темы. Они также должны быть знакомы со всеми внутренними требованиями к управлению и безопасности.
• Кому будет разрешено назначать рабочие области домену? Роль участника домена включает пользователей, которым разрешено назначить рабочую область домену. Участники домена также должны быть администратором рабочей области, чтобы назначить рабочую область домену. Рассмотрим, сколько элементов управления вы хотите делегировать пользователям самообслуживания в вашей организации.
• Будут ли разные домены обрабатываться иначе? В крупных организациях некоторые домены могут иметь разные политики. Подготовьтесь к адаптации решений на основе потребностей и навыков разных команд. Дополнительные сведения см. в разделе "Переопределение параметров на уровне клиента".

Шаг 3. Обновление доменов

На этом этапе доступны существующие параметры домена и целевые решения. Теперь вы готовы добавлять, изменять или удалять домены (при необходимости).

Обязательно следуйте существующим методам управления изменениями и сообщите всем пользователям, которые будут затронуты любыми изменениями.

Шаг 4. Домены документов

В зависимости от того, сколько доменов у вас есть, можно создать документацию для расширения информации, доступной на портале администрирования. Ваша документация может включать:

• Дополнительные сведения или контекст, такие как назначение для домена, и почему отдельный домен полезен.
• Кто одобрил домен и когда.
• Кто является владельцем домена или стюардом, если он отличается от администраторов домена, заданных на портале администрирования.
• Любые другие требования соответствия или нормативные требования, связанные с доменом.

Шаг 5. Управление доменами

Домены должны регулярно проверяться на портале администрирования. Ежеквартально, или дважды в год, должны работать хорошо для этой цели.

Кроме того, рассмотрите возможность управления запросами от пользователей, которые хотят создать новый домен, изменить существующий домен или добавить рабочие области в домен.

Шаг 6. Аудит доменов

У вас должен быть процесс регулярного аудита доменов и их параметров. Ниже приведены некоторые действия для идентификации доменов аудита с помощью журнала действий.

• Создан новый домен: найдите действие InsertDataDomainAsAdmin .
• Существующий домен изменился: найдите действие UpdateDataDomainAsAdmin .
• Рабочая область назначена домену: найдите действие UpdateDataDomainFoldersRelationsAsAdmin .
• Администраторы домена или участники домена изменились: найдите действие UpdateDataDomainAccessAsAdmin .

Контрольный список . При планировании и управлении доменами ключевые решения и действия включают:

• Просмотрите текущие домены: определите текущее состояние, просмотрите все домены на портале администрирования.
• Обсудите и решите: определите, какие группы доменов лучше всего будут работать в соответствии с вашими потребностями. При рассмотрении вопросов управления доменами необходимо привлечь соответствующих лиц и заинтересованных лиц.
• Проверьте, требуется ли утверждение: определите, должен ли процесс существовать для получения утверждения от других пользователей при создании нового домена.
• Создайте расписание для повторной проверки: настройте расписание для повторной проверки доменов на регулярной основе.
• Сделайте обновления: обновите домены при возникновении новых потребностей.
• Создание документации. Если необходимо записать другие сведения, создайте документацию для доменов.
• Создайте процесс для обработки запросов пользователей: настройте процесс, чтобы пользователи могли запрашивать новый домен.
• Настройка аудита. Создайте процесс аудита, чтобы отслеживать, когда создаются новые домены, или когда происходят изменения.

Управление рабочими областями

Рабочие области являются основным понятием в Fabric. Рабочие области служат контейнерами для хранения и защиты содержимого. В основном рабочие области предназначены для создания контента, совместной работы и распространения содержимого.

Страница рабочих областей на портале администрирования позволяет администраторам Fabric просматривать и управлять всеми рабочими областями в клиенте.

Ниже приведены несколько причин, по которым администратор Fabric может участвовать в управлении рабочими областями.

• Получите доступ к стандартной рабочей области. Администратор Структуры может помочь в ситуации (например, сбой обновления данных), если основной владелец содержимого, например, не будет в отпуске. В этом случае им потребуется назначить себя роли рабочей области.
• Получите временный доступ к личной рабочей области. Администратор Структуры может получить доступ к личной рабочей области другого пользователя, но только в течение 24 часов. Временный доступ к личной рабочей области полезен, когда владелец рабочей области покинул организацию или находится в отпуске.
• Управление ролями рабочей области. Администратор Структуры имеет разрешение на управление ролями рабочей области для всех рабочих областей в клиенте. Это полезно, когда централизованная команда управляет доступом к рабочей области. Это также полезно, если рабочая область находится в состоянии потерянных (указывая, что нет администратора рабочей области), что может произойти в результате прекращения работы или передачи.
• Переназначьте рабочую область. Чтобы разблокировать другие функции, иногда необходимо обновить режим лицензии рабочей области. Например, администратор Fabric может изменить рабочую область с Pro или Premium на пользователя (PPU) на емкость.
• Определите тип рабочей области. Администратор Структуры может просмотреть уровень SKU, которому назначена рабочая область. Например, администратор может быстро определить наличие четырех рабочих областей в клиенте, назначенных PPU.
• Найдите и/или восстановите удаленные рабочие области. Состояние рабочей области может указать, что рабочая область удалена. В течение короткого периода администратор Структуры может восстановить рабочую область, если она была удалена в ошибке. Кроме того, они могут восстановить удаленную личную рабочую область как стандартную рабочую область . Дополнительные сведения см. в разделе "Хранение рабочей области".
• Обновите имя рабочей области. Администратор Структуры может переименовать рабочую область, возможно, потому что его имя не соответствует установленному соглашению об именовании.

Примечание.

Уровень участия в управлении рабочими областями зависит от ролей и обязанностей, назначенных администратору Fabric. Стратегия владения контентом и управления также может повлиять на степень, в которой администратор Fabric участвует в управлении рабочими областями.

Шаг 1. Просмотр рабочих областей

Первым шагом является проверка существующих рабочих областей и среды клиента, чтобы понять текущее состояние. Ниже приведены некоторые факторы, которые следует учитывать во время процесса проверки.

• Текущие рабочие области: просмотрите все рабочие области, которые в настоящее время существуют. Вы также должны просмотреть назначения ролей и параметры каждой рабочей области, чтобы убедиться, что они соответствующие.
• Текущий параметр клиента: просмотрите текущую настройку параметра клиента "Создание рабочих областей".

Существует два способа компиляции списка текущих рабочих областей.

• Просмотрите список рабочих областей на портале администрирования. Список можно экспортировать в CSV-файл.
• Программное извлечение инвентаризации клиента с помощью API администратора с помощью:
  • API-интерфейсы сканирования метаданных (также известные как API сканера). Этот набор API позволяет асинхронно находить измененные рабочие области. Так как он может извлекать постепенно измененные рабочие области, лучше всего подходит для крупных организаций с большим количеством рабочих областей. Дополнительные сведения см. в разделе "Метаданные" с помощью API-интерфейсов проверки метаданных.
  • REST API Get Groups as Admin или командлет Get-PowerBIWorkspace PowerShell. Эти методы возвращают данные для всех рабочих областей в клиенте, поэтому они лучше подходят для небольших организаций с меньшими объемами данных. Дополнительные сведения см. в разделе API групп или командлетов рабочих областей.

Шаг 2. Выбор рабочих областей

После просмотра рабочих областей пора изучить процесс принятия решений.

Ниже приведены некоторые факторы, которые следует учитывать во время процесса принятия решений.

• Какие решения по управлению уже существуют? По возможности обратитесь к существующим решениям по управлению рабочей областью . Стремитесь к настройке рабочей области, чтобы она была согласованной и эффективной.
• Кто должен быть разрешен для создания рабочих областей? Рассмотрим, что разрешения на создание рабочей области — это язык и региональные параметры и решение по управлению.
• Должен ли быть определенный процесс создания рабочих областей? Важно установить процесс создания рабочей области, удобный и удобный для пользователей.
• Как следует называть рабочие области? Определите, будет ли соглашение об именовании рабочей области использовать организацию.
• Как организованы рабочие области? Часто полезно упорядочивать рабочие области по темам и областям. Подход к организации содержимого в рабочих областях может отличаться от отделов.
• Сколько содержимого содержится в личных рабочих областях? Рассмотрите возможность использования личных рабочих областей в вашей организации.
• У кого должен быть доступ к рабочим областям? В первую очередь следует ограничить доступ к рабочей области пользователям, которые создают содержимое и управляют ими. Дополнительные сведения см. в разделе "Планирование безопасности создателя контента".

Дополнительные рекомендации см. в статье "Планирование рабочей области на уровне клиента" и планирование рабочей области на уровне рабочей области.

Шаг 3. Обновление рабочих областей

На этом этапе доступны существующие рабочие области и целевые решения. Если вы нашли рабочие области, которые будут переименованы или перенастроены, теперь вы готовы внести любые необходимые изменения.

Рекомендации во время процесса обновления включают:

• Кто будет обрабатывать обновление? Если у вас несколько администраторов Fabric, определите, управляются ли рабочие области одним или двумя определенными администраторами. Убедитесь, что процесс согласован, хорошо понятен и хорошо контролируется.
• Существует ли процесс управления изменениями? Рассмотрим, как избежать несоответствий между решениями, документацией и результирующей обновлениями. Обмен данными между командами является ключевым фактором успеха в управлении изменениями. В зависимости от требований аудита вы можете сохранить внутренний журнал изменений для отслеживания того, кто сделал изменения, когда и почему (записывать дополнительные сведения за пределами записанных в журнале действий).
• Как будет обрабатываться взаимодействие с пользователями? При внесении изменений, влияющих на то, что пользователи могут сделать, обязательно общаться с этим изменением. Всегда старайтесь избежать разочарования пользователей и ненужных запросов на поддержку.

Шаг 4. Рабочие области документов

В зависимости от того, сколько рабочих областей у вас есть, можно создать документацию для расширения сведений, доступных на портале администрирования или REST API. Этот тип документации является ключевой частью инвентаризации клиента. Ваша документация может включать:

• Дополнительные сведения или контекст, например предназначенная для рабочей области (если она еще не упоминалась в описании рабочей области).
• Кто одобрил рабочую область и когда.
• Кто назначен владельцем рабочей области, если владелец отличается от администраторов рабочей области.
• Требования к соответствию или нормативным требованиям, связанным с содержимым, хранящимся в рабочей области.
• Содержит ли рабочая область особенно конфиденциальную информацию.
• Требования к управлению для рабочей области.
• Процессы управления жизненным циклом, применимые к рабочей области.

Шаг 5. Управление рабочими областями

Управление рабочими областями на постоянной основе включает в себя:

• Создание рабочих областей.
• Обновление метаданных рабочей области (например, имя или описание).
• Обновление ролей рабочей области.
• Восстановление удаленных рабочих областей.
• Переназначение рабочей области (например, с Pro на PPU).
• Управление параметром клиента "Создание рабочих областей ".

В зависимости от ролей и обязанностей вторичные действия администратора могут включать:

• Публикация содержимого (например, семантической модели или отчета) в рабочую область.
• Устранение неполадок, связанных с существующим содержимым рабочей области.

Внимание

Роль администратора Fabric — это роль с высоким уровнем привилегий, которая может выполнять множество высокоуровневых функций. В частности, роль не предоставляет автоматически доступ ко всем данным в клиенте. Тем не менее, поскольку администраторы имеют права на управление рабочими областями в клиенте, они могут предоставлять доступ (через роли рабочей области) другим пользователям, включая себя.

Шаг 6. Аудит рабочих областей

У вас должен быть процесс регулярного аудита рабочих областей. Ниже приведены некоторые действия, которые необходимо определить при аудите рабочих областей с помощью журнала действий.

• Изменен параметр клиента Create workspaces : найдите измененные значения параметров клиента в журнале действий с помощью действия UpdatedAdminFeatureSwitch . Имя элемента будет создано в CreateAppWorkspaces.
• Администратор Fabric получил доступ к личной рабочей области пользователя: найдите действие AddAdminPersonalWorkspaceAccess . Имя рабочей области будет иметь формат PersonalWorkspace-NameOfUser. Действие не регистрируется, когда система автоматически отменяет доступ, что происходит через 24 часа.
• Создана новая рабочая область: найдите действие CreateFolder .
• Существующая рабочая область изменилась: найдите действие UpdateFolder .
• Доступ к рабочей области изменился: найдите действие UpdateWorkspaceAccess или действие UpdateFolderAccess.
• Рабочая область была переназначена: найдите действие MigrateWorkspaceIntoCapacity .
• Рабочая область назначена домену: найдите действие UpdateDataDomainFoldersRelationsAsAdmin .

Совет

Помимо использования журнала действий, рекомендуется регулярно создавать инвентаризацию клиентов. Это моментальный снимок, который описывает все рабочие области и их содержимое (например, семантические модели и отчеты). Кроме того, он может записывать сведения о доступе к рабочей области. Дополнительные сведения см. в разделе "Инвентаризация клиентов" и "Доступ к данным инвентаризации клиентов".

Контрольный список . При планировании и управлении рабочими областями ключевые решения и действия включают:

• Просмотрите текущие рабочие области: определите текущее состояние, просмотрите все рабочие области и связанные параметры клиента на портале администрирования.
• Обсудите и решите: определите, как управлять рабочими областями и управлять ими. При принятии решения о том, кто может управлять рабочими областями, необходимо привлечь соответствующих лиц и заинтересованных лиц.
• Проверьте, требуется ли утверждение: определите, должен ли процесс существовать для получения утверждения от других пользователей при создании новой рабочей области.
• Создайте расписание для повторной проверки: настройте расписание для повторной проверки рабочих областей на регулярной основе.
• Обновление рабочих областей, включая назначения ролей, при возникновении новых потребностей.
• Создание документации. Если необходимо отслеживать дополнительные сведения, создайте документацию для рабочих областей.
• Создайте процесс для обработки запросов пользователей: настройте процесс запроса пользователей о том, как пользователи могут запрашивать новую рабочую область.
• Настройте аудит: создайте процесс аудита, чтобы отслеживать, когда создаются новые рабочие области или когда происходят изменения.

Управление кодами внедрения

При использовании функции публикации в Интернете Power BI создает код внедрения. Код внедрения используется для внедрения отчета на веб-странице, доступной в Интернете всем пользователям. Эта возможность доступна для конкретных целей: она предназначена в основном для журналистики данных или отчетов, содержащих общедоступные данные, которые могут просматриваться анонимной аудиторией, не требуя проверки подлинности.

Регулярно просматривайте коды внедрения и управляйте ими является ключевой ответственностью администратора Fabric. Это особенно важная ответственность, поскольку она включает в себя проверку отчетов, которые были опубликованы публично в Интернете.

Внимание

Некоторые администраторы ошибочно считают, что внутренний сайт приложения или интрасети является безопасным расположением для внедрения публикации в веб-отчет. Мы настоятельно рекомендуем использовать этот метод таким образом, так как отчеты, опубликованные с помощью публикации в Интернете, независимо от того, где вы внедряете их, можно обнаружить с помощью поисковой системы. Для внедрения содержимого Power BI для внутренней аудитории рекомендуется использовать функции внедрения API или использовать метод внедрения кода без кода. Дополнительные сведения см. в статье о внедрении сценария использования организации .

Шаг 1. Проверка кодов внедрения

Первым шагом является проверка существующих кодов внедрения и среды клиента, чтобы понять текущее состояние. Ниже приведены некоторые факторы, которые следует учитывать во время процесса проверки.

• Текущие коды внедрения: просмотрите каждый код внедрения во всех рабочих областях на портале администрирования. Запишите состояние каждого кода внедрения (например, активный или заблокированный).
• Текущий параметр клиента: просмотрите текущую настройку параметра публикации в веб-клиенте.

Шаг 2. Решение о коде внедрения

После проверки кодов внедрения пришло время изучить процесс принятия решений. Привлечь соответствующих лиц, принимающих решения, и заинтересованных лиц в обсуждениях о том, какие материалы, если таковые имеются, можно опубликовать в Интернете.

Также определите, какие пользователи могут публиковать отчеты в Интернете. Если политика управления или политика безопасности существует, обратитесь к ней по возможности.

Внимание

Настоятельно рекомендуется включить параметр "Опубликовать в веб-клиенте " для очень ограниченного набора пользователей. Из-за высокого риска случайной публикации отчетов, содержащих конфиденциальные данные, рассмотрите возможность запрета или ограничения создателей контента от публикации в Интернете.

Шаг 3. Обновление кодов внедрения

На этом этапе доступны существующие коды внедрения и целевые решения. Теперь вы готовы внести временные или постоянные изменения в существующие коды внедрения.

Чтобы определить, какие обновления необходимы, может потребоваться выполнить некоторые дальнейшие исследования.

• Просмотрите все отчеты, имеющие активные коды внедрения, чтобы убедиться, что в Интернете нет неуместных сведений. Кроме того, убедитесь, что базовые семантические модели не содержат конфиденциальных или закрытых сведений.
• Обратитесь к пользователю, который опубликовал отчет, чтобы уточнить его назначение.
• При необходимости обратитесь к владельцу содержимого, чтобы переместить содержимое в не личную рабочую область, которая хорошо подходит для этой цели. Рассмотрите возможность использования рабочей области, которая четко указывает, что она содержит общедоступное содержимое. Например, имя рабочей области "Финансы" [public] четко указывает на ее назначение.
• Просмотрите метку конфиденциальности, назначенную содержимому. Убедитесь, что метка конфиденциальности указывает, что целевая аудитория является общедоступной аудиторией.

Шаг 4. Коды внедрения документов

В зависимости от ваших обстоятельств вы можете создать некоторую документацию, чтобы дополнить сведения, доступные на портале администрирования. Ваша документация может включать:

• Дополнительные контексты и детали, такие как назначение, целевая аудитория и обоснование.
• Кто одобрил публикацию содержимого публично и когда.
• Кто владелец контента — если он отличается от пользователя, который опубликовал его.

Шаг 5. Управление кодами внедрения

Коды внедрения должны регулярно отслеживаться на портале администрирования. Кроме того, рассмотрите возможность управления запросами от пользователей, которые хотят опубликовать отчеты в Интернете.

Примечание.

Не все отчеты поддерживаются для использования с публикацией в Интернете. Возможно, у пользователей будут вопросы о поддержке , связанные с использованием функции.

Шаг 6. Аудит кодов внедрения

Важно регулярно проводить аудит кодов внедрения. Ниже приведены некоторые действия, которые необходимо определить при аудите кодов внедрения с помощью журнала действий.

• Создан новый код внедрения: найдите действие PublishToWebReport .
• Изменен параметр публикации в веб-клиенте : найдите измененные значения параметров клиента в журнале действий с помощью действия UpdatedAdminFeatureSwitch . Имя элемента будет PublishToWeb.

Контрольный список . При планировании и управлении кодами внедрения, ключевыми решениями и действиями относятся:

• Просмотрите текущие коды внедрения: определите текущее состояние, просмотрив все коды внедрения на портале администрирования.
• Просмотрите текущий параметр клиента: просмотрите настройку параметра публикации в веб-клиенте .
• Обсудите и решите: определите, какое содержимое, если таковые есть, можно опубликовать публично и с помощью каких пользователей. При необходимости необходимо привлечь соответствующих лиц и заинтересованных лиц. По возможности обратитесь к существующим политикам управления.
• Проверьте, требуется ли утверждение: определите, должен ли процесс существовать для получения утверждения от других пользователей при публикации отчета в Интернете.
• Создайте расписание для повторной проверки: настройте расписание для повторного просмотра кодов внедрения на регулярной основе.
• Обновление. При необходимости обновите текущие коды внедрения. Обновите параметр публикации в веб-клиенте на основе принятых решений (если они отличаются от опубликованных в настоящее время).
• Создание документации. Если необходимо отслеживать дополнительные сведения, создайте документацию по кодам внедрения.
• Создайте процесс для обработки запросов пользователей: настройте процесс того, как пользователи могут запрашивать публикацию отчета в Интернете или иметь разрешение на публикацию собственных отчетов в Интернете.
• Настройка аудита. Создайте процесс аудита, чтобы отслеживать создание нового кода внедрения и изменение параметра публикации в веб-клиенте .

Управление визуальными элементами организации

Создатели отчетов Power BI могут использовать несколько типов визуальных элементов в их конструкторе отчетов Power BI.

• Основные визуальные элементы: визуальные элементы по умолчанию, встроенные в Power BI Desktop и служба Power BI.
• Не сертифицированные пользовательские визуальные элементы из AppSource: пользовательские визуальные элементы, разработанные сторонними поставщиками программного обеспечения или членами сообщества Power BI по всему миру.
• Сертифицированные пользовательские визуальные элементы из AppSource: пользовательские визуальные элементы, разработанные сторонними поставщиками программного обеспечения или членами сообщества Power BI по всему миру, и которые прошли процесс сертификации, определенный корпорацией Майкрософт.

Организация может ограничить использование пользовательских визуальных элементов (когда отчет публикуется в служба Power BI), зарегистрируя, какие визуальные элементы (и версии) разрешены. Допустимые визуальные элементы называются визуальными элементами организации.

Администраторы Структуры отвечают за регистрацию и управление визуальными элементами организации в Центре администрирования. Они могут зарегистрировать:

• Сертифицированные и не сертифицированные визуальные элементы из AppSource. Регистрация определенного визуального элемента особенно полезна, если включен параметр клиента несертифицированных (или всех) визуальных элементов, но определенный визуальный элемент был проверен и утвержден для использования в вашей организации.
• Собственные визуальные элементы, разработанные внутри компании.
• Пользовательские визуальные элементы, приобретенные непосредственно у поставщика.

Существует множество преимуществ регистрации визуальных элементов организации.

• Некоторые или все пользовательские визуальные элементы будут автоматически доступны на панели визуализаций для всех создателей отчетов.
• Создатели содержимого не должны импортировать файлы визуальных элементов Power BI (PBIVIZ).
• Версия пользовательских визуальных элементов согласована для всех отчетов.
• Отчеты и панели мониторинга будут автоматически обновляться при обновлении визуального элемента организации.
• Новые и измененные пользовательские визуальные элементы можно методически протестировать и предварительно утвердить, прежде чем стать широко доступными для организации.
• Если существующий пользовательский визуальный элемент больше не соответствует требованиям организации, его можно быстро отключить или удалить.

Дополнительные сведения о распространении пользовательских визуальных элементов на пользовательских устройствах (для использования в Power BI Desktop) см. в разделе "Пользовательские визуальные элементы".

Остальная часть этого раздела посвящена управлению визуальными элементами организации.

Шаг 1. Просмотр визуальных элементов организации

Первым шагом является проверка существующих визуальных элементов организации и среды клиента, чтобы понять текущее состояние.

• Текущие визуальные элементы организации: проверьте, какие пользовательские визуальные элементы были добавлены в репозиторий визуальных элементов организации.
• Текущий параметр клиента: проверьте настройку параметров клиента визуальных элементов Power BI.

Шаг 2. Выбор визуальных элементов организации

После просмотра визуальных элементов организации пора изучить процесс принятия решений. Вы должны быть готовы принять тщательное решение о том, как управлять пользовательскими визуальными элементами.

Ниже приведены некоторые вопросы, которые следует рассмотреть во время процесса принятия решений.

• Разрешены ли пользовательские визуальные элементы организации? Существует несколько причин, по которым организация может быть намеренной при использовании пользовательских визуальных элементов.
  • Ожидания качества и стабильности зависят от того, кто разработал пользовательский визуальный элемент.
  • Свободно доступные пользовательские визуальные элементы могут не поддерживать техническую поддержку.
  • Для организаций с значительными проблемами конфиденциальности данных ( или очень чувствительными к проблемам утечки данных) использование пользовательских визуальных элементов может быть несовместимо с их профилем риска. Это связано с тем, что пользовательские визуальные элементы имеют доступ к данным, запрашиваемые из семантических моделей. Кроме того, можно также, что пользовательский визуальный элемент может передавать данные обратно в веб-службу (которая часто используется для законных целей, таких как вызов API или запуск алгоритма ИИ).
• Как настраиваемое визуальное представление проверено и утверждено для использования? Все пользовательские визуальные элементы должны быть проверены и предварительно утверждены для использования в организации. Этот процесс проверки снижает риск использования ненадежных визуальных элементов. Кроме того, администратор может указать, какая версия проверена и утверждена для использования.
• Кто может использовать пользовательские визуальные элементы? Визуальные элементы allow, созданные с помощью параметров клиента пакет SDK для Power BI, которые разрешены добавлять, предоставлять общий доступ или взаимодействовать с пользовательским визуальным элементом. Если организация приняла решение ограничить или ограничить эту функциональность (из AppSource или импортированных PBIVIZ-файлов), то вы можете зависеть от визуальных элементов организации в качестве способа разрешить определенные пользовательские визуальные элементы.
• Требуются ли сертифицированные визуальные элементы? Если AppSource разрешено, некоторые организации предпочитают ограничить его только сертифицированными визуальными элементами. Это сделано путем настройки параметра "Добавить и использовать сертифицированные визуальные элементы" только для клиента. В этой ситуации можно использовать визуальные элементы организации для распространения несертифицированного визуального элемента, утвержденного для использования организацией.
• Следует ли централизованно управлять пользовательскими визуальными элементами? Когда визуальные элементы скачиваются из AppSource отдельными создателями отчетов, могут возникнуть проблемы с несоответствиями версий. С помощью визуального репозитория организации для централизованного управления пользовательскими визуальными элементами процесс упрощает процесс для создателей отчетов, так как он позволяет всем создателям отчетов Power BI в клиенте использовать ту же утвержденную версию. Однако это требует, чтобы администратор Fabric принимал участие, что может привести к задержкам.
• Какие источники разрешены? Визуальные элементы организации могут поступать из AppSource или PBIVIZ-файла. AppSource обычно является лучшим источником, особенно если вы хотите использовать сертифицированный визуальный элемент. PBIVIZ-файл подходит, если визуальный элемент был получен от поставщика в частном порядке или когда он был разработан внутри системы.
• Когда пользовательский визуальный элемент должен отображаться в области визуализаций? Во многих случаях необходимо разрешить пользовательскому визуальному элементу отображаться в области визуализаций, чтобы он был автоматически доступен всем создателям отчетов.

Шаг 3. Обновление визуальных элементов организации

На этом этапе доступны существующие визуальные элементы организации и целевые решения. Теперь вы готовы внести временные или постоянные изменения в существующие визуальные элементы организации.

Кроме того, может потребоваться изменить параметры клиента, связанные с пользовательскими визуальными элементами (если создатели отчетов могут скачать и установить пользовательские визуальные элементы, которые не находятся в репозитории визуальных элементов организации).

Примечание.

Параметры клиента, связанные с пользовательскими визуальными элементами, применяются только к опубликованным отчетам, а не к отчетам в Power BI Desktop. Чтобы создатели отчетов имели согласованные настраиваемые визуальные параметры в служба Power BI и Power BI Desktop, вам потребуется управлять визуальными элементами локального компьютера (для Power BI Desktop) с помощью групповой политики. Дополнительные сведения см. в разделе "Пользовательские средства и устройства".

Шаг 4. Визуальные элементы организации документа

В зависимости от ситуации вы можете создать некоторую документацию, чтобы дополнить сведения, доступные на портале администрирования. Ваша документация может включать:

• Дополнительные сведения и контекст, например то, что делает пользовательский визуальный элемент.
• Кто создал пользовательский визуальный элемент (например, внутренний разработчик или поставщик), или кто будет обращаться за дополнительными сведениями.
• Тесты, выполненные для проверки визуального элемента, чтобы их можно было повторять, следует обновить визуальный элемент.
• Кто одобрил использование пользовательского визуального элемента и когда.

Шаг 5. Управление визуальными элементами организации

Визуальные элементы организации должны регулярно отслеживаться на портале администрирования. Кроме того, рассмотрите возможность управления запросами от пользователей, которые хотят использовать новый пользовательский визуальный элемент, который они находят в Интернете.

Иногда следует также проверять время последнего обновления каждого пользовательского визуального элемента. Проверьте, доступна ли более новая версия. Когда доступна более новая версия, вы можете обновить визуальный элемент организации, если он проходит тестирование.

Шаг 6. Аудит визуальных элементов организации

Важно регулярно проводить аудит визуальных элементов организации. Ниже приведены некоторые действия, которые необходимо определить при аудите визуальных элементов организации с помощью журнала действий.

• Добавлен новый визуальный элемент организации: найдите действие InsertOrganizationalGalleryItem .
• Существующий визуальный элемент организации обновлен: найдите действие UpdateOrganizationalGalleryItem .
• Визуальные элементы allow, созданные с помощью параметра клиента пакет SDK для Power BI, изменились: найдите измененные значения параметров клиента в журнале действий с помощью действия UpdatedAdminFeatureSwitch. Имя элемента будет CustomVisualsTenant.
• Изменен параметр "Добавление и использование сертифицированных визуальных элементов" (только для блокировки без сертификации): найдите измененные значения параметров клиента в журнале действий с помощью действия UpdatedAdminFeatureSwitch . Имя элемента будет сертифицированоCustomVisualsTenant.

Контрольный список . При планировании и управлении визуальными элементами организации ключевые решения и действия включают:

• Просмотрите текущие визуальные элементы организации: определите текущее состояние, просмотрите все визуальные элементы организации на портале администрирования.
• Просмотрите текущие параметры клиента: просмотрите все параметры клиента визуальных элементов Power BI. Определите, как они могут повлиять на зависимость от визуальных элементов организации.
• Обсудите и решите: определите, как пользовательские визуальные элементы должны использоваться в организации и кем. При рассмотрении вопроса об использовании визуальных элементов организации, AppSource и PBIViz соответствующих лиц и заинтересованных лиц.
• Создайте расписание для повторной проверки: настройте расписание для повторного просмотра визуальных элементов организации на регулярной основе.
• Обновление: обновите текущие визуальные элементы организации по мере необходимости. Обновите параметры клиента визуальных элементов Power BI на основе принятых решений (если они отличаются от опубликованных в настоящее время).
• Управление компьютерами пользователей. Настройте групповую политику, чтобы гарантировать, что пользовательские визуальные элементы управляются так же, как в Power BI Desktop, так и в служба Power BI.
• Создание документации. Если необходимо отслеживать дополнительные сведения, создайте документацию по визуальным элементам организации.
• Создайте процесс для обработки запросов пользователей: настройте процесс, чтобы пользователи могли запрашивать использование пользовательских визуальных элементов (в целом) или запрашивать доступ к конкретному пользовательскому визуальному элементу.
• Настройка аудита. Создайте процесс аудита, чтобы отслеживать, когда новый настраиваемый визуальный элемент зарегистрирован в качестве визуального элемента организации, а также при изменении параметров клиента визуальных элементов Power BI.

Управление подключениями Azure

Power BI может интегрироваться со службами Azure для расширения функций и предоставления других функций. Существует три основных причины использования подключений Azure.

• Хранилище данных для потоков данных (1-го поколения). Доступ к данным для потоков данных Power BI (1-го поколения) можно получить непосредственно в Azure. Рабочая область может быть подключена к учетной записи хранения, определенной на уровне клиента, или к учетной записи хранения, относящуюся к рабочей области. Этот метод иногда называется собственным озером (BYOL). Гибкость стратегии BYOL полезна, если вы хотите повторно использовать потоки данных за пределами Power BI, позволяя другим процессам или другим пользователям просматривать или получать доступ к данным. Дополнительные сведения см. в статье Настройка хранилища потоков данных для использования Azure Data Lake Storage 2-го поколения и сценария самостоятельной подготовки данных.

• Резервное копирование и восстановление семантической модели. Возможно, потребуется выполнить резервное копирование и восстановление семантической модели для аварийного восстановления, выполнить требования к хранению данных или перенести модель данных. Дополнительные сведения см. в статье "Резервное копирование и восстановление семантических моделей с помощью Power BI Premium".

• Интеграция Azure Log Analytics. Вы можете анализировать семантические действия модели, производительность и тенденции. Интеграция Log Analytics позволяет просматривать диагностические данные, созданные подсистемой Служб Analysis Services (где размещаются семантические модели Power BI). Дополнительные сведения см . в журналах событий семантической модели.

  Примечание.

  Изменение имени набора данных было развернуто в служба Power BI и документации, хотя в документации может быть несколько экземпляров, например с именами операций журнала событий, где изменение еще не произошло.

Если основной вариант использования подключений Azure предназначен для хранения данных (BYOL, описанный в первой точке выше), рекомендуется использовать потоки данных 2-го поколения и OneLake . Хотя оба используют ADLS 2-го поколения для хранения данных, они предлагают различные возможности, имеют несколько разных целей и используют разные параметры хранения (в зависимости от способа записи данных). Например: OneLake хранит табличные данные и потоки данных 2-го поколения в открытом формате Delta Parquet, а выходные данные из потоков данных Power BI (1-го поколения) (с подключениями Azure) хранят данные в общем формате модели данных. Дополнительные сведения см. в статье "Получение из поколения 1 в поколение 2".

Остальная часть этого раздела посвящена управлению подключениями Azure на портале администрирования.

Шаг 1. Проверка подключений Azure

Первым шагом является проверка существующих подключений Azure и среды клиента, чтобы понять текущее состояние. Существует две области для рассмотрения.

Сначала просмотрите существующие параметры на портале администрирования.

• Текущий параметр хранилища на уровне клиента: проверьте, как в настоящее время настроено хранилище на уровне клиента. Он предоставляет подключение Azure по умолчанию, к которому администраторы рабочих областей могут подключаться в параметрах рабочей области.
• Текущие разрешения хранилища на уровне рабочей области: проверьте, включены ли разрешения хранилища на уровне рабочей области. При включении администраторы рабочих областей могут подключать рабочую область к собственной учетной записи ADLS 2-го поколения.

Во-вторых, ознакомьтесь с настройкой подключений Azure Log Analytics для параметра клиента администраторов рабочей области. При включении администраторы рабочих областей могут подключать рабочую область к учетной записи ADLS 2-го поколения для отправки диагностических данных для семантических моделей.

Шаг 2. Выбор подключений Azure

После проверки подключений Azure пора изучить процесс принятия решений.

Ниже приведены некоторые вопросы, которые следует рассмотреть во время процесса принятия решений.

• Соответствует ли использование подключений Azure с вашей стратегией данных и потребностями пользователей? Рассмотрите, будут ли подключения Azure полезными для хранения потоков данных (1-го поколения). Определите, имеются ли требования к использованию функций резервного копирования и восстановления семантической модели. Рассмотрите необходимость интеграции Azure Log Analytics.
• Какое хранилище данных является централизованным и децентрализованным? Узнайте о потребностях децентрализованных команд и о том, поддерживают ли отдельные лица или отделы свои собственные служба хранилища Azure учетные записи. Определите, разрешено ли администраторам рабочей области подключать собственную учетную запись ADLS 2-го поколения или использовать одну учетную запись ADLS 2-го поколения для всех рабочих областей (хранилище на уровне клиента).
• Как будет использоваться OneLake и подключения Azure? При внедрении OneLake рассмотрите возможность постепенного перехода к использованию OneLake для хранения данных (BYOL).

Дополнительные сведения см. в статье "Интеграция рабочей области с ADLS 2-го поколения".

Дополнительные сведения см. в статье "Интеграция рабочей области с Azure Log Analytics".

Шаг 3. Обновление подключений Azure

На этом этапе доступны существующие подключения Azure, и вы приняли целенаправленные решения о том, планируется ли интегрировать озеро данных с Power BI. Теперь вы готовы настроить параметры, если это необходимо, на основе ваших результатов.

Шаг 4. Документирование подключений Azure

В зависимости от ситуации необходимо создать некоторую документацию, чтобы дополнить сведения, доступные на портале администрирования. Ваша документация может включать:

• Расположение озера данных уровня клиента, утвержденное для использования. Включите тех, кто владеет и управляет озером данных, и кто будет обращаться за дополнительными сведениями.
• Можно ли интегрировать озера данных на уровне рабочей области. Другие сведения, такие как ключевые решения, принятые и причины, должны быть задокументированы для последующей справки.

Шаг 5. Управление подключениями Azure

Подключения Azure должны отслеживаться на портале администрирования от времени.

Рассмотрим, как вы будете поддерживать несколько учетных записей ADLS 2-го поколения в организации (если разрешены подключения Azure на уровне рабочей области).

Кроме того, рассмотрите возможность управления запросами от пользователей, которые хотят подключить рабочую область к Azure Log Analytics.

Шаг 6. Аудит подключений Azure

Важно регулярно проводить аудит подключений Azure. Существует несколько действий, которые необходимо определить при аудите подключений Azure с помощью журнала действий.

• Рабочая область подключена к ADLS 2-го поколения: найдите действие AddLinkToExternalResource. ResourceType указывает, является ли это учетной записью хранения или Log Analytics.
• Рабочая область отключена от ADLS 2-го поколения: найдите действие DeleteLinkToExternalResource. ResourceType указывает, является ли это учетной записью хранения или Log Analytics.
• Хранилище на уровне клиента включено или отключено: найдите измененные значения в журнале действий с помощью действия AddExternalResource или действия DeleteLinkToExternalResource.
• Хранилище на уровне рабочей области включено или отключено. Найдите измененные значения в журнале действий с помощью действия UpdatedAdminFeatureSwitch . Имя элемента будет storageAccountAttachForWorkspaceAdminsEnabled. Параметр SwitchState будет иметь значение true или false.
• Подключения Azure Log Analytics для параметров клиента администраторов рабочих областей изменились: этот параметр клиента позволяет некоторым или всем администраторам рабочей области интегрировать собственную учетную запись ADLS 2-го поколения. Найдите измененные значения параметров клиента в журнале действий с помощью действия UpdatedAdminFeatureSwitch . Имя элемента будет logAnalyticsAttachForWorkspaceAdmins.

Контрольный список . При планировании подключений Azure и управлении ими к ключевым решениям и действиям относятся:

• Просмотрите текущие подключения Azure: определите текущее состояние, просмотрите параметры уровня клиента и рабочей области для подключений Azure на портале администрирования. Кроме того, ознакомьтесь с настройкой подключений Azure Log Analytics для параметров клиента администраторов рабочей области.
• Обсудите и решите: определите, планируется ли интегрировать подключения Azure с Power BI. В будущем решите, что оптимально использовать для OneLake, а также для подключений Azure к хранилищу данных (BYOL).
• Проверьте, требуется ли утверждение: определите, должен ли процесс существовать для получения утверждений для использования учетных записей хранения на уровне рабочей области.
• Создайте расписание для повторной проверки: настройте расписание для повторного просмотра подключений Azure на регулярной основе.
• Обновление: обновите текущие подключения Azure, чтобы изменить разрешения хранилища на уровне клиента и рабочей области. Кроме того, обновите подключения Azure Log Analytics для параметров клиента администраторов рабочих областей на основе принятых решений (если они отличаются от того, что в данный момент задано).
• Создание документации. Если необходимо отслеживать дополнительные сведения, создайте документацию по подключениям Azure.
• Создайте процесс для обработки запросов пользователей: настройте процесс того, как пользователи могут запрашивать возможность использования подключений Azure.
• Настройка аудита. Создайте процесс аудита, чтобы отслеживать, когда рабочие области установили подключение Azure или изменились параметры.

Аудит использования Power BI

Данные аудита на уровне клиента позволяют анализировать меры по внедрению, анализировать шаблоны использования, обучать пользователей, поддерживать пользователей, устранять риски, улучшать соответствие, управлять затратами на лицензии и отслеживать производительность. Важно, чтобы вы извлекли и храните данные аудита Power BI как можно раньше, даже если сегодня вы еще не готовы проанализировать данные.

Сведения об аудите пользователей, действий и решений в Power BI см. в статье об аудите на уровне клиента.

Мониторинг служба Power BI

Мониторинг относится к текущим действиям, которые сообщают вам о том, что происходит. Мониторинг обычно является пассивным действием, которое включает оповещения и автоматизацию, хотя иногда это делается активно.

Сведения о мониторинге Power BI см. в разделе "Мониторинг на уровне клиента".

Связанный контент

Дополнительные рекомендации, действия, критерии принятия решений и рекомендации по внедрению Power BI см. в статье о планировании реализации Power BI.