Centric connect.engage.succeed

Continuous Monitoring; iets voor jouw team?

Geschreven door Hans Oude Middendorp - 10 mei 2019

Hans Oude Middendorp
Softwareontwikkelaars monitoren applicaties op fouten, zodat ze deze snel kunnen opsporen. Dat doen ze met name reactief; 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.

Steeds vaker werken softwareontwikkelaars en systeembeheerders samen in DevOps-teams. Vanuit deze teams houden zij zich bezig met zowel het onderhoud en uitbreiden van de functionaliteit van systemen als het dagelijks beheer van deze systemen.

Proactief

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, zelfs het voorkomen van sommige problemen kan geautomatiseerd worden.

Daarnaast kan monitoring worden ingezet om te meten hóe systemen gebruikt worden om het succes van nieuwe of bestaande functies te meten en te kunnen anticiperen op pieken of dalen in het gebruik van systemen.

Als laatste zou het ook prachtig zijn als we met dezelfde technieken kunnen meten hoe efficiënt we als team werken aan onze applicaties en systemen.

Betrouwbaarheid

We monitoren systemen proactief om de betrouwbaarheid te waarborgen. Bij de betrouwbaarheid van een systeem kun je denken aan zaken als beschikbaarheid, performance, mate van correctheid van informatie, houdbaarheid van informatie, actualiteit van informatie et cetera.

Service Level Indicators en objectives

Veel van deze zaken kunnen gemeten worden met Service Level Indicators. Een Service Level Indicator moet genoteerd kunnen worden als een percentage, bijvoorbeeld: het percentage succesvolle http-calls ten opzichte van het totale aantal http-calls. Of: het aantal bewerkingen dat is uitgevoerd binnen 10 milliseconden ten opzichte van het totale aantal uitgevoerde bewerkingen.

Door aan een Service Level Indicator een tijdspanne en een doel te koppelen, kun je een Service Level Objective definiëren. Bijvoorbeeld: 90% van de bewerkingen in het afgelopen uur is binnen 10 milliseconden uitgevoerd.

Geautomatiseerde reactie

Als op enig moment een systeem niet meer voldoet aan een Service Level Objective moet je als team reageren. Dit kan een geautomatiseerde reactie zijn, zoals: we schalen onze Web Application Service op als in het afgelopen uur minder dan 90% van de bewerkingen binnen 10 milliseconden is uitgevoerd. Of: we starten een extra virtuele machine als de CPU-load op de al draaiende machines de afgelopen 5 minuten hoger was dan 85%. Uiteraard moet je in dit soort gevallen ook nadenken over het afschalen van je service of het uitzetten van extra virtuele machines indien het systeem weer voldoet aan de Service Level Objectives.

Actiegerichte notificatie

Vaak is het lastig of onmogelijk een geautomatiseerde reactie te definiëren die er in alle gevallen voor zorgt dat het systeem weer voldoet aan de Service Level Objectives. In die gevallen moet het team zelf actie ondernemen.

Uiteraard heeft het alleen zin om iemand een notificatie te sturen als deze persoon iets kan onderzoeken en in staat is het probleem op te lossen. Het is niet fijn als je midden in de nacht een SMS krijgt met het verzoek te reageren, terwijl jij niet degene bent die iets aan het probleem kan doen (behalve een collega uit zijn bed bellen).

Verder is het raadzaam niet alleen een notificatie te sturen, maar deze te voorzien van extra informatie. Op die manier kan degene die de notificatie ontvangt ook gelijk met het onderzoek en/of de oplossing aan de slag. Over welk Service Level Objective gaat het? Welke stappen kunnen ondernomen worden om het probleem op te lossen? Ook het belang van het oplossen van het probleem (hoeveel last heeft de klant/eindgebruiker ervan?) kan helpen bij de beslissing of er direct iets moet gebeuren, of dat het kan wachten tot de werkdag weer begint.

Teamefficiency

Met metrieken kun je inzicht krijgen in de efficiency van een team. Hieronder een aantal metrieken (dus geen volledige lijst):

  • Deployment frequency: hoe vaak rol je wijzigingen uit (per dag/week/maand et cetera) in productie
  • Deployment speed: hoe lang duurt het uitrollen van wijzigingen gemiddeld?
  • Deployment failure: hoe vaak leidt de uitrol van wijzigingen tot nieuwe fouten in de productieomgeving?
  • Change lead time: wat is de gemiddelde tijd tussen het aanvragen van een wijziging en de uitrol daarvan?
  • Change volume: hoeveel wijzigingen zijn gemiddeld in één uitrol-actie opgenomen?
  • Mean time to detection: hoe lang duurt het gemiddeld voordat een fout wordt opgemerkt nadat deze is opgetreden in productie?
  • Mean time between failures: wat is de gemiddelde tijd tussen het optreden van fouten in productie?
  • Mean time to recovery: wat is de gemiddelde tijd tussen het optreden van fouten in productie en het beschikbaar komen van een oplossing in productie? 

Daarnaast kun je natuurlijk altijd besluiten om bepaalde zaken niet te meten of je met je team op andere metrieken te richten.

Azure DevOps en Azure Monitor

Met de mogelijkheden die Azure DevOps en Azure Monitor je bieden, kun je (bijna) je complete monitoringbehoefte invullen.

Benieuwd hoe dat in zijn werk gaat? Kom dan naar het komende Craft InDepth Cloud Event in jouw regio (juni 2019)! Meld je hier aan.

Over Hans

Craft Expert Hans Oude Middendorp is Craft Expert van Team ALM binnen Craft, hét groeiprogramma voor IT'ers (powered by Centric). Wil je zijn blog volgen? Schrijf je in voor de Craft-update.

Wil je meer weten over Craft, hét groeiprogramma voor IT'ers? Neem een kijkje op de website!

Tags:ALMCloud

     
Schrijf een reactie
  • Captcha image
  • Verzenden