Aanbevelingen voor het definiëren van betrouwbaarheidsdoelen

Is van toepassing op deze aanbeveling voor de controlelijst voor betrouwbaarheid 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 verkrijgen, verwachtingen in te stellen en acties uit te voeren om de ideale status te bereiken. Gebruik de gedefinieerde doelen om het statusmodel te bouwen. In het statusmodel wordt gedefinieerd hoe gezonde, gedegradeerde en beschadigde statussen eruitzien.

In deze handleiding worden de aanbevelingen beschreven voor het definiëren van metrische gegevens voor beschikbaarheids- en hersteldoelgegevens voor kritieke workloads en stromen. Betrouwbaarheidsdoelen worden afgeleid via 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 kunnen doorgeven aan klanten via contractuele overeenkomsten. 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 overeengekomen.

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

Term	Definitie
Service level objective (SLO)	Een meting van de prestaties en betrouwbaarheid van een workload of toepassing. Een SLO is een specifiek, meetbaar doel dat is ingesteld voor bepaalde klantinteracties. Het is een doel dat u instelt voor uw workload op toepassing op basis van de kwaliteit van de service die uw gebruikers verwachten te ontvangen.
Indicator op serviceniveau (SLI)	Een metrische waarde die wordt verzonden door een service. SLI-metrische gegevens worden geaggregeerd om een SLO-waarde te kwantificeren.
Service Level Agreement (SLA)	Een contractuele overeenkomst tussen de serviceprovider en de serviceklant. Het niet voldoen aan 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 storing (MBTF)	De duur waarvoor de workload de verwachte functie zonder onderbreking kan uitvoeren, totdat deze mislukt.
Beoogde hersteltijd (RTO)	De maximaal acceptabele tijd die een toepassing na een incident niet beschikbaar kan zijn.
Recovery Point Objective (RPO)	De maximale acceptabele 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 kritiek ze zijn voor uw vereisten. Gebruik de waarden om het ontwerp van uw workload te stimuleren in termen van architectuur- en beoordelings-, test- en incidentbeheerbewerkingen. Het niet voldoen aan de doelen heeft invloed op het bedrijf buiten het tolerantieniveau.

Belangrijke ontwerpstrategieën

Technische discussies moeten niet bepalen hoe u betrouwbaarheidsdoelen definieert voor uw kritieke stromen. In plaats daarvan moeten zakelijke belanghebbenden zich richten op klanten wanneer ze de vereisten van een workload definiëren. Technische experts helpen de belanghebbenden realistische numerieke waarden toe te wijzen die correleren 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 in maandelijkse omzet. Dat dollarbedrag 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 inkomstenverlies opweegt tegen de extra kosten en beheerlast die nodig zijn om deze te beschermen. Volg dit patroon wanneer u stromen bekijkt en een volledige lijst met doelen maakt.

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

Betrouwbaarheids- en herstelvereisten op het hoogste niveau en gecorreleerde metrische gegevens kunnen bijvoorbeeld een toepassingsbeschikbaarheid van 99,9 procent bevatten voor alle regio's of een beoogde RTO van 5 uur voor de regio Amerika. Als u deze typen doelen definieert, kunt u bepalen welke kritieke stromen betrokken zijn bij deze doelen. Vervolgens kunt u doelen op onderdeelniveau overwegen.

Compromis: 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 overengineeren, probeert u deze op een economische maar zinvolle manier te benaderen.

Metrische gegevens over beschikbaarheid

SLA's en SLA's

Een SLO is een meting van de prestaties en betrouwbaarheid van een workload of toepassing. Een SLO is een specifiek, meetbaar doel dat is ingesteld voor bepaalde klantinteracties. Het is een doel dat u hebt ingesteld voor uw workload of toepassing voor de kwaliteit van de service die uw gebruikers verwachten te ontvangen.

Een SLO kan worden gedefinieerd in termen van verschillende metrische gegevens, zoals beschikbaarheid, reactietijd, doorvoer, slagingspercentage en andere. Een SLO voor een webservice kan bijvoorbeeld zijn dat deze beschikbaar is voor gebruikers van 99,9% van de tijd in een bepaalde maand, of dat deze binnen 500 milliseconden reageert op 95% van de aanvragen.

Voordat u de SLA's voor uw toepassing of workload definieert, controleert u de gepubliceerde SLA's van Microsoft voor de onderliggende services waarop uw toepassing of workload wordt gehost.

Notitie

De Sla's van de Microsoft-service zijn geen platform-SLA's of SLO's

Let bij het controleren van de SLA voor elke service op hoeveel redundantie u nodig hebt om te voldoen aan hoge SLA's. Microsoft garandeert bijvoorbeeld hogere SLA's voor implementaties met 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-toepassing Gateway heeft bijvoorbeeld een SLA voor beschikbaarheid, maar de Azure Web Application Firewall-functionaliteit biedt geen garantie om te voorkomen dat schadelijk verkeer wordt doorgegeven. Houd rekening met deze beperking wanneer u uw SLA's en SLA'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 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 het volgende zijn:

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

Wat is de maximale downtime die u voor deze toepassing kunt verwachten? 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 verrassend omdat een toepassing die afhankelijk is van meerdere services meer potentiële storingspunten 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 tijdspercentage voor een gelijktijdige fout is 0,0001 × 0,001. Dit is dus 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 aanpak vormt een compromis:

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

Voor implementaties in 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 nadenkt over 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 kunnen onderdelen bevatten 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. Interne workloads kunnen doorgaans 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 SLO's zijn de slo's die van invloed zijn op uw kritieke stromen vanuit het perspectief van uw klanten. Voor veel stromen omvatten SLO's latentie, doorvoer, foutsnelheid en beschikbaarheid. Een goede SLI helpt u te identificeren wanneer een SLO het risico loopt te worden geschonden. Correleren van de SLI aan specifieke klanten, indien mogelijk.

Als u het verzamelen van nutteloze metrische gegevens wilt voorkomen, beperkt u het aantal SLO's voor elke stroom. Streven naar drie SLO's per stroom, indien mogelijk.

Metrische herstelgegevens

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

Definities voor realistische hersteldoelen zijn afhankelijk van uw analyse van de foutmodus en uw plannen en testen voor bedrijfscontinuïteit en herstel na noodgevallen. Voordat u dit werk voltooit, bespreekt u aspiratiedoelen met belanghebbenden en zorgt u ervoor dat uw architectuurontwerp de hersteldoelen ondersteunt voor het beste inzicht. Communiceer duidelijk met belanghebbenden dat stromen of volledige workloads die niet grondig zijn getest voor metrische herstelgegevens geen gegarandeerde SLA's hebben. Zorg ervoor dat belanghebbenden begrijpen dat hersteldoelen na verloop van tijd kunnen veranderen wanneer workloads worden bijgewerkt. De workload kan complexer worden naarmate klanten worden toegevoegd of als u nieuwe technologieën gebruikt om de klantervaring te verbeteren. Deze wijzigingen kunnen uw metrische herstelgegevens vergroten of verkleinen.

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, beslaat u alleen onderdelen die onder uw beheer vallen.

Wanneer u hersteldoelen definieert, definieert u drempelwaarden voor het initiëren van een herstelbewerking. 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 het herstel voor een specifiek onderdeel, 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 potentiële 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 bijbehorende kritieke stromen. Een statusmodel definieert statussen 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 gedegradeerd en rood voor beschadigd. Een statusmodel zorgt ervoor dat u weet wanneer de status van een stroom verandert van in orde in verslechterd of beschadigd.

Hoe u gezonde, gedegradeerde en beschadigde statussen 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 AKS-knooppunten (Azure Kubernetes Service) met X procent.

• Een gele of gedegradeerde status geeft aan dat een of meer onderdelen van de stroom waarschuwen 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 is dan toegestaan door uw betrouwbaarheidsdoelen of dat de stroom niet meer beschikbaar is.

Notitie

In het statusmodel mogen niet alle fouten hetzelfde worden behandeld. Het statusmodel moet onderscheid maken tussen tijdelijke en niet-tijdelijke fouten. Het moet duidelijk onderscheid maken tussen verwachte tijdelijke maar herstelbare fouten en een echte noodtoestand.

Dit model werkt met behulp van een bewakings- en waarschuwingsstrategie die is ontwikkeld en beheerd op basis van de principes van continue verbetering. Naarmate uw workloads zich ontwikkelen, moeten uw gezondheidsmodellen zich met deze modellen ontwikkelen.

Voor gedetailleerde ontwerpoverwegingen en aanbevelingen voor een gelaagd toepassingsstatusmodel raadpleegt u de richtlijnen voor statusmodellering in de essentiële ontwerpgebieden voor workloads. Zie de handleiding voor statuscontrole voor gedetailleerde richtlijnen over bewakings- en waarschuwingsconfiguraties.

Visualisatie

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

Azure-facilitering

Azure SLA's bieden de Toezeggingen van Microsoft 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

• Goed ontworpen Framework bedrijfskritieke richtlijnen voor statusmodellering: Statusmodellering en waarneembaarheid van bedrijfskritieke workloads in Azure

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid