Skip to main content

Dus je bent begonnen met het invoeren van DevOps in je bedrijf. Maar hoe weet je of dit je processen verbetert? Je moet het succes op de een of andere manier meten. Dat kun je doen door enkele belangrijke DevOps-metrieken te monitoren.

Er zijn veel manieren om de kwaliteit van een systeem of applicatie te beoordelen, maar in dit artikel richt ik me op belangrijke metrieken die helpen de kwaliteit van je processen te evalueren. Door deze indicatoren bij te houden, krijg je diepere inzichten in je sterke en zwakke punten, verbeter je je DevOps-best practices en benut je de juiste tools en software voor continue verbetering.

Waarom zijn DevOps-metrieken belangrijk?

Zoals hierboven besproken, kunnen gedeelde doelen en metrieken een uitdaging vormen voor teams die DevOps binnen een bedrijf invoeren. Zonder DevOps-metrieken zouden er geen tests of metingen plaatsvinden en zou de ontwikkeling niet verbeteren. Het zouden slechts iteraties van dezelfde software zijn, gebaseerd op vermoedens en ideeën, die vervolgens in de leegte worden gegooid waarna iets nieuws wordt geprobeerd. Zonder feedback of metrieken voor productsucces om te begrijpen hoe iets presteert, is er geen richting.

Want more from The CTO Club?

Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.

Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.
Een cirkeldiagram van DevOps-metrieken dat laat zien hoe een typische ontwikkelaar zijn tijd besteedt
Redenen waarom je DevOps-metrieken nodig hebt.

Financiële afdelingen willen de kosten bijvoorbeeld zo laag mogelijk houden, terwijl ontwikkelaars de prestaties zo hoog mogelijk willen houden. Deze twee doelen hoeven niet op elkaar aan te sluiten, tenzij de risico’s zijn beoordeeld en de teams elkaars doelstellingen begrijpen.

Waar je ontwikkelaars er misschien voor kiezen een onvolledig product uit te brengen en de problemen later op te lossen, leidt de impact hiervan tot technische schuld. Door DevOps te implementeren kunnen de doelen en strategieën van beide teams op elkaar worden afgestemd, en kun je je ontwikkelaars inzicht geven in de kostenimpact van hun technische beslissingen.

Dit is slechts een klein onderdeel van DevOps en van het belang van gedeelde metrieken.

5 belangrijke DevOps-metrieken (DORA)

DevOps implementeren en raamwerken op basis van principes begrijpen is één ding, maar met DevOps-metrieken begin je de voordelen van deze samenwerkingsgerichte aanpak voor de levenscyclus van softwareontwikkeling echt te zien. Zoals bij de meeste bedrijfsstrategieën zijn er eindeloos veel metrieken die je kunt kiezen om groei te meten, afhankelijk van je sector, doelgroep en doelen.

Het DevOps Research and Assessment-team van Google Cloud (DORA) is het langstlopende onderzoeksteam in zijn soort. Aanvankelijk ontdekten zij vier belangrijke metrieken om de prestaties van de ‘elite’ binnen DevOps te meten. Sindsdien is er echter een vijfde belangrijke metriek aan de mix toegevoegd, en hun clusteranalyse onderscheidt slechts drie niveaus van DevOps-teams: hoog, gemiddeld en laag, waarbij ‘elite’ tot het verleden behoort.

1. Implementatiefrequentie (DF)

DF meet hoe vaak je succesvol naar productie uitbrengt. Deze metriek draait om consistentie en is een uitstekende indicatie van het behalen van doelstellingen.

Teams in de categorie ‘elite’ zouden consequent meerdere keren per dag naar productie implementeren, terwijl teams met lage prestaties dichter bij één keer per zes maanden zouden zitten.

DF verbeteren is zo eenvoudig als het uitbrengen van meerdere kleine updates. Het belangrijkste voordeel hiervan is dat eventuele procesblokkades, knelpunten of complexe projecten die aandacht vereisen aan het licht komen. Grotere teams geven er mogelijk de voorkeur aan om met regelmatige tussenpozen te implementeren door Agile-releasetreinen op te zetten; dit helpt de overweldiging door een extreem tempo en een groot aantal mensen te verminderen.

2. Doorlooptijd voor wijzigingen (LTC)

LTC verwijst naar de tijd die nodig is voordat een commit in productie terechtkomt. Deze metriek is een goede indicator van de reactiesnelheid en wendbaarheid van een team, omdat wordt gemeten hoe snel het op behoeften en verzoeken van gebruikers kan reageren.

De vroegere ‘elite’-norm streefde naar een LTC van minder dan één dag, terwijl teams met lagere prestaties er meer dan zes maanden over konden doen. Een score aan de onderkant van de schaal voor LTC is waarschijnlijk het gevolg van inefficiënte processen.

Je kunt deze metriek verbeteren door automatiseringsprocessen te verbeteren, vooral het testen. Door je continue integratie en pipeline voor continue levering (CI/CD) te verbeteren, kun je updates sneller naar productie brengen. Een risico waar je hier echter op moet letten, is duurzaamheid. Als je team dit verbeterde tempo niet kan volhouden, kun je te maken krijgen met een slechte gebruikerservaring en mogelijke beveiligingskwetsbaarheden.

3. Faalpercentage van wijzigingen (CFR)

CFR is het percentage implementaties dat een storing in productie veroorzaakt. Een storing kan bestaan uit downtime, terugdraaien of een verminderde dienstverlening. Deze metriek laat zien hoe effectief je team is bij het implementeren van wijzigingen.

Benchmarks voor eliteprestaties liggen tussen 0 en 15%, terwijl hoge, gemiddelde en lage prestaties allemaal binnen 16-30% vallen.

Het verbeteren van CFR draait om kwaliteit boven kwantiteit. Bedrijven brengen verschillende aantallen wijzigingen uit en hebben daarom ook verschillende aantallen storingen. Wijzigingen van de hoogste kwaliteit leiden echter tot minder storingen, ongeacht of ze twee keer per jaar of twee keer per dag worden geïmplementeerd.

4. Gemiddelde hersteltijd (MTTR)

MTTR is de tijd die je team nodig heeft om de dienstverlening na een storing of onderbreking te herstellen. Deze metriek meet niet alleen de wendbaarheid van je team, maar is ook een goede graadmeter voor de stabiliteit van je software.

Als je mikt op een ‘elite’-niveau, moet je streven naar een MTTR van minder dan een uur. Teams met lage prestaties kunnen er meer dan zes maanden over doen.

Je kunt MTTR verbeteren door je te richten op kleine, snelle releases, waardoor storingen gemakkelijker te vinden en op te lossen zijn. Je kunt ook functievlaggen verkennen om je team meer controle te geven — vooral als ze experimenteel zijn.

Een tabel met de DORA-metrieken, uitgesplitst naar snelheid en kwaliteit
De vier DORA-metrieken zijn DF, LTC, CFR en MTTR.

Er is nog één metriek die we moeten behandelen.

5. Betrouwbaarheid

De vijfde bonusmetriek is betrouwbaarheid. Deze metriek werd later ontdekt door het DORA-team (2021), omdat beschikbaarheid eerder als benchmark voor betrouwbare software werd gemeten. Er werd echter besloten dat betrouwbaarheid beschikbaarheid, latentie, prestaties en schaalbaarheid beter omvat. Het gaat in wezen om het meten van operationele prestaties naast ontwikkeling.

Andere veelgebruikte DevOps-metrieken

Get regular tech leadership wisdom for delivering better software and systems.

Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form

Doorlooptijd

De doorlooptijd is de totale tijd vanaf het starten van een taak tot de uiteindelijke oplevering. Op het eerste gezicht houdt deze de werksnelheid van je team bij. Je kunt echter dieper in deze metriek duiken om knelpunten te vinden, zoals lange wachttijden en lang openstaande pullverzoeken.

Een kortere doorlooptijd wijst op een efficiënte workflow, vermindert knelpunten en verhoogt de ontwikkelsnelheid.

De doorlooptijd meten

De doorlooptijd wordt berekend door tijdstempels van commits, code-uploads en implementaties bij te houden in tools zoals GitHub, GitLab of Jenkins.

Doorlooptijd = implementatietijd - committijd

Om de doorlooptijd te verbeteren, moeten teams:

  • CI/CD-pijplijnen optimaliseren voor snellere integratie en implementatie.
  • Builds en tests automatiseren.
  • De samenwerking tussen ontwikkel- en operationele teams verbeteren.
  • Afhankelijkheden tussen taken verminderen om knelpunten tot een minimum te beperken.

Gemiddelde detectietijd (MTTD)

Dit is de gemiddelde tijd die je team nodig heeft om een storing te erkennen. Een lage MTTD wijst op efficiënte monitoring- en waarschuwingssystemen, waardoor incidenten snel kunnen worden afgehandeld en opgelost.

MTTD meten

MTTD kan worden gemeten door de gemiddelde tijd bij te houden tussen het optreden van een probleem en de detectie ervan door monitoringtools of meldingen van gebruikers. Het verlagen van MTTD omvat het verbeteren van geautomatiseerde monitoring, het verfijnen van waarschuwingsmechanismen en het waarborgen van proactieve detectie van problemen.

Geslaagde geautomatiseerde tests

Het is goed om te streven naar een goede testdekking, vooral met geautomatiseerde tests. Hierbij heb ik het over unit-, integratie-, UI- en end-to-endtests. Een goede dekking is echter niet voldoende om de kwaliteit van de software te waarborgen. Wat telt, is het percentage van deze tests dat slaagt.

Natuurlijk is het doel om een percentage geslaagde tests te hebben dat zo dicht mogelijk bij 100% ligt. Door deze metriek te monitoren, kun je ook ontdekken hoe vaak nieuwe ontwikkelingen bestaande tests laten mislukken.

Het percentage geslaagde geautomatiseerde tests meten

De berekening is een eenvoudig percentage: vermenigvuldig het aantal geslaagde tests met 100 en deel dit vervolgens door het totale aantal tests. Je kunt deze informatie verkrijgen uit de pijplijntool die de builds uitvoert (Jenkins, Azure DevOps, CircleCI enzovoort).

Het aantal kan een goede indicator zijn voor de kwaliteit van het product. Het kan echter ook lastig zijn als je onbetrouwbare of instabiele tests hebt.

Ontsnappingspercentage van defecten

Het ontsnappingspercentage van defecten geeft aan hoeveel bugs tijdens het testen worden gemist en in productie worden uitgebracht – hoeveel er zijn ‘ontsnapt’. Deze metriek is ideaal om bij te houden als je test- en automatiseringsprocessen wilt verbeteren.

In een utopische wereld zouden al onze apps foutloos zijn. Dat is echter zelden het geval. Idealiter worden defecten tijdens de ontwikkel- en testfasen van het DevOps-proces opgespoord, en niet in productie.

Deze metriek helpt de doeltreffendheid van je testprocessen en de algehele kwaliteit van je programma te bepalen. Een hoog ontsnappingspercentage van defecten wijst erop dat procedures moeten worden verbeterd en dat meer automatisering nodig is, terwijl een laag percentage (idealiter bijna nul) duidt op een hoogwaardige applicatie.

Het ontsnappingspercentage van defecten meten

Om dit te meten, kun je je bugvolgsysteem gebruiken en voor elk openstaand defect bijhouden waar het is gedetecteerd: in de testomgeving of de productieomgeving (of een andere omgeving die je mogelijk gebruikt, zoals UAT).

Klanttickets

Klanttevredenheid is een drijvende factor voor innovatie, en met goede reden: een vlekkeloze gebruikerservaring is goede klantenservice en komt doorgaans overeen met een stijging van de verkoop. Als gevolg daarvan zijn klanttickets, vooral tijdens het ticketescalatieproces, een goede indicator voor hoe goed je DevOps-transitie verloopt. 

Klanten zouden niet als kwaliteitscontrole moeten optreden door defecten en bugs te melden. Een afname van het aantal klanttickets is dan ook een goed teken van goede applicatieprestaties.

CPU- en geheugengebruik

Identificeert trends in het gebruik van systeembronnen.

Responstijd

Meet de tijd die de applicatie nodig heeft om op verzoeken te reageren.

Foutpercentage

Houdt het aantal mislukte verzoeken in de loop van de tijd bij.

Verwerkingscapaciteit

Meet het aantal verzoeken dat per seconde wordt verwerkt.

Latentie van API-verzoeken

Meet de vertraging tussen het verzenden van een verzoek en het ontvangen van een antwoord.

Prestaties van databasequery's

Houdt uitvoeringstijden van query's en mogelijke knelpunten bij.

Analyse van gebruikersgedrag

Monitort trends in functie-adoptie en betrokkenheid.

Gemiddelde tijd tussen storingen (MTBF)

MTBF meet de gemiddelde verstreken tijd tussen systeemstoringen, uitvaltijd of incidenten. Deze metriek beoordeelt de betrouwbaarheid en stabiliteit van je softwaresystemen en benadrukt de doeltreffendheid van je preventieve onderhouds- en foutbeperkingsstrategieën.

Tijd tot beperking (TTM)

De tijd die nodig is om een probleem op te lossen nadat het is gedetecteerd, is de TTM. Deze metriek helpt incidentrespons- en oplossingsprocessen te beoordelen en geeft de efficiëntie van je teams aan bij het aanpakken van en herstellen van problemen.

Doorlooptijd van wijzigingen (CLT)

CLT biedt een ijkpunt voor het implementatieproces van wijzigingen van begin tot eind, inclusief ontwikkeling, testen, beoordeling en implementatie. Een kortere CLT duidt op snellere leveringscycli en een grotere wendbaarheid.

KPI's instellen met DevOps-metrieken

Nu je goed begrijpt welke metrieken je kunt gebruiken om DevOps in je bedrijf te implementeren en te optimaliseren, wil je de belangrijkste prestatie-indicatoren (KPI's) verkennen om doelstellingen en ijkpunten voor je team vast te stellen.

Metrieken versus KPI's

Je vraagt je misschien af wat het verschil is tussen metrieken en KPI's. Een metriek is wat je meet. Het is een kwantificeerbare meting die gegevens verschaft over een specifiek prestatieaspect. Niet alle metrieken zijn noodzakelijkerwijs gekoppeld aan specifieke doelstellingen of streefwaarden.

KPI's zijn daarentegen een type metriek dat strategisch is geselecteerd en gedefinieerd om de meest kritieke aspecten van prestaties en voortgang richting strategische doelstellingen weer te geven. KPI's zijn doorgaans gekoppeld aan doelstellingen en hebben vaak bijbehorende streefwaarden, drempelwaarden of ijkpunten die moeten worden behaald.

KPI's instellen voor je DevOps-team

De eerste stap bij het instellen van KPI's voor je DevOps-team is het koppelen van DevOps-statistieken aan je bedrijfsstrategie en -doelen. Door prioriteit te geven aan de belangrijkste statistieken om bij te houden, kun je beginnen met het vaststellen van doelstellingen en benchmarks voor voortdurende verbetering. Bij het selecteren van de juiste statistieken moet je rekening houden met de omvang van je bedrijf, je product en je markt. Richt je op wat de meest bruikbare inzichten oplevert en vermijd de veelvoorkomende valkuil van een overvloed aan statistieken.

Het monitoren van je KPI's is net zo belangrijk als het instellen ervan. Verken datavisualisatie tools om je team realtimegegevens te bieden via intuïtieve dashboards. Dit zorgt voor volledige zichtbaarheid, maakt verantwoordelijkheid mogelijk en stelt iedereen in staat samen te werken aan gedeelde doelen. Zo worden ontwikkelings- en operationele teams op één lijn gebracht en wordt de invoering en volwassenwording van DevOps ondersteund.

Een tabel met de benchmark-KPI's voor de DORA DevOps-statistieken
Benchmark-KPI's voor DORA DevOps-statistieken.

Als we de kernstatistieken van DORA bekijken, zien we de benchmarks voor elke statistiek op basis van teams met elite-, hoge, gemiddelde en lage prestaties. Deze tabel kan je helpen KPI's voor je eigen bedrijf vast te stellen, afhankelijk van wat je als prioriteit beschouwt.

Bij het instellen van je KPI's kun je het beste zorgvuldig rekening houden met je team en bedrijf, zonder ze te vergelijken met andere bedrijven. Als we CFR als voorbeeld nemen, is de benchmark hetzelfde voor hoge, gemiddelde en lage prestaties. Dit hangt sterk af van je implementatiefrequentie, maar kan daar ook omgekeerd invloed op hebben. Als je team al zijn tijd besteedt aan het herstellen van fouten, blijft er minder tijd over voor het ontwikkelen en uitbrengen van updates. KPI's kunnen ook veranderen naarmate je DevOps-team volwassener wordt. Waterdichte automatiserings- en testprocessen zouden automatisch moeten betekenen dat je de lat voor je doelstellingen hoger kunt leggen.

Hoe je DevOps-statistieken gebruikt om op te schalen

Nu de wereldwijde DevOps-markt naar verwachting $24.71 miljard in 2027 zal bereiken (een samengesteld jaarlijks groeipercentage van 22.9%, gebaseerd op de marktomvang van $10.84 miljard in 2023), is dit je teken als je op zoek bent naar het beste moment om DevOps in je bedrijf te implementeren.

DevOps versnelt niet alleen de ontwikkeling en verkort daarmee de marktintroductietijd, maar verbetert ook de samenwerking door silo's te elimineren, verhoogt de kwaliteit met voortdurend testen en feedbacklussen en benut middelen efficiënt, wat geld bespaart. Tot slot is DevOps eenvoudig schaalbaar en ondersteunt het bedrijfsgroei tot nieuwe grenzen, waarbij 83% van de IT-besluitvormers in 2021 toegang kreeg tot meer bedrijfswaarde door DevOps te implementeren.

Prestatiemeting en voortdurende verbetering

Het monitoren van prestaties is de sleutel tot het opschalen van een bedrijf dat DevOps gebruikt. Het is een aanpak met een hoog tempo en een voortdurende productieworkflow, dus meten en rapporteren moet net zo vaak gebeuren. Met DevOps-statistieken kun je de prestaties van je ontwikkelings- en leveringsprocessen volgen. Door belangrijke aspecten zoals implementatiefrequentie, doorlooptijd en het percentage mislukte wijzigingen te kwantificeren, kun je knelpunten, inefficiënties en verbeterpunten identificeren. Hierdoor kun je workflows en processen regelmatig optimaliseren.

Een lus die laat zien hoe ontwikkelings- en operationele teams verantwoordelijkheden integreren
Optimaliseer workflows met DevOps.

Door statistieken zoals het percentage mislukte wijzigingen en de gemiddelde hersteltijd bij te houden, kun je trends identificeren waarmee je problemen vroegtijdig kunt detecteren. Dankzij deze proactieve aanpak kun je corrigerende maatregelen nemen en de impact op klanten beperken, wat betrouwbaarheid oplevert – nog een essentieel ingrediënt om op hoog kwaliteitsniveau op te schalen.

Tot slot helpt het gebruik van DevOps-statistieken je DevOps-team volwassener te maken door een cultuur van voortdurende verbetering te bevorderen. Feedbacklussen stimuleren leren en groei; er moet altijd ruimte zijn om met verschillende benaderingen te experimenteren.

Welke DevOps-statistieken ondersteunen bedrijfsgroei?

Bij het instellen van KPI's moeten de meeste statistieken binnen je team worden bekeken en gericht zijn op groei, in plaats van te worden vergeleken met andere bedrijven en groepen met een ander volwassenheidsniveau.

Een lage LTC kan bijvoorbeeld aantonen dat je team efficiënt werkt, maar als het tempo niet kan worden volgehouden, is het niet duurzaam en kan dit uiteindelijk de gebruikerservaring beïnvloeden. Deze statistiek moet in de loop van de tijd worden gemeten, in plaats van een KPI vast te stellen die overeenkomt met een goed presterend of zelfs elitair, volwassen DevOps-team. KPI's instellen om LTC maandelijks, per kwartaal of jaarlijks te verlagen, laat groei binnen je team en bedrijf zien.

CFR is een waardevolle maatstaf, omdat niet iedereen hetzelfde aantal fouten of problemen heeft. Door hier een percentage aan te koppelen, kunt u echter meten hoe succesvol uw implementaties zijn. Uw team heeft mogelijk zeer weinig fouten als het niet vaak wijzigingen uitbrengt, maar als elke release een probleem veroorzaakt, zal de CFR zeer hoog zijn. Als u CI/CD-praktijken volgt, ziet u mogelijk een groter aantal fouten, maar als uw CFR laag is, hebt u een voordeel omdat snelheid en kwaliteit samen groei ondersteunen. MTTR moet ook in de loop van de tijd worden gemeten om een gestage groei te waarborgen.

DORA ontdekte dat teams met alle prestatieniveaus op het gebied van ontwikkeling betere resultaten behaalden wanneer ze zich richtten op operationele prestaties. Dit kan betekenen dat u KPI's instelt voor incidentrapporten of openstaande tickets, de bedrijfstijd en beschikbaarheid van applicaties.

Een groot aantal openstaande tickets kan wijzen op een probleem met uw klanttevredenheid, maar streven naar een afname in de loop van de tijd weerspiegelt groei op dit gebied. U kunt dieper graven en respons- en wachtrijtijden meten om de verbetering van deze maatstaf te versnellen.

De enige maatstaf die ontwikkeling en operationele processen volledig combineert binnen een DevOps-team, is de cyclustijd. Dit biedt ruimte om een cultuur van feedback en groei op te bouwen. Naarmate andere maatstaven verbeteren en automatisering volwassener wordt, mag u verwachten dat de cyclustijd afneemt. Als uw klantenservice goed is en het aantal ontwikkelingsfouten laag, hebt u een winnende combinatie gevonden om uw bedrijf op te schalen.

Slotgedachten

Net als elke andere methodologie is DevOps alleen succesvol als het correct wordt geïmplementeerd. En u kunt het succes niet kennen voordat u weet hoe u DevOps-maatstaven gebruikt.

Natuurlijk brengt het implementeren van DevOps-maatstaven uitdagingen met zich mee. Het vereist een strategische mentaliteit, een samenwerkingsgerichte cultuur en toewijding aan voortdurende verbetering. De resultaten zijn echter geoptimaliseerde werkstromen en processen waarop u een solide basis kunt bouwen om uw bedrijf op te schalen.

Als u op de hoogte wilt blijven van nieuws en artikelen, schrijf u dan in voor onze nieuwsbrief!