Del via

Anbefalinger for utforming med enkelhet og effektivitet som mål

  • Artikkel

Gjelder denne Power Platform Well-Architected Reliability-sjekklisteanbefalingen:

RE:01 Utform arbeidsbelastningen slik at den er i samsvar med forretningsmålene, og unngå unødvendig kompleksitet eller kostnader. Bruk en praktisk og balansert tilnærming til å ta utformingsbeslutninger som gir de ønskede resultatene. Begrens utformingen til nødvendighetene for å redusere ineffektivitet og potensielle problemer.

Denne veiledningen beskriver anbefalingene for å minimere unødvendig kompleksitet og kostnader, slik at arbeidsbelastningene er enkle og effektive. Velg de beste komponentene for å utføre de nødvendige arbeidsbelastningsoppgavene og optimalisere påliteligheten til arbeidsbelastningen. Du kan lette byrden ved utvikling og administrasjon ved å dra nytte av effektiviteten som plattformleverte tjenester tilbyr. Denne utformingen hjelper deg å opprette en arbeidsbelastningsarkitektur som er fleksibel, gjentakbar, skalerbar og håndterbar.

Definisjoner

Term Definisjon
Arbeidsbelastning En diskret funksjon eller databehandlingsoppgave som du kan skille logisk fra andre oppgaver.

Viktige utformingsstrategier

Et viktig prinsipp ved utforming med pålitelighet som mål er å holde ting enkle og effektive. Fokuser utformingen av arbeidsbelastningen på å oppfylle forretningskravene for å redusere risikoen for unødvendig kompleksitet eller overskytende kostnader. Vurder anbefalingene i denne artikkelen, som kan gjøre det enklere å ta beslutninger om utformingen av en veltrimmet, effektiv og pålitelig arbeidsbelastning. Ulike arbeidsbelastninger kan ha ulike krav til tilgjengelighet, skalerbarhet, datakonsistens og nødgjenoppretting.

Du må forsvare hver utformingsbeslutning med et forretningskrav. Dette utformingsprinsippet kan virke åpenbart, men det er avgjørende for utforming av arbeidsbelastning. Støtter arbeidsmengden din millioner av brukere, eller noen få tusen? Er det store trafikkbølger eller en jevn arbeidsbelastning? Hvilket nivå av nedetid er akseptabelt? Forretningskrav styrer disse utformingshensynene.

Avveining: En kompleks løsning har flere funksjoner og større fleksibilitet, men kan påvirke påliteligheten til arbeidsbelastningen, fordi den krever mer koordinering, kommunikasjon og administrasjon av komponenter. Det kan også hende at en enklere løsning ikke oppfyller brukernes forventninger fullstendig, eller den kan ha en negativ innvirkning på utvidbarheten etter hvert som arbeidsbelastningen utvikler seg.

Samarbeidsbaserte utformingsøvelser

Samarbeid med interessenter for å gjøre følgende:

  • Definer og tilordne et kritikalitetsnivå til arbeidsbelastningen og komponentene i den. Denne øvelsen hjelper deg å fastsette de nødvendige komponentene og den beste tilnærmingen for å oppnå nødvendig fleksibilitetsnivå. Se Definere programnivåer hvis du vil ha mer informasjon.

  • Definer funksjonelle og ikke-funksjonelle krav. Funksjonelle krav definerer funksjonene og funksjonaliteten til systemet. De angis av brukeren og registreres i brukstilfeller. Ikke-funksjonelle krav definerer ytelses- og kvalitetsattributtene for systemet. Pass på at du forstår ikke-funksjonelle krav som tilgjengelighet, forskriftssamsvar, dataoppbevaring/-lagring, ytelse, personvern, gjenopprettingstid, sikkerhet og skalerbarhet. Disse kravene påvirker utformingsbeslutninger og teknologivalg.

    Her er noen eksempler på funksjonelle og ikke-funksjonelle krav i forbindelse med en arbeidsbelastning som håndterer utgiftsrapporter:

    Funksjonelle krav Ikke-funksjonelle krav
    Arbeidsbelastningen skal la brukere logge seg på med legitimasjonen og bare gi dem tilgang til de personlige dataene deres. Arbeidsbelastningen skal være tilgjengelig minst 99,9 % av tiden.
    Arbeidsbelastningen bør ha et instrumentbord som gir oversikt over åpne, godkjente og avslåtte utgiftsrapporter. Arbeidsbelastningen må funger i tråd med de relevante forskriftene og standardene for personvern.
    Arbeidsbelastningen skal støtte sikkerhetskopiering og gjenoppretting for arbeidsbelastningsdataene. Arbeidsbelastningen bør ha en responstid på mindre enn 5 sekunder for de fleste brukerforespørsler.
    Arbeidsbelastningen skal sende varsler til brukere og administratorer når visse hendelser eller terskler utløses. Arbeidsbelastningen skal ha sterk sikkerhet og kryptering for data under overføring og inaktive data.

    Hvis du vil ha mer informasjon, kan du se opplæringsmodulen kalt Arbeid med krav for Microsoft Power Platform og Dynamics 365.

  • Del opp arbeidsbelastningen i komponenter. Enkelte løsningsforslag bør begynne å bli klare under registreringen og kravinnsamlingen. Identifiser løsningskomponenter som kan utgjøre den foreslåtte løsningen, for å oppfylle forretningskravene. Prioriterer enkelhet, effektivitet og pålitelighet i utformingen. Fastsett hvilke komponenter du trenger for å støtte arbeidsbelastningen. Fremhev hvor bruksklare funksjoner kan brukes, og hvor det kan være behov for egendefinert utvikling.

  • Bruk feilmodusanalyse til å identifisere enkeltsteder der feil kan oppstå og som er utsatt for risiko. Ha en klar forståelse av forretningsvirksomhetens risikotoleranse. Hvis du vil ha mer informasjon, kan du se Anbefalinger for utføring av feilmodusanalyse.

  • Definer tilgjengelighets- og gjenopprettingsmål for arbeidsbelastningen for å støtte arkitekturbeslutninger. Forretningsmåledata omfatter servicegradmål, serviceavtaler, middeltid for gjenoppretting, middeltid mellom feil, gjenopprettingstidsmål og gjenopprettingspunktmål. Definer målverdier for disse måledataene. Denne øvelsen kan kreve kompromiss og gjensidig forståelse mellom teknologiteam og forretningsteam for å sikre at målene til hvert team, oppfyller forretningsmål og er realistiske. Hvis du vil ha mer informasjon, kan du se Anbefalinger for definisjon av pålitelighetsmål. Power Platform-serviceavtaler gir Microsoft forpliktelser vedrørende oppetid og tilkobling. Ulike tjenester har ulike serviceavtaler, og noen ganger har SKU-er i en tjeneste ulike serviceavtaler. Hvis du vil ha mer informasjon, kan du se Serviceavtaler for onlinetjenester.

Ytterligere utformingsanbefalinger

Du kan følge følgende anbefalinger uten deltakelse fra interessenter:

  • Sats på enkelhet og klarhet i utformingen. Bruk riktig abstraksjonsnivå og detaljnivå for komponentene og tjenestene. Unngå å utvikle en løsning som er for komplisert eller ikke komplisert nok. Eksempel:

    • Hvis du løser et prosessautomatiseringskrav med Power Automate, kan oppdeling av en stor prosess i flere mindre skyflyter gjøre den vanskeligere å forstå, teste og vedlikeholde. Hvis du på den annen side har alt i en stor flyt, kan dette få en negativ innvirkning på ytelsen og antall API-oppkall.

    • Hvis du løser et brukerkrav med Power Apps, kan en stor, monolittisk lerretsapp med mange kontroller ha en negativ innvirkning på ytelsen. Hvis du bryter den ned i enkeltapper eller egendefinerte sider, kan det bli vanskeligere å teste den, men det kan ha en betydelig positiv innvirkning på ytelsen.

  • Forvent endringer over tid, enten det er snakk om å rette feil, implementere nye funksjoner eller teknologier, eller gjøre eksisterende systemer mer skalerbare og fleksible.

  • Deleger aspekter på tvers av systemet til en separat tjeneste. Minimer behovet for å duplisere kode på tvers av ulike funksjoner. Foretrekk gjenbruk av tjenester med veldefinerte grensesnitt som enkelt kan brukes av forskjellige komponenter. Hvis et sett med dataoperasjoner for eksempel må utføres fra ulike steder, kan du flytte denne funksjonaliteten til et lavkodebasert programtillegg.

  • Evaluer hvor godt vanlige mønstre og fremgangsmåter er egnet til dine behov. Unngå å følge trender eller anbefalinger som kanskje ikke passer best i konteksten din eller til kravene dine. Det kan for eksempel hende at implementering av komponenter med egendefinert kode ikke er det beste alternativet for hvert program, fordi de kan føre til kompleksitet, ekstra kostnader og avhengighetsproblemer.

Utvikle akkurat nok kode

Prinsippene for enkelhet, effektivitet og pålitelighet gjelder også for utviklingspraksisen din. Vurder disse anbefalingene:

  • Bruk plattformfunksjoner når de oppfyller forretningskravene dine. Eksempel:

    • Bruk moderne kontroller i stedet for å utvikle dine egne kodekomponenter for å oppnå en Fluent 2-utformingsstandard.
    • Bruk opprinnelige koblinger i stedet for å utvikle egendefinerte koblinger for å redusere egendefinert kode.
    • Bruk generative svar i Microsoft Copilot Studio slik at agenten finner og presenterer informasjon fra flere kilder (som kan være interne eller eksterne) uten manuelt opprettede emner.

  • Innfør egne økter for kodegjennomgang som en utviklingspraksis.

  • Implementer en tilnærming for å identifisere død kode. Vær skeptisk til koden som de automatiske testene ikke dekker.

  • Vurder kompetansesettet til utviklingsteamet. Det tar tid å lære seg en ny ferdighet eller å ta i bruk ny teknologi.

Ta hensyn til hvor dataene er

Som en del av den arkitektoniske utformingen må du ta hensyn til hvordan du lagrer dataene, eller hvordan du henter data til leseaktiviteter. Du kan hente og lagre data på ulike måter:

  • Nye data: Hvis appen oppretter data som ikke allerede finnes, for eksempel der den eksisterende forretningsprosessen ble gjort på papir, anbefaler vi at du lagrer dataene i Microsoft Dataverse.

  • Les/skriv fra et eksisterende system: Hvis appen må hente data fra en eksisterende database eller et eksisterende system, må du evaluere den beste måten å koble til databasen eller systemet på: ved hjelp av en bruksklar kobling, en egendefinert kobling eller virtuelle tabeller.

  • Lage en kopi av dataene: I situasjoner der de opprinnelige dataene aldri bør endres eller overskrives, kan du kopiere dataene til et annet datalager, for eksempel Dataverse. Denne strategien holder det opprinnelige systemets data uendret, samtidig som appen din kan jobbe med det. Dette scenarioet er vanlig når du arbeider med data i regnskaps- og omsetningsrelaterte systemer. Du må vurdere hvordan data kopieres, hvor ofte de oppdateres, og hvorvidt toveis synkronisering må brukes.

Tilrettelegging for Power Platform

For praktiske utformingsråd kan du se følgende artikler:

Sjekkliste for pålitelighet

Se hele settet med anbefalinger.

Sjekkliste for pålitelighet