La Stebimumas iš nišinės techninės temos tapo strateginiu ramsčiu Bet kuriai organizacijai, kuri priklauso nuo programinės įrangos – o tai praktiškai yra visos jos – vien „serverių stebėjimo“ ar atskirų ataskaitų suvestinių peržiūros nebeužtenka. Įmonės turi suprasti, kas vyksta jų sistemose realiuoju laiku, susieti šiuos duomenis su verslo duomenimis ir greitai reaguoti, kai kas nors nutinka ne taip. Be to, tai daryti jos turi vis labiau programinės įrangos valdomoje aplinkoje. Agento dirbtinis intelektas, atvirieji standartai ir paskirstytosios architektūros.
Šiuo atveju tendencija akivaizdžiai rodo, kad atviresnis stebimumas, glaudžiau susijęs su verslo rezultatais ir daug autonomiškesnis„OpenTelemetry“ tampa bendra telemetrijos kalba, dirbtinis intelektas žengia toliau nei eksperimentai ir integruojasi į pagrindinę stebėjimo platformų struktūrą, o „ITops“ komandos transformuojasi į išmaniųjų sistemų, kurios pačios aptinka, analizuoja ir net ištaiso problemas, organizatorius. Panagrinėkime, kaip vyksta šis pokytis ir kokį poveikį jis turi technologijoms, verslui, saugumui ir duomenų valdymui.
Nuo klasikinio stebėjimo iki stebimumo eros
Evoliucija nuo tradicinio stebėjimo link modernaus stebimumo Tai siekia tolimus laikus. Kai atsirado novatoriškos APM priemonės, tokios kaip Lew Cirne išpopuliarintos su „New Relic“, didžiausia naujiena buvo galimybė išsamiai matyti, ką monolitinės programos kodas veikia įmonės duomenų centre. Tai buvo revoliucija: pirmą kartą komandos galėjo stebėti savo gamybinių programų našumą labai smulkiu detalumu.
Atvykus debesų kompiuterija, mikropaslaugos, konteineriai, beserverė kompiuterija ir „DevOps“ bei SRE praktikosPadėtis visiškai pasikeitė. Perėjimas nuo monolitinių prie paskirstytų sistemų reiškė, kad matomumo konkrečiu momentu nebepakako. Paslauga nebėra viena programa, o efemeriškų mikropaslaugų spiečius, valdomas tokiose platformose kaip „Kubernetes“, diegiamas dešimtis kartų per dieną ir veikiantis hibridinėse infrastruktūrose su keliais debesijos teikėjais.
Tokioje aplinkoje tradicinis stebėjimas, orientuotas į iš anksto nustatytus rodiklius ir statinius įspėjimus, yra nepakankamas. Stebimumas pristato kitokį požiūrį: metrikų, žurnalų, pėdsakų ir įvykių rinkimą ir koreliaciją. nustatyti vidinę sistemos būseną iš jos išorinių išvesčių. Svarbu ne tik žinoti, kad kažkas nepavyko, bet ir suprasti, kodėl tai įvyko ir kokį poveikį tai daro vartotojui ir verslui.
Autoriams patinka Jurijus Škuro Šis skirtumas yra gerai apibendrintas: stebėsena matuoja tai, kas iš anksto nuspręsta kaip svarbu, o stebimumas leidžia suformuluoti naujus klausimus apie sistemą iš anksto neparuošus visų rodiklių. Kitaip tariant, Stebimumas paverčia telemetrijos duomenis veiksmingomis aplinkybėmis plėtrai, operacijoms ir verslui.
Šį perėjimą taip pat lemia labai specifiniai veiksniai: a žiaurus spaudimas greitai diegti naujovesVis reiklesni klientai, kurie atsisako programėlės vos pastebėję menkiausią trūkumą, beveik begalinis technologijų ir valdomų paslaugų pasirinkimas ir augantis viso programinės įrangos gyvavimo ciklo automatizavimasVisa ta automatizacija taip pat yra programinė įranga, kuri gali sugesti, ir jai reikia savo stebimumo.
Sudėtingumas, rizika ir per daug įrankių: kodėl stebimumas yra labai svarbus
Šiuolaikinė architektūra kelia keturis pagrindinius galvos skausmus, dėl kurių Stebimumas yra praktiškai privalomas Jei norite išlaikyti kontrolę:
Pirma, sudėtingumas išaugo iki neregėtų aukštumųKonteineris gali gyvuoti minutes ar sekundes, mikropaslauga gali keisti versijas kelis kartus per dieną, o komponentų daugėja. Tai, kas kadaise buvo monolitinė programa, tampa tarpusavyje sujungtų paslaugų žvaigždynu. Operacijų komandos susiduria su šimtais ar tūkstančiais nuolat kintančių objektų, kurių daugelio jos pačios nesukūrė.
Prie to pridedama a akivaizdus rizikos padidėjimasDiegimas kelis kartus per dieną reiškia nuolatinį pakeitimų ir galimų atšaukimų įvedimą. Lankstūs metodai ir nuolatinis teikimas prideda daugiau įrankių, srautų ir automatizavimo, į kuriuos taip pat reikia atsižvelgti. Gebėjimas greitai aptikti problemą, nustatyti pagrindinę priežastį ir ją atkurti arba ištaisyti per kelias minutes nebėra pageidautinas, o būtinas.
Lygiagrečiai, a įgūdžių spragaTechnologijų rinkinys yra toks platus, kad vienam žmogui neįmanoma įvaldyti duomenų bazių, tinklų, API, saugumo, konteinerių, orkestravimo platformų ir CI/CD įrankių. Reikalingi mechanizmai, kurie padėtų suprasti, kaip viskas dera tarpusavyje, kas nuo ko priklauso ir kur ieškoti, kai kas nors negerai. Be šio sujungto požiūrio, laikas, sugaištas šokinėjant nuo vieno įrankio prie kito, gali būti milžiniškas.
Ir, svarbiausia, kyla problemų dėl „Įrankių išsiplėtimas“ arba įrankių pertekliusKiekvienas steko sluoksnis paprastai turi savo stebėjimo sprendimą: vieną – duomenų bazei, kitą – infrastruktūrai, dar kitą – sąsajai, dar kitą – žurnalams, dar kitą – pėdsakams... Duomenų koreliavimas tarp jų reikalauja nuolatinio konteksto perjungimo, rankinės paieškos ir ilgesnio incidentų sprendimo laiko. Tai visiškai priešinga tam, ko reikia, kai programa neveikia ir vartotojai skundžiasi.
Atsakymas į visa tai slypi tame pačiame vieninga stebimumo platforma kuri renka visą svarbią telemetriją, sujungia ją su ją generuojančiais subjektais ir leidžia bet kuriai komandai – kūrimo, operacijų, saugumo, verslo – tyrinėti ir naudoti šiuos duomenis iš vienos vietos. Tai apima ne tik našumo rodiklius, bet ir verslo įvykius bei signalus, kurie atskleidžia kiekvieno incidento ekonominį poveikį.
„OpenTelemetry“ kaip bendra stebimumo kalba
Viena ryškiausių tendencijų yra konsolidacija. „OpenTelemetry“ (OTel) kaip atviras telemetrijos standartasTai atvirojo kodo sistema, apibrėžianti API, SDK ir komponentus, skirtus metrikai, žurnalams ir pėdsakams rinkti homogeniškai, nepririšant jų prie konkretaus stebėjimo įrankio gamintojo.
Ateinančiais metais to tikimasi Įmonės reikalauja suderinamumo su „OpenTelemetry“ savo tiekėjams. Priežastis paprasta: naudodama „universalią kalbą“ telemetrijai apibūdinti, organizacija gali keisti stebėjimo platformas neperrašydama ar iš naujo neapdorodama viso savo kodo. Tai sumažina tiekėjo priklausomybės riziką ir suteikia lankstumo tobulinti sistemą pagal poreikį.
Priešingai nei visiškai patentuoti sprendimai, kur kiekviena nauja integracija priklauso nuo gamintojo veiksmų plano, „OTel“ Tai leidžia integracijoms išlikti atsparioms technologiniams pokyčiams.Atsiradus naujoms debesijos paslaugoms, karkasams ar vykdymo aplinkoms, joms tereikia standartiniu formatu pateikti telemetrijos duomenis, kad jas būtų galima siųsti į bet kurią suderinamą serverio sistemą.
Be to, „OpenTelemetry“ naudojimas yra labai svarbus tinkamai maitinti dirbtinį intelektąDirbtinio intelekto modeliai, nesvarbu, ar tai tradicinis mašininis mokymasis, anomalijų aptikimas, ar generatyvinis dirbtinis intelektas, geriausiai veikia, kai duomenys yra švarūs, struktūrizuoti ir nuoseklūs. „OTel“ teikia būtent tokią vienodą sistemą telemetrijos, kurią algoritmai vėliau apdoros, generavimui ir žymėjimui.
Naujausi tyrimai rodo, kad organizacijos, kurios jau naudoja „OpenTelemetry“Net ir įgyvendinus tik iš dalies, jie pastebi teigiamą poveikį tokiems rodikliams kaip pajamų augimas, pagerėjusios veiklos maržos ir prekės ženklo reputacija. Tai ne magija: turint nuoseklią ir perkeliamą stebėjimo bazę, lengviau aptikti problemas, kol jos nepaveikia kliento, ir optimizuoti pagrindinių paslaugų našumą.
Trys šiuolaikinės stebimumo praktikos ramsčiai
Be tokio standarto kaip OTel taikymo, patikima stebimumo praktika remiasi ir tuo, kad trys pagrindiniai komponentai, kurie vienas kitą sustiprina: atvira instrumentacija, prijungti subjektai (arba duomenys) ir programuojamumas.
La atvira instrumentacija Tai apima telemetrijos rinkimą tiek iš patentuotų, tiek iš atvirojo kodo agentų. Programos, paslaugos, pagrindiniai kompiuteriai, konteineriai, serverių neturinčios funkcijos, mobiliosios programėlės, valdomos debesijos paslaugos – viskas turi galėti skleisti metriką, įvykius, žurnalus ir pėdsakus standartizuotais formatais. Čia pradeda veikti tradicinių tiekėjų agentai, taip pat eksportuotojai ir bibliotekos iš „OpenTelemetry“ ir kitų atvirojo kodo projektų.
Antrasis blokas yra tas, kuris sujungti subjektai ir metaduomenysVien tik kaupti metriką ir žurnalus nepakanka; reikia suprasti, kas juos generuoja ir kaip jie yra susiję tarpusavyje. Tam reikia identifikuoti paslaugas, duomenų bazes, eiles, funkcijas, pod'us, klasterius, debesies paskyras ir susieti jų telemetriją bei priklausomybes. Šiame kontekste platforma gali automatiškai pateikti architektūros žemėlapius, skambučių srautus ir incidentų laiko juostas, komandai nereikės visko konfigūruoti rankiniu būdu.
Remiantis tuo, galima kreiptis intelektas ir pažangi analizėNustatydamos duomenų rinkinyje esančius modelius, anomalijas ir koreliacijas, stebėjimo platformos gali padėti nustatyti įspėjimų prioritetus, sumažinti triukšmą, aptikti sudėtingus incidentus ir paspartinti pagrindinių priežasčių analizę. Tai natūralus kelias link vis aktyvesnio stebėjimo ir, kaip matysime vėliau, agentinės autonomijos.
Pagaliau yra programuojamumasKiekvienas verslas turi specifinių poreikių: savo KPI, skirtingus kritinius procesus ir unikalius sąnaudų modelius. Šiuolaikinė stebėjimo platforma turi leisti kurti pritaikytas programas ir rodinius, papildančius visą telemetriją: ataskaitų suvestines, kurios sujungia techninius duomenis su verslo rodikliais, ekonominio poveikio analizę, susijusią su sutrikimais ar pablogėjimais, arba vidines programas, skirtas tirti sudėtingus incidentus pagal įmonės darbo eigą.
Ši galimybė „programuoti“ stebimumo duomenis atveria duris tokiems atvejams kaip įvertinti tikrąją klaidos kainą Mokėjimo procese susiekite jį su technine priežastimi (pavyzdžiui, regresija atsiskaitymo mikropaslaugoje) ir tokiu būdu nustatykite taisymo pastangų prioritetą, remdamiesi grynai ekonominio poveikio kriterijais.
Į verslą orientuotas stebimumas: nuo konsolės iki rezultato
Vienas iš svarbiausių numatomų pokyčių yra perėjimas nuo vieno stebimumas, orientuotas į techninę operaciją į kitą, aiškiai į verslą orientuotą. Tie patys duomenys – žurnalai, pėdsakai, metrika, įvykiai – pradedami naudoti ne tik infrastruktūros priežiūrai, bet ir atsakyti į pagrindinius klausimus apie pajamas, išlaidas ir naudotojų patirtį.
Pavyzdžiui, pramonės sektoriuose daiktų interneto jutiklių stebimumas leidžia numatyti mašinų gedimus ir optimizuoti techninės priežiūros planus. Jei aptinkami nenormalūs vibracijos modeliai arba už diapazono ribų esanti temperatūra, galima suplanuoti įsikišimą prieš sustojant gamybos linijai, taip išvengiant neplanuotų prastovų ir jų ekonominių pasekmių.
Finansų sektoriuje analizuojant realiuoju laiku operacijų žurnalai Tai padeda nustatyti įtartinas operacijas, kurios gali būti susijusios su sukčiavimu. Kai sistema aptinka netipines įvykių sekas, neįprastas geolokacijas arba sumas, kurios neatitinka įprastų modelių, ji gali suaktyvinti automatinius blokavimo mechanizmus arba rankinę peržiūrą, kol ataka nebus sėkminga.
Rinkodaros ir pardavimo srityse koreliacija programos pėdsakai su kampanijos metrika Tai leidžia atsakyti į labai tiesioginius klausimus: ar svetainės delsa turi įtakos paspaudimų rodikliui ar konversijai? Kuri funkcijos versija geriausiai pagerina naršymą ir užlaikymo laiką? Jei kampanijos metu sumažėja našumas, stebimumas padeda nustatyti, kiek potencialių pardavimų buvo prarasta ir kuriame tiksliame piltuvo taške kilo problema.
Visa tai apima techninės telemetrijos pavertimą praktinės žinios verslo lyderiamsReikia ne parodyti pardavimų direktoriui procesoriaus grafiką, o parodyti, kiek operacijų nepavyko užbaigti dėl paslaugų pablogėjimo ir kokia buvo numatoma kaina. Norint tai pasiekti, stebimumas tame pačiame modelyje turi susieti techninius duomenis, naudotojų įvykius ir verslo metriką.
Stebimumo srityje besispecializuojančios konsultacinės įmonės, tokios kaip „Nettaro“, jau padeda įmonėms ir įstaigoms kad šis šuolis būtų atliktas nuo grynai operacinės vizijos prie strateginės vizijoskuriant modelius, kurie sujungia verslo KPI su realaus laiko telemetrijos signalais.
Nuo AIOps iki agentų stebimumo
Įvaikinimas Dirbtinis intelektas stebimumo platformose Tai jau realybė. Dauguma ITOps komandų į savo darbo eigą įtraukė AIOps komponentus – algoritmus, kurie analizuoja didelius operatyvinių duomenų kiekius, kad aptiktų anomalijas, grupuotų įvykius arba numatytų problemas.
Daugeliu atvejų jis taip pat integruojamas generatyvinis AI sąveikauti su telemetrija naudojant natūralią kalbą: užduokite pokalbio tipo klausimus, pvz., „kodėl prieš 20 minučių Europoje padidėjo 500 klaidų?“, ir gaukite paaiškinimą, pagrįstą žurnalais, metrika ir pėdsakais, nereikėdami kurti sudėtingų užklausų.
Tačiau šiandien dauguma sprendimų priimami remiantis dirbtiniu intelektu. Juos ir toliau peržiūri žmonėsAlgoritmai padeda filtruoti triukšmą ir nustatyti galimas priežastis, tačiau operacijų komandos išlaiko kontrolę, patvirtina rekomendacijas ir rankiniu būdu atlieka daugelį taisomųjų veiksmų. Visiškas pasitikėjimas automatizuotais sprendimais vis dar ribotas.
Čia yra Agento stebimumasTai metodas, kai dirbtinio intelekto agentai prisiima daug autonomiškesnį vaidmenį: jie ne tik aptinka modelius ir paaiškina, kas vyksta, bet ir Jie valdo visas darbo eigas, nuo gedimo nustatymo iki tinkamo sprendimo įgyvendinimo.
Šiame modelyje agentas gali, pavyzdžiui, aptikti anomaliai padidėjusį kritinės paslaugos delsos laiką, susieti jį su konkrečiu diegimu, patikrinti panašių incidentų istoriją ir pats nuspręsti, ar... paleisti atšaukimą, išplėsti pajėgumus arba pritaikyti alternatyvią konfigūracijąVisa tai yra išsamiai užfiksuojama auditui ir galimai vėlesnei žmonių peržiūrai.
Šiuo metu tik nedidelė dalis įmonių naudojasi šia galimybe Aktyvaus agento stebimumassu automatizuotu taisymu ir pažangiu problemų prognozavimu. Tačiau prognozės rodo, kad jo diegimas gerokai išaugs dėl didesnio IT komandų produktyvumo paieškos ir poreikio sumažinti laiką, kurį jos skiria pasikartojančioms priežiūros užduotims.
Rankinės priežiūros apribojimai ir autonomijos poreikis
Savarankiškai dirbančių agentų paklausa geriau suprantama, jei nagrinėjame kraštutinius atvejus, tokius kaip didelio kalbų modelio stebimumas (LLM)Rankinis tokių sistemų stebėjimas yra beveik neįmanoma užduotis: duomenų kiekiai yra milžiniški, architektūros apjungia kelis paskirstytus komponentus, o stebėjimo realiuoju laiku poreikis yra nuolatinis.
Įrašų ir metrikų gausa tai lemia Rankinis problemų nustatymas yra labai lėtasBet koks delsimas aptinkant elgesio pokyčius, klaidų skaičiaus padidėjimą ar atsakymų kokybės pablogėjimą gali turėti rimtų pasekmių gamybinėje aplinkoje, tiek vartotojo patirties, tiek reputacijos ir atitikties reglamentams požiūriu.
Be to, rankinis stebėjimas sunaudoja daug žmogiškųjų išteklių; linkęs į klaidas ir nėra gerai keičiamas Augant modelių, egzempliorių ar integracijų su verslo programomis skaičiui, tai, kas gali veikti bandomajame projekte su keliais vartotojais, tampa kliūtimi, kai sistema diegiama visoje organizacijoje.
Todėl sudėtingose aplinkose, tokiose kaip LLM arba labai paskirstytos architektūros, poreikis autonominių stebimumo sprendimųKalbame apie sistemas, galinčias nuolat analizuoti telemetriją, aptikti nukrypimus, siūlyti arba vykdyti taisomuosius veiksmus ir mokytis iš kiekvienos intervencijos, siekiant laikui bėgant pagerinti jų efektyvumą.
Vizijos ir veiksmų agentai bei automatizavimas sąsajose
Dirbtinio intelekto pažanga neapsiriboja „klasikinio“ stebimumo sritimi. Tyrimus atlieka tokios įmonės kaip NVIDIA, įgyvendindamos tokius projektus kaip Nitrogenas Tai skatina modelius, kurie sujungia regėjimo ir veiksmų galimybes: agentai stebi ekraną, daro išvadas apie aplinkos būseną ir nusprendžia, ką daryti toliau, be specialios integracijos su sistema, kurią jie valdo.
Techniškai tai reiškia modelio mokymą su dideli žaidimų ar sąveikos vaizdo įrašų korpusai kad jie išmoktų susieti tai, ką mato, su veiksmais, kuriuos atliktų ekspertas. Jie dirba su laiko sekomis, judesių diskretizavimu, ilgalaikiais tikslais ir optimizavimu, atsižvelgdami į daugybę apribojimų, tokių kaip delsa ar stabilumas.
Nors labiausiai matomas pavyzdys yra žaidimų kūrimas, šis vizijos ir veiksmų metodas turi milžinišką potencialą versle: jis leidžia kurti agentai, veikiantys grafinėse sąsajose įprasti, sudėtingų programų naršymas, pasikartojančių srautų vykdymas, procesų patvirtinimas arba kompleksinių testų atlikimas be specialių API.
Tai yra natūrali tradicinės RPA evoliucija link... Išmanesnė, labiau kontekstinė automatizacijaTipiniai naudojimo atvejai apima automatizuotą programinės įrangos testavimą, kuris imituoja realų vartotojo elgesį, valdomą pagalbą, kuri spustelėjimu atkartoja tai, ką darbuotojas turėtų daryti, sintetinių duomenų generavimą kokybės užtikrinimui arba „skaitmeninius dvynius“, kurie atkartoja žmogaus veiklą įmonės sistemose.
Kad visa tai būtų įgyvendinama, tvirta kibernetinio saugumo, valdymo ir stebimumo sistemaAgentai, sąveikaujantys su kritinėmis sąsajomis ir sistemomis, privalo laikytis prieigos politikos, vengti pavojingų veiksmų, registruoti kiekvieną žingsnį audito tikslais ir veikti aiškiai apibrėžtose ribose. Stebimumas čia veikia ir kaip „juodoji dėžė“, ir kaip „įrankių dėžė“: jis įrašo agento veiksmus ir teikia duomenis jo elgesiui kalibruoti ir tobulinti.
Saugumas, valdymas ir nulinis pasitikėjimas dirbtinio intelekto agentų eroje
Agentinio dirbtinio intelekto ir autonominių sistemų plėtra atneša Naujos rizikos, kurias reikia valdyti atsargiaiVienas iš labiausiai aptariamų yra vadinamasis „šešėlinis dirbtinis intelektas“: agentai, modeliai ar integracijos, kurie paleidžiami ne oficialiais organizacijos kanalais, be tinkamos saugumo ar atitikties reguliavimo kontrolei.
Taip pat kyla pavojus, dvigubi agentai arba kenkėjiški agentaiTai gali įvykti dėl tyčinių priežasčių (išorinės atakos, manipuliavimas, instrukcijų įterpimas) arba dėl konfigūracijos klaidų, kurios leidžia geranoriškai sistemai atlikti netyčinius veiksmus. Siekiant sumažinti šią riziką, svarbu taikyti principus Nulinis pasitikėjimas, ypač susijęs su dirbtiniu intelektu.
Nulinis pasitikėjimas šiame kontekste reiškia, kad Joks dirbtinio intelekto agentas ar komponentas pagal nutylėjimą nėra laikomas „patikimu“.Kiekvienas veiksmas turi būti aiškiai autorizuotas, leidimai turi būti apriboti iki būtino minimumo (mažiausių privilegijų principas), o visa sąveika turi būti registruojama vėlesniam auditui. Taigi stebimumas tampa pagrindiniu dirbtinio intelekto valdymo elementu.
Geras stebimumas leidžia realiuoju laiku stebėti agentų veiksmus, aptikti anomalų elgesį, patvirtinti prieigos politikas ir gauti išsamius įrodymus incidentų atveju. Tokios priemonės kaip leidžiamų veiksmų sąrašai, žmonių atliekamos kritinių ciklų peržiūros, jautrių duomenų valymas ir skaičiavimo vietos (vietinės, viešosios debesijos, nepriklausomos debesijos) kontrolė yra esminiai patikimo kontrolinio sąrašo elementai. efektyvus dirbtinio intelekto valdymas.
Šioje situacijoje labai svarbu rasti, inovacijų ir kontrolės pusiausvyraOrganizacijos nori visapusiškai išnaudoti agentinio dirbtinio intelekto potencialą, kad padidintų produktyvumą ir konkurencingumą, tačiau neaukodamos saugumo, atitikties reglamentams ar skaidrumo automatizuotame sprendimų priėmime.
Duomenys, infrastruktūra ir dirbtinis intelektas kaip verslo pamatinis sluoksnis
Žvelgiant į platesnį vaizdą, dirbtinis intelektas iš papildomo įrankio tampa vis svarbesniu. struktūrinis sluoksnis, kuriuo grindžiamas ekonominis konkurencingumasViskas sukasi apie tą transformaciją: duomenų strategijos, debesų architektūra, techninės įrangos projektavimas, darbo jėgos modeliai ir net nacionalinė skaitmeninės infrastruktūros politika.
Viena vertus, Duomenys konsoliduojami kaip pagrindinis konkurencinis diferenciatoriusSkaičiavimui ir modeliavimui tampant vis labiau komercializuotu dalyku, esminis skirtumas yra nuosavi aukštos kokybės, gerai valdomi duomenys. Stebimumas, fiksuojant išsamius ir kontekstinius telemetrijos duomenis, tampa vienu vertingiausių duomenų šaltinių. dirbtinio intelekto sistemos ir tobulinti procesus.
Kita vertus, Dirbtinio intelekto infrastruktūra pradedama laikyti strateginiu nacionaliniu turtuSuverenių debesų kompiuterijos iškilimas reaguoja į poreikį kontroliuoti, kur saugomi ir tvarkomi jautrūs duomenys, kaip apmokomi modeliai ir pagal kokias reguliavimo sistemas jie veikia. Šalys investuoja į duomenų centrus, optimizuotus dirbtinio intelekto darbo krūviams, efektyviai naudojančius energiją ir atitinkančius atitikties reikalavimus.
Visa tai sutampa su spartesnis duomenų centrų modernizavimasDėl dirbtinio intelekto darbo krūvių ir agentų sistemų energijos ir aušinimo poreikių energijos vartojimo efektyvumas nebėra tik eksploatavimo problema, bet tapo inovacijų ribojančiu veiksniu ir aplinkosaugos atitikties reikalavimu.
Tuo pačiu metu įmonės yra priverstos perkvalifikuoti savo darbuotojusTikslas nėra paversti visus programuotojais, o apmokyti specialistus, gebančius valdyti ir išnaudoti šias autonomines sistemas: dirbtinio intelekto valdomus verslo ekspertus, inžinierius, galinčius operacinius poreikius paversti stebimumo ir saugumo politika, ir hibridinius vaidmenis, kurie supranta tiek techninį, tiek ekonominį sprendimų poveikį.
Apibendrinus šią evoliuciją, susidaro scenarijus, kuriame atviresnis ir autonomiškesnis stebimumas Tai tampa klijais, jungiančiais technologijas, verslą ir reguliavimą: tokie standartai kaip „OpenTelemetry“ garantuoja duomenų perkeliamumą ir kokybę, dirbtinis intelektas ir agentų stebimumas sumažina operacijų sudėtingumą ir pagreitina reagavimą į incidentus, o valdymo ir nulinio pasitikėjimo praktika užtikrina, kad visa tai vyktų kontroliuojamai, saugiai ir su realiu audituojamumu.
Organizacijos, kurios sugebės suderinti šį derinį – standartizuotą telemetriją, vieningas platformas, dėmesį verslo rezultatams ir dirbtinio intelekto agentus, valdomus geru stebimumu, – bus geriausiai pasirengusios konkuruoti aplinkoje, kurioje skaitmeninės sistemos tampa vis svarbesnės, sudėtingesnės ir autonomiškesnės, tačiau kartu ir labiau geba generuoti apčiuopiamą vertę, kai yra valdomos tinkamai matomos.
