Hoe belangrijk is DevOps om downtime te vermijden?

Het is een utopie om te denken dat je alle fouten in applicaties die tot downtime (kunnen) leiden kan vermijden. Maar de tijd nodig om ze te voorspellen, te vinden en op te lossen kan wel gevoelig verbeterd worden.

Wie krijgt de schuld?

Nu zien we nog te vaak dat de verantwoordelijkheid om een applicatiefout op te lossen in eerste instantie bij de systeembeheerder terecht komt. Die zal met zijn monitoring en management tools aan de slag gaan om te kijken of de fout kan gerelateerd worden aan infrastructuurcomponenten zoals de CPU, het geheugen of het netwerk. Pas als hij daar niks kan vinden, zal hij de hulp van ontwikkelaars inroepen. Die maken dan weer gebruik van eigen diagnostische tools, zodat je meerdere databronnen en meer kans op verwarring en ongenoegen tussen beiden creëert.

Het eindresultaat: meer tijd dan nodig om de eigenlijke oorzaak van het probleem te vinden, met een langere downtime als gevolg. Kan dat beter? Ja. Door een DevOps-filosofie toe te passen.

Bij DevOps, wordt de verantwoordelijkheid voor de prestaties van de applicatie gedeeld tussen beide afdelingen. Dat betekent dat ontwikkelaars en systeembeheerders van bij de start samenzitten. Zo krijgen ontwikkelaars een beter beeld van de mogelijkheden en beperkingen van de systemen waarop hun applicatie gaat draaien en krijgen systeembeheerders meer inzicht in het gedrag van de applicatie.

Betere bugfixes

Door het implementeren van Application Performance Monitoring kunnen beide partijen fouten lokaliseren nog voor ze problematisch worden. Een Source Control Systeem kan dan weer alle wijzigingen in de code registreren en zo beide partijen meer inzicht geven in elkaars manier van werken.

Een DevOps-aanpak maakt het ook mogelijk om bugfixes makkelijker en sneller aan een productie-omgeving toe te voegen. Binnen een traditionele set-up, waar de ontwikkelomgeving duidelijk gescheiden is van de productie-omgeving, bestaat de kans dat bugfixes niet werken zoals gewenst, net omdat er verschillen zijn tussen de twee omgevingen. Bij DevOps zijn die omgevingen veel beter op elkaar afgestemd, en is die kans kleiner. Als gevolg hiervan verlaagt de tijd om tot een effectieve oplossing of workaround te komen.

Solution goal versus MTTR

Omdat we bij Combell volgens de DevOps-filosofie werken, durven we contractueel een Solution Goal afspreken in plaats van een Mean Time to Repair (MTTR). Het verschil? Bij een Solution Goal spreek je een duidelijk periode af waarbinnen er een oplossing of workaround zal zijn. Bij een Mean Time to Repair spreek je een gemiddelde tijd af. Zo kan je service provider 10x iets fiksen op enkele minuten en de elfde keer enkele uren nodig hebben voor een oplossing, maar toch binnen de MTTR-afspraken blijven. Terwijl jij als klant wel enkele uren downtime hebt ervaren. Niet zo bij een Solution goal dus.

Om dat mogelijk te maken is het belangrijk dat ontwikkelaars en systeembeheerders samen werken. Hoe dat in de praktijk gaat kan je lezen in ons stappenplan voor een efficiënte DevOps-aanpak.