Aanbevelingen voor het definiëren van betrouwbaarheidsdoelen
Van toepassing op deze aanbeveling voor de Well-Architected Reliability-checklist: Power Platform
| 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 scheppen en acties te ondernemen om de ideale situatie te bereiken. Gebruik de gedefinieerde doelen om het gezondheidsmodel te bouwen. Het gezondheidsmodel definieert hoe gezonde, gedegradeerde en ongezonde toestanden eruit zien. |
|---|
In deze guide worden de aanbevelingen beschreven voor het definiëren van doelstatistieken voor beschikbaarheid en herstel van kritieke workloads. Betrouwbaarheidsdoelen worden afgeleid via workshopactiviteiten met zakelijke belanghebbenden.
Door middel van bewaking en testen worden de doelen verbeterd. Werk samen met uw interne belanghebbenden om realistische verwachtingen voor de betrouwbaarheid vast te stellen. Deze activiteit zal ook helpen om draagvlak voor architecturale ontwerpkeuzes te creëren onder belanghebbenden en te zorgen dat zij inzien dat uw ontwerp bedoeld is om de overeengekomen doelen zo goed mogelijk te bereiken.
Microsoft Power Platform pakt de meeste problemen met beschikbaarheid en betrouwbaarheid op niveau van de infrastructuur aan voor u. De beschikbaarheid van de workloads die u bouwt, is echter een gedeelde verantwoordelijkheid. Het is belangrijk om te begrijpen dat, zelfs met Microsoft's toewijding aan hoge beschikbaarheid, het risico op systeemuitval nooit nul is.
Overweeg de volgende metrische gegevens te gebruiken om de bedrijfsvereisten te kwantificeren.
| Term | Definitie |
|---|---|
| Dienstverleningsdoelstelling (SLO) | Een percentagedoel dat staat voor de status van het onderdeel en de betrouwbaarheidslaag. Hoe hoger de laag, des te betrouwbaarder het onderdeel. Samengestelde SLO vertegenwoordigt het totale doel van de volledige werklast en houdt rekening met de component-SLO's. |
| Serviceniveau-indicator (SLI) | Een meetwaarde die wordt uitgezonden door een service. SLI-meetwaarden worden samengevoegd om een SLO-waarde te kwantificeren. |
| Dienstverleningsovereenkomst (SLA) | Een contractuele overeenkomst tussen de dienstverlener en de klant die de dienst afneemt. In de overeenkomst worden de SLO's gedefinieerd. Het niet nakomen van de overeenkomst kan financiële gevolgen hebben voor de dienstverlener. |
| Gemiddelde hersteltijd (MTTR) | De tijd die nodig is om een onderdeel te herstellen nadat een fout is gedetecteerd. |
| Gemiddelde tijd tussen fouten (MTBF) | De duur gedurende welke de workload de verwachte functie zonder onderbreking kan uitvoeren, totdat er een fout optreedt. |
| Hersteltijddoelstelling (RTO) | De maximaal aanvaardbare duur dat een toepassing na een incident niet beschikbaar mag zijn. |
| Herstelpuntdoelstelling (RPO) | De maximaal aanvaardbare duur van gegevensverlies tijdens een incident. |
Definieer de doelwaarden van de workload voor deze metrische gegevens in de context van gebruikers- en systeemstromen. Identificeer en beoordeel deze stromen op basis van hoe belangrijk ze zijn voor uw vereisten. Gebruik de waarden om het ontwerp van uw workload te sturen op het gebied van architectuur, beoordeling, testen en incidentbeheer. Als de doelstellingen niet worden gehaald, heeft dit gevolgen voor het bedrijf die verder gaan dan het tolerantieniveau.
Belangrijke ontwerpstrategieën
Technische discussies mogen niet bepalend zijn voor de manier waarop u betrouwbaarheidsdoelstellingen voor uw kritieke stromen definieert. In plaats daarvan moeten zakelijke belanghebbenden zich concentreren op hun vereisten en de verwachtingen van de eindgebruikers van de workload. Technische experts helpen de belanghebbenden realistische numerieke waarden aan die vereisten te koppelen. Door informatie uit te wisselen maken technische experts het mogelijk om haalbare SLO's te bespreken en overeen te komen.
Bekijk een voorbeeld van hoe u vereisten kunt toewijzen aan meetbare numerieke waarden. Belanghebbenden schatten dat voor een kritieke gebruikersstroom een uur aan downtime tijdens reguliere kantooruren resulteert in een verlies van X euro aan maandelijkse inkomsten. Dat bedrag in euro's 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. Beslissers moeten bespreken of het risico van dat inkomstenverlies opweegt tegen de extra kosten en de beheerlast die nodig is om zich ertegen te beschermen.
Volg dit patroon terwijl u stromen onderzoekt en een volledige lijst met doelen samenstelt.
Houd er rekening mee dat betrouwbaarheidsdoelstellingen niet hetzelfde zijn als prestatiedoelstellingen. Betrouwbaarheidsdoelstellingen zijn gericht op beschikbaarheid en herstel. Om betrouwbaarheidsdoelstellingen in te stellen, begint u met het definiëren van de breedste vereisten en definieert u vervolgens meer specifieke metrische gegevens om aan de vereisten op hoog niveau te voldoen.
Vereisten op het hoogste niveau voor betrouwbaarheid en herstel en gecorreleerde metrische gegevens kunnen bijvoorbeeld een toepassingsbeschikbaarheid van 99,9 procent voor alle regio's of een beoogde RTO van 5 uur voor de regio Amerika omvatten. Door dit soort doelen te definiëren, kunt u bepalen welke kritieke stromen bij deze doelen betrokken zijn. Vervolgens kunt u doelstellingen op onderdeelniveau overwegen.
Metrische gegevens voor beschikbaarheid
Beschikbaarheidsdoelen komen overeen met metrische gegevens voor SLO, SLA en SLI.
SLO's en SLA's
Metrische gegevens over beschikbaarheid correleren met SLO's, die u gebruikt om SLA's te definiëren. De workload-SLO bepaalt hoeveel downtime in een bepaalde periode aanvaardbaar is; bijvoorbeeld minder dan 1 uur per maand. Om er zeker van te zijn dat u de SLO-doelstelling kunt halen, controleert u de SLA's voor elk onderdeel. Microsoft
Denk bij het vaststellen van uw SLO’s na over het volgende:
Niet-functionele vereisten van uw workload (bijvoorbeeld piekaanvraagpercentages, gelijktijdige gebruikers) voor de komende 1-2 jaar.
Beschikbare metrische gegevens voor wat u kunt meten, gedurende een specifieke periode. Deze gegevens geven aan welke SLI's moeten worden opgegeven.
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. Bij het berekenen van een samengestelde SLA zijn verschillende factoren betrokken, afhankelijk van uw architectuurontwerp.
Het definiëren van de juiste SLO's kost tijd en vraagt om zorgvuldige afweging. Zakelijke belanghebbenden moeten de betrouwbaarheidstolerantie begrijpen. Deze feedback moet als grondslag voor de doelstellingen dienen.
SLA-waarden
In de onderstaande tabel worden veel voorkomende SLA-waarden beschreven.
| SLA (Service Level Agreement) | 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 gebruikers- en systeemstromen, bedenk dan dat verschillende gebruikers- en systeemstromen verschillende definities van kritikaliteit hebben. Houd rekening met deze verschillen wanneer u uw samengestelde SLA's opbouwt. Niet-kritieke stromen kunnen onderdelen bevatten die u uit uw berekeningen moet weglaten, omdat ze geen invloed hebben op de klantervaring als ze kortstondig niet beschikbaar zijn.
SLI's
Beschouw SLI's als metrische gegevens op onderdeelniveau die bijdragen aan een SLO. De belangrijkste SLI's zijn de SLI's die uw kritieke stromen beïnvloeden vanuit het perspectief van uw klanten. Voor veel stromen omvatten SLI's latentie, doorvoer, foutpercentage en beschikbaarheid. Met een goede SLI kunt u bepalen wanneer het risico bestaat dat een SLO wordt geschonden. Correleer de SLI indien mogelijk met specifieke klanten.
Om te voorkomen dat er nutteloze metrische gegevens worden verzameld, beperkt u het aantal SLI's voor elke stroom. Streef indien mogelijk naar drie SLI's per stroom.
Metrische gegevens voor herstel
Hersteldoelen komen overeen met metrische gegevens voor RTO, RPO, MTTR en MTBF. In tegenstelling tot beschikbaarheidsdoelen zijn hersteldoelen voor deze metingen niet sterk afhankelijk van SLA's. Microsoft Microsoft publiceert RTO- en RPO-garanties alleen voor bepaalde producten, zoals SQL Database.
Definities voor realistische hersteldoelen zijn afhankelijk van uw analyse van foutmodus en uw plannen en tests voor zakelijke continuïteit en herstel na noodgeval. Bespreek voordat u deze werkzaamheden afrondt ambitieuze doelstellingen met belanghebbenden en zorg ervoor dat uw architectuurontwerp de hersteldoelstellingen naar uw beste inzicht ondersteunt. Communiceer duidelijk aan belanghebbenden dat delen van de workload die niet grondig zijn getest op metrische gegevens voor herstel geen gegarandeerde SLA's mogen hebben. Zorg ervoor dat belanghebbenden begrijpen dat hersteldoelen in de loop der tijd kunnen veranderen naarmate workloads worden bijgewerkt. De workload kan complexer worden naarmate u nieuwe technologieën gebruikt om de gebruikerservaring te verbeteren. Door deze wijzigingen kunnen uw metrische gegevens voor herstel worden verhoogd of verlaagd.
Opmerking
Het kan uitdagend zijn om de MTBF te definiëren en te garanderen. Platforms as a service (PaaS) of software as a service (SaaS) kunnen uitvallen en herstellen zonder enige melding van de cloudprovider, en het proces kan voor u volledig transparant zijn. Als u doelen voor deze meetwaarde definieert, neem dan alleen de onderdelen mee die u zelf beheert.
Een gezondheidsmodel maken
Gebruik de gegevens die u hebt verzameld voor uw betrouwbaarheidsdoelen om uw gezondheidsmodel op te bouwen voor elke workload en bijbehorende kritieke stromen. Een gezondheidsmodel definieert de status in orde, verslechterd en beschadigd* voor de stromen en workloads. De statussen zorgen voor passende operationele prioriteiten. Dit model wordt ook wel een verkeerslichtmodel genoemd. Het model kent groen toe aan in orde, geel aan verslechterd en rood aan beschadigd. Een gezondheidsmodel zorgt ervoor dat u weet wanneer de status van een stroom verandert van in orde naar verslechterd of beschadigd.
Hoe u de status in orde, verslechterd en beschadigd definieert, hangt af van uw betrouwbaarheidsdoelen. Hier volgen enkele voorbeelden van manieren waarop u de statussen kunt definiëren:
De status groen of in orde geeft aan dat aan belangrijke niet-functionele vereisten en doelstellingen volledig wordt voldaan en dat resources optimaal worden gebruikt.
De status geel of verslechterd geeft aan dat een of meer onderdelen van de stroom waarschuwen afgeven voor de gedefinieerde drempelwaarde, maar dat de stroom operationeel is. Er is bijvoorbeeld aanvraagbeperking voor opslag gedetecteerd.
De status rood of beschadigd geeft aan dat de verslechtering langer heeft geduurd dan is toegestaan binnen uw betrouwbaarheidsdoelen of dat de stroom niet meer beschikbaar is.
Opmerking
Het gezondheidsmodel zou niet alle fouten op dezelfde manier moeten behandelen. Het gezondheidsmodel moet onderscheid maken tussen tijdelijke en niet-tijdelijke storingen. Er moet duidelijk onderscheid worden gemaakt tussen verwachte tijdelijke maar herstelbare fouten en een echte noodgevalstatus.
Dit model werkt met behulp van een bewakings- en waarschuwingsstrategie die is ontwikkeld en wordt toegepast op basis van de principes van continue verbetering. Naarmate uw workloads evolueren, moeten uw gezondheidsmodellen mee evolueren.
Voor gedetailleerde richtlijnen over configuratie voor bewaking en waarschuwingen raadpleegt u de guide voor statusbewaking.
Visualisatie
Als u uw operationele teams en belanghebbenden van de workload op de hoogte wilt houden van de realtime status en algemene trends van het statusmodel van de workload, kunt u overwegen om dashboards te maken in uw bewakingsoplossing. Bespreek visualisatieoplossingen met de belanghebbenden om ervoor te zorgen dat u de informatie levert die zij belangrijk vinden en die gemakkelijk te gebruiken is. Mogelijk willen ze ook wekelijks, maandelijks of driemaandelijks gegenereerde rapporten zien.
Power Platform-facilitering
Power Platform SLA's bieden de Microsoft garantie voor uptime en connectiviteit. Verschillende services hebben verschillende SLA's, en soms hebben SKU's binnen een service verschillende SLA's. Zie Dienstverleningsovereenkomsten voor onlineservices.
De SLA voor Power Platform omvat procedures voor het verkrijgen van een servicetegoed als niet aan de SLA wordt voldaan, samen met definities van de beschikbaarheid voor elke service. Dat aspect van de SLA fungeert als handhavingsbeleid.
Microsoft Business Applications biedt Business Continuity and Disaster Recovery (BCDR)-mogelijkheden voor alle productieomgevingen in Dynamics 365 en Power Platform SaaS-toepassingen. Ontdek hoe u ervoor zorgt dat uw productiegegevens veerkrachtig blijven tijdens regionale uitval. Microsoft
Organisatorische afstemming
Cloud Adoption Framework biedt richtlijnen voor aanbevelingen voor SLO's en SLI's met betrekking tot bewaking in de hele organisatie.
Zie SLO's voor cloudbewaking voor meer informatie.
Controlelijst voor betrouwbaarheid
Raadpleeg de volledige reeks aanbevelingen.