Koji kvarovi povlače druge: kako pronaći skrivene veze u toku incidenata
U prodavnici je nestao komunikacioni kanal. Pet minuta kasnije u Service Desk upadaju još tri prijave: otkazale su kase, gostinski Wi-Fi i plaćanje karticom. Verovatan je scenario u kom tri različite IT grupe paralelno pokušavaju da poprave tri „različita“ kvara.
Na kraju meseca rukovodilac u izveštaju vidi rast incidenata i pad SLA za tri servisa, iako je koren problema bio jedan. Iz ravnog dnevnika prijava nemoguće je razumeti gde je prvobitni uzrok, a gde posledica. Dok su te veze skrivene, kompanija suvišno troši inženjerske resurse na uklanjanje simptoma, a u izveštajima se jedna havarija računa kao nekoliko nezavisnih.
Zadatak algoritma
Metod automatskog traženja veza analizira sirove izvoze iz Service Desk sistema i odgovara na tri pitanja:
- Koji kvar je okidač? Posle otkaza kog sistema se lavinski otvaraju prijave za druge servise.
- Da li je to obrazac ili poklapanje? Koliko puta se sličan scenario ponovio u praksi i koliko bi takvih poklapanja dala obična slučajnost.
- Koliko se stvarnih havarija desilo? Koji udeo prijava je samo „eho“ havarije koja je već u toku ili duplikati koje treba spojiti u jedan incident.
Kako metod radi
Metod spada u algoritme za traženje asocijativnih veza i prilagođen je specifičnostima incidenata.
- 1. Prozor posmatranja (15 minuta)
Posle pojave bilo koje prijave algoritam prati vremenski prozor od 15 minuta: da li su se za to vreme otvorile prijave za druge sisteme.
- 2. Filtriranje slučajnih poklapanja i šuma
Najčešća greška analitike je da se dnevna aktivnost proglasi vezom. Ako se dva kancelarijska sistema češće kvare danju, to još ne znači da jedan obara drugi.
Uračunavanje osnovnog ritma: algoritam poredi poklapanja sa uobičajenim opterećenjem drugog sistema u tim nedeljama, u taj dan u nedelji i sat.
Isključivanje „dana-oluje“: dani kada je istovremeno palo sve (na primer, ostao bez struje data centar) isključuju se iz pretrage. U oluji se sve poklapa sa svim, što stvara lažne veze.
Provera postojanosti: veza se priznaje kao stvarna samo ako se ponovila u najmanje 4 različita dana i ostaje kad se uklone dva najvršnija dana.
- 3. Određivanje smera: ko je glavni
Usmerena veza (A → B): ako sistem A skoro uvek otkaže prvi, beleži se kao prvobitni uzrok.
Veza „bez prvog“ (A ↔ B): ako je prvi čas jedan, čas drugi sistem, algoritam ih označava kao žrtve zajedničkog uzroka (na primer, verovatnog kvara napajanja ili zajedničke infrastrukture).
- 4. Spajanje incidenata (deduplikacija)
Nastavak: prijava za povezan sistem u roku od 15 minuta računa se kao eho prvobitnog kvara, a ne kao novi nezavisan incident.
Duplikati: prijave za isti sistem sa razlikom od nekoliko minuta se spajaju.
Važno: statistička veza nije isto što i fizički uzrok: A možda ne kvari B direktno, već ih obara treći sistem C. Ali metod tačno pokazuje gde tražiti koren problema i smanjuje informacioni šum.
Šta algoritam vidi u stvarnim podacima i od čega je zaštićen
Sirovi dnevnici Service Desk-a gotovo nikad nisu savršeni: puni su ponovljenih oluja iz monitoringa, nejasnog vremena i ljudskog faktora. Evo kako metod obrađuje tipične scenarije:
| Šta se desilo | Šta je u dnevniku | Kako algoritam reaguje | Praktičan efekat |
|---|---|---|---|
| Lančana reakcija | Pao je komunikacioni kanal, za njim - kase, Wi-Fi i terminali za plaćanje | Pronalazi prvi sistem i gradi lanac posledica | Na listi najvećih incidenata havarija stoji jednom umesto četiri puta; „krivac“ se odmah vidi |
| Skriveni zajednički uzrok | Isključilo se napajanje; prve slučajno padaju čas kase, čas Wi-Fi | Beleži vezu „kvare se zajedno, bez jasnog prvog“ | Upućuje inženjere da traže infrastrukturni uzrok (napajanje, svič) |
| Dve posledice jednog kvara | Kase i Wi-Fi pali su zbog komunikacionog kanala | Ne povezuje kase i Wi-Fi direktno međusobno | Isključuje lažne hipoteze da softver kasa kvari Wi-Fi |
| Duplikati i „treperenje“ | Monitoring ili korisnici otvorili su nekoliko prijava za jedan kvar za 10 minuta | Spaja ponavljanja u jednu havariju i računa njihov udeo | Pokazuje koliko je prijava ponavljanje i za koliko je broj kvarova uvećan |
| Oluja (masovni kvar) | Zbog havarije u data centru ili kod velikog provajdera otkazuje sve odjednom | Isključuje takve dane iz traženja veza | Štiti od stotina bezvrednih veza „svega sa svim“ |
| Nizak kvalitet podataka | Nije naveden sistem ili je vreme zapisano sa tačnošću do sata | Ne traži veze i u izveštaju piše zašto | Štiti od nepouzdanih zaključaka kad se evidencija vodi nemarno |
Pouzdanost provere: radi stvaranja rezerve tačnosti, pored testova na stvarnim bazama, algoritam je testiran na stotinama veštački generisanih dnevnika bez stvarnih veza - do 30 sistema i 5 500 prijava godišnje, uključujući i dane masovnih kvarova. Lažna veza je pronađena samo u jednoj godini od 200.
Šta raditi ako je algoritam našao vezu
Kada model pokaže redovnu vezu između kvarova, inženjeri dobijaju gotov obrazac za rad. Tabela pokazuje kako tumačiti pronađene kombinacije:
| Scenario | Verovatan uzrok | Kako proveriti hipotezu | Šta raditi |
|---|---|---|---|
| Sistem A pada prvi, za njim B, V i G | Zavisnost arhitekture: B, V i G ne mogu da rade bez A | Da li se objekti (prodavnica, čvorni orman, filijala) para prijava poklapaju | Prioritet rezervisanja: ulaganje u pouzdanost jednog sistema A uklanja kvarove na tri druga |
| Sistemi A i B padaju zajedno nasumičnim redom | Zajednički infrastrukturni uzrok (napajanje, zajednički svič, data centar) | Pronaći zajednički hardverski ili logički čvor za objekte iz dve prijave | Traženje jedinstvene tačke otkaza (SPOF): rezervisati ne same sisteme, već čvor koji im je zajednički |
| Sistem A pada sam za sobom nekoliko puta zaredom | „Treperenje“ monitoringa ili dupliranje tiketa od strane korisnika | Izvori prijava (robot ili čovek) i poklapanje tekstova | Manje zamora od upozorenja (Alert Fatigue): suzbijanje ponovljenih alarma štiti inženjere od sagorevanja |
| Različiti timovi paralelno preuzimaju isti problem | Organizaciona razjedinjenost: svaki sektor vidi samo svoj simptom | Uporediti vreme registracije i objekte kod tiketa različitih timova | Jedinstven centar upravljanja: tiketi-posledice vezuju se za glavni, otklanjanje se vodi iz jedne tačke |
Primer. Komunikacioni kanal i tri reda prijava
Polazni podaci: trgovinski lanac, 12 IT sistema, oko 1 100 prijava godišnje. Kada se prekine internet kanal u prodavnici, prva linija podrške dobija tikete za kase, Wi-Fi i terminale za plaćanje. Svaki tiket ide u svoju servisnu grupu.
Šta je algoritam pronašao: u roku od 15 minuta posle kvara „Komunikacionih kanala“ otvarale su se prijave za kase - 10 puta od 106 (slučajno bi se poklopilo oko 0.8 puta), za Wi-Fi - 9 puta (oko 0.4), za platni gejtvej - 8 puta (oko 0.2). 56 prijava od 1 116 godišnje je direktan nastavak havarija koje su već u toku.
Šta to daje:
- Ušteda IT resursa. Umesto tri paralelne istrage određuje se jedan odgovoran za komunikacioni kanal. Sati uskih stručnjaka ne troše se na simptome.
- Providni KPI i SLA. Vidi se da je broj incidenata u izveštajima uvećan oko 5% samo zbog eha i ponavljanja. Izveštavanje prema rukovodstvu postaje pošteno.
- Obrazloženje isplativosti (ROI) za rukovodstvo. Budžet za drugi, rezervni komunikacioni kanal lakše je obrazložiti: „zaštita jednog kanala odmah uklanja tri kategorije kvarova na kasama i plaćanju“.
Traka - koliko puta se posle kvara kanala u roku od 15 minuta otvorila prijava za drugi sistem; siva oznaka - koliko bi dala slučajnost.
Kako primeniti rezultate u radu
Pronađene zavisnosti preuređuju rad IT sektora na tri nivoa - od svakodnevne obrade tiketa do strateških odluka.
- Procesi (Incident Management)Princip „jedna havarija - jedan glavni tiket“: tiketi-posledice otvoreni u prozoru od 15 minuta vezuju se za roditeljski tiket (Parent-Child). Rezultat: jedno obaveštenje za biznis, jedan dežurni inženjer i nikakve zabune kada različiti timovi paralelno rade isti posao.
- Arhitektura i budžet (Problem Management)Sistem-„okidač“ koji za sobom povlači kaskadu kvarova glavni je kandidat za rezervisanje i modernizaciju. Rezultat: razumljiva isplativost IT projekata. Jačanje jedne kritične tačke skida sloj sekundarnih prijava i opterećenje druge i treće linije podrške.
- Upravljanje i KPI (Executive Reporting)Rukovodstvo vidi koji deo prijava su duplikati i „eho“ havarija, i stvarnu sliku dostupnosti servisa. Rezultat: odluke o nabavkama i rezervisanju donose se po činjenicama, a ne po naduvanom broju prijava.
Glavni zaključak
Traženje veza između kvarova pretvara dnevnik Service Desk-a iz pasivnog „groblja tiketa“ u alat za tačkastu optimizaciju IT infrastrukture. Prestajete da trošite resurse na uklanjanje simptoma i dobijate mapu skrivenih zavisnosti svojih sistema.