SLA vs. SLO vs. SLI: wat is het verschil?

Wat is een SLA?

Een SLA (Service Level Agreement) is een overeenkomst tussen de provider en de klant over meetbare statistieken zoals uptime, respons en verantwoordelijkheden.

Deze overeenkomsten worden doorgaans opgesteld door teams voor nieuwe en juridische zaken van een bedrijf en ze vertegenwoordigen de beloftes die je aan klanten doet en de gevolgen als je die beloften niet nakomt. Meestal omvatten de gevolgen financiële sancties, servicekredieten of licentieverlengingen.

De uitdagingen van SLA's

SLA's zijn berucht omdat ze vaak moeilijk te meten, te rapporteren en aan te voldoen zijn. Deze overeenkomsten, die meestal worden geschreven door mensen die zelf niet in de technische loopgraven zitten, bevatten vaak beloftes die moeilijk te meten zijn voor teams, ze sluiten niet altijd aan bij de huidige en steeds evoluerende bedrijfsprioriteiten en houden dan geen rekening met nuances.

Een SLA kan bijvoorbeeld beloven dat teams de gerapporteerde problemen met Product X binnen 24 uur zullen oplossen. Maar in diezelfde SLA staat niet vermeld wat er gebeurt als de klant er 24 uur over doet om antwoorden of screenshots te sturen om je team te helpen een diagnose te stellen van het probleem. Betekent dit dat de 24 uur per dag beschikbare tijd van het team is verspild door vertragingen bij klanten of start en stopt de klok op basis van wanneer klanten reageren? SLA's moeten deze antwoord geven op deze vragen, maar vaak slagen ze daar niet in. Dat heeft ervoor gezorgd dat veel IT-managers een afkeer tegen ze hebben.

Voor veel experts is het antwoord op deze uitdaging in de eerste plaats dat technologie betrokken moet worden bij het opstellen van SLA's. Hoe meer IT en DevOps samenwerken met juridische en bedrijfsontwikkelingsteams om SLA's te ontwikkelen die inspelen op scenario's uit de echte wereld, hoe meer SLA's de belangrijkste realiteiten weerspiegelen, zoals klanten die hun eigen probleemoplossing uitstellen.

Voor wie is een SLA?

Een SLA is een overeenkomst tussen een leverancier en een betalende klant. Bedrijven die gebruikers gratis service aanbieden, willen geen SLA of hebben die waarschijnlijk niet nodig voor deze gratis gebruikers.

Wat is een SLO?

Een SLO (Service Level Objective) is een overeenkomst binnen een SLA over een specifieke statistiek, zoals uptime. Dus als de SLA de formele overeenkomst is tussen jou en je klant, zijn SLO's de individuele beloftes die je aan die klant doet. SLO's bepalen de verwachtingen van klanten en vertellen de IT- en DevOps-teams welke doelen ze moeten bereiken en hoe ze hun prestaties moeten meten.

De uitdagingen van SLO's

SLO's worden meer gewaardeerd dan SLA's, maar ze kunnen net zoveel problemen veroorzaken als ze vaag, overgecompliceerd of zelfs onmogelijk te meten zijn. Om SLO's een succes te laten zijn en ervoor te zorgen dat je engineers hun haar niet uit het hoofd willen trekken, moeten ze eenvoudig en duidelijk zijn opgesteld. Alleen de belangrijkste statistieken zouden in aanmerking moeten komen voor de SLO-status. De doelstellingen moeten in duidelijke taal worden omschreven en, net als bij SLA's, moeten ze altijd rekening houden met zaken als vertragingen aan de kant van de klant.

Voor wie zijn SLO's?

Waar SLA's alleen relevant zijn in het geval van betalende klanten, kunnen SLO's nuttig zijn voor zowel betaalde als onbetaalde accounts, en voor interne en externe klanten.

Interne systemen, zoals CRM's, opslagplaatsen voor klantgegevens en intranet, kunnen net zo belangrijk zijn als extern gerichte systemen. Een SLO's gebruiken voor die interne systemen is niet alleen belangrijk om bedrijfsdoelen te bereiken, maar ook om interne teams in staat te stellen hun eigen klantgerichte doelen te bereiken.

Wat is een SLI?

Een SLI (Service Level Indicator) meet de naleving van een SLO (Service Level Objective). Dus als je SLA bijvoorbeeld aangeeft dat je systeem 99,95% van de tijd beschikbaar moet zijn, is je SLO waarschijnlijk 99,95% uptime en je SLI is de daadwerkelijke meting van je uptime. Misschien is dat 99,96%. Misschien 99,99%. Om aan je SLA te blijven voldoen, moet de SLI voldoen aan de beloften in dat document of deze overtreffen.

De uitdagingen van SLI's

Net als bij SLO's is het de uitdaging van SLI's om ze eenvoudig te houden, de juiste statistieken te kiezen om bij te houden en het werk van IT niet al te ingewikkeld te maken door te veel statistieken bij te houden die er eigenlijk niet toe doen voor klanten.

Een gedetailleerd disasterrecoveryplan opstellen

Wat doe je als de downtime toeslaat? Als je het antwoord op die vraag nog niet weet, is het standaardantwoord meestal 'kostbare tijd verspillen met uitzoeken wat je moet doen'.

Hoe beter je plan voor incidentrespons is, hoe sneller en effectiever je teams incidenten kunnen afhandelen. Daarom moet de eerste stap van elk nieuw programma voor incidentmanagement verwerking en planning zijn.

Voor wie zijn SLI's?

Elk bedrijf dat zijn prestaties meet aan de hand van SLO's heeft SLI's nodig om die metingen uit te voeren. Zonder SLI's kun je niet echt een SLO hebben.

SLA's opstellen op basis van de verwachtingen van klanten

Elk onderdeel van je klantovereenkomst moet gebaseerd zijn op wat de klant belangrijk vind. Aan het einde van de keten kan een incident wel 10 verschillende componenten beïnvloeden. Maar volgens de klant is het belangrijkste dat het systeem naar verwachting functioneert.

Je SLA's en SLO's moeten deze realiteit weerspiegelen. Maak het niet te ingewikkeld door alles tot in detail te bepalen en individuele beloftes te doen voor elk van die 10 componenten. Houd je beloftes beperkt tot de hoogwaardige, gebruikersgerichte functionaliteit. Dit zal klanten blijer maken, minder verwarrend werken en het leven van IT'ers vereenvoudigen die verantwoordelijk zijn voor het nakomen van je SLA-beloften.

Gebruik gewone taal in SLA's

Klanten vragen niet altijd om opheldering, dus als je SLA-taal te ingewikkeld is, sta je waarschijnlijk later voor een aantal pijnlijke misverstanden. Hoe eenvoudiger je taalgebruik, hoe kleiner de kans op een conflict met klanten in de toekomst.

Met een SLO is minder altijd meer

Niet elke statistiek is van belang voor het succes van klanten, daarom hoeft niet elke statistiek een SLO te zijn. Probeer zo min mogelijk SLO's op te stellen en je op die doelen te richten die er voor de klant toe doen.

Niet elke volgbare statistiek moet SLI zijn

Op dezelfde manier kan het heel snel lastig zijn om de prestaties van 10 componenten voor elk van de 10 SLO's te volgen. Kies in plaats daarvan strategisch welke statistieken echt belangrijk zijn voor je belangrijkste SLO's en steek je energie in het effectief volgen van die statistieken.

Voeg factoren toe die buiten de macht van IT liggen

Wat gebeurt er als de klant degene is die de tijd vertraagt om tot een oplossing te komen? Als je hier niet duidelijk over bent in je SLA, kan je team aan onmogelijke standaarden worden gehouden om problemen van klanten op te lossen zonder tussenkomst van de klant.

Houd ruimte voor een foutenbudget

Door ruimte te laten voor fouten wordt het bedrijf niet alleen beschermd tegen SLA-overtredingen en grote gevolgen, het biedt ook ruimte voor flexibiliteit. Zo kan het team snel veranderingen aanbrengen en heeft het de ruimte om innovatieve nieuwe oplossingen uit te proberen die mogelijk mislukken.

Google raadt in feite aan om het resterende foutenbudget te gebruiken voor geplande downtime, wat je kan helpen onvoorziene problemen te identificeren (bijv. diensten die servers op ongepaste wijze gebruiken) en voldoen aan de juiste verwachtingen van je klanten.

Beloof geen gouden bergen

Het feit dat je team waarschijnlijk 99,99% uptime kan behouden, wil nog niet zeggen dat er in SLO 99,99% moet staan. Het is altijd beter om te weinig te beloven en meer te leveren. Dit geldt in het bijzonder voor flexibele teams die vroeg en vaak willen releasen en een foutenbudget nodig hebben om dat snelle tempo bij te houden.

Welke invloed heeft dit op SRE's?

Voor diegenen die het Google-model volgen en Site Reliability Engineerding (SRE)-teams gebruiken, zijn SLA's, SLO's en SLI's cruciaal om de kloof tussen ontwikkeling en operations te overbruggen. SLA's helpen teams om grenzen en foutenbudgetten op te stellen. SLO's helpen bij het stellen van prioriteiten. En SLI's vertellen SRE's wanneer ze alle releases moeten stopzetten om een foutenbudget dat in het geding komt te redden en wanneer ze de teugels wat kunnen laten vieren.

Handel SLA's tijdig af om aanvragen op basis van prioriteiten op te oplossen en gebruik geautomatiseerde escalatieregels om de juiste teamleden op de hoogte te stellen en SLA-inbreuken te voorkomen met Jira Service Management.