Oeps. Er werkt iets niet – en als eigenaar van een webshop met digitale producten, rust alle druk op u om het op te lossen. Wat doet u?
Het is nooit leuk als een website offline gaat, maar met een webshop voor digitale producten staan uw inkomsten, de tevredenheid van uw klanten en uw merkreputatie op het spel. Het goede nieuws is dat u enkele voorzorgsmaatregelen kunt nemen om het risico op een websitecrash te verkleinen, en er zijn ook stappen die u kunt nemen als het ergste toch gebeurt.
In de editie van deze week van The EDDit bespreken we wat u moet doen als uw website voor digitale producten offline gaat, zodat u zich zekerder – en beter voorbereid voelt om ermee om te gaan!
Verifieer dat er een probleem is
Het is belangrijk om te verifiëren dat er daadwerkelijk een probleem is voordat u intensievere probleemopsporingsmethoden gaat gebruiken. Af en toe hoort u misschien dat uw site "offline" is, terwijl er eigenlijk andere factoren meespelen.
Om de situatie te beoordelen, stelt u de volgende vragen:
- Laadt uw website normaal vanaf uw eigen apparaten? Controleer desktop- en mobiele versies. U kunt zelfs tools zoals de websitebeschikbaarheidstest van Uptrends, Where’s it Up en Down for Everyone, or Just Me? gebruiken om te controleren hoe uw site laadt in verschillende delen van de wereld.
- Is er een probleem met het apparaat van de gebruiker? Er is niet noodzakelijk veel dat u kunt doen als dit het geval is.
- Is er een probleem met de gebruikte browser? Laad uw site in meerdere browsers om dit te controleren.
- Heeft de gebruiker een stabiele internetverbinding? Kunnen ze andere sites zonder problemen bezoeken?
- Ziet de gebruiker een gecachte versie van uw site? Een harde refresh wist de cache en dwingt de browser om de meest recente versie van de pagina te laden. Dit kan gedaan worden door:
Nadat u problemen met de gebruiker, browser, connectiviteit en caching hebt uitgesloten, kunt u verdergaan met verdere probleemoplossing.
Identificeer de bron van het probleem
Ken uw HTTP-fouten
Moderne browsers proberen u iets meer te vertellen over het verzoek als het simpelweg mislukt, maar het is ook belangrijk om te weten waar HTTP-statuscodes voor staan en hoe ze zijn gegroepeerd voordat u begint met het proces van debuggen.
Vooral als u een 4XX- of 5XX-fout ontvangt, is het belangrijk om te begrijpen wat dit betekent als u het probleem nauwkeurig wilt beoordelen (en aanpakken).
4XX-clientfouten
Deze fouten worden veroorzaakt door de browser van de gebruiker. De meest voorkomende 4XX-fouten zijn:
- 404 niet gevonden. In dit geval werd de door de gebruiker gevraagde bron niet gevonden op de server.
- 403 forbidden. Dit is een op rechten gebaseerde fout, wat betekent dat de client (de browsergebruiker) niet over de juiste machtigingen beschikt om de bron te openen. Dit kan betekenen dat de bron authenticatie vereist, of dat de bestanden op de server onjuiste machtigingen hebben toegewezen gekregen.
Als u zich verder wilt vertrouwd maken met verschillende soorten 4XX-fouten, kunt u de lijst van Wikipedia hier raadplegen.
5XX serverfouten
In tegenstelling tot 4XX-fouten, treden 5XX-fouten op aan de serverzijde. Er zijn verschillende veelvoorkomende 5XX-fouten, waaronder:
- 500 interne serverfout. Een fout op codeniveau, of een andere onspecifieke fout op serverniveau.
- 502 bad gateway. Wanneer de server als proxy fungeert, kan deze fout optreden wanneer deze een ongeldige aanvraag ontvangt van een andere server in de netwerkhierarchie.
- 503 service unavailable. Deze fout treedt op wanneer de server de aanvraag niet kan verwerken, hetzij omdat deze buiten gebruik is voor onderhoud, hetzij omdat deze te veel aanvragen tegelijkertijd verwerkt.
- 504 gateway timeout. Aanvragen kunnen verlopen wanneer de server er lang over doet om te reageren, wat resulteert in een 504-fout.
Als u een 500-fout tegenkomt, wilt u uw foutenlogboeken controleren, aangezien uw code een fout heeft geproduceerd. Controleer voor 502- en 503-fouten of uw webserverdienst (zoals Nginx, Apache, NodeJS, etc.) actief is en of alle afhankelijke services (database, PHP, etc.) actief zijn.
Wat 504-fouten betreft, heeft uw server er gewoon te lang over gedaan om de aanvraag te verwerken en deze volledig te stoppen. Dit kan te wijten zijn aan verschillende redenen - trage databasequery's, een externe service die u nodig heeft en die niet reageert, of uw serverbronnen zijn maximaal benut. Elk van deze moet enigszins anders worden afgehandeld.
U kunt hier meer leren over 5XX-fouten.
Weet waar uw logboeken zich bevinden
Het is belangrijk dat u de locaties van uw foutenlogboeken voor uw servers onthoudt of veilig opslaat. Aangezien tijd cruciaal is wanneer uw e-commerce winkel offline is, is het snel identificeren van het probleem de sleutel.
Als u monitoringtools zoals Rollbar gebruikt, kan het zo eenvoudig zijn als inloggen op uw account en uw foutenlogboeken bekijken.
Controleer de belasting van uw server
Alle servers bieden een manier om de huidige belasting te bekijken, wat een lijst is van alle bronnen die op dat moment worden gebruikt - en in sommige gevallen, historisch. Weet hoe u deze kunt bekijken om te bepalen of er iets is dat te veel van een bepaalde bron gebruikt.
Drie primaire bronnen waar u op wilt letten zijn CPU, geheugen en schijf I/O. U wilt zich voornamelijk richten op CPU en geheugen, aangezien dit de bronnen zijn die gewoonlijk worden beïnvloed door webverkeer.
Wist u dat?
Uw CPU verwerkt alle verzoeken aan uw server en voert ook alle verwerking van die verzoeken uit. Wanneer uw verkeer piekt, zal uw CPU-gebruik ook pieken, aangezien uw server steeds meer verzoeken probeert te verwerken. Als er meer verzoeken zijn dan uw CPU aankan, beginnen de verzoeken in de wachtrij te staan en worden ze afgehandeld volgens een First In, First Out (FIFO) methode.
Geheugengebruik is een andere veelvoorkomende knelpunt die ervoor kan zorgen dat uw site vertraagt of volledig tot stilstand komt. Wanneer uw server geen geheugen meer heeft, wachten verzoeken totdat er meer geheugen beschikbaar is voordat ze kunnen worden voltooid. Net als bij CPU zijn de twee opties het toevoegen van meer geheugen, of het verminderen van de hoeveelheid geheugen die elk verzoek vereist.
Zowel CPU als geheugen hebben twee basismethoden om verkeerspieken of hoog-verbruikende verzoeken te ondersteunen:
- Voeg meer van de benodigde bron toe
- Optimaliseer uw code of database om minder bronnen te vereisen
Er zijn complete boeken geschreven over deze twee onderwerpen, maar we houden het hierbij: De snelle en gemakkelijke oplossing is om meer bronnen toe te voegen, wat meer geld kan kosten. De juiste oplossing voor de lange termijn is om code en databasequery's te identificeren die onnodig zijn en ze ofwel tijdelijk uit te schakelen of te optimaliseren.
Monitoringtools zoals NewRelic kunnen u inzicht geven in welke processen, code en databasequery's de meeste van uw bronnen verbruiken, wat u kan helpen bepalen of u uw bronnen moet optimaliseren of verhogen. We hebben dit al een aantal keren gebruikt om code te identificeren die 504-fouten (time-outs) op onze eigen sites veroorzaakte!
Neem contact op met uw hostingbedrijf
De meeste hostingbedrijven gebruiken geautomatiseerde monitoring, dus als het probleem bij uw host ligt, is de kans groot dat ze er al van op de hoogte zijn en actief bezig zijn om het op te lossen. Als u echter niet zeker bent, moet u contact met hen opnemen om hen te laten weten dat uw site offline is en hen informeren over de specifieke fout die u krijgt.
Onnodig te zeggen dat het belangrijk is om een host met een goede reputatie te kiezen als het gaat om ondersteuning. Bij het onderzoeken van hostingproviders, zorg ervoor dat u de servicevoorwaarden (TOS) en de service level agreement (SLA) controleert om zaken als technische ondersteuning, gegarandeerde uptime, serverbeschikbaarheid en monitoring die u van hen kunt verwachten, in te schatten.
Doe een aankondiging op sociale media
Als u meer dan kortstondige downtime ervaart, wilt u misschien een aankondiging doen op sociale media – vooral als u een grootschalig bedrijf runt met meer dan een paar mensen die problemen ondervinden. Twitter is bijvoorbeeld een gebruikelijke manier voor bedrijven om snel met hun gebruikers te communiceren wanneer er een probleem is:
Zorg dat gekochte producten bij uw klanten komen
Als u klanten heeft die producten van uw site hebben besteld, maar deze niet hebben ontvangen omdat uw site offline was, heeft u een manier nodig om die producten tijdig te leveren. Afhankelijk van de omvang van uw winkel kan het bewaren van kopieën van uw producten in Dropbox of Google Drive een goede optie zijn; op deze manier kunt u eenvoudig een privé-downloadlink naar de klant sturen. U kunt de klant vragen u op de hoogte te stellen zodra ze het product hebben gedownload, zodat u de unieke link snel kunt verwijderen.
Gebruik best practices voor preventie
Er zijn veel redenen waarom een site offline kan gaan, maar zoals ze zeggen: preventie is de beste geneeskunde. Dus, wat zijn enkele manieren waarop u zich tegen deze potentiële problemen kunt beschermen?
Ten eerste wilt u er zeker van zijn dat u de downtime van uw site monitort; het is tenslotte beter om er zelf achter te komen dan om te worden geïnformeerd door een collega, of erger nog - een klant.
Maak altijd een back-up van alles
Wanneer u een wijziging aan uw site gaat aanbrengen, zorg er dan voor dat u een back-up maakt. Of u nu nieuwe code wilt pushen, plug-ins, thema's, uw CMS wilt updaten, of iets anders wilt doen, het maken van een back-up van uw site is absoluut essentieel.
Het is ook belangrijk om een vooraf bepaald (en getest) 'rollback'-plan te hebben. Voordat u op die glimmende knop drukt om wijzigingen aan te brengen, moet u weten welke stappen u moet nemen om die wijzigingen ongedaan te maken - en zorg ervoor dat u deze test in een stagingomgeving.
Volg serviceproviders op sociale media
Sommige serviceproviders kondigen storingen publiekelijk aan, dus door ze op sociale media te volgen, kunt u op de hoogte blijven als er iets gebeurt. Schakel pushmeldingen in voor die accounts om als eerste op de hoogte te zijn van eventuele problemen.
Sommige providers hebben zelfs handige statuspagina's voor hun infrastructuur. Maak er een bladwijzer van!
Overweeg het gebruik van monitoringtools
- NodePing. Deze serverbewakingsservice kan uw startpagina vanaf meerdere geografische locaties aanroepen om u te waarschuwen voor downtime. U kunt waarschuwingen instellen voor uw startpagina en uw afrekenpagina om te zoeken naar specifieke tekstreeksen op de pagina, zoals de voettekst op de startpagina en tekst op de aankoopknop bij het afrekenen. NodePing waarschuwt u via SMS (of een aantal andere methoden) wanneer een van deze controles mislukt.
- Rollbar. Effectief voor foutopsporing en crashrapportage, Rollbar bewaakt fouten in realtime en groepeert en catalogueert uw foutenlogs in een realtime feed en doorzoekbare webinterface. Belangrijker nog, het kan u waarschuwen als specifieke fouten de trend beginnen te volgen. Dit helpt u te weten of een update van uw site problemen veroorzaakt.
- NewRelic. NewRelic integreert rechtstreeks met servers om bijna realtime statistieken over uw server naar hun logplatform te sturen. Dit kan u helpen langzame verzoeken, databasequery's, inefficiënte code (die het regel voor regel kan uitsplitsen) te bepalen - uiteindelijk, wat precies fouten veroorzaakt of pagina's langzaam laadt.
Met deze drie services kunt u fouten op codeniveau en storingen detecteren en realtime meldingen ontvangen. Zo heeft u nooit een storing waarvan u niet op de hoogte bent, en kunt u snel reageren.
Heb een actieplan
Weten wat te doen als uw site offline gaat, is de helft van het werk – en een plan hebben kan het een stuk gemakkelijker maken voor u en uw klanten, mochten er problemen optreden. Hopelijk heeft dit bericht u wat begeleiding gegeven om naar te verwijzen, en enkele inzichten die u kunnen helpen om downtime van de site in de eerste plaats te voorkomen!
Hoe bent u omgegaan met downtime voor uw eigen digitale productwinkel? Welke stappen hebt u ondernomen om uw site te herstellen en toekomstige problemen te voorkomen? Laat ons weten wat u te zeggen heeft. Laat hieronder een reactie achter!
Illustratie door Jessica Johnston.
