Wat je mag verwachten van hosting en beheer
Duidelijke afspraken over incidenten, updates, beveiliging en herstel. Met inzicht in wat is uitgevoerd, wat aandacht vraagt en wie de volgende stap zet.
Beheer begint met duidelijke verantwoordelijkheden
Hosting zorgt voor de plek waar je applicaties draaien. Beheer zorgt dat iemand de omgeving volgt, onderhoud plant, verstoringen onderzoekt en wijzigingen gecontroleerd doorvoert.
Vooraf leggen we vast welke websites, frontends, backends, databases, API’s en achtergrondprocessen binnen de dienstverlening vallen. Ook afhankelijkheden van leveranciers, onderhoudsvensters, contactpersonen en de route voor spoedmeldingen horen daarbij.
Incidenten en bereikbaarheid
We spreken af hoe meldingen worden geclassificeerd, wanneer ze worden opgepakt en hoe je op de hoogte blijft. Buiten-kantoorurenondersteuning en achtervang worden expliciet vastgelegd.
Updates en beveiliging
Kwetsbaarheden worden beoordeeld op hun relevantie en impact. Updates krijgen een passende planning, teststap en terugvalmogelijkheid.
Back-ups en herstel
We bepalen wat wordt geback-upt, hoe lang gegevens worden bewaard en hoe herstel wordt getest. Maximaal dataverlies en gewenste hersteltijd zijn afzonderlijke afspraken.
Een passende reactie per incidentprioriteit
De impact op gebruikers en bedrijfsprocessen bepaalt de prioriteit. Een volledig stilgevallen klantportaal vraagt een andere opvolging dan een kleine weergavefout.
Onderstaande tijden zijn een illustratief servicemodel. De afgesproken dekking en responstijden worden per klant vastgelegd; dit is geen algemene SLA of herstelgarantie.
| Prioriteit | Voorbeeld van impact | Voorbeeld eerste reactie | Opvolging |
|---|---|---|---|
| P1 — kritiek | Een essentieel proces ligt stil of er is een actief beveiligingsincident met grote impact. | Binnen 1 uur, uitsluitend binnen de overeengekomen dekking. | Direct onderzoeken en escaleren; frequente updates. Voor 24/7-opvolging zijn consignatie en achtervang nodig. |
| P2 — hoog | Een belangrijke functie is beperkt; een tijdelijke omweg is beschikbaar. | Binnen 4 werkuren. | Impact beperken, herstelroute bepalen en voortgang afstemmen. |
| P3 — normaal | Een beperkte fout zonder uitval van een essentieel proces. | Binnen 1 werkdag. | Onderzoeken en inplannen op basis van impact en afhankelijkheden. |
| P4 — verzoek | Een vraag, kleine verbetering of geplande wijziging. | Binnen 2 werkdagen. | Afstemmen van scope, planning en eventuele aanvullende kosten. |
Een eerste reactie betekent dat de melding wordt beoordeeld en de opvolging wordt gestart. Herstelduur hangt onder meer af van de oorzaak, toegang, leveranciers en technische mogelijkheden. Werkuren, communicatiekanalen en escalatiecontacten maken deel uit van de afspraak.
Onderhoud en security die bij de omgeving passen
Een updatebeleid werkt wanneer urgentie, technische impact en bedrijfscontinuïteit samen worden afgewogen.
We inventariseren runtimes, frameworks, plugins, libraries en infrastructuurcomponenten. Meldingen over kwetsbaarheden worden gecontroleerd op gebruikte versie, blootstelling en beschikbare oplossing. Actieve misbruiksignalen kunnen directe beperking van het risico vragen.
Regulier onderhoud wordt gebundeld in afgesproken onderhoudsvensters. Voor risicovolle wijzigingen beoordelen we testdekking, een actuele back-up, rollback en de controle na uitrol. Open uitzonderingen krijgen een eigenaar en herbeoordelingsmoment.
Wat we vooraf vastleggen
- Wie patches beoordeelt en toestemming geeft voor uitrol.
- Termijnen per risicoklasse en omgang met spoedpatches.
- Welke ondersteuning geldt voor verouderde software.
- Welke tests en herstelstappen per wijziging nodig zijn.
- Wie verantwoordelijk is voor externe API’s, accounts en licenties.
Doorontwikkeling, een grote frameworkupgrade of functionele wijziging kan apart projectwerk zijn. Dat wordt vooraf duidelijk gemaakt.
Voorbeeld: beheer van een groter applicatielandschap
Een webshop, klantportaal en medewerkersomgeving delen een backend, databases en meerdere API’s. Een storing in één onderdeel kan daardoor effect hebben op een andere gebruikersroute.
Illustratieve omgeving: drie frontends; één beheerbackend; een relationele transactiedatabase; een rapportagedatabase; interne product- en order-API’s; externe betaal- en leveranciers-API’s; een wachtrij met workers; bestandsopslag en centrale authenticatie.
Monitoring volgt de bereikbaarheid én kritieke routes, zoals inloggen, een aanvraag afronden en een order verwerken. Daarnaast bewaken we wachtrijen, mislukte taken, databasecapaciteit, certificaten en de actualiteit van rapportagegegevens.
De onderstaande maandgegevens zijn volledig fictief en illustreren welke terugkoppeling je kunt verwachten.
| Onderdeel | Voorbeeldbevinding | Opvolging |
|---|---|---|
| Drie frontends | Webshop en klantportaal beschikbaar; medewerkersomgeving 12 minuten beperkt na een release. | Release teruggedraaid, gebruikersroute gecontroleerd en regressietest toegevoegd. |
| Backend en interne API’s | Een order-API verwerkte langzamer tijdens een import. | Import en gebruikersverkeer apart begrensd; p95-verwerkingstijd blijft gevolgd. |
| Externe API en wachtrij | Leverancier tijdelijk onbereikbaar; 240 taken wachtend. | Beperkte retries; gecontroleerd herverwerkt met controle op dubbele orders. |
| Transactie- en rapportagedatabase | Replicatieachterstand tijdens de import; rapportages tijdelijk minder actueel. | Achterstand hersteld; actualiteitsmelding toegevoegd aan rapportage. |
| Back-ups en herstel | Dagelijkse taken geslaagd; één samenhangende hersteltest van database, files en configuratie uitgevoerd. | Herstelvolgorde en gebruikerscontrole vastgelegd. Dit bewijst niet automatisch herstel bij verlies van een hele regio. |
| Onderhoud en security | Vier updates na acceptatietest uitgevoerd; één compatibility-update vraagt vervolgonderzoek. | Open uitzondering heeft een eigenaar, tijdelijke maatregel en evaluatiedatum. |
Een rapport dat helpt besluiten
Het maandrapport maakt zichtbaar hoe de beheerafspraken in de praktijk worden uitgevoerd.
Je ziet uitgevoerde updates, incidenten en responstijden, relevante beveiligingsmeldingen, back-up- en herstelcontroles, capaciteitsontwikkeling en open acties. Bij iedere actie horen een eigenaar en een volgende stap.
We bespreken ook wat buiten het afgesproken beheer valt, welke afhankelijkheden aandacht vragen en welke verbetering de meeste waarde heeft. Zo blijft beheer begrijpelijk en kun je bijsturen voordat kleine problemen groter worden.