Spoor softwarebugs proactief op met continuous monitoring
Het opsporen van softwarebugs en fouten in applicaties of problemen in de infrastructuur van een informatiesyteem gebeurt nog te vaak reactief: gaat er iets mis, dan wordt pas IT ingeschakeld. “Zonde”, stelt Hans Oude Middendorp, IT-expert bij Centric. “Met de huidige beschikbare technologie is het veel eenvoudiger geworden om proactief met monitoring om te gaan en gebruikers al te helpen voordat ze zelf in de gaten hebben dat er een probleem is.”
“Sterker nog,” gaat Oude Middendorp verder, “zelfs het voorkomen van sommige problemen kan geautomatiseerd worden.” Hij doelt hiermee op de sterk toegenomen rekenkracht van nieuwe technologieën, die veelal gepaard gaan met de voordelen van cloud(technologie). “Zo kan je met de mogelijkheden die Azure DevOps en Azure Monitor bieden, (bijna) de complete monitoringbehoefte invullen”, stelt de IT-adviseur.
Het kiezen voor een meer proactieve en oplossingsgerichte aanpak kan bedrijven veel geld besparen, legt Oude Middendorp uit. Te denken valt aan processen die vertraagd worden of worden stopgezet, als gevolg van optredende bugs of wijzigingen in het gebruik van een systeem. Wanneer er op een dergelijk scenario vooraf onvoldoende is voorbereid, kunnen processen tot stilstand komen. “Met het gevolg dat tijd verloren gaat of dat dit in het ergste geval kan leiden tot een impact op de dienstverlening aan klanten.”
Wat vandaag de dag normaal gesproken gebeurt, is dat softwareontwikkelaars vooral reactief opereren. “Als een gebruiker zich meldt met een probleem, dan worden logfiles, event-logs et cetera bekeken om te achterhalen wat er fout is gegaan en waarom. Vanuit operations wordt met name gelet op de beschikbaarheid en de performance van systemen. Ook dat gebeurt heel vaak reactief; pas nadat gebruikers klagen over snelheid of uitval van een systeem wordt er actie ondernomen.”
Service level-doelstellingen
Een manier om proactiever te handelen, is door het gebruik van metrische gegevens en die te koppelen aan service level-doelstellingen. “Neem bijvoorbeeld het geval van betrouwbaarheid van een systeem... dan kun je denken aan zaken als beschikbaarheid, performance, mate van correctheid van informatie, houdbaarheid van informatie, actualiteit van informatie et cetera.”
Als hiervoor een service level-doelstelling is gedefinieerd – “deze moet genoteerd kunnen worden als een percentage” – kan actie ondernomen worden zodra de performance daalt tot onder de vooraf gestelde target. Oude Middendorp: “Dit kan een geautomatiseerde reactie zijn, zoals ‘we schakelen extra servers in’, of een handmatige reactie, waarbij de IT’er die de taak heeft de situatie te monitoren uiteindelijk beslist wat de best mogelijke corrigerende maatregel is.
In het geval van een geautomatiseerde reactie is het volgens Oude Middendorp essentieel om zorgvuldig na te denken over hoe dit proces wordt gemanaged en wat de mogelijke gevolgen kunnen zijn. “Bijvoorbeeld: vaak is het lastig of onmogelijk een automatische reactie te definiëren die er in alle gevallen voor zorgt dat het systeem weer voldoet aan de service level-doelstellingen. In die gevallen moet het team zelf actie ondernemen.” Een ander voorbeeld: “Uiteraard moet ook worden nagedacht hoe de geautomatiseerde reactie eruitziet, wanneer de performance weer voldoet aan de service level-doelen.”
