DORA-metrieken zijn ontwikkeld door het DevOps Research and Assessment (DORA) team van Google, dat jarenlang onderzoek
heeft gedaan naar de prestaties van de best presterende DevOps-teams. Op basis van dit onderzoek hebben ze vier metrieken opgesteld waarmee je de prestaties van een DevOps-team kunt beoordelen. In deze reeks lichten we steeds een van de metrieken nader toe.
In dit derde deel van de reeks zoomen we in op Mean Time to Recovery (MTTR): de gemiddelde tijd die nodig is om een storing of
incident op te lossen.
Waar de Change Failure Rate vertelt hóe vaak iets misgaat, zegt MTTR hoe snel je het oplost als dat gebeurt. Incidenten zijn nu eenmaal onvermijdelijk, maar als je ze snel oplost heeft het een minimale impact.
Een lage MTTR betekent dus dat je snel kunt reageren, herstellen en doorgaan, zonder langdurige impact voor gebruikers of klanten.
Gebruikers haken snel af als ze tegen problemen aanlopen. Een tijdelijke storing kan al genoeg zijn om het vertrouwen te schaden. Zeker als je een systeem levert dat voor klanten nodig is voor hun bedrijfsproces.
Denk aan een versproduct zoals bananen: één rot exemplaar kan nog door de vingers worden gezien, zolang het snel wordt vervangen.
Maar als het halve schap blijft liggen met bedorven waar, kom je daar als winkel niet meer mee weg. Zo werkt het ook
met software. Incidentele fouten zijn te vergeven,
mits je ze snel oplost en transparant handelt.
1. Slimme version control (en rollback-strategieën)
Hoe sneller je kunt terugvallen op een stabiele vorige versie, hoe korter de downtime. Gebruik van version control (zoals Git) en technieken als blue/green deployments of feature flags zorgen ervoor dat je bij problemen snel kunt terugschakelen.
Het is alsof je altijd een verse tros bananen op voorraad hebt liggen, voor het geval het huidige aanbod onverhoopt tegenvalt.
2. Monitoring en observability
Je kunt een probleem pas oplossen als je weet dat het speelt. Monitoringtools zoals Apache Devlake of Grafana en observabilitytools zoals Dynatrace geven realtime inzicht in de gezondheid van je applicatie.
Door duidelijke dashboards, loganalyse en metrics op te zetten, zie je afwijkingen direct. MTTR begint dus met zichtbaar maken wat normaal is, zodat je weet wanneer het afwijkt.
3. Proactieve notificaties en alerting
Goede monitoring vertelt je wat er gebeurt, maar het echte verschil maak je door ook in actie te komen vóórdat een incident uit de hand loopt.
Stel: de CPU-waarde van een service schiet naar 90%, het geheugen kruipt richting zijn limiet, of de responstijd begint ineens op te lopen. Op dat moment is er nog niets stuk, maar misschien is het handig om meer resources aan het proces toe te kennen of te onderzoeken waarom dat zo hoog ligt.
Met proactieve notificaties krijgt je team een seintje zodra een metric de verkeerde kant op gaat. Zo kun je ingrijpen voordat gebruikers er last van hebben.
Hoe sneller je die signalen opvangt, hoe kleiner de kans dat een klein probleem escaleert tot een volwaardig incident, en hoe lager je MTTR uiteindelijk uitvalt.
Incidenten zijn nooit helemaal te voorkomen, maar met de juiste tools en processen kun je er wél voor zorgen dat je snel weer op de rails bent. Een lage Mean Time to Recovery betekent dat je voorbereid bent: je weet wat er speelt, je ziet het op tijd en je kunt meteen handelen.
Net als een goede fruitwinkel die altijd een vers alternatief achter de hand heeft, bouw je met een lage MTTR aan vertrouwen, stabiliteit en klanttevredenheid.
Benieuwd waar jouw team staat op het gebied van Mean Time To Recovery? Download dan onze whitepaper of neem contact op met het Gitlab expert service team.