Koji kvarovi se vraćaju u ciklusu: od intuicije do prognoze
„Opet je pala noćna razmena sa bazom. Čini se da je već bilo nešto slično, i pre toga isto...“ U IT podršci taj osećaj deža vija je čest. Ali dokazati obrazac „od oka“ skoro je nemoguće: između tih sličnih događaja u dnevniku leže stotine drugih, slučajnih prijava.
Zadatak
Ako analiza po satima traži čvrstu vezu sa rasporedom nedelje, analiza ciklusa je prediktivna analitika. Metod traži skriveni ritam incidenata koji se vraćaju u jednakim vremenskim razmacima ili su vezani za kalendar. Algoritam automatski skenira dnevnik i odgovara na tri pitanja:
- Koji kvar se vraća u ciklusu. Otkriva ranjiv sistem i njegov korak - na koliko dana ili tačno kojih dana u mesecu dolazi do kvara.
- Koliko to nije slučajno. Računa koliko puta se incident poklopio sa izračunatim ciklusom i poredi to sa uobičajenim pozadinskim ritmom sistema, isključujući slučajna poklapanja.
- Kada očekivati sledeću havariju. Računa datum najbližeg kvara po ciklusu po principu „ako se ništa ne menja“ - ili beleži da se lanac prekinuo i da je uzrok već uklonjen.
Kako algoritam traži cikluse
U osnovi metoda je ispitivanje hipoteza i stroga provera na slučajnost. Algoritam ne traži samo skokove, već otkriva matematički potvrđen ritam za svaki konkretan IT sistem. Kako to radi korak po korak:
- Izdvajanje sistema i noćnih kvarova. Dnevnik se deli po sistemima (na primer, 1C, sajt, obračun). Posebnu pažnju algoritam posvećuje noćnim kvarovima (od 00:00 do 07:00). Noću korisnici spavaju, pa je skok prijava u to vreme najverovatnije trag palog skripta ili zadatka.
- Ispitivanje koraka. Sistem proverava sve moguće intervale: na 2 dana, na 10 dana i tako dalje, obuhvatajući periode do četvrtine ukupne dužine dnevnika. Posebno se proverava vezanost za konkretne datume (na primer, „poslednja tri dana svakog meseca“).
- Isključivanje nedelja. Koraci od 7, 14 i 21 dan ovde se ne traže. Njih otkriva analiza po danima u nedelji i satima, da se isti incident ne bi duplirao u izveštajima.
- Zaštita od slučajnog šuma. Da bi postao „ciklus“, kvar mora upasti u ritam najmanje 4 puta i primetno premašiti uobičajenu pozadinu sistema. Algoritam poredi svaki sumnjiv dan sa normom. Vruća sezona ili jednokratan niz havarija neće postati ciklus. Prag odsecanja je visok: na slučajnim podacima sistem će jednostavno ćutati, bez lažnih alarma.
- Prognoza sledećeg datuma. Ako matematika potvrdi aktivan ciklus, algoritam navodi datum sledećeg očekivanog incidenta po principu „ako se ništa ne menja“.
- Kontrola ispravke. Ako u poslednja tri očekivana dana ciklusa nije bilo kvarova, prognoza se ne pravi. Izveštaj beleži da je ciklus prestao - najverovatnije su inženjeri već našli i uklonili uzrok.
Rad sa stvarnim podacima: šta algoritam pronalazi
Dnevnici incidenata uvek su puni „šuma“. Metod je usmeren na to da želje ne izdaje za stvarnost. Na običnim dnevnicima bez obrazaca, čak i sa velikim jednokratnim havarijama, sistem će jednostavno reći: „Ciklusa nema“.
- Kako algoritam obrađuje osobenosti dnevnika
Kvarovi danju: dnevni ciklus je teže naći - tone u prirodnom toku prijava korisnika. Algoritam će ga istaći samo ako se kvar dešava skoro u svakom ciklusu. Ako je ritam slab, sistem će radije ćutati.
Kratka istorija: ako izvoz obuhvata manje od 6 nedelja, algoritam neće tražiti cikluse. Matematici je potrebno najmanje 4 ponavljanja da bi razlikovala raspored od slučajnosti.
Retki događaji: jedna prijava mesečno je 12 tačaka godišnje među hiljadama drugih incidenata. Za potvrdu takvog ciklusa potrebna je istorija od nekoliko godina; na godišnjem preseku algoritam će to smatrati slučajnošću.
Nedostatak vremena: ako dnevnik sadrži samo datume bez sati i minuta, analiza će svejedno proći, ali bez posebnog izdvajanja noćnih kvarova.
Matrica odluka: o čemu govori pronađeni ciklus
| Priroda ciklusa | Moguć uzrok | Šta tim radi |
|---|---|---|
| Na svakih nekoliko dana, u isti satna primer, na svakih 10 dana u 03:00 | Automatski zadatak po rasporedu: težak prenos, preračun, izvoz podataka | Proveriti planer. Prebaciti zadatak na drugo vreme, dodeliti više resursa ili dodati skript provere pre pokretanja |
| Na svakih nekoliko dana, ali u različito vreme | Efekat nakupljanja: prepunjen disk, curenje memorije, zapušen red, neočišćen keš ili dnevnik. Resurs se iscrpljuje u istom periodu | Podesiti monitoring popunjenosti resursa. Podesiti automatsko čišćenje ili preventivni restart servisa po rasporedu |
| Isti dani u mesecuna primer, od 28. do 30. dana | Zatvaranje finansijskog meseca, formiranje redovnih izveštaja, masovne isplate | Uskladiti kalendar teških izveštaja. Unapred izdvojiti dodatne kapacitete baze podataka i postaviti stručnog dežurnog za te datume |
| Na svakih 30, 60 ili 90 dana | Rok važenja: istek SSL sertifikata, rotacija lozinki, kraj licenci ili ključeva za pristup API-ju | Uporediti datume izdavanja i isteka. Uvesti kontrolu rokova ili skripte za automatsko produženje sertifikata |
Primer 1. Kvar skripta sa korakom od 10 dana
Situacija: trgovinski lanac, oko 1100 prijava godišnje. Noćna razmena 1C:ERP sa sajtom povremeno pada. Ujutru skladište vidi neisporučene porudžbine, prijava se zatvara ručno i zaboravlja do sledećeg puta.
Šta je pokazala analiza: u 03:00 noću 1C:ERP otkazuje na svakih 10 dana - kvar je zabeležen u 18 ciklusa od 37, a norma za taj sistem je 2. Poslednji slučaj je 20. decembar, sledeći dan ciklusa je 9. januar.
Rezultat: inženjeri prestaju da gase simptome ujutru i idu u planer zadataka. Korekcija jednog pozadinskog procesa uklanja oko 18 havarija godišnje i jutarnje zastoje skladišta.
Svaki kružić je dan ciklusa: crveni - tog dana je sistem otkazao, prazan - dan je prošao mirno. Crtice - kvarovi u druge dane. Prazan crveni kružić posle kraja izvoza je sledeći dan ciklusa, ako se ništa ne menja.
Primer 2. Problem zatvaranja meseca
Situacija: računovodstvo se žali na zamrzavanja 1C na kraju meseca. IT služba smatra da je problem preuveličan, jer ne vidi jasne potvrde u opštem toku prijava.
Šta je pokazala analiza: u poslednja tri dana meseca 1C:ERP otkazuje u 11 meseci od 12 - 18 dana sa kvarom naspram pozadinske norme od 6. Sledeći prozor rizika je 29-31. januar.
Rezultat: beskorisne rasprave smenjuje tačan proračun. Za datume zatvaranja meseca IT odeljenje unapred izdvaja dodatne kapacitete servera i određuje dežurnog stručnjaka.
Zaključak: kako primeniti ove podatke u radu
Ciklični kvar je incident koji se može predvideti, a samim tim i sprečiti. Rad sa algoritmom za traženje ciklusa daje tri praktična rezultata:
- Ciljana dežurstvaInženjer se određuje strogo za datume ciklusa i proverava zdravlje sistema dan ranije, umesto da sutradan ujutru raščišćava posledice.
- Argumentacija za rukovodstvo i tehnički dugKvar koji se ponavlja pretvara se u razumljivu stavku u planu rada sa providnom matematikom: koji sistem pati, koliko havarija se dešava godišnje i kakav efekat će dati popravka.
- Automatska provera rezultataMetod providno pokazuje otklanjanje problema: čim se prvobitni uzrok očisti, izveštaj beleži da je ciklus prestao („u poslednjim ciklusima kvara nije bilo“).