SLA en SLO
In deze les worden serviceovereenkomsten (SLA's) en serviceniveaudoelstellingen (SLO's) besproken.
Service Level Agreement (SLA)
Omdat SaaS niet alleen software is, maar voornamelijk een service is, is één verschil tussen SaaS en traditionele softwareproducten SLA. De SLA is een overeenkomst tussen een SaaS-provider en een client die de toezeggingen van de provider voor uptime en connectiviteit beschrijft. Als de SaaS-provider de serviceniveaus voor elke service niet bereikt en onderhoudt zoals beschreven in de SLA, kunnen klanten in aanmerking komen voor compensatie.
SLA-compensatie en boetes voor softwareproviders zijn afhankelijk van de branche en het type bedrijf. De twee meest voorkomende scenario's zijn financiële boetes en servicetegoeden. Voor servicetegoeden komen klanten mogelijk in aanmerking voor een tegoed voor hun maandelijkse servicekosten.
Hoewel u 100% uptime voor uw service kunt definiëren, is het moeilijk om 100% beschikbaarheid voor complexe systemen te bereiken. De meeste SLA's zijn gekoppeld aan de beschikbaarheid die ze kunnen bieden.
Een SLA die 100% uptime aangeeft, garandeert mogelijk geen beschikbaarheid van 100%. De uptime van 100% kan betekenen dat als er storingen zijn, klanten compensatie krijgen volgens de overeenkomst. Het bouwen van systemen met hoge beschikbaarheid is een technische taak, terwijl sla een manier is om een bedrijf wettelijk te beschermen tegen storingen.
Zie Service Level Agreements (SLA) voor onlineservices voor voorbeelden van Microsoft SLA's.
Serviceniveaudoelstellingen (SLO's)
SLO's zijn meetbare doelen die zijn vastgesteld op belangrijke klantgerichte serviceniveauindicatoren (SLO's). SLO's meten de ervaring van uw klant van een bedrijfs- of infrastructuurworkload.
SLO's bepalen of de SaaS-provider voldoet aan de toezeggingen die zijn gedaan in een formeel overeengekomen SLA. SLO's en SLO's moeten vroeg worden gedefinieerd in het ontwerp van een cloudworkload voor bedrijven of infrastructuur.
De focus voor service-eigenaren is om het volgende te bepalen:
- Welke scenario's kritieke indicatoren van de servicestatus zijn vanuit het perspectief van de klant.
- Hoe u SLA's verzamelt zodat ze zo dicht mogelijk bij de klantervaring liggen.
- Wat de SLO's moeten zijn voor de SLO's.
Er zijn twee soorten SLO's in de software-industrie:
Servicegerichte SLO's zijn tactische doelen die teams definiëren om de kwaliteit van hun service in de loop van de tijd geleidelijk te verbeteren.
Deze SLO's zijn pragmatische doelen die haalbaar zijn in een technische mijlpaal. Als een service momenteel bijvoorbeeld een beschikbaarheid van 99,7% bereikt, kan het team een doel instellen om in het volgende kwartaal een beschikbaarheid van 99,9% te bereiken.
Klantgerichte SLO's definiëren de ideale toekomstige staat of doelstelling waarbuiten verdere investeringen in kwaliteit onnodig zijn, omdat aan de verwachtingen van de klanten volledig wordt voldaan.
SLO's zijn belangrijk in de ontwikkeling en bewerkingen van cloudworkloads en dienen verschillende doeleinden in vergelijking met SLA's. Een SLO geeft de status en richting van technische teams aan, terwijl sla een contract is met klanten over de voorwaarden voor geleverde services en compensatie.
In Azure is serviceniveaubeheer lichtgewicht, omdat Microsoft de interfaces, functionaliteit en metrische gegevens vooraf definieert. Consumenten moeten hun verwachtingen voor servicelevering beheren wanneer ze cloudworkloads gebruiken.
Contoso-scenario
Een eenvoudige SLA-overeenkomst tussen Contoso en hun gebruikers definieert eerst de gegarandeerde serviceniveaus en SLA's, zoals:
- Gebruikers kunnen toegang krijgen tot en zich aanmelden bij het systeem, ontwerpen genereren en andere beschikbare functionaliteit in het systeem gebruiken.
- Contoso biedt 99,99% beschikbaarheid voor hun services die betrekking hebben op de voorgaande scenario's.
- Aanvragen in de afgelopen vijf minuten worden in minder dan 1000 milliseconden verwerkt bij 99%.
De SLO's zijn aggregaties van tijdreeksgegevens. Hoe de SLO's worden verzameld, is belangrijk. Als de klant met de service communiceert met behulp van een API, zijn het meten van systeemlatentie en de tijd voor het verwerken van aanvragen nauwkeurige SLA's. Maar als de klant met de service communiceert via een webportal, moet de totale tijd die nodig is om de aanvraag te verwerken ook de JavaScript-prestaties van de webpagina bevatten.
De SLA moet ook downtime definiëren en de compensatie voor klanten die te maken hebben met downtime. Er kan bijvoorbeeld een compensatiestructuur zijn van het uptimepercentage dat is gecorreleerd met het percentage maandelijkse tegoeden dat is ontvangen, of een systeem van platte compensatie voor elke minuut downtime.
Met betrekking tot SLO's kan Contoso beginnen met het definiëren van:
- Quality of Service (QoS): het AI-model moet binnen 3 minuten na een gebruikersaanvraag nieuwe ontwerpideeën genereren.
- Beschikbaarheid: 99,99% gedurende een maandelijkse periode.
- Capaciteit: doelpercentagegebruik voor CPU, opslag, geheugen, latentie, doorvoer en schalen.
- Productacceptatie: het acceptatiepercentage van voorgestelde ontwerpideeën moet hoger zijn dan 20%.