Anbefalinger for å definere pålitelighetsmål
Gjelder denne Power Platform anbefalingen for sjekkliste for godt strukturert pålitelighet:
| Referanse:04 | Definer pålitelighets- og gjenopprettingsmål for komponentene, flytene og den totale løsningen. Visualiser målene for å forhandle, få enighet, angi forventninger og fremme handlinger for å oppnå den ideelle tilstanden. Bruk de definerte målene til å bygge tilstandsmodellen. Tilstandsmodellen definerer hvordan sunne, nedsatte og usunne tilstander ser ut. |
|---|
Denne veiledningen beskriver anbefalingene for å definere måleverdier for tilgjengelighet og gjenoppretting for kritiske arbeidsbelastninger. Pålitelighetsmål utledes gjennom seminarøvelser med forretningsinteressenter.
Målene forbedres gjennom overvåking og testing. Arbeid med de interne interessentene for å etablere realistiske forventninger om pålitelighet. Denne øvelsen vil også hjelpe interessenter med å støtte valgene dine for arkitekturutforming og forstå at dere utformer slik at dere best mulig kan nå målene dere ble enige om.
Microsoft Power Platform håndterer de fleste tilgjengelighets- og pålitelighetsbekymringer på infrastrukturnivå for deg. Tilgjengeligheten av arbeidsbelastningene du bygger, er imidlertid et delt ansvar. Det er viktig å forstå at selv med Microsofts engasjement for høy tilgjengelighet er risikoen for nedetid for systemet aldri på null.
Vurder å bruke følgende måleverdier til å kvantifisere forretningskravene.
| Term | Definisjon |
|---|---|
| Servicenivåmål (SLO) | Et prosentmål som representerer tilstanden for komponenten og pålitelighetsnivået. Jo høyere nivå, jo mer pålitelig er komponenten. Sammensatt serviceavtale representerer det samlede målet for hele arbeidsbelastningen og tar hensyn til komponent-serviceavtalene. |
| Servicenivåindikator (SLI) | En måleverdi som sendes ut av en tjeneste. SLI-måleverdier aggregeres for å kvantifisere en SLO-verdi. |
| Serviceavtale (SLA) | En kontraktsavtale mellom tjenesteleverandøren og servicekunden. Avtalen definerer SLO-ene. Hvis avtalen ikke overholdes, kan det få økonomiske konsekvenser for tjenesteleverandøren. |
| Middeltid for gjenoppretting (MTTR) | Tiden det tar å gjenopprette en komponent etter at en feil ble oppdaget. |
| Middeltid mellom feil (MTBF) | Hvor lenge arbeidsbelastningen kan utføre den forventede funksjonen uten avbrudd, til den mislykkes. |
| Mål for gjenopprettingstid (RTO) | Maksimal akseptabel tid der et program ikke er tilgjengelig etter en hendelse. |
| Mål for gjenopprettingspunkt (RPO) | Maksimal akseptabel varighet for tap av data under en hendelse. |
Definer målverdiene for arbeidsbelastningen for disse måleverdiene i konteksten for bruker- og systemflyter. Identifiser og ranger disse flytene etter hvor kritiske de er for dine behov. Bruk verdiene til å styre utformingen av arbeidsbelastningen i form av arkitektur, gjennomgang, testing og hendelsesbehandling. Hvis målene ikke oppfylles, vil dette påvirke virksomheten utover toleransenivået.
Viktige utformingsstrategier
Tekniske diskusjoner bør ikke styre hvordan du definerer pålitelighetsmål for kritiske flyter. I stedet bør forretningsinteressenter fokusere på sine krav og forventningene til sluttbrukerne av arbeidsbelastningen. Tekniske eksperter hjelper interessentene med å tilordne realistiske numeriske verdier som oppfyller disse kravene. Ved å utveksle informasjon muliggjør tekniske eksperter diskusjon og avtale om gjennomførbare SLO-er.
Vurder et eksempel på hvordan du tilordner krav til målbare numeriske verdier. Interessenter estimerer at for en kritisk brukerflyt fører en times nedetid i vanlig arbeidstid til et tap på X dollar i månedlig omsetning. Dette dollarbeløpet sammenlignes med den beregnede kostnaden for utforming av en flyt som har en tilgjengelighets-SLO på 99,95 prosent i stedet for 99,9 prosent. Beslutningstakerne må diskutere om risikoen for dette omsetningstapet oppveier de ekstra kostnadene og administrasjonsbyrden som kreves for å beskytte mot det.
Følg dette mønsteret når du undersøker flyter og bygger en fullstendig liste over mål.
Husk at pålitelighetsmål er forskjellige fra ytelsesmål. Pålitelighetsmål fokuserer på tilgjengelighet og gjenoppretting. For å angi pålitelighetsmål må du starte ved å definere de bredeste kravene og deretter definere mer spesifikke måleverdier for å oppfylle kravene på høyt nivå.
Krav til pålitelighet og gjenoppretting på høyeste nivå og korrelerte måleverdier kan for eksempel omfatte en programtilgjengelighet på 99,9 prosent for alle regioner, eller en mål-RTO på 5 timer for Amerika. Når du definerer disse måltypene, blir det enklere å identifisere hvilke kritiske flyter som er involvert i disse målene. Deretter kan du vurdere mål på komponentnivå.
Måleverdier for tilgjengelighet
Tilgjengelighetsmål tilsvarer måleverdier for SLO, SLA og SLI.
SLO-er og SLA-er
Måleverdier for tilgjengelighet korrelerer med SLO-er, som du bruker til å definere SLA-er. SLO-en for arbeidsbelastningen avgjør hvor mye nedetid som kan tolereres i en bestemt periode, for eksempel mindre enn 1 time per måned. For å være sikker på at du kan oppfylle SLO-målet, må du se gjennom Microsofts serviceavtaler for hver komponent.
Tenk på følgende når du skal etablere SLO-er:
Ikke-funksjonelle krav til arbeidsbelastningen din (for eksempel topp forespørselsrater, samtidige brukere) i løpet av de neste 1-2 årene.
Tilgjengelige måleverdier for hva du kan måle i løpet av en bestemt tidsperiode. Disse dataene informerer deg om hvilke SLI-er som må spesifiseres.
Når du har samlet inn SLA-ene for de enkelte arbeidsbelastningskomponentene, beregner du en sammensatt SLA. Den sammensatte SLA-en skal samsvare med arbeidsbelastningens mål-SLO. Beregning av en sammensatt SLA omfatter flere faktorer, avhengig av arkitekturutformingen.
Definering av ordentlige SLO-er tar tid og nøye vurdering. Forretningsinteressenter bør forstå pålitelighetstoleransen. Denne tilbakemeldingen må informere målene.
SLA-verdier
Den følgende tabellen definerer vanlige SLA-verdier.
| Serviceavtale | Nedetid per uke | Nedetid per måned | Nedetid per år |
|---|---|---|---|
| 99 % | 1.68 timer | 7.2 timer | 3.65 dager |
| 99,9 % | 10.1 minutter | 43.2 minutter | 8.76 timer |
| 99,95 % | 5 minutter | 21.6 minutter | 4.38 timer |
| 99,99 % | 1.01 minutter | 4.32 minutter | 52.56 minutter |
| 99,999 % | 6 sekunder | 25.9 sekunder | 5.26 minutter |
Når du tenker på sammensatte SLA-er i konteksten for bruker- og systemflyter, må du huske at forskjellige bruker- og systemflyter har forskjellige definisjoner for kritiskhet. Vurder disse forskjellene når du bygger sammensatte SLA-er. Ikke-kritiske flyter kan ha komponenter som du bør utelate fra beregningene, fordi de ikke påvirker kundeopplevelsen hvis de bare er uilgjengelige i en kort stund.
SLI-er
Tenk på SLI-er som måleverdier på komponentnivå som bidrar til en SLO. De mest signifikante SLI-ene er de som påvirker dine kritiske flyter fra kundenes perspektiv. For mange flyter inkluderer SLI-er latens, gjennomstrømning, feilfrekvens og tilgjengelighet. En god SLI hjelper deg med å identifisere når det er fare for brudd på en SLO. Korreler SLI-en til spesifikke kunder når det er mulig.
Begrens antall SLI-er for hver flyt for å unngå å samle inn unyttige måleverdier. Prøv å ha tre SLI-er per flyt hvis mulig.
Måleverdier for gjenoppretting
Gjenopprettingsmål tilsvarer måleverdier for RTO, RPO, MTTR og MTBF. Til forskjell fra tilgjengelighetsmål er ikke gjenopprettingsmål for disse målingene svært avhengige av Microsofts SLA-er. Microsoft publiserer RTO- og RPO-garantier bare for enkelte produkter, for eksempel SQL Database.
Definisjoner for realistiske gjenopprettingsmål avhenger av feilmodusanalysen, planene dine, testingen for kontinuitet og nødgjenoppretting. Før du fullfører dette arbeidet, bør du diskutere aspirerende mål med interessenter og sørge for at arkitekturutformingen støtter gjenopprettingsmålene så godt du kan. Kommuniser tydelig med interessenter om at delene av arbeidsbelastningen som ikke er grundig testet for gjenopprettingsmålinger, ikke skal ha garanterte SLA-er. Sørg for at interessentene forstår at gjenopprettingsmål kan endres over tid etter hvert som arbeidsbelastninger oppdateres. Arbeidsbelastningen kan bli mer kompleks etter hvert som du innfører ny teknologi for å forbedre brukeropplevelsen. Disse endringene kan øke eller redusere måleverdiene for gjenoppretting.
Merk
MTBF kan være utfordrende å definere og garantere. Det kan oppstå feil på PaaS (plattform som tjeneste) eller SaaS (programvare som tjeneste), som kan gjenopprettes uten forvarsel fra skyleverandøren, og prosessen kan være fullstendig transparent for deg. Hvis du definerer mål for denne måleverdien, må du kun dekke komponenter som du har kontroll over.
Bygging av en tilstandsmodell
Bruk dataene du har samlet inn for pålitelighetsmålene, til å bygge opp tilstandsmodellen for hver arbeidsbelastning og tilknyttede kritiske flyter. En tilstandsmodell definerer tilstandene sunn, redusert og usunn* for flyter og arbeidsbelastninger. Tilstandene sørger for hensiktsmessig driftsprioritering. Denne modellen er også kjent som en trafikklysmodell. Modellen tilordner grønt for sunn, gul for redusert og rød for usunn. En tilstandsmodell sikrer at du vet når tilstanden for en flyt endres fra sunn til redusert eller usunn.
Hvordan du definerer sunne, reduserte og usunne tilstander avhenger av pålitelighetsmålene. Her er noen eksempler på hvordan du kan definere tilstandene:
En grønn eller sunn tilstand angir at viktige ikke-funksjonelle krav og mål er fullstendig innfridd, og at ressursene brukes optimalt.
En gul eller redusert tilstand angir at én eller flere komponenter i flyten varsler mot den definerte terskelen, men flyten er i drift. For eksempel er begrensning av lagringsplass påvist.
En rød eller usunn tilstand angir at forringelsen har vedvart lengre enn tillatt av pålitelighetsmålene, eller at flyten har blitt utilgjengelig.
Merk
Tilstandsmodellen bør ikke behandle alle feil på samme måte. Helsemodellen bør skille mellom forbigående og ikke-forbigående feil. Den må tydelig skille mellom forventede-midlertidige, men gjenopprettbare feil og en virkelig nødtilstand.
Denne modellen fungerer ved å bruke en overvåkings- og varslingsstrategi som utvikles og drives etter prinsippene om kontinuerlig forbedring. Etter hvert som arbeidsbelastningene dine utvikler seg, må tilstandsmodellene utvikles med dem.
Hvis du vil ha detaljert rettledning om overvåkings- og varslingskonfigurasjoner, kan du se veiledningen om tilstandsovervåking.
Visualisering
For å holde driftsteamene og interessentene informert om sanntidsstatusen og de generelle trendene for tilstandsmodellen for arbeidsbelastningen, kan du vurdere å opprette instrumentbord i overvåkingsløsningen. Diskuter visualiseringsløsninger med interessentene for å sikre at du leverer informasjonen de setter pris på, og som er enkel å fordøye. De ønsker kanskje også å se genererte rapporter ukentlig, månedlig eller kvartalsvis.
Tilrettelegging for Power Platform
Power Platform-serviceavtaler gir Microsoft forpliktelser vedrørende oppetid og tilkobling. Ulike tjenester har ulike serviceavtaler, og noen ganger har SKU-er i en tjeneste ulike serviceavtaler. Hvis du vil ha mer informasjon, kan du se Serviceavtaler for onlinetjenester.
Serviceavtalen for Power Platform inneholder prosedyrer for å få en servicekreditt hvis serviceavtalen ikke oppfylles, sammen med definisjoner av tilgjengelighet for hver tjeneste. Dette aspektet ved serviceavtalen fungerer som en håndhevelsespolicy.
Microsoft Business Applications leverer funksjoner for forretningskontinuitet og nødgjenoppretting til alle produksjonsmiljøer i Dynamics 365-apper og Power Platform SaaS-apper. Finn ut hvordan Microsoft sikrer at produksjonsdataene dine er robuste under regionale avbrudd.
Organisasjonsjustering
Cloud Adoption Framework gir veiledning for anbefalinger for SLO-er og SLI-er relatert til overvåking i hele organisasjonen.
Hvis du vil ha mer informasjon, kan du se SLO-er for overvåking i skyen.
Sjekkliste for pålitelighet
Se hele settet med anbefalinger.