Anbefalinger til definition af stabilitetsmål
Gælder for denne Power Platform anbefaling af tjekliste for velstruktureret pålidelighed:
| RE:04 | Definer pålidelighed- og gendannelsesmål for komponenterne, flowene og den overordnede løsning. Visualiser målene for at afstemme, opnå konsensus, angive forventninger og drive handlinger for at opnå den ideelle tilstand. Brug de definerede mål til at oprette en tilstandsmodel. I tilstandsmodellen defineres, hvordan sunde, forringede og usunde tilstande ser ud. |
|---|
I denne guide beskrives anbefalingerne til definition af metrikværdier for tilgængelighed og gendannelse for vigtige arbejdsbelastninger. Pålidelighedsmål er afledt gennem workshop-øvelser med virksomhedens interessenter.
Målene forbedres gennem overvågning og test. Arbejd med dine interne interessenter for at etablere realistiske forventninger om stabilitet. Denne øvelse hjælper også interessenterne med at understøtte dine valg af arkitektonisk design og forstå, at du designer, så det bedst lever op til de mål, I er blevet enige om.
Microsoft Power Platform håndterer bekymringer om tilgængelighed og pålidelighed på infrastrukturniveau for dig. Tilgængeligheden af de arbejdsbelastninger, du opbygger, er imidlertid et delt ansvar. Det er vigtigt at forstå, at selv med Microsofts engagement til høj tilgængelighed er risikoen for systemets nedetid aldrig nul.
Overvej at bruge følgende metrikværdier til at sætte tal på forretningskravene.
| Begreb | Definition |
|---|---|
| Mål for serviceaftale (SLO) | En procentdel, der repræsenterer komponentens tilstand og pålidelighedsniveau. Jo højere niveau, desto mere pålidelig er komponenten. Sammensat SLO repræsenterer det samlede mål for hele arbejdsbelastningen og tegner sig for komponent-SLO'erne. |
| SLI (Service-Level Indicator) | En metrikværdi, der udsendes af en service. SLI-metrikværdier samles for at kvantificere en SLO-værdi. |
| Serviceaftale (SLA) | En kontraktaftale mellem tjenesteudbyderen og servicekunden. I aftalen defineres SLO'erne. Hvis aftalen ikke overholdes, kan det have økonomiske konsekvenser for tjenesteudbyderen. |
| Gennemsnitlig tid til gendannelse (MTTR) | Den tid, det tager at gendanne en komponent, efter at en fejl er registreret. |
| Gennemsnitlig tid mellem fejl (MTBF) | Den varighed, som arbejdsbelastningen kan udføre den forventede funktion uden afbrydelse, indtil det går ned. |
| RTO (Recovery Time Objective) | Den maksimale acceptable tid, en applikation ikke kan være tilgængeligt efter en hændelse. |
| RPO (Recovery Point Objective) | Den maksimale acceptable varighed af tab af data under en hændelse. |
Definer arbejdsbelastningens målværdier for disse metrikværdier i sammenhængen af bruger- og systemflows. Identificer og bedøm disse flows efter, hvor kritiske de er for dine behov. Brug værdierne til at fremme design af arbejdsbelastningen med hensyn til arkitektur, gennemgang, test og hændelsesstyring. Hvis målene ikke overholdes, påvirkes forretningen ud over toleranceniveauet.
Vigtigste designstrategier
Tekniske diskussioner bør ikke bruges til at definere stabilitetsmål for vigtige flows. I stedet bør forretnings interessenter fokusere på deres krav og forventningerne til slutbrugerne af arbejdsbelastningen. Tekniske eksperter hjælper interessenterne med at tildele numeriske værdier, der opfylder disse krav. Ved at udveksle oplysninger gør tekniske eksperter det muligt at diskutere og nå til aftale om uafhængige SLO'er.
Overvej et eksempel på, hvordan du kan knytte krav til målbare numeriske værdier. Interessenterne vurderer, at for et vigtigt brugerflow resulterer en time med nedetid i almindelige forretningstimer i tab af X dollar i månedlig omsætning. Dette beløb i dollar sammenlignes med de anslåede omkostninger ved at designe et flow, der har en tilgængeligheds-SLO på 99,95 procent i stedet for 99,9 procent. Beslutningstagerne skal diskutere, om risikoen for tab af omsætning skaber de ekstra omkostninger og den administrative belastning, der er forbundet med at beskytte mod den.
Følg dette mønster, når du undersøger flows og opbygger en komplet liste over mål.
Husk, at stabilitetsmål er forskellige fra præstationsmål. Stabilitetsmål fokuserer på tilgængelighed og gendannelse. Hvis du vil angive stabilitetsmål, skal du starte med at definere de bredest mulige krav og derefter definere mere specifikke målepunkter for at imødekomme de overordnede krav.
Krav til stabilitet og gendannelse på højeste niveau og korrelerede metrikværdier kan f.eks. omfatte en applikationstilgængelighed på 99,9 procent for alle områder eller en RTO på 5 timer for USA. Hvis du definerer disse typer mål, kan du bedre identificere, hvilke vigtige flows der er involveret i disse mål. Derefter kan du overveje mål på komponentniveau.
Tilgængelighedsmetrikværdier
Tilgængelighedsmål svarer til SLO-, serviceaftale- og SLI-metrikværdier.
SLO'er og serviceaftaler
Tilgængelighedsmetrikværdier korrelerer med SLO'er, som du bruger til at definere serviceaftaler. Arbejdsbelastnings-SLO'en bestemmer, hvor meget nedetid der kan bruges i en bestemt periode. f.eks. mindre end 1 time om måneden. Hvis du vil sikre dig, at du kan opfylde SLO-målet, skal du gennemgå Microsofts serviceaftaler hver enkelt komponent.
Hvis du vil oprette SLO'er, skal du overveje følgende:
Ikke-funktionsrelaterede krav til arbejdsbelastningen (f.eks. antallet af maksimale anmodninger, samtidige brugere) i løbet af de næste 1-2 år.
Tilgængelige metrikværdier for, hvad du kan måle over en bestemt tidsperiode. Disse data angiver, hvilke SLI'er der skal angives.
Når du har indsamlet serviceaftalerne for de enkelte arbejdsbelastningskomponenter, skal du beregne en sammensat serviceaftale. Den sammensatte serviceaftale skal svare til arbejdsbelastningens mål-SLO. Beregningen af en sammensat serviceaftale involverer flere faktorer, afhængigt af dit arkitekturdesign.
Når du definerer korrekte SLO'er, skal du tage dig tid og nøje overveje dette. Forretningsmæssige interessenter skal forstå pålidelighedtolerancen. Denne feedback skal informere målene.
Serviceaftaleværdier
I følgende tabel defineres fælles serviceaftaleværdier.
| SLA | Nedetid pr. uge | Nedetid pr. måned | Nedetid pr. år |
|---|---|---|---|
| 99 % | 1.68 timer | 7.2 timer | 3.65 dage |
| 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 tænker på sammensatte serviceaftaler i forbindelse med bruger- og systemforløb, skal du huske, at forskellige bruger- og systemflows har forskellige definitioner af kritiskhed. Overvej disse forskelle, når du bygger de sammensatte serviceaftaler. Ikke-kritiske flows kan have komponenter, du skal udelade i dine beregninger, da de ikke påvirker kundeoplevelsen, hvis de kort tid ikke er tilgængelige.
SLI'er
Tønk på SLI'er som metrikværdier på komponentniveau, der bidrager til en SLO. De vigtigste SLI'er er dem, der påvirker dine vigtige flows fra kundernes perspektiv. I forbindelse med mange flow omfatter SLI'er ventetid, gennemløb, fejlprocent og tilgængelighed. En god SLI hjælper dig med at identificere, hvornår en SLO er i risiko for at blive identificeret. Korreler SLI til bestemte kunder, når det er muligt.
Hvis du vil undgå indsamling af metrikker, der kan bruges, skal du begrænse antallet af SLI'er for hvert flow. Mål for tre SLI'er pr. flow, hvis det er muligt.
Gendannelsesmetrikværdier
Gendannelsesmål svarer til RTO-, RPO-, MTTR-, og MTBF-metrikværdier. I modsætning til målene for tilgængelighed afhænger genoprettelsesmål for disse målinger ikke i stort grad af Microsofts serviceaftaler. Microsoft udgiver kun RTO- og RPO-garantier for visse produkter, f.eks. SQL Database.
Definitionerne af realistiske indtægtsberedskabsmål er baseret på din fejltilstandsanalyse og dine planer og test med henblik på forretningskontinuitet og it-katastrofeberedskab. Inden du afslutter dette arbejde, skal du diskutere vigtige mål med interessenter og sikre, at arkitekturdesignet understøtter målene for gendannelse efter din bedste forståelse. Du skal klart kommunikere til interessenterne, at alle dele af arbejdsbelastningen, der ikke er grundigt testet for gendannelsesmetrikværdier, ikke skal have garanterede serviceaftaler. Sørg for, at interessenterne forstår, at målene for gendannelse kan ændre sig med tiden, efterhånden som arbejdsbelastninger opdateres. Arbejdsbelastningen kan blive mere kompleks, efterhånden som du bruger nye teknologier til at forbedre brugeroplevelsen. Disse ændringer kan øge eller formindske dine gendannelsesmetrikværdier.
Bemærk
Det kan være en udfordring at definere og garantere MTBF. Platforme som en service (PaaS) eller software as a service (SaaS) kan mislykkes og gendannes uden meddelelse fra cloududbyderen, og processen kan være helt gennemskuelig for dig. Hvis du definerer mål for denne metrikværdi, skal du kun dække komponenter, der er under din kontrol.
Opbygning af en tilstandsmodel
Brug de data, du har indsamlet til dine stabilitetsmål, til at opbygge din tilstandsmodel for hver arbejdsbelastning og tilknyttede vigtige flows. En tilstandsmodel definerer sunde, forringede og ikke-sunde* tilstande for flows og arbejdsbelastninger. Tilstandene sikrer den rette driftsmæssige prioritering. Denne model kaldes også en trafiklysmodel. I modellen tildeler grøn for sundt, gult for forringet og rød for ikke-sund. En tilstandsmodel sikrer, at du ved, hvornår tilstanden for et flow ændres fra sund til forringet eller ikke-sund.
Den måde, du definerer sunde, forringede og ikke-sunde tilstande på, afhænger af målene for stabilitet. Her er nogle eksempler på, hvordan du kan definere tilstande:
En grøn eller sund tilstand indikerer, at nøglekrav og -mål er fuldt ud opfyldt, og at ressourcer bruges optimalt.
En gul eller forringet tilstand indikerer, at en eller flere komponenter i flowet advarer mod den definerede tærskelværdi, men flowet er driftklart. Der er f.eks. registreret lageroplagring.
En rød eller ikke-sund tilstand indikerer, at forringelsen har varet længere end det, der kan tillades af stabilitetsmålene, eller at flowet ikke er blevet tilgængeligt.
Bemærk
Tilstandsmodellen skal ikke behandle alle fejl på samme måde. Sundhedsmodellen bør skelne mellem forbigående og ikke-forbigående fejl. Der skal klart skelnes mellem forventede, men genoprettelige fejl og en sand katastrofetilstand.
Denne model fungerer ved hjælp af en overvågnings- og advarselsstrategi, der udvikles og drives ud fra principperne om løbende forbedringer. Efterhånden som arbejdsbelastningerne udvikler sig, skal dine tilstandsmodeller udvikle sig med dem.
Du kan finde en detaljeret vejledning i konfigurationer af overvågning og advarsler i vejledningen Overvågning af tilstand.
Visualisering
Hvis du vil holde driftsteams og interessenter i arbejdsbelastning orienteret om status i realtid og de overordnede tendenser i tilstandsmodellen for arbejdsbelastning, skal du overveje at oprette dashboards i din overvågningsløsning. Diskuter visualiseringsløsninger med interessenterne for at sikre, at du leverer de oplysninger, de værdsætter, og som er brugervenlige. De kan også få vist genererede ugentlige, månedlige eller kvartalsvise rapporter.
Power Platform-processtyring
Power Platform SlA'er giver Microsoft tilsagn om oppetid og forbindelse. Forskellige tjenester har forskellige SLA'er, og undertiden har SKU'er i en tjeneste forskellige SLA'er. Få flere oplysninger i Aftaler for onlinetjenester på tjenesteniveau.
Power Platform-serviceaftalen indeholder procedurer til indhentning af en servicekreditering, hvis serviceaftalen ikke opfyldes, sammen med definitioner på tilgængelighed for de enkelte services. Dette aspekt af serviceaftalen fungerer som en håndhævelsespolitik.
Microsoft Business Applications leverer BCDR-funktioner (Business Continuity and Disaster Recovery) til alle produktionstypemiljøeri Dynamics 365 og Power Platform SaaS-applikationer. Få mere at vide om, hvordan Microsoft sikrer, at dine produktionsdata er robuste under regionale afbrydelser.
Organisatorisk justering
Cloud Adoption Framework indeholder en vejledning i anbefalinger til SLO'er og SLI'er til overvågning på tværs af organisationen.
Du kan finde flere oplysninger i Cloudovervågnings-SLO'er.
Kontrolliste for bæredygtighed
Se det fuldstændige sæt anbefalinger.