Från drifttid till upplevelse: Den AI‑drivna förändringen i modern observabilitet

År 2001 skrev IBM ett manifest för autonom IT. Visionen för autonom databehandling delade upp självhantering i fyra pelare: självoptimering, självläkning, självkonfiguration och självskydd. Jag var på Microsoft när IBM presenterade denna IT‑vision. Vi reagerade genom att föreslå teknologiska idéer som det autonoma datacentret, men i slutändan var det en dröm som låg långt före sin tid. Det fanns inget praktiskt sätt att förverkliga den visionen.

Under mina år på Microsoft var jag med i teamet bakom Clippy. Även om den animerade gem‑assistenten var ökänd för att vara påträngande, var idén bakom den sund: datorer bör aktivt hjälpa människor att utföra sina jobb. Vi hade bara inte den beräkningskraft och AI som krävdes för att göra det möjligt. 25 år senare har vi äntligen möjlighet.

Från servicenivå till upplevelsenivå

Begreppet observabilitet uppstod inte inom IT. År 1960 myntade den ungersk‑amerikanska ingenjören och matematikern Rudolf E. Kálmán termen “observabilitet” för att beskriva hur väl ett system kan mätas via sina utdata. Sedan, år 2013, adopterade termen i en serie blogginlägg, vilket i praktiken sade att gammaldags övervakning, med alla kommersiella färdiga verktyg de hade tillgängliga, var avsedd för en annan teknologisk era och inte fungerade i mikroserviceskala‑arkitekturer.

Tänk på det som en läkare som undersöker en patient. De kan kontrollera pulsen, ta blodtrycket och observera andra yttre tecken för att indirekt bedöma patientens inre hälsa. Inom IT måste vi göra samma sak. När det finns en fläkt i patientens puls måste vi veta om det betyder problem i njurarna eller levern. På den skala och komplexitet som Twitter hanterade för 20 år sedan (företaget betjänade bara 100 miljoner användare med realtids‑tweets och flöden) krävde observabilitet ett annat verktygs‑ och övervakningssätt.

Dagens system har blivit ännu större och mer komplexa, med beroenden på innehållsleveransnätverk, cachning och distribution av bitmaps, typsnitt, JavaScript‑filer och så vidare över hela världen. Att verkligen förstå prestandan hos verkliga applikationer är ingen lätt uppgift.

När IT blir uppringd klockan fyra på morgonen måste någon gå upp ur sängen och ta reda på om problemet beror på en dålig sektor på en hårddisk eller en illasinnad aktör som försöker tränga in och skapa kaos i infrastrukturen. Det spelar egentligen ingen roll vilken det är: i slutändan är deras uppgift att hålla alla system igång. Lyckligtvis kan vi idag bedöma applikationshälsa genom att samla in all tillgänglig telemetri: varje nätverksenhet, varje applikation, tusentals färdiga integrationer, ärendehantering via JIRA eller Atlassian och många andra signaler.

Det är här Experience Level Objectives (XLOs) kommer in. Du har förmodligen hört talas om Service Level Agreements (SLAs) och Service Level Objectives (SLOs), men XLOs tar nästa steg genom att mäta om dina kunder och anställda får den upplevelsen de önskar. Det handlar om kvalitet, inte bara drifttid. Ur ett tekniskt perspektiv är det enda sättet att uppnå XLOs att ha insyn från NIC till slutanvändarens enhet.

I oktober förra året gick ner. Catchpoint upptäckte problemet 16 minuter innan Amazon offentligt bekräftade det. Kunder med den insynen kunde reagera innan deras användare märkte avbrottets konsekvenser.

Löftet med observabilitet är som Smokey Bear: att upptäcka rök innan det blir en brand. När det görs på rätt sätt låter observabilitet dig släcka en präriebrand innan den blir en förödande eldsvåda som tar ner Palisades i Kalifornien. Smokey är ett tidigt varningssystem som kan upptäcka de små rökpuffarna oavsett var de kommer ifrån: ett AWS‑problem, ett Oracle‑problem, ett GCP‑problem, ett Microsoft Azure‑problem eller något fel i din infrastruktur.

AI skalar säkerhetssystem

Ingen mänsklig operatör kan hålla koll på dagens infrastruktursystem. Det enda sättet att övervaka system i skala, med insamling av petabytes loggdata och triljoner mätvärden per dag, är att använda AI.

Till exempel, anta att du vill spåra läs/skriv‑prestanda på en disk eller in‑/utdata‑ eller paketbufferöverskridanden i ditt nätverksmiljö. Du kan använda ett dynamiskt tröskelvärde för att definiera vad som är normalt, eller ett deterministiskt sätt att titta på tidsseriedata över den senaste veckan, månaden, året eller vilken tidsram du önskar, och fastställa normala prestandatrösklar. När du har denna statistiska analys kan du sätta nivåer för två standardavvikelser från medelvärdet, så att när något inträffar utanför det intervallet får du en varning om att prestandan potentiellt är onormal.

Mycket komplexa system kan dock få tusentals larm per dag. Instrumentpaneler börjar blinka och folk blir uppringda. Att sålla igenom alla dessa larm är inte en bra användning av människors tid. Faktum är att Vectra uppskattar att organisationer i genomsnitt får 2 992 säkerhetslarm per dag, varav 63 % förblir obehandlade.

AI-verktyg kan minska dessa tusentals aviseringar per dag till bara några dussin. Jag minns ett fall där ett enda problem på ett enda nätverkskort på en enda maskin orsakade 2 000 efterföljande aviseringar. Tack vare AI kunde kunden utföra aviseringkorrelation och komma till en mycket snabbare rotorsaksanlysning, vilket i sin tur visade att ett problem vid just detta tillfälle fick hela företagets instrumentpanel att bli röd.

AI gör IT spännande igen

Jag tog lite ledigt efter att Cisco förvärvade Splunk 2023. Under de följande två åren såg jag hur mina vänner och tidigare kollegor grundade företag för att använda AI på sätt som inte var möjliga för fem år sedan. (Kom ihåg att om ChatGPT vore ett mänskligt barn, skulle det vara tre år gammalt).

IT-team behöver hjälp att upptäcka rök innan larmet går, inte fler instrumentpaneler att stirra på. De. På ett sätt är detta samma problem som IBM, Twitter och till och med Microsoft med Clippy har försökt lösa.

Det är därför jag bestämde mig för att hoppa tillbaka in. Tekniken har äntligen nått en punkt där vi kan hålla det ursprungliga löftet om observabilitet och autonom IT.