Databasebeheer uitbesteden: wat dat voor het mkb inhoudt

De meeste mkb-bedrijven die contact opnemen over databasebeheer uitbesteden zitten niet midden in een eenmalig project. Ze hebben al een migratie achter de rug, of hebben een systeem overgenomen dat prima werkt, en willen vooral iemand die het dag in dag uit draaiend houdt: gepatcht, met werkende back-ups, gemonitord en snel, zonder dat iemand in het team er per ongeluk halve dagen databasebeheerder van wordt. Die doorlopende verantwoordelijkheid, en niet een eenmalige migratie, staat in deze gids centraal.

Databasebeheer uitbesteden: wat dat behelst

"Een database beheren" klinkt als één taak. In de praktijk zijn het er meerdere, die continu doorlopen in plaats van eenmalig:

• Monitoring en alarmering. Iemand houdt opslaggroei, queryprestaties en foutlogs scherp genoeg in de gaten om een trage query op te merken voordat die uitgroeit tot een storing, niet erna.
• Back-up en herstel, getest en niet aangenomen. Een back-upjob die elke nacht draait, is niet hetzelfde als een back-up waaruit u onder druk daadwerkelijk kunt herstellen. Het testen van een restore is precies de stap die bij eigen beheer vaak wordt overgeslagen, omdat die meestal pas tijdens een echt incident voor het eerst serieus wordt getest.
• Patches en versie-upgrades. Databasesystemen brengen beveiligingsupdates uit volgens hun eigen schema, los van de releasecyclus van uw applicatie. Een ongepatchte database achter een goed beveiligde applicatie blijft een doelwit.
• Prestatieoptimalisatie. Indexen, queryplannen en instellingen die vorig jaar bij het datavolume van toen prima werkten, worden dat steeds minder naarmate het bedrijf groeit. Meestal merkt niemand dat tot een rapportage die ooit seconden kostte, plotseling minuten duurt.
• Toegangsbeheer. Wie welke tabellen mag lezen, wie mag schrijven, en of dat nog steeds klopt met wie het daadwerkelijk nodig heeft, ook een half jaar na het vertrek van wie de rechten ooit instelde.
• Capaciteit en kosten. Opslag, rekenkracht en de bewaartermijn van back-ups schalen allemaal mee met het datavolume en kosten allemaal geld. Iemand moet dat bewaken, in plaats van het pas op de factuur te ontdekken.

Niets hiervan heeft een crisis nodig om ertoe te doen. Goed uitgevoerd is het onzichtbaar. Slecht uitgevoerd wordt het zichtbaar als downtime, een back-up die niet terug te zetten is, of in het slechtste geval een datalek dat niemand heeft zien aankomen.

Signalen dat uw database aandacht nodig heeft

Een aantal patronen duikt meestal op voordat een database een actief probleem wordt:

• Alle kennis zit bij één persoon. Weet maar één medewerker hoe de database is ingericht, waar de back-ups staan en wanneer het onderhoudsvenster valt? Dan hebt u geen beheerd systeem, maar één single point of failure die ook nog toevallig de enige is die het kan oplossen.
• "We denken dat de back-ups werken." Niemand heeft recent echt een volledige restore geprobeerd. Dit is de meest voorkomende tekortkoming die we tegenkomen, en degene die vrijwel altijd op het slechtst mogelijke moment aan het licht komt.
• Prestatieklachten zonder duidelijke eigenaar. Rapportages en dashboards worden trager, en het antwoord is meer hardware erbij in plaats van uitzoeken waarom, omdat niemand specifiek verantwoordelijk is voor de optimalisatie.
• Patches stapelen zich op omdat niemand iets durft te breken. Beveiligingsupdates raken vertraagd voorbij een redelijke termijn, omdat de laatste keer dat iemand er een toepaste een storing veroorzaakte, en er geen getest proces is om ze veilig door te voeren.
• De database is uit het informele beheer gegroeid. Wat begon als "wie toevallig tijd heeft, pakt het op" draait inmiddels echte omzet, en die informele afspraak is niet meegegroeid.

Herkent u meer dan één van deze signalen, dan is de vraag niet of u iets moet doen, maar of de oplossing zelf aannemen, uitbesteden of een combinatie van beide is.

Zelf doen, uitbesteden of een hybride vorm

Er is geen vast juist antwoord. Het hangt af van hoeveel doorlopende aandacht uw databases daadwerkelijk nodig hebben en hoe centraal ze zijn voor de bedrijfsvoering.

Zelf doen is logisch als het werk echt een volledige functie vult, de database diep verweven is met bedrijfslogica die alleen uw eigen team begrijpt, of de gevoeligheid van de data maakt dat u geen externe toegang wilt verlenen. Bij een laag volume is het bovendien simpelweg duurder: één vaste medewerker kost een volledig salaris, of uw database nu tien uur per week aandacht nodig heeft of veertig.

Uitbesteden is voor de meeste mkb-bedrijven logisch, precies omdat databasebeheer niet lineair meeschaalt met de bedrijfsgrootte. Een bedrijf met tien medewerkers en een bedrijf met honderd medewerkers kunnen qua databaseonderhoud een factor twee verschillen, niet een factor tien, en dat is precies het soort werklast dat een gedeeld specialistenteam efficiënter opvangt dan een eigen vaste aanstelling.

Een hybride vorm is in de praktijk het meest gangbare antwoord. Uw eigen team, of een generalistische IT-partner, houdt de eigenaarschap over de bedrijfslogica, het datamodel en wat de applicatie precies van de database nodig heeft, terwijl een specialist de operationele laag daaronder voor zijn rekening neemt: patches, back-upverificatie, prestatieoptimalisatie en incidentrespons. Dit sluit ook vaak aan op de bredere IT-ondersteuning: onze gids over de IT-servicedesk uitbesteden behandelt dezelfde afweging tussen zelf doen, uitbesteden en een hybride vorm voor ondersteuning in het algemeen, en databasewerk is vaak één specifieke laag van die bredere keuze, niet een volledig losstaande beslissing.

Wat een uitbestede databasebeheerdienst meestal omvat

De omvang verschilt per leverancier, maar een serieuze dienst voor databasebeheer dekt doorgaans:

• Monitoring, 24/7 of tijdens kantooruren, met vooraf afgesproken alarmeringsdrempels, niet pas ontdekt tijdens een incident.
• Beheerd patchen volgens een vast ritme, eerst getest tegen een kopie buiten productie voordat het de live database raakt.
• Back-upbeheer inclusief periodieke restore-tests, niet alleen back-upjobs die draaien, maar bewijs dat ze ook werken.
• Prestatieoptimalisatie als doorlopende activiteit, niet als eenmalige noodreparatie zodra iets eindelijk vastloopt.
• Vastgelegde incidentrespons met een benoemde reactietijd, zodat "er kijkt wel iemand naar" een echte SLA wordt.
• Periodieke rapportage over wat er is aangepast, wat er is gepatcht en wat richting een probleem beweegt.

Dit is een andere scope dan een eenmalige datamigratie: een migratie brengt een database van de ene plek of versie naar de andere en is daarna klaar. Beheer is het doorlopende werk dat begint zodra de database op zijn nieuwe plek is geland en doorloopt zolang die in productie staat. Beide volgen elkaar vaak op, eerst migreren, dan het resultaat overdragen aan doorlopend beheer, maar ze worden anders geprijsd, anders bemand en anders afgebakend. Is een leverancier vaag over welke van de twee hij u offreert, stel die vraag dan rechtstreeks.

Een specifieke, veelvoorkomende variant hiervan is het tijdig beheren van een naderend einde van ondersteuning: een databaseversie die op een vaste datum geen beveiligingspatches van de leverancier meer krijgt, zoals we specifiek beschreven voor SQL Server 2016, is precies het soort risico dat doorlopend beheer jaren van tevoren moet signaleren, niet pas de week dat de ondersteuning afloopt.

Uw databasepartner is meestal ook verwerker onder de AVG

Staat er klant- of personeelsdata of iets anders onder de AVG in de database die wordt beheerd? Dan is databasebeheer uitbesteden niet alleen een operationele keuze, maar ook een gegevensbeschermingskeuze, en dat is precies het onderdeel dat mkb-bedrijven het vaakst overslaan.

Een leverancier die toegang heeft tot die data om te monitoren, te patchen, te optimaliseren of te herstellen, is onder de AVG een *verwerker*. Uw bedrijf blijft de *verwerkingsverantwoordelijke*: de partij die bepaalt waarom de data wordt verwerkt en hoe. Artikel 28 van de AVG verplicht een schriftelijke verwerkersovereenkomst tussen beide partijen voordat dat werk begint. Zonder die overeenkomst zijn beide partijen in overtreding, niet alleen degene die erom had moeten vragen. Die overeenkomst moet de daadwerkelijke omvang van het werk vastleggen (wat de leverancier wel en niet met de data mag doen), de geheimhoudingsplicht van iedereen bij de leverancier die de data kan zien, de beveiligingsmaatregelen waartoe die zich verplicht, wat er gebeurt met een onderaannemer die wordt ingeschakeld (waarvoor u vooraf schriftelijk toestemming moet geven), en wat er met de data gebeurt zodra de samenwerking stopt.

Één detail struikelt mensen specifiek bij databasebeheer: krijgt de leverancier te maken met een datalek dat uw data raakt, bijvoorbeeld omdat de eigen systemen zijn gecompromitteerd, dan is die verplicht u daarover onverwijld te informeren. Maar de leverancier mag dat lek alleen zelf melden bij de Autoriteit Persoonsgegevens als u daar vooraf expliciet toestemming voor hebt gegeven. De meldtermijn van 72 uur blijft uw verantwoordelijkheid om te bewaken, ook als het incident op de infrastructuur van de leverancier plaatsvond. De verwerkersovereenkomst moet daarom ook precies vastleggen hoe en hoe snel de leverancier u informeert: een telefoontje op zaterdagochtend naar de juiste persoon, geen ticket dat tot maandag in een wachtrij blijft liggen.

Dit alles is geen reden om databasebeheer niet uit te besteden. Het is een reden om de verwerkersovereenkomst als onderdeel van het voorstel te vragen, en niet pas als bijzaak zodra de samenwerking al loopt.

Wat u vastlegt voordat u tekent

• Reactietijd per ernstniveau, niet één SLA-cijfer. "Vier uur reactietijd" betekent iets anders voor een traag dashboard dan voor een productiedatabase die plat ligt. Vraag om niveaus.
• Wie een restore initieert, en hoe snel. Weten dat er een back-up bestaat is iets anders dan weten wie u om twee uur 's nachts precies belt en hoe lang een volledige restore werkelijk duurt.
• Afspraken over data-export, op papier. Dezelfde vraag die we stellen in onze gids over [vendor lock-in voorkomen](/nl/articles/vendor-lock-in-voorkomen) is hier rechtstreeks van toepassing: kunt u uw data en uw configuratie er in een bruikbaar formaat uit krijgen als u ooit van leverancier wisselt?
• De verwerkersovereenkomst, met de bovengenoemde punten, getekend voordat toegang wordt verleend, niet erna.
• Een overdrachtsplan, ook als u nooit denkt het nodig te hebben: actuele documentatie van de huidige configuratie, zodat een toekomstige leverancier, of uw eigen team, niet vanaf nul begint.

Veelgestelde vragen

Wat is het verschil tussen databasebeheer en een datamigratie? Een migratie brengt een database naar een nieuwe versie, platform of leverancier en is daarna klaar. Beheer is het doorlopende werk, monitoring, patches, back-ups, optimalisatie, dat doorloopt zolang de database in productie blijft. Staat u aan de vooravond van een overstap in plaats van op zoek naar doorlopende zorg erna, lees dan onze gids over datamigratie.

Hebben we nog iemand intern nodig als we databasebeheer uitbesteden? Meestal wel, maar in een andere rol. Iemand bij u houdt doorgaans de eigenaarschap over het datamodel en wat het bedrijf daadwerkelijk van de database nodig heeft; de uitbestede partij beheert de operationele laag daaronder. Volledige overdracht zonder interne eigenaar is ongewoon en leidt vaak juist tot het single-point-of-knowledge-probleem dat uitbesteden zou moeten oplossen.

Is het veilig om een externe partij een database met klantgegevens te laten beheren? Dat kan, mits de leverancier formeel verwerker wordt onder een getekende verwerkersovereenkomst die de omvang, de beveiligingsmaatregelen, onderaannemers en datalekmelding vastlegt. Vraag om die overeenkomst als onderdeel van het voorstel, voordat u toegang verleent, niet erna.

Hoe wordt uitbesteed databasebeheer meestal geprijsd? Dat verschilt per leverancier: een vast maandbedrag, prijsniveaus per SLA, of op basis van gebruik. We noemen hier bewust geen vast bedrag, want dat hangt sterk af van de omvang en het belang van de database en hoeveel optimalisatiewerk er daadwerkelijk nodig is. Bij mkb-bedrijven valt het vaak binnen een bredere afspraak voor IT-beheer in plaats van als losse post. Onze gids over wat IT-beheer per werkplek kost laat zien hoe die bredere prijsopbouw doorgaans werkt.

Wat gebeurt er met onze data als we later van leverancier wisselen? Dat is precies het soort afhankelijkheid die u controleert voordat u tekent, niet op het moment dat u wilt vertrekken. Onze gids over vendor lock-in voorkomen beschrijft specifiek wat u moet nagaan over data-export en eigenaarschap van de configuratie.

De operationele laag op orde

Een database die wordt gemonitord, met getest herstelbare back-ups, volgens schema gepatcht en gedekt door een echte verwerkersovereenkomst, is infrastructuur waar u niet meer over hoeft na te denken, en dat is precies het doel van uitbesteden. Ons team Data & databases verzorgt precies dit soort doorlopend beheer naast migraties en analysewerk, ons team IT-beheer & support kan het opnemen in een bredere IT-afspraak als dat beter bij u past, en ons team Cybersecurity & identiteit kan de toegangsbeheerkant van een bestaande database beoordelen als dat specifiek de vraag is.