Bagikan melalui


Peta jalan adopsi Microsoft Fabric: Pengawasan sistem

Catatan

Artikel ini membentuk bagian dari seri artikel peta jalan adopsi Microsoft Fabric. Untuk gambaran umum seri ini, lihat peta jalan adopsi Microsoft Fabric.

Pengawasan sistem—juga dikenal sebagai administrasi Fabric—adalah aktivitas administratif yang sedang berlangsung, sehari-hari. Ini secara khusus berkaitan dengan:

  • Tata kelola: Memberlakukan pedoman tata kelola dan kebijakan untuk mendukung skenario layanan mandiri dan data perusahaan dan kecerdasan bisnis (BI).
  • Pemberdayaan pengguna: Memfasilitasi dan mendukung proses dan sistem internal yang memberdayakan komunitas pengguna internal sejauh mungkin, sambil mematuhi peraturan dan persyaratan organisasi.
  • Adopsi: Memungkinkan adopsi fabric organisasi yang lebih luas dengan praktik tata kelola dan manajemen data yang efektif.

Penting

Tujuan budaya data organisasi Anda memberikan arahan untuk keputusan tata kelola Anda, yang pada gilirannya menentukan bagaimana aktivitas administrasi Fabric berlangsung dan oleh siapa.

Pengawasan sistem adalah topik yang luas dan mendalam. Tujuan artikel ini adalah memperkenalkan beberapa pertimbangan dan tindakan terpenting untuk membantu Anda menjadi sukses dengan tujuan adopsi organisasi Anda.

Administrator fabric

Peran administrator Fabric adalah peran yang ditentukan dalam Microsoft 365, yang mendelegasikan subset aktivitas manajemen. Administrator Global Microsoft 365 adalah administrator Fabric secara implisit. Administrator Power Platform juga secara implisit administrator Fabric.

Keputusan tata kelola utama adalah siapa yang akan ditetapkan sebagai administrator Fabric. Ini adalah peran terpusat yang memengaruhi seluruh penyewa Anda. Idealnya, ada dua hingga empat orang dalam organisasi yang mampu mengelola Fabric. Administrator Anda harus beroperasi dalam koordinasi erat dengan Center of Excellence (COE).

Peran hak istimewa tinggi

Peran administrator Fabric adalah peran hak istimewa yang tinggi karena:

  • Pengalaman pengguna: Pengaturan yang dikelola oleh administrator Fabric memiliki efek signifikan pada kemampuan pengguna dan pengalaman pengguna. Untuk informasi selengkapnya, lihat Mengatur pengaturan penyewa.
  • Akses keamanan penuh: Administrator Fabric dapat memperbarui izin akses untuk ruang kerja di penyewa. Hasilnya adalah administrator dapat mengizinkan izin untuk melihat atau mengunduh data dan laporan sesuai keinginan. Untuk informasi selengkapnya, lihat Mengatur pengaturan penyewa.
  • Akses ruang kerja pribadi: Administrator Fabric dapat mengakses konten dan mengatur ruang kerja pribadi pengguna mana pun.
  • Metadata: Administrator Fabric dapat melihat semua metadata penyewa, termasuk semua aktivitas pengguna yang terjadi di portal Fabric (dijelaskan di bagian Audit dan pemantauan di bawah).

Penting

Memiliki terlalu banyak administrator Fabric adalah risiko. Ini meningkatkan probabilitas manajemen penyewa yang tidak disetujui, tidak diinginkan, atau tidak konsisten.

Peran dan tanggung jawab

Jenis aktivitas yang akan dilakukan administrator setiap hari akan berbeda antar-organisasi. Yang penting, dan diberi prioritas dalam budaya data Anda, akan sangat memengaruhi apa yang dilakukan administrator untuk mendukung layanan mandiri yang dipimpin bisnis, layanan mandiri terkelola, dan data perusahaan dan skenario BI. Untuk mengetahui informasi selengkapnya, lihat artikel Kepemilikan dan manajemen konten.

Tip

Jenis orang terbaik untuk berfungsi sebagai administrator Fabric adalah orang yang memiliki pengetahuan yang cukup tentang alat dan beban kerja untuk memahami apa yang perlu dicapai pengguna layanan mandiri. Dengan pemahaman ini, administrator dapat menyeimbangkan pemberdayaan dan tata kelola pengguna.

Selain administrator Fabric, ada peran lain yang menggunakan istilah administrator. Tabel berikut ini menjelaskan peran yang umum dan digunakan secara teratur.

Peran Cakupan Keterangan
Administrator fabric Penyewa Mengelola pengaturan penyewa dan pengaturan lainnya di portal Fabric. Semua referensi umum kepada administrator dalam artikel ini merujuk ke jenis administrator ini.
Administrator kapasitas Satu kapasitas Mengelola ruang kerja dan beban kerja, dan memantau kesehatan kapasitas Fabric.
Administrator gateway data Satu gateway Mengelola konfigurasi sumber data gateway, kredensial, dan penetapan pengguna. Mungkin juga menangani pembaruan perangkat lunak gateway (atau berkolaborasi dengan tim infrastruktur pada pembaruan).
Administrator ruang kerja Satu ruang kerja Mengelola pengaturan dan akses ruang kerja.

Ekosistem beban kerja Fabric luas dan dalam. Ada banyak cara agar Fabric terintegrasi dengan sistem dan platform lain. Dari waktu ke waktu, Anda harus bekerja dengan administrator lain dan profesional TI. Untuk informasi selengkapnya, lihat Berkolaborasi dengan administrator lain.

Sisa artikel ini memberikan gambaran umum tentang aktivitas paling umum yang dilakukan administrator Fabric. Ini berfokus pada kegiatan yang penting untuk dilakukan secara efektif ketika mengambil pendekatan strategis untuk adopsi organisasi.

Manajemen layanan

Mengawasi penyewa adalah aspek penting untuk memastikan bahwa semua pengguna memiliki pengalaman yang baik dengan Power BI. Beberapa tanggung jawab tata kelola utama administrator Fabric meliputi:

  • Pengaturan penyewa: Mengontrol fitur dan kemampuan Power BI mana yang diaktifkan, dan pengguna mana di organisasi Anda.
  • Domain: Kelompokkan dua ruang kerja atau lebih yang memiliki karakteristik serupa.
  • Ruang kerja: Meninjau dan mengelola ruang kerja di penyewa.
  • Kode semat: Mengatur laporan mana yang telah diterbitkan secara publik di internet.
  • Visual organisasi: Mendaftarkan dan mengelola visual organisasi.
  • Koneksi Azure: Integrasikan dengan layanan Azure untuk menyediakan fungsionalitas tambahan.

Untuk informasi selengkapnya, lihat Administrasi penyewa.

Komputer dan perangkat pengguna

Adopsi Fabric tergantung langsung pada pembuat konten dan konsumen yang memiliki alat dan aplikasi yang mereka butuhkan. Berikut adalah beberapa pertanyaan penting yang perlu dipertimbangkan.

  • Bagaimana pengguna akan meminta akses ke alat baru? Apakah akses ke lisensi, data, dan pelatihan akan tersedia untuk membantu pengguna menggunakan alat secara efektif?
  • Bagaimana konsumen konten akan melihat konten yang telah diterbitkan oleh orang lain?
  • Bagaimana pembuat konten akan mengembangkan, mengelola, dan menerbitkan konten? Apa kriteria Anda untuk memutuskan alat dan aplikasi mana yang sesuai untuk kasus penggunaan mana?
  • Bagaimana Anda akan menginstal dan menyiapkan alat? Apakah itu termasuk prasyarat terkait dan komponen konektivitas data?
  • Bagaimana Anda akan mengelola pembaruan berkelanjutan untuk alat dan aplikasi?

Untuk informasi selengkapnya, lihat Alat dan perangkat pengguna.

Sistem

Dalam konteks Fabric, arsitektur berkaitan dengan arsitektur data, manajemen kapasitas, serta arsitektur dan manajemen gateway data.

Arsitektur data

Arsitektur data mengacu pada prinsip, praktik, dan metodologi yang mengatur dan menentukan data apa yang dikumpulkan, dan bagaimana data tersebut diserap, disimpan, dikelola, diintegrasikan, dimodelkan, dan digunakan.

Ada banyak keputusan arsitektur data yang harus dibuat. COE sering terlibat dalam desain dan perencanaan arsitektur data. Umum bagi administrator untuk terlibat juga, terutama ketika mereka mengelola database atau infrastruktur Azure.

Penting

Keputusan arsitektur data memiliki dampak signifikan pada adopsi Fabric, kepuasan pengguna, dan tingkat keberhasilan proyek individu.

Beberapa pertimbangan arsitektur data yang memengaruhi adopsi meliputi:

  • Di mana Fabric cocok dengan seluruh arsitektur data organisasi? Apakah ada komponen lain yang ada seperti gudang data perusahaan (EDW) atau data lake yang akan penting untuk diperhitungkan dalam rencana?
  • Apakah Fabric digunakan secara end-to-end untuk persiapan data, pemodelan data, dan presentasi data atau fabric hanya digunakan untuk beberapa kemampuan tersebut?
  • Apakah pola layanan mandiri terkelola diikuti untuk menemukan keseimbangan terbaik antara penggunaan kembali data dan fleksibilitas pembuat laporan?
  • Di mana pengguna akan menggunakan konten? Umumnya, tiga cara utama untuk mengirimkan konten adalah: portal Fabric, Server Laporan Power BI, dan disematkan dalam aplikasi kustom. Selain itu, Microsoft Teams adalah alternatif yang nyaman bagi pengguna yang menghabiskan banyak waktu di Teams.
  • Siapa bertanggung jawab untuk mengelola dan memelihara arsitektur data? Apakah itu tim terpusat, atau tim terdesentralisasi? Bagaimana COE diwakili dalam tim ini? Apakah set keterampilan tertentu diperlukan?
  • Sumber data apa yang paling penting? Jenis data apa yang akan kita peroleh?
  • Mode konektivitas model semantik dan pilihan mode penyimpanan apa (misalnya, Direct Lake, impor, koneksi langsung, DirectQuery, atau kerangka kerja model komposit) yang paling cocok untuk kasus penggunaan?
  • Sejauh mana penggunaan kembali data didorong menggunakan lakehouse, gudang, dan model semantik bersama?
  • Sejauh mana penggunaan kembali logika persiapan data dan persiapan data tingkat lanjut yang didorong dengan menggunakan alur data, buku catatan, dan aliran data?

Penting bagi administrator untuk menyadari sepenuhnya kemampuan teknis Fabric—serta kebutuhan dan tujuan pemangku kepentingan mereka—sebelum mereka membuat keputusan arsitektur.

Tip

Dapatkan kebiasaan yang baik untuk menyelesaikan bukti konsep teknis (POC) untuk menguji asumsi dan ide. Beberapa organisasi juga menyebut mereka proyek mikro ketika tujuannya adalah untuk memberikan unit kerja kecil. Tujuan dari POC adalah untuk mengatasi hal-hal yang tidak diketahui dan mengurangi risiko sedini mungkin. POC tidak harus dilemparkan ke tempat kerja, tetapi harus sempit dalam cakupan. Ulasan praktik terbaik, seperti yang dijelaskan dalam artikel Pendampingan dan pengaktifan pengguna, adalah cara lain yang berguna untuk membantu pembuat konten dengan keputusan arsitektur penting.

Manajemen kapasitas

Kapasitas mencakup fitur dan kemampuan untuk memberikan solusi analitik dalam skala besar. Ada dua jenis lisensi organisasi Fabric: Premium per Pengguna (PPU) dan kapasitas. Ada beberapa jenis lisensi kapasitas. Jenis lisensi kapasitas menentukan beban kerja Fabric mana yang didukung.

Penting

Terkadang artikel ini mengacu pada Power BI Premium atau langganan kapasitasnya (SKU P). Ketahuilah bahwa Microsoft saat ini mengonsolidasikan opsi pembelian dan menghentikan SKU Power BI Premium per kapasitas. Pelanggan baru dan yang sudah ada harus mempertimbangkan untuk membeli langganan kapasitas Fabric (F SKU) sebagai gantinya.

Untuk informasi selengkapnya, lihat Pembaruan penting yang masuk ke lisensi Power BI Premium dan Tanya Jawab Umum Power BI Premium.

Penggunaan kapasitas dapat memainkan peran penting dalam strategi Anda untuk membuat, mengelola, menerbitkan, dan mendistribusikan konten. Beberapa alasan utama untuk berinvestasi dalam kapasitas meliputi:

  • Distribusi konten Power BI tak terbatas ke sejumlah besar pengguna baca-saja. Konsumsi konten oleh pengguna dengan lisensi Power BI gratis hanya tersedia dalam kapasitas Premium, bukan PPU. Konsumsi konten oleh pengguna gratis juga tersedia dengan lisensi kapasitas F64 Fabric atau yang lebih tinggi.
  • Akses ke pengalaman Fabric untuk memproduksi analitik end-to-end.
  • Alur penyebaran untuk mengelola publikasi konten ke ruang kerja pengembangan, pengujian, dan produksi. Mereka sangat disarankan untuk konten penting untuk meningkatkan stabilitas rilis.
  • Titik akhir XMLA, yang merupakan protokol standar industri untuk mengelola dan menerbitkan model semantik, atau mengkueri model semantik dari alat yang mematuhi XMLA apa pun.
  • Peningkatan batas ukuran model, termasuk dukungan model semantik besar.
  • Penyegaran data yang lebih sering.
  • Penyimpanan data di area geografis tertentu yang berbeda dari wilayah asal.

Daftar di atas tidak all-inclusive. Untuk daftar lengkapnya, lihat Fitur Power BI Premium.

Mengelola kapasitas Fabric

Mengawasi kesehatan kapasitas Fabric adalah aktivitas berkelanjutan yang penting bagi administrator. Setiap SKU kapasitas mencakup sekumpulan sumber daya. Unit kapasitas (CUs) digunakan untuk mengukur sumber daya komputasi untuk setiap SKU.

Perhatian

Kurangnya manajemen, dan secara konsisten melebihi batas sumber daya kapasitas Anda sering kali dapat mengakibatkan tantangan performa dan tantangan pengalaman pengguna. Kedua tantangan tersebut, jika tidak dikelola dengan benar, dapat memberikan dampak negatif pada upaya adopsi.

Saran untuk mengelola kapasitas Fabric:

  • Tentukan siapa yang bertanggung jawab untuk mengelola kapasitas. Konfirmasikan peran dan tanggung jawab sehingga jelas tindakan apa yang akan diambil, mengapa, kapan, dan oleh siapa.
  • Buat serangkaian kriteria tertentu untuk konten yang akan diterbitkan ke kapasitas. Ini sangat relevan ketika satu kapasitas digunakan oleh beberapa unit bisnis karena potensi ada untuk mengganggu pengguna lain jika kapasitas tidak dikelola dengan baik. Pertimbangkan untuk memerlukan tinjauan praktik terbaik (seperti ukuran model semantik yang wajar dan perhitungan yang efisien) sebelum menerbitkan konten baru ke kapasitas produksi.
  • Gunakan aplikasi metrik kapasitas Fabric secara teratur untuk memahami pemanfaatan dan pola sumber daya untuk kapasitas. Hal paling penting, cari pola penggunaan berlebihan yang konsisten, yang akan berkontribusi pada gangguan pengguna. Analisis pola penggunaan juga harus membuat Anda menyadari jika kapasitas kurang digunakan, menunjukkan lebih banyak nilai yang dapat diperoleh dari investasi.
  • Atur pengaturan penyewa sehingga Fabric memberi tahu Anda jika kapasitas menjadi kelebihan beban, atau jika terjadi pemadaman atau insiden.

Skala Otomatis

Skala otomatis dimaksudkan untuk menangani ledakan sesekali atau tidak terduga dalam tingkat penggunaan kapasitas. Skala otomatis dapat merespons ledakan ini dengan secara otomatis meningkatkan sumber daya CPU untuk mendukung peningkatan beban kerja.

Peningkatan skala otomatis mengurangi risiko performa dan tantangan pengalaman pengguna dengan imbalan dampak finansial. Jika kapasitas tidak dikelola dengan baik, skala otomatis mungkin memicu lebih sering dari yang diharapkan. Dalam hal ini, aplikasi metrik dapat membantu Anda menentukan masalah yang mendasar dan melakukan perencanaan kapasitas.

Manajemen kapasitas terdesentralisasi

Administrator kapasitas bertanggung jawab untuk menetapkan ruang kerja ke kapasitas tertentu.

Ketahuilah bahwa administrator ruang kerja juga dapat menetapkan ruang kerja ke PPU jika administrator ruang kerja memiliki lisensi PPU. Namun, akan mengharuskan semua pengguna ruang kerja lain juga harus memiliki lisensi PPU untuk berkolaborasi, atau menampilkan konten Power BI di ruang kerja. Beban kerja Fabric lainnya tidak dapat disertakan dalam ruang kerja yang ditetapkan ke PPU.

Dimungkinkan untuk menyiapkan beberapa kapasitas untuk memfasilitasi manajemen terdesentralisasi oleh unit bisnis yang berbeda. Mendesentralisasi manajemen aspek tertentu dari Fabric adalah cara yang bagus untuk menyeimbangkan kelincahan dan kontrol.

Berikut adalah contoh yang menjelaskan salah satu cara Anda dapat mengelola kapasitas Anda.

  • Beli node kapasitas P3 di Microsoft 365. Ini termasuk 32 inti virtual (v-core).
  • Gunakan 16 v-core untuk membuat kapasitas pertama. Ini akan digunakan oleh tim Penjualan.
  • Gunakan 8 v-core untuk membuat kapasitas kedua. Ini akan digunakan oleh tim Operasi.
  • Gunakan 8 v-core yang tersisa untuk membuat kapasitas ketiga. Ini akan mendukung penggunaan umum.

Contoh sebelumnya memiliki beberapa keuntungan.

  • Administrator kapasitas terpisah dapat disiapkan untuk setiap kapasitas. Oleh karena itu, ini memfasilitasi situasi manajemen terdesentralisasi.
  • Jika kapasitas tidak dikelola dengan baik, efeknya terbatas pada kapasitas tersebut saja. Kapasitas lainnya tidak terpengaruh.
  • Penagihan dan penagihan balik ke unit bisnis lain sangat mudah.
  • Ruang kerja yang berbeda dapat dengan mudah ditetapkan ke kapasitas terpisah.

Namun, contoh sebelumnya juga memiliki kerugian.

  • Batas per kapasitas lebih rendah. Ukuran memori maksimum yang diizinkan untuk model semantik bukan seluruh ukuran simpul kapasitas P3 yang dibeli. Sebaliknya, ini adalah ukuran kapasitas yang ditetapkan di mana model semantik dihosting.
  • Kemungkinan besar salah satu kapasitas yang lebih kecil perlu ditingkatkan pada beberapa titik waktu.
  • Ada lebih banyak kapasitas untuk dikelola di penyewa.

Catatan

Sumber daya untuk Power BI Premium per Kapasitas disebut sebagai v-core. Namun, kapasitas Fabric menyebutnya sebagai unit kapasitas (CUs). Skala untuk CUs dan v-core berbeda untuk setiap SKU. Untuk informasi selengkapnya, lihat dokumentasi lisensi Fabric.

Arsitektur dan manajemen gateway data

Gateway data memfasilitasi transfer data yang aman dan efisien antara sumber data organisasi dan layanan Fabric. Gateway data diperlukan untuk konektivitas data ke layanan lokal atau cloud saat sumber data:

  • Terletak di dalam pusat data perusahaan.
  • Dikonfigurasi di belakang firewall.
  • Dalam jaringan virtual.
  • Dalam mesin virtual.

Ada tiga jenis gateway.

  • Gateway data lokal (mode standar) adalah layanan gateway yang mendukung koneksi ke sumber data terdaftar untuk digunakan banyak pengguna. Penginstalan dan pembaruan perangkat lunak gateway diinstal pada komputer yang dikelola oleh pelanggan.
  • Gateway data lokal (mode pribadi) adalah layanan gateway yang hanya mendukung refresh data. Mode gateway ini biasanya diinstal pada PC pembuat konten. Mode ini hanya mendukung penggunaan oleh satu pengguna. Ini tidak mendukung koneksi langsung atau koneksi DirectQuery.
  • Gateway data jaringan virtual adalah layanan terkelola Microsoft yang mendukung konektivitas untuk banyak pengguna. Secara khusus, ini mendukung konektivitas untuk model semantik dan aliran data yang disimpan di ruang kerja yang ditetapkan ke kapasitas Premium atau Premium Per Pengguna.

Tip

Keputusan siapa yang dapat menginstal perangkat lunak gateway adalah keputusan tata kelola. Untuk sebagian besar organisasi, penggunaan gateway data dalam mode standar, atau gateway data jaringan virtual, harus sangat didorong. Gateway data jauh lebih dapat diskalakan, dikelola, dan dapat diaudit daripada gateway data dalam mode pribadi.

Manajemen gateway terdesentralisasi

Gateway data lokal (mode standar) dan Gateway data jaringan virtual mendukung jenis sumber data tertentu yang dapat didaftarkan, bersama dengan detail koneksi dan bagaimana kredensial disimpan. Pengguna dapat diberikan izin untuk menggunakan sumber data gateway sehingga mereka dapat menjadwalkan refresh atau menjalankan kueri DirectQuery.

Aspek tertentu dari manajemen gateway dapat dilakukan secara efektif secara terdesentralisasi untuk menyeimbangkan kelincahan dan kontrol. Misalnya, grup Operasi mungkin memiliki gateway yang didedikasikan untuk tim pembuat konten layanan mandiri dan pemilik datanya.

Manajemen gateway terdesentralisasi berfungsi paling baik ketika itu adalah upaya bersama sebagai berikut.

Dikelola oleh pemilik data terdesentralisasi:

Dikelola oleh pemilik data terpusat (termasuk sumber data yang digunakan secara luas di seluruh organisasi; manajemen dipusatkan untuk menghindari sumber data duplikat):

Dikelola oleh TI:

  • Pembaruan perangkat lunak gateway (pembaruan gateway biasanya dirilis setiap bulan).
  • Penginstalan driver dan konektor kustom (yang sama yang diinstal DI komputer pengguna).
  • Manajemen kluster gateway (jumlah komputer di kluster gateway untuk ketersediaan tinggi, pemulihan bencana, dan untuk menghilangkan satu titik kegagalan yang dapat menyebabkan gangguan pengguna yang signifikan).
  • Manajemen server (misalnya, sistem operasi, RAM, CPU, atau konektivitas jaringan).
  • Manajemen dan pencadangan kunci enkripsi gateway.
  • Pemantauan log gateway untuk menilai kapan peningkatan atau peluasan skala diperlukan.
  • Pemberitahuan waktu henti atau sumber daya rendah persisten pada komputer gateway.

Tip

Memungkinkan tim terdesentralisasi untuk mengelola aspek gateway tertentu berarti memungkinkan mereka untuk dapat bergerak lebih cepat juga. Tradeoff manajemen gateway terdesentralisasi berarti menjalankan lebih banyak server gateway sehingga masing-masing dapat didedikasikan untuk area organisasi tertentu. Jika manajemen gateway ditangani sepenuhnya oleh TI, proses yang baik untuk menangani permintaan dengan cepat guna menambahkan sumber data dan menerapkan pembaruan pengguna menjadi hal yang sangat penting.

Lisensi pengguna

Setiap pengguna memerlukan lisensi komersial, yang terintegrasi dengan identitas Microsoft Entra. Lisensi pengguna bisa Gratis, Pro, atau Premium Per Pengguna (PPU).

Lisensi pengguna diperoleh melalui langganan, yang mengotorisasi sejumlah lisensi tertentu dengan tanggal mulai dan berakhir.

Catatan

Meskipun setiap pengguna memerlukan lisensi, lisensi Pro atau PPU hanya diperlukan untuk berbagi konten Power BI. Pengguna dengan lisensi gratis dapat membuat dan berbagi konten Fabric selain item Power BI.

Ada dua pendekatan untuk mendapatkan langganan.

  • Terpusat: Administrator penagihan Microsoft 365 membeli langganan untuk Pro atau PPU. Ini adalah cara paling umum untuk mengelola langganan dan menetapkan lisensi.
  • Terdesentralisasi: Departemen individu membeli langganan melalui pembelian layanan mandiri.

Pembelian layanan mandiri

Keputusan tata kelola penting berkaitan dengan sejauh mana pembelian layanan mandiri akan diizinkan atau didorong.

Pembelian layanan mandiri berguna untuk:

  • Organisasi yang lebih besar dengan unit bisnis terdesentralisasi yang memiliki otoritas pembelian dan ingin menangani pembayaran langsung dengan kartu kredit.
  • Organisasi yang berniat untuk mempermudah pembelian langganan dengan komitmen bulanan.

Pertimbangkan untuk menonaktifkan pembelian layanan mandiri saat:

  • Proses pengadaan terpusat dilakukan untuk memenuhi persyaratan peraturan, keamanan, dan tata kelola.
  • Harga diskon diperoleh melalui Perjanjian Enterprise (EA).
  • Proses yang ada tersedia untuk menangani penagihan balik antarperusahaan.
  • Proses yang ada tersedia untuk menangani penetapan lisensi berbasis grup.
  • Prasyarat diperlukan untuk mendapatkan lisensi, seperti persetujuan, pembenaran, pelatihan, atau persyaratan kebijakan tata kelola.
  • Ada kebutuhan yang valid, seperti persyaratan peraturan, untuk mengontrol akses dengan cerah.

Uji coba lisensi pengguna

Keputusan tata kelola penting lainnya adalah apakah uji coba lisensi pengguna diizinkan. Secara default, uji coba akan diaktifkan. Itu berarti ketika konten dibagikan dengan kolega, jika penerima tidak memiliki lisensi Pro atau PPU, mereka akan diminta untuk memulai uji coba untuk melihat konten (jika konten tidak berada di dalam ruang kerja yang didukung oleh kapasitas). Pengalaman uji coba dimaksudkan untuk menjadi kenyamanan yang memungkinkan pengguna untuk melanjutkan alur kerja normal mereka.

Umumnya, menonaktifkan uji coba tidak disarankan. Ini dapat mendorong pengguna untuk mencari solusi, mungkin dengan mengekspor data atau bekerja di luar alat dan proses yang didukung.

Pertimbangkan untuk menonaktifkan uji coba hanya saat:

  • Ada kekhawatiran biaya serius yang akan membuatnya tidak mungkin memberikan lisensi penuh pada akhir periode percobaan.
  • Prasyarat diperlukan untuk mendapatkan lisensi (seperti persetujuan, pembenaran, atau persyaratan pelatihan). Tidak cukup untuk memenuhi persyaratan ini selama periode percobaan.
  • Ada kebutuhan yang valid, seperti persyaratan peraturan, untuk mengontrol akses ke layanan Fabric secara dekat.

Tip

Jangan memperkenalkan terlalu banyak hambatan untuk mendapatkan lisensi Fabric. Pengguna yang perlu menyelesaikan pekerjaan akan menemukan cara, dan cara itu mungkin melibatkan solusi yang tidak ideal. Misalnya, tanpa lisensi untuk menggunakan Fabric, orang mungkin terlalu mengandalkan berbagi file pada sistem file atau melalui email ketika pendekatan yang jauh lebih baik tersedia.

Cost management

Mengelola dan mengoptimalkan biaya layanan cloud, seperti Fabric, adalah aktivitas penting. Berikut adalah beberapa aktivitas yang dapat Anda pertimbangkan.

  • Analisis siapa yang menggunakan—dan, lebih ke titik, tidak menggunakan—lisensi Fabric yang dialokasikan dan membuat penyesuaian yang diperlukan. Penggunaan fabric dianalisis menggunakan log aktivitas.
  • Analisis efektivitas biaya kapasitas atau Premium Per Pengguna. Selain fitur tambahan, lakukan analisis biaya/manfaat untuk menentukan apakah lisensi kapasitas lebih hemat biaya ketika ada sejumlah besar konsumen.
  • Pantau dan kelola kapasitas Fabric dengan hati-hati. Memahami pola penggunaan dari waktu ke waktu akan memungkinkan Anda memprediksi kapan harus membeli lebih banyak kapasitas. Misalnya, Anda dapat memilih untuk meningkatkan kapasitas tunggal dari P1 ke P2, atau meluaskan skala dari satu kapasitas P1 menjadi dua kapasitas P1.
  • Jika ada lonjakan sesekali dalam tingkat penggunaan, penggunaan skala otomatis dengan Fabric disarankan untuk memastikan pengalaman pengguna tidak terganggu. Skala otomatis akan meningkatkan sumber daya kapasitas selama 24 jam, lalu menurunkan skalanya kembali ke tingkat normal (jika aktivitas berkelanjutan tidak ada). Kelola biaya skala otomatis dengan membatasi jumlah maksimum v-core, dan/atau dengan batas pengeluaran yang ditetapkan di Azure. Dari segi model harga, skala otomatis paling cocok untuk menangani peningkatan penggunaan yang terkadang tidak direncana.
  • Untuk sumber data Azure, temukan di wilayah yang sama dengan penyewa Fabric Anda jika memungkinkan. Ini akan menghindari dikenakan biaya keluar Azure. Biaya keluar data minimal, tetapi dalam skala besar dapat menambah biaya yang tidak diencana yang cukup besar.

Keamanan, perlindungan informasi, dan pencegahan kehilangan data

Keamanan, perlindungan informasi, dan pencegahan kehilangan data (DLP) adalah tanggung jawab bersama di antara semua pembuat konten, konsumen, dan administrator. Itu bukan tugas kecil karena ada informasi sensitif di mana-mana: data pribadi, data pelanggan, atau data yang ditulis pelanggan, informasi kesehatan yang dilindungi, kekayaan intelektual, informasi organisasi kepemilikan, hanya untuk beberapa nama. Peraturan pemerintah, industri, dan kontraktual dapat berdampak signifikan pada pedoman tata kelola dan kebijakan yang Anda buat terkait keamanan.

Laporan resmi keamanan Power BI adalah sumber daya yang sangat baik untuk memahami luasnya pertimbangan, termasuk aspek yang dikelola Microsoft. Bagian ini akan memperkenalkan beberapa topik yang bertanggung jawab pelanggan untuk mengelola.

Tanggung jawab pengguna

Beberapa organisasi meminta pengguna Fabric untuk menerima pengakuan pengguna layanan mandiri. Ini adalah dokumen yang menjelaskan tanggung jawab dan harapan pengguna untuk melindungi data organisasi.

Salah satu cara untuk mengotomatiskan implementasinya adalah dengan kebijakan ketentuan penggunaan Microsoft Entra. Pengguna diharuskan untuk melihat dan menyetujui kebijakan sebelum mereka diizinkan untuk mengunjungi portal Fabric untuk pertama kalinya. Anda juga dapat mengharuskannya untuk diakui secara berulang, seperti perpanjangan tahunan.

Keamanan data

Dalam model tanggung jawab bersama cloud, mengamankan data selalu menjadi tanggung jawab pelanggan. Dengan platform data layanan mandiri, pembuat konten layanan mandiri memiliki tanggung jawab untuk mengamankan konten yang dibagikan dengan kolega dengan benar.

COE harus memberikan dokumentasi dan pelatihan apabila relevan untuk membantu pembuat konten dengan praktik terbaik (terutama situasi untuk menangani data yang sangat sensitif).

Administrator dapat membantu dengan mengikuti praktik terbaik itu sendiri. Administrator juga dapat menimbulkan kekhawatiran ketika mereka melihat masalah yang dapat ditemukan saat mengelola ruang kerja, mengaudit aktivitas pengguna, atau mengelola kredensial gateway dan pengguna. Ada juga beberapa pengaturan penyewa yang biasanya dibatasi kecuali untuk beberapa pengguna (misalnya, kemampuan untuk menerbitkan ke web atau kemampuan untuk menerbitkan aplikasi ke seluruh organisasi).

Pengguna tamu eksternal

Pengguna eksternal—seperti mitra, pelanggan, vendor, dan konsultan—adalah kejadian umum bagi beberapa organisasi, dan jarang terjadi bagi orang lain. Cara Anda menangani pengguna eksternal adalah keputusan tata kelola.

Akses pengguna eksternal dikontrol oleh pengaturan penyewa dan pengaturan ID Microsoft Entra tertentu. Untuk detail pertimbangan pengguna eksternal, tinjau laporan resmi Distribusikan konten Power BI ke pengguna tamu eksternal menggunakan whitepaper Microsoft Entra B2B .

Perlindungan informasi dan pencegahan kehilangan data

Fabric mendukung kemampuan untuk perlindungan informasi dan pencegahan kehilangan data (DLP) dengan cara berikut.

  • Perlindungan informasi:Perlindungan Informasi Microsoft Purview (sebelumnya dikenal sebagai Perlindungan Informasi Microsoft) mencakup kemampuan untuk menemukan, mengklasifikasikan, dan melindungi data. Prinsip utamanya adalah bahwa data dapat dilindungi dengan lebih baik setelah diklasifikasikan. Blok penyusun kunci untuk mengklasifikasikan data adalah label sensitivitas. Untuk informasi selengkapnya, lihat Perlindungan informasi untuk perencanaan Power BI.
  • Pencegahan kehilangan data untuk Power BI: Pencegahan Kehilangan Data Microsoft Purview (sebelumnya dikenal sebagai Pencegahan Kehilangan Data Office 365) mendukung kebijakan DLP untuk Power BI. Dengan menggunakan label sensitivitas atau jenis informasi sensitif, kebijakan DLP untuk Power BI membantu organisasi menemukan model semantik sensitif. Untuk informasi selengkapnya, lihat Pencegahan kehilangan data untuk perencanaan Power BI.
  • Aplikasi Microsoft Defender untuk Cloud:Microsoft Defender untuk Cloud Apps (sebelumnya dikenal sebagai Microsoft Cloud App Security) mendukung kebijakan yang membantu melindungi data, termasuk kontrol real time saat pengguna berinteraksi dengan layanan Power BI. Untuk informasi selengkapnya, lihat Defender untuk Cloud Aplikasi untuk perencanaan Power BI.

Residensi data

Untuk organisasi dengan persyaratan untuk menyimpan data dalam wilayah geografis, kapasitas Fabric dapat diatur untuk wilayah tertentu yang berbeda dari wilayah asal penyewa Fabric.

Kunci enkripsi

Microsoft menangani enkripsi data tidak aktif di pusat data Microsoft dengan enkripsi sisi server transparan dan rotasi otomatis sertifikat. Bagi pelanggan dengan persyaratan peraturan untuk mengelola kunci enkripsi Premium itu sendiri, kapasitas Premium dapat dikonfigurasi untuk menggunakan Azure Key Vault. Menggunakan kunci yang dikelola pelanggan—juga dikenal sebagai bring-your-own-key atau BYOK—adalah tindakan pencegahan untuk memastikan bahwa, jika terjadi kesalahan manusia oleh operator layanan, data pelanggan tidak dapat diekspos.

Ketahuilah bahwa Premium Per User (PPU) hanya mendukung BYOK saat diaktifkan untuk seluruh penyewa Fabric.

Audit dan Pemantauan

Sangat penting bagi Anda untuk menggunakan data audit untuk menganalisis upaya adopsi, memahami pola penggunaan, mendidik pengguna, mendukung pengguna, mengurangi risiko, meningkatkan kepatuhan, mengelola biaya lisensi, dan memantau performa. Untuk informasi selengkapnya tentang mengapa mengaudit data Anda sangat berharga, lihat Ringkasan audit dan pemantauan.

Ada berbagai cara untuk mendekati audit dan pemantauan tergantung pada peran dan tujuan Anda. Artikel berikut menjelaskan berbagai pertimbangan dan kegiatan perencanaan.

  • Audit tingkat laporan: Teknik yang dapat digunakan pembuat laporan untuk memahami pengguna mana yang menggunakan laporan yang mereka buat, terbitkan, dan bagikan.
  • Audit tingkat data: Metode yang dapat digunakan pembuat data untuk melacak performa dan pola penggunaan aset data yang mereka buat, terbitkan, dan bagikan.
  • Audit tingkat penyewa: Keputusan utama dan tindakan yang dapat diambil administrator untuk membuat solusi audit end-to-end.
  • Pemantauan tingkat penyewa: Tindakan taktis yang dapat dilakukan administrator untuk memantau layanan Power BI, termasuk pembaruan dan pengumuman.

REST API

REST API Power BI dan FABRIC REST API menyediakan banyak informasi tentang penyewa Fabric Anda. Mengambil data dengan menggunakan REST API harus memainkan peran penting dalam mengelola dan mengatur implementasi Fabric. Untuk informasi selengkapnya tentang perencanaan penggunaan REST API untuk audit, lihat Audit tingkat penyewa.

Anda dapat mengambil data audit untuk membangun solusi audit, mengelola konten secara terprogram, atau meningkatkan efisiensi tindakan rutin. Tabel berikut menyajikan beberapa tindakan yang bisa Anda lakukan dengan REST API.

Perbuatan Sumber daya dokumentasi
Mengaudit aktivitas pengguna REST API untuk mendapatkan peristiwa aktivitas
Mengaudit ruang kerja, item, dan izin Kumpulan API REST pemindaian metadata asinkron untuk mendapatkan inventarisasi penyewa
Mengaudit konten yang dibagikan ke seluruh organisasi REST API untuk memeriksa penggunaan tautan yang dibagikan secara luas
Mengaudit pengaturan penyewa REST API untuk memeriksa pengaturan penyewa
Terbitkan konten REST API untuk menyebarkan item dari alur penyebaran atau mengkloning laporan ke ruang kerja lain
Mengelola konten REST API untuk me-refresh model semantik atau mengambil alih kepemilikan model semantik
Mengelola sumber data gateway REST API untuk memperbarui kredensial untuk sumber data gateway
Ekspor konten REST API untuk mengekspor laporan
Membuat ruang kerja REST API untuk membuat ruang kerja baru
Mengelola izin ruang kerja REST API untuk menetapkan izin pengguna ke ruang kerja
Memperbarui nama atau deskripsi ruang kerja REST API untuk memperbarui atribut ruang kerja
Memulihkan ruang kerja REST API untuk memulihkan ruang kerja yang dihapus
Mengambil hasil kueri secara terprogram dari model semantik REST API untuk menjalankan kueri DAX terhadap model semantik
Menetapkan ruang kerja ke kapasitas REST API untuk menetapkan ruang kerja ke kapasitas
Mengubah model data secara terprogram API Model Objek Tabular (TOM)
Menyematkan konten Power BI dalam aplikasi kustom API klien analitik power BI yang disematkan

Tip

Ada banyak REST API Power BI lainnya. Untuk daftar lengkapnya, lihat Menggunakan REST API Power BI.

Perencanaan perubahan

Setiap bulan, Microsoft merilis fitur dan kemampuan Fabric baru. Agar efektif, sangat penting bahwa semua orang yang terlibat dengan pengawasan sistem tetap terkini. Untuk informasi selengkapnya, lihat Pemantauan tingkat penyewa.

Penting

Jangan meremehkan pentingnya tetap terkini. Jika Anda mendapatkan beberapa bulan di belakang pada pengumuman, mungkin sulit untuk mengelola Fabric dengan benar dan mendukung pengguna Anda.

Pertimbangan dan tindakan utama

Daftar periksa - Pertimbangan dan tindakan utama yang dapat Anda ambil untuk pengawasan sistem mengikuti.

Meningkatkan pengawasan sistem:

  • Verifikasi siapa yang diizinkan menjadi administrator Fabric: Jika memungkinkan, kurangi jumlah orang yang diberikan peran administrator Fabric jika lebih dari beberapa orang.
  • Gunakan PIM untuk administrator sesekali: Jika Anda memiliki orang yang terkadang memerlukan hak administrator Fabric, pertimbangkan untuk menerapkan Privileged Identity Management (PIM) di ID Microsoft Entra. PIM ini dirancang untuk menetapkan izin peran just-in-time yang kedaluwarsa setelah beberapa jam.
  • Administrator pelatihan: Periksa status pelatihan silang dan dokumentasi yang berlaku untuk menangani tanggung jawab administrasi Fabric. Pastikan bahwa orang cadangan dilatih sehingga kebutuhan dapat terpenuhi tepat waktu, dengan cara yang konsisten.

Meningkatkan manajemen layanan Fabric:

  • Tinjau pengaturan penyewa: Lakukan peninjauan semua pengaturan penyewa untuk memastikan pengaturan tersebut selaras dengan tujuan budaya data dan pedoman dan kebijakan tata kelola . Memverifikasi grup mana yang ditetapkan untuk setiap pengaturan.
  • Dokumentasikan pengaturan penyewa: Buat dokumentasi pengaturan penyewa Anda untuk komunitas Fabric internal dan posting di portal terpusat. Sertakan grup mana yang perlu diminta pengguna untuk dapat menggunakan fitur. Gunakan Get Tenant Pengaturan REST API untuk membuat proses lebih efisien, dan untuk membuat rekam jepret pengaturan secara teratur.
  • Kustomisasi tautan Dapatkan Bantuan: Saat sumber daya pengguna dibuat, seperti yang dijelaskan dalam artikel Pendampingan dan pengaktifan pengguna, perbarui pengaturan penyewa untuk menyesuaikan tautan di bawah opsi menu Dapatkan Bantuan. Ini akan mengarahkan pengguna ke dokumentasi, komunitas, dan bantuan Anda.

Meningkatkan manajemen komputer dan perangkat pengguna:

  • Membuat proses orientasi yang konsisten: Tinjau proses Anda tentang cara orientasi pembuat konten baru ditangani. Tentukan apakah permintaan baru untuk perangkat lunak, seperti Power BI Desktop, dan lisensi pengguna (Gratis, Pro, atau PPU) dapat ditangani bersama-sama. Langkah ini dapat menyederhanakan orientasi karena pembuat konten baru tidak akan selalu tahu apa yang harus diminta.
  • Menangani pembaruan komputer pengguna: Pastikan proses otomatis tersedia untuk menginstal dan memperbarui perangkat lunak, driver, dan pengaturan untuk memastikan semua pengguna memiliki versi yang sama.

Perencanaan arsitektur data:

  • Menilai seperti apa arsitektur data end-to-end Anda: Pastikan Anda jelas tentang:
    • Bagaimana Fabric saat ini digunakan oleh berbagai unit bisnis di organisasi Anda versus bagaimana Anda ingin Fabric digunakan. Menentukan apakah ada celah atau tidak.
    • Jika ada risiko yang harus ditangani.
    • Jika ada situasi pemeliharaan tinggi yang harus ditangani.
    • Sumber data apa yang penting bagi pengguna Fabric, dan bagaimana mereka didokumenkan dan ditemukan.
  • Tinjau gateway data yang sudah ada: Cari tahu gateway apa yang digunakan di seluruh organisasi Anda. Memverifikasi bahwa administrator dan pengguna gateway diatur dengan benar. Memverifikasi siapa yang mendukung setiap gateway, dan bahwa ada proses yang dapat diandalkan untuk menjaga server gateway tetap terbaru.
  • Verifikasi penggunaan gateway pribadi: Periksa jumlah gateway pribadi yang sedang digunakan, dan oleh siapa. Jika ada penggunaan yang signifikan, ambil langkah-langkah untuk bergerak menuju penggunaan gateway mode standar.

Meningkatkan manajemen lisensi pengguna:

  • Tinjau proses untuk meminta lisensi pengguna: Mengklarifikasi apa prosesnya, termasuk prasyarat apa pun, bagi pengguna untuk mendapatkan lisensi. Tentukan apakah ada perbaikan yang harus dilakukan pada proses tersebut.
  • Tentukan cara menangani pembelian lisensi layanan mandiri: Mengklarifikasi apakah pembelian lisensi layanan mandiri diaktifkan. Perbarui pengaturan jika tidak cocok dengan niat Anda tentang bagaimana lisensi dapat dibeli.
  • Konfirmasikan bagaimana uji coba pengguna ditangani: Verifikasi uji coba lisensi pengguna diaktifkan atau dinonaktifkan. Ketahuilah bahwa semua uji coba pengguna adalah Premium Per Pengguna. Mereka berlaku untuk pengguna berlisensi Gratis yang mendaftar untuk uji coba, dan pengguna Pro mendaftar untuk uji coba Premium Per Pengguna.

Meningkatkan manajemen biaya:

  • Tentukan tujuan manajemen biaya Anda: Pertimbangkan cara menyeimbangkan biaya, fitur, pola penggunaan, dan pemanfaatan sumber daya yang efektif. Menjadwalkan proses rutin untuk mengevaluasi biaya, setidaknya setiap tahun.
  • Mendapatkan data log aktivitas: Pastikan Anda memiliki akses ke data log aktivitas untuk membantu analisis biaya. Ini dapat digunakan untuk memahami siapa—atau tidak—menggunakan lisensi yang ditetapkan untuk mereka.

Meningkatkan keamanan dan perlindungan data:

  • Mengklarifikasi dengan tepat apa harapan untuk perlindungan data: Pastikan harapan untuk perlindungan data, seperti cara menggunakan label sensitivitas, didokumenkan dan dikomunikasikan kepada pengguna.
  • Tentukan cara menangani pengguna eksternal: Pahami dan dokumentasikan kebijakan organisasi sekelas berbagi konten Fabric dengan pengguna eksternal. Pastikan pengaturan di Fabric mendukung kebijakan Anda untuk pengguna eksternal.
  • Menyiapkan pemantauan: Selidiki penggunaan aplikasi Microsoft Defender untuk Cloud untuk memantau perilaku dan aktivitas pengguna di Fabric.

Meningkatkan audit dan pemantauan:

  • Rencanakan untuk kebutuhan audit: Kumpulkan dan dokumentasikan persyaratan bisnis utama untuk solusi audit. Pertimbangkan prioritas Anda untuk audit dan pemantauan. Buat keputusan utama yang terkait dengan jenis solusi audit, izin, teknologi yang akan digunakan, dan kebutuhan data. Konsultasikan dengan IT untuk mengklarifikasi proses audit apa yang saat ini ada, dan preferensi persyaratan apa yang ada untuk membangun solusi baru.
  • Pertimbangkan peran dan tanggung jawab: Identifikasi tim mana yang akan terlibat dalam membangun solusi audit, serta analisis berkelanjutan dari data audit.
  • Mengekstrak dan menyimpan data aktivitas pengguna: Jika saat ini Anda tidak mengekstrak dan menyimpan data mentah, mulai mengambil data aktivitas pengguna.
  • Mengekstrak dan menyimpan rekam jepret data inventory penyewa: Mulai mengambil metadata untuk membangun inventori penyewa, yang menjelaskan semua ruang kerja dan item.
  • Mengekstrak dan menyimpan rekam jepret data pengguna dan grup: Mulai mengambil metadata tentang pengguna, grup, dan perwakilan layanan.
  • Membuat model data yang dikumpulkan: Lakukan pembersihan data dan transformasi data mentah untuk membuat model data yang dikumpulkan yang akan mendukung pelaporan analitik untuk solusi audit Anda.
  • Menganalisis data audit dan bertindak berdasarkan hasil: Membuat laporan analitik untuk menganalisis data audit yang dikumpulkan. Klarifikasi tindakan apa yang diharapkan untuk diambil, oleh siapa, dan kapan.
  • Sertakan data audit tambahan: Seiring waktu, tentukan apakah data audit lain akan membantu untuk melengkapi data log aktivitas, seperti data keamanan.

Tip

Untuk informasi selengkapnya, lihat Audit tingkat penyewa.

Gunakan REST API:

  • Rencanakan penggunaan REST API Anda: Pertimbangkan data apa yang paling berguna untuk diambil dari API REST Power BI dan FABRIC REST API.
  • Lakukan bukti konsep: Lakukan bukti konsep kecil untuk memvalidasi kebutuhan data, pilihan teknologi, dan izin.

Pertanyaan untuk ditanyakan

Gunakan pertanyaan seperti yang ditemukan di bawah ini untuk menilai pengawasan sistem.

  • Apakah ada pengaturan administrasi atipikal diaktifkan atau dinonaktifkan? Misalnya, adalah seluruh organisasi yang diizinkan untuk menerbitkan ke web (kami sangat menyarankan untuk membatasi fitur ini).
  • Apakah pengaturan dan kebijakan administrasi selaras dengan, atau menghambat, cara kerja pengguna?
  • Apakah ada proses untuk menilai pengaturan baru secara kritis dan memutuskan cara mengaturnya? Atau, hanya pengaturan yang paling ketat yang ditetapkan sebagai tindakan pencegahan?
  • Apakah grup keamanan Microsoft Entra digunakan untuk mengelola siapa yang dapat melakukan apa?
  • Apakah tim pusat memiliki visibilitas alat audit dan pemantauan yang efektif?
  • Apakah solusi pemantauan menggambarkan informasi tentang aset data, aktivitas pengguna, atau keduanya?
  • Apakah alat audit dan pemantauan dapat ditindak? Apakah ada ambang batas dan tindakan yang jelas yang ditetapkan, atau melakukan laporan pemantauan hanya menjelaskan apa yang ada di data estate?
  • Apakah Azure Log Analytics digunakan (atau direncanakan untuk digunakan) untuk pemantauan terperinci kapasitas Fabric? Apakah potensi manfaat dan biaya Azure Log Analytics jelas bagi pembuat keputusan?
  • Apakah label sensitivitas dan kebijakan pencegahan kehilangan data digunakan? Apakah potensi manfaat dan biaya ini jelas bagi pembuat keputusan?
  • Apakah administrator mengetahui jumlah lisensi dan biaya lisensi saat ini? Berapa proporsi total pengeluaran BI yang masuk ke kapasitas Fabric, dan ke lisensi Pro dan PPU? Jika organisasi hanya menggunakan lisensi Pro untuk konten Power BI, bisakah jumlah pengguna dan pola penggunaan menjamin peralihan hemat biaya ke kapasitas Power BI Premium atau Fabric?

Tingkat kematangan

Tingkat kematangan berikut akan membantu Anda menilai status pengawasan sistem Power BI Anda saat ini.

Tingkat Status pengawasan sistem
100: Awal • Pengaturan penyewa dikonfigurasi secara independen oleh satu atau beberapa administrator berdasarkan penilaian terbaik mereka.

• Kebutuhan arsitektur, seperti gateway dan kapasitas, dipenuhi sesuai kebutuhan. Namun, tidak ada rencana strategis.

• Log aktivitas Fabric tidak digunakan, atau secara selektif digunakan untuk tujuan taktis.
200: Dapat diulang • Pengaturan penyewa secara sengaja selaras dengan pedoman dan kebijakan tata kelola yang ditetapkan. Semua pengaturan penyewa ditinjau secara teratur.

• Sejumlah kecil administrator tertentu dipilih. Semua administrator memiliki pemahaman yang baik tentang apa yang coba dicapai pengguna di Fabric, sehingga mereka berada dalam posisi yang baik untuk mendukung pengguna.

• Proses yang terdefinisi dengan baik ada bagi pengguna untuk meminta lisensi dan perangkat lunak. Formulir permintaan mudah ditemukan pengguna. Pengaturan pembelian layanan mandiri ditentukan.

• Label sensitivitas dikonfigurasi di Microsoft 365. Namun, penggunaan label tetap tidak konsisten. Keuntungan perlindungan data tidak dipahami dengan baik oleh pengguna.
300: Ditentukan • Pengaturan penyewa sepenuhnya didokumenkan di portal terpusat untuk direferensikan pengguna, termasuk cara meminta akses ke grup yang benar.

• Ada pelatihan silang dan dokumentasi bagi administrator untuk memastikan kelangsungan, stabilitas, dan konsistensi.

• Label sensitivitas ditetapkan ke konten secara konsisten. Keuntungan menggunakan label sensitivitas untuk perlindungan data dipahami oleh pengguna.

• Proses otomatis diberlakukan untuk mengekspor log aktivitas Fabric dan data API ke lokasi yang aman untuk pelaporan dan audit.
400: Mampu • Administrator bekerja sama dengan tim COE dan tata kelola untuk memberikan pengawasan terhadap Fabric. Keseimbangan pemberdayaan dan tata kelola pengguna berhasil dicapai.

• Manajemen arsitektur data terdesentralisasi (seperti gateway atau manajemen kapasitas) secara efektif ditangani untuk menyeimbangkan kelincahan dan kontrol.

• Kebijakan otomatis disiapkan dan dipantau secara aktif di Microsoft Defender untuk Cloud Apps untuk pencegahan kehilangan data.

• Log aktivitas dan data API dianalisis secara aktif untuk memantau dan mengaudit aktivitas Fabric. Tindakan proaktif diambil berdasarkan data.
500: Efisien • Administrator Fabric bekerja sama dengan COE secara aktif tetap terkini. Posting blog dan rencana rilis dari tim produk Fabric sering ditinjau untuk merencanakan perubahan yang akan datang.

• Analisis manajemen biaya reguler dilakukan untuk memastikan kebutuhan pengguna terpenuhi dengan cara yang hemat biaya.

• Fabric REST API digunakan untuk mengambil nilai pengaturan penyewa secara teratur.

• Log aktivitas dan data API secara aktif digunakan untuk menginformasikan dan meningkatkan upaya adopsi dan tata kelola.

Untuk informasi selengkapnya tentang pengawasan sistem dan administrasi Fabric, lihat sumber daya berikut.

Pada artikel berikutnya dalam seri peta strategi adopsi Microsoft Fabric, pelajari tentang manajemen perubahan yang efektif.