Guides
Policy-driven remediation vs runbook automation — wat is het verschil?
Het verschil tussen runbook automation en policy-driven remediation is niet wie uitvoert, maar wie beslist. Bij runbook automation triggert een engineer de uitvoering — door een script te starten, een workflow goed te keuren of een knop te klikken. Bij policy-driven remediation beslist het systeem zelf, op basis van real-time detectie en vooraf gedefinieerde condities. Beide aanpakken automatiseren het uitvoeringswerk. Maar alleen bij policy-driven remediation is de beslisloop gesloten: detectie → beslissing → actie → verificatie, zonder mens als schakel.
1. Definitie van beide termen
Runbook automation is het geautomatiseerd uitvoeren van gedocumenteerde stappen nadat een engineer de trigger geeft. De engineer bepaalt óf er wordt gehandeld, de tooling bepaalt hoe. De beslissing blijft menselijk; de uitvoering wordt sneller.
Policy-driven remediation is geautomatiseerde incidentafhandeling waarbij het systeem op basis van een policy bepaalt welke actie nodig is bij een specifiek type incident — en die actie zelfstandig uitvoert, verifieert en logt. De engineer definieert de policy vooraf; het systeem past hem toe zonder tussenkomst.
Kernonderscheid
Runbook automation versnelt het bestaande proces. Policy-driven remediation vervangt de menselijke schakel in het beslismoment. Het verschil klinkt subtiel, maar de operationele consequenties zijn fundamenteel.
2. De kernverschillen
De volgende tabel maakt één ding zichtbaar: runbook automation schaalt met mensen, policy-driven remediation schaalt met regels. Voor een MSP met tien klanten is dat verschil beheersbaar. Voor een MSP met honderd klanten bepaalt het de operationele houdbaarheid.
| Dimensie | Runbook automation | Policy-driven remediation |
|---|---|---|
| Trigger | Engineer (handmatig) | Systeem (real-time detectie) |
| Beslissing | Engineer keurt goed | Policy beslist autonoom |
| Loop gesloten? | Nee | Ja |
| After-hours | Afhankelijk van piket | Direct |
| Audit trail | Optioneel | Verplicht |
| Schaalbaarheid | Met team | Met policies |
Beide aanpakken vereisen een betrouwbare monitoring-stack als signaallaag. Maar bij runbook automation is de monitoring een notificatiekanaal — iemand moet de alert lezen en handelen. Bij policy-driven remediation is de monitoring een triggerlaag — het systeem handelt zodra de conditie is gemeten.
Een ander verschil dat in de praktijk zwaarder weegt dan verwacht: de audit trail. Bij runbook automation is logging optioneel en afhankelijk van discipline. Bij policy-driven remediation is het verplicht onderdeel van de loop — elke actie is herleidbaar naar de policy die is gevolgd, de conditie die is getriggerd, en het verificatieresultaat. Voor MSPs die aan klanten of auditors verantwoording afleggen, is dat geen luxe.
3. Wanneer kies je welke?
Runbook automation is het logische startpunt. Het is de gestructureerde versie van wat de meeste MSPs al doen: stappen documenteren en de uitvoering (deels) automatiseren. Als een MSP nog geen gedocumenteerde processen heeft voor de meest voorkomende incidenttypes, is runbook automation de eerste stap — niet policy-driven remediation.
De overgang naar policy-driven is relevant wanneer drie patronen zichtbaar worden:
Herhalingsvolume
Dezelfde incidenttypes komen structureel terug en de oplossing is telkens identiek. Runbooks worden niet meer gelezen — engineers kennen de stappen uit hun hoofd.
After-hours druk
Incidenten buiten kantoortijden vereisen piketdienst of worden pas de volgende ochtend opgepakt. De reactietijd is niet technisch maar organisatorisch begrensd.
Beslissingsplafond
Het knelpunt is niet de uitvoering maar de goedkeuring. Engineers bevestigen routinematig acties die ze in hun slaap kunnen uitvoeren.
In het MSP Automation Maturity Model zit dit omslagpunt tussen niveau 3 (scripted remediation) en niveau 4 (policy-driven autonomous). De meeste mkb-MSPs bevinden zich ergens tussen niveau 2 en 3.
Keuze per incidenttype
| Situatie | Runbook | Policy |
|---|---|---|
| Service restart na crash | ✓ | ✓ |
| Certificaatvernieuwing | ✓ | ✓ |
| Disk cleanup bij threshold | ✓ | ✓ |
| DNS-failover bij onbereikbaarheid | ✓ | ✓ |
| Database corruption | ✓ | ✗ |
| Klantcommunicatie bij incident | ✓ | ✗ |
| Security incident response | ✓ | Meestal ✗ |
| Onbekend incidenttype | ✓ | ✗ |
Voorspelbaar, herhaalbaar, omkeerbaar — dat is het domein waar policy-driven remediation waarde toevoegt. Incidenten die context-afhankelijke beoordeling vereisen, blijven bij de engineer.
4. De overgang van runbook naar policy
De overgang is geen big bang. De meest succesvolle implementaties zijn incrementeel.
Selecteer kandidaat-runbooks
Begin met runbooks die het vaakst worden uitgevoerd, een voorspelbare oorzaak hebben, een gestandaardiseerde oplossing kennen en een omkeerbare actie vereisen. In de praktijk zijn dat de incidenten waar engineers de minste energie aan willen besteden — juist omdat ze zo voorspelbaar zijn.
Formaliseer de beslissing
Vertaal het impliciete beslismoment van de engineer naar een expliciete conditie. "Als disk-usage boven 90% op een productieserver" is een policy-conditie. "Als het er slecht uitziet" is dat niet.
Begin in assisted mode
Laat het systeem de policy matchen en de actie voorstellen, maar laat de engineer nog goedkeuren. Dit bouwt vertrouwen op en vangt edge cases vroeg af.
Activeer autonoom voor gevalideerde policies
Na voldoende runs zonder interventie schakelt de engineer uit de loop. Het systeem handelt, verifieert en logt. De engineer ziet alleen de resultaten.
Realistische tijdlijn
Twee tot vier weken voor de eerste drie tot vijf policies in assisted mode, nog eens vier tot zes weken voor de eerste autonome policies. De tijdlijn hangt meer af van organisatorische bereidheid dan van technische complexiteit.
5. Veelgestelde vragen
Is policy-driven remediation een vervanging van runbooks?
Nee. Runbooks blijven waardevol voor incidenten die context-afhankelijke beoordeling vereisen, niet-omkeerbare acties bevatten of menselijke communicatie met de klant veronderstellen. Policy-driven remediation vervangt niet het runbook als document — het vervangt de engineer als trigger voor de uitvoering, en alleen voor incidenttypes waarvoor de beslissing op voorhand genomen kan worden.
Hoe lang duurt de overgang van runbook automation naar policy-driven?
De technische implementatie van een eerste set policies is in weken te realiseren. De organisatorische shift — van een team dat uitvoert naar een team dat beleid definieert en valideert — duurt typisch langer, afhankelijk van de cultuur en het vertrouwen in autonome acties. De meeste MSPs starten met drie tot vijf policies en breiden uit op basis van resultaten.
Welke runbooks zijn geschikt om om te zetten naar policies?
Runbooks die voldoen aan vier criteria: het incident komt frequent voor, de oorzaak is voorspelbaar, de oplossing is gestandaardiseerd, en de actie is omkeerbaar. In de praktijk zijn dat typisch service-herstarts, disk cleanup, certificaatvernieuwing en vergelijkbare L1-handelingen. Runbooks die diagnosestappen bevatten of context-afhankelijke keuzes vereisen, blijven bij een engineer.
Hoe UptimePilot dit aanpakt
UptimePilot is een autonomous infrastructure platform voor mkb-MSPs, gebouwd rond policy-driven remediation als kernmechanisme. De overgang van runbook automation naar policy-driven is geen migratie — het is een toevoeging. UptimePilot vervangt geen bestaande runbook-tooling of RMM. Het voegt de beslis- en actielaag toe die tussen detectie en menselijke interventie ontbreekt: de policy bepaalt de actie, het systeem voert uit en verifieert, en elke handeling is herleidbaar in de audit trail.
Volgende stap
Welke van jouw runbooks komen in aanmerking voor policy-driven remediation?
Bekijk hoe UptimePilot de stap zet van runbook automation naar een gesloten beslisloop — zonder je bestaande tooling te vervangen.