Matrica eskalacije i šum upozorenja: koga buditi i kada

1. Odakle dolazi šum

Šum se ne pojavljuje odjednom. Gomila se godinama, i skoro svaki njegov izvor je u svoje vreme bio razumna odluka. Zato je čišćenje toka teško: ne raspravlja se sa greškom, nego sa nečijim nekadašnjim zdravim razumom.

• Pragovi. Posle velikog kvara prag okidanja se spusti sa rezervom. Takvi kvarovi se više ne dešavaju, a signali ostaju. Posle godinu dana niko se ne seća zašto je zauzetost diska od 70% razlog za poziv, ali je i strašno isključiti.
• Nadzor opreme, a ne usluge. Monitoring se postavlja po spisku opreme: svaki server, port, disk. Otkaz jednog sviča pretvara se u desetine poruka o nedostupnosti svega što stoji iza njega, umesto jedne - o uzroku.
• Nema tišine tokom radova. Planirano održavanje i restarti posle ažuriranja stvaraju tok „havarijskih“ poruka. Tim se navikne da ih ne primećuje - i jednog dana ne primeti pravi kvar koji se vremenski poklopio sa radovima.
• Treperenje. Kanal ili servis nestaje i vraća se nekoliko puta u minuti (flapping). Svaki prelaz - par poruka. Incidenta možda uopšte nema, a desetak redova u traci već postoji.
• Signali bez primaoca. Poruka ide u zajednički čet od pedeset ljudi, gde za nju niko nije odgovoran. Takav signal se ne obrađuje - samo se čita.
• Nasleđe otišlih sistema i ljudi. Provere za servis kog više nema; pravila inženjera koji je otišao pre tri godine. Strašno ih je isključiti: niko ne zna šta će se pokvariti.

Svi ovi uzroci imaju jedan ishod, i on nije tehnički nego ljudski: zamor od upozorenja (alert fatigue). Google ga u knjizi o SRE opisuje direktno: kada signala ima previše, ljudi počinju da ih samo preleću pogledom i ignorišu, propuštajući pravi koji je sakriven u šumu. Dežurni prestaje da čita traku i hvata poznate slike. To radi do prve važne poruke u nepoznatom obliku. Tako šum od neprijatnosti postaje rizik za biznis.

2. Kako izmeriti šum

„Mnogo upozorenja“ je osećaj, a ne pokazatelj. Razgovor se menja kada su na stolu nekoliko brojeva za poslednjih pola godine. Računaju se iz izvoza događaja iz monitoringa i incidenata iz sistema prijava, koje već imate. Poseban projekat nije potreban.

Smernice kod kojih izvor nije naveden su referentne tačke iz naše prakse, a ne norma. Telekomunikaciona mreža i računovodstveni sistem imaju različite normalne vrednosti. Smisao nije da se poredite sa tuđom brojkom, nego da izračunate svoju i pogledate je ponovo za kvartal: smer kretanja je važniji od apsolutnog nivoa.

3. Tri klase događaja i pravilo jednog primaoca

ITIL deli događaje na tri klase. Informativni: činjenica je zabeležena, akcija nije potrebna (rezervna kopija je napravljena, korisnik se prijavio). Upozorenje: pokazatelj se približava granici, akcija će biti potrebna, ali ne sada (disk je pun 80%). Izuzetak: kršenje, postupiti treba odmah (servis je nedostupan).

Korist od podele je u tome što tri klase imaju različite puteve isporuke. Informativni - samo u dnevnik: niko ga ne čita u realnom vremenu i ne treba. Upozorenje - u radni red, rešava se u radno vreme. Izuzetak - konkretnoj osobi, sa zahtevom za reakciju. Kada su sve tri pomešane u jednoj traci, sortiranje koje je trebalo da uradi sistem radi umoran inženjer. To je tehnički uzrok šuma.

4. Sedam koraka za smanjenje toka

Redosled nije slučajan. Prva tri koraka daju vidljiv rezultat za nekoliko dana i skoro ništa ne koštaju - za njih je lako dobiti saglasnost tima. Poslednji traže rad sa podacima i razgovor sa vlasnicima usluga.

1. Spajanje ponavljanja. Ponovljena poruka o istom stanju ažurira otvoreni događaj umesto da stvara novi (deduplikacija). Jedan otkaz - jedan red sa brojačem ponavljanja.
2. Tišina tokom radova. Potiskivanje upozorenja tokom održavanja, vezano za kalendar izmena. Sporedni efekat je vredniji od glavnog: bez tačnog kalendara potiskivanje se ne može podesiti, pa se kalendar pojavljuje.
3. Vremensko zadržavanje. Stanje mora da potraje zadato vreme pre nego što postane signal. Uklanja treperenje bez diranja pragova.
4. Uklanjanje signala bez akcije. Uzimamo pravila sortirana po broju okidanja i za svako od gornjih postavljamo jedno pitanje: šta čovek radi kada ovo dobije? Nema odgovora - pravilo ide u dnevnik. Ne isključuje se, nego prestaje da budi.
5. Pragovi po podacima, a ne po okruglim brojevima. Prag se postavlja po stvarnom ponašanju pokazatelja tokom nekoliko meseci. „90% diska“ je okrugao broj. „Nivo iznad kog je pokazatelj bio 2% vremena, i svaki put se to završilo kvarom“ - to je prag.
6. Povezivanje po zavisnostima. Ako se zna da iza sviča stoji dvadeset servera, njegov otkaz daje jedan događaj o uzroku, a ne dvadeset jedan (korelacija). Potrebna je bar gruba mapa zavisnosti - to je najduži od sedam koraka.
7. Redovna revizija. Jednom u kvartalu - pola sata na najbučnija pravila i na pravila koja nijednom nisu okinula. Prva prave šum, druga su najverovatnije pokvarena i ćute ne zato što je sve u redu. Google SRE savetuje da se statistika upozorenja sa rukovodstvom razmatra isto tako - jednom u kvartalu.

Šta ne treba raditi: početi masovnim isključivanjem pravila „da bude tiho“. Takva tišina se ničim ne razlikuje od tišine pokvarenog monitoringa, i posle ih nećete razlikovati. Svako uklonjeno pravilo mora da ode ili u dnevnik, ili u izveštaj koji neko gleda po rasporedu.

5. Prioritet: uticaj i hitnost

Matrica eskalacije ne počinje od ljudi, nego od prioriteta. Po ITIL-u prioritet incidenta čine dve nezavisne stvari: uticaj (koliko korisnika i usluga je pogođeno i kojih) i hitnost (koliko brzo će posledice postati ozbiljne). Često se mešaju: kvar kod jednog čoveka može biti hitan - na primer, na kasi u špicu - a masovna sitna neprijatnost nije hitna. Nivoa je obično četiri ili pet; ispod je tipična varijanta sa četiri.

Rokovi u tabeli su tipične smernice, a ne obaveza. Pravi rokovi dolaze iz dogovora sa biznisom i iz onoga što tim stvarno može da izdrži. Lepo zapisan a neizvodljiv rok gori je od nepostojećeg: uči ljude da proceduru smatraju dekoracijom.

Pravilo koje štedi mnogo noćnih rasprava (naša praksa): gubitak rezerve je P2, a ne P3. Usluga radi, klijent ništa ne primećuje, i želi se odložiti do jutra. Ali svaki sledeći otkaz je sada kritičan: rezerva sigurnosti, zbog koje je rezerva postavljena, već je potrošena.

6. Matrica eskalacije: ko, kada, za koliko

U ITIL-u eskalacija postoji u dve vrste, i ne treba ih mešati. Funkcionalna: zadatak prelazi na onoga ko ima više znanja ili prava - od dežurnog do inženjera za oblast, dalje do proizvođača ili izvođača. Njeni nivoi se obično zovu linije podrške: L1, L2, L3. Hijerarhijska: pitanje se podiže po upravljačkoj liniji kada su potrebne odluke, novac, prioriteti ili komunikacija sa spoljnim svetom. Prva ubrzava popravku, druga uklanja prepreke; jedan incident može zahtevati obe. Oznake M1 i M2 u tabeli su naše, radi kratkoće.

Tri znaka razlikuju matricu koja radi od nacrtane. Po tajmeru, a ne po osećaju. Istekao je kontrolni rok - sledeći nivo se uključuje sam, bez unutrašnje borbe „zvati ili još sačekati“. Eskalacija nije kazna. Ako se za podizanje pitanja naviše pita „zašto se nisi snašao“, inženjer će odugovlačiti do poslednjeg. U SRE za to postoji pojam analize bez traženja krivca (blameless): analiziraju se događaji i pravila, a ne ljudi. Svaka uloga ima zamenu. Uloga bez drugog kontakta je konkretna osoba, i dok je ona na odmoru, nivo eskalacije nestaje.

Red koji se često zaboravlja je eskalacija ka spoljnom dobavljaču. Ona ima svoje rokove, broj ugovora, kontakt i postupak potvrde. Ako dežurni u tri ujutru to nema pri ruci, vreme oporavka ne određuje tehnika, nego brzina traženja pravog telefona.

7. Kada buditi rukovodioca

Najspornije pitanje svake službe, i treba da ga rešava zapisano pravilo, a ne karakter dežurnog. Pravilo mora da se primeni za trideset sekundi, bez razmišljanja. Ispod su naša četiri kriterijuma: okidanje bilo kog - razlog za poziv u bilo koje doba dana i noći.

• Pogođeni su klijenti ili novac. Usluga koju koriste spolja je nedostupna ili iskrivljuje podatke. Ne „može biti pogođena“, nego postoji znak da je već pogođena.
• Potrebna je odluka iznad prava dežurnog. Isključiti deo funkcija, vratiti ažuriranje, prebaciti lokaciju, potrošiti novac, angažovati izvođača van ugovora.
• Treba razgovarati sa spoljnim svetom. Klijenti, regulator, mediji, veliki partner. Ćutanje u tom trenutku košta više od samog kvara, a dežurni ne treba da govori u ime kompanije.
• Prognoza je gora od činjenice. Sada sve radi, ali događaji vode ka kritičnom: ponestaje prostora, red raste, rezerva je otkazala, kvar kod dobavljača se širi. Probuditi sada je jeftinije nego za dva sata.

Pravilu trebaju dve zaštite. „Probudili bez razloga“ nije greška dežurnog ako je kriterijum okinuo: preispituje se pravilo, a ne čovek. „Nisu probudili kada je trebalo“ se obavezno analizira - ali kao defekt pravila, a ne kao prekršaj. Tim koji je jednom izgrđen zbog noćnog poziva sledeći put najverovatnije neće zvati.

Korisno je unapred se dogovoriti o formatu samog poziva. Trideset sekundi: šta ne radi, od kada, koga pogađa, šta je već urađeno, šta je potrebno od sagovornika. Probuđen čovek bolje prima strukturu nego priču, i odluka se donosi u prvom minutu, a ne u desetom.

8. Šta se vidi u podacima

Sve opisano se proverava običnim izvozom za 90 dana i više: dnevnik događaja iz monitoringa i dnevnik incidenata iz sistema prijava. Ne anketom tima: anketa pokazuje predstave, izvoz - ponašanje.

• Pokvarena eskalacija: veliki razmak između početka kvara i početka rada. Ako incident traje dva sata, a sama popravka je trajala petnaest minuta, znači da popravljaju brzo, ali dugo traže ko treba da popravlja. U DevOps-u se ovaj deo meri prosečnim vremenom potvrde (MTTA). To je defekt rutiranja, a ne kvalifikacije.
• Šum: odnos signala i incidenata i udeo signala zatvorenih bez ijedne akcije. Obe vrednosti se računaju mehanički.
• Formalni prioriteti: ako skoro svi incidenti u bazi imaju isti prioritet, prioritizacije nema - postoji polje u formularu.
• Noćno opterećenje: dnevni profil i udeo noćnih buđenja koja su se završila stvarnim incidentom. To je cena trenutnih pravila, izražena u probuđenim ljudima.
• Ponavljanja: isti kvar se vraća nedeljama. Znači da eskalacija svaki put iznova gasi ono što je već gašeno. To više nije pitanje za matricu, nego za upravljanje problemima - ITIL praksu koja traži i uklanja uzroke.