A Microsoft Fabric bevezetési ütemterve: Rendszerfelügyelet

  • Cikk

Feljegyzés

Ez a cikk a Microsoft Fabric bevezetési ütemtervének cikksorozatának része. A sorozat áttekintéséhez tekintse meg a Microsoft Fabric bevezetési ütemtervét.

A rendszerfelügyelet – más néven Hálófelügyelet – a folyamatos, napi szintű felügyeleti tevékenység. Kifejezetten a következőkkel foglalkozik:

  • Irányítás: Szabályozási irányelvek és szabályzatok kidolgozása az önkiszolgáló és vállalati adatok és üzletiintelligencia-forgatókönyvek támogatásához.
  • Felhasználói felhatalmazás: Megkönnyítheti és támogathatja a belső felhasználói közösséget a lehető legnagyobb mértékben támogató belső folyamatokat és rendszereket, miközben betartja a szervezet előírásait és követelményeit.
  • Bevezetés: A Fabric szélesebb körű szervezeti bevezetésének lehetővé tétele hatékony irányítási és adatkezelési gyakorlatokkal.

Fontos

A szervezeti adatkultúra célkitűzései útmutatást nyújtanak a szabályozási döntésekhez, ami azt határozza meg, hogy a Fabric-adminisztrációs tevékenységek hogyan és ki által valósulnak meg.

A rendszerfelügyelet széles körű és mély témakör. A cikk célja, hogy bemutassa azokat a legfontosabb szempontokat és intézkedéseket, amelyek segítenek a szervezeti bevezetési célok sikeressé tételében.

Hálógazdák

A Háló rendszergazdai szerepkör egy definiált szerepkör a Microsoft 365-ben, amely a felügyeleti tevékenységek egy részhalmazát delegálja. A Globális Microsoft 365-rendszergazdák implicit módon Fabric-rendszergazdák. A Power Platform rendszergazdái implicit módon Fabric-rendszergazdák is.

A legfontosabb irányítási döntés az, hogy ki legyen a Háló rendszergazdája. Ez egy központosított szerepkör, amely a teljes bérlőt érinti. Ideális esetben 2-4 személy van a szervezetben , akik képesek kezelni a Fabricet. A rendszergazdáknak szorosan együttműködve kell működnie a Kiválósági Központtal (COE).

Magas jogosultsági szerepkör

A Háló rendszergazdai szerepköre magas jogosultsági szintű szerepkör, mert:

  • Felhasználói élmény: a hálógazdák által felügyelt Gépház jelentős hatással vannak a felhasználói képességekre és a felhasználói élményre. További információ: Bérlői beállítások szabályozása.
  • Teljes biztonsági hozzáférés: A hálógazdák frissíthetik a bérlő munkaterületeinek hozzáférési engedélyeit. Ennek az az eredménye, hogy a rendszergazda engedélyezheti az adatok és jelentések megtekintését vagy letöltését a megfelelőnek látja. További információ: Bérlői beállítások szabályozása.
  • Személyes munkaterület-hozzáférés: A hálógazdák hozzáférhetnek a tartalmakhoz, és szabályozhatják bármely felhasználó személyes munkaterületét .
  • Metaadatok: A hálógazdák megtekinthetik az összes bérlői metaadatot, beleértve a Háló portálon végzett összes felhasználói tevékenységet is (erről az alábbi Naplózás és figyelés szakaszban olvashat).

Fontos

Ha túl sok hálógazdát veszünk fel, az kockázatot jelent. Növeli a bérlő nem jóváhagyott, nem szándékos vagy inkonzisztens felügyeletének valószínűségét.

Szerepkörök és felelősségi körök

A rendszergazdák által napi szinten végzett tevékenységek típusai különbözőek lesznek a szervezetek között. Ami fontos, és elsőbbséget élvez az adatkultúrában, az nagymértékben befolyásolja , hogy a rendszergazda mit tesz az üzleti vezetésű önkiszolgáló, a felügyelt önkiszolgáló, valamint a vállalati adatok és BI-forgatókönyvek támogatásához. További információt a Tartalom tulajdonjogáról és kezeléséről szóló cikkben talál.

Tipp.

A hálógazdák legjobb típusa az, aki elegendő tudással rendelkezik az eszközökről és a számítási feladatokról ahhoz, hogy megértse, mit kell tenniük az önkiszolgáló felhasználóknak. Ezzel a megértéssel a rendszergazda kiegyensúlyozza a felhasználók felhatalmazását és irányítását.

A Háló-rendszergazda mellett vannak más szerepkörök is, amelyek a rendszergazda kifejezést használják. Az alábbi táblázat a gyakran és rendszeresen használt szerepköröket ismerteti.

Szerepkör Hatókör Leírás
Hálóadminisztrátor Bérlő Kezeli a bérlői beállításokat és egyéb beállításokat a Háló portálon. A jelen cikkben szereplő összes rendszergazdai általános hivatkozás erre a rendszergazdatípusra hivatkozik.
Kapacitásadminisztrátor Egy kapacitás Kezeli a munkaterületeket és a számítási feladatokat, és figyeli a Fabric-kapacitás állapotát.
Adatátjáró rendszergazdája Egy átjáró Kezeli az átjáró adatforrás-konfigurációját, hitelesítő adatait és felhasználói hozzárendeléseit. Az átjáró szoftverfrissítéseit is kezelheti (vagy együttműködhet az infrastruktúra csapatával a frissítéseken).
Munkaterület rendszergazdája Egy munkaterület Kezeli a munkaterület beállításait és a hozzáférést.

A számítási feladatok Fabric-ökoszisztémája széles és mély. A Fabric számos módon integrálható más rendszerekkel és platformokkal. Időről időre más rendszergazdákkal és informatikai szakemberekkel kell dolgoznia. További információ: Együttműködés más rendszergazdákkal.

A cikk további része áttekintést nyújt a Háló rendszergazdái által végzett leggyakoribb tevékenységekről. Olyan tevékenységekre összpontosít, amelyeket a szervezeti bevezetés stratégiai megközelítése során fontos hatékonyan végrehajtani.

Szolgáltatásmenedzsment

A bérlő felügyelete kulcsfontosságú szempont annak biztosításához, hogy minden felhasználó jó tapasztalattal rendelkezzen a Power BI-ban. A Hálógazdák fő irányítási feladatai közé tartoznak a következők:

  • Bérlői beállítások: Annak szabályozása, hogy mely Power BI-funkciók és képességek engedélyezettek, és mely felhasználók számára vannak engedélyezve a szervezetben.
  • Tartományok: Csoportosítsa két vagy több hasonló tulajdonságokkal rendelkező munkaterületet.
  • Munkaterületek: A bérlő munkaterületeinek áttekintése és kezelése.
  • Beágyazási kódok: Az interneten nyilvánosan közzétett jelentések szabályozása.
  • Szervezeti vizualizációk: Szervezeti vizualizációk regisztrálása és kezelése.
  • Azure-kapcsolatok: Integrálható az Azure-szolgáltatásokkal további funkciók biztosítása érdekében.

További információ: Bérlői felügyelet.

Felhasználói gépek és eszközök

A Fabric bevezetése közvetlenül a tartalomkészítőktől és a szükséges eszközökkel és alkalmazásokkal rendelkező felhasználóktól függ. Íme néhány fontos kérdés, amit érdemes megfontolni.

  • Hogyan kérnek hozzáférést a felhasználók az új eszközökhöz? Elérhető lesz-e a licencekhez, adatokhoz és betanításokhoz való hozzáférés, hogy a felhasználók hatékonyan használják az eszközöket?
  • Hogyan tekintik meg a tartalomfelhasználók a mások által közzétett tartalmakat?
  • Hogyan fejlesztenek, kezelnek és tesznek közzé tartalmakat a tartalomkészítők? Milyen kritériumok alapján dönti el, hogy mely eszközök és alkalmazások megfelelőek a használati esetekhez?
  • Hogyan fogja telepíteni és beállítani az eszközöket? Ezek tartalmazzák a kapcsolódó előfeltételeket és az adatkapcsolati összetevőket?
  • Hogyan fogja kezelni az eszközök és alkalmazások folyamatos frissítéseit?

További információ: Felhasználói eszközök és eszközök.

Architektúra

A Fabric kontextusában az architektúra az adatarchitektúrához, a kapacitáskezeléshez, valamint az adatátjáró architektúrához és -kezeléshez kapcsolódik.

Adatarchitektúra

Az adatarchitektúra azokat az alapelveket, eljárásokat és módszertanokat jelenti, amelyek szabályozzák és meghatározzák az összegyűjtött adatokat, valamint az adatok betöltésének, tárolásának, kezelésének, integrációjának, modellezésének és felhasználásának módját.

Számos adatarchitektúra-döntést kell meghoznia. A COE gyakran foglalkozik az adatarchitektúra tervezésével és tervezésével. Gyakran előfordul, hogy a rendszergazdák is belekeverednek, különösen akkor, ha adatbázisokat vagy Azure-infrastruktúrát kezelnek.

Fontos

Az adatarchitektúra-döntések jelentős hatással vannak a Fabric bevezetésére, a felhasználói elégedettségre és az egyes projektek sikerességi arányára.

A bevezetést befolyásoló néhány adatarchitektúra-szempont:

  • Hol illeszkedik a Fabric a szervezet teljes adatarchitektúrájába? Vannak más meglévő összetevők, például egy vállalati adattárház (EDW) vagy egy data lake, amelyek fontos szerepet fognak adni a tervekben?
  • A Fabric végpontok közötti adat-előkészítéshez, adatmodellezéshez és adatbemutatáshoz használatos, vagy a Fabric csak néhány ilyen képességhez használható?
  • Követik a felügyelt önkiszolgáló mintákat, hogy megtalálják a legjobb egyensúlyt az adatok újrafelhasználhatósága és a jelentéskészítő rugalmassága között?
  • Hol fogják felhasználni a felhasználók a tartalmat? A tartalmak kézbesítésének három fő módja általában a Fabric Portál, a Power BI jelentéskészítő kiszolgáló és az egyéni alkalmazásokba ágyazott. Emellett a Microsoft Teams kényelmes alternatíva azoknak a felhasználóknak, akik sok időt töltenek a Teamsben.
  • Ki felelős az adatarchitektúra kezeléséért és karbantartásáért? Központosított vagy decentralizált csapat? Hogyan jelenik meg a COE ebben a csapatban? Szükség van bizonyos készségekre?
  • Mely adatforrások a legfontosabbak? Milyen típusú adatokat fogunk beszerezni?
  • Milyen szemantikai modellkapcsolati mód és tárolási mód (például Direct Lake, importálás, élő kapcsolat, DirectQuery vagy összetett modell-keretrendszerek) ideálisak a használati esetekhez?
  • Milyen mértékben ösztönzi az adatok újrafelhasználhatóságát a lakehouse-k, a raktárak és a megosztott szemantikai modellek használata?
  • Milyen mértékben támogatja az adat-előkészítési logika és a fejlett adat-előkészítés újrafelhasználhatóságát adatfolyamok, jegyzetfüzetek és adatfolyamok használatával?

Fontos, hogy a rendszergazdák teljes mértékben tisztában legyenek a Fabric technikai képességeivel , valamint az érdekelt felek igényeivel és céljaival, mielőtt architekturális döntéseket hoznának.

Tipp.

Ismerkedjen meg azzal a jó szokással, hogy egy technikai megvalósíthatósági igazolást (POC) kell elvégeznie, hogy tesztelje a feltételezéseket és az ötleteket. Egyes szervezetek mikroprojekteknek is nevezik őket, amikor a cél egy kis munkaegység megvalósítása. A POC célja az ismeretlenek kezelése és a kockázat lehető legkorábbi csökkentése. A POC-nek nem kell kidobó munkát végeznie, de szűk hatókörűnek kell lennie. A mentorálásról és a felhasználói engedélyezésről szóló cikkben ismertetett ajánlott eljárások áttekintése egy másik hasznos módszer a tartalomkészítőknek a fontos architekturális döntések meghozatalában.

Kapacitáskezelés

A kapacitás olyan funkciókat és képességeket tartalmaz, amelyekkel nagy léptékű elemzési megoldásokat biztosíthat. A Fabric szervezeti licenceknek két típusa van: felhasználónkénti prémium (PPU) és kapacitás. A kapacitáslicenceknek számos típusa van. A kapacitáslicencek típusa határozza meg, hogy mely Háló számítási feladatok támogatottak.

Fontos

Ez a cikk időnként a Power BI Premiumra vagy annak kapacitás-előfizetésére (P termékváltozatokra) hivatkozik. Vegye figyelembe, hogy a Microsoft jelenleg összevonja a vásárlási lehetőségeket, és visszavonul a Power BI Premium kapacitásonkénti termékváltozataitól. Az új és a meglévő ügyfeleknek érdemes megfontolni a Fabric-kapacitás-előfizetések (F SKU-k) megvásárlását.

További információ: Fontos frissítés a Power BI Premium licenceléséhez és a Power BI Premiumhoz – gyakori kérdések.

A kapacitás használata jelentős szerepet játszhat a tartalom létrehozására, kezelésére, közzétételére és terjesztésére vonatkozó stratégiában. A kapacitásba való befektetés néhány fő oka a következők:

  • Korlátlan Power BI-tartalomterjesztés nagy számú írásvédett felhasználó számára. Az ingyenes Power BI-licenccel rendelkező felhasználók tartalomhasználata csak prémium szintű kapacitásban érhető el, pPU-val nem. Az ingyenes felhasználók által fogyasztott tartalom F64 Fabric-kapacitás licenccel vagy annál magasabb licenccel is elérhető.
  • Hozzáférés a Fabric-szolgáltatásokhoz a végpontok közötti elemzések létrehozásához.
  • Üzembe helyezési folyamatok a tartalom fejlesztési, tesztelési és éles munkaterületeken való közzétételének kezeléséhez. Kifejezetten ajánlottak kritikus tartalmakhoz a kiadás stabilitásának javítása érdekében.
  • XMLA-végpont, amely egy szemantikai modell kezelésére és közzétételére szolgáló iparági szabványprotokoll, vagy a szemantikai modell lekérdezése bármely XMLA-kompatibilis eszközről.
  • Megnövelt modellméretkorlátok, beleértve a nagy szemantikai modellek támogatását.
  • Gyakoribb adatfrissítések.
  • Az adatok tárolása egy adott földrajzi területen, amely eltér az otthoni régiótól.

A fenti lista nem teljes körű. A teljes listát a Power BI Premium funkcióiban találja.

Hálókapacitás kezelése

A Fabric-kapacitás állapotának felügyelete nélkülözhetetlen tevékenység a rendszergazdák számára. Minden kapacitás-termékváltozat erőforráskészletet tartalmaz. A kapacitásegységek (CU-k) az egyes termékváltozatok számítási erőforrásainak mérésére szolgálnak.

Figyelemfelhívás

A felügyelet hiánya és a kapacitáserőforrások korlátainak következetes túllépése gyakran teljesítményproblémákat és felhasználói élményt eredményez. Ha nem megfelelően kezelik mindkét kihívást, az hozzájárulhat a bevezetési erőfeszítésekre gyakorolt negatív hatáshoz.

Javaslatok a hálókapacitás kezeléséhez:

  • Határozza meg, hogy ki felelős a kapacitás kezeléséért. Erősítse meg a szerepköröket és a felelősségeket, hogy egyértelmű legyen, hogy milyen műveletet hajtanak végre, miért, mikor és ki által.
  • Hozzon létre egy adott feltételkészletet a kapacitásban közzéteendő tartalomhoz. Ez különösen akkor fontos, ha egyetlen kapacitást több üzleti egység használ, mert fennáll a lehetőség, hogy megzavarja a többi felhasználót, ha a kapacitás nincs megfelelően kezelve. Fontolja meg az ajánlott eljárások felülvizsgálatát (például ésszerű szemantikai modellméretet és hatékony számításokat) az új tartalom éles kapacitásban való közzététele előtt.
  • A Fabric kapacitásmetrikák alkalmazásával rendszeresen megismerheti a kapacitás erőforrás-kihasználtságát és mintáit. A legfontosabb, hogy keressen konzisztens túlhasználati mintákat, amelyek hozzájárulnak a felhasználói fennakadásokhoz. A használati minták elemzésével azt is figyelembe kell vennie, hogy a kapacitás kihasználatlan-e, ami azt jelzi, hogy több érték származhat a befektetésből.
  • Állítsa be a bérlői beállítást, hogy a Fabric értesítést küldjön, ha a kapacitás túlterhelődik, vagy ha kimaradás vagy incidens történik.

Automatikus méretezés

Az automatikus skálázás a kapacitáshasználati szintek időnkénti vagy váratlan adatkitöréseinek kezelésére szolgál. Az automatikus skálázás képes reagálni ezekre a kipukkadásokra azáltal, hogy automatikusan növeli a cpu-erőforrásokat a megnövekedett számítási feladat támogatása érdekében.

Az automatizált vertikális felskálázás csökkenti a teljesítmény és a felhasználói élmény kihívásainak kockázatát a pénzügyi hatásért cserébe. Ha a kapacitás nincs megfelelően felügyelve, az automatikus skálázás a vártnál gyakrabban aktiválódik. Ebben az esetben a metrikák alkalmazás segíthet a mögöttes problémák meghatározásában és a kapacitástervezésben.

Decentralizált kapacitáskezelés

A kapacitásgazdák feladata , hogy munkaterületeket rendeljenek hozzá egy adott kapacitáshoz.

Vegye figyelembe, hogy a munkaterület-rendszergazdák munkaterületet is hozzárendelhetnek a PPU-hoz, ha a munkaterület rendszergazdája PPU-licenccel rendelkezik. Ehhez azonban minden más munkaterület-felhasználónak PPU-licenccel is rendelkeznie kell a Power BI-tartalmak munkaterületen való együttműködéséhez vagy megtekintéséhez. Más hálóterhelések nem vehetők fel a PPU-hoz hozzárendelt munkaterületekbe.

Több kapacitást is beállíthat, hogy megkönnyítse a különböző üzleti egységek decentralizált felügyeletét. A Fabric bizonyos aspektusainak decentralizált kezelése nagyszerű módja az agilitás és az ellenőrzés egyensúlyának.

Íme egy példa, amely a kapacitás kezelésének egyik módját ismerteti.

  • P3-kapacitáscsomópont vásárlása a Microsoft 365-ben. 32 virtuális magot (v-magot) tartalmaz.
  • Az első kapacitás létrehozásához használjon 16 virtuális magot. A sales csapat fogja használni.
  • A második kapacitás létrehozásához használjon 8 virtuális magot. Az operatív csapat fogja használni.
  • A fennmaradó 8 virtuális maggal hozza létre a harmadik kapacitást. Ez támogatja az általános használatot.

Az előző példának számos előnye van.

  • Minden kapacitáshoz külön kapacitásgazdák állíthatók be. Ezért megkönnyíti a decentralizált felügyeleti helyzeteket.
  • Ha egy kapacitás nincs megfelelően felügyelve, a hatás csak erre a kapacitásra korlátozódik. A többi kapacitásra nincs hatással.
  • A számlázás és a más üzleti egységekre történő visszaterhelések egyszerűek.
  • A különböző munkaterületek könnyen hozzárendelhetők a különálló kapacitásokhoz.

Az előző példának azonban hátrányai is vannak.

  • A kapacitásonkénti korlátok alacsonyabbak. A szemantikai modellek maximális memóriamérete nem a megvásárolt teljes P3-kapacitáscsomópont-méret. Ehelyett ez a hozzárendelt kapacitásméret, ahol a szemantikai modell üzemel.
  • Valószínűbb, hogy a kisebb kapacitások egyikét valamikor fel kell skálázni.
  • A bérlő több kapacitást kezelhet.

Feljegyzés

A Power BI Premium kapacitásonkénti erőforrásait virtuális magoknak nevezzük. A hálókapacitás azonban kapacitásegységként (CU) hivatkozik rájuk. A termékváltozatok és a virtuális magok méretezése minden termékváltozatnál eltérő. További információkért tekintse meg a Fabric licencelési dokumentációját.

Az adatátjáró architektúrája és kezelése

Az adatátjárók megkönnyítik az adatok biztonságos és hatékony átvitelét a szervezeti adatforrások és a Fabric szolgáltatás között. Adatátjáróra van szükség a helyszíni vagy felhőszolgáltatásokhoz való adatkapcsolathoz, ha egy adatforrás a következő:

  • A vállalati adatközpontban található.
  • Tűzfal mögött konfigurálva.
  • Egy virtuális hálózaton belül.
  • Egy virtuális gépen belül.

Az átjáróknak három típusa van.

  • A helyszíni adatátjáró (standard mód) egy átjárószolgáltatás, amely számos felhasználó számára támogatja a regisztrált adatforrásokhoz való csatlakozást. Az átjáró szoftvertelepítései és frissítései az ügyfél által felügyelt gépen vannak telepítve.
  • A helyszíni adatátjáró (személyes mód) egy átjárószolgáltatás, amely csak az adatfrissítést támogatja. Ez az átjáró mód általában egy tartalomkészítő számítógépére van telepítve. Csak egy felhasználó általi használatot támogatja. Nem támogatja az élő kapcsolatot és a DirectQuery-kapcsolatokat.
  • A virtuális hálózati adatátjáró egy Microsoft által felügyelt szolgáltatás, amely számos felhasználó számára támogatja a kapcsolatot. Pontosabban támogatja a prémium szintű kapacitáshoz vagy felhasználónkénti prémium szintű munkaterületeken tárolt szemantikai modellekhez és adatfolyamokhoz való kapcsolódást.

Tipp.

Annak eldöntése, hogy ki telepíthet átjárószoftvert , az szabályozási döntés. A legtöbb szervezet esetében erősen ajánlott az adatátjáró használata standard módban vagy virtuális hálózati adatátjáróként. Sokkal méretezhetőbbek, kezelhetők és naplózhatók, mint a személyes módban lévő adatátjárók.

Decentralizált átjárókezelés

A helyszíni adatátjáró (standard mód) és a virtuális hálózati adatátjáró bizonyos, regisztrálható adatforrástípusokat támogat, a kapcsolat részleteivel és a hitelesítő adatok tárolásának módjával együtt. A felhasználók engedélyt kaphatnak az átjáró adatforrásának használatára, hogy ütemezhessenek egy frissítést, vagy DirectQuery-lekérdezéseket futtassanak.

Az átjárókezelés bizonyos aspektusai decentralizált módon hatékonyan elvégezhetők az agilitás és az ellenőrzés egyensúlyának biztosítása érdekében. Előfordulhat például, hogy az operatív csoport rendelkezik egy átjáróval, amelyet önkiszolgáló tartalomkészítőkből és adattulajdonosokból álló csapatának szenteltek.

A decentralizált átjárókezelés az alábbiak szerint működik a legjobban, ha közös erőfeszítésről van szó.

A decentralizált adattulajdonosok kezelik:

Központosított adattulajdonosok kezelik (beleértve a szervezeten belül széles körben használt adatforrásokat is; a felügyelet központosított, hogy elkerülje a duplikált adatforrásokat):

  • Központosított adatforrás-kapcsolati információk és adatvédelmi szintek.
  • Központosított adatforrás tárolt hitelesítő adatai (beleértve a rutin jelszómódosítások frissítésével kapcsolatos felelősséget is).
  • Központosított adatforrás-felhasználók, akik jogosultak az egyes adatforrások használatára.

Informatikai felügyelet:

  • Átjárószoftver-frissítések (az átjárófrissítések általában havonta jelennek meg).
  • Illesztőprogramok és egyéni összekötők telepítése (ugyanazok, amelyek a felhasználói gépekre vannak telepítve).
  • Átjárófürt-kezelés (az átjárófürtben lévő gépek száma magas rendelkezésre állás, vészhelyreállítás és egyetlen meghibásodási pont kiküszöbölése érdekében, ami jelentős felhasználói fennakadásokat okozhat).
  • Kiszolgálókezelés (például operációs rendszer, RAM, CPU vagy hálózati kapcsolat).
  • Átjárótitkosítási kulcsok kezelése és biztonsági mentése.
  • Az átjárónaplók monitorozása annak felméréséhez, hogy szükség van-e a vertikális felskálázásra vagy a vertikális felskálázásra.
  • Riasztás az átjárógép állásidejéről vagy állandó alacsony erőforrásairól.

Tipp.

Ha lehetővé teszi egy decentralizált csapat számára az átjáró bizonyos aspektusainak kezelését, az azt jelenti, hogy gyorsabban mozoghatnak. A decentralizált átjárókezelés kompromisszuma azt jelenti, hogy több átjárókiszolgálót futtat, hogy mindegyik a szervezet egy adott területére legyen dedikált. Ha az átjárókezelést teljes egészében az informatikai rendszer kezeli, elengedhetetlen, hogy megfelelő folyamat legyen érvényben az adatforrások hozzáadására és a felhasználói frissítések alkalmazására irányuló kérelmek gyors kezeléséhez.

Felhasználói licencek

Minden felhasználónak szüksége van egy kereskedelmi licencre, amely egy Microsoft Entra-identitással van integrálva. A felhasználói licenc lehet ingyenes, Pro vagy Prémium felhasználónként (PPU).

A felhasználói licenc egy előfizetésen keresztül szerezhető be, amely bizonyos számú licencet engedélyez kezdő és záró dátummal.

Feljegyzés

Bár minden felhasználónak licencre van szüksége, a Power BI-tartalmak megosztásához pro- vagy PPU-licencre van szükség. Az ingyenes licenccel rendelkező felhasználók nem Power BI-elemeket hozhatnak létre és oszthatnak meg Fabric-tartalmakat.

Az előfizetések beszerzésének két módszere van.

  • Központosított: A Microsoft 365 számlázási rendszergazdája pro- vagy PPU-előfizetést vásárol. Ez a leggyakoribb módja az előfizetések kezelésének és a licencek hozzárendelésének.
  • Decentralizált: Az egyes részlegek önkiszolgáló vásárlással vásárolnak előfizetést.

Önkiszolgáló vásárlás

Egy fontos irányítási döntés azt határozza meg, hogy milyen mértékben engedélyezik vagy ösztönzik az önkiszolgáló vásárlást.

Az önkiszolgáló vásárlás a következő esetekben hasznos:

  • Nagyobb szervezetek decentralizált üzleti egységekkel, amelyek beszerzési hatósággal rendelkeznek, és közvetlenül hitelkártyával szeretnék kezelni a fizetést.
  • Azok a szervezetek, amelyek a lehető legegyszerűbbé kívánják tenni az előfizetések havi előfizetéssel történő megvásárlását.

Fontolja meg az önkiszolgáló vásárlás letiltását a következő esetekben:

  • A központi beszerzési folyamatok megfelelnek a szabályozási, biztonsági és szabályozási követelményeknek.
  • A kedvezményes díjszabás egy Nagyvállalati Szerződés (EA) keresztül érhető el.
  • A vállalatközi terhelés-visszaterhelések kezelésére meglévő folyamatok vannak érvényben.
  • A csoportalapú licencelési hozzárendelések kezelésére meglévő folyamatok vannak érvényben.
  • A licenc beszerzésének előfeltételei, például jóváhagyás, indoklás, képzés vagy szabályozási szabályzatra vonatkozó követelmény.
  • A hozzáférés szigorú ellenőrzéséhez érvényes szükség van, például egy szabályozási követelményre.

Felhasználói licenccel kapcsolatos próbaverziók

Egy másik fontos szabályozási döntés az, hogy engedélyezve vannak-e a felhasználói licenccel kapcsolatos próbaverziók. Alapértelmezés szerint a próbaverziók engedélyezve vannak. Ez azt jelenti, hogy ha a tartalom meg van osztva egy munkatárssal, ha a címzett nem rendelkezik Pro- vagy PPU-licenccel, a rendszer kérni fogja, hogy indítsa el a próbaverziót a tartalom megtekintéséhez (ha a tartalom nem a kapacitás által támogatott munkaterületen belül található). A próbaverziós felület célja, hogy kényelmes legyen, amely lehetővé teszi a felhasználók számára a normál munkafolyamat folytatását.

Általában nem ajánlott letiltani a próbaverziókat. Arra ösztönözheti a felhasználókat, hogy áthidaló megoldásokat keressenek, például adatok exportálásával vagy a támogatott eszközökön és folyamatokon kívül végzett munkával.

Fontolja meg a próbaverziók letiltását, ha:

  • Vannak komoly költségproblémák, amelyek miatt nem valószínű, hogy a próbaidőszak végén teljes licenceket adnának.
  • A licenc megszerzésének előfeltételei (például jóváhagyás, indoklás vagy betanítási követelmény). A próbaidőszak alatt nem elegendő ennek a követelménynek megfelelni.
  • A Fabric szolgáltatáshoz való hozzáférés szigorú szabályozásához érvényes szükség van, például egy szabályozási követelményre.

Tipp.

Ne vezessen be túl sok akadályt a Fabric-licencek beszerzéséhez. Azok a felhasználók, akiknek el kell végezni a munkát, megtalálják a módját, és ez olyan áthidaló megoldásokat is tartalmazhat, amelyek nem ideálisak. Például a Fabric használatára vonatkozó licenc nélkül a felhasználók túl sokat támaszkodhatnak a fájlok fájlrendszeren vagy e-mailben történő megosztására, ha lényegesen jobb megközelítések érhetők el.

Költségkezelés

A felhőszolgáltatások( például a Fabric) költségeinek kezelése és optimalizálása fontos tevékenység. Íme néhány tevékenység, amelyeket megfontolhat.

  • Elemezheti, hogy ki használja a lefoglalt Fabric-licenceket, és végezze el a szükséges módosításokat. A hálóhasználat elemzése a tevékenységnapló használatával történik.
  • A kapacitás vagy a felhasználónkénti Premium költséghatékonyságának elemzése. A további funkciók mellett költség-haszon elemzést is végezhet annak megállapításához, hogy a kapacitáslicencelés költséghatékonyabb-e, ha nagy számú fogyasztó van.
  • Gondosan monitorozza és kezelje a hálókapacitást. A használati minták időbeli megértése lehetővé teszi, hogy előre jelezhesse, mikor vásároljon több kapacitást. Dönthet például úgy, hogy egy P1-ről P2-re felskáláz egy kapacitást, vagy egy P1-kapacitásról két P1-kapacitásra skáláz.
  • Ha a használati szint időnként kiugróan magas, az automatikus méretezés használata a Hálóval javasolt annak biztosítása érdekében, hogy a felhasználói élmény ne szakadjon meg. Az automatikus skálázás 24 órán keresztül skálázza fel a kapacitáserőforrásokat, majd a normál szintre skálázza őket (ha a tartós tevékenység nem jelenik meg). Az automatikus skálázási költségek kezelése a virtuális magok maximális számának korlátozásával és/vagy az Azure-ban beállított költségkeretekkel. A díjszabási modellnek köszönhetően az automatikus skálázás a legjobban alkalmas a használat időnkénti nem tervezett növekedésének kezelésére.
  • Azure-adatforrások esetén lehetőség szerint keresse meg őket ugyanabban a régióban, mint a Fabric-bérlő. Ezzel elkerülhetők az Azure-beli kimenő díjak. Az adatforgalmi díjak minimálisak, de nagy léptékben jelentős, nem tervezett költségekkel járhatnak.

Biztonság, információvédelem és adatveszteség-megelőzés

A biztonság, az információvédelem és az adatveszteség-megelőzés (DLP) a tartalomkészítők, a felhasználók és a rendszergazdák közös feladata. Ez nem kis feladat, mert mindenhol vannak bizalmas információk: személyes adatok, ügyféladatok vagy ügyfél által létrehozott adatok, védett egészségügyi információk, szellemi tulajdon, védett szervezeti információk, csak hogy csak néhányat említsünk. A kormányzati, iparági és szerződéses szabályozások jelentős hatással lehetnek a biztonsággal kapcsolatos szabályozási irányelvekre és szabályzatokra.

A Power BI biztonsági tanulmánya kiváló forrás a megfontolandó szempontok megértéséhez, beleértve a Microsoft által kezelt szempontokat is. Ez a szakasz számos olyan témakört mutat be, amelyek kezeléséért az ügyfelek felelősek.

Felhasználói felelősségek

Egyes szervezetek arra kérik a Fabric-felhasználókat, hogy fogadjanak el önkiszolgáló felhasználói visszaigazolást. Ez egy dokumentum, amely ismerteti a felhasználó szervezeti adatok védelmével kapcsolatos feladatait és elvárásait.

A megvalósítás automatizálásának egyik módja a Microsoft Entra használati szabályzata. A felhasználónak meg kell tekintenie és el kell fogadnia a szabályzatot, mielőtt első alkalommal megnyithatja a Háló portált. Azt is megkövetelheti, hogy ismétlődően, például éves megújítással nyugtázza.

Adatbiztonság

A felhőalapú megosztott felelősségi modellben az adatok védelme mindig az ügyfél feladata. Önkiszolgáló adatplatform esetén az önkiszolgáló tartalomkészítők feladata a munkatársakkal megosztott tartalmak megfelelő védelme.

A COE-nak adott esetben dokumentációt és képzést kell nyújtania, hogy segítse a tartalomkészítőket az ajánlott eljárásokban (különösen az ultraérzékeny adatok kezelésére vonatkozó helyzetekben).

Rendszergazda istratorok segíthetnek az ajánlott eljárások követésében. Rendszergazda istratorok akkor is aggályokat vethetnek fel, ha olyan problémákat tapasztalnak, amelyek felderíthetők a munkaterületek kezelése, a felhasználói tevékenységek naplózása vagy az átjáró hitelesítő adatainak és felhasználóinak kezelése során. Számos bérlői beállítás is van, amelyek általában korlátozottak, kivéve néhány felhasználót (például a webes közzététel lehetőségét vagy az alkalmazások közzétételének lehetőségét a teljes szervezetben).

Külső vendégfelhasználók

A külső felhasználók – például partnerek, ügyfelek, szállítók és tanácsadók – gyakran előfordulnak egyes szervezeteknél, és ritkán fordulnak elő mások számára. A külső felhasználók kezelése szabályozási döntés.

A külső felhasználók hozzáférését a bérlői beállítások és bizonyos Microsoft Entra-azonosítók szabályozzák. A külső felhasználói szempontok részleteiért tekintse át a Power BI-tartalmak külső vendégfelhasználóknak való terjesztését a Microsoft Entra B2B tanulmányával.

Információvédelem és adatveszteség-megelőzés

A Fabric az alábbi módokon támogatja az információvédelem és az adatveszteség-megelőzés (DLP) képességeit.

Adattárolási hely

A földrajzi régión belüli adatok tárolására vonatkozó követelményekkel rendelkező szervezetek esetében a Fabric-kapacitás beállítható egy adott régióhoz , amely eltér a Fabric-bérlő otthoni régiójától.

Titkosítási kulcsok

A Microsoft transzparens kiszolgálóoldali titkosítással és a tanúsítványok automatikus rotálásával kezeli az inaktív adatok titkosítását a Microsoft adatközpontjaiban. A Prémium titkosítási kulcs felügyeletére vonatkozó jogszabályi követelményekkel rendelkező ügyfelek számára a Prémium szintű kapacitás konfigurálható az Azure Key Vault használatára. Az ügyfél által felügyelt kulcsok (más néven saját kulcs vagy BYOK) használata elővigyázatosság, hogy egy szolgáltató emberi hibája esetén az ügyféladatok ne legyenek közzétéve.

Vegye figyelembe, hogy a Felhasználónkénti Premium (PPU) csak akkor támogatja a BYOK-ot, ha az a teljes Fabric-bérlő esetében engedélyezve van.

Naplózás és figyelés

Kritikus fontosságú, hogy a naplózási adatok használatával elemezze a bevezetési erőfeszítéseket, megértse a használati mintákat, tájékoztassa a felhasználókat, támogassa a felhasználókat, mérsékelje a kockázatokat, javítsa a megfelelőséget, kezelje a licencköltségeket, és figyelje a teljesítményt. Az adatok naplózásának értékével kapcsolatos további információkért tekintse meg a naplózás és a figyelés áttekintését.

A naplózás és a monitorozás különböző módokon közelíthet meg a szerepkörétől és célkitűzéseitől függően. Az alábbi cikkek különböző szempontokat és tervezési tevékenységeket ismertetnek.

  • Jelentésszintű naplózás: Technikák, amelyekkel a jelentéskészítők megismerhetik, hogy mely felhasználók használják az általuk létrehozott, közzétett és megosztott jelentéseket.
  • Adatszintű naplózás: Olyan módszerek, amelyekkel az adatkészítők nyomon követhetik az általuk létrehozott, közzétett és megosztott adategységek teljesítményét és használati mintáit.
  • Bérlőszintű naplózás: A rendszergazdák kulcsfontosságú döntéseket és műveleteket hozhatnak egy végpontok közötti naplózási megoldás létrehozásához.
  • Bérlőszintű monitorozás: A rendszergazdák taktikai műveleteket hajthatnak végre a Power BI szolgáltatás figyelésére, beleértve a frissítéseket és a bejelentéseket.

REST API-k

A Power BI REST API-k és a Fabric REST API-k rengeteg információt nyújtanak a Fabric-bérlőről. Az adatok REST API-k használatával történő lekérésének fontos szerepet kell játszania a Fabric-implementációk kezelésében és szabályozásában. A REST API-k naplózáshoz való használatának tervezésével kapcsolatos további információkért lásd a bérlői szintű naplózást.

A naplózási adatok lekérésével naplózási megoldást hozhat létre, programozott módon kezelheti a tartalmakat, vagy növelheti a rutinműveletek hatékonyságát. Az alábbi táblázat néhány műveletet mutat be, amelyeket a REST API-k használatával végezhet el.

Művelet Dokumentációs erőforrás(ok)
Felhasználói tevékenységek naplózása REST API tevékenységesemények lekéréséhez
Munkaterületek, elemek és engedélyek naplózása Aszinkron metaadatok gyűjteménye REST API-k vizsgálata bérlői leltár beszerzéséhez
A teljes szervezet számára megosztott tartalom naplózása REST API a széles körben megosztott hivatkozások használatának ellenőrzéséhez
Bérlői beállítások naplózása REST API a bérlői beállítások ellenőrzéséhez
Tartalom közzététele REST API az elemek üzembe helyezéséhez egy üzembehelyezési folyamatból , vagy egy jelentés klónozása egy másik munkaterületre
Tartalom kezelése REST API szemantikai modell frissítéséhez vagy szemantikai modell tulajdonjogának átvételéhez
Átjáró-adatforrások kezelése REST API az átjáró adatforrásának hitelesítő adatainak frissítéséhez
Tartalom exportálása REST API jelentés exportálásához
Munkaterületek létrehozása REST API új munkaterület létrehozásához
Munkaterület-engedélyek kezelése REST API a felhasználói engedélyek munkaterülethez rendeléséhez
Munkaterület nevének vagy leírásának frissítése REST API a munkaterület attribútumainak frissítéséhez
Munkaterület visszaállítása REST API törölt munkaterület visszaállításához
Lekérdezési eredmény programozott lekérése szemantikai modellből REST API DAX-lekérdezések szemantikai modellen való futtatásához
Munkaterületek hozzárendelése kapacitáshoz REST API a munkaterületek kapacitáshoz rendeléséhez
Adatmodell programozott módosítása Táblázatos objektummodell (TOM) API
Power BI-tartalom beágyazása egyéni alkalmazásokba Power BI embedded analytics ügyfél API-k

Tipp.

Számos más Power BI REST API is létezik. A teljes listát a Power BI REST API-k használata című témakörben találja.

Változás tervezése

A Microsoft minden hónapban új Fabric-funkciókat és képességeket ad ki. A hatékonyság érdekében kulcsfontosságú, hogy a rendszerfelügyeletben részt vevő összes résztvevő naprakész maradjon. További információ: Bérlőszintű monitorozás.

Fontos

Ne becsülje alá a jelenlegi állapot megőrzésének fontosságát. Ha néhány hónappal lemarad a bejelentésekről, akkor nehéz lehet megfelelően kezelni a Hálót, és támogatni a felhasználókat.

Megfontolandó szempontok és főbb műveletek

Ellenőrzőlista – Megfontolandó szempontok és a rendszerfelügyeleti műveletek követése.

A rendszer felügyeletének javítása:

  • Ellenőrizze, hogy ki lehet hálóadminisztrátor: Ha lehetséges, csökkentse a Háló rendszergazdai szerepkörrel rendelkező személyek számát, ha többen vannak.
  • A PIM használata alkalmi rendszergazdák számára: Ha olyan személyekkel rendelkezik, akiknek időnként háló-rendszergazdai jogosultságokra van szükségük, fontolja meg a Privileged Identity Management (PIM) implementálását a Microsoft Entra ID-ban. Úgy tervezték, hogy időben hozzárendelje a néhány óra múlva lejáró szerepkör-engedélyeket.
  • Rendszergazdák betanítása: Ellenőrizze a hálófelügyeleti feladatok kezeléséhez szükséges képzések és dokumentációk állapotát. Győződjön meg arról, hogy a biztonsági mentési személy be van tanítva, hogy az igényeket időben, következetesen lehessen teljesíteni.

A Fabric szolgáltatás felügyeletének javítása:

  • Bérlői beállítások áttekintése: Tekintse át az összes bérlői beállítást, hogy azok igazodjanak az adatkultúra célkitűzéseihez, valamint az irányítási irányelvekhez és szabályzatokhoz. Ellenőrizze, hogy mely csoportok vannak hozzárendelve az egyes beállításokhoz.
  • A bérlői beállítások dokumentálása: Hozza létre a belső Fabric-közösség bérlői beállításainak dokumentációját, és tegye közzé a központi portálon. Adja meg, hogy a felhasználó mely csoportokat kérheti egy szolgáltatás használatához. A Bérlő lekérése Gépház REST API használatával hatékonyabbá teheti a folyamatot, és rendszeres időközönként pillanatképeket készíthet a beállításokról.
  • A Súgó lekérése hivatkozásainak testreszabása: Ha a felhasználói erőforrások létrejönnek, a Mentorálás és a felhasználói engedélyezés című cikkben leírtak szerint frissítse a bérlői beállítást, hogy testre szabja a Súgó beolvasása menüben található hivatkozásokat. A felhasználókat a dokumentációhoz, a közösséghez és a súgóhoz irányítja.

Felhasználói gépek és eszközök felügyeletének javítása:

  • Konzisztens előkészítési folyamat létrehozása: Tekintse át az új tartalomkészítők előkészítésének módját. Határozza meg, hogy az új szoftverkérelmek, például a Power BI Desktop és a felhasználói licencek (ingyenes, Pro vagy PPU) együtt kezelhetők-e. Egyszerűsítheti az előkészítést, mivel az új tartalomkészítők nem mindig tudják, mit kérjenek.
  • Felhasználói gép frissítéseinek kezelése: Győződjön meg arról, hogy a szoftver, az illesztőprogramok és a beállítások telepítése és frissítése automatikusan történik, hogy minden felhasználó azonos verziójú legyen.

Adatarchitektúra tervezése:

  • A végpontok közötti adatarchitektúra megjelenésének felmérése: Győződjön meg arról, hogy a következőkre van szüksége:
    • Hogyan használja jelenleg a Fabricet a szervezet különböző üzleti egységei, és hogyan szeretné használni a Fabricet. Állapítsa meg, hogy van-e rés.
    • Ha vannak olyan kockázatok, amelyeket kezelni kell.
    • Ha vannak olyan magas karbantartási helyzetek, amelyeket meg kell oldani.
    • Milyen adatforrások fontosak a Fabric-felhasználók számára, és hogyan dokumentálják és derítik fel őket.
  • Tekintse át a meglévő adatátjárókat: Megtudhatja, hogy milyen átjárókat használnak a szervezeten belül. Ellenőrizze, hogy az átjárógazdák és a felhasználók megfelelően vannak-e beállítva. Ellenőrizze, hogy ki támogatja az egyes átjárók használatát, és hogy van-e megbízható folyamat az átjárókiszolgálók naprakészen tartásához.
  • Személyes átjárók használatának ellenőrzése: Ellenőrizze a használatban lévő személyes átjárók számát, és hogy kik által. Ha jelentős a használat, lépéseket kell tennie a standard módú átjáró használata felé.

A felhasználói licencek kezelésének javítása:

  • Tekintse át a felhasználói licenc kérésének folyamatát: Tisztázza, hogy mi az a folyamat, beleértve az előfeltételeket is, hogy a felhasználók licenchez jussanak. Határozza meg, hogy vannak-e fejlesztések a folyamaton.
  • Az önkiszolgáló licencvásárlás kezelésének meghatározása: Annak tisztázása, hogy engedélyezve van-e az önkiszolgáló licencelés vásárlása. Frissítse a beállításokat, ha azok nem felelnek meg a licencek megvásárlására vonatkozó szándékának.
  • Ellenőrizze a felhasználói próbaverziók kezelésének módját: Ellenőrizze, hogy a felhasználói licenc próbaverziói engedélyezve vannak-e vagy le vannak-e tiltva. Vegye figyelembe, hogy minden felhasználói próbaidőszak felhasználónkénti prémium szintű. A próbaverzióra regisztráló ingyenes licenccel rendelkező felhasználókra, a Prémium felhasználónkénti próbaverzióra regisztráló Pro-felhasználókra pedig érvényesek.

A költségkezelés javítása:

  • Határozza meg a költségkezelési célkitűzéseket: Fontolja meg a költségek, a funkciók, a használati minták és az erőforrások hatékony kihasználtságának egyensúlyát. Ütemezzen legalább évente egy rutinfolyamatot a költségek kiértékeléséhez.
  • Tevékenységnapló-adatok beszerzése: Ellenőrizze, hogy rendelkezik-e hozzáféréssel a tevékenységnapló adataihoz a költségelemzéshez. Segítségével megtudhatja, hogy ki használja vagy nem használja a hozzájuk rendelt licencet.

A biztonság és az adatvédelem javítása:

  • Pontosan tisztázza az adatvédelemmel kapcsolatos elvárásokat: Győződjön meg arról, hogy az adatvédelemmel kapcsolatos elvárások, például a bizalmassági címkék használata, dokumentálva vannak és kommunikálnak a felhasználókkal.
  • A külső felhasználók kezelésének meghatározása: A Fabric-tartalom külső felhasználókkal való megosztására vonatkozó szervezeti szabályzatok megismerése és dokumentálása. Győződjön meg arról, hogy a Fabric beállításai támogatják a külső felhasználók házirendjeinek használatát.
  • Monitorozás beállítása: Vizsgálja meg a Felhőhöz készült Microsoft Defender-alkalmazások használatát a felhasználói viselkedés és tevékenységek nyomon követéséhez a Fabricben.

A naplózás és a figyelés javítása:

  • Naplózási igények megtervezése: Gyűjtse össze és dokumentálja a naplózási megoldás alapvető üzleti követelményeit. Fontolja meg a naplózás és a figyelés prioritásait. A naplózási megoldás típusával, az engedélyekkel, a használandó technológiákkal és az adatigényekkel kapcsolatos legfontosabb döntések meghozatala. Konzultáljon az informatikai rendszerrel annak tisztázásához, hogy mely naplózási folyamatok léteznek, és milyen követelmények vonatkoznak egy új megoldás létrehozására.
  • Vegye figyelembe a szerepköröket és a felelősségeket: Határozza meg, hogy mely csapatok vegyenek részt a naplózási megoldás létrehozásában, valamint a naplózási adatok folyamatos elemzésében.
  • Felhasználói tevékenység adatainak kinyerése és tárolása: Ha jelenleg nem nyeri ki és tárolja a nyers adatokat, kezdje el beolvasni a felhasználói tevékenység adatait.
  • Pillanatképek kinyerése és tárolása a bérlői leltár adatairól: Megkezdheti a metaadatok lekérését egy bérlői leltár létrehozásához, amely az összes munkaterületet és elemet ismerteti.
  • Felhasználók és csoportok adatainak pillanatképeinek kinyerése és tárolása: Megkezdheti a felhasználók, csoportok és szolgáltatásnevek metaadatainak lekérését.
  • Válogatott adatmodell létrehozása: Végezze el a nyers adatok adattisztítását és átalakítását egy olyan válogatott adatmodell létrehozásához, amely támogatja a naplózási megoldás elemzési jelentéseit.
  • Naplózási adatok elemzése és az eredményekre való reagálás: Elemzési jelentések létrehozása a válogatott naplózási adatok elemzéséhez. Tisztázza, hogy milyen műveleteket kell végrehajtania, ki és mikor.
  • További naplózási adatok belefoglalása: Idővel állapítsa meg, hogy más naplózási adatok hasznosak lennének-e a tevékenységnapló adatainak, például a biztonsági adatoknak a kiegészítéséhez.

Tipp.

További információ: Bérlőszintű naplózás.

Használja a REST API-kat:

  • Tervezze meg a REST API-k használatát: Fontolja meg, hogy milyen adatok kérhetők le leginkább a Power BI REST API-kból és a Fabric REST API-kból.
  • Fogalmi igazolás végrehajtása: Az adatigények, a technológiai lehetőségek és az engedélyek ellenőrzéséhez végezzen el egy kis koncepcióigazolást.

Megválaszolandó kérdések

A rendszerfelügyelet értékeléséhez használja az alábbihoz hasonló kérdéseket.

  • Engedélyezve vagy letiltva vannak az atipikus felügyeleti beállítások? Például a teljes szervezet számára engedélyezett a webes közzététel (erősen javasoljuk a funkció korlátozását).
  • A felügyeleti beállítások és szabályzatok összhangban vannak-e a felhasználó működési módjával, vagy gátolják az üzleti működést?
  • Van olyan folyamat, amely kritikusan értékeli az új beállításokat, és eldönti, hogyan kell beállítani őket? Vagy csak a legszigorúbb beállítások vannak beállítva elővigyázatosságból?
  • A Microsoft Entra biztonsági csoportjai kezelik, hogy ki mit tehet?
  • A központi csapatok rendelkeznek a hatékony naplózási és monitorozási eszközökkel?
  • A monitorozási megoldások az adategységekkel, a felhasználói tevékenységekkel vagy mindkettővel kapcsolatos információkat ábrázolják?
  • Végrehajthatók a naplózási és monitorozási eszközök? Vannak-e meghatározott küszöbértékek és műveletek, vagy a monitorozási jelentések egyszerűen leírják az adattulajdonban lévő adatokat?
  • Az Azure Log Analytics a Fabric-kapacitások részletes monitorozásához használatos (vagy tervezi) használatát? Az Azure Log Analytics lehetséges előnyei és költségei egyértelműek a döntéshozók számára?
  • Használnak bizalmassági címkéket és adatveszteség-megelőzési szabályzatokat? Ezek lehetséges előnyei és költségei egyértelműek a döntéshozók számára?
  • Ismerik a rendszergazdák a licencek aktuális számát és a licencköltségeket? A teljes BI-költség hány százaléka a Fabric-kapacitásra, valamint a Pro- és PPU-licencekre vonatkozik? Ha a szervezet csak Pro-licenceket használ Power BI-tartalmakhoz, a felhasználók száma és a használati minták költséghatékony váltást indokolhatnak a Power BI Premium- vagy Fabric-kapacitásra?

Érettségi szintek

Az alábbi érettségi szintek segítenek felmérni a Power BI-rendszer felügyeletének aktuális állapotát.

Szinten A rendszerfelügyelet állapota
100: Kezdeti • A bérlői beállításokat egy vagy több rendszergazda egymástól függetlenül konfigurálja a legjobb ítélőképességük alapján.

• Az architektúra igényei, például az átjárók és a kapacitások igény szerinti kielégítése. Azonban nincs stratégiai terv.

• A hálótevékenység naplói nincsenek használatban, vagy taktikai célokra szelektíven használják.
200: Megismételhető • A bérlői beállítások szándékosan összhangban vannak a meglévő szabályozási irányelvekkel és szabályzatokkal. Minden bérlői beállítást rendszeresen áttekintünk.

• Kevés konkrét rendszergazda van kiválasztva. Minden rendszergazda tisztában van azzal, hogy a felhasználók mit próbálnak elérni a Fabricben, ezért jó helyzetben vannak a felhasználók támogatásához.

• Egy jól meghatározott folyamat létezik a felhasználók számára, hogy licenceket és szoftvereket kérjenek. A kéreleműrlapok könnyen megtalálhatók a felhasználók számára. Az önkiszolgáló vásárlási beállítások meg vannak adva.

• A bizalmassági címkék a Microsoft 365-ben vannak konfigurálva. A címkék használata azonban továbbra is inkonzisztens marad. Az adatvédelem előnyeit a felhasználók nem ismerik jól.
300: Definiálva • A bérlői beállítások teljes mértékben dokumentálva vannak a központosított portálon, hogy a felhasználók hivatkozni tudjanak, beleértve a megfelelő csoportokhoz való hozzáférés kérését is.

• A rendszergazdák a folyamatosság, a stabilitás és a konzisztencia biztosítása érdekében kereszttanúsítást és dokumentációt is biztosítanak.

• A bizalmassági címkéket a rendszer következetesen hozzárendeli a tartalomhoz. A bizalmassági címkék adatvédelemre való használatának előnyeit a felhasználók értelmezik.

• Automatizált folyamat zajlik a Fabric tevékenységnaplóinak és API-adatainak biztonságos helyre való exportálásához a jelentéskészítéshez és a naplózáshoz.
400: Képes • Rendszergazda istratorok szorosan együttműködnek a COE-val és a szabályozási csapatokkal a Fabric felügyeletének biztosítása érdekében. A felhasználói felhatalmazás és a szabályozás egyensúlya sikeresen megvalósul.

• Az adatarchitektúra decentralizált kezelése (például átjárók vagy kapacitáskezelés) hatékonyan kezelhető az agilitás és az ellenőrzés egyensúlyának biztosítása érdekében.

• Az automatizált szabályzatok beállítása és aktív figyelése az Felhőhöz készült Microsoft Defender-alkalmazásokban adatveszteség-megelőzés céljából.

• A tevékenységnaplók és AZ API-adatok aktívan elemezve figyelik és naplózják a Fabric-tevékenységeket. Az adatok alapján proaktív műveletet hajtunk végre.
500: Hatékony • A Háló rendszergazdái szorosan együttműködnek a COE-val, és folyamatosan naprakészek maradnak. A Fabric termékcsapatának blogbejegyzéseit és kiadási terveit gyakran áttekintjük a közelgő változások tervezése érdekében.

• Rendszeres költségkezelési elemzéssel biztosítjuk, hogy a felhasználói igények költséghatékonyan teljesüljenek.

• A Fabric REST API a bérlői beállítási értékek rendszeres lekérésére szolgál.

• A tevékenységnaplók és API-adatok aktívan használják a bevezetési és szabályozási erőfeszítések tájékoztatására és javítására.

Kapcsolódó tartalom

A rendszerfelügyeletről és a Fabric felügyeletéről az alábbi forrásokban talál további információt.

A Microsoft Fabric bevezetési ütemtervsorozatának következő cikkében megismerheti a hatékony változáskezelést.