Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Devops werkt niet voor iedereen

puzzel

'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

"De meest gebruikte ontwikkelstraten hebben de vier genoemde metrics nog niet standaard ingebouwd"

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

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

DevOps is een term die te pas en te onpas gebruikt wordt terwijl het dus voornamelijk om een paradigma in de ontwikkeling van software gaat. Veel DevOps teams zijn vooral gericht op de oplevering van software waardoor de werklijke Ops kant van service levels uiteindelijk nog teveel onderbelicht blijft, DevOps meet uiteindelijk de verkeerde parameters want het rekensommetje aangaande de uptime wordt niet beter als je snel hersteld van veel fouten. Een service delivery manager moet dat weten want de frustratie aan het loket omdat de computer het weer niet doet is dodelijk voor het imago van een organisatie.

Wendbaarheid is ook zo'n veelgehoorde maar overschatte term want de meeste organisaties zijn net zo wendbaar als een mammoettanker zonder een kapitein door de verwevenheid van processen. Ik ben natuurlijk gekke Henkie maar ik zie een toenemende vraag naar long term support, oplossingen in de basis van de architectuur moeten zo'n 10+ jaar mee gaan omdat we 'veranderingsmoe' aan het worden zijn. Ik denk dat de quote van Jack Welch hierop wees, als de markt sneller veranderd dan de organisatie dan is er een probleem maar het omgekeerde geldt ook. Een te veranderlijke organisatie wordt nog vaak als te opportuun afgeserveerd omdat vertrouwen gebaseerd is op continuïteit, nog zo'n KPI die veelal gemist wordt door DevOps.

deployment frequency : hoe vaak kun je de boel laten omvallen ?
lead time for changes : als je een bug kunt introduceren, hoe snel kun je dat dan doen ?
time to disrupt service : zie ook deployment frequency, hoe snel kun je de de service verstoren ?
change failure rate : hoe snel kun je iets kappot maken ?

gaat dit te langzaam of wil je dit helemaal niet, dan is devsops wellicht niks voor jullie.

Een prima inleiding in DevOps, maar het artikel gaat voorbij aan veel relevante vragen rond het onderwerp. Wanneer is DevOps relevant en wanneer niet? Wat moet je doen om DevOps werkelijk te laten functioneren ten bate van de organisatie? Helaas wordt de stelling in te titel ook niet echt onderbouwd. Voor wie werkt het wel/niet en waarom? Misschien wel een nog leukere vraag: Wat te doen als DevOps niet het antwoord is?

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2020-02-13T11:29:00.000Z Erik Sackman
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.