Aanbevelingen voor het definiëren van betrouwbaarheidsdoelen

Is van toepassing op deze aanbeveling voor de betrouwbaarheidschecklist van Azure Well-Architected Framework:

RE:04	Definieer betrouwbaarheids- en hersteldoelen voor de onderdelen, de stromen en de algehele oplossing. Visualiseer de doelen om te onderhandelen, consensus te bereiken, verwachtingen te stellen en acties aan te zetten om de ideale status te bereiken. Gebruik de gedefinieerde doelen om het statusmodel te bouwen. Het statusmodel definieert hoe statussen in orde, gedegradeerd en beschadigd eruitzien.

In deze handleiding worden de aanbevelingen beschreven voor het definiëren van metrische gegevens voor beschikbaarheids- en hersteldoel voor kritieke workloads en stromen. Betrouwbaarheidsdoelen worden afgeleid door workshopoefeningen met zakelijke belanghebbenden. De doelen worden verfijnd door middel van bewaking en testen.

Stel met uw interne belanghebbenden realistische verwachtingen in voor de betrouwbaarheid van workloads, zodat belanghebbenden deze verwachtingen via contractuele overeenkomsten aan klanten kunnen communiceren. Realistische verwachtingen helpen belanghebbenden ook om uw beslissingen over architectuurontwerpen te begrijpen en te ondersteunen en te weten dat u ontwerpt om optimaal te voldoen aan de doelen die u hebt afgesproken.

Overweeg het gebruik van de volgende metrische gegevens om de bedrijfsvereisten te kwantificeren.

Termijn	Definitie
Service level objective (SLO)	Een percentagedoel dat de status van het onderdeel en de betrouwbaarheidslaag aangeeft. Hoe hoger de laag, hoe betrouwbaarder het onderdeel. Samengestelde SLO vertegenwoordigt het geaggregeerde doel van de volledige workload en is verantwoordelijk voor de SLO's van het onderdeel.
Service level indicator (SLI)	Een metrische waarde die wordt verzonden door een service. Metrische SLI-gegevens worden geaggregeerd om een SLO-waarde te kwantificeren.
Service Level Agreement (SLA)	Een contractuele overeenkomst tussen de serviceprovider en de serviceklant. De overeenkomst definieert de SLO's. Het niet nakomen van de overeenkomst kan financiële gevolgen hebben voor de serviceprovider.
Gemiddelde tijd om te herstellen (MTTR)	De tijd die nodig is om een onderdeel te herstellen nadat een fout is gedetecteerd.
Gemiddelde tijd tussen fouten (MBTF)	De duur waarvoor de workload de verwachte functie zonder onderbreking kan uitvoeren, totdat deze mislukt.
Beoogde hersteltijd (RTO)	De maximaal acceptabele tijd dat een toepassing niet beschikbaar kan zijn na een incident.
Recovery Point Objective (RPO)	De maximaal aanvaardbare duur van gegevensverlies tijdens een incident.

Definieer de doelwaarden van de workload voor deze metrische gegevens in de context van gebruikersstromen en systeemstromen. Identificeer en score deze stromen op basis van hoe essentieel ze zijn voor uw vereisten. Gebruik de waarden om het ontwerp van uw workload te stimuleren in termen van architectuur, beoordeling, testen en incidentbeheerbewerkingen. Als u de doelen niet haalt, heeft dit invloed op het bedrijf dat verder gaat dan het tolerantieniveau.

Belangrijke ontwerpstrategieën

Technische discussies moeten niet bepalen hoe u betrouwbaarheidsdoelen voor uw kritieke stromen definieert. In plaats daarvan moeten zakelijke belanghebbenden zich richten op klanten bij het definiëren van de vereisten van een workload. Technische experts helpen de belanghebbenden realistische numerieke waarden toe te wijzen die overeenkomen met deze vereisten. Terwijl ze kennis delen, maken technische experts onderhandelingen en wederzijdse consensus over realistische SLO's mogelijk.

Bekijk een voorbeeld van het toewijzen van vereisten aan meetbare numerieke waarden. Belanghebbenden schatten dat voor een kritieke gebruikersstroom een uur downtime tijdens normale kantooruren resulteert in een verlies van X dollar aan maandelijkse omzet. Dit bedrag wordt vergeleken met de geschatte kosten voor het ontwerpen van een stroom met een beschikbaarheids-SLO van 99,95 procent in plaats van 99,9 procent. Besluitvormers moeten bespreken of het risico van dat omzetverlies opweegt tegen de extra kosten en beheerlast die nodig zijn om zich ertegen te beschermen. Volg dit patroon bij het onderzoeken van stromen en het samenstellen van een volledige lijst met doelen.

Houd er rekening mee dat betrouwbaarheidsdoelen verschillen van prestatiedoelen. Betrouwbaarheidsdoelen zijn gericht op beschikbaarheid en herstel. Als u betrouwbaarheidsdoelen wilt instellen, definieert u eerst de breedste vereisten en definieert u vervolgens meer specifieke metrische gegevens om te voldoen aan de vereisten op hoog niveau.

Vereisten voor betrouwbaarheid en herstel op het hoogste niveau en gecorreleerde metrische gegevens kunnen bijvoorbeeld een beschikbaarheid van toepassingen van 99,9 procent voor alle regio's of een beoogde RTO van 5 uur voor de regio Noord- en Zuid-Amerika omvatten. Door deze typen doelen te definiëren, kunt u bepalen welke kritieke stromen betrokken zijn bij deze doelen. Vervolgens kunt u doelen op onderdeelniveau overwegen.

Afweging: er kan een conceptuele kloof bestaan tussen de technische beperkingen van de onderdelen van uw workload en wat dat betekent voor het bedrijf, bijvoorbeeld doorvoer in megabits per seconde versus transacties per seconde. Het maken van een model tussen deze twee weergaven kan lastig zijn. In plaats van de oplossing te overbouwen, probeert u deze op een economische, maar zinvolle manier te benaderen.

Metrische gegevens over beschikbaarheid

SLA's en SLA's

Metrische gegevens over beschikbaarheid zijn gerelateerd aan SLO's, die u gebruikt om SLA's te definiëren. De SLO van de workload bepaalt hoeveel downtime in een bepaalde periode acceptabel is, bijvoorbeeld minder dan 1 uur per maand. Bekijk de Microsoft-SLA's voor elk onderdeel om ervoor te zorgen dat u aan het SLO-doel voldoet. Let op hoeveel redundantie u nodig hebt om te voldoen aan hoge SLA's. Microsoft garandeert bijvoorbeeld hogere SLA's voor implementaties in meerdere regio's van Azure Cosmos DB dan voor implementaties met één regio.

Notitie

Azure SLA's hebben niet altijd betrekking op alle aspecten van een service. Azure Application Gateway heeft bijvoorbeeld een SLA voor beschikbaarheid, maar de azure Web Application Firewall-functionaliteit biedt geen garantie dat schadelijk verkeer niet wordt doorgegeven. Houd rekening met deze beperking wanneer u uw SLA's en SLO's ontwikkelt.

Nadat u de SLA's voor de afzonderlijke workloadonderdelen hebt verzameld, berekent u een samengestelde SLA. De samengestelde SLA moet overeenkomen met de doel-SLO van de workload. Het berekenen van een samengestelde SLA omvat verschillende factoren, afhankelijk van uw architectuurontwerp. Bekijk de volgende voorbeelden.

Notitie

De SLA-waarden in de volgende voorbeelden zijn hypothetisch en zijn alleen bedoeld voor demonstratiedoeleinden. Ze zijn niet bedoeld om de huidige waarden weer te geven die door Microsoft worden ondersteund.

Samengestelde SLA's hebben betrekking op meerdere services die ondersteuning bieden voor een toepassing, met verschillende beschikbaarheidsniveaus. Denk bijvoorbeeld aan een Azure App Service web-app die naar Azure SQL Database schrijft. Hypothetisch kunnen deze SLA's er als volgt uit zien:

• App Service web-apps = 99,95 procent
• SQL Database = 99,99 procent

Wat is de maximale downtime die u kunt verwachten voor deze toepassing? Als beide services uitvallen, valt de hele toepassing uit. De kans dat elke service mislukt, is onafhankelijk, dus de samengestelde SLA voor deze toepassing is 99,95 procent × 99,99 procent = 99,94 procent. Deze waarde is lager dan de afzonderlijke SLA's. Deze conclusie is niet verwonderlijk, omdat een toepassing die afhankelijk is van meerdere services meer potentiële foutpunten heeft.

U kunt de samengestelde SLA verbeteren door onafhankelijke terugvalpaden te maken. Als SQL Database bijvoorbeeld niet beschikbaar is, plaatst u transacties in een wachtrij die later moet worden verwerkt:

In dit ontwerp is de toepassing nog steeds beschikbaar, zelfs als deze geen verbinding kan maken met de database. Het mislukt echter als de database en de wachtrij tegelijkertijd mislukken. Het verwachte percentage tijd voor een gelijktijdige fout is 0,0001 × 0,001, dus hier is de samengestelde SLA voor dit gecombineerde pad:

Database of wachtrij = 1,0 − (0,0001 × 0,001) = 99,99999 procent

De totale samengestelde SLA:

Web-app en (database of wachtrij) = 99,95 procent × 99,99999 procent = ~99,95 procent

Deze benadering levert compromissen op:

• De toepassingslogica is complexer.
• U betaalt voor de wachtrij.
• U moet rekening houden met problemen met gegevensconsistentie.

Voor implementaties met meerdere regio's wordt de samengestelde SLA als volgt berekend:

• N is de samengestelde SLA voor de toepassing die in één regio is geïmplementeerd.

• R is het aantal regio's waarin de toepassing wordt geïmplementeerd.

De verwachte kans dat de toepassing in alle regio's tegelijk mislukt, is ((1 − N) ^ R). Als de hypothetische SLA voor één regio bijvoorbeeld 99,95 procent is:

• De gecombineerde SLA voor twee regio's = (1 − (1 − 0,9995) ^ 2) = 99,999975 procent

• De gecombineerde SLA voor vier regio's = (1 − (1 − 0,9995) ^ 4) = 99,999999 procent

Het definiëren van de juiste SLO's kost tijd en zorgvuldige overweging. Zakelijke belanghebbenden moeten begrijpen hoe belangrijke klanten de app gebruiken. Ze moeten ook de betrouwbaarheidstolerantie begrijpen. Deze feedback moet de doelen informeren.

SLA-waarden

In de volgende tabel worden algemene SLA-waarden gedefinieerd.

SLA	Downtime per week	Downtime per maand	Downtime per jaar
99%	1,68 uur	7,2 uur	3,65 dagen
99,9%	10,1 minuten	43,2 minuten	8,76 uur
99,95%	5 minuten	21,6 minuten	4,38 uur
99,99%	1,01 minuten	4,32 minuten	52,56 minuten
99,999%	6 seconden	25,9 seconden	5,26 minuten

Wanneer u denkt aan samengestelde SLA's in de context van stromen, moet u er rekening mee houden dat verschillende stromen verschillende kritieke definities hebben. Houd rekening met deze verschillen wanneer u uw samengestelde SLA's bouwt. Niet-kritieke stromen bevatten mogelijk onderdelen die u uit uw berekeningen moet weglaten, omdat ze geen invloed hebben op de klantervaring als ze kort niet beschikbaar zijn.

Notitie

Klantgerichte workloads en workloads voor intern gebruik hebben verschillende SLO's. Normaal gesproken kunnen workloads voor intern gebruik veel minder beperkende beschikbaarheids-SLO's hebben dan klantgerichte workloads.

SLA's

U kunt SLA's beschouwen als metrische gegevens op onderdeelniveau die bijdragen aan een SLO. De belangrijkste SLI's zijn de SLI's die van invloed zijn op uw kritieke stromen vanuit het perspectief van uw klanten. Voor veel stromen omvatten SLO's latentie, doorvoer, foutfrequentie en beschikbaarheid. Een goede SLI helpt u te identificeren wanneer een SLO het risico loopt te worden geschonden. Correleert de SLI waar mogelijk met specifieke klanten.

Om te voorkomen dat u nutteloze metrische gegevens verzamelt, beperk u het aantal SLI's voor elke stroom. Streef indien mogelijk naar drie SLI's per stroom.

Metrische herstelgegevens

Hersteldoelen komen overeen met RTO-, RPO-, MTTR- en MBTF-metrische gegevens. In tegenstelling tot beschikbaarheidsdoelen zijn hersteldoelen voor deze metingen niet sterk afhankelijk van Microsoft-SLA's. Microsoft publiceert RTO- en RPO-garanties alleen voor bepaalde producten, zoals SQL Database.

Definities voor realistische hersteldoelen zijn afhankelijk van uw foutmodusanalyse en uw plannen en testen voor bedrijfscontinuïteit en herstel na noodgevallen. Voordat u dit werk voltooit, moet u ambitieuze doelen bespreken met belanghebbenden en ervoor zorgen dat uw architectuurontwerp de hersteldoelen naar beste inzicht ondersteunt. Communiceer duidelijk aan belanghebbenden dat stromen of volledige workloads die niet grondig zijn getest op metrische herstelgegevens, geen gegarandeerde SLA's mogen hebben. Zorg ervoor dat belanghebbenden begrijpen dat hersteldoelen na verloop van tijd kunnen veranderen als workloads worden bijgewerkt. De workload kan complexer worden naarmate klanten worden toegevoegd of wanneer u nieuwe technologieën gebruikt om de klantervaring te verbeteren. Deze wijzigingen kunnen uw metrische herstelgegevens verhogen of verlagen.

Notitie

MTBF kan lastig zijn om te definiëren en te garanderen. Platform as a Service (PaaS) of SaaS (Software as a Service) kan mislukken en herstellen zonder enige melding van de cloudprovider, en het proces kan volledig transparant zijn voor u of uw klanten. Als u doelen voor deze metrische waarde definieert, behandelt u alleen onderdelen die onder uw beheer vallen.

Wanneer u hersteldoelen definieert, definieert u drempelwaarden voor het initiëren van een herstel. Als een webknooppunt bijvoorbeeld langer dan 5 minuten niet beschikbaar is, wordt automatisch een nieuw knooppunt toegevoegd aan de pool. Definieer drempelwaarden voor alle onderdelen, rekening houdend met wat herstel voor een specifiek onderdeel inhoudt, inclusief het effect op andere onderdelen en afhankelijkheden. Uw drempelwaarden moeten ook rekening houden met tijdelijke fouten om ervoor te zorgen dat u niet te snel herstelacties start. Documenteer en deel met de belanghebbenden de mogelijke risico's van herstelbewerkingen, zoals gegevensverlies of sessieonderbrekingen voor klanten.

Een statusmodel bouwen

Gebruik de gegevens die u hebt verzameld voor uw betrouwbaarheidsdoelen om uw statusmodel te bouwen voor elke workload en de bijbehorende kritieke stromen. Een statusmodel definieert de status in orde, gedegradeerd en beschadigd voor de stromen en workloads. De statussen zorgen voor de juiste operationele prioriteitstelling. Dit model wordt ook wel een verkeerslichtmodel genoemd. Het model wijst groen toe voor gezond, geel voor verslechterd en rood voor beschadigd. Een statusmodel zorgt ervoor dat u weet wanneer de status van een stroom verandert van goed in gedegradeerd of beschadigd.

Hoe u de status in orde, gedegradeerd en beschadigd definieert, is afhankelijk van uw betrouwbaarheidsdoelen. Hier volgen enkele voorbeelden van manieren waarop u de statussen kunt definiëren:

• Een groene of gezonde status geeft aan dat aan belangrijke niet-functionele vereisten en doelen volledig wordt voldaan en dat resources optimaal worden gebruikt. Zo wordt 95 procent van de aanvragen verwerkt in <=500 ms met Azure Kubernetes Service (AKS)-knooppuntgebruik op X procent.

• Een gele of gedegradeerde status geeft aan dat een of meer onderdelen van de stroom waarschuwingen geven tegen de gedefinieerde drempelwaarde, maar dat de stroom operationeel is. Er is bijvoorbeeld opslagbeperking gedetecteerd.

• Een rode of beschadigde status geeft aan dat degradatie langer dan is toegestaan door uw betrouwbaarheidsdoelen of dat de stroom niet meer beschikbaar is.

Notitie

Het statusmodel moet niet alle fouten op dezelfde basis behandelen. Het statusmodel moet onderscheid maken tussen tijdelijke en niet-tijdelijke fouten. Er moet duidelijk onderscheid worden gemaakt tussen verwachte tijdelijke maar herstelbare fouten en een echte noodtoestand.

Dit model werkt met behulp van een bewakings- en waarschuwingsstrategie die is ontwikkeld en uitgevoerd op basis van de principes van continue verbetering. Naarmate uw workloads zich ontwikkelen, moeten uw statusmodellen mee evolueren.

Voor gedetailleerde ontwerpoverwegingen en aanbevelingen voor een gelaagd toepassingsstatusmodel raadpleegt u de richtlijnen voor statusmodellering in de ontwerpgebieden voor bedrijfskritieke werkbelastingen. Zie de handleiding voor statusbewaking voor gedetailleerde richtlijnen over configuraties voor bewaking en waarschuwingen.

Visualisatie

Als u uw operationele teams en belanghebbenden van workloads op de hoogte wilt houden van de realtime status en algemene trends van het workloadstatusmodel, kunt u dashboards maken in uw bewakingsoplossing . Bespreek visualisatieoplossingen met de belanghebbenden om ervoor te zorgen dat u de informatie levert die zij waarderen en die gemakkelijk te gebruiken is. Mogelijk willen ze ook wekelijks, maandelijks of per kwartaal gegenereerde rapporten zien.

Azure-facilitering

Azure SLA's bieden de Microsoft-toezeggingen voor uptime en connectiviteit. Verschillende services hebben verschillende SLA's en soms hebben SKU's binnen een service verschillende SLA's. Zie Serviceovereenkomsten voor onlineservices voor meer informatie.

De Azure SLA bevat procedures voor het verkrijgen van een servicetegoed als niet aan de SLA wordt voldaan, samen met definities van beschikbaarheid voor elke service. Dit aspect van de SLA fungeert als een afdwingingsbeleid.

Verwante koppelingen

• essentiële richtlijnen voor Well-Architected Framework voor statusmodellering: statusmodellering en waarneembaarheid van bedrijfskritieke workloads in Azure

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid