Dela via

Kompromisser med driftseffektivitet för Power Platform arbetsbelastningar

  • Artikel

Operational Excellence stöder arbetsbelastningskvaliteten genom implementering av tydliga teamstandarder, förstått ansvar och ansvarsskyldighet, uppmärksamhet på kundresultat och teamsammanhållning. Implementeringen av dessa mål är grundad i DevOps som rekommenderar att minimera processvariationer, minska mänskliga fel och i slutändan öka värdet för arbetsbelastningen. Det värdet mäts inte bara mot de funktionella krav som hanteras av komponenterna i arbetsbelastningen. Det mäts också efter det värde som teamet levererar för förbättringar.

Under designfasen av en arbetsbelastning och under dess livscykel när kontinuerliga förbättringssteg vidtas är det viktigt att överväga hur beslut som baseras på designprinciperna för driftskvalitet och rekommendationerna i checklistan för designgranskning för driftseffektivitet kan påverka målen och optimeringarna för andra pelare. Vissa beslut kan gynna vissa pelare men utgöra avvägningar för andra. I den här artikeln beskrivs exempel på problem som ett arbetsbelastningsteam kan stöta på när de utformar arbetsbelastningens arkitektur och åtgärder.

Avvägningar mellan driftförutsättningar och tillförlitlighet

Kompromiss: Ökad komplexitet. Tillförlitlighet prioriterar enkelhet, eftersom enkel design minimerar felkonfiguration och minskar oväntade interaktioner.

  • Säkra distributionsstrategier kräver ofta viss kompatibilitet framåt och bakåt mellan programlogik och data i arbetsbelastningen. Den ökade komplexiteten ökar testbördan och kan leda till komplexitets- eller integritetsproblem med arbetsbelastningens data.

  • Strukturer som är starkt byggda i flera skikt eller är inaktuella eller parameterbaserade kan öka risken för oavsiktliga felkonfigurering på grund av komplexiteten i interaktionen mellan komponenterna i arbetsbelastningen.

  • Molndesignmönster som gynnar åtgärder kräver ibland introduktion av fler komponenter, till exempel användning av hemligt arkiv eller att ta ett beroende av Application Insights. De extra komponenterna ökar interaktionspunkterna i systemet, vilket ökar risken för fel eller felkonfiguration.

Kompromiss: Ökade potentiellt destabiliserande aktiviteter. Tillförlitlighetspelaren uppmuntrar till att undvika aktiviteter eller designval som kan destabilisera ett system och leda till avbrott, driftsavbrott eller funktionsfel.

  • Att distribuera små, inkrementella ändringar är en teknik för att minska risken, men användarna förväntar sig att de små ändringarna ska levereras till produktion oftare. Distributioner kan försämra ett system så att distributionstakten ökar. Detta innebär även den risken.

  • Om systemet har ett mått på hastigheten, t.ex. distributioner per vecka och använder automatisering som gör det lättare att införa förändringar i snabbare takt, kan det också leda till fler distributioner under en kortare period.

  • Att öka densiteten för att förenkla verksamheten genom att minska antalet kontroll- och observerbarhetspunkter kan också leda till en ökad tillgänglighetsrisk eftersom fel eller felkonfiguration ökar effekten av en destabiliserande händelse.

Avvägningar mellan driftförutsättningar och säkerhet

Kompromiss: Ökad yta. Säkerhetspelaren rekommenderar en reducerad yta för arbetsbelastningen när det gäller komponenter och åtgärder. Den här minskningen minimerar sårbarheter och ger ett mindre omfång för säkerhetskontroll och testning.

  • Komponenter som omger arbetsbelastningen och stöder verksamheten, som automatisering eller anpassad kontroll, måste också kunna användas för regelbunden säkerhetshärdning och testning.

  • Rutinmässiga, oplanerade och nödåtgärder ökar kontaktpunkterna med arbetsbelastningen. En nolltillit metod kräver att dessa processer betraktas som sårbarheter och måste ingå i säkerhetskontrollerna och valideringen för arbetsbelastningen.

  • Systemets plattform för tillförlitlighet samlar in loggar och mått om arbetsbelastningen, som kan vara en värdefull källa att information lämnas ut. Därför måste arbetsbelastningens säkerhet utökas för att skydda data från interna och externa hot.

  • Byggagenter, extern konfiguration och lagring av funktionsväxlar ökar den programyta som kräver säkerhet.

  • En högre distributionsfrekvens som orsakas av små, inkrementella ändringar eller av "kom aktuellt, håll dig uppdaterad" resulterar i mer säkerhetstestning i livscykeln för programvaruutveckling (SDLC).

Kompromiss: Ökad önskan om transparens. En säker arbetsbelastning baseras på utformningar som skyddar sekretessen för data som passerar systemets komponenter.

Observationsplattformar tar in data av alla slag för att få insikter i en arbetsbelastnings hälsa och beteende. När team försöker skapa bättre observationsdata ökar risken för att dataklassificeringskontroller, som datamaskering, i källsystemen inte utvidgas till loggar och loggutslag på observationsplattformen.

Kompromiss: Minskad segmentering. En viktig säkerhetsstrategi för att isolera åtkomst och funktion är att utforma en kraftfull segmenteringsstrategi. Den här designen implementeras med hjälp av resursisolering och identitetskontroller.

  • Genom att lokalisera olika programkomponenter i delade miljöer och dataresurser för att underlätta hanteringen återställs segmenteringen eller underlättar rollbaserad segmentering. Samlokalisera komponenter kan också behöva dela en identitet för arbetsbelastningen, vilket kan leda till övertilldelning av behörigheter eller bristande spårning.

  • Genom att samla in alla loggar från hela systemet i ett enhetligt loggutslag kan det bli enklare att skapa och söka efter aviseringar. Men om du gör det kan det också bli svårare eller omöjligt att tillhandahålla radbaserad säkerhet för att behandla känsliga data med de granskningskontroller som krävs.

  • Om hanteringen av attributbaserad eller rollbaserad säkerhet förenklas genom att rollerna blir mer detaljerade och tilldelas kan behörigheterna bli för breda.

Avvägningar mellan driftförutsättningar och upplevelseoptimering

Kompromiss: Konkurrerande prioriteringar. Med upplevelseoptimering rekommenderar vi en användarcentrerad inställning.

  • Utveckling av användarupplevelser som kräver betydande resurser kan nedprioriteras, vilket kan leda till att upplevelsen saknar den användbarhet, interaktion och visuella design som arbetsbelastningsanvändare behöver.

  • Utveckling av användargränssnitt görs ofta i snabbare iterationer och leveranscykler, vilket kan belasta teamets SDLC-processer.

Avvägningar för driftseffektivitet med prestandaeffektivitet

Kompromiss: Ökat resursutnyttjande. Grundpelaren för prestandaeffektivitet rekommenderar att du allokerar så mycket av de tillgängliga beräknings- och nätverksresurserna som möjligt till arbetsbelastningens krav.

  • Övervakningsramverket för en arbetsbelastning kräver att komponenterna i arkitekturen allokerar tid och resurser för att skapa, samla in och strömma loggar och mått. Dessa datapunkter hjälper till att säkerställa att effektiv avisering och övervakning är möjlig för tillförlitlighet, säkerhet och prestanda. När instrumenteringsnivån ökar kan belastningen på systemresurserna också öka.

Kompromiss: Ökad latens. För att skapa högpresterande arbetsbelastningar letar teamen efter sätt att minska den tid och de resurser som arbetsbelastningarna förbrukar för att utföra sina uppgifter.

  • Vissa molndesignmönster som stöder metoder för "oberoende ändring över tid" för att stödja idealen för inkrementell förbättring kan medföra svarstider på grund av bläddring av ytterligare komponenter.