Als een bureau één of twee klantsites beheert, is de snelheid waarmee je op een incident reageert de belangrijkste maatstaf. Als je de omgeving kent, ligt de oplossing meestal binnen handbereik. Een goed afgehandeld probleem kan de relatie met de klant versterken, dus snel reageren is een vaardigheid die je ontwikkelt en een punt van trots waarop je voortbouwt.
Maar het aantal incidenten in een portfolio groeit mee met het portfolio zelf. Als je je op de verkeerde dingen richt, kun je wel sneller worden in het oplossen van problemen, zonder dat ze minder vaak voorkomen. Het verschil tussen reactiesnelheid en incidentfrequentie is waar de echte kosten van een reactief bureau schuilgaan.
Waarom een snelle reactie op incidenten de verkeerde succesmaatstaf is
Bij een setup met één site kun je een ‘snel-oplossen’-cultuur volhouden, omdat incidenten zeldzaam en op zichzelf staand zijn. Als je de omgeving door en door kent en een vertrouwd pad naar de oplossing hebt, is je reactiesnelheid een zinvolle prestatiemaatstaf. Dit wordt Mean Time to Recovery of Repair (MTTR) genoemd: de gemiddelde tijd die het kost om een storing op te lossen zodra die zich voordoet.
Naarmate je groeit, wordt Mean Time Between Failures (MTBF) echter een betere indicator voor de operationele gezondheid. Waar MTTR de herstelsnelheid meet, meet MTBF hoe lang een systeem draait voordat de volgende storing optreedt. Een hoge MTBF betekent dat storingen zelden voorkomen, maar een lage MTBF betekent dat je team bijna constant bezig is met herstel, ongeacht hoe snel elk afzonderlijk herstel verloopt.
Kortom: als je alleen op MTTR optimaliseert, richt je je op de garage terwijl de auto steeds weer kapotgaat. In plaats daarvan heb je MTTR nodig om inzicht te krijgen in de herstelefficiëntie, en MTBF om te zien of de omgeving überhaupt incidenten veroorzaakt.
Wat een lage MTBF kost in een groeiend portfolio
In een groot portfolio zorgt een lage MTBF per site voor een supportwachtrij die je met reactiesnelheid alleen niet wegwerkt. Veelvoorkomende incidenttypen overlappen regelmatig tussen meerdere sites:
- Conflicten bij plugin-updates treffen meerdere installaties tegelijk wanneer er een update wordt uitgerold voor een gedeelde plugin die in het hele portfolio wordt gebruikt.
- Door bots veroorzaakte prestatievermindering kan meerdere sites tegelijk treffen wanneer geautomatiseerd verkeer de caching omzeilt en onbeperkt PHP-threads verbruikt.
- Deploy-fouten zorgen voor configuratiefouten in live-omgevingen wanneer workflows met testomgevingen niet consequent worden gevolgd.
- Incidenten met gedeelde infrastructuur op platforms die sites niet van elkaar isoleren, kunnen zich als een domino-effect verspreiden van de ene site naar andere sites op dezelfde server.
Veel van deze incidenten zijn niet door jouw team veroorzaakt en kun je binnen de omgeving niet voorkomen. Ze allemaal sneller oplossen is dus niet hetzelfde als er minder van hebben.
Hall is een klant van Kinsta met tientallen jaren ervaring als webbureau. Bij hun vorige host had terugkerende site-uitval tijdens verkeerspieken direct invloed op de omzet van een WooCommerce-klant, en slokte het teamcapaciteit op die eigenlijk aan klantwerk had moeten worden besteed:
Kinsta werkt zoals wij werken. We hebben geweldige prestaties nodig zodat er geen verrassingen zijn, en geweldige ondersteuning voor het geval er toch iets gebeurt. Dankzij Kinsta hebben we minder last van ondersteuningsproblemen en kunnen we onze productiviteit verhogen.
De kosten die niet op incidenttickets staan
De meeste bureaus houden de directe kosten van een incident bij, meestal de uren die een ontwikkelaar of accountmanager besteedt aan het opsporen en oplossen van het probleem. Dat cijfer is reëel, maar onvolledig, vanwege een aantal verborgen kosten:
- Door contextwisseling moet een ontwikkelaar een bouwproject onderbreken om een incident op een live site op te lossen, maar het bouwproject loopt gewoon door. Onderzoek wijst uit dat het 15-25 minuten duurt om na een onderbreking weer volledig geconcentreerd te raken. Eén incident halverwege de ochtend kan dus stilletjes het grootste deel van een geconcentreerde werkperiode teniet doen. Die kosten staan nooit op het incidentticket, maar stapelen zich op voor elke site in het portfolio.
- Het vertrouwen van de klant is groot als je één incident transparant aanpakt en oplost. Maar een patroon van terugkerende incidenten zaait twijfel over de vraag of de omgeving wel in orde is. Op den duur bepaalt de frequentie alleen al het vertrouwen van de klant.
- Een bureau dat draait om reactief handelen, zet senior ontwikkelaars in als permanente eerste verdedigingslinie. Als standaardwerkwijze voor een groeiend portfolio leidt dit tot personeelsverloop en capaciteitsbeperkingen, waardoor de negatieve situatie alleen maar erger wordt.
Dat een team voortdurend als buffer moet fungeren tussen een portfolio en terugkerende storingen, is meer een platformprobleem dan een personeelskwestie. De oplossing is een infrastructuur die geen constante tussenkomst nodig heeft om stabiel te blijven. Het bekroonde digitale marketingbureau Paramark beschrijft een soortgelijk model van vóór Kinsta:
Er was buitensporig veel systeembeheer nodig om te voorkomen dat websites uitvielen. Enkele van de terugkerende problemen waren het beheren van serverbronnen en het opschonen van logbestanden. Als je dat niet deed, werden websites instabiel.
De oplossing (het bijhouden van incidenten per site per maand in plaats van de tijd die nodig is om ze op te lossen) laat zien of de omgeving echt verbetert, of dat je team simpelweg steeds beter wordt in het omgaan met een terugkerend probleem.
Hoe het voorkomen van incidenten eruitziet
De infrastructuur en het hele platform van Kinsta zijn rond deze filosofie opgebouwd: het verminderen van de kans op incidenten in plaats van alleen de hersteltijd.
Ten eerste draait elke site in zijn eigen geïsoleerde Linux-container met een eigen softwarestack. Resources kunnen de grenzen van de container niet overschrijden, en dat geldt zelfs tussen sites die bij hetzelfde bedrijfsaccount horen.
Voor een bureauportfolio hebben incidenten in een individuele omgeving geen invloed op de prestaties of beschikbaarheid van andere sites die je beheert. Op gedeelde hostingplatforms daarentegen zorgt een piek in het resourcegebruik op één site ervoor dat andere sites op dezelfde server trager worden.
Automatische backups en herstellen met één klik
Kinsta maakt dagelijks volledige backups van elke site en bewaart deze minimaal 14 dagen. Je kunt backups openen en terugzetten via het scherm Backups in MyKinsta, waar je ook toegang hebt tot twee andere relevante soorten backups:
- Door het systeem gegenereerde backups worden automatisch geactiveerd vóór belangrijke bewerkingen, zoals het herstellen vanuit een bestaande backup. Er is altijd een herstelpunt beschikbaar voordat een bewerking wordt uitgevoerd.
- Met handmatige backups kun je op elk moment tot vijf extra snapshots maken, die je ook een label kunt geven om ze te herkennen.
Met de knop Herstellen naar bij elke backup ga je met een paar klikken terug naar een bekende staat. Voor bureaus die de Automatische Updates add-on gebruiken voor hun hele portfolio: bij elke geplande update is er al een door het systeem gegenereerd herstelpunt aanwezig. Het proces is nu ‘herstellen en onderzoeken’, wat voorspelbaar is, ongeacht welke site erbij betrokken is.
Testomgevingen en Selective Push
De testomgevingen van Kinsta bieden een aparte kopie van de live-site om wijzigingen te testen voordat ze bij klanten terechtkomen. Elk Kinsta-pakket bevat één gratis standaard testomgeving per site. Als een wijziging klaar is om te worden gedeployd, bepaal je met Selective Push precies wat er naar de productieomgeving gaat.
Om Selective Push te gebruiken, selecteer je je testomgeving in MyKinsta, klik je op Omgeving pushen en kies je een deploybereik (Bestanden of Database). Elk bereik heeft ook een vervolgkeuzemenu waarmee je precies kunt instellen wat er wordt gepusht:
Kinsta maakt voor elke push automatisch een backup van de doelomgeving. Deploy-fouten die op live-sites terechtkomen, zijn vaak de oorzaak van incidenten. Daarom is een opzet met meerdere omgevingen, waarbij je Selective Push gebruikt en automatisch backups maakt vóór de push, een manier om te voorkomen dat je dringend moet ingrijpen op de live-site.
Botbescherming als beschermingslaag tegen prestatieproblemen
Kinsta’s Botbescherming filtert verkeer voordat WordPress een verzoek verwerkt, om geautomatiseerde belasting op infrastructuurniveau te verminderen voordat dit de serverprestaties beïnvloedt. Standaard blokkeert Kinsta verkeer dat als schadelijk wordt aangemerkt op het hele platform.
Om de bescherming voor een site in te stellen, ga je naar het scherm Botbescherming in MyKinsta en klik je op Wijzigen in het Beschermingsniveau panel:
Er zijn vier niveaus waaruit je kunt kiezen, en Blokkeer kwaadaardig verkeer is de standaardinstelling voor alle sites. Dit blokkeert DDoS-pogingen en verzoeken van IP-adressen die in verband worden gebracht met bekende aanvalsbronnen. Je kunt dit echter uitbreiden: bevestigd geautomatiseerd verkeer blokkeren, verificatiecontroles voorleggen aan vermoedelijke bots en niet-geclassificeerde verzoeken, en zelfs al het niet-geverifieerde verkeer zo’n controle laten doorlopen, inclusief bezoekers die waarschijnlijk menselijk zijn.
Selecteer je meerdere sites in MyKinsta en klik je op Acties > Botbescherming wijzigen, dan pas je een beschermingsniveau in één keer toe op meerdere sites. Door bots veroorzaakte belasting kan caching volledig omzeilen en bij elk verzoek PHP-threads opgebruiken, vooral bij het beheren van WooCommerce- of lidmaatschapssites. Het wordt steeds belangrijker om deze functionaliteit bij de hand te hebben.
Analytics als vroegtijdige waarschuwing
De analytics-suite van MyKinsta geeft je inzicht in situaties voordat ze uitgroeien tot problemen voor je klanten. Vanuit de Analytics pagina houdt het tabblad Prestatie de PHP-responstijden en het gebruik van PHP-threads in de loop van de tijd bij. Een patroon van stijgende responstijden zonder dat het menselijke verkeer evenredig toeneemt, is vaak een vroeg signaal dat wijst op botverkeer of een inefficiënte databasequery:
Het doornemen van de analysegrafieken kost per site een paar minuten en brengt patronen aan het licht die bij reactieve monitoring over het hoofd worden gezien. Bekijk je bijvoorbeeld de grafiek Bezoeken onder Pakketgebruik, dan zie je gegevens over zaken als factureerbaar menselijk verkeer. Vergelijk je dit met het rapport Topverzoeken op basis van weergaven (dat al het verkeer omvat, inclusief geautomatiseerde verzoeken), dan krijg je inzicht in waar botverkeer de serverprestaties beïnvloedt terwijl het aantal bezoeken normaal lijkt.
Het bedrijfsmodel van je bureau verschuiven naar preventie
Het streven naar minder incidenten wordt ondersteund door de keuze van het platform en de functionaliteit, in plaats van door andere werkpatronen.
Begin bijvoorbeeld met het vastleggen van individuele factoren die per site een rol spelen, naast de stappen die je neemt om het probleem op te lossen wanneer er een incident optreedt. Het doel is niet documentatie omwille van de documentatie zelf, maar om te zien of incidenten zich herhalen om dezelfde onderliggende redenen. De logbestanden in MyKinsta kunnen hierbij helpen:
Een logboek dat drie incidenten op dezelfde site laat zien, veroorzaakt door conflicten bij plugin-updates, wijst op een tekortkoming in de workflow met testomgevingen. Zonder die registratie blijft het patroon onzichtbaar en blijven de incidenten zich voordoen.
Een checklist vóór de deploy is een optimale manier om de beslissingen die je al hebt genomen in een herhaalbaar proces te gieten. De onderstaande punten voorkomen de meest voorkomende soorten vermijdbare incidenten:
- Test elke wijziging in een Kinsta-testomgeving tegen een toestand die representatief is voor de productieomgeving, voordat je pusht.
- Gebruik Selective Push om het deploybereik af te stemmen op de wijziging.
- Controleer Botbescherming na elke deploy waarbij dynamische functionaliteit voor het publiek wordt toegevoegd, met name formulieren, afrekenprocessen of login-endpoints.
- Controleer na het deployen de grafiek Prestatie onder Analytics om te bevestigen dat de responstijden binnen het gewenste bereik blijven.
Zodra je incidenten per site regelmatig bijhoudt, kun je proactief rapporteren over betrouwbaarheidstrends, in plaats van achteraf problemen uit te leggen. Een klant die een kwartaaloverzicht krijgt waarin de incidentfrequentie daalt en de uptime consistent is, heeft een heel andere kijk op de service dan iemand die na elk incident wordt gebeld.
Een infrastructuur waarin preventie voorop staat, maakt schaalbaarheid van een bureau duurzaam
Snelle incidentrespons is een fundamentele vaardigheid voor elk bureau. Infrastructuur die ervoor zorgt dat incidenten zeldzaam zijn, bepaalt of die vaardigheid constant wordt gebruikt of zelden nodig is. Op bureauniveau wordt de winstgevendheid en de stabiliteit van het team bepaald door het verschil tussen die twee.
De tools en infrastructuur van Kinsta (zoals containerisolatie, het automatische backupsysteem en botbescherming) pakken de soorten incidenten aan waar je de meeste tijd aan kwijt bent. Van daaruit zorgt het proces dat je instelt, zoals een incidentlogboek of een checklist vóór de deploy, ervoor dat de vermindering consistent is voor elke site die je beheert.
Voor bureaus die klantwebsites op Kinsta beheren, biedt het Agency Partner Programma dedicated ondersteuning, middelen voor gezamenlijke verkoop en tools die zijn ontwikkeld voor het beheren van WordPress op grote schaal.
