Стратегия внедрения Microsoft Fabric: системный надзор

Статья
11/24/2023

Примечание.

Эта статья является частью серии статей по внедрению Microsoft Fabric. Общие сведения о серии см . в схеме внедрения Microsoft Fabric.

Системный надзор ( также известный как администрирование Fabric) — это текущая, повседневная, административная деятельность. Это особенно касается:

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

Внимание

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

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

Администраторы Структуры

Роль администратора Fabric — это определенная роль в Microsoft 365, которая делегирует подмножество действий управления. Глобальные администраторы Microsoft 365 неявно являются администраторами Fabric. Администраторы Power Platform также неявно являются администраторами Fabric.

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

Роль с высоким уровнем привилегий

Роль администратора Fabric — это роль с высоким уровнем привилегий, так как:

Взаимодействие с пользователем: Параметры, управляемые администратором Fabric, оказывают значительное влияние на возможности пользователей и взаимодействие с пользователем. Дополнительные сведения см. в разделе "Управление параметрами клиента".
Полный доступ к безопасности: администраторы Структуры могут обновлять разрешения доступа для рабочих областей в клиенте. Результатом является то, что администратор может разрешить разрешение на просмотр или скачивание данных и отчетов по мере их представления. Дополнительные сведения см. в разделе "Управление параметрами клиента".
Доступ к личной рабочей области: администраторы Структуры могут получать доступ к содержимому и управлять личной рабочей областью любого пользователя.
Метаданные. Администраторы Структуры могут просматривать все метаданные клиента, включая все действия пользователей, происходящие на портале Fabric (описаны в разделе аудита и мониторинга ниже).

Внимание

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

Роли и обязанности

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

Совет

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

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

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

Экосистема структуры рабочих нагрузок широка и глубока. Структура интегрируется с другими системами и платформами. Время от времени необходимо будет работать с другими администраторами и ИТ-специалистами. Дополнительные сведения см. в статье "Совместная работа с другими администраторами".

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

Управление сервисным обслуживанием

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

Параметры клиента: управление включенными функциями и возможностями Power BI и пользователями в вашей организации.
Домены: группирование двух или нескольких рабочих областей с аналогичными характеристиками.
Рабочие области. Просмотр рабочих областей и управление ими в клиенте.
Коды внедрения: управление опубликованными отчетами в Интернете.
Визуальные элементы организации: регистрация и управление визуальными элементами организации.
Подключения Azure. Интеграция со службами Azure для предоставления дополнительных функций.

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

Пользовательские компьютеры и устройства

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

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

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

Архитектура

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

Архитектура данных

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

Существует множество решений по архитектуре данных. Часто COE участвует в проектировании и планировании архитектуры данных. Обычно администраторы также принимают участие, особенно при управлении базами данных или инфраструктурой Azure.

Внимание

Решения по архитектуре данных оказывают значительное влияние на внедрение, удовлетворенность пользователей и показатели успеха отдельных проектов.

Ниже приведены некоторые рекомендации по архитектуре данных, влияющие на внедрение:

Где Структура вписывается в всю архитектуру данных организации? Существуют ли другие компоненты, такие как корпоративное хранилище данных (EDW) или озеро данных, которое будет важно учитывать в планах?
Используется ли Структура для комплексной подготовки данных, моделирования данных и представления данных или используется ли Fabric только для некоторых этих возможностей?
Используются ли управляемые шаблоны самообслуживания , чтобы найти оптимальный баланс между возможностью повторного использования данных и гибкостью создателя отчетов?
Где пользователи будут использовать содержимое? Как правило, основными способами доставки содержимого являются портал Fabric, Сервер отчетов Power BI и внедренные в пользовательские приложения. Кроме того, Microsoft Teams — это удобная альтернатива для пользователей, которые тратят много времени в Teams.
Кто отвечает за управление и обслуживание архитектуры данных? Это централизованная команда или децентрализованная команда? Как COE представлен в этой команде? Требуются ли определенные наборы навыков?
Какие источники данных являются наиболее важными? Какие типы данных мы получим?
Какие варианты выбора режима подключения к семантической модели и режима хранения (например, Direct Lake, импорт, динамическое подключение, DirectQuery или составные платформы моделей) лучше всего подходят для вариантов использования?
В какой степени рекомендуется повторно использовать данные с помощью лейкхаусов, хранилищ и общих семантических моделей?
В какой степени можно повторно использовать логику подготовки данных и расширенную подготовку данных, поощряемую с помощью конвейеров данных, записных книжек и потоков данных?

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

Совет

Получите хорошую привычку завершить техническое доказательство концепции (POC), чтобы проверить предположения и идеи. Некоторые организации также называют их микропроектами , когда цель состоит в том, чтобы обеспечить небольшую единицу работы. Цель POC заключается в том, чтобы устранить неизвестные и уменьшить риск как можно раньше. POC не должен быть бросать работу, но она должна быть узкой в область. Обзоры рекомендаций, как описано в статье "Руководство и включение пользователей", являются еще одним полезным способом помочь создателям содержимого с важными архитектурными решениями.

Управление емкостью

Емкость включает функции и возможности для доставки решений аналитики в большом масштабе. Существует два типа лицензий организации Fabric: Premium на пользователя (PPU) и емкость. Существует несколько типов лицензий емкости. Тип лицензии на емкость определяет, какие рабочие нагрузки Fabric поддерживаются.

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

Неограниченное распространение содержимого Power BI для большого количества пользователей, доступных только для чтения. Использование содержимого пользователями с бесплатной лицензией Power BI доступно только в емкости Premium, а не PPU. Использование содержимого бесплатными пользователями также доступно с лицензией емкости F64 Fabric или более поздней.
Доступ к интерфейсам Fabric для создания комплексной аналитики.
Конвейеры развертывания для управления публикацией содержимого в рабочих областях разработки, тестирования и рабочей среды. Они настоятельно рекомендуется для критически важного содержимого для повышения стабильности выпуска.
Конечная точка XMLA, которая является стандартным протоколом для управления и публикации семантической модели или запроса семантической модели из любого средства, совместимого с XMLA.
Увеличение ограничений размера модели, включая поддержку крупной семантической модели .
Более частые обновления данных.
служба хранилища данных в определенной географической области, отличной от домашнего региона.

Приведенный выше список не является все инклюзивным. Полный список см. в разделе "Функции Power BI Premium".

Управление емкостью Fabric

Наблюдение за работоспособностью емкости Fabric является важным текущим действием для администраторов. Каждый номер SKU емкости включает набор ресурсов. Единицы емкости (CUS) используются для измерения вычислительных ресурсов для каждого номера SKU.

Внимание

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

Рекомендации по управлению емкостью Fabric:

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

Автомасштабирование

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

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

Децентрализованное управление емкостью

Администраторы емкости отвечают за назначение рабочих областей определенной емкости.

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

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

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

Приобретите узел емкости P3 в Microsoft 365. Он включает в себя 32 виртуальных ядер (виртуальные ядра).
Используйте 16 виртуальных ядер для создания первой емкости. Она будет использоваться командой продаж.
Используйте 8 виртуальных ядер для создания второй емкости. Она будет использоваться командой operations.
Используйте оставшиеся 8 виртуальных ядер для создания третьей емкости. Она будет поддерживать общее использование.

В предыдущем примере есть несколько преимуществ.

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

Однако в предыдущем примере тоже есть недостатки.

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

Примечание.

Ресурсы для Power BI Premium на емкость называются виртуальными ядрами. Однако емкость Fabric называет их единицами емкости (ЦС). Масштаб для ЦС и виртуальных ядер отличается для каждого номера SKU. Дополнительные сведения см. в документации по лицензированию Fabric.

Архитектура и управление шлюзом данных

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

Расположен в корпоративном центре обработки данных.
Настроено за брандмауэром.
В пределах виртуальной сети.
В виртуальной машине.

Существует три типа шлюзов.

Локальный шлюз данных (стандартный режим) — это служба шлюза, которая поддерживает подключения к зарегистрированным источникам данных для многих пользователей. Установки и обновления программного обеспечения шлюза устанавливаются на компьютере, управляемом клиентом.
Локальный шлюз данных (личный режим) — это служба шлюза, которая поддерживает только обновление данных. Этот режим шлюза обычно устанавливается на компьютере создателя содержимого. Он поддерживает только один пользователь. Он не поддерживает динамическое подключение или подключения DirectQuery.
Шлюз данных виртуальной сети — это управляемая корпорацией Майкрософт служба, которая поддерживает подключение для многих пользователей. В частности, он поддерживает подключение для семантических моделей и потоков данных, хранящихся в рабочих областях, назначенных емкости Premium или Premium на пользователя.

Совет

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

Децентрализованное управление шлюзами

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

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

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

Управляется децентрализованными владельцами данных:

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

Управляется централизованным владельцами данных (включая источники данных, которые широко используются в организации; управление централизованно для предотвращения повторяющихся источников данных):

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

Управляемое ИТ-службой:

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

Совет

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

Лицензии пользователей

Каждому пользователю требуется коммерческая лицензия, интегрированная с удостоверением Microsoft Entra. Лицензия пользователя может быть бесплатной, pro или Premium на пользователя (PPU).

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

Примечание.

Хотя каждому пользователю требуется лицензия, лицензия Pro или PPU требуется только для совместного использования содержимого Power BI. Пользователи с бесплатной лицензией могут создавать и совместно использовать содержимое Fabric, отличное от элементов Power BI.

Существует два подхода к приобретению подписок.

Централизованно: администратор выставления счетов Microsoft 365 приобретает подписку на Pro или PPU. Это наиболее распространенный способ управления подписками и назначения лицензий.
Децентрализованный: отдельные отделы покупают подписку с помощью самостоятельного приобретения.

Самостоятельное приобретение

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

Самостоятельное приобретение полезно для:

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

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

Централизованные процессы закупок выполняются в соответствии с нормативными требованиями, безопасностью и управлением.
Скидочные цены получаются через Соглашение Enterprise (EA).
Существующие процессы выполняются для обработки межкомпанийных сборов.
Существующие процессы применяются для обработки назначений лицензирования на основе групп.
Необходимые условия необходимы для получения лицензии, например утверждения, обоснования, обучения или требования политики управления.
Существует действительная необходимость, например требование нормативных требований, для тесного контроля доступа.

Пробные версии лицензий пользователей

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

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

Рассмотрите возможность отключения пробных версий только в том случае, если:

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

Совет

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

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

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

Анализ того, кто использует (и, больше до точки, а не использует) их выделенные лицензии Fabric и вносит необходимые корректировки. Использование структуры анализируется с помощью журнала действий.
Анализ стоимости емкости или уровня "Премиум" на пользователя. Помимо дополнительных функций, выполните анализ затрат и преимуществ, чтобы определить, является ли лицензирование емкости более экономичным, если существует большое количество потребителей.
Тщательно отслеживайте емкость Fabric и управляйте ими. Понимание шаблонов использования с течением времени позволит предсказать, когда приобрести больше емкости. Например, можно увеличить масштаб одной емкости от P1 до P2 или увеличить масштаб с одной емкости P1 до двух емкостей P1.
Если на уровне использования возникают случайные пики, рекомендуется использовать автомасштабирование с Fabric, чтобы убедиться, что взаимодействие с пользователем не прерывается. Автомасштабирование масштабирует ресурсы емкости в течение 24 часов, а затем масштабирует их до обычных уровней (если устойчивые действия отсутствуют). Управление затратами автомасштабирования путем ограничения максимального количества виртуальных ядер и (или) ограничений расходов, установленных в Azure. Благодаря модели ценообразования автомасштабирование лучше всего подходит для обработки случайных незапланированных увеличений использования.
Для источников данных Azure найдите их в том же регионе, что и клиент Fabric, когда это возможно. Это позволит избежать оплаты исходящего трафика Azure. Затраты на исходящие данные минимальны, но в большом масштабе могут быть значительными незапланированными затратами.

Защита от потери данных, защита информации и защита от потери данных

Безопасность, защита информации и защита от потери данных (DLP) являются совместными обязанностями среди всех создателей контента, потребителей и администраторов. Это не небольшая задача, так как есть конфиденциальная информация везде: персональные данные, данные клиентов или данные, созданные клиентом данные, защищенные сведения о работоспособности, интеллектуальная собственность, частная информация организации, просто назовите несколько. Правительственные, отраслевые и договорные правила могут оказать значительное влияние на руководящие принципы и политики управления , которые вы создаете, связанные с безопасностью.

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

Обязанности пользователя

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

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

Безопасность данных

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

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

Администратор istrator может помочь, следуя рекомендациям. Администратор istrators также могут вызывать проблемы, которые могут быть обнаружены при управлении рабочими областями, аудите действий пользователей или управлении учетными данными шлюза и пользователями. Существует также несколько параметров клиента, которые обычно ограничены, за исключением нескольких пользователей (например, возможность публикации в Интернете или возможность публикации приложений в всей организации).

Внешние гостевые пользователи

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

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

Защита информации и защита от потери данных

Fabric поддерживает возможности защиты информации и защиты от потери данных (DLP) следующим образом.

Information protection:Защита информации Microsoft Purview (прежнее название — Microsoft Information Protection) включает возможности для обнаружения, классификации и защиты данных. Ключевым принципом является то, что данные можно лучше защитить после классификации. Ключевой стандартный блок для классификации данных — метки конфиденциальности. Дополнительные сведения см. в статье "Защита информации" для планирования Power BI.
Защита от потери данных для Power BI: Защита от потери данных Microsoft Purview (прежнее название — Защита от потери данных Office 365) поддерживает политики защиты от потери данных для Power BI. Используя метки конфиденциальности или типы конфиденциальной информации, политики защиты от потери данных для Power BI помогают организации находить конфиденциальные семантические модели. Дополнительные сведения см. в разделе "Защита от потери данных" для планирования Power BI.
приложения Microsoft Defender для облака:Microsoft Defender для облака Приложения (ранее известные как Microsoft Cloud App Security) поддерживают политики, которые помогают защитить данные, включая элементы управления в режиме реального времени при взаимодействии с служба Power BI. Дополнительные сведения см. в разделе Defender для облака Приложения для планирования Power BI.

Место расположения данных

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

Ключи шифрования

Корпорация Майкрософт обрабатывает шифрование неактивных данных в центрах обработки данных Майкрософт с прозрачным шифрованием на стороне сервера и автоматическим поворотом сертификатов. Для клиентов с нормативными требованиями к управлению ключом шифрования Premium емкость Premium можно настроить для использования Azure Key Vault. Использование ключей, управляемых клиентом, также известных как перенос собственного ключа или BYOK, является меры предосторожности, чтобы гарантировать, что в случае ошибки человека оператором службы данные клиента не могут быть предоставлены.

Обратите внимание, что premium per User (PPU) поддерживает только BYOK, если он включен для всего клиента Fabric.

Аудит и мониторинг

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

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

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

Интерфейсы REST API

REST API Power BI и REST API Fabric предоставляют множество сведений о клиенте Fabric. Получение данных с помощью REST API должно играть важную роль в управлении реализацией Fabric и управлении ею. Дополнительные сведения о планировании использования REST API для аудита см. в разделе "Аудит на уровне клиента".

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

Действие	Ресурсы документации
Аудит действий пользователей	REST API для получения событий действий
Аудит рабочих областей, элементов и разрешений	Коллекция асинхронных метаданных, сканирующих REST API для получения инвентаризации клиентов
Аудит содержимого, доступного всей организации	REST API для проверка использования широко общих ссылок
Аудит параметров клиента	REST API для проверка параметров клиента
Публикация содержимого	REST API для развертывания элементов из конвейера развертывания или клонирования отчета в другую рабочую область
Управление содержимым	REST API для обновления семантической модели или владения семантической модели
Управление источниками данных шлюза	REST API для обновления учетных данных для источника данных шлюза
Экспорт содержимого	REST API для экспорта отчета
Создание рабочих областей	REST API для создания новой рабочей области
Управление разрешениями рабочей области	REST API для назначения разрешений пользователя рабочей области
Обновление имени или описания рабочей области	REST API для обновления атрибутов рабочей области
Восстановление рабочей области	REST API для восстановления удаленной рабочей области
Программное получение результата запроса из семантической модели	REST API для выполнения запроса DAX к семантической модели
Назначение рабочих областей емкости	REST API для назначения рабочих областей емкости
Программное изменение модели данных	API табличной объектной модели (TOM)
Внедрение содержимого Power BI в пользовательских приложениях	API клиента встроенной аналитики Power BI

Совет

Существует множество других REST API Power BI. Полный список см. в разделе "Использование REST API Power BI".

Планирование изменений

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

Внимание

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

Соображения и ключевые действия

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

Улучшение системного надзора:

Проверьте, кто может быть администратором Fabric: если это возможно, уменьшите число пользователей, которым предоставлена роль администратора Fabric, если это более нескольких пользователей.
Используйте PIM для случайных администраторов: если у вас есть пользователи, которые иногда нуждаются в правах администратора Fabric, рассмотрите возможность реализации управление привилегированными пользователями (PIM) в идентификаторе Microsoft Entra ID. Он предназначен для назначения разрешений роли jit-in-time, срок действия которого истекает через несколько часов.
Обучение администраторов. Проверьте состояние перекрестной подготовки и документации на месте для обработки обязанностей администрирования Fabric. Убедитесь, что пользователь резервного копирования обучен таким образом, чтобы обеспечить своевременное выполнение необходимых требований.

Улучшение управления службой Fabric:

Просмотрите параметры клиента. Просмотрите все параметры клиента, чтобы убедиться, что они согласованы с целями и политиками и параметрами управления данными. Проверьте, какие группы назначены для каждого параметра.
Задокументируйте параметры клиента: создайте документацию по параметрам клиента для внутреннего сообщества Fabric и опубликуйте его на централизованном портале. Включите группы, которые пользователь должен запросить, чтобы иметь возможность использовать функцию. Используйте REST API Get Tenant Параметры для повышения эффективности процесса и создания моментальных снимков параметров на регулярной основе.
Настройка ссылок справки get: при установке ресурсов пользователей, как описано в статье "Руководство и включение пользователей", обновите параметр клиента, чтобы настроить ссылки в меню "Получить справку". Он будет направлять пользователей в документацию, сообщество и справку.

Улучшено управление компьютерами и устройствами пользователей:

Создайте согласованный процесс подключения: просмотрите процесс подключения новых создателей контента. Определите, можно ли обрабатывать новые запросы на программное обеспечение, например Power BI Desktop, а также лицензии пользователей (Free, Pro или PPU). Это может упростить подключение, так как новые создатели контента не всегда будут знать, что запрашивать.
Обработка обновлений компьютера пользователей. Убедитесь, что автоматизированный процесс установлен для установки и обновления программного обеспечения, драйверов и параметров, чтобы гарантировать, что все пользователи имеют одну и ту же версию.

Планирование архитектуры данных:

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

Улучшение управления лицензиями пользователей:

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

Улучшение управления затратами:

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

Повышение безопасности и защиты данных:

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

Улучшение аудита и мониторинга:

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

Совет

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

Используйте ИНТЕРФЕЙСы REST API:

Планирование использования ИНТЕРФЕЙСов REST API. Рассмотрим, какие данные будут наиболее полезны для получения из REST API Power BI и ИНТЕРФЕЙСов REST API Fabric.
Провести подтверждение концепции: сделайте небольшое доказательство концепции для проверки потребностей данных, выбора технологий и разрешений.

Вопросы

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

Включены или отключены ли нетипические параметры администрирования? Например, вся организация может публиковаться в Интернете (мы настоятельно советуем ограничить эту функцию).
Соответствуют ли параметры и политики администрирования или препятствуют работе пользователей?
Существует ли процесс для критического определения новых параметров и принятия решения о том, как их задать? Кроме того, в качестве меры предосторожности устанавливаются только самые строгие параметры?
Используются ли группы безопасности Microsoft Entra для управления тем, кто может сделать что?
Имеют ли центральные команды видимость эффективных средств аудита и мониторинга ?
Показаны ли решения мониторинга о ресурсах данных, действиях пользователя или обоих?
Доступны ли средства аудита и мониторинга? Есть ли четкие пороговые значения и набор действий или отчеты мониторинга просто описывают то, что находится в пространстве данных?
Используется ли Azure Log Analytics (или планируется использовать) для подробного мониторинга емкостей Fabric? Являются ли потенциальные преимущества и затраты Azure Log Analytics понятны для принятия решений?
Используются ли метки конфиденциальности и политики защиты от потери данных? Являются ли потенциальные преимущества и стоимость этих четких для лиц, принимающих решения?
Знают ли администраторы текущее количество лицензий и затрат на лицензирование? Какая доля расходов на бизнес-аналитику переходит к емкости Fabric, а также к лицензиям Pro и PPU? Если организация использует только лицензии Pro для содержимого Power BI, может ли количество пользователей и шаблонов использования гарантировать экономичное переключение на емкость Power BI Premium или Fabric?

Уровни зрелости

Следующие уровни зрелости помогут оценить текущее состояние контроля системы Power BI.

Уровень	Состояние системного надзора
100: изначально	• Параметры клиента настраиваются независимо от одного или нескольких администраторов на основе их наилучшего решения. • Потребности архитектуры, такие как шлюзы и емкости, удовлетворяются по мере необходимости. Однако не существует стратегического плана. • Журналы действий структуры не используются или выборочно используются для тактических целей.
200: повторяемость	• Параметры клиента специально соответствуют установленным рекомендациям и политикам управления. Все параметры клиента регулярно проверяются. • Выбрано небольшое количество конкретных администраторов. Все администраторы имеют хорошее представление о том, что пользователи пытаются достичь в Fabric, поэтому они находятся в хорошей позиции для поддержки пользователей. • Четко определенный процесс существует для пользователей для запроса лицензий и программного обеспечения. Формы запросов просты для поиска пользователей. Задаются параметры самостоятельного приобретения. • Метки конфиденциальности настраиваются в Microsoft 365. Однако использование меток остается несогласованным. Преимущества защиты данных не хорошо понятны пользователям.
300: определено	• Параметры клиента полностью документированы на централизованном портале, чтобы пользователи ссылались, включая запрос доступа к правильным группам. • Существуют перекрестные учебные материалы и документация для администраторов для обеспечения непрерывности, стабильности и согласованности. • Метки конфиденциальности назначаются содержимому последовательно. Преимущества использования меток конфиденциальности для защиты данных понимаются пользователями. • Автоматизированный процесс выполняется для экспорта журнала действий Fabric и данных API в безопасное расположение для создания отчетов и аудита.
400: возможности	• Администратор istrator тесно сотрудничают с командами COE и управления, чтобы обеспечить надзор за Структурой. Баланс возможностей пользователей и управления успешно достигается. • Децентрализованное управление архитектурой данных (например, шлюзами или управлением емкостью) эффективно обрабатывается для балансировки гибкости и контроля. • Автоматические политики настраиваются и активно отслеживаются в приложениях Microsoft Defender для облака для предотвращения потери данных. • Журнал действий и данные API активно анализируются для мониторинга и аудита действий Fabric. Упреждающее действие выполняется на основе данных.
500: эффективность	• Администраторы Структуры тесно сотрудничают с COE активно оставаться в курсе. Записи блога и планы выпуска из группы продуктов Fabric часто проверяются, чтобы планировать предстоящие изменения. • Регулярный анализ управления затратами выполняется для обеспечения удовлетворения потребностей пользователей экономически эффективным способом. • REST API Fabric используется для регулярного получения значений параметров клиента. • Журнал действий и данные API активно используются для информирования и улучшения усилий по внедрению и управлению.

Дополнительные сведения о системе надзора и администрирования Fabric см. в следующих ресурсах.

В следующей статье серии стратегий внедрения Microsoft Fabric узнайте об эффективном управлении изменениями.

Стратегия внедрения Microsoft Fabric: системный надзор