Dziiiiin! 3 je ujutro, sanjate divan san, i odjednom se javlja poziv. Ove sedmice ste na dužnosti i očigledno se nešto dogodilo. Automatski sistem poziva da sazna šta nije u redu. Ovo je važan aspekt upravljanja modernim računarskim sistemima, ali hajde da pogledamo kako da poboljšate obaveštenja za ljude.
Upoznajte se sa filozofijom monitoringa koja je nastala tokom nekoliko decenija mojih dužnosti u različitim monitoring timovima. Na nju je u velikoj mjeri utjecala prava biblija Roba Evashchuka (Moja filozofija obavještavanja) uključena u knjigu o , i knjiga Johna Alspaugha (Napomene o postavljanju upozorenja).
, и — hvala na pomoći u uređivanju posta.
Šta je CASE?
Odlučio sam smisliti lijepu skraćenicu poput ili . Ja to zovem CASE metoda. On opisuje četiri tačke na koje treba obratiti pažnju kada radite sa automatskim nadzorom:
- (uvezan kontekst)
- (praktična vrijednost)
- (naglasak na simptomima)
- (razred)
Ako koristite CASE, prema obavijestima se odnosite sa zdravom ravnodušnošću i ne budite ljude noću. Praćenje treba redovno procjenjivati u pogledu korisnosti i djelotvornosti. Kada osoba primi obavijest, imat će bolje mentalne modele i više samopouzdanja.
Da biste lakše zapamtili, zamislite da vam je potreban SLUČAJ [to jest slučaj, razlog - napomena prevodioca] da opravda svako upozorenje. :naočare za sunce:
I zašto je sve ovo?
. Iz mnogo razloga. I CASE ih neće sve eliminisati. Ali s njim ćete se buditi noću uz bolje obavijesti. Ova metoda pokriva različite organizacijske procese koji će također pomoći u ovom pitanju.
Ljepota metoda RED i USE je u tome što uz njihovu pomoć ne samo da znamo kako raditi, već i razgovaramo jedni s drugima istim jezikom. Nadam se da će CASE metoda olakšati raspravu o obavještenjima koja štite naše sisteme, ali drže naše kolege zauzetima.
Poenta je da morate stvoriti kulturu u svojoj organizaciji u kojoj se obavijesti tretiraju sa zdravom ravnodušnošću. Obavijesti se mogu kreirati za određenu svrhu, ali nije činjenica da kasnije neće izgubiti vrijednost. Zašto smo postavili ovo obavještenje? Koliko davno su njegovi kriterijumi revidirani? Pomoću CASE-a na ova pitanja se može odgovoriti.
Context-Heavy - kontekstualno povezivanje
3 sata ujutro nije najbolje vrijeme za čitanje poruka koje sadrže mnogo pametnih riječi. Da biste efikasno odgovorili, potrebne su vam informacije. U idealnom slučaju, to bi trebala biti informacija o određenom problemu, za koji je kontekst odmah jasan, a obavijesti bi trebale biti konfigurirane tako da je to moguće. Ovo je "posmatranje" i "orijentacija" iz . Nije sramota trošiti vrijeme na ovu postavku, jer je stalno ometanje osobe još skuplje. Poštujmo jedni druge.
Problemi imaju mnogo izvora. Posebno duhovi.
Kako mogu pomoći dežurnom? Prvo što dežurni vidi je obaveštenje, pa na osnovu njega gradi sve hipoteze. Zatim pogleda uputstva i kontrolne table, ali da li uvek postoje podaci o određenom obaveštenju, a ne samo opšti podaci? Alspaugh savjetuje “razmišljanje o tome kako biste mogli protumačiti ili odgovoriti na obavještenje” (slajd 29). Dobra notifikacija je fokusirana na osobu na dužnosti, a ne samo konfigurisana pragom.
Evo nekoliko ideja kako poboljšati kontekst obavještenja:
- Pokažite korisniku nešto korisno i posebno kreirano, a ne samo obične upute ili kontrolnu ploču. Ranije smo momci i ja koristili istraživačke kontrolne table konfigurisane za određena obaveštenja. Ovo će pomoći ako je problem poznat, ali će samo zbuniti druge. Ovdje moramo pronaći balans.
- Recite nam nešto o istoriji obavještenja: da li je novo? Da li radi često? Je li sezonski?
- Prikaži nedavne promjene stanja sistema. Da li se nešto promijenilo u posljednje vrijeme? (Na primjer, implementacija ili omogućavanje/onemogućavanje funkcionalnosti.)
- Pokažite odnose i pružite informacije za mentalni model: sistemske zavisnosti treba da budu jasno vidljive, po mogućnosti sa naznakom funkcionalnosti.
- Brzo povežite korisnika s timom: mogu li vidjeti trenutne incidente ili mogu saznati ko je još u kompaniji primio obavještenje? Program aktiviran?
U idealnom slučaju, program upravljanja incidentima će pružiti savjete o tome kako poboljšati kontekst obavještavanja o istragama incidenta. Uvijek se ima na čemu raditi!
Djelotvorno - praktična vrijednost
Da li dežurni treba da uradi nešto kao odgovor na obaveštenje? Ako ne morate ništa da radite ili vam nije jasno šta da radite, zašto ste ga probudili? Morate izbjegavati obavijesti koje nerviraju dežurne i ne zahtijevaju radnju.
Sta da radim? Šta želiš?
U prošlosti, kada su sistemi bili jednostavni, a timovi mali, postavljali smo nadzor samo da bismo bili u toku. Obavijest da je opterećenje na hrpi povećano dat će nam kontekst ako usluga naknadno ne radi. U velikoj mjeri, takva obavještenja će samo stvoriti zabunu jer naši sistemi uvijek rade u stanju degradacije različite težine. To brzo dovodi do i, naravno, do gubitka osetljivosti. Stoga dežurni ignoriše ili čak filtrira takve obavijesti i ne odgovara uvijek na njih po potrebi. Nemojte upasti u ovu zamku! Nemojte postavljati sve obavijesti zaredom, a zatim ih slati e-poštom u neki od Boga zaboravljeni folder.
Evo kako izgleda obavijest s praktičnom vrijednošću:
- Obavještenje zahtijeva radnju, a ne samo prijavljivanje vijesti.
- Ovu radnju je teško ili rizično automatizirati. Ako se neka akcija može automatizirati, onda je automatizirajte, prestanite gnjaviti ljude!
- Obaveštenje sadrži hitne preporuke u obrascu (SLA) ili (RTO). Dežurni tada može aktivirati program upravljanja incidentima organizacije.
Želim pojasniti: ne kažem da bi obavijesti trebale doći samo za najvažnije SLO (ciljeve na razini usluge) za API. SLO praćenje je konstantno fragmentirano i podijeljeno i zahtijeva isti pristup svim uslugama. Jasno je da ćete pratiti najvažnije SLO za klijente koji vam plaćaju. Ali infrastrukturne SLO, kao što su baze podataka, također treba pratiti. Uskoro ćete morati da se bavite internim kupcima i da im pružite podršku. I tako u nedogled.
Zasnovano na simptomima - naglasak na simptomima
Hteli to ili ne, vi radite u distribuiranom sistemu (Kavaj). Kao rezultat toga, koristite različite taktike da izolujete usluge i zaštitite ih od neuspjeha (Trainor et al.)3. I iako odloženo sakupljanje smeća ili upit baze podataka u zastoju ukazuju na probleme, nema potrebe žuriti da ih popravite ako korisnici ne budu imali problema u bliskoj budućnosti.
Ovo su važni signali i mogu imati praktičnu vrijednost, ali ako ne ometaju korisnike, onda nisu dovoljno hitni da odvrate pažnju polaznika. Obavještenja zasnovana na uzrocima su snimci naših mentalnih modela o kvaru sistema. Bolje je pratiti važne simptome nego pokušavati navesti sve moguće uzroke neuspjeha.
Da bi obavještenja bila smislena, fokusirajte se na , važno za korisnike. Evashchuk to naziva "nadzor za korisnike". Zapamtite da se ova filozofija mora primjenjivati u cijeloj organizaciji. Ako neka usluga ima hitne probleme negdje duboko u infrastrukturi, odgovarajući tim će se pobrinuti za njih. Zaštita sistema od takvih kvarova je potpuno odvojena stvar (Trainer et al., odjeljak o strategijama za minimiziranje kritičnih ovisnosti).
Simptomi nisu toliko varijabilni
Richard Cook nas podsjeća da su složeni sistemi puni mana, nedostataka i problema. Pokušaj nabrajanja svih mogućih razloga je sizifov zadatak. Pokušavate opisati probleme, ali oni se stalno mijenjaju. Cindy Sridharan smatra da “sistemi ne moraju biti u savršenom stanju svake sekunde” i da je bolje koristiti ljudskiji pristup ( (“Nadgledanje distribuiranih sistema”), 7).
Izbjegavajte obavještenja nakon incidenta
Obično su obavještenja o uzrocima konfigurirana za ispravljanje incidenata. A ova ograničena obavještenja o tome što se dogodilo stvaraju lažni osjećaj sigurnosti, jer sistem svaki put smisli nove načine za razbijanje.
Nemojte da vas zavaraju obavijesti o uzroku. bolje razmisli:
- Zašto obavještenje zasnovano na simptomima nije primijetilo problem?
- Da li bi bilo korisno poboljšati kontekst za korisnika?
- Kako se alati za praćenje mogu poboljšati kako bi se dijagnoza postavila brže, umjesto da se gomilaju obavijesti o tome šta se dogodilo?
Alati za praćenje za dijagnozu pomoći će samo ako o njima razmišljate kao o načinu prelaska od simptoma do rješenja. Bez ovih povratnih informacija, jednostavno ćete biti bombardirani kasnim obavještenjima i grafikonima o prošlim neuspjesima—i ni riječi o budućim. Ovo je odlična prilika za organizaciju da pređe iz odbrane u napad. I programeri i menadžeri proizvoda imat će ista očekivanja i jasne ciljeve. Slučaj - CASE (:wink:) - je jasan za svako obavještenje.
Obavještenja zasnovana na razlozima podnošljiva su u umjerenim količinama
Ponekad nam naš sistem ostavlja malo izbora u pogledu obavještenja zasnovanih na uzroku. A ponekad i dežurni savršeno dobro razumiju da će simptom definitivno dovesti do neuspjeha i stoga ima praktičnu vrijednost. Možda jednostavno niste sigurni što se događa i postavljate obavještenja kako biste bili sigurni. Nadamo se da je ova radnja privremena dok ne možemo promijeniti sistem da riješimo problem s performansama.
Imajte na umu ostale komponente CASE-a kada se bavite ovim situacijama. Samo zato što je privremeno ne znači da možete prestati da razmišljate svojom glavom.
Ocijenjeno - evaluacija
Bilo kakve promjene u sistemu (novi kod, nova infrastruktura, bilo šta novo) proširuju raspon kvarova (Cook, 3). Radi li ovo obavještenje i dalje prema očekivanjima? Jasni i aktuelni mentalni modeli sistema i iskustvo reagovanja na neka obaveštenja podrške - ovo su ključne karakteristike . Defekti u sistemima se stalno razvijaju i moramo ih pratiti.
Morate stalno procjenjivati kvalitet svakog obavještenja kako biste bili sigurni da funkcionira kako se očekuje. Dragi lideri! Vašim timovima će biti mnogo lakše ako im pomognete da uspostave ovaj proces! Evo nekoliko ideja za procjenu:
- Koristite , ili druge metode testiranja obavještenja. Tim to može učiniti sam bez potrebe da se oslanja na težak sistem upravljanja incidentima!
- Uključite kolekciju svih obavještenja vezanih za incidente u svoj program upravljanja incidentima. Označite korisno, štetno, neprikladno, nejasno itd. Koristite ih kao povratnu informaciju.
- Prava obavještenja se pokreću rijetko i pažljivo se testiraju. Uvjerite se da sve veze rade, da upućuju na pravi kontekst, itd.
- Ako se obavještenje nikada ne pokreće ili se pokreće prečesto, nešto nije u redu s njim. Popravite ili uklonite. Čuvajte se pretjerane pasivnosti ili aktivnosti!
- Postavite vremenske oznake obavijesti s datumima isteka. Ako je datum isteka istekao, procijenite obavijest koristeći CASE metodu i ažurirajte vremensku oznaku. Kao i hrana, redovno provjeravajte rok trajanja.
- Pojednostavite proces poboljšanja obavještenja. Koristite praćenje kao kod i pohranite obavijesti u Git spremište. Zahtjevi za povlačenje pomažu angažirati tim i daju vam historiju prošlih obavještenja. I više se nećete bojati mijenjati obavještenja ili tražiti dozvolu od onih koji su za njih odgovorni.
- Postavite povratne informacije za obavještenja, čak i ako su jednostavne , tako da dežurni označavaju obavještenja kao beskorisna ili nametljiva. Ugradite link ili poziv na akciju u samo obavještenje i redovno pregledajte svoje povratne informacije.
- Uspostavite pravilo u timu - pustite dežurne da rade da bi se pojednostavila dežurstva kada je malo posla. Neka sve poslije bude malo bolje nego prije.
zaključak
Vjerujem da metoda CASE pomaže programerima i organizacijama da razgovaraju o postavljanju i slanju automatiziranih obavijesti. Jedan programer može početi procjenjivati obavijesti koristeći CASE metodu, a zatim će se cijela organizacija pridružiti drugim programerima, menadžmentu i programima za upravljanje incidentima kako bi obavijesti održale u dobrom stanju. Ovo ne zahtijeva nikakve posebne alate ili složene procese.
Čitava industrija treba da razmišlja o ljudskom faktoru dok je na dužnosti bez žrtvovanja vrhunske korisničke usluge. Svi ovi alati i prakse se mogu i trebaju poboljšati. Nadam se da će CASE metoda pomoći u ovome.
Uživajte u poboljšanim obavještenjima!
izvor: www.habr.com