Rekommendationer för att definiera tillförlitlighetsmålen
Gäller för den här Power Platform rekommendationen för checklistan Well-Architected Reliability :
| RE:04 | Ange tillförlitlighets- och återställningsmålen för komponenterna, flödena och den övergripande lösningen. Visualisera de mål som du sätter upp när du ska genomföra förhandlingarna, uppnå konsensus, sätta upp förväntningar och driva fram åtgärder som uppnår ett idealt läge. Skapa en hälsomodell med hjälp av de definierade målen. Hälsomodellen definierar hur tillstånden felfritt, försämrat och ej felfritt ser ut. |
|---|
Den här guiden innehåller rekommendationer för hur du definierar mått för tillgänglighet och återställningsmål för kritiska arbetsbelastningar. Tillförlitlighetsmålen fastställs med hjälp av en dialog med företagets intressenter.
Målen förbättras genom övervakning och testning. Arbeta med interna intressenter för att skapa realistiska förväntningar på tillförlitlighet. Den här övningen hjälper också intressenterna att stödja dina val av arkitekturdesign och förstå att du designa för att bäst uppfylla de mål ni kommit överens om.
Microsoft Power Platform hanterar de flesta frågor på infrastrukturnivå för tillgänglighet och tillförlitlighet åt dig. Tillgängligheten för de arbetsbelastningar som du skapar är emellertid ett delat ansvar. Det är viktigt att förstå att även med Microsofts åtagande om hög tillgänglighet är risken för att systemavbrott aldrig noll.
Överväg att använda följande mått för att fastställa verksamhetskraven.
| Begrepp | Definition |
|---|---|
| Mål för serviceavtal (SLO) | Ett procentmål som representerar komponentens hälsotillstånd och tillförlitlighetsnivå. Ju högre nivå, desto mer tillförlitlig är komponenten. Sammansatt serviceavtal representerar det aggregerade målet för hela arbetsbelastningen och står för komponentens servicenivåmål. |
| Servicenivåindikator (SLI) | Mått som genereras av en tjänst. SLI-mått samlas in för att kvantifiera ett SLO-värde. |
| Serviceavtal (SLA) | Ett kontrakterat avtal mellan tjänsteleverantören och tjänstens kund. I avtalet definieras SLO:erna. Om avtalet inte uppfylls kan det få ekonomiska konsekvenser för tjänsteleverantören. |
| Genomsnittlig tid till återställning (MITR) | 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 felar. |
| Mål för återställningstid (RTO) | Längsta godtagbara tid då en app inte kan vara tillgänglig efter en incident. |
| Mål för återställningspunkt (RPO) | Längsta godtagbara varaktighet för dataförlust under en incident. |
Definiera arbetsbelastningens målvärden för dessa mått för med användar- och systemflöden. Identifiera och poängsätt dessa flöden efter hur viktiga de är för dina krav. Använd värdena för att utforma arbetsbelastningen med avseende på arkitektur, granskning, testning och incidenthantering. Om du misslyckas med att uppnå målen påverkas verksamheten utanför toleransnivån.
Viktiga designstrategier
Tekniska diskussioner bör inte ligga till grund för hur du definierar tillförlitlighetsmålen för de kritiska flödena. I stället bör företagets intressenter fokusera på sina krav och på slutanvändarenas förväntningar på arbetsbelastningen. Med hjälp av tekniska experter kan intressenterna tilldela numeriska värden som uppfyller dessa krav. Genom att utbyta information kan tekniska experter diskutera och enas om genomförbara SLO:er.
Tänk dig hur du mappar krav till mätbara numeriska värden. Intressenterna beräknar att en timmes driftavbrott under kontorstid för ett kritiskt användarflöde resulterar i en förlust på X kronor i månadsintäkt. Det dollarbeloppet jämförs med den beräknade kostnaden för att utforma ett flöde med en tillgänglighets-SLO på 99,95 procent i stället för 99,9 procent. Beslutsfattarna måste diskutera om risken för intäktsförlust uppväger den extra kostnaden och hanteringsarbetet som krävs för att skyddet.
Följ det här mönstret när du undersöker flöden och skapar en fullständig lista med mål.
Kom ihåg att tillförlitlighetsmålen skiljer sig från prestandamålen. Tillförlitlighetsmålen fokuserar på tillgänglighet och återställning. När du vill ange tillförlitlighetsmålen börjar du med att definiera de bredaste kraven, och sedan definierar du mer specifika mått för att uppfylla kraven på hög nivå.
Högsta tillförlitlighets- och återställningskrav samt korrelerade mått kan till exempel omfatta en programtillgänglighet på 99,9 procent för alla regioner eller ett mål-RTO på 5 timmar för regionen Nordamerika, Centralamerika och Sydamerika. Genom att definiera dessa typer 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å.
Tillgänglighetsmått
Tillgänglighetsmålen motsvarar måtten SLO, SLA och SLI.
SLO och SLA
Tillgänglighetsmåtten korrelerar med SLO:er, som du använder för att definiera SLA:er. Arbetsbelastningens SLO avgör hur mycket driftavbrott som tolereras under en viss period, till exempel mindre än 1 timme per månad. Se till att du kan uppnå SLO-målet genom att granska Microsofts SLA:er för varje komponent.
När du vill skapa SLO:er bör du tänka på följande:
Icke-funktionella krav för din arbetsbelastning (till exempel priser vid hög belastning, samtidiga användare) under de kommande 1–2 åren.
Tillgängliga mått på vad du kan mäta under en viss tidsperiod. Dessa data informerar om vilka SLI:er du vill ange.
När du har samlat SLA:er för de enskilda arbetsbelastningskomponenterna beräknar du ett sammansatt SLA. Det sammansatta SLA:et ska matcha arbetsbelastningens mål-SLO. Att beräkna ett sammansatt SLA omfattar flera faktorer, beroende på arkitekturens utformning.
Det krävs tid och omsorg för att definiera lämpliga SLO:er. Företagets intressenter bör förstå till tillförlitlighetens tolerans. Denna feedback ska ligga till grund för målen.
SLA-värden
I följande tabell definieras vanliga SLA-värden.
| SLA | Driftstopp per vecka | Driftstopp per månad | Driftstopp 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 SLA:er i samband med användar- och systemflöden, ska du komma ihåg att olika användar- och systemflöden har olika kritiska definitioner. Tänk på dessa skillnader när du skapar sammansatta SLA:er. Icke-kritiska flöden kan ha komponenter som du bör utelämna från beräkningarna, eftersom de inte påverkar kundupplevelsen om de är otillgängliga under en kort tid.
SLI
Tänk på SLI:er som mått på komponentnivå som bidrar till en SLO. De viktigaste SLI:erna är de som påverkar dina kritiska flöden utifrån kundeperspektiv. För många flöden, SLA:er omfattar latens, dataflöde, felfrekvens och tillgänglighet. Ett bra SLI hjälper dig att identifiera när en SLO riskerar att brytas. Korrelera SLI:en med specifika kunder när det är möjligt.
Du kan undvika att samla in oanvändbara mått genom att begränsa 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ålen motsvarar måtten RTO, RPO, MTTR och MTBF. Till skillnad mot tillgänglighetsmålen är inte återställningsmålen för dessa mått beroende av Microsofts SLA:er. Microsoft publicerar RTO- och RPO-garantier enbart för vissa produkter, som SQL Database.
Definitionerna för återställningsmålen grundar sig på din analys av felläge och dina planer för testning av verksamhetskontinuitet samt haveriberedskap. Innan du slutför det här arbetet bör du diskutera viktiga mål med intressenter och se till att din arkitekturdesignen stöder återställningsmålen så bra det går. Kommunicera tydligt med intressenter om att alla delar av arbetsbelastningen som inte har testats ordentligt för återställningsmåtten inte bör ha garanterade SLA:er. 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 du använder ny teknik för att förbättra användarupplevelsen. Ändringarna kan öka eller minska återställningsmåtten.
Kommentar
MTBF kan vara svårare att definiera och garantera. Plattformar som en tjänst (PaaS) eller programvara som en tjänst (SaaS) kan fallera och återställas utan meddelanden från molnleverantören, och du kanske inte ens märker processen. Om du definierar mål för det här måttet omfattar du bara de komponenter som du har kontroll över.
Skapa en hälsomodell
Använd de data du samlat in för tillförlitlighetsmålen och skapa en hälsomodell för varje arbetsbelastning och tillhörande kritiska flöden. En hälsomodell definierar tillstånden felfritt, försämrat och ej felfritt* för flöden och arbetsbelastningar. Dessa tillstånd säkerställer en lämplig operativ prioritering. Den här modellen kallas även för trafikljusmodellen. Modellen tilldelar grön för felfritt, gult för försämrat och rött för ej felfritt. En hälsomodell säkerställer att du vet när ett flödestillstånd ändras från felfritt till försämrat eller ej felfritt.
Hur du definierar tillstånden felfritt, försämrat och ej felfritt beror på tillförlitlighetsmålen. Här följer några exempel på hur du kan definiera tillstånden:
Ett grönt eller felfritt tillstånd anger att viktiga icke-funktionella krav och mål är helt uppfyllda och att resurser används optimalt.
Ett gult eller försämrat tillstånd anger att en eller flera komponenter i flödet aviserar mot det definierade tröskelvärdet, men att flödet fungerar. Begränsad lagring har exempelvis identifierats.
Ett rött eller ej felfritt tillstånd anger att det försämrade tillståndet varat längre än vad som är tillåtet för tillförlitlighetsmålen eller att flödet inte är tillgängligt.
Kommentar
En hälsomodell bör inte behandla alla fel på samma sätt. Hälsomodellen bör skilja mellan tillfälliga och icke-tillfälliga fel. Den bör klart och tydligt skilja mellan förväntade övergående men återställningsbara fel och en riktig katastrof.
Modellen fungerar genom att använda en övervaknings- och aviseringsstrategi som utvecklas och drivs utifrån principerna för kontinuerlig förbättring. I takt med att arbetsbelastningar utvecklas måste dina hälsomodeller utvecklas med dem.
Detaljerad vägledning om övervaknings- och aviseringskonfigurationer finns i guiden för hälsoövervakning .
Visualisering
Om du vill hålla dina verksamhetsteam och intressenter informerade om status i realtid och allmänna trender i arbetsbelastningens hälsomodell bör du skapa instrumentpaneler i övervakningslösningen. Diskutera visualiseringslösningar med intressenterna för att se till att du levererar användbar information som är lätt att ta till sig. De kanske också vill ha genererade rapporter varje vecka, månad eller kvartal.
Underlätta Power Platform
Power Platform SLA tillhandahåller Microsoft-åtaganden om 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.
SLA för Power Platform innehåller procedurer för att få en tjänstekredit om SLA inte uppfylls, tillsammans med definitioner av tillgänglighet för varje tjänst. Den aspekten av SLA fungerar som en tvingande princip.
Microsoft Business Applications tillhandahåller funktioner för affärskontinuitet och haveriberedskap för alla miljöer av produktionstyp i Dynamics 365 och Power Platform SaaS-appar. Lär dig hur Microsoft säkerställer att dina produktionsdata är motståndskraftiga under regionala avbrott.
Organisationsanpassning
Cloud Adoption Framework ger vägledning för rekommendationer för SLO:er och SLI:er som är relaterade till övervakning av hela organisationen.
Mer information finns i SLO:er för molnövervakning.
Checklista för tillförlitlighet
Se den fullständiga uppsättningen med rekommendationer.