Dziiiiin! 3 je ujutro, sanjate divan san i odjednom se čuje poziv. Ovaj tjedan ste na dužnosti i očito se nešto dogodilo. Automatizirani sustav zove da sazna što nije u redu. Ovo je važan aspekt upravljanja modernim računalnim sustavima, ali pogledajmo kako poboljšati obavijesti za ljude.
Upoznajte se s filozofijom praćenja, rođenom tijekom nekoliko desetljeća mojih dužnosti u različitim timovima za praćenje. Na nju je uvelike utjecala prava biblija Roba Evashchuka (My Notification Philosophy) uključen u knjigu o , i knjiga Johna Alspaugha (Napomene o postavljanju upozorenja).
, и — hvala na pomoći u uređivanju posta.
Što je CASE?
Odlučio sam smisliti lijepu kraticu poput ili . Ja to zovem CASE metoda. On opisuje četiri točke na koje treba obratiti pozornost kada radite s automatskim nadzorom:
- (vezano za kontekst)
- (praktična vrijednost)
- (naglasak na simptome)
- (razred)
Ako koristite CASE, prema obavijestima se odnosite zdravo ravnodušno i ne budite ljude noću. Potrebno je redovito procjenjivati korisnost i učinkovitost praćenja. Kada osoba primi obavijest, imat će bolje mentalne modele i više samopouzdanja.
Da biste lakše zapamtili, zamislite da vam treba SLUČAJ [to jest, slučaj, razlog - napomena prevoditelja] za opravdanje svakog upozorenja. :sunčane naočale:
A čemu sve to?
. Iz mnogo razloga. A CASE ih neće sve eliminirati. Ali s njim ćete se noću probuditi uz bolje obavijesti. Ova metoda pokriva različite organizacijske procese koji će također pomoći u ovom pitanju.
Ljepota RED i USE metoda je u tome što uz njihovu pomoć ne samo da znamo raditi, već i međusobno govorimo istim jezikom. Nadam se da će metoda CASE olakšati raspravu o obavijestima koje štite naše sustave, ali zaokupljaju naše kolege.
Poanta 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 ovu obavijest? Prije koliko su vremena revidirani njegovi kriteriji? S CASE-om se na ova pitanja može odgovoriti.
Context-Heavy - vezanje konteksta
3 ujutro nije najbolje vrijeme za čitanje poruka koje sadrže mnogo pametnih riječi. Da biste učinkovito odgovorili, potrebne su vam informacije. U idealnom slučaju, to bi trebala biti informacija o određenom problemu, za koju je kontekst odmah jasan, a obavijesti bi trebale biti konfigurirane tako da je to moguće. Ovo je "promatranje" i "orijentacija" iz . Nije šteta trošiti vrijeme na ovu postavku, jer je stalno ometanje osobe još skuplje. Poštujmo jedni druge.
Problemi imaju mnogo izvora. Pogotovo duhovi.
Kako mogu pomoći dežurnom? Prvo što dežurni vidi je obavijest, pa na temelju nje gradi sve hipoteze. Zatim pogleda upute i nadzorne ploče, no jesu li uvijek podaci o određenoj obavijesti, a ne samo opći podaci? Alspaugh savjetuje "razmišljanje o tome kako biste mogli protumačiti ili odgovoriti na obavijest" (slajd 29). Dobra obavijest usmjerena je na osobu na dužnosti, a ne samo konfigurirana pragom.
Dakle, evo nekoliko ideja o tome kako poboljšati kontekst obavijesti:
- Pokažite korisniku nešto korisno i posebno kreirano, a ne samo obične upute ili nadzornu ploču. Ranije smo dečki i ja koristili istražne nadzorne ploče konfigurirane za određene obavijesti. To će pomoći ako je problem poznat, ali će samo zbuniti druge. Tu moramo pronaći ravnotežu.
- Recite nam nešto o povijesti obavijesti: je li nova? Djeluje li često? Je li sezonski?
- Prikaži nedavne promjene stanja sustava. Je li se što promijenilo u zadnje vrijeme? (Na primjer, implementacija ili funkcija omogućavanja/onemogućavanja.)
- Pokažite odnose i pružite informacije za mentalni model: ovisnosti sustava trebaju biti jasno vidljive, po mogućnosti s naznakom funkcionalnosti.
- Brzo povežite korisnika s timom: mogu li vidjeti trenutne incidente ili mogu saznati tko je još u tvrtki primio obavijest? Program aktiviran?
U idealnom slučaju, program upravljanja incidentima pružit će savjete o tome kako poboljšati kontekst obavijesti o istragama incidenta. Uvijek ima na čemu raditi!
Upotrebljivo - praktična vrijednost
Treba li dežurni nešto poduzeti po dojavi? Ako ne morate ništa učiniti ili vam nije jasno što učiniti, zašto ste ga probudili? Morate izbjegavati obavijesti koje smetaju onima na dužnosti i ne zahtijevaju radnju.
Što da napravim? Što želiš?
U prošlosti, kada su sustavi bili jednostavni, a timovi mali, postavili smo nadzor samo kako bismo bili u tijeku. Obavijest da se opterećenje hrpe povećalo dat će nam kontekst ako usluga naknadno ne radi. U velikoj mjeri, takve će obavijesti samo stvoriti zabunu jer naši sustavi uvijek rade u stanju degradacije različite ozbiljnosti. To brzo dovodi do i, naravno, do gubitka osjetljivosti. Stoga dežurni takve obavijesti ignorira ili čak filtrira i ne reagira uvijek na njih prema potrebi. Nemojte upasti u ovu zamku! Nemojte postavljati sve obavijesti za redom i onda ih slati e-poštom u neki bogomforsake folder.
Ovako izgleda obavijest s praktičnom vrijednošću:
- Obavijest zahtijeva radnju, a ne samo prijavu vijesti.
- Ovu je radnju teško ili riskantno automatizirati. Ako se radnja može automatizirati, onda je automatizirajte, prestanite gnjaviti ljude!
- Obavijest sadrži hitne preporuke u obrascu (SLA) ili (RTO). Dežurni tada može aktivirati program organizacije za upravljanje incidentima.
Želim pojasniti: ne kažem da bi obavijesti trebale dolaziti samo za najvažnije SLO (ciljeve razine usluge) za API. Nadzor ČVN-a je stalno fragmentiran i podijeljen i zahtijeva isti pristup svim uslugama. Jasno je da ćete pratiti najvažnije ČVN za klijente koji vam plaćaju. Ali infrastrukturne ČVN-e, kao što su baze podataka, također treba nadzirati. Uskoro ćete morati imati posla s internim kupcima i pružati im podršku. I tako u nedogled.
Temeljeno na simptomima - naglasak na simptomima
Htjeli vi to ili ne, radite u distribuiranom sustavu (Kavaj). Kao rezultat toga, koristite različite taktike da izolirate usluge i zaštitite ih od kvara (Trainor et al.)3. I premda odgođeno prikupljanje smeća ili zaustavljeni upit baze podataka ukazuje 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 nije dovoljno hitno da bi odvratilo pozornost poslužitelja. Obavijesti temeljene na uzrocima su snimke naših mentalnih modela o kvaru sustava. Bolje je pratiti važne simptome nego pokušavati navesti sve moguće uzroke kvara.
Da bi obavijesti imale smisla, usredotočite se na , važno za korisnike. Evashchuk to naziva "monitoring za korisnike". Ne zaboravite da se ova filozofija mora primijeniti u cijeloj organizaciji. Ako servis ima hitnih problema negdje duboko u infrastrukturi, odgovarajući tim će ih riješiti. Zaštita sustava od takvih kvarova potpuno je zasebna stvar (Trainer et al., odjeljak o strategijama za minimiziranje kritičnih ovisnosti).
Simptomi nisu toliko promjenjivi
Richard Cook nas podsjeća da su složeni sustavi puni mana, nedostataka i problema. Pokušati nabrojati sve moguće razloge je sizifov posao. Pokušavate opisati probleme, ali oni se stalno mijenjaju. Cindy Sridharan vjeruje da "sustavi ne moraju biti u savršenom stanju svake sekunde" i da je bolje koristiti ljudskiji pristup ( ("Nadziranje distribuiranih sustava"), 7).
Izbjegavajte obavijesti nakon incidenta
Obično su obavijesti o uzrocima konfigurirane za ispravljanje incidenata. A te ograničene obavijesti o tome što se dogodilo stvaraju lažan osjećaj sigurnosti jer sustav svaki put smišlja nove načine za proboj.
Neka vas ne zavare obavijesti o uzrocima. Bolje razmisli:
- Zašto obavijest temeljena na simptomima nije uočila problem?
- Bi li bilo korisno poboljšati kontekst za korisnika?
- Kako se alati za praćenje mogu poboljšati da se dijagnoza postavi brže, umjesto da se gomilaju obavijesti o tome što se dogodilo?
Alati za praćenje radi dijagnoze pomoći će samo ako o njima razmišljate kao o načinu prelaska sa simptoma na rješenje. Bez ovih povratnih informacija jednostavno ćete biti bombardirani kasnim obavijestima i grafikonima o prošlim neuspjesima—i ni riječi o budućim. Ovo je izvrsna prilika za organizaciju da prijeđe iz obrane u napad. I programeri i voditelji proizvoda imat će ista očekivanja i jasne ciljeve. Za svaku obavijest jasan je slučaj - CASE (:wink:).
Obavijesti utemeljene na razlozima podnošljive su u umjerenim količinama
Ponekad nam naš sustav ne ostavlja malo izbora u smislu obavijesti temeljenih na uzrocima. A ponekad oni na dužnosti savršeno dobro razumiju da će simptom sigurno dovesti do neuspjeha, pa stoga ima praktičnu vrijednost. Možda jednostavno niste sigurni što se događa i postavljate obavijesti kako biste bili sigurni. Nadamo se da je ova radnja privremena dok ne promijenimo sustav kako bismo riješili problem s performansama.
Imajte na umu druge komponente CASE-a kada se bavite ovakvim situacijama. Samo zato što je privremeno ne znači da možete prestati razmišljati svojom glavom.
Ocijenjeno – ocjena
Sve promjene u sustavu (novi kod, nova infrastruktura, bilo što novo) proširuju raspon kvarova (Cook, 3). Radi li ova obavijest i dalje prema očekivanjima? Jasni i aktualni mentalni modeli sustava i iskustvo u odgovaranju na neke obavijesti podrške - ovo su ključne značajke . Nedostaci u sustavima stalno se razvijaju i moramo ići u korak s njima.
Morate stalno procjenjivati kvalitetu svake obavijesti kako biste bili sigurni da rade prema očekivanjima. Dragi voditelji! Vašim će timovima biti puno lakše ako im pomognete uspostaviti ovaj proces! Evo nekoliko ideja za ocjenjivanje:
- upotreba , ili druge metode testiranja obavijesti. Tim to može učiniti sam, a da se ne mora oslanjati na teški sustav upravljanja incidentima!
- Uključite prikupljanje svih obavijesti povezanih s incidentima u svoj program upravljanja incidentima. Označite kao korisno, štetno, neprikladno, nejasno itd. Koristite ih kao povratnu informaciju.
- Ispravne obavijesti pokreću se rijetko i pažljivo se testiraju. Provjerite rade li sve veze, pokazuju li na pravi kontekst itd.
- Ako se obavijest nikad ne aktivira ili se aktivira prečesto, s njom nešto nije u redu. Popravite to ili uklonite. Čuvajte se pretjerane pasivnosti ili aktivnosti!
- Postavite vremenske oznake obavijesti s datumima isteka. Ako je datum isteka istekao, procijenite obavijest metodom CASE i ažurirajte vremensku oznaku. Kao i hrani, redovito provjeravajte rok trajanja.
- Pojednostavite postupak poboljšanja obavijesti. Koristite nadzor kao kod i pohranite obavijesti u Git repozitorij. Zahtjevi za povlačenjem pomažu angažirati tim i daju vam povijest prošlih obavijesti. I više se nećete bojati mijenjati obavijesti ili tražiti dopuštenje od onih koji su za njih odgovorni.
- Postavite povratne informacije za obavijesti, čak i ako su jednostavne , tako da dežurni označavaju obavijesti kao beskorisne ili nametljive. Ugradite vezu ili poziv na radnju u samu obavijest i redovito pregledavajte povratne informacije.
- Uspostavite pravilo u timu - pustite dežurne da rade kako bi pojednostavili dežurstva kada ima malo posla. Neka sve poslije tebe bude malo bolje nego što je bilo prije.
Zaključak
Vjerujem da metoda CASE pomaže programerima i organizacijama u raspravi o postavljanju i slanju automatskih 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 bile u dobrom stanju. Ovo ne zahtijeva nikakve posebne alate ili složene procese.
Cijela industrija mora razmišljati o ljudskom faktoru dok je na dužnosti bez žrtvovanja vrhunske korisničke usluge. Svi ovi alati i prakse mogu se i trebaju poboljšati. Nadam se da će CASE metoda pomoći u tome.
Uživajte u poboljšanim obavijestima!
Izvor: www.habr.com