Guides
Wat is policy-driven remediation? Van runbooks naar autonome incidentafhandeling
Policy-driven remediation is geautomatiseerde incidentafhandeling waarbij een systeem op basis van vooraf gedefinieerde policies bepaalt welke actie moet worden uitgevoerd bij een specifiek type incident — en die actie zelfstandig uitvoert, verifieert en logt. Het verschilt van scripting doordat de beslissingslogica losstaat van de uitvoering, van runbook-automation doordat geen mens de trigger hoeft te geven, en van handmatige response doordat de gehele loop — van detectie tot verificatie — zonder menselijke tussenkomst verloopt voor bekende incidenttypes.
1. Het uitvoeringsprobleem
De meeste MSPs hebben geen detectieprobleem. Ze hebben een uitvoeringsprobleem.
Monitoring werkt. Alerts komen binnen. En dan begint het echte werk: een engineer leest de alert, opent een ticket, zoekt het runbook op, voert de stappen uit, verifieert het resultaat, sluit het ticket. Voor een incident dat vorige week ook al voorkwam. En de week daarvoor.
Het probleem is niet dat niemand weet wat er moet gebeuren. Het probleem is dat bij elk incident opnieuw een mens moet besluiten om het te doen. Policy-driven remediation lost precies dat op: het koppelt de bekende oplossing aan het bekende probleem, en voert die uit zonder te wachten op een engineer.
Van handmatig naar policy-driven: wie beslist?
| Aanpak | Wie beslist? | Wie voert uit? | Loop gesloten? |
|---|---|---|---|
| Handmatige response | Engineer | Engineer | Nee |
| Runbook (documentatie) | Engineer | Engineer | Nee |
| Scripted automation | Engineer triggert | Script | Gedeeltelijk |
| Runbook automation | Engineer keurt goed | Tool | Gedeeltelijk |
| Policy-driven remediation | Policy | Systeem | Ja |
Vuistregel
Als een engineer nog moet bevestigen voordat er iets wordt opgelost, is het runbook automation. Als de policy beslist en de engineer alleen achteraf de log ziet: dat is policy-driven remediation.
2. Hoe een policy werkt
Een policy is een gestructureerde regel die drie dingen vastlegt:
Wanneer wordt deze policy getriggerd? Dit is een specifiek, meetbaar signaal: disk usage > 90%, service X niet bereikbaar na health check, certificaat verloopt binnen 14 dagen, response time boven threshold.
Wat moet er gebeuren? De actie is vooraf gedefinieerd, herhaalbaar en omkeerbaar: service herstarten, tijdelijke bestanden opruimen, DNS-failover activeren, of escaleren naar een engineer met de juiste context.
Heeft de actie het gewenste resultaat opgeleverd? Na uitvoering controleert het systeem of de situatie is genormaliseerd. Zo ja: log en sluit. Zo nee: escaleer alsnog.
De policy-loop
Het verschil met een script is dat de policy niet zegt hoe iets technisch wordt uitgevoerd, maar wanneer en waarom. De uitvoeringslaag is gescheiden van de beslissingslaag. Daardoor kun je dezelfde policy toepassen op verschillende omgevingen, klanten en technologieën zonder de logica te herschrijven.
3. Automated remediation vs. runbook automation: het verschil
De termen worden vaak door elkaar gebruikt. Dat is verwarrend, want het verschil is fundamenteel.
Runbook automation
De uitvoering is geautomatiseerd. Het script draait sneller dan een engineer het handmatig zou doen. Maar de beslissing om het script te starten — die ligt nog steeds bij een mens. Iemand moet de alert zien, beoordelen, en bevestigen dat de automation mag draaien.
Policy-driven remediation
De beslissing is geautomatiseerd. De engineer heeft die beslissing al genomen op het moment dat de policy werd goedgekeurd — niet op het moment dat het incident zich voordoet.
Runbook automation schaalt met het aantal engineers (iemand moet nog steeds goedkeuren). Policy-driven remediation schaalt met het aantal policies — elke nieuwe policy dekt een extra incidenttype af, zonder extra menselijke capaciteit.
4. Waarom de meeste MSPs nooit voorbij runbooks komen
Het obstakel is zelden technisch. MSPs die vastzitten tussen niveau 2 en 3 in de self-healing volwassenheidsladder hebben de ingrediënten al in huis: monitoring draait, runbooks bestaan, engineers kennen de oplossingen. Wat ontbreekt is governance — niemand heeft formeel vastgelegd welke beslissingen het systeem mag nemen zonder menselijke tussenkomst.
Het vertrouwensgat
Engineers vertrouwen automation niet genoeg om de beslissing uit handen te geven. Niet omdat de techniek onbetrouwbaar is, maar omdat er geen expliciete afspraak is over wat wel en niet autonoom mag. Zonder die afspraak voelt elke autonome actie als een risico.
De runbook-illusie
Het bestaan van een runbook voelt als vooruitgang. "We hebben het gedocumenteerd, dus we zijn geautomatiseerd." Maar een runbook dat in Confluence staat en door een engineer wordt uitgevoerd is geen automation — het is gestandaardiseerde handarbeid.
De perfectieval
Teams willen pas automatiseren als alles perfect is gedocumenteerd, alle edge cases zijn afgedekt, en het systeem nooit faalt. Die drempel wordt nooit bereikt. Ondertussen blijven dezelfde incidenten handmatig worden opgelost.
De oplossing is niet "meer vertrouwen in technologie." De oplossing is een expliciete policy: een document dat vastlegt welke conditie tot welke actie leidt, hoe het resultaat wordt geverifieerd, en wanneer er wordt geëscaleerd. Dat is governance, niet techniek.
5. Welke incidenten zijn geschikt voor policies?
Niet elk incident is geschikt voor autonome afhandeling. De vuistregel: hoe vaker het voorkomt, hoe voorspelbaarder het patroon, en hoe omkeerbaarder de actie, hoe geschikter het is voor een policy.
Geschikt voor policies
Niet geschikt (escaleer naar engineer)
De grens is niet technisch maar operationeel: kun je de beslissing op voorhand nemen, of vereist het incident oordeel op het moment zelf?
6. Drie fouten die MSPs maken bij automation
Scripts bouwen in plaats van policies definiëren
Scripts lossen één probleem op, op één plek, op één manier. Dat werkt — totdat je honderd klanten hebt met elk hun eigen variaties. Policy-driven remediation scheidt de logica van de implementatie: dezelfde policy werkt ongeacht de onderliggende omgeving.
Automatiseren zonder verificatie
Een script dat een service herstart maar niet controleert of de service daarna ook daadwerkelijk draait, creëert een vals gevoel van controle. Policy-driven remediation zonder verificatiestap is potentieel gevaarlijker dan handmatig werken — omdat niemand meer kijkt.
Alles tegelijk willen automatiseren
De meest succesvolle implementaties beginnen met vijf tot tien incidenttypes die het vaakst voorkomen en de minste risico's dragen. De eerste policies moeten saai zijn — juist omdat de waarde zit in volume, niet in complexiteit.
7. Plek in de volwassenheidsladder
In de self-healing volwassenheidsniveaus is policy-driven remediation niveau 4: het systeem detecteert, matcht op een policy, handelt autonoom, verifieert en logt. De stappen ernaartoe zijn niet optioneel.
Van handmatig naar alert-based
Je monitoring-stack geeft signaal op de juiste plekken. Zonder betrouwbare detectie heeft een policy niets om op te triggeren.
Van alerts naar scripted remediation
Je hebt runbooks gedocumenteerd en de meest voorkomende omgezet naar scripts. Je weet wat de oplossing is — je voert hem alleen nog handmatig uit.
Van scripts naar policies
De scripts die geschikt zijn voor autonome uitvoering worden gewrapped in policies met condities, acties en verificatie. De engineer verdwijnt uit de loop voor bekende incidenttypes.
8. Veelgestelde vragen
Wat is het verschil tussen een policy en een script?
Een script beschrijft hoe een taak technisch wordt uitgevoerd. Een policy beschrijft wanneer en waarom een actie wordt ondernomen, inclusief de condities voor activering en de verificatie na afloop. Een script kan onderdeel zijn van een policy — als de uitvoeringslaag — maar de beslissingslogica zit in de policy, niet in het script.
Is policy-driven remediation hetzelfde als runbook automation?
Nee. Bij runbook automation triggert een mens de uitvoering — door goedkeuring te geven, een knop te klikken of een workflow te starten. Bij policy-driven remediation triggert het systeem zelf op basis van real-time detectie en vooraf gedefinieerde condities. Het verschil is wie beslist: een engineer of een policy.
Hoe weet ik welke incidenten geschikt zijn voor een policy?
Begin bij frequentie en voorspelbaarheid. Incidenten die vaak voorkomen, een bekende oorzaak hebben, een gestandaardiseerde oplossing kennen en een omkeerbare actie vereisen, zijn de beste kandidaten. In de praktijk zijn dat meestal de incidenten waar je team het minste energie aan wil besteden — juist omdat ze zo voorspelbaar zijn.
Wat als de policy de verkeerde actie uitvoert?
Een goed ontworpen policy handelt alleen op omkeerbare acties met verifieerbare resultaten. Als de verificatie faalt — de service draait niet na herstart, de disk is niet vrijgemaakt — escaleert het systeem automatisch naar een engineer. De policy-scope bepaalt de veiligheidsgrens: wat een policy mag doen, is expliciet vastgelegd.
Moet ik al mijn runbooks omzetten naar policies?
Nee. Niet elk runbook is geschikt voor autonome uitvoering. Runbooks die context-afhankelijke beoordeling vereisen, niet-omkeerbare acties bevatten of communicatie met de klant veronderstellen, blijven bij een engineer. De sterkste implementaties combineren policy-driven remediation voor het voorspelbare werk met menselijke expertise voor het onvoorspelbare.
Is policy-driven remediation hetzelfde als automated incident response?
De termen overlappen, maar automated incident response is breder. Het omvat ook detectie, triage en communicatie. Policy-driven remediation richt zich specifiek op het autonome beslissings- en uitvoeringsmoment: de policy bepaalt de actie, het systeem voert uit en verifieert. Het is het mechanisme binnen een bredere incident response workflow, niet de hele workflow zelf.
9. Waar op te letten bij een policy-engine
Niet elke tool die "automation" claimt werkt op basis van policies. Bij de evaluatie van een platform voor policy-driven remediation zijn vijf eigenschappen bepalend:
Expliciete condities
De trigger voor een policy moet specifiek en meetbaar zijn, niet een vaag signaal. Je moet kunnen opschrijven wat de conditie is en die aan een collega of klant kunnen uitleggen.
Gescheiden beslissings- en uitvoeringslaag
De logica die bepaalt wanneer er wordt gehandeld moet losstaan van de technische uitvoering. Anders bouw je scripts met een policy-label erop.
Verificatie na elke actie
Het systeem moet controleren of de actie het gewenste resultaat heeft opgeleverd. Zonder verificatie is autonome uitvoering onverantwoord.
Audit trail
Elke autonome handeling moet herleidbaar zijn naar de policy die is gevolgd, de conditie die is getriggerd, en het verificatieresultaat. Voor MSPs is dit niet optioneel — klanten en auditors verwachten het.
Escalatie als vangnet
Het systeem moet weten wanneer het niet moet handelen. Een goede policy-engine escaleert bij onbekende patronen, mislukte verificaties of situaties buiten de gedefinieerde scope.
Hoe UptimePilot dit aanpakt
UptimePilot is een autonomous infrastructure platform voor mkb-MSPs, gebouwd rond policy-driven remediation als kernmechanisme. De vijf eigenschappen hierboven zijn geen checklist achteraf — ze zijn de ontwerpbasis van het platform.
UptimePilot vervangt geen RMM of PSA. Het voegt de beslis- en actielaag toe die daar nu ontbreekt.
Volgende stap
Welke van jouw herhalende incidenten zijn geschikt voor policy-driven remediation?
Bekijk welke incidenttypes UptimePilot automatisch detecteert, beoordeelt en oplost — voordat een gebruiker een ticket opent.