Del via

Køreplan for indførelse af Microsoft Fabric: Systemtilsyn

  • Artikel

Bemærk

Denne artikel er en del af microsoft Fabric-køreplansserierne for indførelse af artikler. Du kan se en oversigt over serien i Microsoft Fabric-introduktionsoversigten.

Systemtilsyn – også kendt som Fabric Administration – er de løbende, daglige administrative aktiviteter. Det drejer sig specifikt om:

  • Styring: Vedtage retningslinjer og politikker for styring for at understøtte selvbetjenings- og virksomhedsdata- og BI-scenarier (Business Intelligence).
  • Bruger empowerment: Faciliterer og understøtter de interne processer og systemer, der giver det interne brugersamfund så meget som muligt, samtidig med at organisationens regler og krav overholdes.
  • Implementering: Gør det muligt at indføre Fabric i bredere organisation med effektive fremgangsmåder for styring og datastyring.

Vigtigt

Målene for din organisations datakultur er retningen for dine beslutninger om styring , hvilket igen bestemmer, hvordan Fabric-administrationsaktiviteter finder sted, og af hvem.

Systemtilsyn er et bredt og dybt emne. Målet med denne artikel er at introducere nogle af de vigtigste overvejelser og handlinger for at hjælpe dig med at få succes med dine mål for implementering af organisationen.

Fabric-administratorer

Rollen som Fabric-administrator er en defineret rolle i Microsoft 365, som uddelegerer et undersæt af administrationsaktiviteter. Globale Microsoft 365-administratorer er implicit Fabric-administratorer. Power Platform-administratorer er også implicit Fabric-administratorer.

En vigtig beslutning om styring er, hvem der skal tildeles som Fabric-administrator. Det er en central rolle, der påvirker hele din lejer. Ideelt set er der to til fire personer i organisationen , der er i stand til at administrere Fabric. Dine administratorer skal arbejde tæt sammen med COE (Center of Excellence).

Rolle med høje rettigheder

Rollen som Fabric-administrator er en rolle med mange rettigheder, fordi:

  • Brugeroplevelse: Indstillinger, der administreres af en Fabric-administrator, har stor indflydelse på brugerfunktioner og brugeroplevelse. Du kan få mere at vide under Styre lejerindstillinger.
  • Fuld sikkerhedsadgang: Fabric-administratorer kan opdatere adgangstilladelser for arbejdsområder i lejeren. Resultatet er, at en administrator kan tillade tilladelse til at få vist eller downloade data og rapporter efter behov. Du kan få mere at vide under Styre lejerindstillinger.
  • Adgang til personligt arbejdsområde: Fabric-administratorer kan få adgang til indhold og styre alle brugeres personlige arbejdsområde .
  • Metadata: Fabric-administratorer kan få vist alle lejermetadata, herunder alle brugeraktiviteter, der forekommer på Fabric-portalen (beskrevet i afsnittet Overvågning og overvågning nedenfor).

Vigtigt

Det er en risiko at have for mange Fabric-administratorer. Det øger sandsynligheden for ikke-godkendt, utilsigtet eller inkonsekvent administration af lejeren.

Roller og ansvarsområder

De typer af aktiviteter, som en administrator udfører dagligt, varierer fra organisation til organisation. Det, der er vigtigt, og som prioriteres i din datakultur, vil have stor indflydelse på , hvad en administrator gør for at understøtte virksomhedsledede selvbetjenings-, administrerede selvbetjenings- og virksomhedsdata og BI-scenarier. Du kan finde flere oplysninger i artiklen Indholdsejerskab og -administration .

Tip

Den bedste type person til at fungere som Fabric-administrator er en person, der har tilstrækkelig viden om værktøjer og arbejdsbelastninger til at forstå, hvad selvbetjeningsbrugere skal opnå. Med denne forståelse kan administratoren balancere brugerstyrke og styring.

Ud over Fabric-administratoren er der andre roller, der bruger ordet administrator. I følgende tabel beskrives de roller, der ofte og regelmæssigt bruges.

Rolle Område Beskrivelse
Fabric-administrator Lejer Administrerer lejerindstillinger og andre indstillinger på Fabric-portalen. Alle generelle referencer til administratoren i denne artikel henviser til denne type administrator.
Kapacitetsadministrator Én kapacitet Administrerer arbejdsområder og arbejdsbelastninger og overvåger tilstanden af en Fabric-kapacitet.
Datagatewayadministrator Én gateway Administrerer konfiguration af gatewaydatakilde, legitimationsoplysninger og brugertildelinger. Kan også håndtere opdateringer af gatewaysoftware (eller samarbejde med infrastrukturteamet om opdateringer).
Administrator af arbejdsområde Ét arbejdsområde Administrerer indstillinger for arbejdsområde og adgang.

Fabric-økosystemet af arbejdsbelastninger er bredt og dybt. Fabric kan integreres med andre systemer og platforme på mange måder. Fra tid til anden vil det være nødvendigt at arbejde sammen med andre administratorer og it-teknikere. Du kan få flere oplysninger under Samarbejd med andre administratorer.

Resten af denne artikel indeholder en oversigt over de mest almindelige aktiviteter, som en Fabric-administrator udfører. Det fokuserer på aktiviteter, der er vigtige at udføre effektivt, når man tager en strategisk tilgang til organisatoriske adoption.

Servicestyring

Tilsyn med lejeren er et afgørende aspekt for at sikre, at alle brugere har en god oplevelse med Power BI. Nogle få af de vigtigste styringsansvar for en Fabric-administrator omfatter:

  • Lejerindstillinger: Kontrollér, hvilke Funktioner og funktioner i Power BI der er aktiveret, og for hvilke brugere i din organisation.
  • Domæner: Gruppér to eller flere arbejdsområder, der har lignende egenskaber.
  • Arbejdsområder: Gennemse og administrer arbejdsområder i lejeren.
  • Integreringskoder: Styr, hvilke rapporter der er publiceret offentligt på internettet.
  • Visualiseringer til organisationer: Registrer og administrer visualiseringer til organisationer.
  • Azure-forbindelser: Integrer med Azure-tjenester for at levere yderligere funktionalitet.

Du kan få flere oplysninger under Lejeradministration.

Brugercomputere og -enheder

Indførelsen af Fabric afhænger direkte af, at indholdsoprettere og forbrugere har de værktøjer og programmer, de har brug for. Her er nogle vigtige spørgsmål, du skal overveje.

  • Hvordan anmoder brugerne om adgang til nye værktøjer? Vil adgang til licenser, data og oplæring være tilgængelig for at hjælpe brugerne med at bruge værktøjer effektivt?
  • Hvordan får indholdsforbrugere vist indhold, der er publiceret af andre?
  • Hvordan udvikler, administrerer og publicerer indhold indhold? Hvad er dine kriterier for at afgøre, hvilke værktøjer og programmer der er relevante for hvilke use cases?
  • Hvordan installerer og konfigurerer du værktøjer? Omfatter det relaterede forudsætninger og dataforbindelseskomponenter?
  • Hvordan administrerer du løbende opdateringer til værktøjer og programmer?

Du kan få flere oplysninger under Brugerværktøjer og -enheder.

Arkitektur

I forbindelse med Fabric er arkitektur relateret til dataarkitektur, kapacitetsstyring og arkitektur og administration af datagateway.

Dataarkitektur

Dataarkitektur refererer til de principper, fremgangsmåder og metoder, der styrer og definerer, hvilke data der indsamles, og hvordan de indtages, gemmes, administreres, integreres, modelleres og bruges.

Der er mange beslutninger om dataarkitektur, der skal træffes. COE beskæftiger sig ofte med design og planlægning af dataarkitektur. Det er almindeligt, at administratorer også involveres, især når de administrerer databaser eller Azure-infrastruktur.

Vigtigt

Beslutninger om dataarkitektur har stor indvirkning på Fabric-implementering, brugertilfredshed og individuelle projektsuccesrater.

Nogle få overvejelser i forbindelse med dataarkitektur, der påvirker indførelsen, omfatter:

  • Hvor passer Fabric ind i hele organisationens dataarkitektur? Er der andre eksisterende komponenter, f.eks. et EDW (Enterprise Data Warehouse) eller en datasø, der er vigtig for at indregne i planer?
  • Bruges Fabric fra ende til anden til dataforberedelse, datamodellering og datapræsentation, eller bruges Fabric kun til nogle af disse funktioner?
  • Følges administrerede selvbetjeningsmønstre for at finde den bedste balance mellem datareusability og fleksibilitet for rapportoprettere?
  • Hvor bruger brugerne indholdet? Generelt er de tre primære måder at levere indhold på: Fabric-portalen, Power BI-rapportserver og integreret i brugerdefinerede programmer. Derudover er Microsoft Teams et praktisk alternativ til brugere, der bruger meget tid i Teams.
  • Hvem er ansvarlig for at administrere og vedligeholde dataarkitekturen? Er det et centraliseret team eller et decentraliseret team? Hvordan repræsenteres COE'et i dette team? Er der behov for visse færdigheder?
  • Hvilke datakilder er de vigtigste? Hvilke typer data henter vi?
  • Hvilke semantiske modelforbindelsestilstande og valg af lagringstilstand (f.eks. Direct Lake, import, direkte forbindelse, DirectQuery eller sammensatte modelrammer) passer bedst til use cases?
  • I hvilket omfang tilskyndes genbrug af data ved hjælp af lakehouses, lagre og delte semantiske modeller?
  • I hvilket omfang fremmes genbrug af dataforberedelseslogik og avanceret dataforberedelse ved hjælp af datapipelines, notesbøger og dataflow?

Det er vigtigt for administratorer at blive fuldt ud opmærksomme på Fabric's tekniske funktioner – samt deres interessenters behov og mål – før de træffer arkitektoniske beslutninger.

Tip

Få den gode vane med at gennemføre en teknisk blåstempling (POC) for at afprøve antagelser og ideer. Nogle organisationer kalder dem også mikroprojekter , når målet er at levere en lille arbejdsenhed. Målet med en blåstempling er at håndtere ukendte forhold og reducere risikoen så tidligt som muligt. En blåstempling behøver ikke at være smid-væk-arbejde, men den skal være begrænset i omfang. Anmeldelser af bedste praksis, som beskrevet i artiklen Vejledning og brugeraktivering , er en anden nyttig måde at hjælpe indholdsoprettere med vigtige arkitektoniske beslutninger på.

Kapacitetsstyring

Kapacitet omfatter funktioner og funktioner til at levere analyseløsninger i stor skala. Der er to typer Fabric-organisationslicenser: Premium pr. bruger og kapacitet. Der er flere typer kapacitetslicenser. Kapacitetslicenstypen bestemmer, hvilke Fabric-arbejdsbelastninger der understøttes.

Vigtigt

Denne artikel henviser til tider Power BI Premium eller dens kapacitetsabonnementer (P-SKU'er). Vær opmærksom på, at Microsoft i øjeblikket konsoliderer købsmuligheder og udfaser Power BI Premium pr. kapacitets-SKU'er. Nye og eksisterende kunder bør overveje at købe Fabric-kapacitetsabonnementer (F SKU'er) i stedet.

Du kan få flere oplysninger under Vigtige opdateringer, der kommer til Power BI Premium-licenser og Ofte stillede spørgsmål om Power BI Premium.

Brugen af kapacitet kan spille en vigtig rolle i din strategi for oprettelse, administration, publicering og distribution af indhold. Nogle af de vigtigste grunde til at investere i kapacitet omfatter:

  • Ubegrænset distribution af Power BI-indhold til et stort antal skrivebeskyttede brugere. Indholdsforbrug for brugere med en gratis Power BI-licens er kun tilgængelig i Premium-kapacitet, ikke Premium pr. bruger. Gratis brugeres indholdsforbrug er også tilgængeligt med en F64 Fabric-kapacitetslicens eller nyere.
  • Adgang til Fabric-oplevelser til fremstilling af komplette analyser.
  • Udrulningspipelines til administration af publicering af indhold til udviklings-, test- og produktionsarbejdsområder. De anbefales på det kraftigste til kritisk indhold for at forbedre udgivelsesstabiliteten.
  • XMLA-slutpunkt, som er en branchestandardprotokol til administration og publicering af en semantisk model eller forespørgsel om den semantiske model fra et hvilket som helst XMLA-kompatibelt værktøj.
  • Øgede grænser for modelstørrelser, herunder understøttelse af store semantiske modeller .
  • Hyppigere dataopdateringer.
  • Lagring af data i et bestemt geografisk område, der er forskelligt fra hjemmeområdet.

Ovenstående liste er ikke all inclusive. Du kan se en komplet liste under Funktioner i Power BI Premium.

Administrer Fabric-kapacitet

Tilsyn med tilstanden af Fabric-kapaciteten er en vigtig løbende aktivitet for administratorer. Hver kapacitets-SKU indeholder et sæt ressourcer. Kapacitetsenheder (CU'er) bruges til at måle beregningsressourcer for hver SKU.

Advarsel

Manglende administration og konsekvent overskridelse af grænserne for dine kapacitetsressourcer kan ofte resultere i ydeevneudfordringer og udfordringer med brugeroplevelsen. Hvis begge udfordringer ikke håndteres korrekt, kan de bidrage til en negativ indvirkning på adoptionsindsatsen.

Forslag til administration af Fabric-kapacitet:

  • Definer, hvem der er ansvarlig for administration af kapaciteten. Bekræft rollerne og ansvarsområderne, så det er tydeligt, hvilken handling der udføres, hvorfor, hvornår og af hvem.
  • Opret et bestemt sæt kriterier for indhold, der publiceres til kapacitet. Det er især relevant, når en enkelt kapacitet bruges af flere forretningsenheder, fordi der er potentiale til at forstyrre andre brugere, hvis kapaciteten ikke administreres korrekt. Overvej at kræve en gennemgang af bedste praksis (f.eks. rimelig semantisk modelstørrelse og effektive beregninger), før du publicerer nyt indhold i en produktionskapacitet.
  • Brug jævnligt appen Fabric capacity metrics til at forstå ressourceudnyttelsen og mønstrene for kapaciteten. Det vigtigste er, at du søger efter ensartede mønstre for overudnyttelse, hvilket vil bidrage til brugerafbrydelser. En analyse af forbrugsmønstre bør også gøre dig opmærksom på, om kapaciteten er underudnyttet, hvilket angiver, at der kan opnås mere værdi ved investeringen.
  • Angiv lejerindstillingen, så Fabric giver dig besked, hvis kapaciteten bliver overbelastet, eller hvis der opstår et nedbrud eller en hændelse.

Automatisk skalering

Autoskalering er beregnet til at håndtere lejlighedsvise eller uventede bursts i kapacitetsforbrugsniveauer. Autoskalering kan reagere på disse bursts ved automatisk at øge CPU-ressourcer for at understøtte den øgede arbejdsbelastning.

Automatiseret opskalering reducerer risikoen for udfordringer med ydeevnen og brugeroplevelsen i bytte for en økonomisk effekt. Hvis kapaciteten ikke administreres korrekt, kan automatisk skalering udløses oftere end forventet. I dette tilfælde kan appen målepunkter hjælpe dig med at bestemme underliggende problemer og udføre kapacitetsplanlægning.

Decentraliseret kapacitetsstyring

Kapacitetsadministratorer er ansvarlige for at tildele arbejdsområder til en bestemt kapacitet.

Vær opmærksom på, at arbejdsområdeadministratorer også kan tildele et arbejdsområde til Premium pr. bruger, hvis arbejdsområdeadministratoren har en Premium pr. bruger-licens. Det kræver dog, at alle andre brugere af arbejdsområdet også skal have en Premium pr. bruger-licens for at samarbejde om eller få vist Power BI-indhold i arbejdsområdet. Andre Fabric-arbejdsbelastninger kan ikke inkluderes i et arbejdsområde, der er tildelt Premium pr. bruger.

Det er muligt at konfigurere flere kapaciteter for at lette decentraliseret administration af forskellige afdelinger. Decentralisering af styringen af visse aspekter af Fabric er en god måde at balancere fleksibilitet og kontrol på.

Her er et eksempel, der beskriver en måde, du kan administrere din kapacitet på.

  • Køb en P3-kapacitetsnode i Microsoft 365. Den indeholder 32 virtuelle kerner (v-kerner).
  • Brug 16 v-kerner til at oprette den første kapacitet. Den bruges af salgsteamet.
  • Brug 8 v-kerner til at oprette den anden kapacitet. Den bruges af operationsteamet.
  • Brug de resterende 8 v-kerner til at oprette den tredje kapacitet. Det understøtter generel brug.

I det forrige eksempel er der flere fordele.

  • Administratorer af separate kapaciteter kan konfigureres for hver kapacitet. Det faciliterer derfor decentrale administrationsforhold.
  • Hvis en kapacitet ikke administreres korrekt, begrænses effekten kun til denne kapacitet. De andre kapaciteter påvirkes ikke.
  • Fakturering og tilbageførsler til andre forretningsenheder er ligetil.
  • Forskellige arbejdsområder kan nemt tildeles til de separate kapaciteter.

Det forrige eksempel har dog også ulemper.

  • Grænserne pr. kapacitet er lavere. Den maksimale hukommelsesstørrelse, der er tilladt for semantiske modeller, er ikke hele den P3-kapacitetsnodestørrelse, der blev købt. I stedet er det den tildelte kapacitetsstørrelse, hvor den semantiske model hostes.
  • Det er mere sandsynligt, at en af de mindre kapaciteter skal skaleres op på et tidspunkt.
  • Der er flere kapaciteter at administrere i lejeren.

Bemærk

Ressourcer til Power BI Premium pr. kapacitet kaldes v-kerner. En Fabric-kapacitet refererer dog til dem som kapacitetsenheder (CU'er). Skalaen for CUs og v-kerner er forskellig for hver SKU. Du kan få flere oplysninger i dokumentationen til Fabric-licenser .

Arkitektur og administration af datagateway

En datagateway faciliterer sikker og effektiv overførsel af data mellem organisationens datakilder og Fabric-tjenesten. Der kræves en datagateway til dataforbindelse til tjenester i det lokale miljø eller cloudmiljøet, når en datakilde er:

  • Placeret i virksomhedens datacenter.
  • Konfigureret bag en firewall.
  • I et virtuelt netværk.
  • I en virtuel maskine.

Der er tre typer gateways.

  • Datagateway i det lokale miljø (standardtilstand) er en gatewaytjeneste, der understøtter forbindelser til registrerede datakilder, så mange brugere kan bruge dem. Installationerne og opdateringerne af gatewaysoftwaren installeres på en computer, der administreres af kunden.
  • Datagateway i det lokale miljø (personlig tilstand) er en gatewaytjeneste, der kun understøtter dataopdatering. Denne gatewaytilstand er typisk installeret på pc'en for en indholdsopretter. Den understøtter kun brug af én bruger. Den understøtter ikke direkte forbindelse eller DirectQuery-forbindelser.
  • Virtuel netværksdatagateway er en Microsoft-administreret tjeneste, der understøtter forbindelse for mange brugere. Det understøtter specifikt forbindelse til semantiske modeller og dataflow, der er gemt i arbejdsområder, der er tildelt Premium-kapacitet eller Premium pr. bruger.

Tip

Beslutningen om , hvem der kan installere gatewaysoftware , er en beslutning om styring. For de fleste organisationer bør brugen af datagatewayen i standardtilstand eller en virtuel netværksdatagateway på det kraftigste fremmes. De er langt mere skalerbare, kan administreres og overvåges end datagateways i personlig tilstand.

Decentraliseret gatewayadministration

Datagatewayen i det lokale miljø (standardtilstand) og den virtuelle netværksdatagateway understøtter specifikke datakildetyper, der kan registreres, sammen med forbindelsesoplysninger, og hvordan legitimationsoplysninger gemmes. Brugerne kan få tilladelse til at bruge gatewaydatakilden, så de kan planlægge en opdatering eller køre DirectQuery-forespørgsler.

Visse aspekter af gatewayadministration kan udføres effektivt på et decentralt grundlag for at balancere fleksibilitet og kontrol. Gruppen Handlinger kan f.eks. have en gateway, der er dedikeret til gruppen af selvbetjente indholdsforfattere og dataejere.

Decentraliseret gatewayadministration fungerer bedst, når det er en fælles indsats på følgende måde.

Administreret af de decentraliserede dataejere:

  • Oplysninger om forbindelse til datakilder i afdelingerne og niveauer for beskyttelse af personlige oplysninger.
  • Lagrede legitimationsoplysninger for afdelingsdata (herunder ansvar for opdatering af rutinemæssige adgangskodeændringer).
  • Brugere af afdelingsdatakilder, der har tilladelse til at bruge hver enkelt datakilde.

Administreret af centraliserede dataejere (omfatter datakilder, der bruges bredt på tværs af organisationen. Administration er centraliseret for at undgå duplikerede datakilder):

Administreret af it::

  • Opdateringer af gatewaysoftware (gatewayopdateringer udgives normalt månedligt).
  • Installation af drivere og brugerdefinerede connectors (de samme, der er installeret på brugercomputere).
  • Administration af gatewayklynger (antal computere i gatewayklynge for høj tilgængelighed, it-katastrofeberedskab og for at eliminere et enkelt fejlpunkt, hvilket kan medføre betydelige brugerafbrydelser).
  • Serveradministration (f.eks. operativsystem, RAM, CPU eller netværksforbindelse).
  • Administration og sikkerhedskopiering af gatewaykrypteringsnøgler.
  • Overvågning af gatewaylogge for at vurdere, hvornår skalering eller udskalering er nødvendig.
  • Besked om nedetid eller vedvarende lave ressourcer på gatewaycomputeren.

Tip

Hvis du giver et decentraliseret team tilladelse til at administrere visse aspekter af gatewayen, kan de bevæge sig hurtigere. Afvejlsen af decentraliseret gatewayadministration betyder, at du kører flere gatewayservere, så de hver især kan dedikeres til et bestemt område i organisationen. Hvis gatewayadministration udelukkende håndteres af it-virksomheden, er det vigtigt at have en god proces på plads til hurtigt at håndtere anmodninger om at tilføje datakilder og anvende brugeropdateringer.

Brugerlicenser

Alle brugere har brug for en kommerciel licens, som er integreret med en Microsoft Entra-identitet. Brugerlicensen kan være gratis, Pro eller Premium pr. bruger.

En brugerlicens opnås via et abonnement, som godkender et bestemt antal licenser med en start- og slutdato.

Bemærk

Selvom hver bruger kræver en licens, kræves der kun en Pro- eller Premium pr. bruger-licens for at dele Power BI-indhold. Brugere med en gratis licens kan oprette og dele Andet Fabric-indhold end Power BI-elementer.

Der er to metoder til at skaffe abonnementer.

  • Centraliseret: Microsoft 365-faktureringsadministratoren køber et abonnement til Pro eller Premium pr. bruger. Det er den mest almindelige måde at administrere abonnementer og tildele licenser på.
  • Decentraliseret: Individuelle afdelinger køber et abonnement via køb via selvbetjening.

Køb via selvbetjening

En vigtig beslutning om styring vedrører, i hvilket omfang køb via selvbetjening tillades eller fremmes.

Køb via selvbetjening er nyttig til:

  • Større organisationer med decentraliserede forretningsenheder, der har indkøbsmyndighed og gerne vil håndtere betaling direkte med et kreditkort.
  • Organisationer, der har til hensigt at gøre det så nemt som muligt at købe abonnementer på en månedlig forpligtelse.

Overvej at deaktivere køb via selvbetjening, når:

  • Centraliserede indkøbsprocesser er på plads for at opfylde lovmæssige krav, sikkerhed og styringskrav.
  • Rabatpriser opnås via en Enterprise-aftale (EA).
  • Eksisterende processer er på plads til håndtering af interne tilbageførsler.
  • Eksisterende processer er på plads til at håndtere gruppebaserede licenstildelinger.
  • Der kræves forudsætninger for at opnå en licens, f.eks. godkendelse, begrundelse, oplæring eller krav til styringspolitik.
  • Der er et gyldigt behov, f.eks. et lovmæssigt krav, for at kontrollere adgangen nøje.

Prøveversioner af brugerlicens

En anden vigtig beslutning om styring er, om brugerlicensforsøg er tilladt. Prøveversioner er som standard aktiveret. Det betyder, at når indhold deles med en kollega, og modtageren ikke har en Pro- eller Premium pr. bruger-licens, bliver vedkommende bedt om at starte en prøveversion for at få vist indholdet (hvis indholdet ikke er placeret i et arbejdsområde, der understøttes af kapacitet). Prøveversionen er beregnet til at være en praktisk funktion, der giver brugerne mulighed for at fortsætte med deres normale arbejdsproces.

Generelt anbefales det ikke at deaktivere prøveversioner. Det kan tilskynde brugerne til at søge løsninger, måske ved at eksportere data eller arbejde uden for understøttede værktøjer og processer.

Overvej kun at deaktivere forsøg, når:

  • Der er alvorlige omkostningsproblemer, der ville gøre det usandsynligt at tildele fulde licenser i slutningen af prøveperioden.
  • Der kræves forudsætninger for at opnå en licens (f.eks. godkendelse, begrundelse eller et oplæringskrav). Det er ikke tilstrækkeligt at opfylde dette krav i prøveperioden.
  • Der er et gyldigt behov, f.eks. et lovmæssigt krav, for at kontrollere adgangen til Fabric-tjenesten nøje.

Tip

Præsenter ikke for mange barrierer til at opnå en Fabric-licens. Brugere, der har brug for at få arbejdet fra hånden, finder en måde, og på den måde kan det omfatte løsninger, der ikke er ideelle. Uden en licens til at bruge Fabric kan folk f.eks. stole alt for meget på at dele filer på et filsystem eller via mail, når der er betydeligt bedre tilgange til rådighed.

Omkostningsstyring

Administration og optimering af omkostningerne ved cloudtjenester, f.eks. Fabric, er en vigtig aktivitet. Her er flere aktiviteter, du kan overveje.

  • Analysér, hvem der bruger – og i endnu højere grad ikke bruger – deres tildelte Fabric-licenser, og foretag de nødvendige justeringer. Stofforbruget analyseres ved hjælp af aktivitetsloggen.
  • Analysér omkostningseffektiviteten af kapacitet eller Premium pr. bruger. Ud over de ekstra funktioner skal du udføre en cost/benefit-analyse for at afgøre, om kapacitetslicenser er mere omkostningseffektive, når der er et stort antal forbrugere.
  • Overvåg og administrer fabric-kapacitet omhyggeligt. Hvis du forstår forbrugsmønstre over tid, kan du forudsige, hvornår du skal købe mere kapacitet. Du kan f.eks. vælge at opskalere en enkelt kapacitet fra en P1 til P2 eller skalere ud fra én P1-kapacitet til to P1-kapaciteter.
  • Hvis der er lejlighedsvise stigninger i brugsniveauet, anbefales brugen af autoskalering med Fabric for at sikre, at brugeroplevelsen ikke afbrydes. Autoskalering skalerer kapacitetsressourcer i 24 timer og skalerer dem derefter ned igen til normale niveauer (hvis vedvarende aktivitet ikke findes). Administrer omkostninger til automatisk skalering ved at begrænse det maksimale antal v-kerner og/eller med forbrugsgrænser, der er angivet i Azure. På grund af prismodellen er autoskalering bedst egnet til at håndtere lejlighedsvise uplanlagte stigninger i forbruget.
  • I forbindelse med Azure-datakilder skal du finde dem i det samme område som din Fabric-lejer, når det er muligt. Det vil forhindre, at azure-gebyrer for udgående data påløber. Gebyrer for dataudgående data er minimale, men i stor skala kan det medføre betydelige uplanlagte omkostninger.

Sikkerhed, beskyttelse af oplysninger og forebyggelse af datatab

Sikkerhed, beskyttelse af oplysninger og forebyggelse af datatab (DLP) er fælles ansvar blandt alle indholdsoprettere, forbrugere og administratorer. Det er ikke en lille opgave, fordi der er følsomme oplysninger overalt: personlige data, kundedata eller kundeudviklede data, beskyttede sundhedsoplysninger, immaterielle rettigheder, beskyttede organisationsoplysninger, bare for at nævne nogle få. Statslige, industrielle og kontraktmæssige bestemmelser kan have en betydelig indvirkning på de retningslinjer og politikker for styring , som du opretter i forbindelse med sikkerhed.

Hvidbogen om Sikkerhed i Power BI er en glimrende ressource til at forstå bredden af overvejelser, herunder aspekter, som Microsoft administrerer. I dette afsnit introduceres flere emner, som kunderne er ansvarlige for at administrere.

Brugeransvar

Nogle organisationer beder Fabric-brugere om at acceptere en selvbetjeningsbrugerbekræftelse. Det er et dokument, der forklarer brugerens ansvar og forventninger til beskyttelse af organisationsdata.

En måde at automatisere implementeringen på er ved hjælp af en Microsoft Entra vilkår for anvendelsespolitik. Brugeren skal have vist og acceptere politikken, før vedkommende får tilladelse til at besøge Fabric-portalen for første gang. Du kan også kræve, at det anerkendes på tilbagevendende basis, f.eks. en årlig fornyelse.

Datasikkerhed

I en model med delt ansvar i cloudmiljøet er det altid kundens ansvar at sikre dataene. Med en selvbetjent dataplatform har oprettere af selvbetjeningsindhold ansvaret for korrekt at beskytte det indhold, de har delt med kolleger.

COE bør levere dokumentation og oplæring , hvor det er relevant, for at hjælpe indholdsoprettere med bedste praksis (især situationer til håndtering af ultrafølsomme data).

Administration ister kan hjælpe ved selv at følge bedste praksis. Administration istratorer kan også give anledning til bekymringer, når de ser problemer, der kan registreres, når de administrerer arbejdsområder, reviderer brugeraktiviteter eller administrerer legitimationsoplysninger og brugere for gatewayen. Der er også flere lejerindstillinger , der normalt er begrænset med undtagelse af nogle få brugere (f.eks. muligheden for at publicere på internettet eller muligheden for at publicere apps til hele organisationen).

Eksterne gæstebrugere

Eksterne brugere – f.eks. partnere, kunder, leverandører og konsulenter – er en almindelig forekomst for nogle organisationer, og det er sjældent for andre. Den måde, du håndterer eksterne brugere på, er en beslutning om styring.

Adgang til eksterne brugere styres af lejerindstillinger og visse Indstillinger for Microsoft Entra-id. Du kan finde flere oplysninger om eksterne brugerovervejelser i hvidbogen Distribuer Power BI-indhold til eksterne gæstebrugere, der bruger Microsoft Entra B2B .

Beskyttelse af oplysninger og forebyggelse af datatab

Fabric understøtter funktioner til beskyttelse af oplysninger og forebyggelse af datatab (DLP) på følgende måder.

Dataopbevaring

For organisationer med krav om at gemme data i et geografisk område kan Fabric-kapacitet angives for et bestemt område , der er forskelligt fra fabric-lejerens hjemmeområde.

Krypteringsnøgler

Microsoft håndterer kryptering af inaktive data i Microsoft-datacentre med gennemsigtig kryptering på serversiden og automatisk rotation af certifikater. For kunder med lovmæssige krav til selv at administrere Premium-krypteringsnøglen kan Premium-kapacitet konfigureres til at bruge Azure Key Vault. Brug af kundeadministrerede nøgler – også kendt som bring-your-own-key eller BYOK – er en forholdsregel for at sikre, at kundedata ikke kan vises i tilfælde af en menneskelig fejl fra en tjenesteoperatør.

Vær opmærksom på, at Premium pr. bruger kun understøtter BYOK, når den er aktiveret for hele Fabric-lejeren.

Overvågning og overvågning

Det er vigtigt, at du bruger overvågningsdata til at analysere indføringsindsatsen, forstå brugsmønstre, uddanne brugere, understøtte brugere, afhjælpe risici, forbedre overholdelse af angivne standarder, administrere licensomkostninger og overvåge ydeevnen. Du kan finde flere oplysninger om, hvorfor overvågning af dine data er værdifuld, under Oversigt over overvågning og overvågning.

Der er forskellige måder at gribe overvågning og overvågning an på, afhængigt af din rolle og dine målsætninger. I følgende artikler beskrives forskellige overvejelser og planlægningsaktiviteter.

  • Overvågning på rapportniveau: Teknikker, som oprettere af rapporter kan bruge til at forstå, hvilke brugere der bruger de rapporter, de opretter, publicerer og deler.
  • Overvågning på dataniveau: Metoder, som oprettere af data kan bruge til at spore ydeevnen og forbrugsmønstrene for dataaktiver, som de opretter, publicerer og deler.
  • Overvågning på lejerniveau: Vigtige beslutninger og handlinger, som administratorer kan udføre for at oprette en overvågningsløsning fra ende til anden.
  • Overvågning på lejerniveau: Taktiske handlinger, som administratorer kan udføre for at overvåge Power BI-tjeneste, herunder opdateringer og meddelelser.

REST API'er

Power BI REST API'er og Fabric REST API'er indeholder et væld af oplysninger om din Fabric-lejer. Hentning af data ved hjælp af REST API'er bør spille en vigtig rolle i administrationen og styringen af en Fabric-implementering. Du kan få mere at vide om planlægning af brugen af REST API'er til overvågning under Overvågning på lejerniveau.

Du kan hente overvågningsdata for at oprette en overvågningsløsning, administrere indhold programmatisk eller øge effektiviteten af rutinehandlinger. I følgende tabel vises nogle handlinger, du kan udføre med REST API'er.

Handling Dokumentationsressourcer
Overvåg brugeraktiviteter REST API til at hente aktivitetshændelser
Overvåg arbejdsområder, elementer og tilladelser Samling af asynkrone metadatascanning AF REST API'er for at få et lejerlager
Overvåg indhold, der er delt med hele organisationen REST API til at kontrollere brugen af links, der deles af mange
Overvåg lejerindstillinger REST API til kontrol af lejerindstillinger
Publicer indhold REST API til at installere elementer fra en udrulningspipeline eller klone en rapport til et andet arbejdsområde
Administrer indhold REST API til opdatering af en semantisk model eller overtagelse af ejerskabet af en semantisk model
Administrer gatewaydatakilder REST API til opdatering af legitimationsoplysninger for en gatewaydatakilde
Eksportér indhold REST API til eksport af en rapport
Opret arbejdsområder REST API til oprettelse af et nyt arbejdsområde
Administrer tilladelser til arbejdsområde REST API til tildeling af brugertilladelser til et arbejdsområde
Opdater navnet eller beskrivelsen af arbejdsområdet REST API til opdatering af arbejdsområdeattributter
Gendan et arbejdsområde REST API til gendannelse af et slettet arbejdsområde
Hent et forespørgselsresultat fra en semantisk model ved hjælp af programmering REST API til at køre en DAX-forespørgsel mod en semantisk model
Tildel arbejdsområder til kapacitet REST API til tildeling af arbejdsområder til kapacitet
Skift en datamodel ved hjælp af programmering TOM-API (Tabular Object Model)
Integrer Power BI-indhold i brugerdefinerede programmer Klient-API'er til integreret Power BI-analyse

Tip

Der er mange andre REST API'er til Power BI. Du kan se en komplet liste under Brug af REST API'er til Power BI.

Planlægning af ændringer

Hver måned udgiver Microsoft nye Fabric-funktioner og -funktioner. For at være effektiv er det afgørende, at alle, der er involveret i systemtilsyn, forbliver opdaterede. Du kan få flere oplysninger under Overvågning på lejerniveau.

Vigtigt

Undervurder ikke vigtigheden af at holde dig opdateret. Hvis du får et par måneder bagud på meddelelser, kan det blive svært at administrere Fabric korrekt og støtte dine brugere.

Overvejelser og vigtige handlinger

Tjekliste – Overvejelser og vigtige handlinger, du kan udføre for at følge systemtilsynet.

Gør systemtilsynet bedre:

  • Bekræft, hvem der har tilladelse til at være Fabric-administrator: Hvis det er muligt, skal du reducere antallet af personer, der har fået tildelt rollen som Fabric-administrator, hvis det er mere end nogle få personer.
  • Brug PIM til lejlighedsvise administratorer: Hvis du har personer, der af og til har brug for Fabric-administratorrettigheder, kan du overveje at implementere Privilegeret identitetsstyring (PIM) i Microsoft Entra ID. Det er designet til at tildele lige-in-time-rolletilladelser, der udløber efter et par timer.
  • Oplær administratorer: Kontrollér status for tværgående oplæring og dokumentation til håndtering af Fabric-administrationsansvar. Sørg for, at en sikkerhedskopieringsperson er oplært, så behovene kan opfyldes rettidigt, på en ensartet måde.

Gør styringen af Fabric-tjenesten bedre:

  • Gennemse lejerindstillinger: Foretag en gennemgang af alle lejerindstillinger for at sikre, at de er i overensstemmelse med datakulturens målsætninger og retningslinjer for styring og politikker. Kontrollér, hvilke grupper der er tildelt for hver indstilling.
  • Dokumentér lejerindstillingerne: Opret dokumentation for dine lejerindstillinger for det interne Fabric-community, og send dem på den centraliserede portal. Medtag, hvilke grupper en bruger skal anmode om for at kunne bruge en funktion. Brug REST API'en Hent lejer Indstillinger til at gøre processen mere effektiv og til at oprette snapshots af indstillingerne regelmæssigt.
  • Tilpas linkene Hent Hjælp : Når der oprettes brugerressourcer, som beskrevet i artiklen Vejledning og brugeraktivering , skal du opdatere lejerindstillingen for at tilpasse linkene under menuindstillingen Hent hjælp . Det sender brugerne til din dokumentation, dit community og din hjælp.

Gør administrationen af brugercomputere og -enheder bedre:

  • Opret en ensartet onboardingproces: Gennemse din proces for, hvordan onboarding af nye indholdsforfattere håndteres. Find ud af, om nye anmodninger om software, f.eks. Power BI Desktop, og brugerlicenser (gratis, Pro eller Premium pr. bruger) kan håndteres sammen. Det kan forenkle onboarding, da nye indholdsforfattere ikke altid ved, hvad de skal bede om.
  • Håndter opdateringer til brugercomputere: Sørg for, at der er en automatiseret proces til installation og opdatering af software, drivere og indstillinger for at sikre, at alle brugere har den samme version.

Planlægning af dataarkitektur:

  • Vurder, hvordan din dataarkitektur fra ende til anden ser ud: Sørg for, at du er klar:
    • Sådan bruges Fabric i øjeblikket af de forskellige forretningsenheder i din organisation i forhold til, hvordan Fabric skal bruges. Find ud af, om der er et mellemrum.
    • Hvis der er nogen risici, der skal håndteres.
    • Hvis der er situationer med høj vedligeholdelse, der skal håndteres.
    • Hvilke datakilder er vigtige for Fabric-brugere, og hvordan de dokumenteres og opdages.
  • Gennemse eksisterende datagateways: Find ud af, hvilke gateways der bruges i hele organisationen. Kontrollér, at gatewayadministratorer og -brugere er angivet korrekt. Kontrollér, hvem der understøtter hver gateway, og at der er en pålidelig proces på plads for at holde gatewayserverne opdateret.
  • Kontrollér brugen af personlige gateways: Kontrollér antallet af personlige gateways, der er i brug, og af hvem. Hvis der er et betydeligt forbrug, skal du tage skridt til at bevæge dig i retning af brugen af standardtilstandsgatewayen.

Gør administrationen af brugerlicenser bedre:

  • Gennemse processen for at anmode om en brugerlicens: Tydeliggør, hvad processen er, herunder eventuelle forudsætninger, for at brugerne kan få en licens. Find ud af, om der skal foretages forbedringer af processen.
  • Bestem, hvordan køb af selvbetjeningslicenser skal håndteres: Tydeliggør, om køb af licenser til selvbetjening er aktiveret. Opdater indstillingerne, hvis de ikke stemmer overens med dine hensigter for, hvordan licenser kan købes.
  • Bekræft, hvordan brugertests håndteres: Kontrollér, at brugerlicensforsøg er aktiveret eller deaktiveret. Vær opmærksom på, at alle brugerforsøg er Premium pr. bruger. De gælder for gratis licenserede brugere, der tilmelder sig en prøveversion, og Pro-brugere, der tilmelder sig en Premium pr. bruger-prøveversion.

Gør omkostningsstyring bedre:

  • Bestem målene for omkostningsstyring: Overvej, hvordan du balancerer omkostninger, funktioner, forbrugsmønstre og effektiv udnyttelse af ressourcer. Planlæg en rutineproces for at evaluere omkostningerne mindst én gang om året.
  • Hent data i aktivitetsloggen: Sørg for, at du har adgang til aktivitetsloggens data for at hjælpe med omkostningsanalyse. Den kan bruges til at forstå, hvem der – eller ikke er – ved hjælp af den licens, der er tildelt dem.

Øg sikkerheden og databeskyttelsen:

  • Tydeliggør præcist, hvad forventningerne er til databeskyttelse: Sørg for, at forventningerne til databeskyttelse, f.eks. hvordan man bruger følsomhedsmærkater, dokumenteres og kommunikeres til brugerne.
  • Bestem, hvordan eksterne brugere skal håndteres: Forstå og dokumentere organisationens politikker for deling af Fabric-indhold med eksterne brugere. Sørg for, at indstillingerne i Fabric understøtter dine politikker for eksterne brugere.
  • Konfigurer overvågning: Undersøg brugen af Microsoft Defender for Cloud Apps til at overvåge brugeradfærd og -aktiviteter i Fabric.

Gør overvågning og overvågning bedre:

  • Planlæg overvågningsbehov: Indsaml og dokumenter de vigtigste forretningsmæssige krav til en overvågningsløsning. Overvej dine prioriteter for overvågning og overvågning. Foretag vigtige beslutninger, der er relateret til typen af overvågningsløsning, tilladelser, teknologier, der skal bruges, og databehov. Rådfør dig med it-virksomheden for at få afklaret, hvilke overvågningsprocesser der findes i øjeblikket, og hvilke behov der er for at skabe en ny løsning.
  • Overvej roller og ansvarsområder: Identificer, hvilke teams der skal være involveret i at oprette en overvågningsløsning, samt den løbende analyse af overvågningsdataene.
  • Udtræk og gem brugeraktivitetsdata: Hvis du ikke i øjeblikket udtrækker og gemmer rådata, skal du begynde at hente brugeraktivitetsdata.
  • Udtræk og gem snapshots af lejerens lagerdata: Begynd at hente metadata for at oprette en lejeroversigt, som beskriver alle arbejdsområder og elementer.
  • Udtræk og gem snapshots af data for brugere og grupper: Begynd at hente metadata om brugere, grupper og tjenesteprincipaler.
  • Opret en organiseret datamodel: Udfør datarensning og transformationer af rådata for at oprette en organiseret datamodel, der understøtter analyserapportering for din overvågningsløsning.
  • Analysér overvågningsdata, og arbejd på resultaterne: Opret analyserapporter for at analysere de udvalgte overvågningsdata. Tydeliggør, hvilke handlinger der forventes at blive truffet, af hvem og hvornår.
  • Medtag yderligere overvågningsdata: Over tid skal du afgøre, om andre overvågningsdata vil være nyttige til at supplere dataene i aktivitetsloggen, f.eks . sikkerhedsdata.

Tip

Du kan få flere oplysninger under Overvågning på lejerniveau.

Brug REST API'erne:

  • Planlæg din brug af REST API'er: Overvej, hvilke data der er mest nyttige at hente fra REST API'erne til Power BI og Fabric REST API'erne.
  • Udfør en blåstempling: Udfør en lille blåstempling for at validere databehov, teknologivalg og tilladelser.

Spørgsmål, der skal stilles

Brug spørgsmål som dem, der findes nedenfor, til at vurdere systemtilsynet.

  • Er der atypiske administrationsindstillinger aktiveret eller deaktiveret? Det kan f.eks. være, at hele organisationen har tilladelse til at publicere på internettet (vi anbefaler på det kraftigste, at denne funktion begrænses).
  • Er administrationsindstillinger og -politikker i overensstemmelse med eller hæmmer den måde, brugeren arbejder på?
  • Er der en proces på plads til kritisk at vurdere nye indstillinger og beslutte, hvordan de skal indstilles? Alternativt kan du kun angive de mest restriktive indstillinger som en forholdsregel?
  • Bruges Microsoft Entra-sikkerhedsgrupper til at administrere, hvem der kan gøre hvad?
  • Har centrale teams synlighed af effektive overvågnings- og overvågningsværktøjer ?
  • Viser overvågningsløsninger oplysninger om dataaktiver, brugeraktiviteter eller begge dele?
  • Kan overvågnings- og overvågningsværktøjer handles? Er der angivet tydelige tærskler og handlinger, eller beskriver overvågningsrapporterne blot, hvad der er i databoet?
  • Bruges Azure Log Analytics (eller er planlagt til at blive brugt) til detaljeret overvågning af Fabric-kapaciteter? Er de potentielle fordele og omkostninger ved Azure Log Analytics klare for beslutningstagere?
  • Bruges følsomhedsmærkater og politikker til forebyggelse af datatab? Er de potentielle fordele og omkostninger ved disse klare for beslutningstagere?
  • Kender administratorer det aktuelle antal licenser og licensomkostninger? Hvilken del af det samlede BI-forbrug går til Fabric-kapacitet og Pro- og Premium pr. bruger-licenser? Hvis organisationen kun bruger Pro-licenser til Power BI-indhold, kan antallet af brugere og forbrugsmønstre så berettige et omkostningseffektivt skift til Power BI Premium- eller Fabric-kapacitet?

Modenhedsniveauer

Følgende modenhedsniveauer hjælper dig med at vurdere den aktuelle tilstand for dit Power BI-systemtilsyn.

Niveau Status for systemtilsyn
100: indledende • Lejerindstillinger konfigureres uafhængigt af en eller flere administratorer baseret på deres bedste dømmekraft.

• Arkitekturbehov, f.eks. gateways og kapaciteter, opfyldes efter behov. Der er dog ikke en strategisk plan.

• Tekstilaktivitetslogge bruges ikke eller bruges selektivt til taktiske formål.
200: gentagelig • Lejerindstillingerne er målrettet i overensstemmelse med etablerede retningslinjer og politikker for styring. Alle lejerindstillinger gennemgås regelmæssigt.

• Der vælges et lille antal specifikke administratorer. Alle administratorer har en god forståelse af, hvad brugerne forsøger at opnå i Fabric, så de er i en god position til at understøtte brugerne.

• Der findes en veldefineret proces, hvor brugerne kan anmode om licenser og software. Det er nemt for brugerne at finde anmodningsformularer. Indstillinger for køb via selvbetjening er angivet.

• Følsomhedsmærkater er konfigureret i Microsoft 365. Brugen af mærkater er dog stadig inkonsekvent. Fordelene ved databeskyttelse forstås ikke godt af brugerne.
300: defineret • Lejerindstillingerne er fuldt dokumenteret på den centraliserede portal, som brugerne kan referere til, herunder hvordan de kan anmode om adgang til de korrekte grupper.

• Der findes tværgående oplæring og dokumentation for administratorer for at sikre kontinuitet, stabilitet og ensartethed.

• Følsomhedsmærkater tildeles indhold på en ensartet måde. Brugerne forstår fordelene ved at bruge følsomhedsmærkater til databeskyttelse.

• Der findes en automatiseret proces til eksport af Fabric-aktivitetslog og API-data til et sikkert sted til rapportering og overvågning.
400: kapabel • Administration istratorer arbejder tæt sammen med COE- og styringsteamene for at føre tilsyn med Fabric. Der opnås en balance mellem brugerstyrke og styring.

• Decentraliseret administration af dataarkitektur (f.eks. gateways eller kapacitetsstyring) håndteres effektivt for at balancere fleksibilitet og kontrol.

• Automatiserede politikker konfigureres og overvåges aktivt i Microsoft Defender for Cloud Apps til forebyggelse af datatab.

• Aktivitetslog- og API-data analyseres aktivt for at overvåge og overvåge Fabric-aktiviteter. Proaktiv handling udføres på baggrund af dataene.
500: effektiv • Fabric-administratorerne arbejder tæt sammen med COE og holder sig aktivt opdateret. Blogindlæg og udgivelsesplaner fra Fabric-produktteamet gennemgås ofte for at planlægge kommende ændringer.

• Regelmæssige cost management-analyser udføres for at sikre, at brugernes behov opfyldes på en omkostningseffektiv måde.

• Fabric REST API'en bruges til at hente lejerindstillingsværdier med jævne mellemrum.

• Aktivitetslogdata og API-data bruges aktivt til at informere og forbedre indførings- og styringsindsatsen.

Relateret indhold

Du kan få flere oplysninger om systemtilsyn og Fabric-administration i følgende ressourcer.

I den næste artikel i serien med køreplaner for indførelse af Microsoft Fabric kan du få mere at vide om effektiv administration af ændringer.