Uptime en server monitoring: storingen zien voordat uw klant ze merkt

Een webshop die om 08.57 uur niet meer reageert. Een klantportaal dat rond het middaguur stroperig wordt. Een koppeling met de boekhouding die zonder enige melding stopt met het doorzetten van orders. Voor degene aan de andere kant maakt de technische oorzaak niets uit: het werkt, of het werkt niet.

De meeste storingen waarvoor wij gebeld worden, kwamen niet uit de lucht vallen. Er waren signalen. Alleen keek er niemand naar, of de melding kwam binnen op een adres dat al maanden niet meer werd gelezen. Deze gids gaat over het dichten van dat gat, zodat u weet wat er speelt voordat uw telefoon begint te rinkelen.

Uptime is geen cijfer dat u eens per kwartaal in een rapportage tegenkomt. Het is een belofte aan klanten, medewerkers en partners. Draait uw organisatie dagelijks op een platform, een interne applicatie of een koppeling met een externe partij, dan wilt u zelf als eerste weten wanneer er iets begint te schuiven.

Wat uptime werkelijk zegt over uw dienstverlening

Uptime is de tijd dat een systeem beschikbaar en bruikbaar is. Dat tweede woord wordt vaak overgeslagen. Een server kan netjes antwoord geven op elk verzoek dat binnenkomt, terwijl het afrekenen in de webshop stukloopt op de betaalprovider. Een interne tool kan prima openen en toch onbruikbaar zijn, simpelweg omdat elke pagina veertien seconden nodig heeft.

Het is daarom verstandig om beschikbaarheid te bekijken vanuit degene die ermee moet werken. Laadt de pagina? Kan iemand inloggen? Komt de bestelling aan de andere kant binnen? Wisselt de applicatie nog data uit met het systeem van de leverancier? Welke van die vragen het zwaarst weegt, verschilt per organisatie. Een uitgever wil dat artikelen online staan op precies het moment dat het verkeer piekt. Een SaaS-platform kan geen uur zonder inlog en dataverwerking. Bij een groothandel is de keten van voorraad naar order naar logistiek meestal de kwetsbaarste schakel.

Een hoge uptimegarantie is dus pas iets waard als helder is wat er precies gemeten wordt. 99,9 procent klinkt bijna perfect en staat nog altijd gelijk aan bijna negen uur uitval per jaar. Of dat acceptabel is, hangt af van uw openingstijden, uw processen en wat een uur stilstand u werkelijk kost. Voor een brochuresite is het een ongemak. Voor een orderportaal op maandagochtend is het iets anders.

Monitoring in lagen: verder kijken dan online of offline

Bruikbare monitoring bestaat uit een paar lagen die elkaar aanvullen. De buitenste laag controleert of een dienst van buitenaf bereikbaar is: de website, een API-endpoint, de mailserver, de inlogpagina. Dat is de laag die het snelst iets zegt over wat uw klanten merken.

Alleen vertelt bereikbaarheid van buiten niet waarom iets misgaat. Daarvoor kijkt u naar de machine eronder: processorbelasting, geheugengebruik, vrije schijfruimte, netwerkverkeer en processen die stilletjes zijn gestopt. Een schijf die in drie weken volloopt levert vandaag geen enkele klacht op. Volgende week blokkeert diezelfde schijf uw databaseschrijfacties, uw uploads en uw nachtelijke back-ups in één keer.

Boven op de infrastructuur zit de applicatie, en daar wordt het interessant. Hier test u of de dingen die geld of tijd kosten daadwerkelijk lukken. Een server kan volledig gezond zijn terwijl een databaseverbinding faalt, de betaalprovider timeouts geeft of de geplande import van vannacht halverwege is blijven steken. Dit soort controles maakt het verschil tussen monitoring voor de technische administratie en monitoring waar uw directie iets mee kan.

Dan is er nog logging, dat doorgaans pas aandacht krijgt wanneer het te laat is. Monitoring meldt dat er iets stuk is. Logs vertellen waarom. Foutmeldingen, uitschieters in responstijden en mislukte taken zijn het materiaal waarmee een beheerder de oorzaak in minuten vindt in plaats van in uren. Zonder dat materiaal wordt herstel gokwerk, en dat gokken duurt langer naarmate er meer systemen en externe partijen bij betrokken zijn.

Welke signalen verdienen direct aandacht?

Niet elke melding hoeft iemand om drie uur 's nachts uit bed te halen. Doet u dat toch, dan heeft u binnen een maand alertmoeheid: er komt zoveel binnen dat niemand nog kijkt, en de melding die er echt toe deed glipt met de rest mee naar beneden.

Kritiek is wat nu geld of vertrouwen kost: een productieomgeving die onbereikbaar is, een database die omvalt, een verlopen SSL-certificaat, een volle schijf, een koppeling die orders laat liggen. Een waarschuwing is iets dat de verkeerde kant op beweegt: geheugengebruik dat elke week een stukje oploopt, responstijden die verdubbelen, een back-up die vroeger twintig minuten duurde en nu twee uur. Daar hoeft niemand wakker voor te worden, en blijven liggen mag het ook niet.

Laat drempelwaarden verder niet op de standaardinstelling staan. Een server die elke ochtend tussen acht en negen tegen zijn plafond aanloopt, is misschien gewoon een server die zijn werk doet. Precies diezelfde piek op zondagavond is wel een signaal: een fout in de software, verkeer dat er niet hoort te zijn, of een proces dat in een lus zit. Monitoring wordt bruikbaar op het moment dat u de cijfers naast het normale ritme van uw bedrijf legt.

Beschikbaarheid begint bij duidelijk eigenaarschap

Tijdens een storing is onduidelijkheid het duurste dat u heeft. Wie krijgt de melding binnen? Wie bepaalt hoe erg het is? Wie mag daadwerkelijk op de server, wie mag de applicatie aanpassen, en wie pakt de telefoon om de externe leverancier te bellen? Zijn ontwikkeling, hosting en beheer over drie partijen verdeeld, dan gaat het eerste halfuur vaak op aan uitzoeken wie er aan zet is.

Eén partij die alles doet is daarvoor niet de enige oplossing. Wel dat elk onderdeel vooraf een eigenaar heeft. Leg vast welke systemen onder beheer vallen, welke reactietijd hoort bij welk type incident en wie klanten en collega's bijpraat terwijl er aan de oplossing wordt gewerkt. Een melding die afgaat zonder dat iemand bereikbaar is om er iets mee te doen, is geen monitoring. Dat is een verslag van een storing.

In de praktijk werkt een indeling in drie niveaus goed. Volledige uitval of een veiligheidsrisico: nu oppakken, ongeacht het tijdstip. Een belangrijke functie die het niet doet: binnen de afgesproken reactietijd beoordelen en herstellen. Kleine afwijkingen: inplannen, tenzij ze aantoonbaar verslechteren. Die driedeling scheelt u een discussie op precies het moment dat u die het minst kunt gebruiken.

Meten is pas nuttig als u ernaar handelt

Een dashboard vol groene blokjes geeft een prettig gevoel en verder niets, zolang niemand de trend leest. Neem de terugkerende waarschuwingen daarom periodiek door, een keer per maand is ruim voldoende: waar zaten de pieken, welke processen worden langzamer, welk incident kwam nu voor de derde keer voorbij? Een storing die u elke maand tijdelijk oplost, is geen storing meer. Dat is een structureel probleem met een handige pleister erop.

Kijk ook vooruit naar capaciteit. Groei in bezoekers, orders, bestanden of gebruikers werkt zelden netjes lineair door in de belasting. Een toename van tien procent kan één slecht geschreven query, een zoekfunctie of een koppeling ineens over de rand duwen. Bij maatwerksoftware is het daarom de moeite waard om prestaties te meten voordat een campagne live gaat, in plaats van tijdens.

Back-ups horen in dezelfde beheerdiscipline thuis. Een groen vinkje bij 'back-up geslaagd' zegt minder dan u zou hopen. U wilt weten of de back-up compleet is, of er een kopie op een andere locatie staat en wanneer er voor het laatst echt een herstel is uitgevoerd. Uptime gaat over beschikbaar blijven. Herstelbaarheid bepaalt hoe lang een echt slechte dag duurt.

Kies monitoring die past bij uw risico

Niet elke omgeving vraagt dezelfde inrichting. Een bedrijfswebsite is goed geholpen met bereikbaarheidscontrole, een oogje op het certificaat en basisbewaking van de server. Een e-commerceomgeving heeft daarbovenop controle nodig op de checkout, betalingen, voorraadkoppelingen en prestaties tijdens drukte. Bij een SaaS-oplossing zijn gebruikersflows, achtergrondtaken, databases en API's meestal allemaal kritisch, en dan is de vraag niet of u monitort, maar hoe fijnmazig.

Meer controles betekent overigens niet automatisch beter. Elke check moet een vraag beantwoorden die u kunt opschrijven: welk bedrijfsrisico zien we hiermee eerder, en wie doet wat als deze check afgaat? Blijft dat antwoord leeg, dan voegt u vooral ruis toe. Begin bij de processen die direct aan omzet, service of de dagelijkse operatie hangen en bouw van daaruit verder.

De hostingomgeving weegt eveneens mee. Gedeelde infrastructuur is prima bij voorspelbaar verkeer en een beperkt risico. Gaat het om gevoelige data, zware koppelingen of harde afspraken over beschikbaarheid, dan wilt u meer grip op capaciteit, beveiliging en configuratie. Die keuze volgt uit uw afhankelijkheid, niet uit een standaardpakket.

Van incident naar structurele verbetering

Zodra alles weer draait, is de neiging groot om door te gaan met de dag. Begrijpelijk, en juist dan is het moment voor de enige vraag die echt iets oplevert: waarom zagen we dit niet eerder? Een evaluatie hoeft geen rapport te zijn. Een half A4 met wat de gebruiker merkte, wanneer het begon, welke signalen er vooraf waren, hoe het is opgelost en welke maatregel herhaling onwaarschijnlijker maakt, is genoeg.

Soms is die maatregel technisch: een query optimaliseren, capaciteit bijzetten, een timeout aanpassen. Vaker dan u zou denken zit het in het proces. Een escalatiepad dat niemand kende. Een contract bij een externe dienst dat stil was verlopen. Een wijziging die op vrijdagmiddag zonder review naar productie ging. Beide kanten verdienen aandacht, want techniek is pas betrouwbaar wanneer het beheer eromheen klopt.

Dat ontwikkeling en hosting bij ons onder één dak zitten, helpt op zulke momenten. Niet omdat het de enige werkbare opzet is, maar omdat niemand hoeft te wachten tot een andere partij terugbelt om te bepalen of het probleem in de code of in de infrastructuur zit.

Begin daarom niet met het uitzoeken van een tool. Begin met één vraag: welk digitaal proces mag morgen niet stilvallen? Richt daar uw controles, uw meldingen en uw afspraken op in. Dan is monitoring geen technische bijzaak meer, maar de reden dat uw organisatie doorwerkt op de dag dat er iets misgaat.