“Doe het maar als het rustig is.” Het klinkt verstandig, maar voor een webwinkel bestaat dat moment niet meer. Er wordt ‘s nachts besteld, in het weekend, tijdens de kerstdagen. Webshop onderhoud tijdens bestellingen is daarom geen uitzondering die u wilt vermijden, maar de normale situatie waarin u moet leren werken.
Wat wél kan, is het risico verkleinen tot het punt waarop een mislukte update hooguit een paar minuten kost en geen enkele klant het merkt. Dat vraagt geen ingewikkelde techniek, wel een vaste werkwijze. En het vraagt dat u ophoudt met de gewoonte om onderhoud maar uit te stellen, want dat is het gevaarlijkste van alles.
Waarom uitstellen duurder is dan het risico
De redenering “we wachten tot het rustiger wordt” leidt in de praktijk tot shops die zes maanden achterlopen. Dat is om drie redenen slechter dan regelmatig bijwerken.
Ten eerste stapelen updates zich op. Werkt u tien plugins tegelijk bij nadat u een halfjaar heeft gewacht, dan is een probleem veel moeilijker te herleiden dan wanneer u er elke twee weken twee doet. De kans op een conflict groeit, en de kans dat u weet wie de dader is, krimpt.
Ten tweede zitten er beveiligingslekken tussen. Een bekend lek in een populaire plugin wordt binnen dagen na publicatie geautomatiseerd misbruikt. Een webshop met klantgegevens en betalingen is daarbij een aantrekkelijker doelwit dan een gewone bedrijfssite.
Ten derde is die drukke periode juist het moment waarop u niet meer kunt bijwerken. In december wilt u nergens aan zitten, dus schuift het door naar januari, waarna de uitverkoop begint. Zo ontstaan de shops die twee jaar achterlopen.
Welk onderhoud u gerust tijdens bestellingen doet
Niet elk onderhoud is even riskant. Deze taken raken het bestelproces nauwelijks en kunt u prima op een dinsdagochtend doen:
- Producten, prijzen en teksten bijwerken.
- Afbeeldingen optimaliseren en de mediabibliotheek opruimen.
- Back-ups controleren en terugzetproeven doen op een kopie.
- Gebruikers en rechten nalopen.
- Logboeken en beveiligingsmeldingen doorlezen.
- Kleine WordPress-onderdelen bijwerken die niets met de shop te maken hebben, zoals een taalbestand.
Waar u overdag vanaf blijft: de webwinkelsoftware zelf, betaalplugins, verzendkoppelingen, het thema, en alles wat de afrekenpagina raakt. Ook de PHP-versie van uw server hoort in die categorie. Die vier of vijf dingen doet u in een gepland venster, met een vangnet.
De werkwijze die het risico wegneemt
Het idee is simpel: u wilt nooit een wijziging op de live shop doen waarvan u nog moet uitvinden of hij werkt. Dat lost u op door het elders uit te proberen.
- Maak een verse back-up van bestanden en database, en niet alleen op dezelfde server.
- Kopieer de shop naar een testomgeving en voer daar de update uit.
- Doorloop op die kopie het hele bestelpad: product in de wagen, afrekenen, betalen in testmodus, bevestigingsmail, factuur.
- Werkt het, voer dan dezelfde stap op de echte shop uit, op het rustigste uur dat u kunt vinden. Voor de meeste Nederlandse shops ligt dat tussen vijf en zeven uur ‘s ochtends.
- Doe direct daarna één echte testbestelling en betaal die ook.
- Blijf het eerste uur kijken naar binnenkomende bestellingen en foutmeldingen.
Stap één tot en met drie kosten samen misschien twintig minuten als u het vaker doet. Zonder die stappen gokt u, en dat gaat een keer per jaar mis op het slechtst denkbare moment. Hoe zo’n kopieeromgeving in de praktijk werkt, staat in de praktijkcase over updates via een testomgeving.
Onderhoudsmodus: liever niet
Veel ondernemers denken bij onderhoud aan een schermpje met “wij zijn zo terug”. Voor een webshop is dat vrijwel altijd de verkeerde keuze. U zet uw winkel dicht voor iedereen, ook voor de negenennegentig procent van de bezoekers die niets merkt van uw update. En bezoekers die zo’n scherm zien, komen zelden dezelfde dag terug.
De uitzondering is een ingreep die de database structureel verandert, bijvoorbeeld een grote versiesprong van de webwinkelsoftware of het omzetten naar een andere opslagstructuur voor bestellingen. Dan is een kort venster van tien tot vijftien minuten met een nette melding beter dan bestellingen die halverwege stukgaan. Kondig het in dat geval aan op uw shop en in uw nieuwsbrief, en kies een tijdstip waarop u historisch de minste bestellingen heeft.
Voor alles daaronder geldt: een goed voorbereide update duurt korter dan het aan- en uitzetten van een onderhoudsscherm.
Wat u doet als het toch misgaat
Bereid dit vooraf voor, want tijdens een storing denkt niemand helder. Zorg dat u van tevoren weet: waar staat de back-up, hoe zet ik hem terug, en hoeveel tijd kost dat? Als het antwoord op die laatste vraag “geen idee” is, heeft u geen back-up maar een bestand.
Belangrijk detail dat specifiek voor shops geldt: zet nooit zomaar een database terug die ouder is dan een uur. U gooit daarmee de bestellingen weg die in de tussentijd zijn binnengekomen, inclusief de betalingen die er al bij horen. Draai bij twijfel eerst de bestanden terug en laat de database staan; die combinatie lost verreweg de meeste mislukte updates op. Wat er gebeurt als u dat onderscheid niet maakt, leest u in het artikel over bestellingen die na een terugzetactie verdwenen.
Mijn eigen opvatting, na genoeg avonden met een half werkende shop: het venster waarin u onderhoud doet is minder belangrijk dan de vraag of u binnen vijf minuten terug kunt. Een update om drie uur ‘s nachts zonder herstelplan is riskanter dan een update om tien uur ‘s ochtends met een geteste kopie en een back-up van tien minuten oud.
Wie dat ritme niet zelf wil bewaken, laat het meelopen in een vast contract voor het technisch beheer van een webwinkel. Bij WebMaintor gaan updates op shops standaard eerst over een kopie en pas daarna live, met een testbestelling als sluitstuk.
Concrete volgende stap: kijk in uw bestelstatistiek naar het uur waarop u historisch de minste bestellingen heeft. Dat uur is vanaf nu uw onderhoudsvenster, en dat is een stuk concreter dan “als het rustig is”.
