Fra oppetid til opplevelse: Det AI-drevne skiftet i moderne observabilitet

I 2001 skrev IBM et manifest for autonom IT. Visjonen om autonom databehandling delte selvstyring inn i fire pilarer: selvoptimalisering, selvhelbredelse, selvkonfigurasjon og selvbeskyttelse. Jeg var i Microsoft da IBM la frem denne IT‑visjonen. Vi reagerte ved å foreslå teknologiske ideer som det autonome datasenteret, men til slutt var det en drøm som lå langt foran sin tid. Det fantes ingen praktisk måte å gjøre den visjonen til virkelighet på.

I mine Microsoft‑dager var jeg på teamet bak Clippy. Selv om den animerte bindersassistenten var beryktet påtrengende, var ideen bak den solid: datamaskiner bør aktivt hjelpe mennesker med å utføre jobben sin. Vi hadde bare ikke den nødvendige beregningskraften og AI‑en til å gjøre det mulig. 25 år senere har vi endelig det.

Fra tjenestenivå til opplevelsenivå

Observabilitetskonseptet oppsto ikke i IT. I 1960 fant den ungarsk‑amerikanske ingeniøren og matematikeren Rudolf E. Kálmán fant på begrepet \”observability\” for å beskrive hvor godt et system kan måles via sine utdata. Så, i 2013, tok Twitter begrepet i bruk i en serie blogginnlegg, og impliserte at gammeldags overvåking, gjennom alle de kommersielle standardverktøyene de hadde tilgjengelig, var designet for en annen teknologiatlas og fungerte ikke i mikroserviceskala‑arkitekturer.

Tenk på det som en lege som undersøker en pasient. Legen kan sjekke pulsen, ta blodtrykket og observere andre ytre tegn for indirekte å vurdere pasientens indre helse. I IT må vi gjøre det samme. Når det er en flimmer i pasientens puls, må vi vite om det betyr problemer i nyrene eller leveren. På den skalaen og kompleksiteten av driften som Twitter håndterte for 20 år siden (selskapet betjente kun 100 millioner brukere med sanntids‑tweets og strømmer), krevde observabilitet et annet verktøy‑ og overvåkingsoppsett.

Dagens systemer har blitt enda større og mer komplekse, med avhengigheter til innholdsleveringsnettverk, caching og distribusjon av bitmap‑bilder, skrifttyper, JavaScript‑filer og lignende over hele verden. Å virkelig forstå ytelsen til virkelige applikasjoner er ingen enkel oppgave.

Når IT blir varslet klokken 04.00 om morgenen, må noen stå opp og finne ut om problemet skyldes en dårlig sektor på en harddisk eller en ondsinnet aktør som prøver å trenge inn og forårsake kaos i infrastrukturen. Det spiller egentlig ingen rolle hvilken som er årsaken: til syvende og sist er deres jobb å holde alle systemene i gang. Heldigvis kan vi i dag, for å vurdere applikasjonshelse, samle inn all tilgjengelig telemetri: hver nettverksenhet, hver applikasjon, tusenvis av standardintegrasjoner, billettflyt gjennom JIRA eller Atlassian, og mange andre signaler.

Det er her Experience Level Objectives (XLOs) kommer inn. Du har sannsynligvis hørt om Service Level Agreements (SLAs) og Service Level Objectives (SLOs), men XLOs tar steget videre ved å måle om kundene og de ansatte får den opplevelsen de ønsker. Det handler om kvalitet, ikke bare oppetid. Fra et teknisk perspektiv er den eneste måten å oppnå XLOs på å ha synlighet fra NIC til sluttbrukerens enhet.

I oktober i fjor gikk AWS US‑EAST‑1 gikk ned. Catchpoint oppdaget problemet 16 minutter før Amazon offentlig anerkjente det. Kunder med den synligheten kunne reagere før brukerne deres merket konsekvensene av driftsavbruddet.

Løftet med observabilitet er som Smokey Bear: oppdage hvor det er røyk før det blir brann. Gjort riktig lar observabilitet deg slukke en præriebrann før den utvikler seg til en inferno som ødelegger Palisades i California. Smokey er varslingssystemet som kan oppdage de små røykpustene uansett hvor de kommer fra: et AWS‑problem, et Oracle‑problem, et GCP‑problem, et Microsoft Azure‑problem, eller noe galt i infrastrukturen din.

AI skalerer sikkerhetssystemer

Ingen menneskelig operatør kan holde oversikt over dagens infrastruktursystemer. Den eneste måten å overvåke systemer i skala, med petabyte med loggdata og billioner av målinger per dag, er å bruke AI.

For eksempel, si at du vil spore lese‑/skrive‑ytelsen på en disk eller inn‑/ut‑data eller pakkebuffer‑overløp i ditt nettverksmiljø. Du kan bruke en dynamisk terskel for å definere hva som er normalt, eller en deterministisk metode for å se på tidsseriedata fra den siste uken, måneden, året, eller hvilken tidsramme du ønsker, og etablere normale ytelsesterkler. Når du har denne statistiske analysen, kan du sette nivåer for to standardavvik fra gjennomsnittet, slik at når noe skjer utenfor dette området, får du en varsling om at ytelsen potensielt er unormal.

Svært komplekse systemer kan imidlertid motta tusenvis av varsler per dag. Dashbordene begynner å blinke, og folk blir varslet. Å sile gjennom alle disse varslene er ikke en god bruk av menneskers tid. Faktisk anslår Vectra at organisasjoner i gjennomsnitt mottar 2 992 sikkerhetsvarsler per dag, hvorav 63 % forblir ubehandlet.

AI‑verktøy kan redusere disse tusenvis av varsler per dag til bare noen dusin. Jeg husker ett tilfelle der et enkelt problem på ett enkelt NIC på én maskin forårsaket 2 000 nedstrøms varsler. Takket være AI klarte kunden å utføre varselskorrigering og komme frem til en mye raskere rotårsaksanalyse, som igjen konkluderte med at ett problem på dette tidspunktet forårsaket at hele selskapets dashbord ble rødt.

AI gjør IT spennende igjen

Jeg tok meg litt fri etter at Cisco kjøpte opp Splunk i 2023. I løpet av de neste to årene så jeg hvordan venner og tidligere kolleger grunnla selskaper for å bruke AI på måter som ikke var mulig for fem år siden. (Husk at hvis ChatGPT var et menneskelig barn, ville det vært en treåring).

IT‑teamene trenger hjelp til å oppdage røyk før alarmen går, ikke flere dashbord å stirre på. De. På en måte er dette det samme problemet som IBM, Twitter og til og med Microsoft med Clippy har forsøkt å løse.

Dette er grunnen til at jeg bestemte meg for å hoppe tilbake inn. Teknologien har endelig nådd et punkt hvor vi kan innfri det opprinnelige løftet om observabilitet og autonom IT.