Dela via

Rekommendationer för design för enkelhet och effektivitet

  • Artikel

Gäller för den här Power Platform rekommendationen för checklistan Well-Architected Reliability :

RE:01 Designa din arbetsbelastning så att den är i linje med affärsmålen och undvik onödig komplexitet eller omkostnader. Använd en praktisk och balanserad metod när du ska fatta designbeslut som ger önskat resultat. Begränsa designen till det som krävs för att minska ineffektivitet och potentiella problem.

I den här guiden beskrivs rekommendationer om hur du minimerar onödig komplexitet och gör arbetsbelastningen enkel och effektiv. Välj de bästa komponenterna för att utföra arbetsbelastningsuppgifterna så att arbetsbelastningen blir så pålitlig som nödvändigt. Du kan minska dina utvecklings- och hanteringsbördor genom att dra nytta av de tjänster som tillhandahålls via plattform. Den här designen hjälper dig att skapa en arbetsbelastningsarkitektur som är anpassningsbar, repeterbar, skalbar och hanterbar.

Definitioner

Begrepp Definition
Arbetsbelastning En diskret funktion eller databehandlingsuppgift som du kan separera från andra uppgifter på ett logiskt sätt.

Viktiga designstrategier

En viktig del i utformningen av tillförlitligheten är att hålla saker enkla och effektiva. Fokusera arbetsbelastningens design på att uppfylla verksamhetskrav och minska risken för onödig komplexitet eller överdriven omkostnad. Överväg rekommendationerna i den här artikeln för att hjälpa dig att fatta beslut om din design för att skapa en effektiv och tillförlitlig arbetsbelastning. Olika arbetsbelastningar kan ha olika krav på tillgänglighet, skalbarhet, konsekvent data och katastrofåterställning.

Du måste motivera varje designbeslut med ett affärskrav. Den här designprincipen kan se ut som en självklarhet, men den är viktig för designen av arbetsbelastningen. Har din arbetsbelastning stöd för miljontals användare eller några tusen? Finns det stora trafikstörningar eller en stadig arbetsbelastning? Vilken nivå av avbrott är acceptabel? De här utformningsaspekterna är drivna av verksamhetskrav.

Kompromiss: En komplex lösning kan erbjuda fler funktioner och flexibilitet, men det kan påverka arbetsbelastningens tillförlitlighet eftersom den kräver mer samordning, kommunikation och hantering av komponenter. Alternativt kanske en enklare lösning inte helt uppfyller användarnas förväntningar, eller så kan den ha en negativ effekt på utbyggbarheten när arbetsbelastningen utvecklas.

Samarbetande designövningar

Arbeta med intressenter för att:

  • Definiera och tilldela en allvarlighetsgrad till din arbetsbelastning och dess komponenter. I den här övningen får du hjälp att fastställa vilka komponenter som krävs och hur du bäst uppnår den nödvändiga nivån av arbete. Se Definiera nivåer av appar för mer information.

  • Definiera funktionella och icke-funktionella krav. Funktionskrav definierar systemets egenskaper och beteende. De specificeras av användaren och samlas i användningsfall. Icke-funktionella krav definierar systemets prestanda- och kvalitetsattribut. Se till att du förstår icke-funktionella krav som tillgänglighet, efterlevnad, datalagring/uppehållstillstånd, prestanda, integritet, återställningstid, säkerhet och skalbarhet. Dessa krav påverkar utformningsbeslut och teknikval.

    Här följer några exempel på funktions- och icke-administrativa krav för en arbetsbelastning som hanterar utgiftsrapporter:

    Funktionella krav Icke-funktionella krav
    Arbetsbelastningen bör tillåta användare att logga in med sina referenser och bara komma åt sina personliga uppgifter. Arbetsbelastningen bör vara tillgänglig minst 99,9 % av tiden.
    Arbetsbelastningen bör innehålla en instrumentpanel med en översikt över öppna, godkända och avböjde utgiftsrapporter. Arbetsbelastningen bör följa relevanta regler och standarder för dataskydd och sekretess.
    Arbetsbelastningen bör stödja säkerhetskopiering och återställning av arbetsbelastningsdata. Arbetsbelastningen bör ha en svarstid på mindre än 5 sekunder för de flesta användarförfrågningar.
    Arbetsbelastningen bör skicka meddelanden till användare och administratörer när vissa händelser eller tröskelvärden utlöses. Arbetsbelastningen bör ha en hög nivå av säkerhet och kryptering för data under överföring och vila.

    För mer information, se utbildningsmodulen Arbeta med krav på Microsoft Power Platform och Dynamics 365.

  • Dela upp arbetsbelastningen i komponenter. Under upptäckten och kravinsamlingsprocessen bör några lösningsidéer börja bli tydliga. Identifiera lösningskomponenter som kan utgöra den föreslagna lösningen för att möta dina affärsbehov. Prioritera enkelhet, effektivitet och tillförlitlighet i din design. Ta reda på vilka komponenter du behöver för att stödja arbetsbelastningen. Markera var du kan använda de inbyggda funktionerna och var du kan behöva anpassa funktionerna.

  • Använd fellägesanalys för att identifiera enskilda felpunkter och potentiella risker. Förstå tydligt ditt företags risktolerans. Mer information finns i Rekommendationer för att utföra analys av felläge.

  • Definiera tillgänglighets- och återställningsmål för din arbetsbelastning för att informera arkitekturbesluten. Affärsmått inkluderar mål på servicenivå (SLO), servicenivåavtal (SLA), medeltid till återhämtning (MTTR), medeltid mellan fel (MTBF), mål för återhämtningstid (RTO) och mål för återställningspunkt (RPO). Definiera målvärden för dessa mått. Denna övning kan kräva kompromisser och ömsesidig förståelse mellan teknik- och affärsteam för att säkerställa att varje teams mål uppfyller affärsmålen och är realistiska. Mer information finns i rekommendationer för att definiera tillförlitlighetsmål. Power Platform SLA:er ger åtaganden för Microsoft drifttid och anslutning. Olika tjänster har olika SLA:er och ibland har SKU:er inom en tjänst olika SLA:er. Mer information finns i Servicenivåavtal för onlinetjänster.

Ytterligare designrekommendationer

Du kan utföra följande rekommendationer utan intressenternas åtagande:

  • Sträva efter enkelhet och tydlighet i din design. Använd lämplig nivå för sammanfattning och granularitet för komponenterna och tjänsterna. Undvik att över- eller underkonstruera din lösning. Till exempel:

    • Om du löser ett krav på processautomatisering med Power Automate, bryta en stor process till flera mindre molnflöden kan det göra det svårare att förstå, testa och underhålla. Om du behåller allt i ett stort flöde kan det däremot påverka prestanda och API-samtalsvolym negativt.

    • Om du löser ett användarriktat krav med Power Apps, en stor monolitisk arbetsyteapp med många kontroller kan ha en negativ inverkan på prestandan. Om du bryter ned den i enskilda appar eller anpassade sidor kan det göra det svårare att testa den, men den kan ha en stor positiv effekt på prestanda.

  • Förutse förändringar över tid, oavsett om det handlar om att åtgärda buggar, implementera nya funktioner eller tekniker eller göra befintliga system mer skalbara och motståndskraftiga.

  • Avlasta övergripande problem till en separat tjänst. Minimera behovet av dubblettkod över olika funktioner. Föredrar att återanvända tjänster med väldefinierade gränssnitt som lätt kan förbrukas av olika komponenter. Om en uppsättning dataåtgärder exempelvis måste utföras från olika platser kan du flytta den här funktionen till ett plugin-program med låg kod.

  • Utvärdera lämpligheten av vanliga mönster och metoder för dina behov. Undvik att följa trender eller rekommendationer som kanske inte passar ditt sammanhang eller dina krav. Att implementera anpassade kodkomponenter kanske inte är det bästa alternativet för varje program eftersom de kan ge problem som är komplexa, komplicerade och beroenden.

Utveckla tillräckligt med kod

Principerna om enkelhet, effektivitet och tillförlitlighet gäller även för dina utvecklingsmetoder. Överväg dessa rekommendationer:

  • Använd plattformsfunktioner när de uppfyller dina affärskrav. Till exempel:

    • Använd moderna kontroller i stället för att utveckla egna kodkomponenter för att uppnå en Fluent 2-designstandard.
    • Använd inbyggda anslutningsprogram i stället för att utveckla anpassade anslutningsprogram för att minska antalet anpassade koder.
    • Använd generativa svar för Microsoft Copilot Studio att göra det möjligt för din andrepilot att hitta och presentera information från flera källor, interna eller externa, utan manuellt skapade ämnen.

  • Introducera dedikerade kodgranskningssessioner som en utvecklingspraxis.

  • Implementera en metod för att identifiera död koden. Var skeptisk till koden som dina automatiserade tester inte täcker.

  • Fundera över kompetensuppsättningen i ditt utvecklingsteam. Det tar tid att lära sig en ny färdighet eller använda en ny teknik.

Fundera över var din data finns

Som en del av din arkitektoniska design måste du överväga hur du lagrar dina data eller hur du hämtar dina data för läsaktiviteter. Data kan hämtas och lagras på olika sätt:

  • Nya data: Om din app skapar data som inte redan finns, till exempel när den befintliga affärsprocessen gjordes på papper, rekommenderar vi att du lagrar data i Microsoft Dataverse.

  • Läsa/skriva från ett befintligt system: Om din app behöver hämta data från en befintlig databas eller ett befintligt system måste du utvärdera det bästa sättet att ansluta till databasen eller systemet: med hjälp av ett färdigt anslutningsprogram, en anpassad anslutningsprogram eller virtuella tabeller.

  • Gör en kopia av data: I situationer där ursprungliga data aldrig ska ändras eller skrivas över kan du kopiera data till ett annat datalager, till exempel Dataverse. Den här strategin behåller det ursprungliga systemets data oförändrade samtidigt som din app kan arbeta med det. Det här scenariot är vanligt när du arbetar med data i redovisnings- och intäktsbaserade system. Du måste fundera på hur data kopieras, hur ofta de uppdateras och om en tvåvägssynkronisering behöver äga rum.

Underlätta Power Platform

Praktiska designråd finns i följande artiklar:

Checklista för tillförlitlighet

Se den fullständiga uppsättningen med rekommendationer.

Checklista för tillförlitlighet