DevOps metrieken uitgelegd: Hoe u uw ontwikkelingspijplijn kunt volgen en optimaliseren

Wij mensen vervagen graag grenzen, een van die pogingen is DevOps. Met DevOps in de SDLC-ring zijn de dingen anders geworden en wat is dat? Het bijhouden van sleutelfactoren zoals de prestaties, kwaliteit en snelheid van applicaties wordt een continu proces. Zonder deze metingen kan het moeilijk zijn om betrouwbare, datagestuurde beslissingen te nemen. Maar op welke schaal meten we prestaties? Daar komen metrics. DevOps-metrics bieden de inzichten die nodig zijn om aan te passen, te optimaliseren en uiteindelijk sneller betere software te leveren. Deze blog gaat over waarom DevOps-metrics belangrijk zijn. Het gaat ook over verschillende punten waar je aan moet denken als je ze gebruikt om beslissingen te nemen.

Waarom DevOps-metriek in de gaten houden?

Je kunt het volgende bereiken door DevOps-metrics in de gaten te houden:

• Onderzoek langetermijnpatronen met gegevens over waarneembaarheid.
• Configureer nuttige waarschuwingen met een sterk signaal en weinig ruis.
• Maak praktische dashboards om te helpen bij rapportage en planning.
• Maak haalbare SLA’s, SLO’s en SLI’s.
• Een interne opslagplaats creëren voor best practices in software engineering.

Het is goed om “datagestuurd” te zijn, maar het risico bestaat dat je overweldigd wordt door analyses. Om waarde aan te tonen, heb je maar een paar maatregelen nodig.

Vier essentiële DevOps meetgegevens om te controleren

De vier DevOps-metrics staan ook bekend onder de naam ‘The Four Keys’ en dienen als benchmark voor het evalueren van de prestaties van een DevOps-team, variërend van laag tot elite. Een “lage” score duidt op slechte prestaties, terwijl “elite” staat voor uitzonderlijke vooruitgang in de richting van het bereiken van DevOps-doelen. Vier primaire metingen, onderverdeeld in snelheidsmetingen (DF en CLT) en stabiliteitsmetingen (MTTR en CFR), zijn geïdentificeerd door Google’s DevOps Research and Assessment (DORA) team als indicatoren voor DevOps prestaties:

DORA Metrics indicatoren van DevOps-prestaties:

1. Inzetfrequentie (DF)
2. Doorlooptijd verandering (CLT)
3. Gemiddelde hersteltijd (MTTR)
4. Verandering storingspercentage (CFR)

Frequentere implementaties, kortere doorlooptijden voor wijzigingen, minder storingen en sneller herstel van de service zijn allemaal kenmerken van goed presterende teams. Het omgekeerde geldt voor slecht presterende teams, wat resulteert in inefficiëntie en een slechte klantervaring.

Laten we elke metriek eens nader bekijken.

1. Inzetfrequentie

De frequentie waarmee code-updates naar staging of productie worden geduwd, wordt gemeten door de deployment-frequentie. De productiviteit van DevOps-teams, reactietijd, vaardigheden van ontwikkelaars, teamcohesie en effectiviteit van tools kunnen allemaal direct of indirect worden gemeten. Effectieve teams zijn in staat om aanpassingen door te voeren als dat nodig is en doen dat vaak gedurende de dag. Omgekeerd beperken slecht presterende teams zich soms tot wekelijkse of maandelijkse implementaties. De inzetfrequentie wordt door elk bedrijf anders berekend. Je kunt bijvoorbeeld de inzetfrequentie berekenen voor succesvolle pijplijn runs. De meting kan echter ook veranderen, afhankelijk van hoe “deployment” wordt gedefinieerd. Het uitrollen van elk klein Pull Request of code-update zal resulteren in een hoge frequentie. De dingen beginnen er echter een beetje anders uit te zien als je deployment gepland is om na een bepaalde tijd uit te voeren. Hoewel bijvoorbeeld het overschakelen van wekelijkse naar dagelijkse deployments laat zien hoe continuous deployment je ontwikkelproces kan verbeteren, kan het alleen vertrouwen op deze DevOps indicator leiden tot onjuiste aannames. Als je bijvoorbeeld je dagelijkse implementaties hebt verhoogd van drie naar 3,3 ten opzichte van het vorige kwartaal, ben je technisch gezien 10% meer “succesvol”, maar dat is geen goede indicator van succes. Om de algehele ontwikkeling te beoordelen, zou je aanvullende meetgegevens in overweging moeten nemen.

Lees ook: 6 redenen waarom u DevOps as a Service nodig hebt

2. Doorlooptijd wijziging

De tijd die een codewijziging nodig heeft om van gecommit naar geïmplementeerd te gaan wordt de “change lead time” genoemd. In essentie stelt het de vraag: “Hoe snel kunnen we een regel code wijzigen en deze operationeel hebben in productie?”. Terwijl een gemiddeld of laag presterend team de gemiddelde doorlooptijd meet in dagen, weken of zelfs maanden, berekent een goed presterend team de gemiddelde doorlooptijd meestal in uren. Er zijn prestatiebeperkingen in je softwareontwikkelings- of implementatieproces als de doorlooptijd voor wijzigingen erg lang is. Door de doorlooptijd van wijzigingen te verkorten, kunt u beter inspelen op veranderende behoeften. Het werken in kleine batches, het automatiseren van tests en het gebruik van trunk-gebaseerde ontwikkeling kunnen allemaal helpen om de doorlooptijd van wijzigingen te verkorten. Het gemiddelde verschil tussen de tijd die het kost om pull requests aan te maken en wanneer ze worden samengevoegd naar de master branch wordt gebruikt om de doorlooptijd van wijzigingen te bepalen. De gemiddelde doorlooptijd voor wijzigingen zou 90 gedeeld door 10 zijn als je 10 wijzigingen in een maand hebt en het totale aantal dagen van vastleggen tot uitrollen voor alle wijzigingen 90 is. Dit zou betekenen dat elke wijziging gemiddeld 9 dagen in beslag neemt. Het kan maanden duren om de behoeften en vooruitzichten van het product te identificeren, maar het kan slechts een paar dagen duren om de code vast te leggen. Hoewel de doorlooptijd voor wijzigingen een waardevolle statistiek is, is het daarom naïef om deze alleen te gebruiken.

3. MTTR (gemiddelde hersteltijd)

De snelheid waarmee service-uitval of complete storingen worden gedetecteerd en verholpen, wordt gemeten aan de hand van je gemiddelde hersteltijd. Terwijl slecht presterende teams soms wel een week nodig hebben om te herstellen van een systeemstoring, herstellen goed presterende teams vaak in minder dan een uur. De gemiddelde tijd die nodig is om een probleem als opgelost af te sluiten is hoe je je MTTR bepaalt. Deze meting kan worden beïnvloed door monitoring, geautomatiseerd testen en effectief reageren op problemen. Omdat statistisch ontwerp de betekenis op de een of andere manier kan beïnvloeden, is de waarde van MTTR de afgelopen jaren vaak in twijfel getrokken. Daarnaast kunnen gemiddelden misleidend zijn en het werkelijke gedrag van systemen verhullen. Probeer de meting daarom te beschouwen in combinatie met andere metingen, hoewel je hem niet volledig moet negeren.

Ontdek onze oplossingen: DevOps als een service

4. Faalpercentage wijzigen

Het percentage codewijzigingen of implementaties waarvoor hotfixes nodig zijn na productie staat bekend als het mislukkingspercentage van wijzigingen. Om het simpel te zeggen: “Hoe vaak is een wijziging die je hebt gemaakt echt ‘succesvol’?”. Naarmate een defect vordert in de pijplijn, van het falen van een pre-commit unit test tot het veroorzaken van een productieuitval, nemen de kosten of schade toe. De statistieken worden aanzienlijk moeilijker te meten wanneer een stadium in de pijplijn faalt, wat betekent dat alle voorgaande stadia niet in staat waren om het probleem te identificeren. Falen kan breed worden gedefinieerd als een fout of probleem dat problemen veroorzaakt voor klanten na een implementatie in productie. Test-geïdentificeerde problemen die worden opgelost voor de uitrol worden niet meegenomen in deze belangrijke maatstaf. Faalpercentages voor wijzigingen kunnen oplopen tot 60% voor slecht presterende teams, terwijl ze minder dan 15% zijn voor goed presterende teams. Het percentage mislukte wijzigingen kan worden verlaagd door dezelfde strategieën die de doorlooptijd verkorten, zoals ontwikkeling op basis van basislijnen, geautomatiseerd testen en werken in kleine batches.

Hoe bereken je DevOps-metriek?

Het volgende advies zal je helpen om het meeste uit DevOps-metrics te halen:

• Basislijnen vaststellen: Voordat je echt je vooruitgang kunt volgen of overwinningen kunt vieren, moet je weten waar je begint. Het is vergelijkbaar met kijken naar het scorebord voordat de wedstrijd begint.
• Vermijd dat metingen doelen worden: “Wanneer een meting een doel wordt, is het geen goede meting meer,” volgens de Wet van Goodhart. Je loopt het risico uit het oog te verliezen wat belangrijk is voor je DevOps-succes als je gefixeerd raakt op één enkel cijfer.
• Begin klein: je kunt de concurrentie voorblijven door snel nieuwe functies toe te voegen. Maak wijzigingen of implementaties in kleinere, makkelijker te beheren batches. Kleinere wijzigingen zijn makkelijker te begrijpen, gaan sneller door de deployment pijplijn en zijn makkelijker ongedaan te maken. Fouten herstellen gaat ook sneller.
• Wees op je hoede voor eenvoud: Het kan verleidelijk zijn om je te concentreren op één enkele, gemakkelijk te begrijpen metriek, maar de realiteit is dat geen enkel cijfer het complete plaatje kan weergeven. DevOps is meer dan een statistiek; het is een manier van denken en een reis rond softwareontwikkeling.
• Maak eerlijke vergelijkingen: Metingen komen misschien niet helemaal overeen als je statistieken van twee afzonderlijke projecten of zelfs twee verschillende periodes vergelijkt. Situaties verschillen en context is cruciaal.
• Kijk beter: Kies statistieken die duidelijk waarde aantonen voor je team en je projecten, zelfs als ze iets meer werk vergen om te controleren. Het is eenvoudig om te meten wat recht voor je staat.
• Bestudeer de opmerkingen van klanten: Gebruikers kunnen nog steeds problemen hebben, zelfs als je implementatie vlot verloopt. Je kunt de tevredenheid van gebruikers niet bepalen met DORA-gegevens. Om erachter te komen wat er moet worden opgelost, moet je kijken wat mensen zeggen. Dit alles valt onder waardestroombeheer.
• Zoek naar trends in problemen: Komen dezelfde soorten problemen steeds terug? Dit kan duiden op ernstigere problemen die aandacht vereisen.
• Let op bijna-ongelukken: Niet alleen de problemen die zich voordeden, maar ook de problemen die zich bijna voordeden. Daar kun je veel van leren over hoe je in de toekomst problemen met softwarelevering kunt voorkomen.
• Bewaak kostenbesparingen: Demonstreer hoe DevOps kosten verlaagt of verdere uitgaven voorkomt. Het budget is hierdoor gerechtvaardigd.
• Verminder downtime: Je wilt dat je systeem altijd operationeel blijft omdat downtime de reputatie van je bedrijf kan schaden en kan leiden tot inkomstenverlies. Doe er alles aan om dit te voorkomen.

Hoe worden DevOps-metrieken geïnterpreteerd?

Je moet scherpzinnig zijn met de statistieken die je verzamelt als je DevOps-metrics gebruikt. Als je niet waakzaam bent, kunnen gemiddelden je gemakkelijk misleiden. Net zoals één uitschieter de perceptie kan vertekenen, kan alleen vertrouwen op gemiddelden om conclusies te trekken de ware verdeling van gegevens verdoezelen. Denk erover om de uitschieters uit je gegevens te verwijderen. Je perceptie van gewone prestaties kan vertekend zijn door deze extreme cijfers. Het zou bijvoorbeeld niet de norm moeten zijn voor je gebruikelijke implementatietijd als één implementatie veel langer duurt dan de rest vanwege onverwachte problemen. Data bucketing kan ook nuttig zijn. Hierbij worden verwante gegevenstypen gegroepeerd, zodat patronen binnen die groepen kunnen worden onderzocht. Houd bijvoorbeeld bugpatches en implementaties van nieuwe functies uit elkaar bij het berekenen van doorlooptijden. Zo kun je bepalen of en waarom het ene type routinematig langer duurt dan het andere. Last, not the least: trek de conclusies die je trekt uit je gegevens voortdurend in twijfel. Welk verhaal vertellen de feiten je? Wat zou er weggelaten kunnen worden? Duidt een drastische verbetering in het mislukkingspercentage van wijzigingen er bijvoorbeeld op dat je implementaties inderdaad betrouwbaarder zijn, of implementeer je minder vaak, waardoor de kans op mislukkingen afneemt? Door meer tijd en energie te investeren in de vroege fasen van de productontwikkeling, wordt de kans op problemen tijdens de implementatie kleiner. Zie het als het repareren van lekkages aan een boot wanneer deze nog aangemeerd ligt in plaats van op zee. Deze proactieve strategie garandeert dat je product betrouwbaar is en sneller wordt gebruikt, terwijl je ook tijd bespaart. Wees je er echter van bewust dat je DevOps-team niet elk gebied van de prestaties van je product direct kan beïnvloeden. Ondanks hun waarde kunnen DORA-metingen af en toe elementen onthullen die buiten de directe controle vallen, zoals algemene bedrijfsprocedures of besluitvormingsschema’s. Je doorlooptijden zouden bijvoorbeeld onvermijdelijk toenemen als je bedrijf een beleid had dat grondige veiligheidscontroles voorschrijft vóór implementatie.

Bekijk: Zuci slaat de handen ineen met de wereldwijde cloudgebaseerde testplatformprovider Sauce Labs

Het stellen van redelijke doelen wordt geholpen door te begrijpen wat de grenzen zijn van wat je direct kunt beïnvloeden. Je kunt bijvoorbeeld proberen andere aspecten van je implementatieproces te stroomlijnen om de verloren tijd goed te maken, ook al kun je die door het bedrijf opgelegde beveiligingscontroles misschien niet versnellen. DevOps Metrics beter meten DORA biedt een nuttig raamwerk om de ontwikkeling en het beheer van technische diensten te verbeteren, vooral als je overweegt om over te stappen op Kubernetes. Het moet echter worden aangepast aan je situatie, worden gebruikt in combinatie met andere statistieken, worden gezien als een enkel moment in de tijd en niet worden gemanipuleerd. Het overkoepelende doel van deze cruciale DevOps KPI’s is het bepalen van de prestaties van de pijplijn en het identificeren van gebieden die voor verbetering vatbaar zijn.