Mākslīgais intelekts IT operācijās uzņēmumā

Pirmdienas rītā viens nepieejams biznesa sistēmas pakalpojums var apturēt pārdošanu, noliktavas darbu vai klientu apkalpošanu. IT komandai tad jāsaprot, vai cēlonis ir tīkla savienojums, mākoņpakalpojuma kļūme, neizdevies atjauninājums, piekļuves problēma vai drošības incidents. Mākslīgais intelekts IT operācijās var šo izmeklēšanu būtiski paātrināt, taču tikai tad, ja tas tiek izmantots kā pārvaldīts darba instruments, nevis kā nekontrolēts automatizācijas eksperiments.

Mazām un vidējām organizācijām jautājums nav par to, vai iegādāties vēl vienu modernu rīku. Jautājums ir, kur MI reāli samazina dīkstāves, uzlabo pārskatāmību un palīdz IT vadībai pieņemt labākus lēmumus ar pieejamo budžetu. Vērtīgākie risinājumi parasti sākas ar konkrētu operacionālu problēmu, nevis ar plašu solījumu automatizēt visu infrastruktūru.

Kur mākslīgais intelekts IT operācijās rada praktisku vērtību

IT operācijas rada lielu datu apjomu: sistēmu žurnālus, veiktspējas rādītājus, paziņojumus par kļūdām, lietotāju pieteikumus, rezerves kopiju rezultātus un drošības notikumus. Cilvēks spēj novērtēt būtiskāko, bet savstarpēji saistītu signālu atrašana vairākās sistēmās prasa laiku. Tieši šeit MI spēj analizēt modeļus un izcelt novirzes ātrāk par manuālu pārbaudi.

Viens no biežākajiem lietojumiem ir anomāliju atklāšana. Piemēram, sistēma var pamanīt, ka servera atmiņas patēriņš noteiktā laikā aug ātrāk nekā ierasts, pieaug neveiksmīgu autorizācijas mēģinājumu skaits vai rezerves kopijas aizņem neparasti ilgu laiku. Šāds signāls vēl nav diagnoze. Tas ir savlaicīgs pamats pārbaudei, pirms problēma kļūst par uzņēmuma dīkstāvi.

MI var arī palīdzēt incidentu prioritizācijā. Ja vienlaikus ienāk desmitiem brīdinājumu, svarīgi nošķirt vienu pamatcēloni no tā radītajām sekām. Piemēram, nepilnība tīkla iekārtā var izraisīt kļūdas vairākās biznesa lietojumprogrammās. Labi konfigurēta analītika palīdz apvienot saistītus notikumus vienā incidentā, lai IT speciālists nepatērētu laiku identisku simptomu apstrādei.

Vēl viena joma ir servisa pieteikumu apstrāde. MI var klasificēt pieprasījumus, piedāvāt atbildes uz biežiem jautājumiem un sagatavot sākotnēju informāciju tehniskajai komandai. Tas ir lietderīgi, ja tiek saglabāts skaidrs eskalācijas ceļš. Darbiniekam jāspēj ātri nonākt pie kompetenta speciālista, īpaši piekļuves, finanšu sistēmu, vadības datu vai drošības jautājumos.

MI nav aizstājējs IT pārvaldībai

Lielākais risks nav tas, ka MI kļūdīsies. Kļūdas ir iespējamas jebkurā tehnoloģijā. Lielāks risks ir piešķirt sistēmai pārāk plašas tiesības vai uzticēties tās secinājumam, nepārbaudot kontekstu.

Piemēram, automatizēta darbība var restartēt pakalpojumu, bloķēt lietotāja kontu vai mainīt konfigurāciju, lai novērstu iespējamu incidentu. Dažos gadījumos tas ir pamatoti un nepieciešami. Citā situācijā šāda rīcība var pārtraukt kritisku integrāciju, aizkavēt rēķinu apstrādi vai liegt piekļuvi cilvēkam, kurš pilda steidzamu darba uzdevumu.

Tādēļ automatizācijas pakāpei jāatbilst riska līmenim. Zema riska darbības, piemēram, pieteikuma maršrutēšana, žurnālu apkopošana vai brīdinājuma papildināšana ar tehnisko informāciju, var būt lielā mērā automatizētas. Darbībām, kas ietekmē produkciju, datus, lietotāju tiesības vai drošības kontroli, parasti nepieciešams cilvēka apstiprinājums un auditējams lēmuma pamatojums.

Arī MI radīts teksts nav pierādījums. Ja rīks apkopo incidentu vai iesaka iespējamu cēloni, IT speciālistam ir jāpārbauda avota dati, izmaiņu vēsture un biznesa ietekme. Vadībai jāpieprasa nevis pārliecinoši formulēts skaidrojums, bet pārbaudāma informācija: kas notika, kāds ir apstiprinātais cēlonis, ko tas ietekmēja un kā tiek novērsta atkārtošanās.

Sāciet ar procesiem, nevis ar platformu

Pirms izvēlēties MI risinājumu, uzņēmumam ir jāzina, kā pašlaik tiek vadītas IT operācijas. Ja nav skaidrs, kur atrodas kritiskās sistēmas, kam pieder piekļuves, kā tiek pārbaudītas rezerves kopijas un kur reģistrētas infrastruktūras izmaiņas, MI tikai ātrāk apstrādās nekārtīgus datus.

Praktiskam sākumam ir vajadzīgas četras pamatlietas:

• aktuāls kritisko sistēmu, datu un atbildīgo personu saraksts;
• centralizēta uzraudzība un žurnālu vākšana no svarīgākajām platformām;
• incidentu klasifikācija pēc biznesa ietekmes, ne tikai tehniskas steidzamības;
• izmaiņu, piekļuves un automatizētu darbību dokumentēšana.

Šī bāze palīdz izvēlēties mērķi, kuru var izmērīt. Tā var būt vidējā incidenta novēršanas laika samazināšana, neizdevušos rezerves kopiju ātrāka atklāšana, mazāks atkārtotu pieteikumu skaits vai precīzāka aizdomīgu piekļuves mēģinājumu atlase. Ja rezultātu nevar izmērīt, būs grūti pamatot gan ieguldījumu, gan turpmāko risinājuma uzturēšanu.

Datu aizsardzība un Eiropas prasības

IT operāciju datos bieži atrodama sensitīva informācija. Žurnālos var būt lietotāju vārdi, e-pasta adreses, ierīču nosaukumi, IP adreses, failu ceļi, klientu dati vai tehniskas konfigurācijas detaļas. Šo informāciju nedrīkst bez izvērtējuma ievadīt publiski pieejamos MI rīkos.

Pirms ieviešanas jānosaka, kur dati tiek apstrādāti, vai tie tiek izmantoti modeļa apmācībai, cik ilgi tie tiek glabāti un kādas ir piegādātāja līgumsaistības. Jāizvērtē personas datu aizsardzības prasības, datu glabāšanas reģions, piegādes ķēdes risks un piekļuves kontrole. Organizācijām, kas strādā regulētās nozarēs vai ar sensitīvu klientu informāciju, šis izvērtējums nav formalitāte - tas ir daļa no drošības un atbilstības pārvaldības.

Svarīga ir arī piekļuves tiesību disciplīna. MI rīkam nevajadzētu piešķirt administratīvas tiesības visā vidē tikai tādēļ, lai tas varētu sniegt plašākus ieteikumus. Piekļuves jāveido pēc mazāko nepieciešamo tiesību principa, jāizmanto atsevišķi servisa konti un regulāri jāpārskata, ko automatizācija patiesībā spēj nolasīt vai mainīt.

Kā izvērtēt ieguldījuma atdevi

MI IT operācijās rada vērtību tad, ja tas uzlabo konkrētu pakalpojuma rezultātu. Vienkāršs piemērs ir nakts brīdinājumi. Ja uzraudzības sistēma regulāri rada simtiem nebūtisku paziņojumu, tehniskā komanda zaudē uzmanību un var palaist garām nopietnu incidentu. MI balstīta korelācija var samazināt trokšņa līmeni, bet tās kvalitāte ir jāvērtē ilgākā periodā.

Vērtēšanā ir lietderīgi salīdzināt situāciju pirms un pēc ieviešanas: cik incidentu tika atklāti laikus, cik nepatiesu trauksmju bija jāizskata, cik ātri tika atjaunots pakalpojums un cik daudz manuāla darba patērēja ikdienas apkalpošana. Jāņem vērā arī izmaksas par licencēm, integrāciju, datu glabāšanu, ekspertu darbu un regulāru konfigurācijas pārskatīšanu.

Ne visiem uzņēmumiem vajadzīga pilna AIOps platforma. Organizācijai ar salīdzinoši vienkāršu infrastruktūru lielāku efektu var dot sakārtota monitorēšana, pārbaudītas rezerves kopijas un skaidrs incidentu process. Savukārt uzņēmumam ar vairākām mākoņvidēm, attālinātām darba vietām un kritiskām integrācijām MI analītika var kļūt par nozīmīgu instrumentu pārskatāmības uzturēšanai.

Atbildība paliek uzņēmuma pusē

Tehnoloģiju piegādātājs var nodrošināt rīku, taču atbildību par biznesa risku nevar nodot algoritmam. Vadībai jānosaka, kuri procesi ir kritiski, kāda dīkstāve ir pieņemama, kas apstiprina automatizētas izmaiņas un kā tiek rīkots drošības incidents. Šie lēmumi savieno IT darbību ar uzņēmuma nepārtrauktību.

Labs ieviešanas modelis sākas ar ierobežotu pilotprojektu vienā skaidrā lietojuma gadījumā. Pēc tam tiek pārbaudīta datu kvalitāte, ieteikumu precizitāte, drošības ietekme un reālais darba laika ietaupījums. Tikai tad ir pamatoti paplašināt automatizāciju uz citām sistēmām.

Pareizi pārvaldīts MI nenovērš vajadzību pēc pieredzējušiem IT speciālistiem un stratēģiskas uzraudzības. Tas dod viņiem vairāk laika darbam, kas tieši aizsargā uzņēmumu: risku novēršanai, infrastruktūras plānošanai, atkopšanas gatavībai un izmaiņām, kas atbalsta biznesa izaugsmi. Sāciet ar vienu procesu, kura rezultātu var pierādīt, un veidojiet uzticību tehnoloģijai pakāpeniski - ar kontroli, skaidru atbildību un izmērāmu ieguvumu.