Käytettävyyden ajasta kokemukseen: tekoälyohjattu muutos nykyaikaisessa havainnoinnissa

Vuonna 2001 IBM kirjoitti autonomisen IT-manifestin. Autonomisen tietojenkäsittelyn visio hajotti itsehallinnan neljään pilariin: itseoptimointi, itseparantuminen, itsesäätö ja itsesuojelu. Olin Microsoftilla, kun IBM esitteli tämän IT-vision. Reagoimme ehdottamalla teknologisia ideoita, kuten autonomista datakeskusta, mutta lopulta se oli unelma, joka oli aikansa ohi. Käytännön keinoa toteuttaa tuo visio ei ollut.

Microsoft-urani aikana olin Clippyn takana olevassa tiimissä. Vaikka animoitu paperiliitin-apulainen oli maineikkaasti tunkeileva, sen taustalla oleva ajatus oli järkevä: tietokoneiden tulisi aktiivisesti auttaa ihmisiä tekemään työnsä. Meillä ei vain ollut riittävää laskentatehoa ja tekoälyä sen toteuttamiseksi. 25 vuotta myöhemmin me lopulta onnistumme.

Palvelutasolta kokemustasolle

Havainnoinnin käsite ei syntynyt IT-alalla. Vuonna 1960 unkarilais-amerikkalainen insinööri ja matemaatikko Rudolf E. Kálmán keksi termin “observability” kuvaamaan, kuinka hyvin järjestelmää voidaan mitata sen ulostuloilla. Sitten, vuonna 2013 Twitter omaksui termin sarjassa blogikirjoituksia, sanoen käytännössä, että vanhanaikainen valvonta, kaikkien käytettävissään olevien kaupallisten valmiiksi saatavilla olevien työkalujen kautta, oli suunniteltu eri teknologia-ajan tarpeisiin eikä toiminut mikropalvelu-asteisen arkkitehtuurin kanssa.

Kuvittele se kuin lääkäri tarkastelisi potilasta. Hän voi tarkistaa pulssin, mitata verenpaineen ja havaita muita ulkoisia piirteitä arvioidakseen epäsuorasti potilaan sisäistä terveyttä. IT-alalla meidän on tehtävä sama. Kun potilaan pulssissa on vilkkuminen, meidän on tiedettävä, tarkoittaako se ongelmia munuaisissa vai maksassa. Sillä mittakaavalla ja monimutkaisuudella, jolla Twitter toimi jo 20 vuotta sitten (yritys palveli vain 100 miljoonaa käyttäjää reaaliaikaisilla tweeteillä ja syötteillä), havainnoitavuus vaati erilaista työkalua ja valvontamenetelmää.

Nykypäivän järjestelmät ovat kasvaneet entistä suuremmiksi ja monimutkaisemmiksi, riippuen sisällönjakeluverkoista, välimuistista ja bittikarttojen, fonttien, JavaScript‑tiedostojen jne. jakelusta ympäri maailmaa. Todellinen ymmärrys todellisten sovellusten suorituskyvystä ei ole helppo tehtävä.

Kun IT saa hälytyksen kello 4 aamulla, jonkun on noustava sängystä ja selvitettävä, johtuuko ongelma viallisesta kiintolevyn sektorista vai pahantahtoisesta toimijasta, joka yrittää tunkeutua ja aiheuttaa kaaosta infrastruktuurissa. Ei ole oikeastaan väliä, kumpi se on: lopulta heidän tehtävänsä on pitää kaikki järjestelmät toiminnassa. Onneksi sovelluksen terveyden arvioimiseksi tänään voimme kerätä kaiken saatavilla olevan telemetrian: jokaisen verkkolaitteen, jokaisen sovelluksen, tuhannet valmiit integraatiot, tikettivirrat JIRA:n tai Atlassianin kautta ja monet muut signaalit.

Tässä kohtaa Experience Level Objectives (XLOt) tulevat kuvaan. Olet todennäköisesti kuullut Service Level Agreements (SLA:t) ja Service Level Objectives (SLO:t), mutta XLOt vievät askeleen pidemmälle mittaamalla, saavatko asiakkaasi ja työntekijäsi haluamansa kokemustason. Kyse on laadusta, ei pelkästä käyttöajasta. Teknisen näkökulman mukaan ainoa tapa saavuttaa XLOt on saada näkyvyys NIC:stä loppukäyttäjän laitteeseen.

Viime lokakuussa AWS US‑EAST‑1 kaatui. Catchpoint havaitsi ongelman 16 minuuttia ennen kuin Amazon julkisesti myönsi sen. Asiakkaat, joilla oli tämä näkyvyys, pystyivät reagoimaan ennen kuin heidän käyttäjänsä tunsivat katkoksen seuraukset.

Havainnoinnin lupaus on kuin Smokey Bear: havaita savua ennen kuin se muuttuu tulipaloiksi. Jos se tehdään oikein, havainnoinnin avulla voit sammuttaa preerian liekin ennen kuin siitä tulee suuri tulipalo, joka pyyhkii pois Palisadesin Kaliforniassa. Smokey on varhainen varoitusjärjestelmä, joka pystyy havaitsemaan ne pienet savun hajut riippumatta siitä, mistä ne tulevat: AWS‑ongelma, Oracle‑ongelma, GCP‑ongelma, Microsoft Azure‑ongelma tai jokin vika infrastruktuurissasi.

Tekoäly skaalaa turvallisuusjärjestelmiä

Mikään ihminen ei pysty pitämään silmällä nykypäivän infrastruktuurijärjestelmiä. Ainoa tapa valvoa järjestelmiä mittakaavassa, käsitellen petatavua lokitietoa ja biljoonia mittareita päivässä, on käyttää tekoälyä.

Esimerkiksi jos haluat seurata levyn luku-/kirjoitusnopeutta tai syötteen/vedon tai pakettipuskurin ylivuotoja verkkoympäristössäsi. Voit käyttää dynaamista kynnysarvoa määrittääksesi, miltä normaali näyttää, tai deterministista tapaa tarkastella aikasarjadataa viimeisen viikon, kuukauden, vuoden tai minkä tahansa haluamasi aikavälin aikana ja asettaa normaalin suorituskyvyn kynnykset. Kun sinulla on tämä tilastollinen analyysi, voit asettaa tasot kahdelle keskiarvosta poikkeavalle keskihajonnalle, jotta kun jokin tapahtuu kyseisen rajan ulkopuolella, saat hälytyksen, että suorituskyky on mahdollisesti poikkeava.

Erittäin monimutkaiset järjestelmät voivat kuitenkin saada tuhansia hälytyksiä päivässä. Hallintapaneelit alkavat vilkkua ja ihmiset alkavat saada hälytyksiä. Näiden hälytysten läpikäyminen ei ole hyvä tapa käyttää ihmisten aikaa. Itse asiassa Vectra arvioi, että organisaatiot saavat keskimäärin 2 992 turvallisuushälytystä päivässä, joista 63 % jää käsittelemättä.

AI-työkalut voivat vähentää nämä tuhannet päivittäiset hälytykset vain muutamaan kymmenikseen. Muistan tapauksen, jossa yksi ongelma yhdellä NIC:llä yhdellä koneella aiheutti 2 000 alapuolista hälytystä. Kiitos AI:n, asiakas pystyi suorittamaan hälytysten korrelaation ja saavuttamaan paljon nopeamman perimmäisen syyn analyysin, jonka seurauksena todettiin, että yksi ongelma juuri sillä hetkellä sai koko yrityksen hallintapaneelin punaiseksi.

AI tekee IT:stä jälleen jännittävän

Pidin taukoa sen jälkeen, kun Cisco hankki Splunkin vuonna 2023. Seuraavien kahden vuoden aikana seurasin, kuinka ystäväni ja entiset kollegani perustivat yrityksiä käyttämään AI:ta tavoilla, jotka eivät olleet mahdollisia vielä viisi vuotta sitten. (Muista, että jos ChatGPT olisi ihmislapsi, se olisi kolmivuotias).

IT-tiimit tarvitsevat apua savun havaitsemiseen ennen kuin hälytys soi, eivät enempää hallintapaneeleja katseltavaksi. He. Jollain tavalla tämä on sama ongelma, jonka IBM, Twitter ja jopa Microsoft Clippyn kanssa ovat yrittäneet ratkaista.

Tämä on syy, jonka takia päätin hypätä takaisin mukaan. Teknologia on vihdoin saavuttanut pisteen, jossa voimme täyttää alkuperäisen observabiliteetin ja autonomisen IT:n lupauksen.