Van Uptime naar Experience: De AI‑gedreven verschuiving in moderne observability

In 2001 schreef IBM een autonoom IT‑manifest. De visie op autonoom computergebruik splitste zelfbeheer op in vier pijlers: zelfoptimalisatie, zelfherstel, zelfconfiguratie en zelfbescherming. Ik zat bij Microsoft toen IBM deze IT‑visie uiteenzette. We reageerden door technologische ideeën voor te stellen, zoals het autonome datacenter, maar uiteindelijk was het een droom die ver voor zijn tijd lag. Er bestond geen praktische manier om die visie in de realiteit te brengen.

In mijn Microsoft‑tijd zat ik in het team achter Clippy. Hoewel de geanimeerde paperclip‑assistent berucht indringend was, was het idee erachter degelijk: computers moeten mensen actief helpen hun werk te doen. We hadden gewoon niet de rekenkracht en AI om het mogelijk te maken. 25 jaar later kunnen we het eindelijk.

Van Service Level naar Ervaringsniveau

Het concept observability is niet ontstaan in de IT. In 1960 bedacht de Hongaars‑Amerikaanse ingenieur en wiskundige Rudolf E. Kálmán bedacht de term “observability” om te beschrijven hoe goed een systeem gemeten kan worden aan de hand van zijn uitgangen. Daarna, in 2013, nam Twitter nam de term over in een reeks blogposts, waarmee ze effectief stelden dat ouderwetse monitoring, via alle commerciële kant‑en‑klare tools die ze beschikbaar hadden, was ontworpen voor een ander tijdperk van technologie en niet werkte in microservice‑schaalarchitecturen.

Zie het als een arts die een patiënt onderzoekt. Hij kan de pols meten, de bloeddruk opnemen en andere uiterlijke kenmerken observeren om indirect de interne gezondheid van de patiënt te beoordelen. In de IT moeten we hetzelfde doen. Wanneer er een flikkering in de pols van de patiënt is, moeten we weten of dat betekent dat er problemen zijn in de nieren of de lever. Op de schaal en complexiteit van de operaties waarmee Twitter twintig jaar geleden (het bedrijf bediende toen slechts 100 miljoen gebruikers met realtime tweets en feeds) te maken had, vereiste observability een andere tooling‑ en monitoringsaanpak.

De systemen van vandaag zijn nog groter en complexer geworden, met afhankelijkheden van content‑delivery‑netwerken, caching en distributie van bitmap‑bestanden, lettertypen, JavaScript‑bestanden, enzovoort, over de hele wereld. Het echt begrijpen van de prestaties van real‑world‑applicaties is geen gemakkelijke opgave.

Wanneer de IT om 4 uur ’s ochtends een alarm krijgt, moet iemand uit bed komen en uitzoeken of het probleem te wijten is aan een defecte sector op een harde schijf of aan een kwaadwillende die de infrastructuur wil binnendringen en ontwrichten. Het maakt eigenlijk niet uit welke het is: uiteindelijk is hun taak om alle systemen draaiende te houden. Gelukkig kunnen we tegenwoordig bij het beoordelen van de gezondheid van applicaties alle beschikbare telemetrie gebruiken: elk netwerkapparaat, elke applicatie, duizenden kant‑en‑klare integraties, ticketstroom via JIRA of Atlassian, en nog veel meer signalen.

Hier komen Experience Level Objectives (XLO’s) om de hoek kijken. Je hebt waarschijnlijk gehoord van Service Level Agreements (SLA’s) en Service Level Objectives (SLO’s), maar XLO’s nemen de volgende stap door te meten of jouw klanten en medewerkers het ervaringsniveau krijgen dat ze wensen. Het gaat om kwaliteit, niet alleen om uptime. Vanuit technisch perspectief is de enige manier om XLO’s te realiseren zichtbaarheid van de NIC tot het eind‑gebruikersapparaat.

Afgelopen oktober viel AWS US‑EAST‑1 viel uit. Catchpoint detecteerde het probleem 16 minuten voordat Amazon het publiekelijk erkende. Klanten met die zichtbaarheid konden reageren voordat hun gebruikers de gevolgen van de storing merkten.

De belofte van observability is vergelijkbaar met Smokey Bear: detecteer waar rook is voordat er brand is. Als het goed wordt gedaan, stelt observability je in staat een prairie‑vuur te blussen voordat het een conflagratie wordt die de Palisades in Californië verwoest. Smokey is het vroegtijdige waarschuwingssysteem dat die kleine rookpluimen kan detecteren, ongeacht waar ze vandaan komen: een AWS‑probleem, een Oracle‑probleem, een GCP‑probleem, een Microsoft‑Azure‑probleem, of iets mis in je infrastructuur.

AI schaalt beveiligingssystemen

Geen enkele menselijke operator kan de infrastructuursystemen van vandaag in de gaten houden. De enige manier om systemen op schaal te monitoren, waarbij petabytes aan loggegevens en triljoenen metrische gegevens per dag worden verwerkt, is door AI te gebruiken.

Stel bijvoorbeeld dat je de lees‑/schrijfpresentatie van een schijf of de invoer/uitvoer‑ of pakketbuffer‑overruns in je netwerkomgeving wilt volgen. Je kunt een dynamische drempel gebruiken om te definiëren hoe normaal eruitziet, of een deterministische methode om tijdreeksgegevens van de afgelopen week, maand, jaar of een willekeurige periode te analyseren en normale prestatiedrempels vast te stellen. Zodra je deze statistische analyse hebt, kun je niveaus instellen op twee standaarddeviaties van het gemiddelde, zodat je een waarschuwing krijgt wanneer iets buiten dat bereik valt en de prestatie mogelijk abnormaal is.

Zeer complexe systemen kunnen echter duizenden waarschuwingen per dag ontvangen. Dashboards beginnen te knipperen en mensen krijgen paginering. Het doorzoeken van al die waarschuwingen is geen goede besteding van de tijd van mensen. Vectra schat dat organisaties gemiddeld 2,992 beveiligingswaarschuwingen per dag ontvangen, waarvan 63 % onbehandeld blijft.

AI‑tools kunnen deze duizenden meldingen per dag terugbrengen tot slechts een paar tientallen. Ik herinner me een geval waarin één probleem op één NIC op één machine 2.000 downstream‑meldingen veroorzaakte. Dankzij AI kon de klant meldingscorrelatie uitvoeren en veel sneller tot een oorzaak‑analyse komen, waaruit bleek dat één enkel probleem op dat moment het volledige dashboard van het bedrijf rood liet worden.

AI maakt IT weer spannend

Ik nam een pauze nadat Cisco Splunk in 2023 had overgenomen. In de daaropvolgende twee jaar zag ik hoe vrienden en voormalige collega’s bedrijven oprichtten om AI op manieren te gebruiken die vijf jaar geleden nog niet mogelijk waren. (Onthoud dat als ChatGPT een menselijk kind zou zijn, het een driejarig kind zou zijn).

IT‑teams hebben hulp nodig om rook te detecteren voordat het alarm afgaat, niet meer dashboards om naar te staren. Zij. In zekere zin is dit hetzelfde probleem waar IBM, Twitter en zelfs Microsoft met Clippy al mee worstelen.

Dit is de reden waarom ik besloot weer in te springen. De technologie heeft eindelijk een punt bereikt waarop we de oorspronkelijke belofte van observability en autonome IT kunnen waarmaken.