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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя администратор 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 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 или запуск алгоритма ИИ).
• Как настраиваемое визуальное представление проверено и утверждено для использования? Все пользовательские визуальные элементы должны быть проверены и предварительно утверждены для использования в организации. Этот процесс проверки снижает риск использования ненадежных визуальных элементов. Кроме того, администратор может указать, какая версия проверена и утверждена для использования.
• Кто может использовать пользовательские визуальные элементы? Настройка клиента “Разрешить визуальные элементы, созданные с помощью SDK для Power BI” определяет, кто имеет право добавлять, предоставлять доступ или взаимодействовать с пользовательскими визуальными элементами. Если организация приняла решение ограничить или запретить эту функциональность (из AppSource или импортированных .pbiviz файлов), то вы можете полагаться на организационные визуальные элементы как на способ разрешить определенные пользовательские визуальные элементы.
• Требуются ли сертифицированные визуальные элементы? Если AppSource разрешено, некоторые организации предпочитают ограничить его только сертифицированными визуальными элементами. Это осуществляется путем настройки параметра клиента "Добавить и использовать только сертифицированные визуальные элементы". В этой ситуации можно использовать визуальные инструменты организации для распространения визуального материала, который не сертифицирован, но утвержден для использования организацией.
• Следует ли централизованно управлять пользовательскими визуальными элементами? Когда визуальные элементы скачиваются из AppSource отдельными создателями отчетов, могут возникнуть проблемы с несоответствиями версий. Использование визуального репозитория для централизованного управления пользовательскими визуальными элементами упрощает задачу создателям отчетов, так как позволяет всем создателям отчетов Power BI внутри организации использовать одну и ту же утвержденную версию. Однако это требует, чтобы администратор Fabric принимал участие, что может привести к задержкам.
• Какие источники разрешены? Визуальные элементы организации могут поступать из AppSource или .pbiviz файла. AppSource обычно является лучшим источником, особенно если вы хотите использовать сертифицированный визуальный элемент. PBIVIZ-файл подходит, если визуальный элемент был получен от поставщика в частном порядке или когда он был разработан внутри системы.
• Когда пользовательский визуальный элемент должен отображаться в области визуализаций? Во многих случаях необходимо разрешить пользовательскому визуальному элементу отображаться в области визуализаций, чтобы он был автоматически доступен всем создателям отчетов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление подключениями 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 Storage. Определите, разрешено ли администраторам рабочей области подключать собственную учетную запись ADLS 2-го поколения или использовать одну учетную запись ADLS 2-го поколения для всех рабочих областей (хранилище на уровне клиента).
• Как будет использоваться OneLake в сравнении с подключениями Azure? При внедрении OneLake рассмотрите возможность постепенного перехода к использованию OneLake для хранения данных (BYOL).

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

Дополнительные сведения см. в статье "Интеграция рабочей области с 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 Gen2: найдите процесс DeleteLinkToExternalResource. ResourceType указывает, является ли это учетной записью хранения или Log Analytics.
• Хранилище на уровне клиента включено или отключено: найдите измененные значения в журнале действий с помощью действия AddExternalResource или действия DeleteLinkToExternalResource .
• Хранилище на уровне рабочей области включено или отключено. Найдите измененные значения в журнале действий с помощью действия UpdatedAdminFeatureSwitch . Имя элемента будет storageAccountAttachForWorkspaceAdminsEnabled. Параметр SwitchState будет иметь значение true или false.
• Настройки арендаторов для администраторов рабочих областей в Azure Log Analytics были изменены: эта настройка арендатора позволяет некоторым или всем администраторам рабочих областей интегрировать свою собственную учетную запись ADLS Gen2. Найдите измененные значения параметров клиента в журнале действий с помощью действия UpdatedAdminFeatureSwitch . Имя элемента будет LogAnalyticsAttachForWorkspaceAdmins.

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

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

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

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

Контролируйте службу Power BI

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

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

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

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