Observability is een vakgebied dat ons als testers veel te bieden heeft. Deel één in deze serie gaf een algemene introductie, deel twee ging de diepte in over hoe observability ons als testers kan helpen. Maar als je nu zelf wilt beginnen observability in te zetten binnen jouw team, welke concrete stappen moet je dan zetten? Welke tools raden wij aan? Dat bespreken we in dit derde en laatste deel van de serie.
Observability benutten
Dit kan informatie zijn op basis waarvan we de dienst verder verbeteren, fouten opsporen of gerichte kostenbesparingen inzetten. Wat we ook willen bereiken, observability moet ons helpen, niet overladen met irrelevante informatie. We willen signalen ontvangen die ons vertellen wanneer er iets mis is, maar ook wat we hiermee kunnen doen.
Hoe gaan we hiermee aan de slag? We noemen drie concrete adviezen.
1. Begin met wat er is
Als je observability wilt gaan inzetten voor testen of quality engineering, maak dan eerst een rondje in je organisatie om te zien welke observability-tooling er al wordt gebruikt. Observability is dagelijkse kost voor operations- en beheerteams, dus grote kans dat er al een basis aanwezig is waar je op voort kunt bouwen.
2. Meet niet te veel
Selecteer één of twee meetbare kerninzichten (KPI’s) die je iets vertellen over de kwaliteit van je dienst. Bijvoorbeeld de error rate en de gemiddelde requestduur op je API. Richt dashboarding en eventueel alerting in op enkel deze metrics, en maak ze onderdeel van je routines.
Richt een alertingkanaal in in Slack of Teams, doe regelmatig check-ins op je dashboards, en evalueer of ze nuttig zijn voor je team. Zo ja, bouw dan langzaam uit. Zo nee, itereer totdat je observability hebt waar je wel wat aan hebt. Beter één nuttig signaal, dan tien signalen aan ruis.
Voorbeelden van ruis in observability:
- Meerdere metrics die op hetzelfde probleem duiden.
- Foutmeldingen die onderdeel zijn van een bekend probleem waar al aan gewerkt wordt.
- Verstoringen in de dienst die hun oorzaak hebben in een externe provider (bijv. een cloud- of internetprovider).
3. Voorkom alert fatigue
Een van de grootste gevaren bij het inrichten van observability, specifiek op het gebied van alerting, is alert fatigue: er worden te veel meldingen verstuurd waar mensen niets mee kunnen. De meldingen kunnen vals alarm zijn, of afgaan op externe oorzaken waar de ontvanger geen invloed op heeft.
Grafana Labs concludeerde uit onderzoek dat 33% van hun klanten alert fatigue noemt als het grootste obstakel voor goede incidentrespons in hun organisaties. Dit is de IT-variant van De jongen die “wolf!” riep: als je specialisten de signalen van het systeem niet meer vertrouwen, verlies je kostbare tijd op de momenten dat er wél iets aan de hand is.
Zelf een observabilitycultuur opzetten
Cloud versus self hosted
Newcomer
Clickstack
Underdog
OpenObserve
Een of meerdere tools
Gespecialiseerde tools per behoefte
Eigenaarschap
Nadenken over tools en techniek is leuk, maar uiteindelijk is de vraag hoe je observability laat landen in jouw organisatie. Een observabilitycultuur is niet enkel metrics binnenhalen en dashboards maken. Het is:
- Teams die nadenken over hoe ze hun succes meetbaar kunnen maken, en techniek inzetten om continu de vinger aan de pols te houden.
- Nadenken over hoe je beter zicht kunt krijgen op de gebruiker, en diens echte problemen.
- Aansluiten bij processen zoals ontwikkeling, incidentrespons en data-analyse.
- Kennis van het observability-systeem en best practices, en het delen daarvan binnen je organisatie.
Hier kunnen weinig algemene adviezen gegeven worden. Onderzoek welke vragen er leven in jouw organisatie, en welke data er beschikbaar is of gemaakt kan worden om die vragen te beantwoorden. Breng de juiste mensen bij elkaar en stel de vraag: hoe komen we samen van ruis naar signalen?
Leg vervolgens het eigenaarschap goed vast, maar evalueer ook regelmatig. Geven je tools je actionable insights? Dan ben je op de goede weg.
