Downtime in je webshop voorkomen: wat er echt helpt

Er is een bepaald soort stilte op kantoor wanneer de webshop eruit ligt. De mailing is net verstuurd, de advertenties lopen gewoon door en iemand roept vanaf de andere kant van de ruimte dat de betaalpagina blijft hangen. De gemiste omzet van dat uur is nog het makkelijkst te berekenen. Lastiger zijn de klanten die niet terugkomen en het team dat de rest van de dag uitleg zit te geven in plaats van te verkopen.

Downtime ontstaat zelden door een enkele spectaculaire fout. Meestal is het een optelsom. Een server die al maanden tegen zijn grens aan zat, een update die op vrijdagmiddag live ging, een koppeling die al weken stilletjes timeouts gaf, en dan een campagne die net iets beter werkt dan verwacht. Los van elkaar is elk punt te overzien. Bij elkaar leggen ze je winkel plat.

Daarom is betere hosting zelden het hele antwoord. Hosting is de bodem waar je op staat. Wat daarboven gebeurt, hoe je wijzigingen doorvoert, hoe je merkt dat er iets misgaat en hoe snel er iemand bij is, bepaalt minstens zoveel.

Waar downtime meestal vandaan komt

In de praktijk komen storingen bij webshops steeds terug op drie technische oorzaken, plus een vierde factor die vooral bepaalt hoe lang de ellende duurt.

Capaciteit is de eerste, en die gaat over veel meer dan schijfruimte. Rekenkracht, geheugen, het aantal gelijktijdige verbindingen en vooral je databaseprestaties bepalen wat je aankunt. Tijdens een mailing of een goedlopende social post blijkt binnen tien minuten of je omgeving is ingericht op je drukste moment of op een gemiddelde dinsdagochtend.

Wijzigingen zijn de tweede. Nieuwe functies, extensies, thema-aanpassingen en beveiligingsupdates zijn nodig, want een webshop die je een jaar met rust laat is geen veilige webshop. Tegelijk is elke wijziging een moment waarop iets kan breken. Een verkeerde cacheregel of een foutje in een template raakt in het slechtste geval precies de checkout, en dat is nu net de pagina die altijd moet werken.

Afhankelijkheden zijn de derde. Betaalproviders, voorraadbeheer, ERP, verzendsoftware, zoekfuncties en reviewwidgets hangen allemaal aan je shop via een koppeling of API. Reageert er een traag of geeft die onverwacht een foutmelding terug, dan kan het bestelproces vastlopen. Zonder nette foutafhandeling is de storing van een leverancier binnen een minuut jouw storing.

De vierde factor is geen oorzaak maar een versterker: gebrek aan zicht. Twee webshops kunnen precies dezelfde fout maken. Degene die het binnen twee minuten ziet, is een kwartier later weer online. De ander hoort het van een klant en is dan al een uur verder. Daar komen we verderop op terug.

Bouw voor je pieken, niet voor je gemiddelde

Een hostingomgeving moet passen bij het gedrag van jouw klanten, niet bij een gemiddelde. Verkoop je tickets, werk je met tijdelijke acties of komt je verkeer in golven binnen na een nieuwsbrief? Dan loop je met een pakket met harde limieten vroeg of laat tegen een muur aan. Je wilt ruimte om tijdelijk op te schalen, en je wilt weten dat die ruimte er is voordat je hem nodig hebt.

Dat betekent niet dat elke webshop een ingewikkelde infrastructuur nodig heeft. Een B2B-shop met voorspelbaar verkeer en tweehonderd orders per week draait prima op een enkele, goed beheerde server. Bij veel gelijktijdige bestellingen, een grote catalogus of zware koppelingen loont het om webserver, database en achtergrondtaken te scheiden, zodat een zware importtaak niet de bezoeker in de checkout raakt. De afweging is uiteindelijk een rekensom: wat kost een uur uitval, en wat kost het om dat uur te voorkomen? Over die verhouding schreven we eerder in ons stuk over de stabiliteit van e-commerceplatformen.

Caching hoort in dit rijtje thuis, maar wel met een duidelijke grens. Productpagina's, categorieoverzichten en afbeeldingen kun je vaak ruim cachen. Het winkelmandje, klantaccounts, actuele voorraad en de checkout juist niet. Een te enthousiast ingestelde cache levert geen downtime op maar iets vervelenders: een webshop die het gewoon lijkt te doen, terwijl klanten een oude prijs zien of in de sessie van iemand anders belanden. Snelheid is pas winst als de bestelling klopt.

Zet updates live zonder je verkoop te onderbreken

Een flink deel van alle uitval is zelf veroorzaakt. Dat klinkt pijnlijk, maar het is goed nieuws, want zelf veroorzaakte uitval kun je ook zelf voorkomen. Het uitgangspunt is simpel: bouw en test buiten productie, en zet pas live wat je hebt zien werken.

In de praktijk werkt een opzet met drie omgevingen goed: ontwikkel, acceptatie en live. Op acceptatie draai je met een kopie van de relevante configuratie en controleer je niet alleen of pagina's openen. Loop de hele klantreis door. Zoeken, product kiezen, kortingscode invoeren, afrekenen met de betaalmethodes die je klanten echt gebruiken, de bevestiging ontvangen en kijken of de order netjes in je backoffice landt. Dat kost twintig minuten en vangt het merendeel van de ongelukken af.

Plan grote releases op een rustig moment, maar vertrouw niet blind op buiten kantooruren. Een release om tien uur 's avonds is alleen minder riskant als er om vijf over tien ook iemand wakker is die kan ingrijpen. Spreek vooraf af wie besluit dat het live gaat, wie kijkt als het misgaat en hoe je terugdraait naar de vorige versie. Een rollbackplan zegt niets over je vertrouwen in de release. Het is gewoon de goedkoopste verzekering die er is.

Beperk het aantal onderdelen dat niemand overziet

De meeste webshops draaien op een mix van kernsoftware, extensies, maatwerk en scripts die ooit door een marketingbureau zijn toegevoegd. Hoe meer losse onderdelen zonder duidelijke eigenaar, hoe langer het duurt voordat je een storing kunt herleiden. Houd daarom bij wat bedrijfskritisch is, wie het beheert en welke versie er draait. Een bijgewerkt lijstje in een gedeeld document is al een enorme stap.

Let daarnaast op stapeling. Drie plug-ins die alle drie iets met caching of met de checkout doen is vragen om conflicten, en het maakt elke update een gok. Soms is een gerichte maatwerkoplossing betrouwbaarder dan vijf uitbreidingen waarvan je hoopt dat ze samenwerken.

Monitoring moet eerder piepen dan je klant belt

Zonder monitoring hoor je van een storing via een klant, een collega of, in het pijnlijkste geval, je betaalprovider. Dat is per definitie te laat. Fatsoenlijke monitoring kijkt continu naar bereikbaarheid, responstijd, serverbelasting, foutmeldingen en databaseprestaties.

Alleen controleren of de homepage antwoord geeft is daarbij bijna waardeloos. Een webshop kan technisch keurig online zijn terwijl niemand kan afrekenen. Meet dus de stappen die geld opleveren: een product in de winkelmand leggen, de betaalmethodes laten laden, een testorder door de checkout duwen en controleren of het orderbericht in je backoffice aankomt. Wordt een van die stappen structureel trager, dan weet je meestal een dag eerder dat er iets aan het schuiven is.

Stel je meldingen wel zo in dat je ze serieus blijft nemen. Honderd waarschuwingen per dag komt neer op nul waarschuwingen, want niemand kijkt er na een week nog naar. Kies drempels die bij jouw omgeving passen, zorg dat de melding terechtkomt bij iemand die er ook echt iets mee kan, en spreek af wat er daarna gebeurt. Wie belt wie om half twaalf 's nachts, en waar ligt de grens tussen morgenochtend oppakken en nu opstaan?

Logging is het onderdeel dat je pas waardeert als het misgaat. Logs laten zien wat er in de vijf minuten voor de storing gebeurde: een release, een verkeerspiek, een API-aanroep die bleef hangen, een query die de database vastzette. Zonder logs is een oplossing een gok, en een gok herhaal je meestal een maand later.

Maak je koppelingen minder kwetsbaar

Je webshop hoeft niet plat te gaan omdat een extern systeem even hapert. Dat vraagt vooral dat je van tevoren nadenkt over wat er moet gebeuren als een antwoord uitblijft. Reageert de voorraadkoppeling niet, dan is een duidelijke melding of een order die tijdelijk in de wachtrij gaat bijna altijd beter dan een checkout die blokkeert.

Zet alles wat niet op het moment zelf hoeft in zo'n wachtrij. Gegevens naar je ERP, CRM of fulfilmentpartij mogen best dertig seconden later verwerkt worden, want de klant heeft zijn bevestiging dan allang. Probeer mislukte verzoeken automatisch opnieuw, maar met een limiet en een oplopende wachttijd. Een koppeling die eindeloos blijft hameren op een systeem dat het al zwaar heeft, maakt een klein probleem groter.

Leg ten slotte vast welk systeem gelijk heeft als twee bronnen van elkaar verschillen. Is de voorraad in de webshop leidend of die in het ERP? Mag een bestelling doorgaan als de voorraadstand een paar minuten oud is? Dat zijn bedrijfskeuzes met technische gevolgen, en je wilt ze gemaakt hebben voordat iemand om elf uur 's avonds moet improviseren.

Herstellen is minstens zo belangrijk als voorkomen

Nul downtime bestaat niet, en wie het je belooft verkoopt iets. Hardware faalt, leveranciers vallen uit en mensen maken fouten, ook goede mensen. Het verschil tussen een vervelend kwartier en een slechte dag zit in hoe snel je herstelt en hoeveel je onderweg kwijtraakt.

Maak dus automatische back-ups van bestanden, database en configuratie, en test een paar keer per jaar of je ze ook echt kunt terugzetten. Een back-up die tijdens het incident voor het eerst wordt uitgeprobeerd is geen zekerheid maar een hoop.

Spreek daarnaast een hersteltijd af waar je achter staat. Voor de ene organisatie is een uur uitval vervelend maar te overleven. Voor een shop die per uur duizenden euro's draait, of die zakelijke bestellingen met levertijdafspraken verwerkt, is een uur onacceptabel. Die gewenste hersteltijd bepaalt de rest: hoeveel redundantie je nodig hebt, hoe uitgebreid je monitoring wordt en of er buiten kantoortijd iemand beschikbaar moet zijn. Meer zekerheid kost geld. Langdurige uitval kost meestal meer, en altijd op het slechtst denkbare moment.

Het scheelt hierbij enorm als de partij die de storing onderzoekt zowel de applicatie als de infrastructuur kent. Anders begint elk incident met heen en weer mailen tussen hostingpartij en ontwikkelaar, terwijl de klok doortikt. Bij LJPc houden we die twee bij elkaar, simpelweg omdat het de weg van melding naar oplossing korter maakt.

Maak er een gewoonte van

De voorbereiding die telt, doe je in de weken dat er niets aan de hand is. Neem na elke storing een half uur de tijd om door te nemen wat er precies gebeurde, welke signalen er achteraf al zichtbaar waren en welke aanpassing herhaling voorkomt. Niet om iemand aan te wijzen, maar omdat dit de enige manier is waarop een omgeving aantoonbaar stabieler wordt.

Plan daarnaast een korte technische check voor elke drukke periode. Verwachte bezoekersaantallen, wat er de afgelopen weken live is gegaan, beschikbare capaciteit, de status van je belangrijkste koppelingen en de vraag of de back-up van gisteren er echt staat. Dat is een half uur werk voor Black Friday, en het bespaart je met enige regelmaat een dag die je liever niet had gehad.

Een betrouwbare webshop is geen product dat je eenmalig koopt en afvinkt. Het is het resultaat van een paar bewuste keuzes, wat routineus onderhoud en mensen die snel reageren als het toch misgaat. Werkt het zo, dan merk je je techniek nauwelijks meer op. En dat is precies de bedoeling, want dan kan je aandacht terug naar groei.