Dziiiiin! Ura je 3 zjutraj, sanjate čudovite sanje in nenadoma vas pokličejo. Ta teden si v službi in očitno se je nekaj zgodilo. Samodejni sistem pokliče, da ugotovi, kaj je narobe. To je pomemben vidik upravljanja sodobnih računalniških sistemov, vendar poglejmo, kako izboljšati obvestila za ljudi.
Seznaniti se s filozofijo spremljanja, ki se je rodila v več desetletjih mojih dolžnosti v različnih ekipah za spremljanje. Nanjo je v veliki meri vplivala prava biblija Roba Evashchuka (Moja filozofija obveščanja), ki je vključena v knjigo o , in knjiga Johna Alspaugha (Opombe o nastavitvi opozoril).
, и — hvala za vašo pomoč pri urejanju objave.
Kaj je CASE?
Odločil sem se, da pripravim čudovito okrajšavo, kot je ali . Jaz temu rečem metoda CASE. Opisuje štiri točke, na katere morate biti pozorni pri delu s samodejnim nadzorom:
- (vezano na kontekst)
- (praktična vrednost)
- (poudarek na simptomih)
- (razred)
Če uporabljate CASE, obravnavate obvestila z zdravo brezbrižnostjo in ne zbujate ljudi ponoči. Spremljanje je treba redno ocenjevati glede uporabnosti in učinkovitosti. Ko oseba prejme obvestilo, bo imela boljše mentalne modele in več samozavesti.
Da bi si lažje zapomnili, si predstavljajte, da potrebujete PRIMER [to je primer, razlog - opomba prevajalca] za utemeljitev vsakega opozorila. :sončna očala:
In zakaj je vse to?
. Iz večih razlogov. In CASE jih ne bo odstranil vseh. Toda z njim se boste ponoči zbujali ob boljših obvestilih. Ta metoda zajema različne organizacijske procese, ki bodo prav tako pomagali pri tej zadevi.
Lepota metod RED in USE je v tem, da z njuno pomočjo ne le znamo delati, ampak tudi drug z drugim govorimo isti jezik. Upam, da bo metoda CASE olajšala razpravo o obvestilih, ki ščitijo naše sisteme, a zaposlene naše kolege.
Bistvo je, da morate v svoji organizaciji ustvariti kulturo, kjer se obvestila obravnavajo zdravo brezbrižno. Obvestila se lahko ustvarijo za določen namen, vendar ni dejstvo, da kasneje ne bodo izgubila vrednosti. Zakaj smo nastavili to obvestilo? Kako dolgo nazaj so bila njegova merila revidirana? S CASE je mogoče odgovoriti na ta vprašanja.
Context-Heavy - kontekstna vezava
3 zjutraj ni najboljši čas za branje sporočil, ki vsebujejo veliko pametnih besed. Za učinkovit odziv potrebujete informacije. V idealnem primeru bi morale biti to informacije o določeni težavi, za katere je kontekst takoj jasen, obvestila pa bi morala biti konfigurirana tako, da je to mogoče. To je "opazovanje" in "usmerjanje" iz . Ni škoda porabiti časa za to nastavitev, saj je nenehno moteče človeka še dražje. Spoštujmo drug drugega.
Težave imajo veliko virov. Predvsem duhovi.
Kako lahko pomagam dežurnemu? Prva stvar, ki jo dežurni vidi, je obvestilo, zato na njegovi podlagi gradi vse hipoteze. Potem pogleda navodila in nadzorne plošče, a so vedno podatki o konkretnem obvestilu in ne samo splošni podatki? Alspaugh svetuje, da "razmislite o tem, kako bi lahko interpretirali obvestilo ali se nanj odzvali" (diapozitiv 29). Dobro obvestilo je osredotočeno na dežurno osebo in ne samo konfigurirano s pragom.
Tukaj je torej nekaj zamisli o tem, kako izboljšati kontekst obvestil:
- Pokažite uporabniku nekaj uporabnega in posebej ustvarjenega, ne le običajnih navodil ali nadzorne plošče. Pred tem smo fantje in jaz uporabljali preiskovalne nadzorne plošče, konfigurirane za posebna obvestila. To bo pomagalo, če je težava znana, druge pa bo le zmedlo. Tukaj moramo najti ravnotežje.
- Povejte nam o zgodovini obvestila: ali je novo? Ali pogosto deluje? Je sezonsko?
- Prikaži nedavne spremembe stanja sistema. Se je v zadnjem času kaj spremenilo? (Na primer funkcija uvajanja ali omogočanja/onemogočanja.)
- Pokažite razmerja in zagotovite informacije za miselni model: sistemske odvisnosti morajo biti jasno vidne, po možnosti z navedbo funkcionalnosti.
- Hitro povežite uporabnika z ekipo: ali lahko vidijo tekoče incidente ali lahko ugotovijo, kdo drug v podjetju je prejel obvestilo? Program aktiviran?
V idealnem primeru bo program upravljanja incidentov zagotovil nasvete o tem, kako izboljšati kontekst obveščanja o preiskavah incidentov. Vedno je nekaj za delati!
Uporabna - praktična vrednost
Ali naj dežurni kaj ukrene po obvestilu? Če vam ni treba storiti ničesar ali ni jasno, kaj storiti, zakaj ste ga zbudili? Izogibati se morate obvestilom, ki moti dežurne in ne zahtevajo ukrepanja.
Kaj naj naredim? Kaj hočeš?
V preteklosti, ko so bili sistemi preprosti in ekipe majhne, smo vzpostavili spremljanje samo zato, da smo na tekočem. Obvestilo, da se je obremenitev kopice povečalo, nam bo dalo kontekst, če storitev pozneje ne deluje pravilno. V velikem obsegu bodo takšna obvestila samo povzročila zmedo, saj naši sistemi vedno delujejo v stanju različno resnih poslabšanj. To hitro pripelje do in seveda do izgube občutljivosti. Zato dežurni taka obvestila ignorira ali celo filtrira in se nanje ne odzove vedno po potrebi. Ne ujemite se v to past! Ne nastavljajte vseh obvestil po vrsti in jih nato pošiljajte po e-pošti v neko od boga pozabljeno mapo.
Takole izgleda obvestilo s praktično vrednostjo:
- Obvestilo zahteva ukrepanje in ne samo poročanje novic.
- To dejanje je težko ali tvegano avtomatizirati. Če je dejanje mogoče avtomatizirati, ga avtomatizirajte, nehajte nadlegovati ljudi!
- Obvestilo vsebuje nujna priporočila v obrazcu (SLA) oz (RTO). Dežurni lahko nato aktivira program organizacije za obvladovanje incidentov.
Želim pojasniti: ne trdim, da morajo obvestila prihajati samo za najpomembnejše SLO (cilje na ravni storitev) za API. SLO monitoring je nenehno razdrobljen in razdeljen ter zahteva enak pristop do vseh storitev. Jasno je, da boste sledili najpomembnejšim SLO za stranke, ki vam plačujejo. Vendar je treba spremljati tudi infrastrukturne SLO, kot so baze podatkov. Kmalu se boste morali ukvarjati z notranjimi strankami in jih podpirati. In tako naprej v nedogled.
Temelji na simptomih – poudarek na simptomih
Če vam je všeč ali ne, delate v porazdeljenem sistemu (Kavaj). Posledično uporabljate različne taktike za izolacijo storitev in njihovo zaščito pred odpovedjo (Trainor et al.)3. In čeprav zakasnjeno zbiranje smeti ali zaustavljena poizvedba po bazi podatkov kaže na težave, ni treba hiteti z odpravljanjem, če uporabniki v bližnji prihodnosti ne bodo imeli težav.
To so pomembni signali in imajo lahko praktično vrednost, vendar če ne motijo uporabnikov, potem ni dovolj nujno, da bi motilo spremljevalca. Obvestila na podlagi vzroka so posnetki naših mentalnih modelov o okvari sistema. Bolje je slediti pomembnim simptomom, kot pa poskušati našteti vse možne vzroke okvare.
Da bodo obvestila smiselna, se osredotočite na , pomembna za uporabnike. Evashchuk to imenuje "spremljanje za uporabnike." Ne pozabite, da je treba to filozofijo uporabljati v celotni organizaciji. Če ima servis nekje globoko v infrastrukturi nujne težave, bo zanje poskrbela ustrezna ekipa. Zaščita sistemov pred takimi okvarami je povsem ločena zadeva (Trainer et al., razdelek o strategijah za zmanjšanje kritičnih odvisnosti).
Simptomi niso tako spremenljivi
Richard Cook nas opominja, da so kompleksni sistemi polni napak, pomanjkljivosti in težav. Našteti vse možne razloge je sizifovo opravilo. Poskušate opisati težave, a se ves čas spreminjajo. Cindy Sridharan meni, da "ni nujno, da so sistemi v popolnem stanju vsako sekundo" in da je bolje uporabiti bolj človeški pristop ( (»Spremljanje porazdeljenih sistemov«), 7).
Izogibajte se obvestilom po incidentu
Običajno so obvestila o vzrokih konfigurirana za odpravljanje incidentov. In ta omejena obvestila o dejstvu, kaj se je zgodilo, ustvarjajo lažen občutek varnosti, saj sistem vsakič najde nove načine za zlom.
Naj vas obvestila o vzrokih ne zavedejo. Raje pomisli:
- Zakaj obvestilo na podlagi simptomov ni opazilo težave?
- Ali bi bilo koristno izboljšati kontekst za uporabnika?
- Kako je mogoče izboljšati orodja za spremljanje, da bi hitreje postavili diagnozo, namesto da bi kopičili obvestila o tem, kaj se je zgodilo?
Orodja za spremljanje diagnoze bodo pomagala le, če boste o njih razmišljali kot o načinu za prehod od simptoma k rešitvi. Brez teh povratnih informacij boste preprosto bombardirani s poznimi obvestili in grafikoni o preteklih napakah – in niti besede o prihodnjih. To je odlična priložnost za organizacijo, da preide iz obrambe v napad. In razvijalci in vodje izdelkov bodo imeli enaka pričakovanja in jasne cilje. Za vsako obvestilo je velika velikost - CASE (:wink:) - jasna.
Obvestila na podlagi razloga so sprejemljiva v zmernih količinah
Včasih nam naš sistem ne pušča veliko izbire glede obvestil na podlagi vzroka. In včasih tisti, ki so na dolžnosti, dobro razumejo, da bo simptom zagotovo privedel do okvare, zato ima praktično vrednost. Morda preprosto niste prepričani, kaj se dogaja, in nastavljate obvestila, da bi bili na varni strani. Upajmo, da je ta ukrep začasen, dokler ne spremenimo sistema in odpravimo težavo z zmogljivostjo.
Ko se ukvarjate s temi situacijami, imejte v mislih druge komponente CASE. Samo zato, ker je začasno, ne pomeni, da lahko nehate razmišljati s svojo glavo.
Ocenjeno – ocena
Vsaka sprememba sistema (nova koda, nova infrastruktura, karkoli novega) razširi obseg napak (Cook, 3). Ali to obvestilo še vedno deluje po pričakovanjih? Jasni in trenutni miselni modeli sistemov in izkušnje z odzivom na nekatera obvestila podpore - to so ključne lastnosti . Napake v sistemih se nenehno razvijajo in moramo jim slediti.
Nenehno morate ocenjevati kakovost vsakega obvestila, da zagotovite, da deluje po pričakovanjih. Spoštovani voditelji! Za vaše ekipe bo veliko lažje, če jim boste pomagali vzpostaviti ta proces! Tukaj je nekaj idej za ocenjevanje:
- Uporabi , ali druge metode testiranja obvestil. Ekipa lahko to stori sama, ne da bi se morala zanašati na težki sistem upravljanja incidentov!
- Zbiranje vseh obvestil, povezanih z incidenti, vključite v svoj program upravljanja incidentov. Označite kot koristno, škodljivo, neprimerno, nejasno itd. Uporabite jih kot povratno informacijo.
- Prava obvestila se sprožijo redko in so skrbno testirana. Prepričajte se, da vse povezave delujejo, kažejo na pravi kontekst itd.
- Če se obvestilo nikoli ne sproži ali se sproži prepogosto, je z njim nekaj narobe. Popravite ali odstranite. Pazite se pretirane pasivnosti ali aktivnosti!
- Nastavite časovne žige obvestil z datumi poteka. Če je datum poteka potekel, ovrednotite obvestilo z metodo CASE in posodobite časovni žig. Tako kot pri živilih redno preverjajte rok uporabnosti.
- Poenostavite postopek izboljšanja obvestil. Uporabite spremljanje kot kodo in shranite obvestila v repozitorij Git. Zahteve za vleko pomagajo vključiti ekipo in vam nudijo zgodovino preteklih obvestil. In ne bo vas več strah spreminjati obvestil ali vprašati za dovoljenje odgovornih zanje.
- Nastavite povratne informacije za obvestila, tudi če so preproste , tako da dežurni obvestila označijo za nekoristna ali vsiljiva. V samo obvestilo vdelajte povezavo ali poziv k dejanju in redno pregledujte povratne informacije.
- Vzpostavite pravilo v ekipi - naj delajo dežurni, da poenostavijo dežurstvo, ko je dela malo. Naj bo za vami vse malo bolje, kot je bilo prej.
Zaključek
Menim, da metoda CASE razvijalcem in organizacijam pomaga razpravljati o nastavitvi in pošiljanju samodejnih obvestil. En razvijalec lahko začne ocenjevati obvestila z metodo CASE, nato pa se bo celotna organizacija pridružila drugim razvijalcem, upravljavcem in programom za upravljanje incidentov, da bodo obvestila v dobri formi. To ne zahteva posebnih orodij ali zapletenih postopkov.
Celotna industrija mora razmišljati o človeškem dejavniku med opravljanjem dela, ne da bi žrtvovala vrhunske storitve za stranke. Vsa ta orodja in prakse je mogoče in treba izboljšati. Upam, da bo metoda CASE pri tem pomagala.
Uživajte v izboljšanih obvestilih!
Vir: www.habr.com