Fra oppetid til oplevelse: Det AI-drevne skift i moderne observabilitet

I 2001 skrev IBM et manifest for autonom IT. Visionen om autonom computing delte selvstyring op i fire søjler: selvoptimering, selvhelbredelse, selvkonfiguration og selvbeskyttelse. Jeg var hos Microsoft, da IBM fremlagde denne IT‑vision. Vi reagerede ved at foreslå teknologiske idéer som det autonome datacenter, men i sidste ende var det en drøm, der lå langt foran sin tid. Der fandtes ingen praktisk måde at omsætte den vision til virkelighed.

I mine Microsoft‑dage var jeg på holdet bag Clippy. Selvom den animerede papirclips‑assistent var berygtet påtrængende, var idéen bag den solid: computere bør aktivt hjælpe mennesker med at udføre deres arbejde. Vi havde blot ikke den nødvendige beregningskraft og AI til at gøre det muligt. 25 år senere kan vi endelig gøre det.

Fra serviceniveau til oplevelsesniveau

Konceptet observabilitet opstod ikke inden for IT. I 1960 opfandt den ungarsk-amerikanske ingeniør og matematiker Rudolf E. Kálmán opfandt begrebet \”observability\” for at beskrive, hvor godt et system kan måles via sine output. Så, i 2013, tog Twitter udtrykket i brug i en række blogindlæg, hvilket i praksis betød, at den gammeldags overvågning, gennem alle de kommercielle standardværktøjer de havde til rådighed, var designet til en anden teknologisk æra og ikke fungerede i mikroservice‑skala arkitekturer.

Tænk på det som en læge, der undersøger en patient. Lægen kan måle pulsen, tage blodtrykket og observere andre ydre tegn for indirekte at vurdere patientens indre helbred. I IT skal vi gøre det samme. Når der er en flimmer i patientens puls, skal vi vide, om det betyder problemer i nyrerne eller leveren. På den skala og kompleksitet af drift, som Twitter håndterede for 20 år siden (virksomheden betjente kun 100 millioner brugere med realtids‑tweets og feeds), krævede observabilitet et andet værktøjssæt og en anden overvågningsmetode.

Dagens systemer er blevet endnu større og mere komplekse, med afhængigheder af indholdsleveringsnetværk, caching og distribution af bitmap‑filer, skrifttyper, JavaScript‑filer osv. over hele verden. At forstå den faktiske ydeevne af virkelige applikationer er ingen let opgave.

Når IT bliver paget kl. 4 om morgenen, må nogen stå op af sengen og finde ud af, om problemet skyldes en defekt sektor på en harddisk eller en ondsindet aktør, der forsøger at trænge ind og forårsage kaos i infrastrukturen. Det er i bund og grund irrelevant, hvilken der er tale om: i sidste ende er deres opgave at holde alle systemer i drift. Heldigvis kan vi i dag, for at vurdere applikations‑sundhed, indsamle al tilgængelig telemetri: hver netværksenhed, hver applikation, tusindvis af standardintegrationer, ticket‑flow gennem JIRA eller Atlassian og utallige andre signaler.

Det er her Experience Level Objectives (XLO’er) kommer ind i billedet. Du har sikkert hørt om Service Level Agreements (SLA’er) og Service Level Objectives (SLO’er), men XLO’er tager det næste skridt ved at måle, om dine kunder og medarbejdere får den oplevelsesgrad, de ønsker. Det handler om kvalitet, ikke kun oppetid. Set fra et teknisk perspektiv er den eneste måde at opnå XLO’er på at have synlighed fra NIC’en til slutbrugerens enhed.

I sidste oktober gik AWS US‑EAST‑1 gik ned. Catchpoint opdagede problemet 16 minutter før Amazon offentligt bekræftede det. Kunder med den synlighed kunne reagere, før deres brugere mærkede konsekvenserne af nedbruddet.

Løftet om observabilitet er som Smokey Bear: at opdage, hvor der er røg, før der er brand. Gøres det rigtigt, gør observabilitet det muligt at slukke en præriebrand, før den udvikler sig til en flamme, der ødelægger Palisades i Californien. Smokey er det tidlige varslingssystem, der kan opdage de små røgsprøjt, uanset hvor de kommer fra: et AWS‑problem, et Oracle‑problem, et GCP‑problem, et Microsoft Azure‑problem eller noget, der er galt i din infrastruktur.

AI skalerer sikkerhedssystemer

Ingen menneskelig operatør kan holde styr på dagens infrastruktursystemer. Den eneste måde at overvåge systemer i stor skala, ved at indtage petabytes af logdata og billioner af målinger pr. dag, er at bruge AI.

For eksempel, antag at du vil spore læse/skriv‑ydelsen på en disk eller input/output‑ eller pakkebuffer‑overløb i dit netværksmiljø. Du kan bruge en dynamisk tærskel til at definere, hvad der er normalt, eller en deterministisk metode til at se på tidsseriedata fra den seneste uge, måned, år eller hvilken som helst tidsramme du ønsker, og fastlægge normale ydelsestærskler. Når du har denne statistiske analyse, kan du sætte niveauer for to standardafvigelser fra gennemsnittet, så når noget sker uden for dette interval, får du en alarm om, at ydelsen potentielt er unormal.

Meget komplekse systemer kan dog modtage tusindvis af alarmer pr. dag. Dashboards begynder at blinke, og folk begynder at blive paget. At gennemgå alle disse alarmer er ikke en god udnyttelse af menneskers tid. Faktisk anslår Vectra anslår, at organisationer i gennemsnit modtager 2,992 sikkerhedsalarmer pr. dag, hvoraf 63 % forbliver ubehandlede.

AI‑værktøjer kan reducere disse tusindvis af alarmer om dagen til kun et par dusin. Jeg husker et tilfælde, hvor et enkelt problem på et enkelt NIC på en enkelt maskine udløste 2.000 efterfølgende alarmer. Takket være AI kunne kunden udføre alarmkorrelation og nå frem til en meget hurtigere rodårsagsanalyse, som igen viste, at ét problem på dette tidspunkt fik hele virksomhedens dashboard til at blive rødt.

AI gør IT spændende igen

Jeg holdt en pause, efter at Cisco købte Splunk i 2023. I løbet af de næste to år så jeg, hvordan mine venner og tidligere kolleger grundlagde virksomheder for at bruge AI på måder, der ikke var mulige for fem år siden. (Husk, at hvis ChatGPT var et menneskeligt barn, ville det være tre år gammelt).

IT‑teams har brug for hjælp til at opdage røg, før alarmen går, ikke flere dashboards at stirre på. De. På en måde er dette det samme problem, som IBM, Twitter og endda Microsoft med Clippy har forsøgt at løse.

Det er grunden til, at jeg besluttede at kaste mig tilbage i det. Teknologien har endelig nået et punkt, hvor vi kan indfri det oprindelige løfte om observabilitet og autonom IT.