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.
