AI lost je incidenten op en je engineers verleren hun systeem

Deze week stond een stuk van Sylvain Kalache hoog op Hacker News, met een titel die de spijker op zijn kop slaat: AI handelt de incidenten af en engineers raken het contact met hun systemen kwijt. De discussie eronder liep vol met mensen die het herkenden. Niet omdat AI-SRE's slecht werk leveren, maar juist omdat ze goed werk leveren. En daar zit precies het probleem.

Ik draai al jaren productie-incidenten bij .NET-klanten. Piket, warme overdrachten om 3 uur 's nachts, de kruipende paniek als een dependency wegvalt die je nooit als kritiek had aangemerkt. Mijn eerste reactie op het stuk was niet weerstand. Het was herkenning. Want wat Kalache beschrijft is geen nieuw AI-probleem. Het is een probleem uit 1983 dat een nieuw jasje heeft aangetrokken.

Wat de discussie eigenlijk aankaart

Kalache werkt bij Rootly, een platform voor incidentmanagement, dus lees zijn stuk met die pet op. Zijn kernpunt staat los van de verkooppraatjes en het klopt. AI-assistenten worden goed in het routinewerk: de bekende alert, de bekende rollback, de disk die volloopt en netjes wordt opgeschoond. Dat verlaagt je gemiddelde hersteltijd. Mooi.

Maar dat routinewerk was nooit alleen maar werk. Het was ook oefening. Elke keer dat een junior een pager-alert oppakt en de traces doorspit, bouwt die persoon een mentaal model van hoe het systeem echt werkt onder druk. Haal die momenten weg en je houdt engineers over die op papier verantwoordelijk zijn voor het systeem, maar er nooit meer met hun handen in hebben gezeten. Tot het moment dat de AI het niet meer weet. En dat moment komt altijd, want de zeldzame, rare incidenten zijn per definitie de incidenten waar geen patroon voor is.

De ironie van automatisering, veertig jaar oud

Lisanne Bainbridge schreef in 1983 een kort artikel met de titel Ironies of Automation. Het gaat over procesbesturing in fabrieken, niet over Kubernetes, maar elk woord is nog waar. Ze stelt: hoe meer je automatiseert, hoe minder de operator oefent met het normale werk, terwijl je hem wel verantwoordelijk houdt voor het abnormale. De automatisering pakt de makkelijke gevallen. De mens houdt de moeilijke gevallen over, en heeft steeds minder routine om die moeilijke gevallen aan te kunnen.

De luchtvaart worstelt hier al decennia mee. Piloten trainen bewust op scenario's die bijna nooit voorkomen, juist omdat de autopilot de rest doet. Ze houden hun hand op de stick, letterlijk, om de vaardigheid warm te houden. Software-teams doen dat nog nauwelijks. Wij bouwen de automatisering, zetten hem aan, en gaan ervan uit dat we het onderliggende systeem nog snappen omdat we het ooit hebben gebouwd. Dat is een aanname die verjaart.

Waar dit .NET-teams harder raakt dan de grafiek laat zien

Je MTTR-dashboard liegt niet, maar het vertelt ook niet alles. Het gemiddelde daalt omdat de vele kleine incidenten sneller dicht gaan. De paar zware incidenten, de kind SEV1 die je bedrijf een dag platlegt, worden juist trager opgelost, want daar staat een engineer die de laatste zes maanden niet meer zelf in de logs heeft gekeken.

Voor een typisch .NET-landschap is dat concreter dan het klinkt. Denk aan een connection pool die uitput onder een thread-starvation-bug. Aan een async-deadlock die alleen onder productie-load opduikt. Aan een EF Core-query die na een migratie een index niet meer gebruikt en je database langzaam wurgt. Dit zijn geen dingen die je met een generieke runbook oplost. Je moet weten waar de bodies liggen. Je moet dit systeem kennen.

Mijn punt is niet dat je de AI moet uitzetten. Dat zou dom zijn. Mijn punt is dat je bewust ruimte moet inbouwen waarin mensen nog aan de knoppen zitten, ook als de machine het sneller kan.

Zet de AI als voorsteller, niet als uitvoerder

De simpelste ingreep die ik bij teams doorvoer: laat de AI diagnoses en remediaties voorstellen, maar houd een mens in de goedkeurlus voor alles wat state verandert. Niet als bureaucratie, maar als leermoment. De engineer die de knop indrukt leest de redenering, controleert hem, en leert.

Hieronder een versimpeld voorbeeld in C#. Een remediatie-actie is een expliciet object met een risiconiveau. Laag risico mag de agent zelf draaien. Alles daarboven wacht op een mens.

public enum RemediationRisk { Low, Medium, High }

public sealed record RemediationAction(
    string Name,
    RemediationRisk Risk,
    Func<CancellationToken, Task> Execute,
    string Rationale);

public sealed class ApprovalGate
{
    private readonly IApprovalChannel _channel; // Slack, Teams, wat dan ook
    private readonly ILogger<ApprovalGate> _log;

    public ApprovalGate(IApprovalChannel channel, ILogger<ApprovalGate> log)
        => (_channel, _log) = (channel, log);

    public async Task RunAsync(RemediationAction action, CancellationToken ct)
    {
        if (action.Risk == RemediationRisk.Low)
        {
            _log.LogInformation("Auto-running low-risk action {Name}", action.Name);
            await action.Execute(ct);
            return;
        }

        var decision = await _channel.RequestApprovalAsync(
            title: $"Approve remediation: {action.Name}",
            body: action.Rationale,
            ct: ct);

        if (!decision.Approved)
        {
            _log.LogWarning("Action {Name} rejected by {User}", action.Name, decision.User);
            return;
        }

        _log.LogInformation("Action {Name} approved by {User}", action.Name, decision.User);
        await action.Execute(ct);
    }
}

De winst zit niet in de code, die is triviaal. De winst zit in het gedrag. Elke goedkeuring dwingt een mens om te lezen wat er gaat gebeuren en waarom. Dat is een minuut oefening die je anders kwijt was.

Oefenen is geen luxe, het is een build-stap

In de luchtvaart heet het een sim-sessie. Bij ons heet het een game day, en de meeste teams die ik zie plannen er twee per jaar en cancelen ze allebei. Dat werkt niet. Oefening moet zo goedkoop en zo routineus zijn dat je hem niet meer afzegt.

Een manier die goed werkt: bouw fault injection in als iets dat je op aanvraag aan kunt zetten in een staging- of zelfs productie-canary. Geen apart chaos-platform nodig om te beginnen. Een middleware die op een header reageert is genoeg om je team te laten oefenen met echte failure-modes.

public sealed class FaultInjectionMiddleware
{
    private readonly RequestDelegate _next;
    private readonly IFaultConfig _config; // in-memory, feature-flagged

    public FaultInjectionMiddleware(RequestDelegate next, IFaultConfig config)
        => (_next, _config) = (next, config);

    public async Task InvokeAsync(HttpContext ctx)
    {
        if (_config.Enabled && ctx.Request.Headers.ContainsKey("X-Chaos"))
        {
            var mode = ctx.Request.Headers["X-Chaos"].ToString();
            switch (mode)
            {
                case "latency":
                    await Task.Delay(_config.LatencyMs, ctx.RequestAborted);
                    break;
                case "500":
                    ctx.Response.StatusCode = StatusCodes.Status500InternalServerError;
                    await ctx.Response.WriteAsync("Injected fault");
                    return;
                case "dbdown":
                    throw new InvalidOperationException("Injected: database unavailable");
            }
        }

        await _next(ctx);
    }
}

Zet dit achter een feature flag en een netwerkrestrictie, zodat alleen je eigen team de header kan zetten. Draai er dan een game day op: iemand zet stiekem X-Chaos: dbdown aan op de canary, en de piketdienst mag het uitzoeken zonder te weten wat er speelt. De eerste keer duurt het pijnlijk lang. De derde keer heeft je team een reflex. Dat is precies de reflex die je kwijtraakt als de AI alles voor je opruimt.

Een waarschuwing die ik hard maak: injecteer nooit faults die echte klantdata kunnen beschadigen, en nooit zonder een kill switch die per direct alles terugdraait. Chaos zonder blast-radius-controle is geen oefening, dat is een incident dat je zelf hebt veroorzaakt.

Houd je telemetrie leesbaar voor mensen

Er sluipt een tweede probleem naar binnen als de AI de logs leest en jij niet meer. Teams beginnen hun telemetrie te optimaliseren voor de machine. Cardinaliteit omhoog, structuur eruit, alles een event. Prima voor een model, waardeloos voor een mens die om 3 uur 's nachts een verhaal probeert te reconstrueren.

Ik houd traces bewust leesbaar. Spannamen die een verhaal vertellen, attributen die een mens snapt, en een handjevol high-signal events in plaats van een moeras. OpenTelemetry in .NET maakt dat makkelijk.

using System.Diagnostics;

public static class Telemetry
{
    public static readonly ActivitySource Source = new("Orders.Checkout");
}

public async Task<OrderResult> CheckoutAsync(Cart cart, CancellationToken ct)
{
    using var activity = Telemetry.Source.StartActivity("checkout");
    activity?.SetTag("cart.items", cart.Items.Count);
    activity?.SetTag("cart.value_eur", cart.TotalEur);

    try
    {
        var payment = await _payments.ChargeAsync(cart, ct);
        activity?.SetTag("payment.provider", payment.Provider);
        activity?.AddEvent(new ActivityEvent("payment.captured"));
        return OrderResult.Ok(payment);
    }
    catch (PaymentDeclinedException ex)
    {
        activity?.SetStatus(ActivityStatusCode.Error, "payment declined");
        activity?.AddEvent(new ActivityEvent("payment.declined",
            tags: new ActivityTagsCollection { { "reason", ex.Reason } }));
        throw;
    }
}

Het idee is niet dat de AI deze data niet aankan. Dat kan hij prima. Het idee is dat een mens die uit de routine is geraakt hier in tien seconden het verhaal uit haalt. Leesbare telemetrie is de goedkoopste verzekering tegen skill-verval die er bestaat, want ze verlaagt de drempel om zelf te kijken.

Wat ik in de praktijk doe

Concreet, bij mijn klanten, komt het op een paar dingen neer. De AI mag alle diagnose doen en alle read-only analyse. Elke actie die state verandert boven laag risico gaat langs een mens, en die mens leest de redenering echt. We draaien elke sprint een korte game day, geen halve dag maar veertig minuten, met echte fault injection op een canary. En we roteren piket zo dat juniors de bekende incidenten zelf oplossen, ook al zou de AI het sneller doen, want dat is hun oefening.

Kost dat tijd? Ja. Voelt het soms als een omweg? Ook ja. Maar de rekening voor skill-verval komt niet in de sprint waarin je hem maakt. Hij komt op de dag dat je zwaarste incident niet in de trainingsset van je model zat, en de enige die het kan oplossen zes maanden niet meer zelf in de logs heeft gekeken.

Veelgestelde vragen over AI-incidentafhandeling en vaardigheidsverval

Moet ik AI dan maar niet inzetten voor incidenten? Jawel, gebruik hem volop voor diagnose en het routinewerk, want daar wint hij tijd. Bouw alleen bewust momenten in waarop mensen zelf aan de knoppen zitten, zodat de vaardigheid niet wegzakt.

Wat is de ironie van automatisering precies? Het idee van Lisanne Bainbridge uit 1983 dat automatisering juist de makkelijke taken overneemt en de mens de moeilijke, zeldzame gevallen laat, terwijl die mens door gebrek aan routine steeds slechter voorbereid is op precies die gevallen.

Waarom raakt dit .NET-teams specifiek? Omdat de zware incidenten in .NET-productie vaak systeemspecifiek zijn, zoals thread-starvation, async-deadlocks of een EF Core-query die na een migratie een index laat vallen, en die los je niet op met een generieke runbook maar met kennis van dit systeem.

Hoe vaak moet ik een game day draaien? Liever kort en vaak dan lang en zelden. Veertig minuten per sprint met echte fault injection op een canary houdt de reflex warm, terwijl de klassieke halfjaarlijkse sessie meestal wordt afgezegd.

Is fault injection op productie niet gevaarlijk? Alleen als je het zonder vangnet doet. Zet het achter een feature flag en een netwerkrestrictie, raak nooit echte klantdata, en zorg voor een kill switch die alles per direct terugdraait.

Verder lezen

Conclusie: Laat AI de routine-incidenten doen, maar behandel oefening als een build-stap en niet als een luxe, anders staat op je zwaarste dag de enige die het kan oplossen zonder routine.

Bronnen: Sylvain Kalache over AI en incidenten - Hacker News-discussie.