Continuous Monitoring; iets voor jouw team?

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 procent 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 procent 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 procent. 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.

Hans Oude Middendorp is Craft Expert van Team ALM binnen Craft, het groeiprogramma voor IT'ers.
Deze blog verscheen eerder op www.centric.eu/craft.