Guides

Self-healing infrastructure: wat het is en wat het niet is

~9 min leestijd

Self-healing infrastructure is IT-infrastructuur die incidenten autonoom detecteert, diagnosticeert en oplost — zonder menselijke tussenkomst voor het gros van de gevallen. De infrastructuur volgt vooraf gedefinieerde policies om herhalende problemen automatisch te remediëren, en escaleert alleen wanneer er sprake is van een nieuw of niet-geclassificeerd incident. Het is geen monitoring, geen alerting, geen runbook-automation, en geen marketinglabel voor operationele software. In dit artikel zetten we de definitie scherp, behandelen de 5 volwassenheidsniveaus, en laten we zien wanneer het wel en niet relevant is voor mkb-MSPs.

1. De definitie, uitgepakt

Self-healing infrastructure bestaat uit drie verplichte componenten. Als er één ontbreekt, is het iets anders.

Detectie

het systeem merkt zelf op dat er iets afwijkt van de gewenste staat. Een service is down, een schijf loopt vol, een certificaat is verlopen, een responsetijd stijgt boven threshold.

Beslissing

het systeem koppelt de detectie aan een vooraf gedefinieerde policy die bepaalt wat er moet gebeuren. Geen mens in de loop voor bekende incidenttypes.

Actie

het systeem voert de remediatie uit, verifieert het resultaat, en logt wat er is gebeurd en waarom.

Detect. Decide. Act.

Alle drie de stappen zijn verplicht. Een systeem dat alleen detecteert is monitoring. Een systeem dat detecteert en beslist maar niet handelt is alerting. Een systeem dat zonder detectie acties uitvoert is een cron-job.

Het verschil zit in de gesloten loop: detectie → beslissing → actie → verificatie, zonder menselijke handeling als schakel.

2. Wat self-healing infrastructure niet is

De term wordt breed gebruikt. Hier de afbakening:

– Monitoring (Datadog, Zabbix, Prometheus) — detecteert afwijkingen en stuurt alerts. De beslissing en actie liggen bij een engineer.
– Alerting (PagerDuty, OpsGenie) — routeert alerts naar de juiste persoon. Geen beslissing, geen actie.
– Runbook documentatie (Confluence, Notion) — beschrijft wat een engineer moet doen. Nuttig, maar passief. Een runbook op papier voert zichzelf niet uit.
– Runbook automation (Rundeck, Ansible) — voert scripts uit na handmatige trigger of goedkeuring. Gedeeltelijk autonoom, maar de beslissing om te starten ligt nog bij een mens.
– Auto-scaling (Kubernetes HPA, AWS Auto Scaling) — schaalt resources autonoom op basis van load. Self-healing binnen één dimensie — capaciteit — maar het handelt niet op incidenten buiten die scope.

Vuistregel

Als een engineer nog een notificatie moet zien, beoordelen en bevestigen voordat er iets wordt opgelost, is het geen self-healing infrastructure. Het is een snellere route naar dezelfde handmatige stap.

3. Vijf volwassenheidsniveaus

Self-healing is geen binaire keuze. Er is een spectrum van handmatig naar autonoom.

Niveau Naam Omschrijving
1 Handmatige response Incident wordt gemeld door gebruiker. Engineer logt in, diagnosticeert, handelt. Geen detectie, geen automatisering.
2 Alert-based response Systeem detecteert en stuurt alert. Engineer beslist en handelt. De loop is nog steeds handmatig.
3 Scripted remediation Bij bepaalde alerts wordt automatisch een script uitgevoerd. Beperkte scope, vaste condities, menselijke goedkeuring of trigger vaak nog vereist.
4 Policy-driven autonomous Systeem detecteert, matcht op een policy, handelt autonoom, verifieert resultaat en logt de actie. Mens wordt alleen geïnformeerd als de remediatie mislukt of het incident buiten de bekende scope valt.
5 Policy recommendation Systeem identificeert terugkerende incidentpatronen en genereert voorstellen voor nieuwe policies. Een engineer beoordeelt, wijzigt en keurt deze voorstellen handmatig goed.
Waar UptimePilot opereert: niveau 3 en 4. Dat is een bewuste ontwerpkeuze. Voor mkb-MSPs zijn expliciete, verifieerbare policies vaak waardevoller dan steeds verdergaande autonomie. Wat een policy doet, kun je op één pagina opschrijven en aan een klant of auditor uitleggen.

4. Wat self-healing in de praktijk oplost

De categorie is breed. Wat wél en niet past in de scope van policy-driven self-healing:

Geschikt voor autonome remediatie

→ Schijf boven threshold — automatisch logs prunen of volume uitbreiden
→ Service onbereikbaar — automatisch herstarten, incident loggen, escaleren bij herhaling
→ SSL-certificaat bijna verlopen — automatisch vernieuwen en valideren
→ Database responsetijd boven threshold — cache flushen of query-optimizer triggeren
→ Backupjob mislukt — automatisch herhalen na interval, engineer informeren bij tweede mislukking
→ Geheugengebruik structureel hoog — process-analyse starten, candidate-processen loggen voor review

Niet geschikt voor autonome remediatie

– Incidenten met onduidelijke root cause (escaleren naar engineer)
– Acties met onomkeerbare impact (data verwijderen, configuratie wijzigen zonder rollback)
– Incidenten buiten de gedekte policy-scope (altijd menselijke beoordeling)
– Nieuwe incidenttypes die nog niet zijn geclassificeerd

De grens is eenvoudig: als de actie omkeerbaar is, de conditie known is, en het resultaat verifieerbaar is — dan is het een kandidaat voor autonome remediatie.

5. Vergelijking met aanverwante categorieën

Categorie Detecteert? Beslist autonoom? Voert uit zonder mens?
Monitoring (Datadog, Zabbix) Ja Nee Nee
Alerting (PagerDuty) Ja Nee Nee
Runbook docs (Confluence) Nee Nee Nee
Runbook automation (Rundeck) Soms Soms Alleen na trigger
Auto-scaling (K8s, AWS ASG) Ja, beperkt Ja, binnen één laag Ja, binnen één laag
Self-healing infrastructure Ja Ja, policy-based Ja

Het onderscheidende kenmerk is niet de detectie — dat doen monitoring-tools al goed. Het onderscheidende kenmerk is de gesloten beslis- en actieloop.

6. Wanneer is self-healing infrastructure relevant voor mkb-MSPs?

Niet elk MSP-profiel heeft dezelfde baat bij self-healing. De relevantie neemt toe naarmate:

Meer relevant

→ Incidentvolume is herhalend — als dezelfde typen incidenten keer op keer terugkomen, is er een gedekte scope voor autonome remediatie
→ After-hours reactietijd is pijnpunt — autonome remediatie handelt onmiddellijk, ook buiten kantoortijden
→ Klantinfrastructuur is homogeen — policies zijn eenvoudiger te schrijven en te onderhouden als de omgevingen op elkaar lijken
→ Engineercapaciteit is schaars — elke L1-handeling die autonoom wordt afgehandeld, is beschikbare tijd voor L2/L3-werk

Minder relevant

– Infrastructuur is sterk heterogeen en incidenttypes zijn vrijwel nooit herhalend
– Klantomgevingen zijn zo klein dat handmatige respons nauwelijks tijd kost
– Compliance-vereisten vragen om menselijke goedkeuring bij elke infrastructuurwijziging

Marge-logica

Stel dat een MSP 50 herhalende L1-tickets per maand verwerkt tegen een interne kostprijs van €60 per ticket. Dan vertegenwoordigt dat ongeveer €3.000 operationele belasting per maand, oftewel €36.000 per jaar. De werkelijke cijfers verschillen per organisatie. Dat is het budget waaruit een self-healing-implementatie zich moet rechtvaardigen.

Zie ook: Wat kost een support ticket gemiddeld voor een Nederlandse MSP? — gedetailleerde kostenopbouw en rekenmodellen.

7. Veelgestelde vragen

Is self-healing infrastructure hetzelfde als monitoring?

Nee. Monitoring detecteert dat er iets afwijkt van de gewenste staat en stuurt eventueel een alert. Self-healing infrastructure sluit de loop: na detectie volgt een policy-gedreven beslissing en een geverifieerde remediatie, zonder menselijke tussenkomst. Een monitoring-tool is een verplicht onderdeel van self-healing, maar geen vervanging ervan.

Hoe weet het systeem welke actie de juiste is?

Via expliciete policies die door engineers worden geschreven, getest en versie-gecontroleerd. Een policy bestaat uit een conditie ("disk-usage > 90% op productieserver") en een actie ("prune logs ouder dan 30 dagen, verifieer onder 80%"). Er is geen black box: elke autonome actie is herleidbaar naar één regel die je in een audit-trail kunt teruglezen.

Wat als het systeem de verkeerde beslissing neemt?

Goed ingerichte self-healing handelt alleen op omkeerbare acties met verifieerbare resultaten. Als de policy-actie mislukt of het resultaat buiten verwachting valt, escaleert het systeem naar een engineer. De policy-scope bepaalt de veiligheidsgrens.

Is self-healing hetzelfde als runbook automation?

Nee. Runbook automation voert scripts uit op basis van een handmatige trigger of goedkeuring. Self-healing infrastructure beslist zelf wanneer actie nodig is, op basis van real-time detectie. Het verschil is wie de beslissing neemt: een engineer (runbook automation) of een policy (self-healing).

Heb je een groot team nodig om self-healing te implementeren?

Niet per definitie. Veel self-healing platforms werken op basis van vooraf gedefinieerde integrations en policies. Voor mkb-MSPs is de instapdrempel in veel gevallen lager dan verwacht — met name voor de meest voorkomende L1-incidenttypes.

Hoe UptimePilot dit aanpakt

UptimePilot is het autonomous infrastructure platform voor mkb-MSPs. Het biedt policy-driven remediation zonder ondoorzichtige besluitvorming en zonder integratie-marathons.

→ Detectie op infrastructuurlaag — services, opslag, connectiviteit, certificaten
→ Policy-engine — bekende incidenttypes matchen op gedefinieerde remediatie-acties
→ Verificatie na elke actie — escalatie bij mislukking of onbekend patroon
→ Auditlog — elke autonome handeling herleidbaar naar de policy die is gevolgd

UptimePilot vervangt geen RMM of PSA. Het voegt een beslis- en actielaag toe tussen detectie en menselijke interventie — het gat waar nu nog engineers zitten voor incidenten die zichzelf eigenlijk kunnen oplossen.

Lees ook: Wanneer is autonomous remediation veilig? · Waarom monitoring alleen geen uptime oplost · Wat is policy-driven remediation? · Hoe verlaag je ticketvolume zonder klantervaring te schaden · Wat kost een support ticket gemiddeld voor een Nederlandse MSP?

Volgende stap

Welke incidenten in jouw omgeving zijn geschikt voor autonome remediatie?

Bekijk welke incidenttypes UptimePilot automatisch detecteert, beoordeelt en oplost — voordat een gebruiker een ticket opent.

Plan een demo →