Koji objekti se kvare iznova
U prodavnici br. 17 kasa opet ne štampa račun. Inženjer je restartuje i uklapa se u normu od 20 minuta. Posle tri dana situacija se ponavlja. U izveštajima Service Desk-a sve je „zeleno“ - prijave se zatvaraju u roku. Ali direktor prodavnice vidi da kasa stalno ne radi.
Svaka pojedinačna popravka radi se po propisu, ali standardni dnevnici ne pokazuju hronične kvarove. Da bi se od subjektivnog osećaja „opet nam se pokvarila kasa“ stiglo do tačnih odluka, potrebne su cifre: koji konkretno objekti se vraćaju na popravku, koliko su gori od susednih i da li je to samo slučajnost.
Zadatak metoda
Analiza izvoza iz Service Desk-a treba da odgovori na tri pitanja:
- Koji objekat se kvari češće od susednih? Konkretna kasa, jedan server od tri - ono što odudara od norme.
- Gde se kvar vraća odmah posle popravke? Objekat pada u serijama 1-3 dana posle popravke.
- Da li je to obrazac ili pozadina? Koliko bi bilo ponovljenih kvarova kada bi se svi objekti u sistemu kvarili istom slučajnom učestalošću.
Kako se računa
- 1. Fokus na objekat, a ne na sistem
Analizira se „kasa prodavnice br. 17“, a ne „sve kase“. Ako se posmatra sistem u celini, kvarovi će se dešavati svake nedelje samo zbog njihovog ukupnog broja.
- 2. Spajanje duplikata
Prijave za isti objekat, otvorene tokom tekuće havarije ili u roku od 1 sata posle popravke, računaju se kao jedan kvar. Time se odseca „treperenje“ monitoringa.
- 3. Metrika povratka
Beleži se kvar istog objekta u roku od 7 dana posle zatvaranja prethodne prijave.
- 4. Poređenje sa slučajnošću
Metod matematički deli kvarove objektima napamet. Zatim poredi činjenicu sa modelom: „27% kvarova se vratilo; pri slučajnoj raspodeli bilo bi ih oko 28%“.
- 5. Dva znaka anomalije
Kvari se češće od drugih: kvarova je više nego kod analoga, uz korekciju za veličinu parka (da se slučajno ne proglasi „najgorom“ prosto jedna od 47 prodavnica).
Kvarovi idu u serijama: posle popravke objekat se kvari za 1-3 dana - znatno češće nego što diktira opšti ritam sistema.
Važno: metod osvetljava problematičan čvor. Tačan uzrok (hardver ili softver) treba tražiti u tekstovima prijava.
Rad sa „prljavim“ dnevnicima u stvarnom životu
Algoritam je zaštićen od tipičnih problema dnevnika Service Desk-a i neće pronalaziti ono čega nema
- Nema kolone sa objektom (samo usluga)Metod ne traži ponavljanja, da ne bi davao lažne anomalije tamo gde je prosto mnogo obraćanja.
- Objekat se retko navodi (manje od 20% prijava)Analiza se zaustavlja uz navođenje razloga. Jasno je koje polje treba naterati da se popunjava.
- Šum monitoringa (5 prijava za sat)Spaja se u jedan incident.
- Različito pisanje („prodavnica 17“ i „PRODAVNICA br. 17“)Prepoznaje se kao jedan objekat.
- Masovni kvar (palo je sve)Ne daje lažne nalaze: jednokratna havarija ne upisuje se u „hroniku“ desetina servera.
- Malo podataka (manje od 4 nedelje ili manje od 20 kvarova)Metod ne donosi zaključke na nedovoljnom uzorku.
Pouzdanost je proverena na 160 godina podataka (ukupno). Metod je pronašao sve objekte koji se kvare 20-25 puta pri normi od 5. Serije od 5 kvarova zaredom hvata u 28 godina od 40, serije od 4 kvara - u 20 od 40. Lažno imenovanih objekata nije bilo.
Šta raditi sa pronađenim objektima
| Slika u dnevniku | Mogući uzroci | Šta dalje raditi |
|---|---|---|
| Objekat se kvari cele godine (26 puta pri normi od 5) | Istrošenost opreme, nenormalno opterećenje, problemi sa napajanjem na lokaciji | Modernizovati ili zameniti čvor. Proveriti tekstove prijava na istovetnost |
| Kvarovi idu u serijama (povratak za 1-3 dana) | Leče se simptomi, a ne uzrok (na primer, popravlja se običnim restartom) | Otvoriti Problem tiket, istražiti celu seriju u celini, a ne zatvarati pojedinačne prijave |
| Serija, a zatim meseci tišine | Neuspešno ažuriranje koje je kasnije vraćeno ili ispravljeno | Proveriti dnevnik izmena (Change Log). Učvrstiti ispravnu konfiguraciju |
| Povrataka je mnogo, ali u okviru slučajnosti | Problem je u celom sistemu, a ne u konkretnom serveru | Raditi sa sistemom globalno, ne tražiti „krivi“ objekat |
Primer. Kasa jedne prodavnice i server rezervnih kopija
Polazni podaci: trgovinski lanac, 47 prodavnica, 25 servera, oko 1 100 prijava godišnje.
Situacija: inženjeri stalno restartuju staru kasu u jednoj prodavnici. Server za rezervne kopije povremeno pada par dana posle podizanja.
Šta je pokazao izveštaj:
- Opšti nivo povrataka je 27% (pri slučajnoj raspodeli - 28%). Opšteg problema sa ponovnim kvarovima u sistemu nema.
- Kase prodavnice br. 17: 26 kvarova godišnje (tipična prodavnica daje 5). Kvare se 5 puta češće od ostalih.
- Server BACKUP-02: 12 od 16 kvarova desilo se u roku od nedelju dana posle prethodne popravke (tri jasne serije).
U čemu je korist takvog rezultata:
- Ciljana popravka. Zamena konkretne kase u prodavnici br. 17 isplati se smanjenjem izlazaka inženjera.
- Problem Management. Serija padova BACKUP-02 prosleđuje se na dubinsku analizu. Očigledno je da su obični restarti samo odlaganje sledećeg kvara.
- Obrazloženje budžeta. Zahtev za kupovinu opreme oslanja se na čeličan argument: „26 popravki godišnje pri normi od 5“. Finansijskom direktoru je to jasno bez tehničkih detalja.
- Upravljanje metrikama. Udeo povrataka (činjenica naspram slučajnosti) postaje providan KPI. Posle kvartala mogu se ponovo izvesti podaci i proveriti da li je broj anomalija na ovim objektima opao.
Red je objekat, oznaka je kvar. Crvena tačka - kvar u roku od 7 dana posle popravke prethodnog, tamna crta - posle pauze. Desno - koliko kvarova ima objekat i koliko ih ima tipičan objekat istog sistema, ili koliko kvarova se vratilo.