Del via

Veikart for innføring av Microsoft Fabric: Systemtilsyn

  • Artikkel

Merk

Denne artikkelen er en del av veikartserien for Innføring av Microsoft Fabric av artikler. Hvis du vil ha en oversikt over serien, kan du se Veikart for innføring av Microsoft Fabric.

Systemtilsyn , også kjent som Fabric Administration , er den pågående, daglige, administrative aktivitetene. Det er spesielt opptatt av:

  • Styring: Vedta retningslinjer og policyer for styring for å støtte selvbetjente scenarioer og bedriftsdata og forretningsintelligens (BI).
  • Brukermyndiggjøring: Tilrettelegge og støtte interne prosesser og systemer som styrker det interne brukerfellesskapet i den grad det er mulig, samtidig som de overholder organisasjonens forskrifter og krav.
  • Innføring: Tillat bredere organisatorisk innføring av Fabric med effektiv styring og praksis for databehandling.

Viktig

Dine organisatoriske datakulturmål gir veiledning for styringsbeslutningene dine, som igjen dikterer hvordan Fabric-administrasjonsaktiviteter finner sted og av hvem.

Systemtilsyn er et bredt og dypt tema. Målet med denne artikkelen er å introdusere noen av de viktigste hensynene og handlingene for å hjelpe deg med å lykkes med organisasjonens innføringsmål .

Fabric-administratorer

Fabric-administratorrollen er en definert rolle i Microsoft 365, som delegerer et delsett av administrasjonsaktiviteter. Globale Microsoft 365-administratorer er implisitt Fabric-administratorer. Power Platform-administratorer er også implisitt Fabric-administratorer.

En viktig styringsbeslutning er hvem du skal tilordne som Fabric-administrator. Det er en sentralisert rolle som påvirker hele leieren. Ideelt sett er det to til fire personer i organisasjonen som er i stand til å administrere Fabric. Administratorene bør operere i tett koordinering med Center of Excellence (COE).

Rolle med høy rettighet

Fabric-administratorrollen er en rolle med høy rettighetsrettighet fordi:

  • Brukeropplevelse: Innstillinger som administreres av en Fabric-administrator, har en betydelig effekt på brukerfunksjoner og brukeropplevelse. Hvis du vil ha mer informasjon, kan du se Styre leierinnstillinger.
  • Full sikkerhetstilgang: Fabric-administratorer kan oppdatere tilgangstillatelser for arbeidsområder i leieren. Resultatet er at en administrator kan gi tillatelse til å vise eller laste ned data og rapporter slik de passer. Hvis du vil ha mer informasjon, kan du se Styre leierinnstillinger.
  • Tilgang til personlig arbeidsområde: Stoffadministratorer kan få tilgang til innhold og styre det personlige arbeidsområdet til alle brukere.
  • Metadata: Stoffadministratorer kan vise alle tenantmetadata, inkludert alle brukeraktiviteter som forekommer i Fabric-portalen (beskrevet i delen Overvåking og overvåking nedenfor).

Viktig

Det er en risiko å ha for mange Fabric-administratorer. Det øker sannsynligheten for ikke-godkjent, utilsiktet eller inkonsekvent administrasjon av leieren.

Roller og ansvar

Hvilke typer aktiviteter som en administrator utfører daglig, vil variere mellom organisasjoner. Det som er viktig og prioritert i datakulturen, vil påvirke hva en administrator gjør for å støtte forretningsledet selvbetjening, administrert selvbetjening og bedriftsdata og BI-scenarier. Hvis du vil ha mer informasjon, kan du se artikkelen om eierskap og administrasjon av innhold.

Tips

Den beste typen person til å fungere som Fabric-administrator er en som har nok kunnskap om verktøyene og arbeidsbelastningene til å forstå hva selvbetjente brukere trenger for å oppnå. Med denne forståelsen kan administratoren balansere brukermpowerment og styring.

I tillegg til Fabric-administratoren finnes det andre roller som bruker termadministratoren. Tabellen nedenfor beskriver rollene som ofte og regelmessig brukes.

Rolle Scope Beskrivelse
Stoffadministrator Leier Administrerer leierinnstillinger og andre innstillinger i Stoff-portalen. Alle generelle referanser til administrator i denne artikkelen refererer til denne typen administrator.
Kapasitetsadministrator Én kapasitet Administrerer arbeidsområder og arbeidsbelastninger, og overvåker tilstanden til en stoffkapasitet.
Administrator for datagateway Én gateway Administrerer gatewayens datakildekonfigurasjon, legitimasjon og brukertilordninger. Kan også håndtere programvareoppdateringer for gateway (eller samarbeide med infrastrukturteamet om oppdateringer).
Arbeidsområdeadministrator Ett arbeidsområde Administrerer innstillinger og tilgang til arbeidsområdet.

Fabric økosystemet av arbeidsbelastninger er bredt og dypt. Det finnes mange måter fabric integreres med andre systemer og plattformer på. Fra tid til annen er det nødvendig å samarbeide med andre administratorer og IT-teknikere. Hvis du vil ha mer informasjon, kan du se Samarbeide med andre administratorer.

Resten av denne artikkelen gir en oversikt over de vanligste aktivitetene som en Fabric-administrator gjør. Den fokuserer på aktiviteter som er viktige å gjennomføre effektivt når du tar en strategisk tilnærming til organisasjonsadopsjon.

Tjenestebehandling

Å overvåke leieren er et viktig aspekt for å sikre at alle brukere har en god opplevelse med Power BI. Noen av de viktigste styringsansvarene til en Fabric-administrator inkluderer:

  • Leierinnstillinger: Kontroller hvilke Power BI-funksjoner som er aktivert, og hvilke brukere i organisasjonen.
  • Domener: Grupper sammen to eller flere arbeidsområder som har lignende egenskaper.
  • Arbeidsområder: Se gjennom og administrer arbeidsområder i leieren.
  • Innebyggingskoder: Styre hvilke rapporter som er publisert offentlig på Internett.
  • Organisasjonsvisualobjekter: Registrer og administrer visualobjekter for organisasjoner.
  • Azure-tilkoblinger: Integrer med Azure-tjenester for å gi ekstra funksjonalitet.

Hvis du vil ha mer informasjon, kan du se Leieradministrasjon.

Brukermaskiner og enheter

Innføringen av Fabric avhenger direkte av innholdsopprettere og forbrukere som har verktøyene og programmene de trenger. Her er noen viktige spørsmål du bør vurdere.

  • Hvordan vil brukere be om tilgang til nye verktøy? Vil tilgang til lisenser, data og opplæring være tilgjengelig for å hjelpe brukere med å bruke verktøy effektivt?
  • Hvordan vil innholdsforbrukere vise innhold som er publisert av andre?
  • Hvordan utvikler, administrerer og publiserer innhold for innholdsopprettere? Hva er kriteriene for å avgjøre hvilke verktøy og programmer som passer for hvilke brukstilfeller?
  • Hvordan installerer og konfigurerer du verktøy? Inkluderer dette relaterte forutsetninger og datatilkoblingskomponenter?
  • Hvordan administrerer du pågående oppdateringer for verktøy og programmer?

Hvis du vil ha mer informasjon, kan du se Brukerverktøy og enheter.

Arkitektur

Arkitekturen er knyttet til dataarkitektur, kapasitetsadministrasjon og arkitektur og administrasjon av datagateway i konteksten Fabric.

Dataarkitektur

Dataarkitektur refererer til prinsippene, praksisene og metodikkene som styrer og definerer hvilke data som samles inn, og hvordan de inntas, lagres, administreres, integreres, modellert og brukes.

Det er mange beslutninger om dataarkitektur å ta. Coe deltar ofte i utforming og planlegging av dataarkitektur. Det er vanlig at administratorer også involverer seg, spesielt når de administrerer databaser eller Azure-infrastruktur.

Viktig

Beslutninger om dataarkitektur har en betydelig innvirkning på stoffinnføring, brukertilfredshet og individuelle prosjektsuksessrater.

Noen vurderinger for dataarkitektur som påvirker innføring, omfatter:

  • Hvor passer Fabric inn i hele organisasjonens dataarkitektur? Finnes det andre eksisterende komponenter, for eksempel et virksomhetsdatalager (EDW) eller en datainnsjø som vil være viktig å ta hensyn til i planene?
  • Brukes Fabric ende-til-ende for dataforberedelse, datamodellering og datapresentasjon, eller brukes Fabric bare til noen av disse funksjonene?
  • Følges administrerte selvbetjente mønstre for å finne den beste balansen mellom data gjenbrukbarhet og rapportoppretterfleksibilitet?
  • Hvor bruker brukerne innholdet? Vanligvis er de tre viktigste måtene å levere innhold på: Stoffportalen, rapportserver for Power BI og innebygd i egendefinerte programmer. Microsoft Teams er i tillegg et praktisk alternativ for brukere som tilbringer mye tid i Teams.
  • Hvem er ansvarlig for å administrere og vedlikeholde dataarkitekturen? Er det et sentralisert team, eller et desentralisert team? Hvordan representeres COE-en i dette teamet? Kreves visse ferdigheter?
  • Hvilke datakilder er de viktigste? Hvilke typer data henter vi?
  • Hvilke valg for semantisk modelltilkobling og lagringsmodus (for eksempel Direct Lake, import, live-tilkobling, DirectQuery eller sammensatte modellrammeverk) passer best til brukstilfellene?
  • I hvilken grad oppmuntres data gjenbrukbarhet ved hjelp av lakehouses, varehus og delte semantiske modeller?
  • I hvilken grad er gjenbrukbarheten av dataforberedelseslogikk og avansert dataforberedelse oppmuntret ved hjelp av datasamlebånd, notatblokker og dataflyter?

Det er viktig for administratorer å bli fullt klar over Fabrics tekniske egenskaper , samt behovene og målene til sine interessenter - før de tar arkitektoniske beslutninger.

Tips

Kom inn i den gode vanen med å fullføre et teknisk konseptbevis (POC) for å teste ut antagelser og ideer. Noen organisasjoner kaller dem også mikroprosjekter når målet er å levere en liten arbeidsenhet. Målet med en poc er å håndtere ukjente og redusere risikoen så tidlig som mulig. En poc trenger ikke å kaste arbeid, men det bør være smalt i omfang. Anbefalte fremgangsmåter, som beskrevet i artikkelen om veiledning og brukeraktivering , er en annen nyttig måte å hjelpe innholdsopprettere med viktige arkitektoniske beslutninger på.

Kapasitetsadministrasjon

Kapasiteten inkluderer funksjoner og funksjoner for å levere analyseløsninger i stor skala. Det finnes to typer fabric-organisasjonslisenser: Premium per bruker (PPU) og kapasitet. Det finnes flere typer kapasitetslisenser. Typen kapasitetslisens bestemmer hvilke Fabric-arbeidsbelastninger som støttes.

Viktig

Til tider refererer denne artikkelen til Power BI Premium eller dets kapasitetsabonnementer (P SKU-er). Vær oppmerksom på at Microsoft for øyeblikket konsoliderer kjøpsalternativer og trekker tilbake Power BI Premium per kapasitet sKU-er. Nye og eksisterende kunder bør vurdere å kjøpe Fabric-kapasitetsabonnementer (F SKU-er) i stedet.

Hvis du vil ha mer informasjon, kan du se Viktige oppdateringer som kommer til Power BI Premium-lisensiering og vanlige spørsmål om Power BI Premium.

Bruk av kapasitet kan spille en viktig rolle i strategien for å opprette, administrere, publisere og distribuere innhold. Noen av de viktigste grunnene til å investere i kapasitet inkluderer:

  • Ubegrenset distribusjon av Power BI-innhold til et stort antall skrivebeskyttede brukere. Innholdsforbruk av brukere med en gratis Power BI-lisens er bare tilgjengelig i Premium-kapasitet, ikke PPU. Innholdsforbruk av gratisbrukere er også tilgjengelig med en F64 Fabric-kapasitetslisens eller høyere.
  • Tilgang til stoffopplevelser for å produsere ende-til-ende-analyser.
  • Utrullingssamlebånd for å administrere publisering av innhold til utviklings-, test- og produksjonsarbeidsområder. De anbefales på det sterkeste for kritisk innhold for å forbedre utgivelsesstabiliteten.
  • XMLA-endepunkt, som er en bransjestandardprotokoll for administrasjon og publisering av en semantisk modell, eller spørre den semantiske modellen fra et xmla-kompatibelt verktøy.
  • Økt modellstørrelsesgrenser, inkludert støtte for stor semantisk modell .
  • Hyppigere dataoppdateringer.
  • Lagring av data i et bestemt geografisk område som er forskjellig fra hjemområdet.

Listen ovenfor er ikke all-inclusive. Hvis du vil ha en fullstendig liste, kan du se Power BI Premium-funksjoner.

Administrer stoffkapasitet

Å overvåke tilstanden til Fabric-kapasiteten er en viktig pågående aktivitet for administratorer. Hver SKU for kapasitet inkluderer et sett med ressurser. Kapasitetsenheter brukes til å måle databehandlingsressurser for hver SKU.

Forsiktig!

Mangel på administrasjon og konsekvent overskridelse av grensene for kapasitetsressursene kan ofte føre til ytelsesutfordringer og utfordringer med brukeropplevelsen. Begge utfordringene, hvis de ikke håndteres riktig, kan bidra til negativ innvirkning på adopsjonsarbeidet.

Forslag til administrasjon av stoffkapasitet:

  • Definer hvem som er ansvarlig for å administrere kapasiteten. Bekreft rollene og ansvarsoppgavene slik at det er klart hvilke handlinger som skal utføres, hvorfor, når og av hvem.
  • Opprett et bestemt sett med vilkår for innhold som skal publiseres til kapasitet. Det er spesielt relevant når en enkelt kapasitet brukes av flere forretningsenheter fordi potensialet finnes for å forstyrre andre brukere hvis kapasiteten ikke er godt administrert. Vurder å kreve en gjennomgang av anbefalte fremgangsmåter (for eksempel rimelig semantisk modellstørrelse og effektive beregninger) før du publiserer nytt innhold til en produksjonskapasitet.
  • Bruk regelmessig måledataappen for stoffkapasitet til å forstå ressursutnyttelse og mønstre for kapasiteten. Viktigst av alt, se etter konsekvente mønstre for overutnyttelse, noe som vil bidra til brukeravbrudd. En analyse av bruksmønstre bør også gjøre deg oppmerksom på om kapasiteten er underutnyttet, noe som indikerer at mer verdi kan oppnås fra investeringen.
  • Angi leierinnstillingen slik at Fabric varsler deg om kapasiteten blir overbelastet, eller hvis det oppstår et strømbrudd eller en hendelse.

Autoskaler

Autoskala er ment å håndtere sporadiske eller uventede serier i kapasitetsbruksnivåer. Autoskala kan reagere på disse utbruddene ved automatisk å øke CPU-ressursene for å støtte den økte arbeidsbelastningen.

Automatisert oppskalering reduserer risikoen for ytelses- og brukeropplevelsesutfordringer i bytte mot en økonomisk innvirkning. Hvis kapasiteten ikke er godt administrert, kan autoskala utløse oftere enn forventet. I dette tilfellet kan måledataappen hjelpe deg med å fastslå underliggende problemer og utføre kapasitetsplanlegging.

Desentralisert kapasitetsadministrasjon

Kapasitetsadministratorer er ansvarlige for å tilordne arbeidsområder til en bestemt kapasitet.

Vær oppmerksom på at administratorer for arbeidsområdet også kan tilordne et arbeidsområde til PPU hvis administratoren for arbeidsområdet har en PPU-lisens. Det krever imidlertid at alle andre brukere av arbeidsområdet også må ha en PPU-lisens for å samarbeide på, eller vise, Power BI-innhold i arbeidsområdet. Andre fabric-arbeidsbelastninger kan ikke inkluderes i et arbeidsområde som er tilordnet PPU.

Det er mulig å sette opp flere kapasiteter for å legge til rette for desentralisert administrasjon av ulike forretningsenheter. Desentraliserende styring av visse aspekter av Fabric er en flott måte å balansere smidighet og kontroll på.

Her er et eksempel som beskriver én måte du kan administrere kapasiteten på.

  • Kjøp en P3-kapasitetsnode i Microsoft 365. Det inkluderer 32 virtuelle kjerner (v-kjerner).
  • Bruk 16 v-kjerner til å opprette den første kapasiteten. Den vil bli brukt av salgsteamet.
  • Bruk 8 v-kjerner til å opprette den andre kapasiteten. Den vil bli brukt av Operasjoner-teamet.
  • Bruk de resterende 8 v-kjernene til å opprette den tredje kapasiteten. Det vil støtte generell bruk.

Det forrige eksemplet har flere fordeler.

  • Separate kapasitetsadministratorer kan konfigureres for hver kapasitet. Derfor legger det til rette for desentraliserte administrasjonssituasjoner.
  • Hvis en kapasitet ikke er godt administrert, er effekten bare begrenset til denne kapasiteten. De andre kapasitetene påvirkes ikke.
  • Fakturering og tilbakeføring til andre forretningsenheter er enkelt.
  • Ulike arbeidsområder kan enkelt tilordnes til de separate kapasitetene.

Det forrige eksemplet har imidlertid også ulemper.

  • Grensene per kapasitet er lavere. Den maksimale minnestørrelsen som er tillatt for semantiske modeller, er ikke hele P3-kapasitetsnodestørrelsen som ble kjøpt. I stedet er det den tilordnede kapasitetsstørrelsen der den semantiske modellen driftes.
  • Det er mer sannsynlig at en av de mindre kapasitetene må skaleres opp på et tidspunkt.
  • Det finnes flere kapasiteter å administrere i leieren.

Merk

Ressurser for Power BI Premium per kapasitet kalles v-kjerner. En fabric-kapasitet refererer imidlertid til dem som kapasitetsenheter (CUer). Skalaen for CUs og v-kjerner er forskjellig for hver SKU. Hvis du vil ha mer informasjon, kan du se dokumentasjonen for stofflisensiering .

Arkitektur og administrasjon av datagateway

En datagateway forenkler sikker og effektiv overføring av data mellom organisatoriske datakilder og Fabric-tjenesten. En datagateway er nødvendig for datatilkobling til lokale tjenester eller skytjenester når en datakilde er:

  • Plassert i virksomhetsdatasenteret.
  • Konfigurert bak en brannmur.
  • I et virtuelt nettverk.
  • Innenfor en virtuell maskin.

Det finnes tre typer gatewayer.

  • Lokal datagateway (standardmodus) er en gateway-tjeneste som støtter tilkoblinger til registrerte datakilder som mange brukere kan bruke. Installasjoner og oppdateringer for gatewayprogramvaren installeres på en maskin som administreres av kunden.
  • Lokal datagateway (personlig modus) er en gateway-tjeneste som bare støtter dataoppdatering. Denne gatewaymodusen er vanligvis installert på PC-en til en innholdsoppretter. Den støtter bare bruk av én bruker. Den støtter ikke live-tilkobling eller DirectQuery-tilkoblinger.
  • Virtuell nettverksdatagateway er en Microsoft-administrert tjeneste som støtter tilkobling for mange brukere. Nærmere bestemt støtter den tilkobling for semantiske modeller og dataflyter som er lagret i arbeidsområder som er tilordnet Premium-kapasitet eller Premium per bruker.

Tips

Beslutningen om hvem som kan installere gateway-programvare er en styringsbeslutning. For de fleste organisasjoner bør bruk av datagatewayen i standardmodus eller en virtuell nettverksdatagateway på det sterkeste oppmuntres. De er langt mer skalerbare, håndterbare og overvåkbare enn datagatewayer i personlig modus.

Desentralisert gateway-administrasjon

Lokal datagateway (standardmodus) og virtuell nettverksdatagateway støtter bestemte datakildetyper som kan registreres, sammen med tilkoblingsdetaljer og hvordan legitimasjon lagres. Brukere kan få tillatelse til å bruke gateway-datakilden, slik at de kan planlegge en oppdatering eller kjøre DirectQuery-spørringer.

Enkelte aspekter ved gateway-administrasjon kan gjøres effektivt på desentralisert basis for å balansere smidighet og kontroll. Operasjoner-gruppen kan for eksempel ha en gateway dedikert til teamet av selvbetjente innholdsopprettere og dataeiere.

Desentralisert gateway-administrasjon fungerer best når det er en felles innsats som følger.

Administrert av desentraliserte dataeiere:

  • Informasjon om tilkoblingsinformasjon og personvernnivåer for avdelingsdatakilde.
  • Lagret legitimasjon for avdelingsdatakilde (inkludert ansvar for å oppdatere rutinemessige passordendringer).
  • Avdelingsdatakildebrukere som har tillatelse til å bruke hver datakilde.

Administreres av sentraliserte dataeiere (inkluderer datakilder som brukes bredt på tvers av organisasjonen. Ledelsen er sentralisert for å unngå dupliserte datakilder):

  • Sentralisert informasjon om datakildetilkobling og personvernnivåer.
  • Sentralisert datakilde lagret legitimasjon (inkludert ansvar for å oppdatere rutinemessige passordendringer).
  • Sentraliserte datakildebrukere som har tillatelse til å bruke hver datakilde.

Administrert av IT:

  • Gateway-programvareoppdateringer (gatewayoppdateringer utgis vanligvis månedlig).
  • Installasjon av drivere og egendefinerte koblinger (de samme som er installert på brukermaskiner).
  • Gateway-klyngebehandling (antall maskiner i gateway-klyngen for høy tilgjengelighet, nødoppretting og for å eliminere ett enkelt feilpunkt, noe som kan føre til betydelige brukerforstyrrelser).
  • Serverbehandling (for eksempel operativsystem, RAM, CPU eller nettverkstilkobling).
  • Administrasjon og sikkerhetskopiering av gateway-krypteringsnøkler.
  • Overvåking av gatewaylogger for å vurdere når oppskalering eller utskalering er nødvendig.
  • Varsler om nedetid eller vedvarende lave ressurser på gatewaymaskinen.

Tips

Å tillate et desentralisert team å administrere visse aspekter av gatewayen betyr at de kan bevege seg raskere. Avveiningen av desentralisert gateway-administrasjon betyr at du kjører flere gateway-servere, slik at hver av dem kan være dedikert til et bestemt område i organisasjonen. Hvis gateway-administrasjon håndteres fullstendig av IT, er det viktig å ha en god prosess på plass for raskt å håndtere forespørsler om å legge til datakilder og bruke brukeroppdateringer.

Brukerlisenser

Hver bruker trenger en kommersiell lisens, som er integrert med en Microsoft Entra-identitet. Brukerlisensen kan være Gratis, Pro eller Premium per bruker (PPU).

En brukerlisens innhentes via et abonnement, som godkjenner et bestemt antall lisenser med en start- og sluttdato.

Merk

Selv om hver bruker krever en lisens, kreves det bare en Pro- eller PPU-lisens for å dele Power BI-innhold. Brukere med en gratis lisens kan opprette og dele stoffinnhold annet enn Power BI-elementer.

Det finnes to fremgangsmåter for å anskaffe abonnementer.

  • Sentralisert: Faktureringsadministrator for Microsoft 365 kjøper et abonnement for Pro eller PPU. Det er den vanligste måten å administrere abonnementer og tilordne lisenser på.
  • Desentralisert: Individuelle avdelinger kjøper et abonnement via selvbetjent innkjøp.

Selvbetjent innkjøp

En viktig styringsbeslutning gjelder i hvilken grad selvbetjent innkjøp vil bli tillatt eller oppmuntret.

Selvbetjent innkjøp er nyttig for:

  • Større organisasjoner med desentraliserte forretningsenheter som har innkjøpsmyndighet og ønsker å håndtere betaling direkte med et kredittkort.
  • Organisasjoner som har til hensikt å gjøre det så enkelt som mulig å kjøpe abonnementer på en månedlig forpliktelse.

Vurder å deaktivere selvbetjent kjøp når:

  • Sentraliserte innkjøpsprosesser er på plass for å oppfylle forskriftsmessige krav, sikkerhet og styringskrav.
  • Rabatterte priser oppnås gjennom en Microsoft Foretaksavtale (EA).
  • Eksisterende prosesser er på plass for å håndtere konserninterne tilbakeføringer.
  • Eksisterende prosesser er på plass for å håndtere gruppebaserte lisensieringstilordninger.
  • Forutsetninger kreves for å få en lisens, for eksempel godkjenning, begrunnelse, opplæring eller et krav til styringspolicy.
  • Det er et gyldig behov, for eksempel et forskriftsmessig krav, for å kontrollere tilgangen nøye.

Prøveversjoner av brukerlisens

En annen viktig styringsbeslutning er om prøveversjoner av brukerlisenser er tillatt. Prøveversjoner er aktivert som standard. Det betyr at når innhold deles med en kollega, blir de bedt om å starte en prøveversjon for å vise innholdet (hvis innholdet ikke befinner seg i et arbeidsområde som støttes av kapasitet) hvis mottakeren ikke har en Pro- eller PPU-lisens. Prøveversjonen er ment å være en bekvemmelighet som gjør det mulig for brukere å fortsette med normal arbeidsflyt.

Vanligvis anbefales ikke deaktivering av prøveversjoner. Det kan oppmuntre brukere til å søke løsninger, kanskje ved å eksportere data eller arbeide utenfor støttede verktøy og prosesser.

Vurder å deaktivere prøveversjoner bare når:

  • Det er alvorlige kostnadsbekymringer som ville gjøre det usannsynlig å gi full lisenser på slutten av prøveperioden.
  • Forutsetninger kreves for å få en lisens (for eksempel godkjenning, begrunnelse eller et opplæringskrav). Det er ikke tilstrekkelig å oppfylle dette kravet i prøveperioden.
  • Det er et gyldig behov, for eksempel et forskriftsmessig krav, for å kontrollere tilgangen til Fabric-tjenesten nøye.

Tips

Ikke introduser for mange barrierer for å få en Fabric-lisens. Brukere som trenger å få arbeidet gjort, vil finne en måte, og på den måten kan det innebære midlertidige løsninger som ikke er ideelle. Uten en lisens til å bruke Fabric, kan for eksempel folk stole altfor mye på å dele filer på et filsystem eller via e-post når betydelig bedre tilnærminger er tilgjengelige.

Kostnadsstyring

Administrasjon og optimalisering av kostnadene for skytjenester, for eksempel Fabric, er en viktig aktivitet. Her er flere aktiviteter du kan vurdere.

  • Analyser hvem som bruker , og mer til poenget, ikke bruker - sine tildelte Fabric-lisenser og gjør nødvendige justeringer. Stoffbruk analyseres ved hjelp av aktivitetsloggen.
  • Analyser kapasitetens kostnadseffektivitet eller Premium per bruker. I tillegg til tilleggsfunksjonene kan du utføre en kostnads-/fordelsanalyse for å avgjøre om kapasitetslisensiering er mer kostnadseffektivt når det finnes et stort antall forbrukere.
  • Overvåk og administrer stoffkapasitet nøye. Hvis du forstår bruksmønstre over tid, kan du forutsi når du skal kjøpe mer kapasitet. Du kan for eksempel velge å skalere opp én enkelt kapasitet fra en P1 til P2, eller skalere ut fra én P1-kapasitet til to P1-kapasiteter.
  • Hvis det er noen ganger pigger i bruksnivået, anbefales bruk av autoskala med Stoff for å sikre at brukeropplevelsen ikke avbrytes. Autoskala skalerer opp kapasitetsressurser i 24 timer, og skalerer dem deretter ned til normale nivåer (hvis vedvarende aktivitet ikke finnes). Administrer autoskalakostnader ved å begrense maksimalt antall v-kjerner, og/eller med forbruksgrenser angitt i Azure. På grunn av prismodellen er autoskala best egnet til å håndtere sporadiske ikke-planlagte økninger i bruken.
  • For Azure-datakilder finner du dem samtidig i samme område som Fabric-leieren når det er mulig. Det vil unngå å pådra seg Azure-utgående kostnader. Datautgående belastninger er minimale, men i stor skala kan det legge opp til betydelige ikke-planlagte kostnader.

Sikkerhet, informasjonsbeskyttelse og hindring av datatap

Sikkerhet, informasjonsbeskyttelse og hindring av datatap (DLP) er felles ansvar blant alle innholdsopprettere, forbrukere og administratorer. Det er ingen liten oppgave fordi det er sensitiv informasjon overalt: personopplysninger, kundedata eller kundeforfattede data, beskyttet tilstandsinformasjon, immaterielle rettigheter, rettighetsbeskyttet organisasjonsinformasjon, bare for å nevne noen. Statlige, bransjemessige og kontraktsmessige forskrifter kan ha en betydelig innvirkning på styringsretningslinjene og policyene du oppretter knyttet til sikkerhet.

Hvitboken for Power BI-sikkerhet er en utmerket ressurs for å forstå bredden av hensyn, inkludert aspekter som Microsoft administrerer. Denne delen vil introdusere flere emner som kundene er ansvarlige for å administrere.

Brukeransvar

Noen organisasjoner ber Fabric-brukere om å godta en selvbetjent brukeranerkjennelse. Det er et dokument som forklarer brukerens ansvar og forventninger for å sikre organisasjonsdata.

Én måte å automatisere implementeringen på, er med en policy for bruk av Microsoft Entra. Brukeren må vise og godta policyen før de får lov til å gå til Stoff-portalen for første gang. Du kan også kreve at den anerkjennes regelmessig, for eksempel en årlig fornyelse.

Datasikkerhet

I en skymodell for delt ansvar er det alltid kundens ansvar å sikre dataene. Med en selvbetjent dataplattform har selvbetjente innholdsopprettere ansvar for å sikre innholdet de delte med kolleger på riktig måte.

Coe bør gi dokumentasjon og opplæring der det er relevant for å hjelpe innholdsopprettere med anbefalte fremgangsmåter (spesielt situasjoner for å håndtere ultrasensitive data).

Administratorer kan hjelpe ved å følge anbefalte fremgangsmåter selv. Administratorer kan også ta opp bekymringer når de ser problemer som kan oppdages når de administrerer arbeidsområder, overvåker brukeraktiviteter eller administrerer gatewaylegitimasjon og brukere. Det finnes også flere leierinnstillinger som vanligvis er begrenset bortsett fra noen få brukere (for eksempel muligheten til å publisere på nettet eller muligheten til å publisere apper til hele organisasjonen).

Eksterne gjestebrukere

Eksterne brukere, for eksempel partnere, kunder, leverandører og konsulenter, er en vanlig forekomst for enkelte organisasjoner og sjeldne for andre. Hvordan du håndterer eksterne brukere er en styringsbeslutning.

Ekstern brukertilgang styres av leierinnstillinger og bestemte Microsoft Entra ID-innstillinger. Hvis du vil ha mer informasjon om eksterne brukerhensyn, kan du se distribuere Power BI-innholdet til eksterne gjestebrukere ved hjelp av Microsoft Entra B2B-hvitboken .

Hindring av informasjonsbeskyttelse og hindring av datatap

Fabric støtter funksjoner for informasjonsbeskyttelse og hindring av datatap (DLP) på følgende måter.

Datalagring

For organisasjoner med krav om å lagre data i et geografisk område, kan stoffkapasitet angis for et bestemt område som er forskjellig fra hjemområdet til Fabric-leieren.

Krypteringsnøkler

Microsoft håndterer kryptering av data i ro i Microsoft-datasentre med gjennomsiktig kryptering på serversiden og automatisk rotasjon av sertifikater. For kunder med forskriftsmessige krav til å administrere Premium-krypteringsnøkkelen selv, kan Premium-kapasiteten konfigureres til å bruke Azure Key Vault. Bruk av kundeadministrerte nøkler , også kjent som bring-your-own-key eller BYOK , er en forholdsregel for å sikre at kundedata ikke kan vises i tilfelle en menneskelig feil av en tjenesteoperatør.

Vær oppmerksom på at Premium per bruker (PPU) bare støtter BYOK når det er aktivert for hele Fabric-leieren.

Overvåking og overvåking

Det er viktig at du bruker overvåkingsdata til å analysere innføringstiltak, forstå bruksmønstre, lære opp brukere, støtte brukere, redusere risiko, forbedre samsvar, administrere lisenskostnader og overvåke ytelsen. Hvis du vil ha mer informasjon om hvorfor overvåking av dataene dine er verdifullt, kan du se Oversikt over overvåking og overvåking.

Det finnes ulike måter å nærme seg overvåking og overvåking på, avhengig av hvilken rolle du har og målene dine. Følgende artikler beskriver ulike hensyn og planleggingsaktiviteter.

  • Overvåking på rapportnivå: Teknikker som rapportopprettere kan bruke til å forstå hvilke brukere som bruker rapportene de oppretter, publiserer og deler.
  • Overvåking på datanivå: Metoder som dataopprettere kan bruke til å spore ytelses- og bruksmønstrene til dataressurser de oppretter, publiserer og deler.
  • Overvåking på leiernivå: Viktige beslutninger og handlinger administratorer kan ta for å opprette en ende-til-ende-overvåkingsløsning.
  • Overvåking på leiernivå: Taktiske handlinger administratorer kan utføre for å overvåke Power Bi-tjeneste, inkludert oppdateringer og kunngjøringer.

REST-API-er

Rest-API-ene for Power BI og REST-API-ene for Fabric gir et vell av informasjon om Fabric-leieren. Henting av data ved hjelp av REST-API-ene bør spille en viktig rolle i administrasjon og styring av en fabric-implementering. Hvis du vil ha mer informasjon om planlegging for bruk av REST-API-er for overvåking, kan du se Overvåking på leiernivå.

Du kan hente overvåkingsdata for å bygge en overvåkingsløsning, administrere innhold programmatisk eller øke effektiviteten av rutinemessige handlinger. Tabellen nedenfor viser noen handlinger du kan utføre med REST-API-ene.

Handling Dokumentasjonsressurser
Overvåke brukeraktiviteter REST-API for å få aktivitetshendelser
Overvåke arbeidsområder, elementer og tillatelser Samling av asynkrone metadata som skanner REST-API-er for å få en leierbeholdning
Overvåke innhold som er delt med hele organisasjonen REST-API for å kontrollere bruken av mye delte koblinger
Innstillinger for overvåkingsleietaker REST-API for å kontrollere leierinnstillinger
Publiser innhold REST-API for å distribuere elementer fra et utrullingsforløp eller klone en rapport til et annet arbeidsområde
Behandle innhold REST-API for å oppdatere en semantisk modell eller overta eierskapet til en semantisk modell
Behandle gateway-datakilder REST-API for å oppdatere legitimasjon for en gateway-datakilde
Eksporter innhold REST-API for å eksportere en rapport
Opprett arbeidsområder REST-API for å opprette et nytt arbeidsområde
Behandle arbeidsområdetillatelser REST-API for å tilordne brukertillatelser til et arbeidsområde
Oppdater arbeidsområdenavn eller beskrivelse REST-API for å oppdatere arbeidsområdeattributter
Gjenopprette et arbeidsområde REST-API for å gjenopprette et slettet arbeidsområde
Hente et spørringsresultat programmatisk fra en semantisk modell REST-API for å kjøre en DAX-spørring mot en semantisk modell
Tilordne arbeidsområder til kapasitet REST-API for å tilordne arbeidsområder til kapasitet
Endre en datamodell programmatisk API for tabellobjektmodell (TOM)
Bygg inn Power BI-innhold i egendefinerte programmer Klient-API-er for innebygd analyse i Power BI

Tips

Det finnes mange andre REST-API-er for Power BI. Hvis du vil ha en fullstendig liste, kan du se Bruke REST-API-ene for Power BI.

Planlegging for endring

Hver måned lanserer Microsoft nye Fabric-funksjoner og -funksjoner. For å være effektiv, er det avgjørende at alle som er involvert i systemtilsyn forblir oppdaterte. Hvis du vil ha mer informasjon, kan du se Overvåking på leiernivå.

Viktig

Ikke undervurder viktigheten av å holde seg oppdatert. Hvis du får noen måneder etter på kunngjøringer, kan det bli vanskelig å administrere Fabric og støtte brukerne på riktig måte.

Vurderinger og viktige tiltak

Sjekkliste – vurderinger og viktige handlinger du kan utføre for systemtilsyn følger.

Forbedre systemtilsyn:

  • Bekreft hvem som har tillatelse til å være fabric-administrator: Hvis det er mulig, kan du redusere antall personer som er tildelt Fabric-administratorrollen hvis det er mer enn noen få personer.
  • Bruk PIM for sporadiske administratorer: Hvis du har personer som av og til trenger Fabric-administratorrettigheter, bør du vurdere å implementere Privileged Identity Management (PIM) i Microsoft Entra ID. Den er utformet for å tilordne akkurat i tide rolletillatelser som utløper etter noen timer.
  • Lære opp administratorer: Kontroller statusen for kryssopplæring og dokumentasjon på plass for håndtering av stoffadministrasjonsansvar. Sørg for at en sikkerhetskopiperson er opplært, slik at behov kan oppfylles i tide, på en konsekvent måte.

Forbedre administrasjon av Fabric-tjenesten:

  • Se gjennom leierinnstillinger: Foreta en gjennomgang av alle leierinnstillinger for å sikre at de er i samsvar med datakulturmål og retningslinjer og retningslinjer for styring . Kontroller hvilke grupper som er tilordnet for hver innstilling.
  • Dokumenter leierinnstillingene: Opprett dokumentasjon av leierinnstillingene for det interne Fabric-fellesskapet, og legg det ut i den sentraliserte portalen. Inkluder hvilke grupper en bruker må be om for å kunne bruke en funksjon. Bruk REST-API-en hent tenanten Innstillinger for å gjøre prosessen mer effektiv, og opprett øyeblikksbilder av innstillingene regelmessig.
  • Tilpass koblingene Hent hjelp : Når brukerressurser opprettes, som beskrevet i artikkelen Om veiledning og brukeraktivering , oppdaterer du leierinnstillingen for å tilpasse koblingene under menyalternativet Få hjelp . Det vil lede brukere til dokumentasjonen, fellesskapet og hjelpen.

Forbedre administrasjon av brukermaskiner og enheter:

  • Opprett en konsekvent pålastingsprosess: Se gjennom prosessen for hvordan pålasting av nye innholdsopprettere håndteres. Bestem om nye forespørsler om programvare, for eksempel Power BI Desktop, og brukerlisenser (gratis, Pro eller PPU) kan håndteres sammen. Det kan forenkle pålasting siden nye innholdsopprettere ikke alltid vet hva de skal be om.
  • Behandle oppdateringer for brukermaskin: Sørg for at en automatisert prosess er på plass for å installere og oppdatere programvare, drivere og innstillinger for å sikre at alle brukere har samme versjon.

Planlegging av dataarkitektur:

  • Vurder hvordan ende-til-ende-dataarkitekturen din ser ut: Kontroller at du er klar over:
    • Hvordan Fabric for øyeblikket brukes av de ulike forretningsenhetene i organisasjonen kontra hvordan du vil at Fabric skal brukes. Finn ut om det er et mellomrom.
    • Hvis det er noen risikoer som bør løses.
    • Hvis det er noen situasjoner med høyt vedlikehold som skal håndteres.
    • Hvilke datakilder som er viktige for Fabric-brukere, og hvordan de er dokumentert og oppdaget.
  • Se gjennom eksisterende datagatewayer: Finn ut hvilke gatewayer som brukes i hele organisasjonen. Kontroller at gatewayadministratorer og -brukere er riktig angitt. Kontroller hvem som støtter hver gateway, og at det finnes en pålitelig prosess for å holde gatewayserverne oppdatert.
  • Kontroller bruken av personlige gatewayer: Kontroller antall personlige gatewayer som er i bruk, og av hvem. Hvis det er betydelig bruk, må du ta skritt for å gå mot bruk av standardmodusgatewayen.

Forbedre administrasjon av brukerlisenser:

  • Se gjennom prosessen for å be om en brukerlisens: Klargjør hva prosessen er, inkludert eventuelle forutsetninger, for brukere å få en lisens. Bestem om det er forbedringer som skal gjøres i prosessen.
  • Bestem hvordan du skal håndtere selvbetjent lisenskjøp: Avklar om selvbetjent lisensieringskjøp er aktivert. Oppdater innstillingene hvis de ikke samsvarer med intensjonene dine for hvordan lisenser kan kjøpes.
  • Bekreft hvordan prøveversjoner av brukere håndteres: Kontroller at prøveversjoner av brukerlisens er aktivert eller deaktivert. Vær oppmerksom på at alle prøveversjoner av brukere er Premium per bruker. De gjelder for gratis lisensierte brukere som registrerer seg for en prøveversjon, og Pro-brukere registrerer seg for en prøveversjon av Premium per bruker.

Forbedre kostnadsstyring:

  • Bestem målene for kostnadsstyring: Vurder hvordan du balanserer kostnader, funksjoner, bruksmønstre og effektiv utnyttelse av ressurser. Planlegg en rutinemessig prosess for å evaluere kostnader, minst årlig.
  • Hent aktivitetsloggdata: Sørg for at du har tilgang til aktivitetsloggdataene for å hjelpe til med kostnadsanalyse. Den kan brukes til å forstå hvem som er eller ikke bruker lisensen som er tilordnet dem.

Forbedre sikkerhet og databeskyttelse:

  • Klargjør nøyaktig hva forventningene er for databeskyttelse: Sørg for at forventningene til databeskyttelse, for eksempel hvordan du bruker følsomhetsetiketter, blir dokumentert og kommunisert til brukerne.
  • Bestem hvordan du skal håndtere eksterne brukere: Forstå og dokumentere organisasjonspolicyer rundt deling av stoffinnhold med eksterne brukere. Sørg for at innstillingene i Fabric støtter policyene dine for eksterne brukere.
  • Konfigurer overvåking: Undersøk bruken av Microsoft Defender for skyapper for å overvåke brukeratferd og aktiviteter i Fabric.

Forbedre overvåking og overvåking:

  • Planlegg for overvåkingsbehov: Samle inn og dokumenter de viktigste forretningskravene for en overvåkingsløsning. Vurder prioriteringene dine for overvåking og overvåking. Ta viktige beslutninger knyttet til typen overvåkingsløsning, tillatelser, teknologier som skal brukes og databehov. Rådfør deg med IT for å klargjøre hvilke revisjonsprosesser som for øyeblikket finnes, og hvilke preferanser for krav som finnes for å bygge en ny løsning.
  • Vurder roller og ansvarsområder: Identifiser hvilke team som skal være involvert i å bygge en revisjonsløsning, samt den pågående analysen av overvåkingsdataene.
  • Trekke ut og lagre brukeraktivitetsdata: Hvis du for øyeblikket ikke trekker ut og lagrer rådataene, begynner du å hente brukeraktivitetsdata.
  • Trekk ut og lagre øyeblikksbilder av leierlagerdata: Begynn å hente metadata for å bygge en leierbeholdning, som beskriver alle arbeidsområder og elementer.
  • Trekke ut og lagre øyeblikksbilder av brukere og grupper data: Begynn å hente metadata om brukere, grupper og tjenestekontohavere.
  • Opprett en kuratert datamodell: Utfør datarensing og transformasjoner av rådataene for å opprette en kuratert datamodell som støtter analyserapportering for overvåkingsløsningen.
  • Analyser overvåkingsdata og handle etter resultatene: Opprett analytiske rapporter for å analysere de kuraterte overvåkingsdataene. Avklar hvilke handlinger som forventes å bli utført, av hvem og når.
  • Inkluder flere overvåkingsdata: Over tid må du avgjøre om andre overvåkingsdata vil være nyttige for å utfylle aktivitetsloggdataene, for eksempel sikkerhetsdata.

Tips

Hvis du vil ha mer informasjon, kan du se Overvåking på leiernivå.

Bruk REST-API-ene:

  • Planlegg for din bruk av REST-API-ene: Vurder hvilke data som vil være mest nyttige å hente fra REST-API-ene for Power BI og REST-API-ene for stoff.
  • Gjennomføre et konseptbevis: Gjør et lite konseptbevis for å validere databehov, teknologivalg og tillatelser.

Spørsmål å stille

Bruk spørsmål som de nedenfor til å vurdere systemtilsyn.

  • Er det atypiske administrasjonsinnstillinger aktivert eller deaktivert? Er for eksempel hele organisasjonen lov til å publisere på nett (vi anbefaler på det sterkeste å begrense denne funksjonen).
  • Samsvarer administrasjonsinnstillinger og -policyer med, eller hemmer, bedriften slik brukeren arbeider?
  • Er det en prosess for å vurdere nye innstillinger kritisk og bestemme hvordan du angir dem? Alternativt er bare de mest restriktive innstillingene angitt som en forholdsregel?
  • Brukes Microsoft Entra-sikkerhetsgrupper til å administrere hvem som kan gjøre hva?
  • Har sentrale team synlighet for effektive overvåkings- og overvåkingsverktøy ?
  • Viser overvåkingsløsninger informasjon om dataressursene, brukeraktivitetene eller begge deler?
  • Kan overvåkings- og overvåkingsverktøy handles? Er det klare terskler og handlinger angitt, eller beskriver overvåkingsrapporter ganske enkelt hva som er i dataområdet?
  • Brukes Azure Log Analytics (eller planlagt å brukes) til detaljert overvåking av stoffkapasiteter? Er de potensielle fordelene og kostnadene ved Azure Log Analytics klare for beslutningstakere?
  • Brukes følsomhetsetiketter og policyer for hindring av datatap? Er de potensielle fordelene og kostnadene ved disse klare for beslutningstakere?
  • Kjenner administratorer gjeldende antall lisenser og lisensieringskostnader? Hvilken andel av det totale BI-forbruket går til Fabric-kapasitet, og til Pro- og PPU-lisenser? Hvis organisasjonen bare bruker Pro-lisenser for Power BI-innhold, kan antall brukere og bruksmønstre garantere en kostnadseffektiv overgang til Power BI Premium- eller Fabric-kapasitet?

Modenhetsnivåer

Følgende forfallsnivåer vil hjelpe deg med å vurdere gjeldende tilstand for systemtilsynet i Power BI.

Nivå Tilstand av systemtilsyn
100: innledende • Leierinnstillinger konfigureres uavhengig av én eller flere administratorer basert på deres beste vurdering.

• Arkitekturbehov, for eksempel gatewayer og kapasiteter, er oppfylt etter behov. Det er imidlertid ikke en strategisk plan.

• Stoffaktivitetslogger brukes ikke, eller brukes selektivt til taktiske formål.
200: gjentakbar • Leierinnstillingene samsvarer med etablerte retningslinjer og policyer for styring. Alle leierinnstillinger gjennomgås regelmessig.

• Et lite antall bestemte administratorer velges. Alle administratorer har en god forståelse av hva brukerne prøver å oppnå i Fabric, slik at de er i en god posisjon til å støtte brukere.

• Det finnes en veldefinert prosess for brukere å be om lisenser og programvare. Forespørselsskjemaer er enkle å finne for brukere. Selvbetjente kjøpsinnstillinger er angitt.

• Følsomhetsetiketter er konfigurert i Microsoft 365. Bruk av etiketter forblir imidlertid inkonsekvent. Fordelene med databeskyttelse forstås ikke godt av brukerne.
300: definert • Leierinnstillingene er fullstendig dokumentert i den sentraliserte portalen som brukerne kan referere til, inkludert hvordan de ber om tilgang til de riktige gruppene.

• Det finnes tverropplæring og dokumentasjon for administratorer for å sikre kontinuitet, stabilitet og konsekvens.

• Følsomhetsetiketter tilordnes til innhold konsekvent. Fordelene ved å bruke følsomhetsetiketter for databeskyttelse forstås av brukere.

• En automatisert prosess er på plass for å eksportere stoffaktivitetslogg og API-data til et sikkert sted for rapportering og revisjon.
400: funksjonsdyktig • Administratorer samarbeider tett med COE- og styringsteamene for å gi tilsyn med Fabric. En balanse mellom brukermyndiggjøring og styring oppnås.

• Desentralisert administrasjon av dataarkitektur (for eksempel gatewayer eller kapasitetsadministrasjon) håndteres effektivt for å balansere smidighet og kontroll.

• Automatiserte policyer konfigureres og overvåkes aktivt i Microsoft Defender for cloud apps for hindring av datatap.

• Aktivitetslogg og API-data analyseres aktivt for å overvåke og overvåke stoffaktiviteter. Proaktiv handling utføres basert på dataene.
500: effektiv • Fabric-administratorene arbeider tett med COE for å holde seg oppdatert. Blogginnlegg og utgivelsesplaner fra Fabric-produktteamet gjennomgås ofte for å planlegge for kommende endringer.

• Regelmessig analyse av kostnadsstyring utføres for å sikre at brukerens behov oppfylles på en kostnadseffektiv måte.

• Rest-API-en for fabric brukes til å hente innstillingsverdier for tenant regelmessig.

• Aktivitetslogg og API-data brukes aktivt til å informere og forbedre innførings- og styringsarbeidet.

Relatert innhold

Hvis du vil ha mer informasjon om systemtilsyn og Fabric-administrasjon, kan du se følgende ressurser.

Lær mer om effektiv endringsadministrasjon i den neste artikkelen i veikartserien for Innføring av Microsoft Fabric.