Self-Healing Infrastructure met AI

Om drie uur 's nachts gaat de pager af. Een database connection pool loopt vol, de API geeft 503's terug, en ergens in Slack tikken drie mensen tegelijk "ik kijk ernaar." Herkenbaar? Dit scenario speelt zich wekelijks af bij teams die nog volledig op handmatige incident response draaien.

Maar wat als het systeem zichzelf herstelt voordat iemand überhaupt wakker wordt?

Wat Self-Healing Eigenlijk Betekent

De term klinkt fancy, maar het concept is verrassend eenvoudig. Een self-healing systeem combineert drie onderdelen: detectie, diagnose en actie. AI voegt daar een vierde laag aan toe — het leert van eerdere incidenten welke actie het meest effectief was.

Een traditionele setup ziet er zo uit:

# Prometheus alertrule - klassieke aanpak
groups:
  - name: database
    rules:
      - alert: HighConnectionCount
        expr: pg_stat_activity_count > 80
        for: 5m
        annotations:
          summary: "Connection pool bijna vol"

Dit stuurt een alert. Iemand moet wakker worden, inloggen, kijken wat er aan de hand is, en handmatig ingrijpen. Met een AI-laag erboven verandert dat fundamenteel.

De Architectuur Achter Automatische Recovery

Een werkende self-healing pipeline heeft minimaal deze componenten nodig:

class IncidentHandler:
    def __init__(self, llm_client, runbook_store):
        self.llm = llm_client
        self.runbooks = runbook_store
        self.history = IncidentHistory()

    async def handle(self, alert: Alert):
        # Verzamel context
        metrics = await self.gather_metrics(alert)
        logs = await self.gather_logs(alert, window="15m")
        similar = self.history.find_similar(alert, limit=5)

        # Laat AI de diagnose stellen
        diagnosis = await self.llm.diagnose(
            alert=alert,
            metrics=metrics,
            logs=logs,
            past_incidents=similar
        )

        # Kies een runbook op basis van diagnose
        runbook = self.runbooks.match(diagnosis)
        if runbook and runbook.confidence > 0.85:
            result = await runbook.execute(dry_run=False)
            self.history.record(alert, diagnosis, runbook, result)

Het cruciale punt: de confidence threshold. Stel die te laag in en het systeem gaat wild acties uitvoeren. Te hoog en alles valt terug op menselijke interventie. In de praktijk blijkt 0.85 een goede startwaarde, maar dat verschilt per type incident.

Patronen Die Goed Werken

Niet elk incident leent zich voor automatische afhandeling. De volgende categorieën hebben bewezen goed te automatiseren:

Incident Type	Automatische Actie	Slagingspercentage
Connection pool exhaustion	Idle connections killen, pool resizen	~92%
Disk space vol	Log rotatie, temp files opruimen	~95%
Memory leak (gradueel)	Rolling restart van pods	~88%
Certificate expiry	Auto-renewal triggeren	~99%
Deployment rollback	Error rate spike → vorige versie	~78%

Deployment rollbacks scoren lager omdat de oorzaak vaker genuanceerd is. Soms is een hoge error rate verwacht bij een migratie, en moet het systeem dat onderscheid kunnen maken.

Runbooks als Code

De kracht zit in gestructureerde runbooks die AI kan interpreteren en uitvoeren:

# runbooks/db-connection-pool.yaml
name: database-connection-exhaustion
triggers:
  - alert: HighConnectionCount
    threshold: 80
steps:
  - name: identify_idle
    command: |
      psql -c "SELECT pid, state, query_start 
      FROM pg_stat_activity 
      WHERE state = 'idle' 
      AND query_start < now() - interval '10 minutes'"
  - name: terminate_idle
    command: |
      psql -c "SELECT pg_terminate_backend(pid) 
      FROM pg_stat_activity 
      WHERE state = 'idle' 
      AND query_start < now() - interval '10 minutes'"
    requires_confirmation: false
  - name: verify
    command: |
      psql -c "SELECT count(*) FROM pg_stat_activity"
    expected: "count < 60"

Het verschil met klassieke scripts? AI kan deze runbooks aanpassen op basis van context. Als de idle connections niet het probleem blijken, kan het systeem de logs analyseren en een alternatieve aanpak kiezen.

Waar Het Misgaat

Een team had hun self-healing systeem zo agressief geconfigureerd dat het pods restarte tijdens een database migratie. De migratie was langzaam, het systeem interpreteerde de hoge latency als een probleem, en begon pods te recyclen. Resultaat: een half-afgeronde migratie en drie uur handmatig herstelwerk.

De les: exclusion windows en maintenance modes zijn niet optioneel. Implementeer ze vanaf dag één.

class SafetyGuard:
    def should_execute(self, action: Action) -> bool:
        if self.maintenance_mode:
            return False
        if action.blast_radius > self.max_blast_radius:
            return False
        if self.recent_actions_count(minutes=10) > 3:
            # Te veel acties in korte tijd = iets structureels
            return False
        return True

Praktisch Beginnen

Start klein. Neem de drie meest voorkomende alerts van de afgelopen maand. Schrijf er runbooks voor. Laat ze eerst in dry-run mode draaien — het systeem rapporteert wat het zou doen, zonder daadwerkelijk in te grijpen. Na twee weken evalueren: hoeveel keer had het systeem het juiste gedaan?

Die data is goud waard. Het geeft vertrouwen om de automatisering stap voor stap op te schroeven. En ondertussen slaapt het team gewoon door.