Branded framework · UptimePilot
UptimePilot Incident Reduction Framework
Vijf fasen van classificatie tot leren — het operationele kader waarmee UptimePilot herhalende infrastructuurincidenten bij mkb-MSPs autonoom terugdringt.
De meeste MSP-incidenten zijn niet uniek. Ze zijn herhalend — dezelfde symptomen, dezelfde oorzaken, dezelfde handelingssequentie. Dat gegeven is de basis van het UptimePilot Incident Reduction Framework (IRF): als een incident een herkenbaar signaal, een vaste handelingssequentie en een verifieerbaar resultaat heeft, is gecontroleerde automatisering mogelijk. Het IRF beschrijft in vijf fasen hoe die automatisering er in de praktijk uitziet — van de eerste classificatie tot het leren na afloop.
1. Wat is het Incident Reduction Framework?
Het Incident Reduction Framework (IRF) is het operationele kader dat UptimePilot gebruikt om herhalende infrastructuurincidenten bij mkb-MSPs autonoom af te handelen. Het is de uitvoeringslaag achter het Detect. Decide. Act. principe.
Het IRF bestaat uit vijf fasen die elk incident doorloopt — van de eerste detectie tot het leren na afloop. Elke fase heeft een duidelijke conditie voor doorstroming, een duidelijk escalatiepad als die conditie niet wordt vervuld, en een auditeerbare uitkomst.
De vijf fasen zijn: classificeren, isoleren, remediëren, verifiëren en leren. Samen beschrijven ze het volledige traject dat een incident doorloopt — van het moment dat het signaal binnenkomt tot het moment dat de kennis uit de afhandeling is verwerkt in de policy-bibliotheek.
Overzicht: vijf fasen
1. Classificeren
2. Isoleren
3. Remediëren
4. Verifiëren
5. Leren
Elke fase heeft een escalatiepad als de conditie niet wordt vervuld
2a. Fase 1 — Classificeren
Wat is dit — en is er een policy voor?
Het systeem ontvangt een signaal en matcht het op een bekende incidentklasse. Is er een policy? Dan start de automatische afhandeling. Is er geen policy? Dan escaleert het incident naar een engineer.
Classificatie is de eerste beslissing in het IRF — en de enige die volledig door het systeem wordt genomen zonder menselijke tussenkomst. Het systeem vergelijkt het inkomende signaal met de bibliotheek van gedefineerde incidentklassen en bepaalt: bestaat er een policy voor dit incidenttype, in deze klantcontext, met deze parameters?
Een succesvolle classificatie betekent niet dat het incident identiek is aan eerdere gevallen — het betekent dat de conditie voldoende overeenkomt om de policy van toepassing te verklaren. De precisie van classificatie bepaalt de veiligheid van wat volgt: een te brede classificatie leidt tot verkeerde remediaties, een te smalle classificatie laat te veel escalateren.
Doorstroomcriteria
- Signaaltype: welke monitoring-conditie heeft het incident getriggerd?
- Contextmatch: geldt de policy voor deze specifieke klantomgeving en infrastructuurconfiguratie?
- Parametervalidatie: vallen de gemeten waarden binnen de verwachte range voor dit incidenttype?
2b. Fase 2 — Isoleren
De scope bepalen voordat er gehandeld wordt
Vóórdat de remediatie start, bepaalt het systeem de exacte scope van het incident: welke systemen zijn betrokken, wat is de afhankelijkheidsketen, en zijn er contra-indicaties voor automatische afhandeling?
Fase 2 is de veiligheidssluis van het IRF. Remediatie zonder isolatie-analyse leidt tot blinde actie: een service restarten terwijl er een onderliggende oorzaak is die de service opnieuw doet vallen — of een schijf vrijmaken terwijl de oorzaak van de vulling actief is en de schijf binnen minuten opnieuw vol is.
Isoleren is niet hetzelfde als inactief wachten. Het systeem brengt in kaart welke afhankelijkheden er zijn, of er gerelateerde incidenten actief zijn op hetzelfde systeem, en of de remediatie-actie veilig kan worden uitgevoerd gegeven de huidige toestand van de klantinfrastructuur. Als de isolatie-analyse contra-indicaties oplevert, escaleert het incident naar een engineer met een volledig contextrapport.
Doorstroomcriteria
- Afhankelijkheidsanalyse: welke services en systemen hangen af van het getroffen systeem?
- Concurrentie-check: zijn er parallelle incidenten actief die de remediatie kunnen beïnvloeden?
- Contra-indicaties: zijn er signalen die wijzen op een onderliggende oorzaak die de remediatie zou invalideren?
2c. Fase 3 — Remediëren
De policy uitvoeren binnen gedefinieerde grenzen
De remediatie-actie wordt uitgevoerd op basis van de policy. Elke actie is vooraf gedefinieerd, afgebakend en auditeerbaar. Het systeem voert precies uit wat de policy voorschrijft — niet meer.
Fase 3 is de uitvoerende kern van het IRF. De policy bepaalt welke acties worden uitgevoerd, in welke volgorde, met welke parameters, en wat de grenzen zijn van de uitvoering. Een policy voor "schijf vrijmaken" specificeert welke directories kandidaat zijn, welke minimale vrije ruimte het doel is, en wat het systeem doet als dat doel niet bereikt kan worden zonder bestanden te verwijderen die buiten de veilige scope vallen.
Elke actie in Fase 3 wordt gelogd in de audit-trail met timestamp, actie-type, betrokken systeem, resultaat, en de policy-versie die is gevolgd. Die traceerbaarheid is niet optioneel — het is de basis voor de verificatie in Fase 4 en het leren in Fase 5.
Doorstroomcriteria
- Scope-naleving: de uitvoering blijft binnen de grenzen die de policy definieert.
- Auditlogboek: elke actie wordt vastgelegd met tijdstip, systeem en resultaat.
- Fallback-trigger: als de remediatie niet kan worden voltooid binnen de policy-grenzen, escaleert het incident.
2d. Fase 4 — Verifiëren
Bevestigen dat het incident daadwerkelijk is opgelost
Na de remediatie controleert het systeem of het incident daadwerkelijk is opgelost. Pas als verificatie slaagt, wordt het incident gesloten. Bij mislukking: escalatie naar engineer met volledig contextrapport.
Fase 4 is het onderscheid tussen "we hebben een actie uitgevoerd" en "het incident is opgelost". Veel automatiseringsoplossingen stoppen na de uitvoering van een actie. Het IRF stopt pas als de verificatie bevestigt dat het signaal dat het incident triggerde is verdwenen en de relevante metrieken zijn hersteld.
De verificatiemethode is onderdeel van de policy-definitie. Voor een service-restart controleert het systeem of de service actief is en health-checks doorstaat. Voor een schijf-opschoning controleert het systeem of de beschikbare ruimte de drempelwaarde heeft bereikt en stabiel blijft. Voor een certificate-renewal controleert het systeem of het nieuwe certificaat geldig is en binnen de verwachte vervalperiode valt.
Doorstroomcriteria
- Signaal verdwenen: de trigger-conditie is niet meer actief.
- Metrieken hersteld: de relevante systeemmetrieken zijn terug op baseline.
- Stabiliteit: het systeem is stabiel over een configureerbare verificatieperiode.
2e. Fase 5 — Leren
Elk incident maakt de volgende afhandeling beter
Na elk incident — autonoom afgehandeld of geëscaleerd — wordt de uitkomst verwerkt in de policy-bibliotheek. Succesvolle remediaties versterken bestaande policies. Mislukte remediaties of nieuwe incidentpatronen leiden tot policy-aanpassingen.
Fase 5 is wat het IRF onderscheidt van eenmalige automatisering. In een statisch runbook-systeem verbetert de automatisering niet op basis van ervaringen — elke uitvoering is identiek aan de vorige, ongeacht de uitkomst. In het IRF levert elk incident data op die terugvloeit naar de policy-laag.
Dat leren is gecontroleerd, niet automatisch. Het systeem signaleert patronen en stelt aanpassingen voor — een engineer beoordeelt en keurt goed. De mens beslist over beleid; het systeem voert uit. Dat onderscheid is bewust: volledige autonomie over policy-aanpassingen zou betekenen dat het systeem zijn eigen grenzen kan verleggen. Die verantwoordelijkheid blijft bij de engineer.
Doorstroomcriteria
- Uitkomstregistratie: elke afhandelingsuitkomst (geslaagd/mislukt/geëscaleerd) wordt vastgelegd.
- Patroonherkenning: terugkerende escalaties op hetzelfde incidenttype worden gesignaleerd als policy-hiaat.
- Voorstel-review: policy-aanpassingen worden voorgesteld aan een engineer voor goedkeuring.
3. Waarom vijf fasen?
De meeste incidentautomatisering reduceert het traject tot twee stappen: detecteer en handel. Dat werkt voor de eenvoudigste incidenttypes in gecontroleerde omgevingen. In de realiteit van mkb-MSP infrastructuur — heterogeen, gedeeld, met klant-specifieke configuraties — zijn er drie problemen met die tweedeelsbenadering.
Handelen zonder isolatie leidt tot cascade-incidenten
Een service restarten zonder te controleren welke services ervan afhankelijk zijn, kan leiden tot een kettingreactie van aanverwante incidenten. Fase 2 (isoleren) voorkomt dat.
Handelen zonder verificatie geeft valse zekerheid
Een policy die de actie uitvoert maar niet controleert of het incident is opgelost, rapporteert succes terwijl het probleem doorgaat. Fase 4 (verifiëren) voorkomt dat.
Herhalen zonder leren leidt tot dezelfde fouten
Een systeem dat bij elke uitvoering exact hetzelfde doet, verbetert niet op basis van uitkomsten. Fase 5 (leren) borgt dat elke afhandeling de volgende verbetering bevat.
De vijf fasen zijn niet bureaucratisch — ze zijn het minimale kader dat veilige, verifieerbare en lerende automatisering mogelijk maakt in een productie-omgeving. Elke fase die ontbreekt, vergroot het risico op stille fouten die alleen zichtbaar worden als een klant belt.
4. Wat het IRF niet doet
De kracht van het IRF zit deels in wat het bewust buiten scope laat. Drie categorieën vallen buiten de automatisering.
Niet-herhalende incidenten
Incidenten zonder voorspelbaar patroon of zonder vaste handelingssequentie escaleert het IRF direct naar een engineer. Automatisering van unieke situaties is geen doel — het is een risico.
Incidenten buiten de policy-scope
Als er geen policy bestaat voor een incidenttype, handelt het IRF niet — ook niet als er oppervlakkige overeenkomst is met een bekende klasse. Policy-scope wordt bewust uitgebreid via Fase 5 en menselijke beoordeling, niet door het systeem zelfstandig te laten beslissen.
Policy-aanpassingen zonder goedkeuring
Fase 5 stelt policy-aanpassingen voor op basis van uitkomstdata. Maar het systeem voert die aanpassingen niet zelf door. Een engineer keurt elke wijziging goed. De mens beslist over beleid — het systeem voert beleid uit.
5. Veelgestelde vragen
Is het Incident Reduction Framework een vervanging voor ITIL of ITSM?
Nee. Het IRF is geen procesframework voor de gehele IT-dienstverlening — het richt zich specifiek op de operationele incidentcyclus bij mkb-MSPs en de vraag hoe die cyclus autonoom kan worden afgehandeld voor bekende incidenttypes. Het kan naast een bestaand ITSM-framework worden ingezet. Voor MSPs die geen formeel ITSM-kader hanteren, biedt het IRF een pragmatisch alternatief voor de incidentafhandeling zonder de overhead van een volledig ITIL-implementatietraject.
Welke incidenttypes zijn geschikt voor het IRF?
Incidenten die aan drie criteria voldoen: ze zijn identificeerbaar op basis van een observeerbaar signaal, ze hebben een vaste handelingssequentie die altijd tot hetzelfde resultaat leidt, en ze zijn verifieerbaar — er is een meetbaar eindresultaat dat bevestigt dat het incident is opgelost. In de praktijk geldt dit voor de meerderheid van L1-incidenten: volle schijven, neergevallen services, backupfouten, certificate warnings, performance-afwijkingen. Incidenten die unieke situationele beoordeling vereisen vallen buiten de IRF-automatiseringsscope.
Hoe verschilt het IRF van Detect. Decide. Act.?
Detect. Decide. Act. is het kernprincipe achter autonome operaties — een beschrijving van de beslissingsloop die plaatsvindt bij elk incident. Het IRF is het operationele kader dat dat principe vertaalt naar vijf uitvoerbare fasen: van classificatie tot leren. DDA beschrijft het mechanisme; het IRF beschrijft het traject per incident, inclusief de governance-stappen rondom verificatie en kennisborging.
Wat als een incident in Fase 3 mislukt?
Als de remediatie in Fase 3 geen succesvol resultaat oplevert, escaleert het incident automatisch naar een engineer. De policy stopt — het systeem handelt niet opnieuw op basis van dezelfde logica als de remediatie eenmaal is mislukt. De engineer handelt het incident manueel af en documenteert de oorzaak van het mislukken. Die documentatie voedt Fase 5: het leermoment wordt gebruikt om de policy aan te passen of de classificatiecriteria te verfijnen.
Hoe weet ik of een incident echt "opgelost" is na Fase 4?
Fase 4 verifieert via drie mechanismen: (1) het signaal dat het incident triggerde is verdwenen, (2) de relevante service-metrieken zijn teruggekeerd naar baseline, en (3) er zijn geen gerelateerde incidenten ontstaan binnen de verificatieperiode. De verificatieperiode is configureerbaar per incidenttype. Voor een volle schijf is dat minuten — de schijf is zichtbaar vrijgemaakt en de write-operaties hersteld. Voor een service-restart is dat langer — de service moet stabiel zijn over meerdere health-check cycli.
Hoeveel incidenten kan het IRF tegelijkertijd afhandelen?
Het IRF werkt per incident-instantie, niet per incidentvolume. Meerdere instanties van hetzelfde incidenttype op verschillende klantomgevingen worden parallel afgehandeld, elk door hun eigen policy-uitvoering. Er is geen wachtrij of concurrentieproblem — het systeem schaalt horizontaal over klantomgevingen. De enige beperking is de verificatiefase: als verificatie een service-beschikbaarheidstest vereist, moet die test per instantie worden uitgevoerd.
Het IRF in de praktijk bij jouw MSP
Het Incident Reduction Framework is de operationele kern van UptimePilot. Van de eerste baselining en policy-definitie tot de doorlopende verfijning in Fase 5 — het traject is begeleid, verifieerbaar en controleerbaar. Het doel is structurele reductie van L1-ticketvolume en meetbare vrijgave van engineercapaciteit voor hoger-waardige taken.
Bespreek het IRF voor jouw MSP