De la timp de funcționare la experiență: schimbarea condusă de AI în observabilitatea modernă

În 2001, IBM a scris un manifest pentru IT autonom. The Vision of Autonomic Computing a descompus auto‑gestionarea în patru piloni: auto‑optimizare, auto‑vindecare, auto‑configurare și auto‑protecție. Eu eram la Microsoft când IBM a prezentat această viziune IT. Am reacționat propunând idei tehnologice precum centrul de date autonom, dar, în final, a fost un vis mult înaintea timpului său. Nu exista o modalitate practică de a transforma acea viziune în realitate.

În perioada mea la Microsoft, am făcut parte din echipa care a creat Clippy. Deși asistentul cu agrafă animată era infam notorios intruziv, ideea din spatele său era solidă: calculatoarele ar trebui să ajute activ oamenii să‑și facă treaba. Pur și simplu nu aveam puterea de calcul și AI‑ul necesar pentru a o face posibilă. 25 de ani mai târziu, în sfârșit reușim.

De la nivel de serviciu la nivel de experiență

Conceptul de observabilitate nu a apărut în IT. În 1960, inginerul și matematicianul maghiaro‑american Rudolf E. Kálmán coined termenul „observabilitate” pentru a descrie cât de bine poate fi măsurat un sistem prin ieșirile sale. Apoi, în 2013, Twitter adopted the term într-o serie de postări pe blog, afirmând practic că monitorizarea tradițională, prin toate instrumentele comerciale disponibile, era concepută pentru o eră tehnologică diferită și nu funcționa în arhitecturi la scară de microservicii.

Gândește‑te la asta ca la un doctor care examinează un pacient. Acesta poate verifica pulsul, măsura tensiunea arterială și observa alte caracteristici externe pentru a evalua indirect sănătatea internă a pacientului. În IT, trebuie să facem același lucru. Când există o scădere în pulsul pacientului, trebuie să știm dacă înseamnă probleme la rinichi sau la ficat. La scară și complexitatea operațiunilor cu care se confrunta Twitter chiar și acum 20 de ani (compania servea doar 100 de milioane de utilizatori cu tweeturi și fluxuri în timp real), observabilitatea necesita un set diferit de instrumente și abordări de monitorizare.

Sistemele de astăzi au devenit și mai mari și mai complexe, cu dependențe de rețele de livrare a conținutului, caching și distribuție de bitmapuri, fonturi, fișiere JavaScript etc., în întreaga lume. Înțelegerea reală a performanței aplicațiilor din viața reală nu este deloc ușoară.

Când IT-ul primește o alertă la ora 4 dimineața, cineva trebuie să se ridice din pat și să afle dacă problema provine de la un sector defect pe un hard disk sau de la un actor rău intenționat care încearcă să pătrundă și să provoace haos în infrastructură. Nu contează cu adevărat care este cauza: la final, sarcina lor este să mențină toate sistemele în funcțiune. Din fericire, pentru a evalua sănătatea aplicațiilor astăzi, putem prelua toate datele de telemetrie disponibile: fiecare dispozitiv de rețea, fiecare aplicație, mii de integrări gata de utilizare, fluxul de tichete prin JIRA sau Atlassian și nenumărate alte semnale.

Aici intervin Obiectivele de Nivel Experiență (XLO). Probabil ați auzit de Acordurile de Nivel de Serviciu (SLA) și de Obiectivele de Nivel de Serviciu (SLO), dar XLO-urile fac pasul următor măsurând dacă clienții și angajații dvs. primesc nivelul de experiență pe care îl doresc. Este vorba despre calitate, nu doar despre timp de funcționare. Din punct de vedere tehnic, singura modalitate de a atinge XLO-urile este să aveți vizibilitate de la NIC până la dispozitivul utilizatorului final.

În octombrie trecut, AWS US‑EAST‑1 went down. Catchpoint a detectat problema cu 16 minute înainte ca Amazon să o recunoască public. Clienții care aveau acea vizibilitate au putut reacționa înainte ca utilizatorii lor să simtă consecințele întreruperii.

Promisiunea observabilității este ca Smokey Bear: să detectezi fumul înainte să apară focul. Dacă este implementată corect, observabilitatea îți permite să stingi un incendiu de prairie înainte să devină o conflagrație care distruge Palisades din California. Smokey este sistemul de avertizare timpurie care poate detecta acele mici mirosuri de fum, indiferent de sursa lor: o problemă AWS, o problemă Oracle, o problemă GCP, o problemă Microsoft Azure sau ceva neregulat în infrastructura dvs.

AI scalează sistemele de securitate

Niciun operator uman nu poate monitoriza sistemele de infrastructură de astăzi. Singura modalitate de a monitoriza sistemele la scară, preluând petabytes de date de jurnal și trilioane de metrici pe zi, este să folosești AI.

De exemplu, să zicem că doriți să monitorizați performanța de citire/scriere pe un disc sau intrările/ieșirile sau depășirile de buffer de pachete în mediul dvs. de rețea. Puteți folosi un prag dinamic pentru a defini ce este normal, sau o metodă deterministică pentru a analiza seriile temporale din săptămâna, luna, anul sau orice interval doriți, și să stabiliți praguri de performanță normale. Odată ce aveți această analiză statistică, puteți seta niveluri la două deviații standard față de medie, astfel încât, când ceva se întâmplă în afara acelui interval, primiți o alertă că performanța este potențial anormală.

Totuși, sistemele extrem de complexe pot primi mii de alerte pe zi. Dashboard‑urile încep să clipească, iar oamenii sunt alertați. Filtrarea tuturor acestor alerte nu este o utilizare eficientă a timpului uman. De fapt, Vectra estimates că organizațiile primesc în medie 2.992 de alerte de securitate pe zi, dintre care 63% rămân neadresate.

Instrumentele AI pot reduce aceste mii de alerte pe zi la doar câteva zeci. Îmi amintesc un caz în care o singură problemă pe o singură placă de rețea (NIC) a unui singur server a generat 2.000 de alerte în aval. Datorită AI, clientul a reușit să efectueze corelarea alertelor și să ajungă la o analiză a cauzei rădăcinii mult mai rapidă, concluzia fiind că o singură problemă, în acel moment, făcea ca întregul tablou de bord al companiei să devină roșu.

AI ca IT-ul să fie din nou incitant

Am luat o pauză după ce Cisco a achiziționat Splunk în 2023. În următorii doi ani, am urmărit cum prietenii și foștii mei colegi au fondat companii pentru a folosi AI în moduri care nu erau posibile nici acum cinci ani. (Rețineți că, dacă ChatGPT ar fi un copil uman, ar avea trei ani).

Echipele IT au nevoie de ajutor pentru a detecta fumul înainte ca alarma să sune, nu de mai multe tablouri de bord la care să privească. Ei. Într-un fel, aceasta este aceeași problemă pe care IBM, Twitter și chiar Microsoft cu Clippy au încercat să o rezolve.

Acesta este motivul pentru care am decis să revin în acțiune. Tehnologia a ajuns în sfârșit la un punct în care putem îndeplini promisiunea inițială a observabilității și a IT-ului autonom.