Artikelen
Tutorials
Interactieve handleidingen
DevOps-statistieken
Waarom, waarmee en hoe je succes meet in DevOps
TOM HALL
DevOps-vertegenwoordiger en -professional
Het oude gezegde 'meten is weten' geldt zowel voor DevOps als voor elke andere werkwijze. Om de belofte na te komen van DevOps (snellere levering van producten van hogere kwaliteit) moeten teams talloze statistieken verzamelen, analyseren en meten. Deze DevOps-statistieken bieden de essentiële gegevens die DevOps-teams nodig hebben om inzicht te krijgen in en controle te hebben over hun ontwikkelingspipeline.
Wat zijn DevOps-statistieken?
DevOps-statistieken zijn gegevenspunten die direct de prestaties van een DevOps-softwarepipeline in kaart brengen en helpen om eventuele knelpunten in het proces snel te identificeren en weg te halen. Deze statistieken kunnen worden gebruikt om zowel technische capaciteiten als teamprocessen bij te houden.
DevOps richt zich voornamelijk op het vervagen van de grens tussen ontwikkelings- en operationsteams, waardoor de samenwerking tussen ontwikkelaars en systeembeheerders beter wordt. DevOps-teams kunnen aan de hand van statistieken coöperatieve workflows meten en beoordelen, en de voortgang bijhouden van hoogwaardige doelen, waaronder verbeterde kwaliteit, snellere releasecycli en verbeterde applicatieprestaties.
Vier kritieke DevOps-statistieken
Hoewel er talloze statistieken worden gebruikt om DevOps-prestaties te meten, volgen hieronder vier belangrijke statistieken die elk DevOps-team zou moeten meten.
1. Doorlooptijd voor veranderingen
Een van de belangrijke DevOps-statistieken die moet worden bijgehouden, is de doorlooptijd voor wijzigingen. De doorlooptijd voor wijzigingen is iets anders dan cyclustijd (hieronder besproken) en betreft de tijdsduur tussen het moment dat een codewijziging wordt vastgelegd in de trunkbranch en wanneer deze geïmplementeerd kan worden. Bijvoorbeeld wanneer de code is geslaagd voor alle noodzakelijke tests vóór de release.
2. Foutpercentage van veranderingen
Het foutpercentage van wijzigingen is het percentage codewijzigingen waarvoor hot fixes of andere hersteloplossingen na productie nodig zijn. Fouten die worden opgevangen door testen en worden opgelost voordat code wordt geïmplementeerd, worden niet gemeten.
3. Implementatiefrequentie
Inzicht in hoe vaak nieuwe code in productie wordt geïmplementeerd, is van cruciaal belang om het succes van DevOps te begrijpen. Veel professionals gebruiken de term 'levering' voor codewijzigingen die worden gereleased in een testomgeving vóór productie, en 'implementatie' als verwijzing naar codewijzigingen die gereleased worden in de productie.
4. Gemiddelde tijd tot herstel
De gemiddelde oplossingstijd meet hoelang de oplossing van een gedeeltelijke serviceonderbreking of totale storing duurt. Dit is een belangrijke statistiek om bij te houden, ongeacht of de onderbreking het gevolg is van een recente implementatie of een geïsoleerde systeemstoring.
Oplossing bekijken
Tools voor het beste DevOps-team
gerelateerd materiaal
Het belang van teamstructuur in DevOps
DevOps-statistieken meten, gebruiken en verbeteren
Net als andere elementen van de DevOps-levenscyclus is bij DevOps-statistieken een cultuur van continue verbetering erg belangrijk. Goed presterende teams hebben als kenmerk dat ze snel feedback krijgen in elke ontwikkelingsfase en de vaardigheden en het gezag hebben om feedback te implementeren. In het DevOps-boek 'Accelerate' merken de auteurs op dat de vier kernstatistieken hierboven worden ondersteund door 24 capaciteiten waar goed presterende softwareteams gebruik van maken. We gaan hieronder dieper in op het merendeel van deze capaciteiten (CI/CD, testautomatisering, werken in kleine batches, controle en continu leren), maar we raden ook aan om 'Accelerate' te lezen voor meer informatie over het onderzoek dat deze werkwijzen ondersteunt.
Doorlooptijd voor wijzigingen
Goed presterende teams meten doorlooptijden doorgaans in uren, waarbij gemiddeld en laag presterende teams doorlooptijden meten in dagen, weken of zelfs maanden.
Testautomatisering, trunk-gebaseerde ontwikkeling en werk in kleine batches zijn belangrijke elementen om de doorlooptijd te verbeteren. Deze werkwijzen stellen ontwikkelaars in staat om snel feedback te krijgen over de kwaliteit van de code, zodat ze eventuele fouten kunnen identificeren en verhelpen. Lange doorlooptijden zijn vrijwel onvermijdelijk als ontwikkelaars werken aan grote wijzigingen die op afzonderlijke branches staan en vertrouwen op handmatige tests voor kwaliteitscontrole.
Foutpercentage van wijzigingen
Goed presterende teams hebben een foutpercentage van wijzigingen die tussen de 0 en 15 procent ligt.
Dezelfde werkwijzen die zorgen voor kortere doorlooptijden,- testautomatisering, trunk-gebaseerde ontwikkeling en werk in kleine batches, hangen samen met een verlaging van het foutpercentage van wijzigingen. Door al deze werkwijzen kunnen fouten veel gemakkelijker geïdentificeerd en verholpen worden.
Het bijhouden en rapporteren van foutpercentages van wijzigingen is niet alleen belangrijk voor het identificeren en oplossen van bugs, maar ook om ervoor te zorgen dat nieuwe codereleases voldoen aan de beveiligingsvereisten.
Implementatiefrequentie
Goed presterende teams kunnen wijzigingen op aanvraag implementeren en doen dat meerdere keren per dag. Minder goed presterende teams zijn vaak beperkt tot een wekelijkse of maandelijkse implementatie.
Implementatie op aanvraag vereist een geautomatiseerde implementatiepipeline die geautomatiseerde test- en feedbackmechanismen bevat, waarnaar in de vorige secties wordt verwezen, en de behoefte aan menselijk handelen vermindert.
Gemiddelde oplossingstijd
Goed presterende teams herstellen snel van systeemstoringen, meestal binnen een uur, terwijl minder goed presterende teams hier tot een week voor nodig hebben.
De duur van de oplossingstijd na een storing hangt af van de mogelijkheid om snel een storing te identificeren, en een oplossing te implementeren of eventuele wijzigingen die tot de storing hebben geleid, terug te draaien. Dit gebeurt meestal door continue bewaking van het systeem en door het operationspersoneel op de hoogte te brengen bij een storing. Het operationspersoneel moet over de nodige processen, tools en rechten beschikken om incidenten op te lossen.
De focus op de gemiddelde oplossingstijd is een verschuiving van de historische werkwijze van de focus op de gemiddelde tijd tussen storingen. Deze is afgestemd op de toegenomen complexiteit van moderne applicaties en de verhoogde verwachting van storingen. Dit versterkt ook het continu leren en verbeteren. In plaats van te wachten tot de implementatie 'perfect' is om fouten te voorkomen (en dus de oude gemiddelde tijd tussen storingen opnieuw in te stellen), implementeren teams voortdurend. In plaats van met de vinger te wijzen wanneer een 'perfecte' gemiddelde tijd tussen storingen is verpest, stimuleert de gemiddelde oplossingstijd retrospectieven om teams te helpen hun upstreamprocessen en tools te verbeteren.
Andere gerelateerde statistieken
Een andere relevante statistiek is de cyclustijd, dit is de tijd die een team aan een item besteedt totdat het klaar is voor levering. In de ontwikkelingswereld is de cyclustijd de tijd vanaf het moment dat ontwikkelaars een commit maken tot het moment dat deze wordt geïmplementeerd voor de productie. Deze belangrijke DevOps-statistiek helpt projectleiders en engineeringmanagers beter inzicht te krijgen in wat goed werkt in de ontwikkelingspipeline. Hierdoor kunnen ze hun werk beter afstemmen op de verwachtingen van belanghebbenden en klanten, zodat hun team sneller kan leveren.
Met rapporten voor cyclustijden kunnen projectleiders een basislijn vaststellen voor de ontwikkelingspipeline die kan worden gebruikt om toekomstige processen te evalueren. Wanneer teams cyclustijden optimaliseren, hebben ontwikkelaars doorgaans minder werk in uitvoering en minder inefficiënte workflows.
Bij Lean productmanagement ligt de focus op het in kaart brengen van waardestromen, wat een visualisatie is van een product- of functieconcept tot de levering. DevOps-statistieken bevatten verschillende essentiële gegevenspunten voor het effectief in kaart brengen en beheer van waardestromen, maar moeten worden aangevuld met andere bedrijfs- en productstatistieken voor een goede end-to-end evaluatie. Zo geven sprint burndown-grafieken inzicht in de effectiviteit van schattings- en planningsprocessen, terwijl een Net Promoter Score aangeeft of de uiteindelijke levering voldoet aan de behoeften van de klant.
Conclusie...
Continue verbetering is een kernprincipe van teams die DevOps implementeren. Door prestaties te meten en bij te houden zoals de doorlooptijd voor wijzigingen, het foutpercentage van wijzigingen, de implementatiefrequentie en gemiddelde oplossingstijd kunnen teams sneller werken en betere kwaliteit leveren.
Open DevOps van Atlassian biedt alles wat teams nodig hebben om software te ontwikkelen en te gebruiken. Teams kunnen de DevOps-toolchain bouwen die voor hen werkt, dankzij integraties met toonaangevende leveranciers en marketplace-apps. Probeer het nu uit.
Deel dit artikel
Volgend onderwerp
Aanbevolen artikelen
Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.
DevOps-community
DevOps-leertraject
