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. U moet betrouwbaarheidsdoelen afleiden uit workshopoefeningen met zakelijke belanghebbenden. Verfijn deze doelen vervolgens door uw workloads te bewaken en te testen.
Stel realistische verwachtingen in met uw interne belanghebbenden over betrouwbaarheid van workloads. Vervolgens kunnen ze contractuele overeenkomsten gebruiken om deze verwachtingen aan klanten te communiceren. Realistische verwachtingen helpen belanghebbenden ook om uw beslissingen over het architectuurontwerp te begrijpen en te ondersteunen en te weten dat u ontwerpt om optimaal te voldoen aan de doelen waarover u het eens bent.
Overweeg het gebruik van de volgende metrische gegevens om uw 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 u hebt ingesteld voor bepaalde interacties van klanten. Het is een doel dat u instelt voor uw workload of toepassing op basis van de kwaliteit van de service die uw klanten verwachten te ontvangen. |
| Indicator op serviceniveau (SLI) | Een kwantitatieve meting van een bepaald aspect van de prestaties van een service. U kunt een SLI gebruiken om de naleving van uw workload met een SLO te meten. |
| 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. |
Belangrijke ontwerpstrategieën
Betrouwbaarheidsdoelen vertegenwoordigen het gewenste kwaliteitsdoel van een workload, zoals beloofd aan de gebruikers en de belanghebbenden van het bedrijf. Dit doel omvat zowel beschikbaarheid als herstelbaarheid van de workload. Houd er rekening mee dat betrouwbaarheidsdoelen verschillen van prestatiedoelen, maar u moet prestatiedoelen opnemen in betrouwbaarheidsdoelen. Houd rekening met de volgende betrouwbaarheidsdoelen:
Beschikbaarheidsdoelen definiëren de kwaliteitsnormen voor een systeem om toegankelijk en functioneel te blijven. Als het niet aan deze standaarden voldoet, wordt het systeem als onbetrouwbaar beschouwd. Gebruik SLO's om te controleren of uw systeem voldoet aan deze standaarden. Zakelijke en technische belanghebbenden werken samen om realistische SLO's in te stellen en rekening te houden met factoren zoals vergelijkende analyse, gebruikerservaring en het workloadprofiel.
De juistheidsdoelen zorgen ervoor dat de werkbelasting de functies correct uitvoert met consistente kwaliteit. Als u de juistheid wilt meten, kwantificeert u de indicatoren van de workload zodat u deze kunt combineren tot een uniforme objectieve score.
Hersteldoelen komen overeen met de metrische gegevens RTO, RPO, MTTR en MBTF, die de effectiviteit van uw plannen kwantificeren en testen voor bedrijfscontinuïteit en herstel na noodgevallen.
Om betrouwbaarheidsdoelen in te stellen, definiëren zakelijke belanghebbenden brede vereisten. Vervolgens beoordelen technische experts de huidige status van de workload en werken ze aan het bereiken en onderhouden van doelen door middel van bewaking en waarschuwingen. Beide partijen moeten het eens zijn over realistische doelstellingen.
Gebruikers- en systeemstromen identificeren en beoordelen op basis van hun belang voor uw bedrijfsvereisten. Gebruik deze scores om het ontwerp, de beoordeling, het testen en het incidentbeheer van uw workload te begeleiden. Stel betrouwbaarheidsdoelen voor deze stromen in en begrijp dat het niet voldoen aan deze doelen uw bedrijf aanzienlijk kan beïnvloeden.
Compromis: Mogelijk hebt u een kloof tussen de technische limieten van uw systeem en de bedrijfsimpact, zoals doorvoer versus transacties per seconde. Het overbruggen van deze kloof kan lastig zijn. Streven naar een praktische en rendabele oplossing in plaats van overengineering.
Beschikbaarheidsdoelstellingen instellen
De algehele SLO van een workload weerspiegelt de holistische kwaliteit, inclusief alle afhankelijkheden. Een volwassen verklaring van de SLO moet het algemene bedrijfsdoel voor die workload aangeven, niet alleen een samengestelde van deze afhankelijkheden. Als klanten bijvoorbeeld 99,99% beschikbaarheid verwachten, moet de algehele SLO naar dat doel streven, zelfs als één onderdeel slechts 99,80% bereikt.
Belanghebbenden evalueren de klantervaring en kijken na hoe downtime van invloed is op de omzet. Ze vergelijken dit verlies met de kosten voor het ontwerpen en uitvoeren van de bedrijfsstroom. Besluitvormers dan of ze meer geld moeten uitgeven aan betrouwbaarheid om inkomstenverlies te voorkomen en hun reputatie te behouden.
Eigenaren van werkbelastingen gebruiken financiële doelstellingen om doelstellingen te bepalen. Bedrijfsvereisten zijn toegewezen aan meetbare metrische gegevens. Het doel is om een set factoren te identificeren die van invloed zijn op de kwaliteit van de klantervaring.
Workloadarchitecten nemen veel technische beslissingen op basis van SLO's. SLO's kunnen:
Fungeren als essentiële invoer in architectuurbeslissingen wanneer u andere afhankelijkheden beschouwt.
Geef een bijna realtime weergave en gedeeld inzicht in de status van een workload om objectieve discussies mogelijk te maken. Ze helpen het workloadteam ook prioriteit te geven aan inspanningen om de betrouwbaarheid te verbeteren en nieuwe functies te ontwikkelen.
Fungeren als een primair signaal voor implementatiebewerkingen, waardoor geautomatiseerd terugdraaien wordt aangetroffen als er problemen optreden en wordt gevalideerd dat de wijzigingen de verwachte verbeteringen in de klantervaring bereiken.
Versnellen van herstel en herstel door zich te richten op doelstellingen, geautomatiseerde melding van problemen aan klanten te stimuleren en vertrouwen tussen teams in uw organisatie te bouwen.
Belangrijk
U moet weten wat het verschil is tussen SLA's en SLO's. Hoewel SLA's en SLO's vergelijkbare gegevens kunnen gebruiken of zelfs presenteren, is hun intentie anders. Een SLA is een formeel contract tussen een organisatie en haar klanten, en heeft directe financiële en juridische implicaties als de organisatie niet aan zijn belofte voldoet. Organisaties gebruiken SLO's om te evalueren of de potentiële downtime binnen de toelaatbare limieten valt.
SLO's en SLA's delen een zakelijke relatie en moeten onafhankelijk worden beheerd. Als de SLA fungeert als een zakelijke tactiek, kan de organisatie deze opzettelijk instellen op een hoge waarde op basis van de doelstellingen van de bedrijfseigenaar. Omgekeerd kunnen SLO's hoger zijn. Bekijk bedrijfskritieke workloads als voorbeeld. Deze workloadklasse kan zich geen lange downtime veroorloven, omdat de effecten, waaronder financieel verlies en zelfs bedreigingen voor menselijke veiligheid, aanzienlijk zijn. Daarom richten SLO's zich doorgaans op een uptime van 99,999%, meestal aangeduid als de vijf negens. Als SLO's niet voldoen aan deze doelen, moeten organisaties snel reageren om fouten te beperken en de resultaten van een mislukte SLA te voorkomen.
In het voorbeeld in dit artikel wordt een hoge SLA ingesteld ter ondersteuning van bedrijfsdoelen.
Cloudplatform- en technologieproviders publiceren SLA's op hun aanbiedingen. U moet de SLA's overwegen als onderdeel van de SLO-berekening, maar u moet ze niet gebruiken zoals is zonder inzicht te krijgen in het bereik van de SLA van de dekking. Zie De impact van Microsoft SLA's beoordelen voor meer informatie.
Overweeg veelvoorkomende SLO's en beïnvloedingsfactoren
Elke SLO is gericht op een specifieke kwaliteitscriteria. Houd rekening met deze algemene SLO's voor betrouwbaarheid. Deze lijst is niet volledig. Voeg SLO's toe op basis van uw zakelijke vereisten.
Succespercentage meet het succes van aanvragen en processen ten opzichte van aanvragen en processen die een fout retourneren of hun taak mislukken.
Latentie meet de tijd tussen het moment waarop een aanvraag voor een bewerking wordt gestart en wanneer het resultaat beschikbaar is of het proces is voltooid.
Capaciteit meet gelijktijdig gebruik, zoals het aantal reacties op basis van beperking.
Beschikbaarheid meet de uptime vanuit het perspectief van klanten.
Doorvoer meet de minimale gegevensoverdrachtsnelheid gedurende een bepaalde tijd. Doorvoer wordt gemeten als een gegevenssnelheidseenheid, zoals transacties per seconde (TPS) of aanvragen per seconde (RPS).
Inzicht in de scenario's en toleranties voor uw workload in Azure. Zowel Azure-services als toepassingsonderdelen zijn van invloed op de SLO van de workload. Combineer antwoorden uit de volgende tabel om de algehele SLO af te leiden. Gebruik deze vragen als voorbeelden om het hulpprogramma van het workloadonderdeel te evalueren.
| Onderdeelkenmerken | Klantinteractie | Andere factoren |
|---|---|---|
| - Worden aanvraag- of antwoord-API's beschikbaar gesteld? - Heeft het query-API's? - Is het een rekenonderdeel ? - Is het een taakverwerkingsonderdeel ? |
- Toegang tot besturingsvlak en beheervlak voor openbare Azure-services. - Gegevensvlaktoegang, bijvoorbeeld cruD-bewerkingen (read, update en delete). |
- Houdt uw releaseproces downtime in? - Wat is de kans op het introduceren van bugs? Als de workload wordt geïntegreerd met andere systemen, moet u mogelijk integratiefouten overwegen. - Hoe beïnvloeden routinebewerkingen zoals patching het beschikbaarheidsdoel? Hebt u rekening houden met partnerafhankelijkheden? - Is uw personeel voldoende om constante rotatie van nood- en noodback-ups te ondersteunen? - Heeft de toepassing lawaaierige buren buiten uw controlebereik die mogelijk verstoringen kunnen veroorzaken? |
Het SLO-bereik bepalen
U kunt SLO's instellen op verschillende niveaus, zoals voor elke toepassing, workload of een specifieke stroom in uw systeem. Stel niveauspecifieke SLO's in, zodat u SLO's kunt aanpassen op basis van het belang van elk onderdeel.
Meet IN SaaS-oplossingen (Software as a Service) SLO's per klant om de ervaring van elke klant te optimaliseren. Klanten kunnen verschillende infrastructuurbronnen in hun segmenten hebben. In dergelijke gevallen is een systeembrede SLO die alle resources in klantsegmenten samenvoegt, mogelijk niet zinvol. Meet in plaats daarvan SLO's die overeenkomen met de specifieke context van elke klant. Zie Tenancy-modellen voor een multitenant-oplossing voor meer informatie.
Samengestelde SLO-doelen definiëren
SLO's moeten meetbaar en gemeten worden binnen een venster waarneembaarheid.
SLO's zijn vaak percentages zoals 99,90%, maar kunnen ook instructies zijn. Gebruik beide methoden om een numerieke waarde op te halen die alle factoren bevat.
Een SLO bestaat uit meetbare SLO's die acceptabele factoren definiëren. SLO's zijn metrische gegevens met een ingestelde drempelwaarde die kan worden gewaarschuwd. U kunt ze verzamelen van een platform of een toepassing. Verschillende onderdelen verzenden relevante SLA's. Wanneer u SLO's kiest, moet u rekening houden met factoren die van invloed zijn op de SLO.
Als u bijvoorbeeld de SLO wilt berekenen voor een stroom die gebruikmaakt van een antwoord- en aanvraag-API, meet u de latentie van de server en de verwerkingstijd van de aanvraag. Doorvoer- en foutsnelheden zijn niet van toepassing op continue rekenomgevingen, zoals virtuele machines (VM's), schaalsets of Azure Batch.
Voor toegang tot het besturingsvlak kunt u foutenpercentages en latentie overwegen voor API-antwoorden en langlopende bewerkingen, zoals het maken van resources. Toegang tot het gegevensvlak is afhankelijk van de GEBRUIKTE API's, elk met hun eigen SLO-doelen.
Een goede SLI laat zien wanneer u een SLO kunt schenden. Het wordt meestal gemeten in percentielen. Hier volgen enkele veelgebruikte percentielen en de geschatte tijd van niet-naleving voor de verwachte beschikbaarheid.
| Doelstelling | Niet-naleving per week | Niet-naleving per maand | Niet-naleving per jaar |
|---|---|---|---|
| 99% | 1,68 uur | 7,20 uur | 3,65 dagen |
| 99.90% | 10,10 minuten | 43,20 minuten | 8,76 uur |
| 99,95% | 5 minuten | 21,60 minuten | 4,38 uur |
| 99,99% | 1,01 minuten | 4,32 minuten | 52,56 minuten |
| 99,999% | 6 seconden | 25,90 seconden | 5,26 minuten |
Belangrijk
Een samengestelde SLO-waarde is een productdistributie van de bijdragende factoren.
Een voorbeeld van een samengestelde SLO is 99,95% × 99,99999% = ~99,95%.
Wanneer u samengestelde SLO's voor verschillende stromen maakt, moet u rekening houden met de verschillende kritieke en relevantie. Stromen kunnen onderdelen bevatten die u als niet-kritiek beschouwt en weglaat uit uw berekeningen. U kunt hun weglating rechtvaardigen op basis van of hun korte onbeschikbaarheid van invloed is op de ervaring van de klant. In sommige gevallen is een onderdeel mogelijk niet relevant voor de use case die u voor de SLO overweegt. U kunt deze onderdelen ook weglaten uit de berekening.
Hetzelfde principe is van toepassing op bewerkingen. Bepaalde bewerkingen kunnen risico's veroorzaken of van invloed zijn op de SLO, en andere zijn onbelangrijk. Het besluit moet expliciet en gebaseerd zijn op consensus.
Zie de sectie Voorbeeld voor een illustratief voorbeeld van het definiëren en meten van SLO's en SLO's.
De impact van Microsoft SLA's beoordelen
Een Microsoft SLA biedt inzicht in de beschikbaarheid van gebieden waarnaar Microsoft doorvoert. SLA's garanderen geen aanbieding als geheel. Wanneer u SLA's evalueert, hebt u een goed beeld van de dekking die rond het gepubliceerde percentiel wordt verstrekt.
Overweeg Web Apps, een functie van Azure-app Service. De functie wordt als beschikbaar beschouwd wanneer deze een status van 200 OK retourneert in een bepaalde use-case. Binnen die specifieke context en tijdsbestek heeft het geen betrekking op een financiële garantie op de beschikbaarheid van functies zoals Easy Auth of sleufwisseling. U moet rekening houden met gebieden die niet expliciet in de overeenkomst worden vermeld als beschikbaar door de best effort van het platform.
Dus als uw workload afhankelijk is van implementatiesites, kunt u uw SLO niet alleen afleiden uit de Sla voor App Service. Als workloadteam moet u de beschikbaarheid van de uptime afdekken en voorspellen. Deze voorspelling kan echter onzeker zijn. Daarom kan het koppelen van uw SLO aan de SLA van het platform problematisch zijn.
Bekijk een ander voorbeeld. Als Azure Front Door een beschikbaarheid van 99,99% heeft, moet uw ontwerp voldoen aan specifieke criteria die in de overeenkomst zijn gepubliceerd. Uw back-end moet bijvoorbeeld opslag bevatten, u hebt een GET bewerking nodig waarmee een bestand van ten minste 50 kB in grootte kan worden opgehaald en moet u agents implementeren op meerdere locaties op ten minste vijf geografisch diverse locaties. Deze smalle use case van Azure Front Door garandeert geen functies zoals caching, routeringsregels of een firewall voor webtoepassingen. Deze aspecten vallen buiten het bereik van de SLA.
Doelen voor meerdere regio's implementeren
Vanuit het oogpunt van betrouwbaarheid is de implementatie van meerdere regio's een implementatie van het principe van redundantie. Het doel is om het risico van een regionale storing of verminderde prestaties te beperken. Deze strategie kan, wanneer deze goed is ontworpen, SLO's verbeteren omdat er een secundaire regio wordt toegevoegd voor failoverdoeleinden.
Er zijn twee belangrijke use cases:
Patroon voor hoge beschikbaarheid, waarin u een belasting over regio's distribueert voor meer capaciteit. Hoge beschikbaarheid beperkt workloadgebruikers niet tot een regio en de prestaties van het hele systeem dragen bij aan de SLO.
Schotpatroon, waarin u klanten beperkt tot specifieke regio's om ze te segmenteren. In dergelijke gevallen behandelt u implementaties met meerdere regio's als afzonderlijke implementaties of stempels in elke regio. Meet de status van elke stempel afzonderlijk, met de SLO's die geschikt zijn voor uw workload. Houd rekening met de SLO van uw algehele workload op basis van de status van elke zegel. Als u een failover tussen stempels kunt uitvoeren, is de slo van uw totale workload hoger omdat een fout in de ene stempel kan worden hersteld via een failover naar een andere stempel.
Let op hoeveel redundantie u nodig hebt om te voldoen aan hoge SLO's. Microsoft garandeert bijvoorbeeld hogere SLA's voor implementaties met meerdere regio's van Azure Cosmos DB dan voor implementaties met één regio.
Metrische herstelgegevens definiëren
Definities voor realistische hersteldoelen, zoals RTO, RPO, MTTR en MBTF-metrische gegevens, zijn afhankelijk van uw analyse van de foutmodus en uw plannen en testen voor bedrijfscontinuïteit en herstel na noodgevallen. Wanneer u deze doelen definieert, moet u rekening houden met de door het platform geleverde herstelgaranties. Microsoft publiceert RTO en RPO-garanties alleen voor sommige producten, zoals Azure SQL Database.
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 wanneer u klanten toevoegt of wanneer 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. PaaS-modellen (Platform as a Service) of SaaS-modellen kunnen 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 vijf minuten niet beschikbaar is, voegt u automatisch een nieuw knooppunt toe aan de pool. Definieer drempelwaarden voor alle onderdelen en overweeg wat het 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 potentiële risico's, zoals gegevensverlies of sessieonderbrekingen voor klanten, van herstelbewerkingen.
De doelen bewaken en visualiseren
Gebruik de gegevens die u verzamelt voor uw betrouwbaarheidsdoelen om uw statusmodel te bouwen voor elke workload en de bijbehorende kritieke stromen. Een statusmodel definieert statussen in orde, gedegradeerd en beschadigd voor de stromen en workloads. Wanneer de status verandert, moet het model de verantwoordelijke partijen waarschuwen. Zie richtlijnen voor statusmodellering voor gedetailleerde ontwerpoverwegingen en aanbevelingen.
Als u uw operationele teams en belanghebbenden van workloads op de hoogte wilt houden, maakt u een visualisatie die de realtime status en de algemene trends van het statusmodel van de workload weerspiegelt. Bespreekt visualisatieoplossingen met de belanghebbenden om ervoor te zorgen dat u 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 producten binnen een service verschillende SLA's. Zie SLA's voor onlineservices voor meer informatie.
De Azure SLA bevat procedures voor het verkrijgen van een servicetegoed als uw workload niet voldoet aan de SLA, samen met definities van beschikbaarheid voor elke service. Dit aspect van de SLA fungeert als een afdwingingsbeleid.
Verken de Azure Monitor-dashboards voor uw visualisatiesysteem.
Opmerking
Contoso, Ltd. ontwerpt een nieuwe mobiele ervaring voor hun gebeurtenisticketsysteem. Dit is de architectuur op hoog niveau.
Het Grafana-logo is een handelsmerk van zijn respectieve bedrijf. Er wordt geen goedkeuring geïmpliceerd door het gebruik van dit merk.
Onderdelen
Hier volgen enkele onderdelen die het concept van slo-definitie illustreren. Deze architectuur bevat onderdelen die niet zijn opgenomen in de volgende lijst. Hoewel Key Vault bijvoorbeeld deel uitmaakt van de kritieke aanvraagstroom, maakt deze geen deel uit van de use-case van het antwoord. Als Key Vault niet beschikbaar is, blijft de toepassing functioneren met behulp van geheimen die tijdens het opstarten worden geladen. Als de toepassing echter moet worden geschaald, wordt de beschikbaarheid van Key Vault essentieel omdat er nieuwe knooppunten moeten worden geladen met geheimen. In dit voorbeeld worden schaalbewerkingen niet overwogen. Andere onderdelen worden weggelaten voor beknoptheid.
Azure Front Door is het single point of entry waarmee een API wordt weergegeven die klanten gebruiken om aanvragen te verzenden.
Azure Container Apps is de omgeving die het workloadteam bezit en gebruikt om bedrijfslogica voor de toepassing uit te voeren.
SQL Managed Instance is eigendom van en wordt beheerd door een ander team en is een kritieke afhankelijkheid van de workload.
Azure Private Link biedt privéconnectiviteit tussen Implementaties van Azure Front Door en Container Apps. SQL Managed Instance wordt ook beschikbaar gesteld aan de toepassing via een privé-eindpunt.
In deze architectuur definieert het API-team een eerste SLO-doel voor kritieke stromen in de toepassing. Ze nemen de strategie aan die wordt beschreven in Factoren die invloed hebben op SLO's. Ze streven ernaar doelstellingen te definiëren die betrekking hebben op de kernfunctionaliteit zonder extra functies te benadrukken. Ze meten de status van drie kritieke gebruikersstromen, die betrekking hebben op alle kernfunctionaliteiten van de cloud en code uitvoeren in implementaties. Deze stromen hebben echter geen betrekking op alle code- of gegevenstoegang. Hier volgen de beïnvloedingsfactoren.
Een samengestelde SLO berekenen
SLO voor azure-beschikbaarheid: de SLA voor financiële toezegging voor Azure fungeert als proxy om de betrouwbaarheid van het platform te beoordelen.
Azure-onderdeel Toepasselijke SLA-dekking Niet gedekt door SLA Aangepaste SLO Azure Front Door 99,99% voor geslaagde HTTP-bewerkingen GETCaching, regelengine 99.98% Container Apps 99,95% op basis van geïmplementeerde apps die bereikbaar zijn via het ingebouwde inkomend verkeer Mogelijkheden voor automatisch schalen, tokenarchief 99,95% SQL Managed Instance 99,99% op basis van de verbinding met het SQL Server-exemplaar Prestaties, gegevensretentie 99.80% Private Link 99,99% op basis van hele minuten wanneer het privé-eindpuntnetwerk geen verkeer heeft geaccepteerd of wanneer verkeer niet tussen het eindpunt en de Private Link-service is gegaan Individuele storingen duren minder dan één minuut 99,99% De aanpassing is gebaseerd op verschillende factoren die afhankelijk zijn van de belofte van het workloadteam aan hun doelstellingen. Een factor kan vertrouwen zijn in de mogelijkheden van het platform op basis van eerdere ervaring. Voor Container Apps en Private Link voelt het team zich bijvoorbeeld comfortabel bij het nemen van de SLA-waarde.
Er zijn ook genuanceerde factoren. Het team verlaagt bijvoorbeeld de SLO-waarde voor SQL Managed Instance tot 99,80% om rekening te houden met mogelijke fouten in hun gegevensbewerkingen, zoals schemawijzigingen en het maken van back-ups.
Het team stelt de samengestelde SLO in door de impact van afzonderlijke, aangepaste SLO-waarden te berekenen. Deze waarde is 99,72%.
Er zijn andere factoren die bijdragen. De architectuur is afhankelijk van Azure-netwerkonderdelen, zoals virtuele netwerken en netwerkbeveiligingsgroepen (NSG's) die geen gepubliceerde SLA hebben. Het workloadteam besluit deze factoren te overwegen met een beschikbaarheid van 99,99% voor elk onderdeel.
Een samengestelde SLO op basis van de voorspelde platformbeschikbaarheid: 99,68% per maand.
Slo voor toepassingscode: het team erkent dat fouten in hun toepassingscode of opgeslagen procedures van invloed kunnen zijn op de beschikbaarheid van het systeem en dat ze één uur maandelijkse downtime toewijzen om rekening te houden met codegerelateerde fouten.
Ze gebruiken veelvoorkomende percentielen voor downtime om de SLO te schatten voor afzonderlijke factoren, zoals codefouten, problemen met schalen en andere overwegingen met betrekking tot code.
Een samengestelde SLO op basis van de beschikbaarheid van code en gegevens: 99,86% per maand.
SLO voor resource- en toepassingsconfiguratie: het team herkent dat cloudresources en toepassingscode correct moeten worden geconfigureerd. Dit doel omvat het instellen van regels voor automatisch schalen, het implementeren van NSG-regels en het selecteren van de juiste grootte van SKU's. Om rekening te houden met configuratiefouten, budgetteren ze 10 minuten maandelijkse downtime, wat ongeveer 99,98% beschikbaarheid is.
Een samengestelde SLO op basis van de beschikbaarheid van de configuratie: 99,95% per maand.
Operations SLO: Het workloadteam ontwikkelt een goede DevOps-cultuur door de goed ontworpen frameworkprincipes voor Operational Excellence te volgen. Ze implementeren cloudresources, configuratie en code elke sprint.
Het team beschouwt implementaties als risico omdat ze een actief systeem kunnen stabiliseren. Er kunnen fouten optreden als gevolg van TLS-certificaatupdates, DNS-wijzigingen of hulpprogrammafouten. Het team beschouwt ook mogelijke downtime die wordt veroorzaakt door noodoplossingen. Ze budgetteren in totaal 20 minuten maandelijkse downtime, wat ongeveer 99,95% beschikbaarheid is.
Onderhoudsvensters worden aangewezen perioden waarin systeemonderhoud of updates plaatsvinden. De API wordt meestal gedurende ongeveer vier uur per dag ongebruikt. Om het risico op onbeschikbaarheid te verminderen, kan het team onderhoudstaken plannen tijdens die minder actieve uren. Deze benadering leidt tot een hogere SLO, maar het team besluit het onderhoudsvenster niet op te nemen als onderdeel van hun SLO.
Een samengestelde SLO op basis van de beschikbaarheid van bewerkingen: 99,95% per maand.
Slo voor externe afhankelijkheden: het team beschouwt SQL Managed Instance als de primaire afhankelijkheid, die al een beschikbaarheid van 99,80% heeft in de algehele platformbeschikbaarheid. Er worden geen andere externe afhankelijkheden overwogen.
Een samengestelde SLO op basis van externe afhankelijkheden: Niet van toepassing.
Het algehele samengestelde SLO-resultaat bepalen
Het algemene samengestelde SLO-doel is ingesteld op 99,45%, wat gelijk is aan ongeveer vier uur downtime per maand.
Om te voldoen aan het SLO-doel van slechts vier uur onbeschikbaarheid per maand, stelt het workloadteam een on-call rotatie in. Zowel klantondersteuning als synthetische transactiebewaking kan SRE-ondersteuning (Site Reliability Engineering) aanroepen om onmiddellijk herstelstappen te starten om SLO-problemen op te lossen.
De SLA voor workloads instellen
De SLA voor de workload is 99,90% beschikbaarheid per maand.
De juridische en financiële afdelingen van het workloadteam stellen de SLA voor de workload in op een beschikbaarheid van 99,90% per maand, die het SLO-doel van 99,45% overschrijdt. Ze nemen deze beslissing nadat ze financiële uitbetalingen versus verwachte klantgroei hebben geanalyseerd op basis van een aantrekkelijke SLA. De SLA omvat twee kerngebruikersstromen en omvat prestatieoverwegingen, niet alleen beschikbaarheid. Het is een berekend risico dat het bedrijfsteam neemt om te profiteren van het bedrijf en het technische team is op de hoogte van de toezegging.
De juistheids-SLO instellen
De kerngebruikersstromen van de toepassing moeten beschikbaar zijn en op een bepaalde manier, of zelfs concurrerend, responsief zijn. Het team stelt een reactietijd-SLO specifiek in voor de API, met uitzondering van clientverwerkingstijd en doorkruising van internetnetwerk. Ze evalueren deze SLO alleen tijdens perioden van beschikbaarheid. Ze kiezen het 75e percentiel als zowel het SLO-doel als de prestatiemeting, die de typische klantervaring vastlegt en scenario's met slechtste gevallen uitsluit.
Verwante koppelingen
Statusmodellering en waarneembaarheid van bedrijfskritieke workloads in Azure
Controlelijst voor betrouwbaarheid
Raadpleeg de volledige set aanbevelingen.