Devops werkt niet voor iedereen

'If the rate of change on the outside exceeds the rate of change on the inside, the end is near.' We kunnen met enige zekerheid stellen dat de eigenaar van deze quote – de legendarische General Electric-ceo Jack Welch – nooit in een devops-team heeft gezeten. Toch is deze quote perfect toepasbaar op deze relatief nieuwe manier van software ontwikkelen en beheren. Het maakt je sneller, flexibeler en meer in the lead. Maar hoe bepaal je dit?

De devops-manier van werken is zo populair omdat je met deze aanpak snel kunt inspelen op veranderingen in de markt en de vraag van de business. Het werken in zelf-organiserende, multidisciplinaire devops-teams vergt echter een compleet andere denk- en werkwijze. Niet langer zijn individuele rollen leidend, maar een gezamenlijke verantwoordelijkheid om een systeem te ontwikkelen, in productie te brengen en beschikbaar te houden. Dit met als doel om sneller te kunnen leveren, wendbaarder te zijn en hiermee de concurrentie voor te blijven.

Dat brengt wel een nieuwe vraag met zich mee; want wanneer is een devops-team succesvol? Hoe meet je de impact van devops op de organisatie? Ben je daadwerkelijk wendbaarder geworden? En hoe perform je ten opzichte van de concurrentie? Hierbij kan het handig zijn om over vergelijkingsmateriaal te beschikken. Dit vereist echter wel dat er gebruik gemaakt wordt van dezelfde metrics. Maar welke ga je gebruiken? Velocity wordt vaak gebruikt, maar is niet vergelijkbaar over teams en organisaties heen. Lead time zegt iets over snelheid, maar ben je ook in staat om het systeem beschikbaar te houden? Het is dus belangrijk om uit te zoomen en naar het grotere geheel te kijken.

Meten is weten

Marktonderzoeken en rapporten als state of devops laten zien dat er vier belangrijke metrics zijn om delivery en operationele performance van een organisatie te meten.

• Deployment frequency

Hoe vaak kun je je product of dienst beschikbaar stellen aan eindgebruikers?

• Lead time for changes

Als je een wijziging wil doorvoeren, hoe snel kun je dat dan doen?

• Time to restore service

Als je service op een of andere manier niet beschikbaar is, hoe snel kun je het dan herstellen?

• Change failure rate

Als je wijzigingen doorvoert, in hoeveel procent van de gevallen levert dit fouten op?

Doordat veel devops-teams deze vier metrics gebruiken, is het relatief eenduidig om je team te vergelijken met de rest van de markt. Onderzoek toont aan dat er grote verschillen zijn tussen de hoogst en de laagst scorende organisaties. Zo kunnen de besten ruim honderd keer sneller wijzigingen doorvoeren en 2600 keer sneller herstellen van incidenten. Het aandeel organisaties dat hier hoog op scoort neemt ook sterk toe.

Dat hoog scoren lijkt echter eenvoudiger dan het is; bij veel bedrijven is dit nog best een uitdaging. De meest gebruikte ontwikkelstraten hebben deze metrics nog niet standaard ingebouwd. Hier ligt nog wel wat ruimte voor verbetering. Hoe kunnen we deze metrics geautomatiseerd meten, en welke data uit je ontwikkelstraat kun je hiervoor gebruiken? Op dit moment gebeurt het nog vaak in gespreksvorm. Er wordt aan een team gevraagd: hoe scoor je ten opzichte van die metrics? Waar denk je dat je zit? Waarom denk je dat? Wanneer begint en eindigt de lead time? Hierop gebaseerd wordt een advies opgesteld: als je wilt verbeteren, dan moet je het daar zoeken.

Devops of niet

Bij de meeste devops-teams moeten deze metrics dus nog handmatig worden bepaald. Om de doorlooptijd van leadtime vast te stellen kun je het versiebeheersysteem van je ontwikkelstraat gebruiken, waarin elke wijziging die je uitvoert is vastgelegd. Ook uit het continuous delivery proces (build en release pipelines) valt data te halen. De praktijk leert echter dat het belangrijk is om een zekere mate van automatisering aan te brengen om deze metrics te verzamelen. Je kunt dan namelijk vaker meten en sneller bepalen of een wijziging in je aanpak of omgeving een positieve bijdrage heeft geleverd. Aan de operationele kant moet je kunnen monitoren wanneer het systeem down was en hoe lang het herstel duurde (time to restore en change failure rate). En wanneer het in teamverband over monitoring gaat wordt het ineens interessant. Dat is het moment waarop je erachter komt of je daadwerkelijk een devops-team vormt of niet. Ben je verantwoordelijk voor je product en heb je zowel zicht op de build- en release pipeline (development) als monitoring (operations)? Is het antwoord nee, dan kun je je afvragen of je eigenlijk wel een devops-team bent.

Elk bedrijf wil hoog scoren in wendbaarheid, maar het is natuurlijk geen doel op zich. Wendbaarheid moet noodzakelijk zijn, bijvoorbeeld omdat concurrenten het sneller kunnen. Het feit dat je meerdere keren per dag on-demand een wijziging in productie kan zetten, is natuurlijk mooi, maar heb je dat ook nodig? Denk dus na over je doelen en wees duidelijk hoe je metrics hieraan koppelt binnen je bedrijf. Je krijgt immers altijd dat waar je op stuurt.

Erik Sackman, service delivery manager bij Info Support