Dedicated hosting beheer: begin bij wat uitval je kost

Het is maandagochtend en de bestelapplicatie reageert niet. Of het is de eerste dag van een campagne en de webshop wordt met elke bezoeker trager. Of de koppeling met het ERP-systeem is 's nachts vastgelopen en niemand ziet het tot de orders ontbreken. Je belt de hostingpartij, die naar de ontwikkelaar wijst, die vraagt of iemand intern iets heeft aangepast. Op zo'n ochtend blijkt of het dedicated hosting beheer in je bedrijf op orde is.

Een eigen server geeft voorspelbare capaciteit en controle over de configuratie. Goed beheerd is hij daarmee nog niet. Hardware, besturingssysteem, updates, back-ups, monitoring en de applicatie zelf moeten op elkaar aansluiten, en iemand moet eigenaar zijn van dat geheel. Hieronder lees je wat je als eerste regelt, wat kan wachten en waar de afwegingen zitten.

Reken eerst uit wat uitval kost

Begin bij de bedrijfsimpact. De hoeveelheid RAM en het aantal processorcores komen later. Een intern urenregistratiesysteem dat een ochtend platligt, is vervelend. Een bestelplatform waar elke minuut omzet binnenkomt, is een ander verhaal. Met dataverlies werkt het net zo: voor de ene organisatie is een dag aan gegevens te overzien, voor de andere zijn een paar uur al te veel.

Maak per applicatie een kort overzicht: welke processen hangen ervan af, wanneer vallen de piekmomenten en hoeveel uitval kun je hebben. Neem de koppelingen mee. Een applicatie kan prima draaien en toch vastlopen omdat de database, de betaalprovider, de voorraadkoppeling of de mailserver niet antwoordt.

Dat overzicht beschermt je tegen twee dure fouten. De eerste is een server die op rustige dagen goed draait en bezwijkt zodra een campagne, import of verkeerspiek begint. De tweede is het omgekeerde: zware infrastructuur kopen voor een probleem dat met een slimmere configuratie of een snellere applicatie was opgelost.

Zet daarna de afspraken op papier. Hoe snel wordt een storing opgepakt, welke systemen gaan voor, wanneer mag onderhoud plaatsvinden en wie mag buiten kantooruren namens jullie beslissen? Zolang die antwoorden ontbreken, is ‘24/7 beheer’ een belofte waar je weinig mee kunt.

Monitor wat je gebruikers zien

Bij veel bedrijven is een medewerker of klant de eerste die merkt dat er iets mis is. Dan ben je te laat. Monitoring die alleen controleert of de server online is, mist de signalen die een probleem aankondigen: geheugenverbruik dat blijft stijgen, een schijf die volloopt, oplopende responstijden, een mislukte back-up of een database die steeds meer capaciteit vraagt.

Een server kan keurig bereikbaar zijn terwijl je applicatie voor gebruikers onbruikbaar is. Meet daarom de hele keten. Laadt de pagina? Geeft de belangrijkste API antwoord? Is de achtergrondtaak die vannacht had moeten draaien echt uitgevoerd?

Daarna komt de opvolging, en daar loopt het vaker vast dan bij de techniek. Een waarschuwing die ongelezen in een mailbox staat, lost niets op. Spreek af wie analyseert, wie ingrijpt en wanneer jij wordt geïnformeerd. Een snel telefoontje van iemand die weet wat er speelt, heeft meer waarde dan een automatisch ticket zonder context.

Een check voor vandaag: open de map of het kanaal waar je monitoringmeldingen binnenkomen en tel hoeveel ervan de afgelopen weken door niemand zijn opgepakt.

Patch lekken direct, plan de rest

Op een server die in productie draait, staat altijd wel een update klaar. Uitstellen levert risico op. Alles direct en blind doorvoeren ook, want een update kan botsen met maatwerk, een verouderde library of een specifieke koppeling.

Hanteer daarom een vaste verdeling. Kritieke beveiligingsupdates gaan voor en worden zo snel mogelijk doorgevoerd. Reguliere updates test je eerst en plan je op een rustig moment. Draait er een bedrijfskritische omgeving op de server, zet dan een test- of acceptatieomgeving op, zodat een wijziging niet voor het eerst onder live druk wordt uitgeprobeerd. Die extra omgeving kost geld en onderhoud. Voor een besloten interne tool kun je hem overslaan. Bij een bestelplatform verdien je hem terug bij de eerste update die anders live was misgegaan.

Patchen is de helft van de beveiliging. Geef alleen toegang aan mensen die die toegang echt nodig hebben, gebruik sterke authenticatie en duidelijke gebruikersrechten, stel firewallregels in en houd logs bij. Een publieke applicatie met persoonsgegevens vraagt meer dan een besloten interne tool, maar die basis hoort op elke server.

Een back-up telt pas na een hersteltest

‘We maken elke nacht een back-up’ klinkt geruststellend. Zolang niemand heeft geprobeerd terug te zetten, weet je alleen dat er iets wordt weggeschreven. Een back-up kan onvolledig zijn, versleuteld raken, op dezelfde infrastructuur staan als het origineel of niet meer passen bij de huidige versie van je applicatie.

Bepaal per systeem wat er geback-upt wordt, hoe vaak en hoe snel herstel moet kunnen. Voor veel systemen is een nachtelijke kopie genoeg. Op een platform met doorlopende transacties kan het verlies van enkele uren al te veel zijn, en dan heb je frequentere snapshots, aparte databaseback-ups en opslag op een andere locatie nodig.

Leg ook vast wie het herstel uitvoert en hoe je daarna controleert of alles werkt. De database terugzetten is stap één. Daarna moeten orders, gebruikersrechten, koppelingen en achtergrondprocessen weer functioneren, en dat controleren kost minstens zoveel aandacht.

Doe je deze week één ding, kies dan één back-up en zet die terug op een aparte omgeving. Dan weet je of je herstelplan werkt.

Een grotere server is zelden de eerste stap

Ook een dedicated server heeft een plafond. Capaciteitsbeheer gaat over groei zien aankomen voordat gebruikers het merken: meer dataverkeer, een database die groeit, meer gebruikers of een nieuwe functie die zwaarder rekent dan verwacht.

Kijk naar de pieken, want gemiddelden zien er bijna altijd geruststellend uit. Een uitgever krijgt een piek bij groot nieuws, een webshop bij een actie, een bureau bij de lancering van een klantcampagne. Let ook op geplande processen. Rapportages, imports en indexeringen kunnen een server op het slechtst denkbare moment zwaar belasten.

Wordt de server krap, kijk dan eerst naar caching, database-optimalisatie, efficiëntere code en het spreiden van zware taken. Dat levert vaak meer op dan extra hardware. Blijkt daarna toch meer capaciteit nodig, dan voer je die uitbreiding gecontroleerd uit, op een moment dat je zelf kiest.

Dedicated hosting beheer hoort bij één team

De meeste tijd win je met duidelijke verantwoordelijkheid. Als de partij die je applicatie kent ook de server beheert, is sneller te zien waar een vertraging vandaan komt: de code, de database, de infrastructuur of een externe API. Je team hoeft dan niet langer als schakel tussen leveranciers te fungeren.

Voor bedrijven met maatwerksoftware of complexe integraties weegt dit het zwaarst, omdat ontwikkeling en hosting elkaar beïnvloeden. Een nieuwe functie kan de serverbelasting opdrijven. Een wijziging aan de infrastructuur kan een koppeling raken. Ligt die kennis bij één team, dan worden wijzigingen beter voorbereid en incidenten sneller opgelost. De keerzijde is dat je meer van die ene partij afhankelijk wordt. Vraag daarom naar documentatie en naar toegang tot je eigen omgeving.

LJPc combineert maatwerkontwikkeling met dedicated hosting en technisch beheer, zodat één team naar de hele keten kijkt. Je krijgt korte lijnen en duidelijke verantwoordelijkheid, en je eigen mensen houden hun tijd voor klanten en groei.

Vier vragen voor je volgende beheergesprek

Prijzen en serverspecificaties vergelijken is het makkelijke deel van een gesprek met een beheerpartner. Deze vragen zeggen meer:

• Hoe is de monitoring ingericht, welke meldingen worden actief opgevolgd en wat zijn de normale reactietijden?
• Hoe worden updates gepland, waar staan de back-ups en hoe vaak wordt herstel getest?
• Hoe word je bij een incident geïnformeerd, en staat daarin wat de impact is, welke actie loopt en wanneer de volgende update komt? Een melding dat er ‘naar gekeken wordt’ is te weinig.
• Wat gebeurt er als je platform verdubbelt in gebruikers, meer data verwerkt of nieuwe koppelingen krijgt?

Stel ze eerst aan je huidige partij. Komt er op de vraag over hersteltests geen concreet antwoord, plan dan samen een hersteltest voordat je over iets anders praat. En wil je horen hoe wij in Assen die vragen beantwoorden, leg ze dan aan LJPc voor.