Rekommendationer för att definiera tillförlitlighetsmål

Gäller för den här rekommendationen om checklista för tillförlitlighet i Azure Well-Architected Framework:

RE:04	Definiera tillförlitlighets- och återställningsmål för komponenterna, flödena och den övergripande lösningen. Visualisera målen för att förhandla, få konsensus, ange förväntningar och driva åtgärder för att uppnå det ideala tillståndet. Använd de definierade målen för att skapa hälsomodellen. Hälsomodellen definierar hur felfria, degraderade och ej felfria tillstånd ser ut.

Den här guiden beskriver rekommendationerna för att definiera målmått för tillgänglighet och återställning för kritiska arbetsbelastningar och flöden. Tillförlitlighetsmål härleds genom workshopövningar med intressenter i verksamheten. Målen förfinas genom övervakning och testning.

Med dina interna intressenter kan du ställa in realistiska förväntningar på arbetsbelastningens tillförlitlighet så att intressenterna kan förmedla dessa förväntningar till kunderna via avtal. Realistiska förväntningar hjälper också intressenterna att förstå och stödja dina beslut om arkitekturdesign och vet att du utformar för att optimalt uppfylla de mål som du kommit överens om.

Överväg att använda följande mått för att kvantifiera affärskraven.

Period	Definition
Servicenivåmål (SLO)	Ett procentmål som representerar hälsotillståndet för komponenten och tillförlitlighetsnivån. Ju högre nivå, desto mer tillförlitlig är komponenten. Sammansatt servicenivåmål representerar det aggregerade målet för hela arbetsbelastningen och står för komponentens servicenivåmål.
Indikator på tjänstnivå (SLI)	Ett mått som genereras av en tjänst. SLI-mått aggregeras för att kvantifiera ett SLO-värde.
Serviceavtal (SLA)	Ett avtal mellan tjänsteleverantören och tjänstekund. Avtalet definierar servicenivåmålen. Om avtalet inte uppfylls kan det få ekonomiska konsekvenser för tjänsteleverantören.
Genomsnittlig tid för återställning (MTTR)	Den tid det tar att återställa en komponent efter att ett fel har identifierats.
Genomsnittlig tid mellan fel (MTBF)	Hur lång tid arbetsbelastningen kan utföra den förväntade funktionen utan avbrott tills den misslyckas.
Mål för återställningstid (RTO)	Den maximala godkända tiden som ett program kan vara otillgängligt efter en incident.
Mål för återställningspunkt (RPO)	Den maximala godkända varaktigheten för dataförlust under en incident.

Definiera arbetsbelastningens målvärden för dessa mått i kontexten för användarflöden och systemflöden. Identifiera och poängsätta dessa flöden efter hur viktiga de är för dina behov. Använd värdena för att driva utformningen av din arbetsbelastning när det gäller åtgärder för arkitektur, granskning, testning och incidenthantering. Om målen inte uppfylls påverkas verksamheten utöver toleransnivån.

Viktiga designstrategier

Tekniska diskussioner bör inte driva hur du definierar tillförlitlighetsmål för dina kritiska flöden. I stället bör affärsintressenter fokusera på kunder när de definierar en arbetsbelastnings krav. Tekniska experter hjälper intressenterna att tilldela realistiska numeriska värden som korrelerar med dessa krav. När de delar kunskap möjliggör tekniska experter förhandlingar och ömsesidig konsensus om realistiska serviceavtal.

Tänk dig ett exempel på hur du mappar krav till mätbara numeriska värden. Intressenterna uppskattar att en timmes stilleståndstid under normal kontorstid för ett kritiskt användarflöde resulterar i en förlust på X dollar i månadsintäkter. Det dollarbeloppet jämförs med den uppskattade kostnaden för att utforma ett flöde som har ett tillgänglighets-SLO på 99,95 procent snarare än 99,9 procent. Beslutsfattarna måste diskutera om risken för denna intäktsförlust uppväger de extra kostnader och den hanteringsbörda som krävs för att skydda mot den. Följ det här mönstret när du undersöker flöden och skapar en fullständig lista över mål.

Kom ihåg att tillförlitlighetsmål skiljer sig från prestandamål. Tillförlitlighetsmålen fokuserar på tillgänglighet och återställning. Om du vill ange tillförlitlighetsmål börjar du med att definiera de bredaste kraven och sedan definiera mer specifika mått för att uppfylla de övergripande kraven.

Krav på tillförlitlighet och återställning på högsta nivå och korrelerade mått kan till exempel innehålla en programtillgänglighet på 99,9 procent för alla regioner eller ett mål-RTO på 5 timmar för Regionen Amerika. Genom att definiera de här typerna av mål kan du identifiera vilka kritiska flöden som ingår i dessa mål. Sedan kan du överväga mål på komponentnivå.

Kompromiss: Det kan finnas en konceptuell lucka mellan de tekniska begränsningarna för arbetsbelastningens komponenter och vad det innebär för verksamheten, till exempel dataflöde i megabit per sekund jämfört med transaktioner per sekund. Det kan vara svårt att skapa en modell mellan dessa två vyer. I stället för att överengineera lösningen, försök att närma sig den på ett ekonomiskt men meningsfullt sätt.

Tillgänglighetsmått

Serviceavtal och serviceavtal

Tillgänglighetsmått korrelerar med SLO:er, som du använder för att definiera serviceavtal. Servicenivåmålet för arbetsbelastningar avgör hur mycket stilleståndstid som kan tolereras under en viss period, till exempel mindre än 1 timme per månad. Kontrollera att du kan uppfylla SLO-målet genom att granska Microsofts serviceavtal för varje komponent. Var uppmärksam på hur mycket redundans du behöver för att uppfylla höga serviceavtal. Microsoft garanterar till exempel högre serviceavtal för distributioner i flera regioner av Azure Cosmos DB än vad det garanterar för distributioner i en region.

Anteckning

Azure-serviceavtal omfattar inte alltid alla aspekter av en tjänst. Till exempel har Azure Application Gateway ett serviceavtal för tillgänglighet, men Azure Web Application Firewall-funktionen ger ingen garanti för att hindra skadlig trafik från att passera. Tänk på den här begränsningen när du utvecklar serviceavtal och serviceavtal.

När du har samlat in serviceavtalen för de enskilda arbetsbelastningskomponenterna beräknar du ett sammansatt serviceavtal. Det sammansatta serviceavtalet ska matcha arbetsbelastningens mål-SLO. Beräkning av ett sammansatt serviceavtal omfattar flera faktorer, beroende på arkitekturdesignen. Tänk dig följande exempel.

Anteckning

SLA-värdena i följande exempel är hypotetiska och är endast i demonstrationssyfte. De är inte avsedda att representera aktuella värden som stöds av Microsoft.

Sammansatta serviceavtal omfattar flera tjänster som stöder ett program, med olika tillgänglighetsnivåer. Tänk dig till exempel en Azure App Service webbapp som skriver till Azure SQL Database. Hypotetiskt kan dessa serviceavtal vara:

• App Service webbappar = 99,95 procent
• SQL Database = 99,99 procent

Vilken är den maximala stilleståndstid som du kan förvänta dig för det här programmet? Om någon av tjänsterna går ned stannar hela programmet. Sannolikheten för att varje tjänst misslyckas är oberoende, så det sammansatta serviceavtalet för det här programmet är 99,95 procent × 99,99 procent = 99,94 procent. Det värdet är lägre än de enskilda serviceavtalen. Den här slutsatsen är inte förvånande eftersom ett program som förlitar sig på flera tjänster har fler potentiella felpunkter.

Du kan förbättra det sammansatta serviceavtalet genom att skapa oberoende återställningsvägar. Om SQL Database till exempel inte är tillgänglig placerar du transaktioner i en kö som ska bearbetas senare:

I den här designen är programmet fortfarande tillgängligt även om det inte kan ansluta till databasen. Det misslyckas dock om databasen och kön misslyckas samtidigt. Den förväntade procentandelen av tiden för samtidiga fel är 0,0001 × 0,001, så här är det sammansatta serviceavtalet för den här kombinerade sökvägen:

Databas eller kö = 1,0 − (0,0001 × 0,001) = 99,99999 procent

Totalt sammansatt serviceavtal:

Webbapp och (databas eller kö) = 99,95 procent × 99,99999 procent = ~99,95 procent

Den här metoden innebär kompromisser:

• Programlogik är mer komplex.
• Du betalar för kön.
• Du måste ta hänsyn till problem med datakonsekvens.

För distributioner i flera regioner beräknas det sammansatta serviceavtalet på följande sätt:

• N är det sammansatta serviceavtalet för programmet som distribueras i en region.

• R är antalet regioner där programmet distribueras.

Den förväntade chansen att programmet misslyckas i alla regioner samtidigt är ((1 − N) ^ R). Om till exempel det hypotetiska serviceavtalet för en region är 99,95 procent:

• Det kombinerade serviceavtalet för två regioner = (1 − (1 − 0,9995) ^ 2) = 99,999975 procent

• Det kombinerade serviceavtalet för fyra regioner = (1 − (1 − 0,9995) ^ 4) = 99,999999 procent

Det tar tid och noggrannt att definiera rätt serviceavtal. Affärsintressenter bör förstå hur viktiga kunder använder appen. De bör också förstå tillförlitlighetstoleransen. Denna feedback bör informera målen.

SLA-värden

I följande tabell definieras vanliga SLA-värden.

SLA	Nedtid per vecka	Nedtid per månad	Nedtid per år
99 %	1,68 timmar	7,2 timmar	3,65 dagar
99,9 %	10,1 minuter	43,2 minuter	8,76 timmar
99,95 %	5 minuter	21,6 minuter	4,38 timmar
99,99 %	1,01 minuter	4,32 minuter	52,56 minuter
99,999 %	6 sekunder	25,9 sekunder	5,26 minuter

När du tänker på sammansatta serviceavtal i kontexten för flöden bör du komma ihåg att olika flöden har olika definitioner av kritiskhet. Tänk på dessa skillnader när du skapar dina sammansatta serviceavtal. Icke-kritiska flöden kan ha komponenter som du bör utelämna från dina beräkningar eftersom de inte påverkar kundupplevelsen om de är kort otillgängliga.

Anteckning

Kundriktade arbetsbelastningar och interna arbetsbelastningar har olika serviceavtal. Vanligtvis kan arbetsbelastningar för intern användning ha mycket mindre restriktiva tillgänglighets-SLO:er än kundriktade arbetsbelastningar.

SLI:er

Tänk på SLI:er som mått på komponentnivå som bidrar till ett servicenivåmål. De viktigaste SLA:erna är de som påverkar dina kritiska flöden ur dina kunders perspektiv. För många flöden omfattar SLI:er svarstid, dataflöde, felfrekvens och tillgänglighet. En bra SLI hjälper dig att identifiera när ett servicenivåmål riskerar att brytas. Korrelera SLI med specifika kunder när det är möjligt.

Om du vill undvika att samla in oanvändbara mått begränsar du antalet SLI:er för varje flöde. Sikta på tre SLI:er per flöde om det är möjligt.

Återställningsmått

Återställningsmål motsvarar RTO-, RPO-, MTTR- och MTBF-mått. Till skillnad från tillgänglighetsmål är återställningsmålen för dessa mått inte särskilt beroende av Microsofts serviceavtal. Microsoft publicerar RTO- och RPO-garantier endast för vissa produkter, till exempel SQL Database.

Definitioner för realistiska återställningsmål förlitar sig på din fellägesanalys och dina planer och testning för affärskontinuitet och haveriberedskap. Innan du slutför det här arbetet ska du diskutera ambitiösa mål med intressenter och se till att arkitekturdesignen stöder återställningsmålen så bra som möjligt. Meddela intressenterna tydligt att alla flöden eller hela arbetsbelastningar som inte testas noggrant för återställningsmått inte ska ha garanterade serviceavtal. Se till att intressenterna förstår att återställningsmålen kan ändras med tiden när arbetsbelastningarna uppdateras. Arbetsbelastningen kan bli mer komplex när kunderna läggs till eller när du använder nya tekniker för att förbättra kundupplevelsen. Dessa ändringar kan öka eller minska dina återställningsmått.

Anteckning

MTBF kan vara svårt att definiera och garantera. Plattformar som en tjänst (PaaS) eller programvara som en tjänst (SaaS) kan misslyckas och återställas utan meddelanden från molnleverantören, och processen kan vara helt transparent för dig eller dina kunder. Om du definierar mål för det här måttet täcker du endast komponenter som är under din kontroll.

När du definierar återställningsmål definierar du tröskelvärden för att initiera en återställning. Om en webbnod till exempel inte är tillgänglig i mer än 5 minuter läggs en ny nod automatiskt till i poolen. Definiera tröskelvärden för alla komponenter, med tanke på vad återställning för en specifik komponent innebär, inklusive effekten på andra komponenter och beroenden. Dina tröskelvärden bör också ta hänsyn till tillfälliga fel för att säkerställa att du inte startar återställningsåtgärder för snabbt. Dokumentera och dela med intressenterna de potentiella riskerna med återställningsåtgärder, till exempel dataförlust eller sessionsavbrott för kunder.

Skapa en hälsomodell

Använd de data som du har samlat in för dina tillförlitlighetsmål för att skapa din hälsomodell för varje arbetsbelastning och associerade kritiska flöden. En hälsomodell definierar felfria, degraderade och felfria tillstånd för flöden och arbetsbelastningar. Staterna säkerställer lämplig operativ prioritering. Den här modellen kallas även för en trafikljusmodell. Modellen tilldelar grönt för felfri, gul för degraderad och röd för felfritt. En hälsomodell säkerställer att du vet när ett flödes tillstånd ändras från felfri till degraderad eller inte felfri.

Hur du definierar felfria, degraderade och ej felfria tillstånd beror på dina tillförlitlighetsmål. Här följer några exempel på hur du kan definiera tillstånden:

• Ett grönt eller felfritt tillstånd indikerar att viktiga icke-funktionella krav och mål är helt uppfyllda och att resurser används optimalt. Till exempel bearbetas 95 procent av begäranden i <=500 ms med noden Azure Kubernetes Service (AKS) med X procent.

• Ett gult eller degraderat tillstånd anger att en eller flera komponenter i flödet aviserar mot det definierade tröskelvärdet, men flödet fungerar. Till exempel har lagringsbegränsning identifierats.

• Ett rött eller felfritt tillstånd indikerar att försämringen har bevarats längre än vad som kan tillåtas av dina tillförlitlighetsmål eller att flödet har blivit otillgängligt.

Anteckning

Hälsomodellen ska inte behandla alla fel på samma sätt. Hälsomodellen bör skilja mellan tillfälliga och icke-övergående fel. Den bör tydligt skilja mellan förväntade och tillfälliga men återställningsbara fel och ett verkligt katastroftillstånd.

Den här modellen fungerar med hjälp av en strategi för övervakning och aviseringar som utvecklas och drivs enligt principerna för kontinuerlig förbättring. När dina arbetsbelastningar utvecklas måste dina hälsomodeller utvecklas med dem.

Detaljerade designöverväganden och rekommendationer för en hälsomodell för skiktade program finns i vägledningen för hälsomodellering i de verksamhetskritiska designområdena för arbetsbelastningar. Detaljerad vägledning om konfigurationer för övervakning och aviseringar finns i hälsoövervakningsguiden .

Visualisering

Överväg att skapa instrumentpaneler i din övervakningslösning för att hålla dina driftsteam och arbetsbelastningsintressenter informerade om realtidsstatus och övergripande trender i modellen för arbetsbelastningshälsa. Diskutera visualiseringslösningar med intressenterna för att säkerställa att du levererar den information som de värdesätter och som är enkel att använda. De kanske också vill se genererade rapporter varje vecka, varje månad eller kvartal.

Azure-underlättande

Azure-serviceavtal tillhandahåller Microsoft-åtaganden för drifttid och anslutning. Olika tjänster har olika serviceavtal, och ibland har SKU:er i en tjänst olika serviceavtal. Mer information finns i Serviceavtal för onlinetjänster.

Serviceavtalet för Azure innehåller procedurer för att erhålla en tjänstkredit om serviceavtalet inte uppfylls, tillsammans med definitioner av tillgänglighet för varje tjänst. Den här delen av serviceavtalet fungerar som en princip för genomdrivande.

Relaterade länkar

• Well-Architected Framework– verksamhetskritisk vägledning för hälsomodellering: Hälsomodellering och observerbarhet för verksamhetskritiska arbetsbelastningar i Azure

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

Checklista för tillförlitlighet