Experts halen ketenmonitoring met regelmaat aan als hét hulpmiddel tegen slecht presterende it met een overdaad aan systemen, applicaties en informatiestromen van verschillende leveranciers. De silver bullet die zorgt voor overzicht en grip in een complex en versnipperd it-landschap. De hele keten in kaart brengen werkt immers stukken beter dan het monitoren van individuele componenten of applicaties, zo is de gedachte.
In hun enthousiasme vergeten it-specialisten nog weleens dat ketenmonitoring pas in een effectief middel verandert wanneer vooraf essentiële stappen zijn gezet. Zonder deze voorbereidingen blijkt het in de praktijk lastig om snel en juist te handelen wanneer processen stilvallen, met een (te) hoge downtime of buitenproportioneel stijgende kosten tot gevolg. Dit zijn de belangrijkste stappen die gezet moeten worden om ketenmonitoring tot een succes maken.
- Maak processen niet belangrijker dan ze zijn
Technisch is er veel mogelijk rondom ketenmonitoring maar voor wie niet oplet, lopen de kosten snel op. Het is verstandig om eerst de sleutelprocessen in kaart te brengen. Niet elk proces hoeft immers als bedrijfskritisch te worden aangemerkt omdat ze simpelweg niet direct de bedrijfsvoering verstoren wanneer ze een paar uur uit de lucht zijn.
Een hypotheekverstrekker zal bijvoorbeeld het opvragen van rentestanden niet als een bedrijfskritisch proces beschouwen. Het indienen en daarmee vastzetten van een hypotheek door klanten daarentegen wel. Het laatstgenoemde proces krijgt dan het label ‘hoge beschikbaarheid’ mee. Door labels aan te brengen en je vervolgens voornamelijk te richten op de belangrijkste processen die hoge beschikbaarheid eisen, kun je de kosten op een aanvaardbaar niveau houden en toch een zo laag mogelijk downtime nastreven.
- Zorg dat alle teams dezelfde taal spreken
Steeds meer organisaties willen hun it-systemen zo inrichten dat ze snel wijzigingen kunnen doorvoeren en niet eens per half jaar een compleet systeem moeten updaten. Dit doen ze door bijvoorbeeld microservices toe te passen, waarbij ze functies losknippen die in een groot systeem aan elkaar vastgeplakt zaten.
Dit is een efficiënte manier van werken, zolang elk team maar op dezelfde manier monitort en logt. Zonder cohesie en standaardisatie is het onnodig moeilijk om erachter te komen waar in de keten het proces niet functioneert. Probeer teams zoveel mogelijk vrijheid te geven, maar wel binnen vooraf gestelde kaders. Zorg er dus voor dat de teams dezelfde taal spreken en hun bevindingen op dezelfde manier vastleggen.
- Vind balans tussen ontwikkeling en beheer
De keuze uit tools is eindeloos groot. Kijk alleen al naar de CNCF Cloud Native Interactive Landscape en je ziet een wirwar aan tooling en applicaties met allemaal hun eigen functies en kenmerken. De vraag is dan ook: wat is de beste tool voor mij en wat biedt deze tool mij meer dan die andere? Het is belangrijk om vooraf goed na te gaan welke (monitoring)tools een organisatie nodig heeft. Kijk ook naar de impact van bepaalde tooling op de beheerteams. Je wilt voorkomen dat de beheerlast proportioneel toeneemt, maar tegelijkertijd wil je ook dat de stakeholders de juiste informatie krijgen. Je wilt innovatie niet stagneren, maar uiteindelijk moet je een middenweg vinden. Je kunt niet iedereen blij maken, maar standaardisatie en een common ground is wel echt nodig.
Open deur
Auteur: Melvin Anbeek, service delivery manager Info Support
Melvin Anbeek kijkt naar het lampje zonder te beseffen dat deze niet brandt want veelal wordt het doel van ketenmonitoring bepaald door service level afspraken, de open deur van weten wat je wilt meten omdat je opvallend vaak incidenten kunt voorspellen op grond van de events die optreden in de keten. Zo is een tekort aan resources in de infrastructuur vaak te voorzien alleen worden de signalen nog weleens genegeerd door het beheermodel van Looijen omdat iedereen alleen maar naar de eigen lampjes kijkt. Functionele beheerders en ontwikkelaars vergeten namelijk nog weleens dat draadloos stroom niet bestaaat als het gaat om de natuurkundige wetten van de IT.
Jaren geleden schreef ik een opinie over de Theory of Contraints en de wet van communicerende vaten als het om de voorspelbare RCA van bottlenecks gaat, het idee van opschalen als je bijna het breekpunt bereikt om vervolgens de belasting te verdelen wordt namelijk lastig als je bepaalde transacties niet op kunt knippen. Veel SOA architecturen worstelen nog altijd met het schrijven van het resultaat als het om de eenduidige waarheid gaat, die klap van de hamer om de klok van de veiling stil te zetten is vaak een struikelblok als ik naar dezelfde taal van tijd in logfiles kijk.
Door te zeggen dat “iemand naar het lampje kijkt, zonder te beseffen dat deze niet brandt”, en vervolgens te zeggen “dat ketenmonitoring veelal bepaald wordt door service level afspraken”, geeft mij het gevoel, dat het artikel niet gelezen c.q. begrepen is. Service level afspraken kunnen heel bepalend zijn. Het geeft richting, maar lang niet alle organisaties weten de implicaties van een service level afspraak, ten aanzien van hun systeem. Er wordt vaak naar de dienst als geheel gekeken, terwijl dat vaak veel overhead in maatregelen geeft. Ik ben van mening dat het definiëren van ketens, organisaties dwingt om hier kritisch naar te kijken op basis van deze input, betere service level afspraken te maken. In een wereld waar meerdere teams, werken aan verschillende componenten van één systeem, waarbij (keten)monitoring thema’s zoals observability moet complimenteren, zijn deze afspraken steeds vaker ondergeschikt.
Ik ben zelf nieuwsgierig naar het opiniestuk, beschreven in de reactie. Het lijkt mij oprecht interessant. Delen wordt gewaardeerd.
Melvin,
Het gevoel dat ik niet bekend ben met ketenmonitoring lijkt me vooral een emotie want hoewel de opinie ‘Ketenproblematiek en communicerende vaten’ bijna 9 jaar oud is heb ik deze ooit geschreven vanuit een paar praktijkcases. Focus ligt op de infrastructuur omdat een toen veel gemaakte fout het ‘overcommitteren’ ervan was en nieuwe ‘heilige graal’ hierin is Quality of Service (QoS) waardoor het lampje dat op dashboard gaat branden als de tank bijna leeg is nog belangrijker is geworden als we kijken naar een ‘harde stop’ vanuit de infrastructuur.
Rationalisatie van diagnostische data vanuit de infrastructuur gaat uiteindelijk om een stukje AIOPS waarin de events omgezet worden naar de voorspellende analyses want je wilt uiteindelijk weten hoever je nog komt met de inhoud van je tank. Op grond van QoS kun je ervoor kiezen om bepaalde processen voorrang te geven om zodoende te voldoen aan de SLA’s want service level afspraken zijn contractueel heel bepalend als er boeteclausules aan vast zitten.