Del via

Anbefalinger til design med henblik på udformning og effektivitet

  • Artikel

Gælder for denne anbefaling af kontrolliste til velstruktureret pålidelighed i Power Platform:

RE:01 Design arbejdsbelastningen, så den er i overensstemmelse med forretningsmålene, og undgå unødvendig kompleksitet eller belastning. Brug en praktisk og balanceret tilgang til at træffe designbeslutninger, der giver de ønskede resultater. Inddæm dit design til de forskellige muligheder for at reducere ineffektivitet og potentielle problemer.

I denne vejledning beskrives de anbefalinger, du skal bruge til at minimere unødvendig kompleksitet og undgå belastninger for at holde arbejdsbelastningerne simple og effektive. Vælg de bedste komponenter til at udføre de nødvendige opgaver i forbindelse med arbejdsbelastning for at optimere pålideligheden af arbejdsbelastningen. Hvis du vil mindske dine udviklings- og administrationsbelastninger, skal du udnytte de effektivitetsfordele, som platformbaserede servicer tilbyder. Med dette design kan du oprette en arkitektur for arbejdsbelastning, der gør det nemmere at gentage, skalere og administrere.

Definitioner

Begreb Definition
Arbejdsbelastning En separat funktion eller computeropgave, du kan udføre logisk adskilt fra andre opgaver.

Vigtigste designstrategier

Et vigtigt element, du skal bruge til at designe med henblik på pålidelighed, er at gøre tingene simple og effektive. Fokuser dit arbejdsbelastningsdesign på at imødekomme forretningskrav for at reducere risikoen for unødvendig kompleksitet eller overlapning. Overvej anbefalingerne i denne artikel, som kan hjælpe dig med at træffe beslutninger om design for at skabe en effektiv og pålidelig arbejdsbelastning. Forskellige arbejdsbelastninger kan have forskellige krav til tilgængelighed, skalerbarhed, ensartet data og it-katastrofeberedskab.

Du skal træffe alle designbeslutninger med et forretningskrav. Dette designprincip kan være indlysende, men det er vigtigt for design af arbejdsbelastning. Understøtter din arbejdsbyrde millioner af brugere eller et par tusinde? Er der store trafikbelastninger eller konstant arbejdsbelastning? Hvilket niveau af afbrydelse er acceptabelt? Forretningskrav driver disse designovervejelser.

Tradeoff: En kompleks løsning kan indeholde flere funktioner og fleksibilitet, men den kan påvirke pålideligheden af arbejdsbyrden, da den kræver mere koordinering, kommunikation og administration af komponenter. En mere enkel løsning lever muligvis ikke helt op til brugernes forventninger, eller den kan have en negativ indvirkning på udvidelsesmulighederne, efterhånden som arbejdsbelastningen udvikler sig.

Samarbejdsbaserede designøvelser

Arbejd med interessenterne om at:

  • Definere og tildele et kritisk niveau til arbejdsbelastningen og dens komponenter. I denne opgave kan du finde frem til de påkrævede komponenter og den bedste fremgangsmåde til at opnå det krævede niveau for lige rettigheder. Du kan finde flere oplysninger i Definition af programniveauer.

  • Definer funktionelle og ikke-funktionelle krav. Funktionskrav definerer systemets funktioner og funktionsmåde. De angives af brugeren og registreres i use cases. Ikke-funktionelle krav definerer systemets ydeevne og kvalitetsattributter. Sørg for, at du forstår ikke-funktionelle krav som tilgængelighed, overholdelse, bevarelse/opbevaring af data, ydeevne, beskyttelse af personlige oplysninger, tid til gendannelse, sikkerhed og skalerbarhed. Disse krav påvirker designbeslutninger og teknologivalg.

    Her er nogle eksempler på funktionelle og ikke-funktionelle krav i forbindelse med en arbejdsbelastning, der håndterer udgiftsrapporter:

    Funktionelle krav Ikke funktionelle krav
    Arbejdsbelastningen skal give brugere mulighed for at logge på med deres legitimationsoplysninger og kun få adgang til deres personlige data. Arbejdsbelastningen skal være tilgængelig mindst 99,9 % af tiden.
    Arbejdsbelastningen skal omfatte et dashboard, der indeholder en oversigt over åbne, godkendte og afviste udgiftsrapporter. Arbejdsbelastningen skal overholde de relevante regler og standarder for databeskyttelse og beskyttelse af personlige oplysninger.
    Arbejdsbelastningen skal understøtte sikkerhedskopiering og gendannelse af arbejdsbelastningsdataene. Arbejdsbelastningen skal have en svartid på mindre end 5 sekunder for de fleste brugeranmodninger.
    Arbejdsbelastningen skal sende meddelelser til brugere og administratorer, når bestemte hændelser eller tærskelværdier udløses. Arbejdsbelastningen skal have et højt sikkerhedsniveau og en høj kryptering for dataene i transit og i hvile.

    Du kan finde flere oplysninger i uddannelsesmodulet med titlen Arbejde med krav til Microsoft Power Platform og Dynamics 365.

  • Opdele arbejdsbelastningen i komponenter. Under processen til indsamling af registreringer og krav skal nogle løsningsideer begynde at blive tydelige. Identificer løsningskomponenter, der kan udgør den foreslåede løsning for at imødekomme forretningskravet. Prioriter produktivitet, effektivitet og pålidelighed i dit design. Find ud af, hvilke komponenter du skal bruge for at understøtte arbejdsbelastningen. Fremhæv, hvor de avancerede funktioner kan bruges, og hvor det kan være nødvendigt med brugerdefineret udvikling.

  • Bruge fejltilstandsanalyse til at identificere enkelte fejlpunkter og potentielle risici. Det er en klar forståelse af virksomhedens tolerance over for risici. Du kan finde flere oplysninger i Anbefalinger til analyse af fejltilstand.

  • Definere mål for tilgængelighed og gendannelse for arbejdsbelastningen for at træffe beslutning i arkitekturen. Forretningsmetrikværdier omfatter serviceniveaumål (SLA'er), serviceaftaler (SLA'er), gennemsnitlig tid til gendannelse (MTTR), gennemsnitlig tid mellem fejl (MTBF), mål for gendannelsestid (RTO'er) og mål for gendannelsespunkter (RPO'er). Definer målværdier for disse metrikværdier. I denne opgave kan det være nødvendigt at gå på kompromis med og gensidig forståelse mellem teknologi- og forretningsteams for at sikre, at de enkelte teams mål når de opstillede forretningsmål. Du kan finde flere oplysninger i Anbefalinger til definition af stabilitetsmål. Power Platform SlA'er giver Microsoft tilsagn om oppetid og forbindelse. Forskellige tjenester har forskellige SLA'er, og undertiden har SKU'er i en tjeneste forskellige SLA'er. Få flere oplysninger i Aftaler for onlinetjenester på tjenesteniveau.

Flere designanbefalinger

Du kan udføre følgende anbefalinger uden engagement fra interessenter:

  • Stræb efter at skabe enkelthed og klarhed i dit design. Brug den rette grad af abstraktion og granularitet for komponenterne og servicen. Undgå at over- eller under-engineering i løsningen. Eksempel:

    • Hvis du løser et krav til procesautomatisering i Power Automate, kan det gøre det sværere at forstå, teste og vedligeholde en stor proces i flere mindre cloudflows. Hvis alt holdes i et stort flow, kan det have en negativ indvirkning på ydeevnen og API-opkaldsmængden.

    • Hvis du løser et brugerrettet krav med Power Apps, kan en stor monolistisk lærredsapp med mange kontrolelementer have en negativ indvirkning på ydeevnen. Hvis du slår den ned i enkelte apps eller brugerdefinerede sider, kan det gøre det sværere at teste, men det kan have en betydelig positiv indvirkning på ydeevnen.

  • Forudse ændringer over tid, uanset om du skal løse problemer, implementere nye funktioner eller teknologier eller gøre eksisterende systemer mere skalerbare og fleksible.

  • Aflastning på tværs af skæringer adskiller sig fra en separat service. Minimer behovet for at duplikere kode på tværs af forskellige funktioner. Foretrækker at genbruge tjenester med veldefinerede grænseflader, der let kan forbruges af forskellige komponenter. Hvis et sæt datahandlinger f.eks. skal udføres forskellige steder, kan du flytte denne funktion til en plug-in med lav kode.

  • Evaluere, om almindelige mønstre og fremgangsmåder er passende til dine behov. Undgå at følge tendenser eller anbefalinger, der måske ikke passer bedst til din kontekst eller dine behov. Hvis du f.eks. implementerer komponenter til brugerdefineret kode, er det måske ikke den bedste løsning for alle programmer, da de kan medføre kompleksitets-, belastnings- og afhængighedsproblemer.

Udvikle lige nok kode

Principperne om effektivitet og pålidelighed gælder også for din udviklingspraksis. Overvej disse anbefalinger:

  • Brug platformsfunktioner, når de opfylder dine forretningskrav. Eksempel:

    • Brug moderne kontrolelementer i stedet for at udvikle dine egne kodekomponenter for at opnå en Fluent 2-designstandard.
    • Brug indbyggede connectorer i stedet for at udvikle brugerdefinerede connectorer for at reducere brugerdefineret kode.
    • Brug generative svar i Microsoft Copilot Studio for at give din helpdesk-medarbejder mulighed for at finde og præsentere information fra flere kilder, interne eller eksterne, uden at kræve manuel oprettelse af emner.

  • Introducer sessioner til gennemgang af specifikke kode som en udviklingspraksis.

  • Implementer en fremgangsmåde til identifikation af dead code. Vær skepsis over for den kode, dine automatiserede test ikke dækker.

  • Overvej det færdighedssæt, som dit udviklingsteam har. Det tager tid at lære en ny færdighed eller at anvende en ny teknologi.

Overvej, hvor dine data er

Som en del af dit arkitektoniske design skal du overveje, hvordan du gemmer dine data, eller hvordan du kan hente data til læseaktiviteter. Data kan hentes og gemmes på tre forskellige måder:

  • Nye data: Hvis din app opretter data, der ikke allerede findes nogen steder, f.eks. i situationer, hvor den eksisterende forretningsproces blev udført med papir, anbefaler vi, at du gemmer dataene i Microsoft Dataverse.

  • Læs/skriv fra et eksisterende system: Hvis din app skal hente data fra en eksisterende database eller et eksisterende system, skal du evaluere den bedste måde at oprette forbindelse til databasen eller systemet på: ved hjælp af en connector, en brugerdefineret tilslutning eller virtuelle tabeller.

  • Opret en kopi af dataene: I de situationer, hvor de oprindelige data aldrig bør ændres eller overskrives, kan du kopiere dataene til et andet datalager f.eks. Dataverse. Denne strategi bevarer det oprindelige systems data uændret, samtidig med at din app kan arbejde med dem. Dette scenarie er almindeligt, når du arbejder med data i regnskabs- og omsætningsrelaterede systemer. Du skal overveje, hvordan data kopieres, hvor ofte de opdateres, og om der skal ske en tovejssynkronisering.

Power Platform-processtyring

For praktiske designråd, se følgende artikler:

Kontrolliste for bæredygtighed

Se det fuldstændige sæt anbefalinger.

Kontrolliste for bæredygtighed