DevOps-statistieken gebruiken om uw bedrijf op te schalen
Als technologieleider of bedrijfseigenaar begrijpt u dat vooroplopen op de concurrentie meer vereist dan alleen ambitie — het vraagt om datagedreven besluitvorming. Daar komen DevOps-tools om de hoek kijken.
Met slechts een beetje data kunt u de teamprestaties, procesefficiëntie en klanttevredenheid verbeteren.
Dat wil niet zeggen dat het eenvoudig is. Het implementeren van DevOps-meetgegevens brengt 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.
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.
Have an account? Log In
In dit artikel bespreken we belangrijke DevOps-meetgegevens en hoe u deze kunt meten om relevante prestatie-KPI's vast te stellen. Vervolgens ontdekken we hoe u deze meetgegevens kunt gebruiken om uw bedrijf effectief op te schalen.
De 5 pijlers van procesvolwassenheid
DevOps combineert en automatiseert processen, werkwijzen en tools die worden gebruikt bij softwareontwikkeling en -beheer om de kwaliteit en snelheid van ontwikkelingslevenscycli te verhogen.
De implementatie van bedrijfsprocessen kent vijf belangrijke pijlers, die bekendstaan als het Capability Maturity Model (CMM). Dit model richt zich op vijf volwassenheidsniveaus voor de implementatie en voortdurende verbetering van service- of productontwikkeling binnen uw bedrijfsmodel.
De vijf pijlers kennen veel variaties, maar initieel, herhaalbaar, gedefinieerd, capabel en efficiënt zijn de oorspronkelijke fasen. Een alternatief is cultuur, automatisering, meting, delen en feedback. Elke fase heeft hetzelfde concept; alleen de benamingen zijn in de loop der tijd veranderd.
Hier volgt een voorbeeld van de vijf pijlers van procesvolwassenheid, met een korte beschrijving van elke pijler:
Er zijn meerdere meetgegevens en raamwerken die kunnen worden gebruikt om het succes van DevOps binnen uw team te implementeren en te meten. Laten we deze in dit gedeelte bekijken.
Op principes gebaseerde DevOps-raamwerken
Er zijn drie belangrijke op principes gebaseerde raamwerken binnen DevOps. Op principes gebaseerd verwijst naar een praktische aanpak met brede richtlijnen, in tegenstelling tot een op regels gebaseerde aanpak met voorgeschreven stappen.
Het Accelerate-raamwerk
De auteurs dr. Nicole Forsgren, Jez Humble en Gene Kim onderzoeken in hun boek ‘Accelerate: De wetenschap van lean software en DevOps: high-performance technologieorganisaties opbouwen en opschalen’ wat succesvolle technologiebedrijven onderscheidt.
In dit boek vindt het Accelerate DevOps-raamwerk zijn oorsprong. Het richt zich op technische werkwijzen en managementpraktijken binnen DevOps-teams van succesvolle technologieorganisaties. U kunt het zien als een onderzoek naar de beste werkwijzen van een DevOps-team.
De drie belangrijkste aandachtsgebieden binnen technische werkwijzen zijn:
- Continue oplevering: Continue oplevering omvat gebieden zoals versiebeheer, continue integratie, implementatie- en testautomatisering en beheer van testgegevens. Hoewel continue oplevering op zichzelf een principe is, wordt het binnen het Accelerate-raamwerk als overkoepelende term gebruikt. De reden voor deze aanpak is dat DevOps-teams die op het hoogste niveau presteren deze elementen gelijktijdig uitvoeren in plaats van los van elkaar.
- Architectuur: Er is vastgesteld dat succesvolle DevOps-teams de meeste tests uitvoeren zonder dat een geïntegreerde omgeving nodig is, nieuwe applicaties onafhankelijk implementeren van de applicaties waarvan ze afhankelijk zijn en testen en implementeerbaarheid belangrijker vinden dan de nieuwste technologie.
- Product en proces: Tijdens de ontwikkeling wordt regelmatig feedback van klanten gevraagd. Er wordt in kleine batches gewerkt, geëxperimenteerd en voortdurend geoptimaliseerd. Dit bleek waarde te leveren, bugs snel op te lossen en een feedbacklus met klanten mogelijk te maken.
Er zijn twee belangrijke aandachtsgebieden binnen managementpraktijken. Dit zijn:
- Lean management en monitoring: Uit het Accelerate-raamwerk bleek dat minimale goedkeuringsprocessen de prestaties van softwareoplevering sterker verbeteren dan processen waarbij teams goedkeuring van derden nodig hebben. Ook het monitoren van capaciteiten met limieten voor werk in uitvoering en visuele tools voor projectmanagement verbetert de prestaties.
- Cultureel: Het raamwerk benadrukt sterk het belang van het creëren van de juiste werkomgeving voor betere DevOps-prestaties. Samenwerking en leren zijn hiervoor twee belangrijke ingrediënten, in combinatie met een ondersteunende en stimulerende benadering van teamwork. Deze teams moeten worden ondersteund door transformationeel leiderschap. Mensen in deze positie zijn doorgaans motiverend en intellectueel stimulerend en erkennen de prestaties van hun team.
‘Doorlooptijd voor wijzigingen’ is een DevOps-metriek die we hieronder verder zullen verkennen. Hiermee wordt gemeten hoe lang een codewijziging duurt vanaf het moment waarop een ontwikkelaar deze vastlegt totdat deze succesvol in productie is geïmplementeerd. Door deze metriek binnen het Accelerate-raamwerk toe te passen, kunt u de snelheid en efficiëntie van uw softwareleveringsproces meten en verbeteren, wat leidt tot snellere en betrouwbaardere implementaties.
Het raamwerk van de Drie Wegen
Het raamwerk van de Drie Wegen werd geïntroduceerd in Het Phoenix Project, geschreven door Gene Kim, Kevin Behr en George Spafford, en komt ook voor in Het DevOps-handboek. Het verbetert de DevOps-prestaties door de nadruk te leggen op de principes van doorstroming, feedback en continu leren.
Hier volgt een overzicht van het raamwerk van de Drie Wegen:
- De eerste weg: denken in doorstroming:
De eerste weg bestaat uit het bereiken van een ononderbroken werkstroom van ontwikkeling naar operations en het snel en betrouwbaar leveren van waarde aan klanten.
‘Doorlooptijd naar productie’ is een metriek die u hier kunt gebruiken door de tijd te meten die een codewijziging nodig heeft om van de eerste vastlegging naar implementatie in de productieomgeving te gaan. Streef ernaar de doorlooptijd te verkorten door de leveringspijplijn te optimaliseren, processen te automatiseren en handmatige interventies tot een minimum te beperken.
- De tweede weg: feedbacklussen versterken
De tweede weg zorgt gedurende het hele softwareleveringsproces voor snelle en effectieve feedbacklussen, zodat continu leren, verbeteren en kwaliteitsborging mogelijk worden.
Bij de metriek ‘gemiddelde detectietijd (MTTD)’ berekent u de gemiddelde tijd die nodig is om een probleem of afwijking te detecteren nadat een codewijziging in productie is geïmplementeerd. Richt u op het verkorten van de MTTD door monitoring, waarschuwingssystemen en feedbacklussen te verbeteren, zodat problemen snel kunnen worden geïdentificeerd en aangepakt.
- De derde weg: een cultuur van voortdurend experimenteren en leren
De derde en laatste weg stimuleert een cultuur van continu leren, experimenteren en het nemen van risico’s om innovatie, aanpassingsvermogen en organisatorische groei te bevorderen.
De metriek ‘percentage mislukte wijzigingen’ is hier ideaal om toe te passen. U houdt bij welk percentage van de codewijzigingen na implementatie tot fouten of problemen leidt. Creëer een experimenteercultuur door een veilige omgeving voor tests te creëren, van fouten te leren en processen voortdurend te verbeteren om het percentage mislukte wijzigingen te verlagen.
Het CALMS-raamwerk
Het CALMS-raamwerk omvat de principes cultuur, automatisering, lean, meting en delen. Het is een ideale optie voor teams die willen overstappen op een DevOps-benadering van softwareontwikkeling en willen voorkomen dat ontwikkelings- en operationele teams in afzonderlijke silo’s werken.
U heeft al gehoord van de bedenker van het CALMS-raamwerk, omdat hij Accelerate en Het DevOps-handboek mede heeft geschreven, waarin respectievelijk het Accelerate-raamwerk en het raamwerk van de Drie Wegen worden beschreven. Jez Humble ontwikkelde het CALMS-raamwerk als een geschiktheidsbeoordeling om vast te stellen of bedrijven goed zijn ingericht en klaar zijn om DevOps-processen te implementeren.
Net als CMM, maar specifiek voor het beheer van DevOps, kunt u het CALMS-raamwerk gebruiken om te testen of uw bedrijf er klaar voor is.
Dit zijn de vijf pijlers die u moet volgen:
- Cultuur: Uw ontwikkelings- en operationele teams hebben binnen hun eigen groepen gewerkt, elk met hun eigen processen en communicatiestijlen. U moet een gevoel van gedeelde verantwoordelijkheid stimuleren om een DevOps-klare cultuur te waarborgen.
- Automatisering: DevOps draait om het stroomlijnen van processen, snelheid en efficiëntie. De sleutel? Automatisering. Uw teams moeten zich voorbereiden op het automatiseren van handmatige taken en procedures waar dat mogelijk is. Deze stap ondersteunt het voortdurend bouwen, testen, implementeren en monitoren van softwarereleases die samen de DevOps-levenscyclus vormen.
- Lean: De principes van de leanmethodologie, een benadering van bedrijfs- en projectmanagement, worden gebruikt om verspilling te minimaliseren en waardestromen te optimaliseren. U moet realistische werkcapaciteiten aanhouden en projectstatussen visualiseren om processen te versnellen.
- Meting: Uw bedrijf is mogelijk klaar om DevOps uit te rollen als u zover bent gekomen en uw teams zich inzetten voor het verzamelen en analyseren van gegevens om processen te verbeteren.
- Delen: Naast een cultuur van gedeelde verantwoordelijkheid moeten uw teams openstaan voor het delen van gegevens en informatie en daartoe bereid zijn, zodat iedereen dezelfde gedeelde doelen nastreeft en er geen concurrentie ontstaat. Dit laatste beoordelingspunt zorgt voor soepele overdrachten en snelle groei.
Uitdagingen bij de implementatie van DevOps
Een van de grootste uitdagingen bij het implementeren van DevOps is de weerstand tegen cultuurverandering. Je hebt twee teams, elk met hun eigen processen, tools en communicatiestijlen. Het samenvoegen ervan tot één hechte eenheid met gedeelde doelen, verantwoordelijkheden en meetwaarden is een ingrijpende transformatie. Het is van cruciaal belang om het moreel hoog te houden en elke stap van het implementatieproces transparant aan te pakken om ervoor te zorgen dat alles soepel verloopt. Er moet ook rekening worden gehouden met de kosten van nieuwe tools en methoden.
Als je team liever regelgebaseerde frameworks volgt, kan het een behoorlijke omschakeling zijn om met principegebaseerde frameworks te gaan werken. Het tempo ligt hoog en het framework evolueert vaak mee met het team, waardoor het complex kan zijn om ermee om te gaan voor medewerkers die jarenlang traditionele benaderingen hebben gebruikt of voor nieuwe teamleden die hun plek moeten vinden in deze dynamische omgeving.
Tot slot kan de continue werkstroom verschillende kwetsbaarheden veroorzaken, doordat software-releases worden uitgerold zonder gegevensversleuteling of authenticatie en doordat bufferoverflows kunnen ontstaan. Hierdoor kunnen DevOps-teams het risico lopen op beveiligingsinbreuken. Daarom is het essentieel om de processen hieromheen aan te scherpen terwijl je DevOps-team volwassener wordt. Dit is ook de reden waarom de implementatie pas moet beginnen nadat het CALMS-framework is gebruikt om te beoordelen of je er klaar voor bent.
Waarom zijn DevOps-meetwaarden belangrijk?
Zoals hierboven is vastgesteld, kunnen gedeelde doelen en meetwaarden een uitdaging vormen voor teams die DevOps binnen een bedrijf uitrollen. Zonder DevOps-meetwaarden zouden er geen tests of metingen plaatsvinden en zouden er geen verbeteringen in de ontwikkeling zijn. Het zouden slechts herhalingen van dezelfde software zijn, gebaseerd op vermoedens en ideeën, waarna deze in het niets worden gelanceerd en vervolgens iets nieuws wordt geprobeerd. Zonder feedback of meetwaarden voor productsucces om te begrijpen hoe iets presteert, is er geen richting.
Financiële afdelingen willen bijvoorbeeld de kosten zo laag mogelijk houden, terwijl ontwikkelaars de prestaties zo hoog mogelijk willen houden. Deze twee doelen sluiten mogelijk niet op elkaar aan, tenzij de risico’s zijn beoordeeld en de teams elkaars doelstellingen begrijpen.
Wanneer je ontwikkelaars ervoor kunnen kiezen om een onvolledig product uit te brengen en de problemen later op te lossen, leidt de kostenimpact hiervan tot technische schuld. Het implementeren van DevOps kan de doelen en strategieën van beide teams op elkaar afstemmen, en je kunt je ontwikkelaars helpen de kostenimpact van hun technische beslissingen te begrijpen.
Dit is slechts een klein onderdeel van DevOps en van het belang van gedeelde meetwaarden.
DevOps-meetwaarden begrijpen
DevOps implementeren en principegebaseerde frameworks begrijpen is één ding, maar met DevOps-meetwaarden begin je de voordelen van deze samenwerkingsgerichte benadering van de levenscyclus van softwareontwikkeling echt te zien. Zoals bij de meeste bedrijfsstrategieën zijn er eindeloos veel meetwaarden die je kunt kiezen om groei te meten, afhankelijk van je sector, doelgroep en doelen.
Het DevOps Research and Assessment-team (DORA) van Google Cloud is het langstlopende onderzoeksteam in zijn soort. Aanvankelijk vonden zij vier belangrijke meetwaarden om de prestaties van de ‘elite’ binnen DevOps te meten. Sindsdien is er echter een vijfde belangrijke meetwaarde aan de mix toegevoegd, en hun clusteranalyse onderscheidt slechts drie niveaus van DevOps-teams: hoog, gemiddeld en laag, waarbij ‘elite’ tot het verleden behoort.
De 4 belangrijkste DORA-meetwaarden
Hier volgt een nadere blik op de vier DORA-meetwaarden:
1. Implementatiefrequentie (DF)
DF meet hoe vaak je succesvol naar productie uitrolt. Deze meetwaarde draait om consistentie en is een uitstekende indicatie van het behalen van doelen.
Teams in de categorie ‘elite’ zouden meerdere keren per dag consistent naar productie uitrollen, 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 procesblokkades, knelpunten of complexe projecten die aandacht vereisen aan het licht komen. Grotere teams geven er wellicht de voorkeur aan om met regelmatige tussenpozen uit te rollen door Agile-release treinen op te zetten; dit helpt de overweldiging door een extreem tempo en veel mensen te verminderen.
2. Doorlooptijd voor wijzigingen (LTC)
LTC verwijst naar de tijd die nodig is voordat een commit in productie terechtkomt. Deze meetwaarde is een goede indicator van de reactiesnelheid en wendbaarheid van een team, omdat wordt gemeten hoe snel het kan inspelen op de behoeften en eisen van gebruikers.
De verouderde ‘elite’-standaard zou voor LTC streven naar minder dan één dag, terwijl teams met lagere prestaties er meer dan zes maanden over kunnen doen. Presteren aan de onderkant van de schaal voor LTC komt waarschijnlijk door inefficiënte processen.
Je kunt deze metriek verbeteren door automatiseringsprocessen te verbeteren, vooral het testen. Door je continue-integratie en continue levering (CI/CD)-pipeline 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 uitvaltijd, terugdraaiacties of een verminderde dienstverlening. Deze metriek laat zien hoe effectief je team is bij het implementeren van wijzigingen.
De prestatienormen voor eliteprestaties liggen op 0-15%, terwijl hoge, gemiddelde en lage prestaties allemaal binnen 16-30% vallen.
Het verbeteren van CFR draait om kwaliteit boven kwantiteit. Bedrijven brengen uiteenlopende aantallen wijzigingen uit en hebben daardoor ook uiteenlopende 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 te herstellen na een storing of onderbreking. Deze metriek meet niet alleen de wendbaarheid van je team, maar is ook een goede indicatie van de stabiliteit van je software.
Als je mikt op een ‘elite’-niveau, moet je voor MTTR streven naar minder dan één 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 eenvoudiger te vinden en op te lossen zijn. Je kunt ook functievlaggen verkennen om je team meer controle te geven — vooral als ze experimenteel zijn.
Er is nog één metriek die we moeten behandelen.
5. Betrouwbaarheid
De bonusmetriek op nummer vijf is betrouwbaarheid. Deze metriek werd later ontdekt door het DORA-team (2021), omdat eerder beschikbaarheid werd gemeten als maatstaf voor betrouwbare software. 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 belangrijke DevOps-metrieken
- Doorlooptijd: Doorlooptijd is de totale tijd vanaf het begin 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 pullverzoeken die lang openstaan.
- Gemiddelde tijd tussen storingen (MTBF): MTBF meet de gemiddelde verstreken tijd tussen systeemstoringen, uitvaltijd of incidenten. Deze metriek evalueert de betrouwbaarheid en stabiliteit van je softwaresystemen en benadrukt de effectiviteit van je strategieën voor preventief onderhoud en foutbeperking.
- 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 aangepakt en opgelost.
- 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 bij het beoordelen van processen voor incidentrespons en -oplossing en geeft de efficiëntie van je teams aan bij het aanpakken van en herstellen van problemen.
- Doorlooptijd van wijzigingen (CLT): CLT biedt een maatstaf 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.
- Ontsnappingspercentage van defecten: Het ontsnappingspercentage van defecten geeft aan hoeveel bugs tijdens het testen worden gemist en naar productie worden uitgebracht — hoeveel er zijn ‘ontsnapt’. Deze metriek is ideaal om bij te houden als je test- en automatiseringsprocessen wilt verbeteren.
KPI's instellen met DevOps-metrieken
Nu je goed begrijpt welke metrieken je kunt gebruiken om DevOps in je bedrijf te implementeren en optimaliseren, wil je waarschijnlijk kritieke prestatie-indicatoren (KPI's) verkennen om doelen en maatstaven 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 levert over een specifiek prestatieaspect. Niet alle metrieken zijn noodzakelijkerwijs gekoppeld aan specifieke doelen of streefwaarden.
KPI's zijn daarentegen een type metriek dat strategisch wordt geselecteerd en gedefinieerd om de meest kritieke aspecten van prestaties en voortgang richting strategische doelen weer te geven. KPI's zijn doorgaans gekoppeld aan doelstellingen en hebben vaak bijbehorende streefwaarden, drempelwaarden of benchmarks 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-metrieken aan je bedrijfsstrategie en doelstellingen. Door prioriteit te geven aan de belangrijkste metrieken om te volgen, kun je beginnen met het vaststellen van streefwaarden en benchmarks voor voortdurende verbetering. Bij het selecteren van de juiste metrieken 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 metrieken.
Het monitoren van je KPI's is net zo belangrijk als het instellen ervan. Ontdek datavisualisatie tools om je team realtimegegevens te bieden op intuïtieve dashboards. Dit zorgt voor volledige zichtbaarheid, bevordert verantwoordelijkheid en stelt iedereen in staat samen aan gedeelde doelen te werken. Zo worden ontwikkelings- en operationele teams op één lijn gebracht en wordt de invoering en volwassenwording van DevOps ondersteund.
Als we de belangrijkste DORA-metrieken bekijken, zien we de benchmarks voor elke metriek op basis van teams die uitmuntend, hoog, gemiddeld en laag presteren. 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 deze met andere bedrijven te vergelijken. 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 in omgekeerde richting invloed op hebben. Als je team al zijn tijd besteedt aan het oplossen 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 streefwaarden hoger kunt leggen.
DevOps-metrieken gebruiken 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 een 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 tijd tot marktintroductie, maar verbetert ook de samenwerking door silo's te elimineren, verhoogt de kwaliteit met continu testen en feedbacklussen en zet middelen efficiënt in, wat geld bespaart. Tot slot is DevOps eenvoudig schaalbaar en ondersteunt het bedrijfsgroei tot nieuwe grenzen. In 2021 kreeg 83% van de IT-besluitvormers 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 snelle aanpak met een voortdurende productieworkflow, dus meten en rapporteren moeten net zo vaak plaatsvinden. Met DevOps-metrieken kun je de prestaties van je ontwikkelings- en leveringsprocessen volgen. Door belangrijke aspecten zoals implementatiefrequentie, doorlooptijd en wijzigingsfoutpercentage te kwantificeren, kun je knelpunten, inefficiënties en verbeterpunten identificeren. Hierdoor kun je workflows en processen regelmatig optimaliseren.
Door metrieken zoals het wijzigingsfoutpercentage en de gemiddelde hersteltijd te volgen, kun je trends identificeren waarmee je problemen vroegtijdig kunt detecteren. Dankzij deze proactieve aanpak kun je corrigerende maatregelen nemen en de impact op klanten minimaliseren, wat betrouwbaarheid oplevert – nog een belangrijk ingrediënt om op schaal een hoge kwaliteit te behouden.
Tot slot helpt het gebruik van DevOps-metrieken je DevOps-team volwassener te maken door een cultuur van voortdurende verbetering te stimuleren. Feedbacklussen bevorderen leren en groei; er moet altijd ruimte zijn om met verschillende benaderingen te experimenteren.
Welke DevOps-metrieken ondersteunen bedrijfsgroei?
Bij het instellen van KPI's moeten de meeste metrieken binnen je team worden beschouwd en worden afgestemd 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 is, maar als het team het tempo niet kan volhouden, is dit niet duurzaam en kan dit uiteindelijk de gebruikerservaring beïnvloeden. Deze metriek moet in de loop van de tijd worden gemeten, in plaats van een KPI vast te stellen die overeenkomt met die van een goed presterend of zelfs uitzonderlijk volwassen DevOps-team. Het instellen van KPI's om de LTC van maand tot maand, per kwartaal of per jaar te verlagen, toont groei binnen je team en bedrijf aan.
CFR is een waardevolle metriek, omdat niet iedereen met hetzelfde aantal fouten of problemen te maken krijgt. Door hier een percentage aan toe te kennen, kun je echter meten hoe succesvol je implementaties zijn. Je team heeft mogelijk zeer weinig fouten als het wijzigingen niet vaak uitbrengt, maar als elke release een probleem veroorzaakt, zal de CFR zeer hoog zijn. Als je CI/CD-praktijken volgt, zie je mogelijk een hoger aantal fouten, maar als je CFR laag is, heb je een voordeel omdat snelheid en kwaliteit samen groei ondersteunen. MTTR moet ook in de loop van de tijd worden gemeten om gestage groei te garanderen.
DORA ontdekte dat teams met elk prestatieniveau op het gebied van ontwikkeling betere resultaten behaalden wanneer ze zich richtten op operationele prestaties. Dit kan betekenen dat je KPI's instelt voor incidentrapporten of openstaande tickets, de uptime van applicaties en beschikbaarheid.
Een groot aantal openstaande tickets kan wijzen op een probleem met je klanttevredenheid, maar streven naar een afname in de loop van de tijd weerspiegelt groei op dit gebied. Je kunt dieper graven en reactie- en wachtrijtijden meten om de verbetering van deze metriek te versnellen.
De ene metriek die ontwikkeling en operationele activiteiten volledig combineert binnen een DevOps-team is de cyclustijd. Dit biedt ruimte voor het opbouwen van een cultuur van terugkoppeling en groei. Naarmate andere metrieken verbeteren en automatisering volwassener wordt, mag je verwachten dat de cyclustijd afneemt. Als je klantenservice uitstekend is en het aantal ontwikkelingsfouten laag, heb je een winnende combinatie gevonden om je bedrijf op te schalen.
Omarm een metriekgestuurde cultuur voor langdurig succes
We hebben ontdekt hoe datagestuurde besluitvorming kan worden geïmplementeerd door geschikte DevOps-metrieken bij te houden en te meten. De juiste aanpak kan de teamprestaties, procesefficiëntie en klanttevredenheid verbeteren.
Hoewel alle DevOps-raamwerken draaien om cultuur, samenwerking en voortdurende verbetering, zal het identificeren van het raamwerk en de metrieken die van toepassing zijn op je groeistrategie je bedrijf ondersteunen om zo effectief mogelijk op te schalen.
Vergeet niet je op onze nieuwsbrief te abonneren om op de hoogte te blijven van al het laatste nieuws van onze experts uit de sector.
