Help. Mijn applicatie is uit de lucht. Wat nu?

Applicaties: We kunnen niet meer zonder. Veel bedrijfsprocessen vallen of staan bij het functioneren van deze applicaties. Dus op het moment dat een bedrijfskritische applicatie het laat afweten, is het cruciaal om die zo snel mogelijk weer aan de praat te krijgen. Hoewel het voor de organisatie een kritisch probleem is, is het voor de programmeurs van Thesio een fantastische uitdaging. Developer Joey deelt graag de vijf belangrijkste stappen die hij neemt om een applicatie weer in de lucht te krijgen.

1. Op zoek naar de fout

Code, programmatuur, syntax; het is allemaal gesneden koek voor de medewerkers bij Thesio en zeer bekend bij elke ontwikkelaar. Maar zelfs voor ervaren professionals is het tijdrovend en bijna onmogelijk om te gaan zoeken naar de spreekwoordelijke speld in een hooiberg. Om hier geen dagen aan te spenderen, zit in iedere fatsoenlijke applicatie dan ook een eenvoudig logboek die fouten zeer minimaal registreert. In veel gevallen kun je hierin terugvinden waar en in welk onderdeel de kritische fout zich bevindt. Maar in een enkel geval staat er alleen een ‘error, exception…’ melding en dan moet je verder zoeken.

2. De applicatie updaten

Technologie verandert razendsnel. Om bij te blijven moet een applicatie dan ook regelmatig geüpdatet worden. Doe je dit niet, dan ontstaat het risico dat de applicatie niet meer compatibel is (samen kan werken) met andere applicaties, de browser of het besturingssysteem. In dat geval kunnen er storingen optreden. Het updaten van een applicatie die uit de lucht is naar de nieuwste versie is dan ook vaak één van de eerste dingen die wij doen als we zien dat deze ‘outdated’ is.

3. De hooiberg doorspitten

Als stap 1 en stap 2 niet de gewenste oplossing bieden dan gaan we op zoek naar een breder overzicht en beginnen we bij het splitsen van alle applicatie-onderdelen (ook wel services). Op deze manier hoef je niet de hele hooiberg door te spitten.

Als er bij stap 1 een foutmelding naar voren is gekomen dan kan je als het goed is ook zien bij welke service dit is geregistreerd. Zit de fout in een API-verbinding, de front-end of de backend? En zit dit probleem dan in de server, de database of in de code? Door de logs per onderdeel te controleren kun je een groot gedeelte van de code uitsluiten en gerichter te werk gaan tijdens de zoektocht.

4. Lokaal debuggen

Als je vervolgens een duidelijke locatie in de onderdelen en/of de code hebt gevonden dan kan je doorgaan met debuggen. Met debuggen kunnen we stap-voor-stap controleren of de code ook wel echt doet waar het voor bedoeld is. Met debuggen kan je goed bekijken welke regel(s) niet functioneren. Dit kàn een tijdrovend werkje zijn als blijkt dat de code niet volledig ‘stuk’ gaat, maar simpelweg de verkeerde reactie geeft of er erg lang over doet. Hierdoor ontstaat een kettingreactie waardoor andere onderdelen stoppen met wachten en de server op zwart gaat.

Voor dit soort gespecialiseerde klussen is het erg belangrijk dat je kennis en ervaring hebt met het ontwikkelen en debuggen van veel verschillende applicaties. Je moet tenslotte in staat zijn om de code goed te doorgronden en te kunnen testen op de werking, daarnaast moet je goed begrijpen waarom dat op een bepaalde manier gebeurt.

5. Voorkomen is beter dan genezen

Op het moment dat de applicatie niet meer functioneert ben je eigenlijk al te laat. In vrijwel alle gevallen is dit namelijk te voorkomen door goed onderhoud uit te voeren en terugkerende tests te maken die een dagelijks of wekelijks rapport genereren met de gevonden fouten. Ook al weet je de applicatie weer aan de gang te krijgen, dan heb je alsnog veel tijd en geld verloren omdat medewerkers de applicatie niet konden gebruiken en er een ontwikkelaar bezig is geweest met het oplossen van het probleem. Beheer en onderhoud moeten een belangrijk onderdeel van ICT-beleid zijn om dit soort situaties te voorkomen en het risico van een crash te minimaliseren.