Het artikel analyseert de 'paradox van automatisering' binnen Site Reliability Engineering (SRE). Hoewel AI-tools routine-incidenten efficiënt oplossen, waardoor de gemiddelde oplostijd (MTTR) daalt, ontnemen ze menselijke engineers de kans om praktijkervaring en intuïtie op te doen. Dit leidt tot 'begripsschuld' (comprehension debt), waardoor complexe incidenten die AI niet kan oplossen juist langer duren om te verhelpen.
De auteur trekt een vergelijking met de luchtvaart, waar piloten via simulatoren getraind worden op zeldzame noodsituaties om hun vaardigheden up-to-date te houden. De conclusie is dat de software-industrie soortgelijke incident-simulaties moet invoeren. Door actief te oefenen met het diagnosticeren van kapotte systemen, kunnen engineers hun grip op de infrastructuur behouden, zelfs wanneer AI het grootste deel van het routinewerk overneemt.
AI handelt incidenten af, engineers raken de grip op hun systemen kwijt
Deze tools doen inmiddels alles: ze inspecteren waarschuwingen, vormen hypothesen, bevragen telemetrie, correleren recente implementaties en voeren zelfs zelf de oplossing uit. Hoewel ik het geweldig vind om dit te zien, heb ik een grote zorg: we raken de grip op onze systemen kwijt.
Hoe beter deze tools worden in het oplossen van routine-incidenten, hoe minder oefening menselijke responders krijgen. Wanneer er dan een ambigu incident met een hoge prioriteit optreedt dat automatisering niet kan oplossen, zullen de verantwoordelijke engineers in de problemen komen.
Automatisering laat de moeilijkste incidenten over aan mensen
Deze AI-ondersteunde tools voor incidentrespons — vaker "AI SRE's" genoemd, een term waar ik niet bijzonder van houd — zijn op veel vlakken fantastisch. Ze voelen vooral magisch aan wanneer ze 's nachts een routine-incident afhandelen, waardoor je niet wakker hoeft te worden voor een capaciteitsprobleem.
Het probleem is dat routine-incidenten juist de manier zijn waarop responders op een "veilige" manier een intuïtie ontwikkelen voor hoe hun systemen zich gedragen en falen. Wanneer AI stuit op een moeilijk, ongekend incident dat het niet kan oplossen, moeten engineers het overnemen met minder praktijkervaring dan ze voorheen zouden hebben gehad.
De onderzoeker naar menselijke factoren, Lisanne Bainbridge, beschreef deze paradox in haar beroemde paper uit 1983, The Ironies of Automation. Ze legde uit dat automatisering de kansen van operators om routinewerk te oefenen vermindert, terwijl ze wel verantwoordelijk blijven voor nieuwe en abnormale situaties. Ze stelt daarom dat operators juist meer vaardig moeten zijn en zelfs méér training nodig hebben dan vóór de automatisering.
Ik voorspel dat de gemiddelde MTTR (Mean Time To Resolution) voor de meeste incidenten in de komende jaren zal dalen dank aan AI-ondersteuning, maar dat de oplostijd voor complexe incidenten juist zal stijgen, omdat incident-responders de grip op hun systeem zijn verloren en moeite hebben met het onderzoek.
De luchtvaart traint piloten voor zeldzame storingen
We kunnen inspiratie putten uit de luchtvaartindustrie.
Automatisering in vliegtuigen handelt een groot deel van het vliegen af, maar piloten blijven verantwoordelijk voor situaties die automatisering niet kan beheren: motoruitvallen, onbetrouwbare instrumenten, afgebroken starts, overtrekken (stalls) en andere abnormale omstandigheden.
Deze gebeurtenissen zijn uiterst zeldzaam. Moderne turbinemotoren hebben bijvoorbeeld minder dan één uitval tijdens de vlucht per 100.000 vlieguren. Met andere woorden: dat is zeldzaam genoeg waardoor een commercieel piloot een hele carrière kan volmaken zonder dit buiten een simulator te ervaren.
Maar wanneer er een storing optreedt, moeten piloten snel en correct reageren. Bij TransAsia Airways-vlucht 235 ging bijvoorbeeld kort na het opstijgen de propeller van de rechtermotor in 'autofeather'-modus. Hoewel het vliegtuig was ontworpen om op de linkermotor door te vliegen, identificeerde de bemanning het probleem verkeerd. Het vliegtuig trok over en stortte slechts 117 seconden na de eerste waarschuwing neer.
Vliegtuigpiloten keren regelmatig terug naar simulatoren om zeldzame noodsituaties te oefenen. Volgens de regels van de Amerikaanse FAA moeten kapiteins elke zes maanden een herhalingstraining of een bekwaamheidscontrole volgen, inclusief scenario's zoals een motoruitval tijdens het opstijgen.
Hoewel de meeste software-incidenten geen levens bedreigen, is dat geen reden om ons vak niet te perfectioneren. Het blijkt dat de technologie die het probleem veroorzaakt, ook kan helpen om het op te lossen.
De software-industrie heeft incident-simulatoren nodig
Bij Rootly, een bedrijf op het gebied van incidentmanagement waar ik werk, zijn we gaan samenwerken met Uptime Labs om dit idee toe te passen via realistische incident-simulaties. Engineers nemen de rol van 'incident commander' op zich tijdens een gesimuleerde outage van een e-commerceplatform, waarbij ze observatietools gebruiken en coördineren met LLM-gestuurde stakeholders in Slack.
Het resultaat voelt echt. Je moet onderzoeken wat er misgaat, terwijl je de respons georganiseerd houdt en communiceert met de CEO en de klantenservice. Je kunt de vaardigheden oefenen die echt tellen tijdens een incident:
- Zin maken van onvolledige informatie;
- Duidelijk communiceren;
- Mensen coördineren;
- Het daadwerkelijk leiden van de respons.
AI kan ook helpen deze vaardigheden te behouden
Maar hoe zit het met het gebruik van AI als trainer? Responders kunnen een agent vragen om de stappen uit te leggen die het heeft genomen, de signalen die het heeft geanalyseerd en het bewijs achter de diagnose.
Echter, uitleg en observatie zijn geen vervanging voor praktijk. Je kunt een paar dingen oppikken door naar Serena Williams te kijken, maar je leert tennis alleen door de baan op te gaan; incidentrespons werkt niet anders.
Ik heb meer dan vijf jaar van mijn carrière besteed aan het bouwen van een software engineering school gebaseerd op progressief onderwijs: leren door te doen. Het was fysiek onderwijs, maar we hadden geen docenten; studenten werkten aan projecten in plaats van te luisteren naar colleges. Toen Dropbox me vertelde dat de afgestudeerden die ze aannamen nog steeds te onervaren waren in troubleshooting, creëerde ik projecten waarbij studenten kapotte infrastructuur kregen die ze moesten diagnosticeren en repareren. Voor de meeste praktische vaardigheden geloof ik dat praktijkonderwijs veel effectiever is dan passieve instructie.
Incident-simulatie moet onderdeel worden van de on-call gereedheid
Naarmate LLM's meer van ons werk overnemen, lopen engineeringteams het risico op het opbouwen van comprehension debt (begripsschuld): een groeiende kloof tussen hoe hun systemen werken en hoe goed de responders deze begrijpen.
Engineers zouden regelmatig interactie moeten hebben met het systeem waarover zij waken, onbekende storingen moeten afhandelen, moeten oefenen met werken onder druk en de coördinatie en communicatie moeten repeteren die vereist zijn tijdens een SEV0. Tabletop-oefeningen en chaos engineering zijn niet nieuw, maar praktijkervaring is in het tijdperk van LLM's nog belangrijker geworden.
Onderzoeker Bainbridge adviseerde om operators regelmatig directe controle te geven en simulaties te gebruiken om te voorkomen dat hun vaardigheden achteruitgaan. Dat is de ironie van automatisering: hoe succesvoller het wordt, hoe minder voorbereid mensen kunnen zijn op het moment dat het faalt.
AI handelt incidenten af, engineers raken de grip op hun systemen kwijt
Deze tools doen inmiddels alles: ze inspecteren waarschuwingen, vormen hypothesen, bevragen telemetrie, correleren recente implementaties en voeren zelfs zelf de oplossing uit. Hoewel ik het geweldig vind om dit te zien, heb ik een grote zorg: we raken de grip op onze systemen kwijt.
Hoe beter deze tools worden in het oplossen van routine-incidenten, hoe minder oefening menselijke responders krijgen. Wanneer er dan een ambigu incident met een hoge prioriteit optreedt dat automatisering niet kan oplossen, zullen de verantwoordelijke engineers in de problemen komen.
Automatisering laat de moeilijkste incidenten over aan mensen
Deze AI-ondersteunde tools voor incidentrespons — vaker "AI SRE's" genoemd, een term waar ik niet bijzonder van houd — zijn op veel vlakken fantastisch. Ze voelen vooral magisch aan wanneer ze 's nachts een routine-incident afhandelen, waardoor je niet wakker hoeft te worden voor een capaciteitsprobleem.
Het probleem is dat routine-incidenten juist de manier zijn waarop responders op een "veilige" manier een intuïtie ontwikkelen voor hoe hun systemen zich gedragen en falen. Wanneer AI stuit op een moeilijk, ongekend incident dat het niet kan oplossen, moeten engineers het overnemen met minder praktijkervaring dan ze voorheen zouden hebben gehad.
De onderzoeker naar menselijke factoren, Lisanne Bainbridge, beschreef deze paradox in haar beroemde paper uit 1983, The Ironies of Automation. Ze legde uit dat automatisering de kansen van operators om routinewerk te oefenen vermindert, terwijl ze wel verantwoordelijk blijven voor nieuwe en abnormale situaties. Ze stelt daarom dat operators juist meer vaardig moeten zijn en zelfs méér training nodig hebben dan vóór de automatisering.
Ik voorspel dat de gemiddelde MTTR (Mean Time To Resolution) voor de meeste incidenten in de komende jaren zal dalen dank aan AI-ondersteuning, maar dat de oplostijd voor complexe incidenten juist zal stijgen, omdat incident-responders de grip op hun systeem zijn verloren en moeite hebben met het onderzoek.
De luchtvaart traint piloten voor zeldzame storingen
We kunnen inspiratie putten uit de luchtvaartindustrie.
Automatisering in vliegtuigen handelt een groot deel van het vliegen af, maar piloten blijven verantwoordelijk voor situaties die automatisering niet kan beheren: motoruitvallen, onbetrouwbare instrumenten, afgebroken starts, overtrekken (stalls) en andere abnormale omstandigheden.
Deze gebeurtenissen zijn uiterst zeldzaam. Moderne turbinemotoren hebben bijvoorbeeld minder dan één uitval tijdens de vlucht per 100.000 vlieguren. Met andere woorden: dat is zeldzaam genoeg waardoor een commercieel piloot een hele carrière kan volmaken zonder dit buiten een simulator te ervaren.
Maar wanneer er een storing optreedt, moeten piloten snel en correct reageren. Bij TransAsia Airways-vlucht 235 ging bijvoorbeeld kort na het opstijgen de propeller van de rechtermotor in 'autofeather'-modus. Hoewel het vliegtuig was ontworpen om op de linkermotor door te vliegen, identificeerde de bemanning het probleem verkeerd. Het vliegtuig trok over en stortte slechts 117 seconden na de eerste waarschuwing neer.
Vliegtuigpiloten keren regelmatig terug naar simulatoren om zeldzame noodsituaties te oefenen. Volgens de regels van de Amerikaanse FAA moeten kapiteins elke zes maanden een herhalingstraining of een bekwaamheidscontrole volgen, inclusief scenario's zoals een motoruitval tijdens het opstijgen.
Hoewel de meeste software-incidenten geen levens bedreigen, is dat geen reden om ons vak niet te perfectioneren. Het blijkt dat de technologie die het probleem veroorzaakt, ook kan helpen om het op te lossen.
De software-industrie heeft incident-simulatoren nodig
Bij Rootly, een bedrijf op het gebied van incidentmanagement waar ik werk, zijn we gaan samenwerken met Uptime Labs om dit idee toe te passen via realistische incident-simulaties. Engineers nemen de rol van 'incident commander' op zich tijdens een gesimuleerde outage van een e-commerceplatform, waarbij ze observatietools gebruiken en coördineren met LLM-gestuurde stakeholders in Slack.
Het resultaat voelt echt. Je moet onderzoeken wat er misgaat, terwijl je de respons georganiseerd houdt en communiceert met de CEO en de klantenservice. Je kunt de vaardigheden oefenen die echt tellen tijdens een incident:
- Zin maken van onvolledige informatie;
- Duidelijk communiceren;
- Mensen coördineren;
- Het daadwerkelijk leiden van de respons.
AI kan ook helpen deze vaardigheden te behouden
Maar hoe zit het met het gebruik van AI als trainer? Responders kunnen een agent vragen om de stappen uit te leggen die het heeft genomen, de signalen die het heeft geanalyseerd en het bewijs achter de diagnose.
Echter, uitleg en observatie zijn geen vervanging voor praktijk. Je kunt een paar dingen oppikken door naar Serena Williams te kijken, maar je leert tennis alleen door de baan op te gaan; incidentrespons werkt niet anders.
Ik heb meer dan vijf jaar van mijn carrière besteed aan het bouwen van een software engineering school gebaseerd op progressief onderwijs: leren door te doen. Het was fysiek onderwijs, maar we hadden geen docenten; studenten werkten aan projecten in plaats van te luisteren naar colleges. Toen Dropbox me vertelde dat de afgestudeerden die ze aannamen nog steeds te onervaren waren in troubleshooting, creëerde ik projecten waarbij studenten kapotte infrastructuur kregen die ze moesten diagnosticeren en repareren. Voor de meeste praktische vaardigheden geloof ik dat praktijkonderwijs veel effectiever is dan passieve instructie.
Incident-simulatie moet onderdeel worden van de on-call gereedheid
Naarmate LLM's meer van ons werk overnemen, lopen engineeringteams het risico op het opbouwen van comprehension debt (begripsschuld): een groeiende kloof tussen hoe hun systemen werken en hoe goed de responders deze begrijpen.
Engineers zouden regelmatig interactie moeten hebben met het systeem waarover zij waken, onbekende storingen moeten afhandelen, moeten oefenen met werken onder druk en de coördinatie en communicatie moeten repeteren die vereist zijn tijdens een SEV0. Tabletop-oefeningen en chaos engineering zijn niet nieuw, maar praktijkervaring is in het tijdperk van LLM's nog belangrijker geworden.
Onderzoeker Bainbridge adviseerde om operators regelmatig directe controle te geven en simulaties te gebruiken om te voorkomen dat hun vaardigheden achteruitgaan. Dat is de ironie van automatisering: hoe succesvoller het wordt, hoe minder voorbereid mensen kunnen zijn op het moment dat het faalt.
Groetjes,