Een door AI aangestuurde assistent nam gedurende zeven dagen mijn on-call diensten over, verwerkte 11 meldingen en verkortte mijn gemiddelde tijd voor het oplossen van problemen van 45 minuten naar 20 minuten. Het experiment is belangrijk omdat een bescheiden taalmodel een half uur kan besparen op incidentrespons, terwijl er nog steeds strikt menselijk toezicht nodig is.

Waarom ik een AI op on-call zette

Cloudteams besteden het grootste deel van hun dienst aan het doorzoeken van logs, het controleren van recente deployments en het bevestigen dat een schaalvergroting veilig is. Die "saaie" taken zijn herhaalbaar, data-intensief en gevoelig voor menselijke vermoeidheid. Recente ontwikkelingen in large language models beloofden precies dat patroonherkenningswerk te automatiseren, maar de meeste publieke demo's draaien in sandbox-omgevingen. Ik wilde zien of de hype standhield in een productie-waardige cluster die daadwerkelijk betalende klanten bedient.

De testopstelling

  • Toegang – De agent kon elke metriek, log en deployment-definitie lezen. Hij kon alleen schrijven naar een beperkte whitelist: een pod herstarten, het aantal replica's verhogen of een deployment schalen. Alles buiten deze acties vereiste mijn expliciete goedkeuring.
  • Rol – Ik behandelde het model als een junior engineer tijdens zijn eerste on-call dienst. Het ontving de melding, voerde de analyse uit en plaatste een aanbeveling in het incidentkanaal.
  • Veiligheidsnetten – Alle schrijfacties werden afgeschermd door een handmatige "ja/nee"-prompt. Ik stelde ook een limiet in op het tokenverbruik van het model om de kosten voorspelbaar te houden.

Waar de AI uitblonk

De snelheid van de agent was de meest opvallende verbetering. Zodra er een melding binnenkwam, haalde hij de relevante logs op, plotte hij recente metrieken en lijstte hij de laatste drie deployments op. Tegen de tijd dat ik mijn laptop opende, was het eerste detectivewerk al gedaan. Van de 11 meldingen:

  • 8 waren routineproblemen (geheugenpieken, container-restarts, eenvoudige misconfiguraties). De AI identificeerde telkens correct de oorzaak.
  • Het signaleerde een geleidelijke geheugenstijging in een microservice voordat het probleem escaleerde in een outage om 2 uur 's nachts, waardoor het team de kans kreeg om vroegtijdig in te grijpen.
  • Het tokenverbruik voor de hele week bleef rond de $30, ruim binnen een typisch on-call budget wanneer er limieten zijn ingesteld.

Deze resultaten vertalen zich in een meetbare vermindering van de mean time to resolution (MTTR) van 45 minuten naar 20 minuten, waardoor engineers meer tijd hebben voor werk met een hogere impact.

Waar het struikelde

Zelfvertrouwen is niet gelijk aan juistheid. De AI zat er vol overtuiging naast bij 3 van de 11 meldingen:

  1. Het gaf een recente code-deployment de schuld van een database-connectiviteitsfout, maar die verklaring was onjuist.
  2. Bij een onbekende netwerkanomalie bood het generieke oplossingen aan die het onderliggende probleem niet aanpakten.
  3. Tijdens een melding gerelateerd aan belasting suggereerde het een service te schalen van 3 naar 30 replica's. De belasting was niet het probleem; een slechte configuratie wel.

Omdat mijn guardrails handmatige goedkeuring vereisten voor elke schrijfactie, werden de fouten van het model opgemerkt voordat ze schade konden aanrichten. Toch onderstreepte dit incident een kernrisico: het model kan aannemelijk klinkende maar onjuiste aanbevelingen doen, vooral bij nieuwe problemen.

Kosten- en risicobeheer

De tokenrekening van $30 laat zien dat het draaien van een LLM in een productie-loop goedkoop kan zijn als het verbruik wordt gemonitord. De werkelijke kosten zijn echter het operationele risico. Het verkeerd schalen van een deployment kan leiden tot ongecontroleerde cloudkosten, en het terugdraaien van een goede release kan het vertrouwen van klanten schaden. Het experiment versterkte twee waarborgen:

  • Action gating – Sta het model alleen toe om wijzigingen met een hoge impact voor te stellen, maar nooit om ze uit te voeren zonder een menselijke klik.
  • Budgetlimieten – Stel harde limieten in op het tokenverbruik en waarschuw het team wanneer het model de limiet nadert.

Waar je op moet letten

Tot die tijd zouden teams het volgende moeten doen:

  • Houd het aandeel AI-gegenereerde suggesties bij die een handmatige correctie vereisen.
  • Meet de impact op de MTTR in verschillende incidentcategorieën (routine versus nieuw).
  • Test het model in een staging-omgeving met synthetische meldingen voordat je schrijfrechten voor productie verleent.

Belangrijkste lessen voor ops-teams

  • Automatiseer de saaie 80% – Gebruik AI voor logaggregatie, metriekcorrelatie en het genereren van de eerste hypothesen.
  • Reserveer de risicovolle 20% voor mensen – Schalen voorbij een bescheiden drempel, rollbacks en verwijderingen moeten achter een handmatige goedkeuringsstap blijven.
  • Behandel het model als een partner, niet als een vervanging – Een engineer die het systeem kent, kan de output van de AI sneller valideren dan een nieuwkomer, waardoor de assistent een krachtvermenigvuldiger wordt.

Een AI-agent kan nog geen cloudoperatie zelfstandig draaien, maar als triagepartner levert het al tastbare snelheidswinst op. De sleutel is om het vertrouwen in toom te houden, strikte kaders af te dwingen en het model het repetitieve routinewerk te laten doen, terwijl menselijke expertise de kritieke beslissingen stuurt.