Ako sme implementovali AI projekt, ktorý skončil bez AI

AI projekt, ktorý mal byť jednoduchý

Pred niekoľkými rokmi sme pracovali na projekte, ktorý mal byť ukážkovým príkladom nasadenia umelej inteligencie v enterprise prostredí. Cieľ bol pomerne jasný. Zmigrovať zákazníka zo starého prostredia na konverzačnú AIOps platformu pre správu sieťovej infraštruktúry veľkej nadnárodnej organizácie. AI mala pomôcť operátorom v network operations centre riešiť incidenty rýchlejšie, znížiť počet manuálnych zásahov a postupne automatizovať časť operácií, ktoré sa denne opakovali.

Na prvý pohľad to nebol ničím výnimočný use-case. Práve naopak. Presne takto dnes začína veľká časť diskusií o AI v enterprise prostredí. Existuje problém, existuje komplexita, existuje tlak na efektivitu a AI sa javí ako prirodzené riešenie.

Lenže prostredie, do ktorého sme mali AI nasadiť, nebolo jednoduché. Išlo o nadnárodnú korporáciu, ktorá spravovala kritickú infraštruktúru rozloženú po celom svete. Infraštruktúra bola tvorená desiatkami dátových centier, tisíckami sieťových prvkov a širokým spektrom koncových zariadení. Technologický mix bol extrémne rôznorodý. Od viac ako 30 rokov starých „legacy“ zariadení, ktoré stále plnili svoju funkciu, až po najnovšie “next gen” generácie network a security zariadenia.

Táto kombinácia sama o sebe vytvárala komplexitu, ktorú nie je možné riešiť jedným nástrojom. Rôzne generácie a typy zariadení znamenali rôzne protokoly, rôzne možnosti monitoringu, rôzne limity a rôzne typy problémov. To, čo fungovalo pre modernú infraštruktúru, nefungovalo pre staršie časti systému. To, čo bolo možné automatizovať na jednom mieste, nebolo možné aplikovať inde.

Do toho vstupoval globálny operations model. Network operations centre nebolo jedno, ale rozdelené medzi viaceré regióny. Tímy pracovali v rôznych časových pásmach, mali rôzne úrovne skúseností a často aj odlišné pracovné postupy. Niektoré časti infraštruktúry boli riadené centrálne, iné lokálne.

Ak si to predstavíte ako celok, nejde o jeden systém, ale skôr ekosystém, ktorý sa vyvíjal roky a často organicky.

A práve do takéhoto prostredia sme mali nasadiť AI orchestration. Očakávania boli preto prirodzene vysoké. AI mala priniesť poriadok do komplexity. Mala pomôcť operátorom orientovať sa v množstve dát, rýchlejšie identifikovať problémy a znížiť závislosť na manuálnych zásahoch. Mala byť vrstvou, ktorá „zjednoduší“ realitu.

Migrácia ako moment pravdy

Na papieri to dávalo perfektný zmysel. Lenže veľmi rýchlo sa ukázalo, že migrácia nebude taká jednoduchá.

Pôvodne to malo byť „len“ technologické zlepšenie a prechod na modernejší nástroj, ktorý by dokázal lepšie orchestrovať dáta a procesy a zároveň podporiť automatizáciu.

V praxi sa však ukázalo, že takáto migrácia nie je len o presune systémov. Je to moment, kedy sa odkryje reálny stav celého prostredia. Všetko, čo bolo dlhodobo „nejako nastavené“, sa zrazu musí pomenovať, pochopiť a rozhodnúť, či to má zmysel preniesť aj do nového sveta.

Práve tento moment nám dal príležitosť začať riešiť problém komplexne. Namiesto toho, aby sme len preniesli existujúci stav do novej platformy, sme sa rozhodli ho najprv pochopiť a upratať.

A v tom momente sa celý projekt začal meniť.

Realita operations: keď systém prestane stíhať

Keď sme sa začali pozerať na realitu operations, veľmi rýchlo sa ukázalo, prečo firma vôbec začala uvažovať o AI. Nie preto, že by chcela experimentovať s novou technológiou, ale preto, že sa dlhodobo pohybovala v prostredí, kde sa postupne nahromadila komplexita, ktorú už nebolo možné efektívne zvládať tradičnými spôsobmi.

Typický obraz vyzeral asi takto. Prostredie s desiatkami tisíc zariadení generovalo kontinuálny tok dát, ktorý monitoring systémy spracovávali v reálnom čase. Alerty vznikali prakticky nepretržite. V niektorých častiach infraštruktúry išlo o desiatky až stovky eventov denne, pričom len časť z nich mala skutočný dopad na prevádzku. Operátori boli vystavení permanentnému „šumu“, v ktorom bolo čoraz náročnejšie rozlíšiť, čo je reálny problém a čo je len vedľajší efekt konfigurácie systému.

Výsledkom bolo, že incidenty nevznikali len na základe reálnych výpadkov, ale aj na základe nepresne nastavených thresholdov alebo duplicitných monitoring pravidiel. Jeden alert spustil ďalšie tri, tie ďalších päť. V niektorých prípadoch sme vedeli identifikovať situácie, kde jeden reálny problém generoval celý reťazec incidentov naprieč rôznymi systémami. Incidenty tak vznikali z rovnakých príčin, ale neboli rozpoznané ako súvisiace. Každý z nich sa riešil samostatne.

Do toho vstupovala organizácia práce. Rôzne tímy mali rôzne zodpovednosti. Niektoré sa venovali monitoringu a L1 supportu, iné incidentom, ďalšie problémom alebo release managementu. V praxi to znamenalo, že ten istý problém mohol byť riešený paralelne na viacerých úrovniach. Každý tím pracoval správne vo svojom kontexte, ale bez jednotného pohľadu na celý systém.

V jednom momente po migrácii sme stáli pred backlogom, ktorý obsahoval desiatky až stovky ticketov. Ešte výraznejší bol pohľad na historické dáta kde sme mali viac ako 1700 orphaned ticketov, ktoré bolo potrebné manuálne vyčistiť v priebehu jedného mesiaca. To nie je situácia, ktorú vyriešite tým, že pridáte jedného človeka navyše. To je situácia, kde systém generuje prácu rýchlejšie, než ju dokáže tím spracovať.

Zaujímavé bolo, že keď sme sa pozreli detailnejšie na štruktúru incidentov, veľká časť z nich nebola spôsobená novými problémami. Opakovali sa rovnaké scenáre, rovnaké typy výpadkov, rovnaké reakcie systému. Rozdiel bol len v tom, že sa objavovali v rôznych formách a bez vzájomného prepojenia.

A tu prichádza zásadný moment.

Problém nebol nedostatok ľudí. Problém bol chaos v dátach a procesoch.

Keď sa povie „AI pre operations“, väčšina ľudí si predstaví systém, ktorý bude automaticky triediť incidenty, identifikovať príčiny a možno aj navrhovať riešenia. Technologicky to dnes nie je sci-fi. Problém je skôr v tom, že takýto systém potrebuje kvalitný a konzistentný vstup (data), na ktorom môže stavať.

Preto bol naším prvým krokom audit dát.

Audit dát: čo systém naozaj robí

Pozreli sme sa na to, čo systém monitoruje, aké eventy vznikajú a ako sa z nich stávajú incidenty. Rozobrali sme monitoring konfiguráciu do detailu ako napr. Thresholdy zariadení, monitoring rules, polling intervaly. Snažili sme sa pochopiť, prečo systém reaguje tak, ako reaguje, a čo presne jednotlivé alerty znamenajú v kontexte reálnej prevádzky. Zároveň sme sa pozreli na štruktúru infraštruktúry. Ako sú zariadenia zoskupené, aké typy zariadení existujú a či majú jednotnú logiku. Veľká časť konfigurácie vznikala postupne, bez centrálneho návrhu, čo znamenalo, že rovnaké typy zariadení boli monitorované rôznymi spôsobmi.

Kľúčová bola aj analýza samotnej pipeline teda ako sa event mení na alert a ako sa z alertu stáva incident. Práve tu sa ukázalo, kde vzniká najväčší rozdiel medzi tým, čo sa deje v infraštruktúre, a tým, čo vidí operátor.

To, čo sme zistili, bolo pomerne jednoznačné. Veľká časť eventov nemala reálnu prevádzkovú hodnotu. Thresholdy boli nastavené historicky a často nereflektovali aktuálny stav infraštruktúry. Zariadenia boli monitorované bez logickej kategorizácie, takže systém reagoval rovnako na kritické aj menej dôležité komponenty. Výsledkom bolo, že množstvo incidentov nevznikalo preto, že by sa niečo nové pokazilo, ale preto, že systém nedokázal správne interpretovať existujúce signály.

V praxi to znamenalo, že jeden problém sa v dátach objavil viackrát, v rôznych formách a bez jasného prepojenia. Incidenty tak nevznikali ako reprezentácia reality, ale ako produkt konfigurácie systému.

A práve to bol moment, kde bolo jasné, že bez úpravy monitoringu nemá zmysel pokračovať ďalej. Preto sme pokračovali ďalším krokom.

Upratali sme monitoring.

Optimalizácia monitoringu nebola jednorazový krok, ale séria konkrétnych zásahov, ktoré postupne menili správanie celého systému.

Začali sme thresholdmi. V mnohých prípadoch boli nastavené historicky konzervatívne, bez ohľadu na reálne správanie zariadení. To viedlo k tomu, že systém generoval alerty aj v situáciách, ktoré nepredstavovali reálny problém. Napríklad krátkodobé výkyvy výkonu alebo prechodné latencie, ktoré sa prirodzene stabilizovali bez zásahu.

Úpravou thresholdov sme odstránili veľké množstvo tzv. „noise“ alertov. Cieľ nebol znížiť počet alertov za každú cenu, ale zabezpečiť, aby každý alert niesol informáciu, ktorá vyžaduje reakciu.

Paralelne sme sa pozreli na monitoring rules. Rôzne časti infraštruktúry mali definované pravidlá rôznymi spôsobmi, často bez jednotnej logiky. Rovnaký typ zariadenia bol monitorovaný inak v rôznych častiach siete. To viedlo k nekonzistentným dátam a komplikovalo interpretáciu. Zjednotením monitoring rules sme dosiahli, že podobné situácie boli zachytávané rovnakým spôsobom. To je zásadný predpoklad pre akúkoľvek ďalšiu analýzu alebo automatizáciu.

Ďalší krok, ktorý nevyhnutne nasledoval bola kategorizácia. Zariadenia sa začali logicky zoskupovať podľa funkcie a kritickosti ako napr. core network, edge zariadenia, firewall infraštruktúra. Táto kategorizácia umožnila nastaviť rôzne pravidlá pre rôzne vrstvy, namiesto jedného univerzálneho prístupu.

Veľký rozdiel priniesla korelácia eventov. Pred úpravou systém reagoval na každý signál samostatne. Po zavedení korelácie sa začali súvisiace udalosti spájať. To znamenalo, že viacero alertov, ktoré mali spoločnú príčinu, sa prestalo prejavovať ako samostatné incidenty.

Cieľ bol jednoduchý, ale zásadný: jeden problém = jeden incident.

Toto pravidlo sa stalo referenčným bodom pre všetky úpravy.

Dopad týchto zmien bol veľmi rýchly a zároveň veľmi merateľný. Počet eventov začal klesať prakticky okamžite po úpravách. Následne sa znížil počet incidentov a backlog, ktorý bol ešte nedávno problémom, sa začal rozpúšťať. V priebehu približne 1,5 mesiaca klesol backlog z 116 na 22, čo predstavuje viac ako 80 % zlepšenie. Paralelne sa podarilo vyčistiť viac ako 1700 orphaned ticketov, ktoré sa nahromadili v systéme.

Ešte dôležitejší bol však každodenný dopad na operations. Len vďaka optimalizácii a následnej automatizácii sa podarilo eliminovať približne 10 až 15 incidentov denne. To je objem práce, ktorý predtým museli operátori riešiť manuálne.

Zrazu bolo možné reálne pracovať s dátami. Zrazu dávali čísla zmysel.

A čo je dôležité, systém začal odrážať realitu infraštruktúry, nie len spôsob, akým bol nakonfigurovaný.

Keď sa upratali dáta, ukázalo sa, že druhá polovica problému sú procesy.

Procesy: keď organizácia brzdí sama seba

Na papieri existovalo všetko. Incident management, release management, availability management, backup management, capacity management, service request management. Každá oblasť mala svoje pravidlá, svoje KPI, svoje tímy.

Problém bol v tom, že fungovali oddelene.

Incident riešil jeden tím. Release iný. Monitoring mal vlastných ľudí. Informácie medzi nimi netiekli tak, ako by mali. Eskalácie boli časté a často aj zbytočné. Reakcie boli pomalšie, než by bolo potrebné, nie preto, že by ľudia nereagovali, ale preto, že systém nebol orchestrovaný.

Typický scenár vyzeral tak, že incident sa vyriešil, ale jeho príčina zostala. O pár dní sa objavil znova. A celý cyklus sa opakoval.

Z pohľadu dát to vyzeralo ako nový problém. Z pohľadu reality to bol stále ten istý.

Preto sme začali tieto oblasti prepájať.

Incident management sa prepojil s problem managementom. Začali sme systematicky identifikovať opakujúce sa problémy a vytvárať tzv. „known errors“. Namiesto riešenia jednotlivých incidentov sme sa zamerali na odstránenie ich príčiny.

Release management začal viac reflektovať realitu operations. Zmeny sa neplánovali izolovane, ale s ohľadom na historické dáta a známe problémy. Capacity a availability management sa posunuli z reaktívneho režimu do proaktívneho – problémy sa riešili skôr, než mali dopad na prevádzku.

Výsledky sa opäť dostavili pomerne rýchlo.

Reakcie sa zrýchlili. Eskalácie klesli. KPI sa začali stabilizovať a v niektorých oblastiach sa podarilo udržať cieľové hodnoty konzistentne niekoľko týždňov po sebe.

Najdôležitejšia zmena však bola v tom, že problémy sa prestali opakovať. Systém sa postupne prestával „točiť v kruhu“.

Až keď boli dáta aj procesy upratané, začalo dávať zmysel uvažovať o ďalšom kroku – automatizácii.

Automatizácia: efektivita bez AI

Dôležité je zdôrazniť, že automatizácia v tomto bode nebola experiment. Bola to logická nadstavba na stabilný systém, ktorý už dával zmysel. Mali sme dáta, mali sme procesy a to nám umožnilo začať sa sústrediť na konkrétne veci, ktoré mali okamžitý dopad na operations.

Opakujúce sa úlohy, ktoré operátori robili denne. Jednoduché incidenty, ktoré mali jasný a opakovateľný postup riešenia. Service requesty, ktoré sa dali štandardizovať bez potreby individuálneho rozhodovania.

V praxi to znamenalo napríklad automatizáciu základných diagnostických krokov, ktoré operátori robili manuálne pri každom incidente. Skripty vedeli overiť dostupnosť zariadenia, skontrolovať základné parametre, vyhodnotiť stav služby a pripraviť podklady pre ďalšie rozhodovanie. To, čo predtým trvalo niekoľko minút manuálnej práce, bolo zrazu otázkou sekúnd.

Vznikli orchestration workflows, ktoré prepájali jednotlivé kroky do jedného konzistentného procesu. Incident už neznamenal sériu manuálnych zásahov, ale riadený tok činností, kde systém vedel automaticky vykonať časť práce a operátor sa sústredil len na rozhodovanie tam, kde to malo zmysel.

Podobný prístup sa aplikoval aj na service requesty. Požiadavky, ktoré mali jasnú štruktúru a opakovateľný postup, sa začali riešiť automaticky alebo poloautomaticky. Tým sa výrazne znížila záťaž na tímy a zároveň sa zvýšila konzistentnosť výsledkov.

Zaujímavé bolo, že po zavedení automatizácie sa skrátil čas riešenia a znížil počet incidentov, ktoré si vyžadovali ďalšie zásahy. Systém vedel rýchlejšie identifikovať správny postup a pripraviť podklady pre operátora, čo viedlo k efektívnejšiemu riešeniu už v skorších fázach procesu. Efekt bol okamžitý a zároveň veľmi dobre merateľný.

Len vďaka automatizácii sa podarilo eliminovať približne 10 až 15 nových incidentov denne. To znamená desiatky percent kapacity tímu, ktorá sa uvoľnila bez toho, aby bolo potrebné zvyšovať počet ľudí.

Zároveň sa skrátil čas riešenia incidentov. Operátori už nemuseli opakovane vykonávať tie isté kroky, systém im poskytoval kontext a v mnohých prípadoch aj pripravené podklady pre rozhodnutie.

Automatizácia mala ešte jeden dôležitý efekt – stabilitu.

Procesy, ktoré boli predtým závislé od individuálneho prístupu konkrétneho operátora, sa stali konzistentnými. Každý incident rovnakého typu sa riešil rovnakým spôsobom. To sa okamžite prejavilo na kvalite služby aj na KPI.

Markantne sa aj zlepšila schopnosť reportovať, pretože systém konečne pracoval s dátami, ktoré mali reálnu výpovednú hodnotu. Výsledkom bolo, že systém bol prehľadný, auditovateľný, dalo sa naň spoľahnúť pri celkovom operatívnom rozhodovaní a nielen na úrovni riešenia incidentov.

Zaujímavým vedľajším efektom bolo aj to, že sa výrazne zlepšila pripravenosť infraštruktúry na ďalšie zmeny.

A stále sme nepoužili AI.

AI nemá byť začiatok, ale koniec príbehu

Na konci projektu sme mali úplne inú situáciu, než na začiatku.

Menej incidentov (o viac ako 50%). Menej eventov (viac ako 70%). Rýchlejšie riešenie requestov (viac ako 60%). Menej manuálnej práce. Stabilizované fungovanie. Lepší prehľad o tom, čo sa v infraštruktúre reálne deje.

Efektivita operations sa zlepšila v priemere približne o 50-60 %.

A najzaujímavejšia časť?

Konverzačnú AI sme nakoniec ani nenasadzovali. Nie preto, že by nebola užitočná. Ale preto, že väčšinu problémov, ktoré sme s jej pomocou chceli riešiť (a ktoré chcú takto riešiť mnohé organizácie cez rôzne formy “AgenticAI”) sme odstránili na základnej úrovni. Systematicky, komplexne a v konečnom dôsledku jednoduchšie.

Najväčší prínos AI orchestrácie vzniká ešte predtým, než AI vôbec zapojíte – uprataním dát, nastavením procesov a hlavne zadefinovaním problému, ktorý chcete riešiť.

AI projekty často začínajú otázkou: aký model použijeme?

Správna otázka je: máme vôbec pripravené dáta a procesy?

A práve preto sa v ďalšom článku pozrieme detailnejšie na to, prečo väčšina AI projektov zlyhá skôr, než začne – a prečo audit dát nie je technický detail, ale úplný základ.