Dela via


Tillförlitlighetskompromisser för Power Platform arbetsbelastningar

En tillförlitlig arbetsbelastning som konsekvent uppfyller de definierade tillförlitlighetsmålen. Den bör nå uppsatta motståndskraftsmål, helst genom att kringgå händelser som påverkar tillförlitligheten. Realistiskt sett måste emellertid en arbetsbelastning tolerera och kontrollera effekterna av sådana händelser och upprätthålla verksamheten på en förutbestämd nivå under aktiva felfunktioner. Även vid en katastrof måste en tillförlitlig arbetsbelastning återställas till ett visst tillstånd inom en viss tidsperiod, som intressenterna har kommit överens om båda. En incidentsvarsplan som gör det möjligt att snabbt upptäcka och återställa systemet.

Under designfasen av en arbetsbelastning måste du överväga hur beslut baserade på Designprinciper för tillförlitlighet och rekommendationer i Checklista för designgranskning för tillförlitlighet 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 tillförlitlighet.

Avvägningar för tillförlitlighet med säkerhet

Kompromiss: Ökad arbetsbelastningsyta. Säkerhetspelaren prioriterar en reducerad och innehållen yta för att minimera angrepp och minska hantering av säkerhetskontroller.

  • Tillförlitligheten erhålls ofta via replikering. Replikering kan ske på komponentnivån, på datanivån eller till och med på en geografisk nivå. Repliker ökar som exempel ytan för en arbetsbelastning. Ur ett säkerhetsperspektiv är en reducerad och innehållen yta att föredra för att minimera potentiella angreppsvektorer och effektivisera hanteringen av säkerhetskontroller.

  • På samma sätt ökar lösningar för katastrofåterställning som säkerhetskopieringar, belastningens yta. De är emellertid ofta isolerade från arbetsbelastningens körning. Detta kräver implementering av ytterligare säkerhetskontroller, som kan vara specifika för lösningen för katastrofåterställning.

  • För att säkerställa tillförlitlighetsmålen kan det behövas ytterligare komponenter för arkitekturen, vilket ökar ytan. Den ökade komplexiteten ökar belastningens yta genom att lägga till nya komponenter som behöver skyddas, eventuellt på sätt som inte redan används i systemet. Vanligtvis åtföljs dessa komponenter av ytterligare kod för att stödja deras användning eller allmänna tillförlitlighetsmönster, vilket också ökar programmets yta.

Kompromiss: Kringgå säkerhetskontroll. Säkerhetspelare rekommenderar att alla kontroller är aktiva både i normala system och system för systemet som fungerar som de ska.

  • Om en arbetsbelastning upplever en tillförlitlighetshändelse som åtgärdas under aktivt incidentsvar kan det leda till att arbetsbelastningsteamen undviker säkerhetskontroller som är optimerade för rutinåtkomst.

  • Felsökningsaktiviteter kan leda till att teamet tillfälligt inaktiverar säkerhetsprotokoll, vilket innebär att ett system som redan har säkerhetsroller kan bli utsatt för risker. Det finns också en risk att säkerhetsprotokollen inte kan återställas omgående.

  • Detaljerade implementeringar av säkerhetskontroller, som rollbaserade åtkomstkontrolltilldelningar eller brandväggsregler, introducerar konfigurations komplexitet och känslighet, vilket ökar risken för felkonfiguration. Att ta itu med denna potentiella tillförlitlighetseffekt genom att använda breda regler undergräver alla tre principerna för noll förtroende-arkitekturen.

Kompromiss: Gamla programvaruversioner. Säkerhetspelaren uppmuntrar till en "håll dig aktuell" när det gäller leverantörens säkerhetskorrigeringar.

  • Att tillämpa uppdateringar av utgivningscykeln eller uppdateringar på leverantörsbibliotek, som komponenter eller lösningar från tredje part, kan potentiellt störa målkomponenten och orsaka otillgänglighet under ändringen. Att försena eller undvika korrigera kan undvika potentiella tillförlitlighetsrisker, men det lämnar systemet oskyddat mot utvecklande hot.

  • Det föregående övervägande gäller även arbetsbelastningens kod. Det gäller till exempel programkod som använder gamla bibliotek och komponenter. Om uppdatering och distribution av appkod betraktas som en ohanterad tillförlitlighetsrisk, utsätts programmet för ytterligare säkerhetsrisker över tiden.

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

Kompromiss: Ökad operativ komplexitet. Den driftförutsättningar, liksom tillförlitligheten i sig själv, prioriterar att fungera.

  • Att ha en omfattande övervakningsstrategi för en arbetsbelastning är en viktig del i verksamheten. Införa ytterligare komponenter i en arkitektur för att implementera tillförlitlighetsdesignmönster resulterar i fler datakällor att hantera, vilket ökar komplexiteten i att implementera distribuerad spårning och observabilitet.

  • Att använda flera regioner för att övervinna begränsningar av resurskapaciteten i en enskild region och/eller implementera en aktiv/aktiv arkitektur ökar komplexiteten i hanteringen av arbetsbelastningens drift. Denna komplexitet uppstår genom behovet av att hantera flera regioner och behovet av att hantera datareplikeringen mellan dem.

Kompromiss: Ökad ansträngning för att skapa kunskap och medvetenhet i teamet. Pelaren för driftförutsättningar rekommenderar att behålla och underhålla ett dokumentationsdatabasen för procedurer och topologier.

  • När arbetsbelastningen blir mer robust tack vare tillförlitlighetskomponenter och mönster tar det längre tid att underhålla operativa procedurer och dokumentation.

  • Utbildningen blir mer komplex i och med att antalet komponenter i arbetsbelastningen ökar. Komplexiteten påverkar den tid som krävs för registrering och ökar den kunskap som krävs för att följa upp produktinformation och vägledning på servicenivå.

Avvägningar för tillförlitlighet med upplevelseoptimering

Kompromiss: Minskad flexibilitet. Pelaren får upplevelseoptimering prioriterar användareffektivitet.

  • Genom att betona rigorösa tester kan det fördröja lanseringen av upplevelsefunktioner som är nödvändiga för användning.

  • Genom att optimera tillförlitlighet kan det överdriva minimeringen av komplexitet, vilket avprioriterar funktioner för mer engagerande användarupplevelser, t.ex. anpassade komponenter och integrationer.

Kompromisser med tillförlitlighet med prestandaeffektivitet

Kompromiss: Ökad latens. Prestandaeffektivitet kräver att ett system uppnår prestandamål för användar- och dataflöden.

  • Tillförlitlighetsmönster innehåller ofta datareplikering för att överleva replikfel. Replikering introducerar ytterligare svarstid för tillförlitliga dataskrivningsåtgärder, vilket förbrukar en del av prestandabudgeten för en specifik användare eller ett visst dataflöde.

  • Tillförlitlighet använder ibland olika former av resursutjämning för att distribuera eller omfördela belastning till felfria repliker. En dedikerad komponent som används för utjämning påverkar vanligtvis prestandan för den begäran eller process som balanseras.

  • Distribution av komponenter över geografiska gränser eller tillgänglighetszoner för att överleva en begränsad påverkan introducerar nätverksfördröjning i kommunikationen mellan komponenter som sträcker sig över dessa tillgänglighetsgränser.

  • Omfattande processer används för att observera hälsotillståndet för en arbetsbelastning. Även om övervakning är avgörande för tillförlitligheten kan instrumentation påverka systemets prestanda. När observerbarheten ökar kan prestandan minska.

Kompromiss: Ökad överetablering. Grundpelaren för prestandaeffektivitet avråder från överetablering och rekommenderar i stället att du använder precis tillräckligt med resurser för att tillgodose efterfrågan.

  • Automatiska skalningsåtgärder är inte omedelbara och kan därför inte på ett tillförlitligt sätt hantera en plötslig och dramatisk topp i efterfrågan som inte kan formas eller jämnas ut. Därför är överetablering via antingen större instanser eller fler instanser en viktig tillförlitlighetstaktik för att ta hänsyn till fördröjningen mellan efterfrågesignal och skapande av tillgång. Outnyttjad kapacitet motverkar målen för prestandaeffektivitet.

  • Ibland kan en komponent inte skalas som reaktion på efterfrågan, och den efterfrågan är inte helt förutsägbar. Att använda stora instanser för att täcka det värsta fallet leder till överetablering av slöseri i situationer som ligger utanför det användningsfallet.