Software speelt een steeds grotere rol in ons dagelijks leven. De reliability, oftewel betrouwbaarheid van deze software, is cruciaal voor een positieve gebruikerservaring. Een slechte gebruikerservaring heeft aanzienlijke gevolgen voor zowel klanten als bedrijven. Dit leidt vaak tot verminderde klanttevredenheid, en een toename van supportverzoeken. Slechte gebruikerservaringen kunnen wijzen op onderliggende problemen zoals trage responstijden, hoge foutpercentages of onbetrouwbare systeemprestaties. Deze problemen leiden tot hogere onderhoudskosten en resulteren uiteindelijk in omzetverlies.
Daarom is het essentieel dat de betrouwbaarheid en de positieve gebruikerservaring gewaarborgd worden. Vaak drukken we de waarborging van betrouwbaarheid uit met de volgende drie kernbegrippen: Service Level Agreements (SLA), Service Level Objectives (SLO) en Service Level Indicators (SLI).
Ondanks hun brede toepasbaarheid en voordelen, zoals verbeterde servicebetrouwbaarheid en klanttevredenheid, implementeren veel organisaties deze concepten nog niet (volledig). Echter, het benutten van SLA’s, SLO’s en SLI’s kan aanzienlijke voordelen opleveren voor elke organisatie.
In onderstaand blog leg ik uit waar de drie begrippen voor staan, en hoe we deze succesvol toepassen en rapporteren bij AkzoNobel.
Relatie tussen SLA, SLO en SLI
Deze elementen vormen het fundament van een betrouwbare service en zijn essentieel voor zowel AkzoNobel als de gebruikers van MIXIT, een online applicatie voor het zoeken naar formules voor coatings van voertuigen, boten en vliegtuigen.
Wat is een Service Level Agreement (SLA)?
Een SLA is een contract tussen een dienstverlener en een klant dat de te leveren service en de verwachte prestatieniveaus beschrijft. Het specificeert hoe je prestaties meet en goedkeurt, evenals de maatregelen bij niet-naleving van de prestatieniveaus.
Voorbeeld: Een cloudserviceprovider garandeert een uptime van 99,9% als onderdeel van hun SLA. Bij langdurige uitval kan de klant aanspraak maken op compensaties.
Wat is een Service Level Objective (SLO)?
Hoewel een SLA de algemene prestatiedoelen vastlegt, zijn er specifiekere, meetbare doelen nodig om deze prestatieniveaus effectief te beheren en te beoordelen. Hiervoor gebruiken we SLO’s. SLO’s bieden een gedetailleerder kader voor het definiëren van gewenste prestatieniveaus van een dienst, zoals responstijden, foutpercentages en doorvoer.
Voorbeeld: Een SLO kan vereisen dat het percentage succesvolle verzoeken dat een API verwerkt ten opzichte van het totaal aantal verzoeken, 98% is over een periode van 30 dagen. Het consistent missen van deze doelstelling kan resulteren in optimalisatie van de API of capaciteitsuitbreiding.
Wat is een Service Level Indicator (SLI)?
Een SLI is een meetbare waarde die de prestatie van een dienst in relatie tot de vastgestelde doelstelling (SLO) aangeeft. SLI’s bieden een nauwkeuriger inzicht in de prestaties van een dienst.
Voorbeeld: Een SLI kan het percentage succesvolle verzoeken zijn dat een API verwerkt ten opzichte van het totaal aantal verzoeken. Een daling onder een bepaalde drempel wijst op problemen die aangepakt moeten worden.
Implementatie SLO en SLI bij AkzoNobel voor MIXIT
AkzoNobel en Cloud Republic hebben nauw samengewerkt met Microsoft om de SLI’s en SLO’s te definiëren die aansluiten op de huidige SLA en de behoeften van de gebruikers van MIXIT. Hierbij is het de kunst om de juiste balans te vinden. SLO’s moeten voldoende ambitieus zijn om een hoogwaardige service en betrouwbaarheid te waarborgen, maar ook realistisch om onhaalbare verwachtingen (en te hoge kosten) te vermijden. Dit proces vereist een grondige analyse van historische prestatiedata, inzicht in klantbehoeften en een evaluatie van de systeemcapaciteiten.
Azure WorkBook – SLO Dashboard
De SLO-definities en onderliggende SLI’s zijn geconfigureerd in Azure Workbooks, geschreven in Kusto Query Language (KQL):
requests
| where cloud_RoleName in ("API naam")
| where resultCode != 0
| summarize totalCount = count(),
httpOkCount = countif(tostring(resultCode) in ({OkResponseCodes:value})),
httpNotOkCount = countif(tostring(resultCode) !in ({OkResponseCodes:value}))
by bin(timestamp, {TimeRange:grain})
| extend httpOkPercentage = round((httpOkCount / todouble(totalCount)) * 100, 2)
| extend httpNotOkPercentage = round((httpNotOkCount / todouble(totalCount)) * 100, 2)
| project httpNotOkPercentage, httpOkPercentage, timestamp
Bovenstaand codefragment illustreert een SLI voor het bepalen van het percentage succesvolle verzoeken dat een API verwerkt ten opzichte van het totaal aantal verzoeken. Variabelen bepalen welke response codes als ‘goed’ worden beschouwd en over welke tijdsduur de data wordt bekeken.
De bijbehorende SLO-definitie luidt:
“API naam – 98% of the HTTP requests returns well structured data* (response codes ‘200’,‘204’) over a period of 30 days.”
Het Azure WorkBook biedt de mogelijkheid om de resultaten grafisch weer te geven, wat de inzichtelijkheid vergroot:
SLO voorbeeld
Persistentie en sturing op SLI-data
Een Azure WorkBook toont vanwege de huidige retentie-instellingen in Azure alleen gegevens van de laatste dertig dagen. Door op vastgelegde momenten gegevens te exporteren naar Power BI, worden lange termijn analyses binnen de organisatie mogelijk gemaakt. Hierdoor zijn rapportages over langere periodes mogelijk.
De interactieve dashboards en visualisaties in Power BI maken het eenvoudiger om inzichten te delen met stakeholders op verschillende niveaus binnen de organisatie. Ook helpen ze bij het identificeren van trends en patronen. Hierdoor nemen we beter geïnformeerde beslissingen.
Power BI dashboard voorbeeld van een API correctness rapport
De retrospective meetings zijn een goed voorbeeld van momenten wanneer men behoefte heeft aan inzichten voor het maken van beter geïnformeerde beslissingen. Tijdens deze meetings raadplegen we de reliability-rapportages om te valideren of de recente aanpassingen hebben geresulteerd in de verwachte resultaten. Als een SLO niet behaald is, kan de uitkomst zijn dat er onderzoek- en optimalisatie-werkzaamheden worden geprioriteerd. Deze aanpak heeft de downtime van diverse API’s aanzienlijk verminderd en de gebruikerservaring verbeterd.
Volgende stap
De volgende stap is het configureren van alerting voor het niet behalen van een SLO. Het is essentieel om deze alerting zo in te stellen dat een API-uitrol geen onterechte alerts genereert. Hierdoor loopt de alerting enigszins achter op de realiteit, wat acceptabel is omdat we API’s tijdens een uitrol nauwlettend monitoren. Hierdoor kunnen we sneller en effectiever reageren op het niet behalen van een SLO dan momenteel het geval is.
Conclusie
Het waarborgen van de betrouwbaarheid van MIXIT is cruciaal voor AkzoNobel. Door duidelijke SLA’s, SLO’s en SLI’s te implementeren, monitoren en optimaliseren we de prestaties van de diensten consistent. De samenwerking van Cloud Republic en AkzoNobel met Microsoft heeft geleid tot effectieve configuraties in Azure Workbooks en duurzame data-opslag in PowerBI. Deze aanpak vermindert downtime en verbetert de gebruikerservaring. Met verbeterde alerting-systemen is AkzoNobel in staat sneller en effectiever te reageren op prestatiedalingen, wat de betrouwbaarheid en klanttevredenheid verder versterkt. Ondanks hun voordelen, zoals verbeterde servicebetrouwbaarheid, worden SLA’s, SLO’s en SLI’s nog niet volledig benut door veel organisaties. Volledige implementatie verbetert echter de operationele efficiëntie en concurrentiepositie.
Wil jij ook aan de slag met een SLA, SLO en SLI’s? Of wil je hier meer over weten? Neem contact met ons op, we helpen je graag.
