Zzzziiiiiing! Na satu su 3 ujutro, sanjate divne snove, i iznenada — zvono. Ove sedmice imate dežurstvo, i očito se nešto dogodilo. Automatizirani sustav poziva vas da istražite u čemu je problem. Ovo je važan trenutak upravljanja modernim računalnim sustavima, ali hajde da vidimo kako učiniti obavijesti prikladnijima za ljude.
Upoznajte se s filozofijom monitoringa, koja je rođena tijekom nekoliko desetljeća mojih dežurstava u različitim timovima za monitoring. Na nju je uvelike utjecala prava biblija od Roba Evaschuka (Moja filozofija obavijesti), uključena u knjigu o , i knjiga Johna Allspoua (Razmatranja o postavkama obavijesti).
, i — hvala na pomoći u uređivanju posta.
Što je CASE?
Odlučio sam smisliti lijepu akronim, kao kod ili Zovem to metod CASE. Opisuje četiri aspekta na koje treba obratiti pažnju prilikom rada s automatskim monitoringom:
- (vezano uz kontekst)
- (praktična vrijednost)
- (fokus na simptome)
- (evaluacija)
Ako koristite CASE, prema obavijestima se odnosite s zdravim indolentnim stavom i ne budite ljude noću. Treba redovito ocjenjivati monitoring zbog korisnosti i učinkovitosti. Kada osoba primi obavijest, njezini mentalni modeli će biti bolji i više povjerljivi.
Da bi bilo lakše zapamtiti, zamislite da vam treba CASE [znači slučaj, razlog — napomena prevoditelja], kako biste opravdali svaku obavijest. :sunglasses:
I zašto to sve?
. Iz više razloga. I CASE neće ukloniti sve. Ali s njim noću ćete se buditi od kvalitetnijih obavijesti. Ova metoda obuhvaća različite organizacijske procese koji također pomažu u ovom poslu.
Lijepota metoda RED i USE leži u tome što ne samo da znamo kako raditi, već i komuniciramo jedni s drugima istim jezikom. Nadam se da će s metodom CASE biti lakše raspravljati o obavijestima koje štite naše sustave, ali ne daju mira kolegama.
Suština je u tome da treba stvoriti kulturu unutar organizacije u kojoj se obaveštenjima pristupa s dozom zdravog nebriga. Obaveštenja mogu biti relevantna, ali nije sigurno da će im kasnije vrednost opasti. Zašto smo postavili ovo obaveštenje? Kada su poslednji put preispitani njegovi kriterijumi? Uz CASE možemo pronaći odgovore na ova pitanja.
Težak kontekst — vezanost za kontekst
3 ujutro — nije najbolje vreme za čitanje poruka koje sadrže mnogo pametnih reči. Da bi se efikasno reagovalo, potrebne su informacije. U idealnom slučaju to bi trebale biti informacije o konkretnom problemu, gde je kontekst odmah jasan, i treba prilagoditi obaveštenja tako da to bude moguće. Ovo je "posmatranje" i "orijentacija" iz . Nije žalosno potrošiti vreme na ovu prilagodbu, jer konstantno ometanje osobe košta još više. Poštujmo jedni druge.
Problemi imaju mnogo izvora. Osobito su to duhovi.
Kako pomoći dežurnom? Prvo što dežurni vidi je obaveštenje, zato sve hipoteze gradi na njegovoj osnovi. Zatim gleda upute i nadzorne panele, ali da li su uvek dostupni podaci za konkretno obaveštenje, a ne samo opšte informacije? Olspo savetuju "razmišljati o tome kako se može interpretirati obaveštenje ili reagovati na njega" (slajd 29). Dobre obaveštenje je orijentirano na dežurnog, a ne samo postavljeno po pragovnim vrednostima.
Zato su ovde ideje kako poboljšati kontekst obaveštenja:
- Pokažite korisniku nešto korisno i posebno izrađeno, a ne samo standardne upute ili nadzorne panele. Ranije smo sa tim ljudima koristili nadzorne panele za istraživanje, prilagođene konkretnim obaveštenjima. To će pomoći ako je problem poznat, a samo će zbuniti u drugim slučajevima. Ovde treba pronaći ravnotežu.
- Ispričajte priču o obaveštenju: je li novo? Često se događa? Sezonsko je?
- Pokažite nedavne promene u stanju sistema. Da li se nešto nedavno promenilo? (Na primer, implementacija ili uključivanje/isključivanje funkcionalnosti.)
- Pokažite međuzavisnosti i pružite informacije za mentalni model: zavisnosti sistema trebaju biti jasno vidljive, poželjno sa naznakom funkcionalnosti.
- Brzo povežite korisnika s timom: vide li trenutne incidente ili mogu saznati tko je još u firmi primio obaveštenje? Program aktivirana?
Idealan program za upravljanje incidentima pruža savjete o tome kako poboljšati kontekst obavijesti tijekom istraživanja incidenata. Ovdje uvijek postoji nešto na čemu se može raditi!
Akcijski — praktična vrijednost
Treba li dežurni nešto učiniti kao odgovor na obavijest? Ako se ništa ne treba raditi ili nije jasno što raditi, zašto su budili? Treba izbjegavati obavijesti koje uzrujavaju dežurne i ne zahtijevaju akciju.
Što učiniti? Što je potrebno?
Nekada, kada su sustavi bili jednostavni, a timovi mali, postavljali smo monitoring samo da bismo bili u toku. Obavijest da je opterećenje na hrpi poraslo pružit će nam kontekst ako usluga kasnije bude imala problema. Na velikoj razini takve obavijesti samo će zbuniti, jer naši sustavi uvijek rade u stanju raznolike degradacije. To brzo dovodi do i, naravno, do gubitka osjetljivosti. Zato dežurni ignorira ili čak filtrira takve obavijesti i ne reagira uvijek na njih onako kako bi trebalo. Ne upadajte u ovu zamku! Nemojte postavljati sve obavijesti bez razmišljanja, da biste ih kasnije slali na e-mail u neku zaboravljenu mapu.
Ovako izgleda obavijest s praktičnom vrijednošću:
- Obavijest zahtijeva akciju, a ne samo javljaju novosti.
- Ova akcija je teška ili riskantna za automatizaciju. Ako se akcija može automatizirati, onda je jednostavno automatizirajte, prestanite zadavati ljudima!
- Obavijest sadrži hitne preporuke u obliku (SLA) ili (RTO). Tada dežurni može uključiti program za upravljanje incidentima unutar organizacije.
Želim naglasiti: ne kažem da obavijesti trebaju dolaziti samo za najvažnije SLO (ciljevi razine usluge) za API. Monitoring SLO neprestano se dijeli i zahtijeva isti pristup za sve usluge. Jasno je da ćete pratiti najvažnije SLO za klijente koji vam plaćaju. No, SLO infrastrukture, poput baza podataka, također treba pratiti. Uskoro ćete se morati baviti unutarnjim klijentima i podržavati ih. I tako do beskonačnosti.
Simptomatski — fokus na simptome
Sviđa li vam se to ili ne, ali radite u distribuiranom sustavu (Kawaj). Kao rezultat toga, koristite različite taktike kako biste izolirali usluge i zaštitili ih od kvarova (Treynor i dr.) 3. Iako dugotrajno prikupljanje smeća ili zagušeni upit prema bazi podataka ukazuju na probleme, ne trebate žuriti s njihovim rješavanjem ako korisnicima u bliskoj budućnosti ne bude stvoreno problema.
To su važni signali i mogu imati praktičnu vrijednost, no ako ne ometaju korisnike, to nije toliko hitno da bi skrenulo pozornost operatera. Obavijesti temeljene na uzrocima su preslikane naše mentalne slike o sistemskom kvaru. Bolje je pratiti važne simptome nego pokušavati nabrojati sve moguće uzroke kvara.
Da bi obavijesti imale praktičnu vrijednost, usredotočite se na , koji su važni za korisnike. Evashchuk to naziva „monitoring za korisnike“. Zapamtite da ovu filozofiju trebate primijeniti širom organizacije. Ako se u servisu negdje unutar infrastrukture jave hitni problemi, njima će se pozabaviti odgovarajući tim. Zaštita sustava od takvih kvarova je potpuno drugačija tema (Treynor i dr., odjeljak o strategijama za minimiziranje kritičnih ovisnosti).
Simptomi nisu tako promjenljivi
Richard Cook podsjeća da u složenim sustavima ima bezbroj mana, nedostataka i problema. Pokušavati nabrojati sve moguće uzroke je Sizičev rad. Pokušavate opisivati probleme, a oni se neprestano mijenjaju. Cindy Sridharan smatra da „sustavi ne moraju nužno biti u savršenom stanju svake sekunde“ i bolje je koristiti više ljudski pristup ( („Promatranje distribuiranih sustava“), 7).
Izbjegavajte obavijesti temeljene na incidentima
Uglavnom se za rješavanje incidenata postavljaju obavijesti o uzrocima. Ova ograničena obavijest o događaju stvara lažni osjećaj sigurnosti jer sustav svaki put pronalazi nove načine da se slomi.
Ne zavaravajte se obavijestima o uzrocima. Bolje razmislite:
- Zašto obavijest temeljena na simptomima nije primijetila problem?
- Hoće li poboljšanje konteksta koristiti korisniku?
- Kako poboljšati alate za nadzor kako bismo brže postavili dijagnozu, umjesto da akumuliramo obavijesti o onome što se dogodilo?
Alati za nadzor za dijagnostiku bit će korisni samo ako ih shvatite kao način prijelaza od simptoma do rješenja. Bez povratnih informacija, jednostavno ćete biti zatrpani zakašnjelim obavijestima i dijagramima o prošlim kvarovima — i ni riječi o budućim. Za subjekt je ovo odlična prilika da pređe iz obrane u napad. A razvojni timovi i menadžeri proizvoda imat će jednake očekivanja i jasne ciljeve. Slučaj — CASE (:wink:) — za svaku obavijest je jasan.
Obavijesti na temelju uzroka su podnošljive u umjerenim količinama.
Ponekad naš sustav gotovo da ne ostavlja izbora u pogledu obavijesti na temelju uzroka. A ponekad dežurni savršeno razumiju da simptom nužno vodi do kvara, što znači da ima praktičnu vrijednost. Možda niste sigurni što se događa i postavljate obavijesti radi opreza. Nadamo se da je taj korak privremen, dok ne promijenimo sustav kako bismo riješili problem smanjenja performansi.
Sjetite se drugih komponenti CASE-a kada se bavite takvim situacijama. Ako je to privremeno, ne znači da ne trebate koristiti zdrav razum.
Evaluated — evaluacija
Svaka promjena u sustavu (novi kod, nova infrastruktura, ma što novo) povećava mogućnosti kvarova (Cook, 3). Radi li ova obavijest još uvijek onako kako se očekuje? Jasni i ažurirani mentalni modeli sustava i iskustva reagiranja na određene obavijesti podržavaju — ključne su karakteristike Defekti u sustavima se neprekidno razvijaju i trebamo biti u korak s njima.
Moramo stalno evaluirati kvalitetu svake obavijesti kako bi funkcionirale onako kako se očekuje. Cijenjeni lideri! Vašim timovima će biti mnogo lakše ako im pomognete da uspostave ovaj proces! Evo nekoliko ideja za evaluaciju:
- Koristite , ili druge metode testiranja obavijesti. Tim to može učiniti samostalno, bez uključivanja teškog sustava upravljanja incidentima!
- Uključite prikupljanje podataka o svim obavijestima vezanim za incidente u program za upravljanje incidentima. Označite korisne, štetne, neprikladne, nejasne itd. Iskoristite ih kao povratnu informaciju.
- Ispravne obavijesti se rijetko pokreću i pažljivo su provjerene. Provjerite da svi linkovi rade i upućuju na odgovarajući kontekst itd.
- Ako obavijest nikada ne funkcioniše ili se prečesto aktivira, s njom nešto nije u redu. Popravite je ili je uklonite. Pazite se prekomjernog pasivnog ili aktivnog pristupa!
- Postavite vremenske oznake za obavijesti sa rokom trajanja. Kada istekne rok trajanja, procijenite obavijest metodom CASE i ažurirajte vremensku oznaku. Redovito provjeravajte rok trajanja, poput hrane.
- P pojednostavite proces poboljšanja obavijesti. Koristite praćenje putem koda i pohranite obavijesti u Git repozitorij. Pull zahtjevi pomažu angažirati tim, a vi ćete imati historiju prethodnih obavijesti. I prestanete se bojati mijenjati obavijesti ili tražiti dopuštenje od onih koji su za njih odgovorni.
- Uspostavite povratne informacije za obavijesti, čak i ako je to samo , kako bi dežurni označili obavijesti kao beskorisne ili nametljive. Ugradite link ili poziv na akciju u samu obavijest i redovito pregledavajte povratne informacije.
- Postavite pravilo u timu - neka dežurni rade na pojednostavljenju dežurstva kada je malo posla. Neka nakon vas sve postane malo bolje nego što je bilo.
Zaključak
Mislite da metoda CASE pomaže programerima i organizacijama da raspravljaju o postavkama i slanju automatskih obavijesti. Jedan programer može početi procjenjivati obavijesti metodom CASE, a zatim se pridružiti cijela organizacija s drugim programerima, vodstvom i programima za upravljanje incidentima kako bi održavali obavijesti u dobrom stanju. Za to nisu potrebni nikakvi posebni alati ili složeni procesi.
Cijela industrija treba razmisliti o ljudskom faktoru tijekom dežurstva bez ugrožavanja vrhunske usluge za korisnike. Svi ovi alati i prakse mogu se i trebaju poboljšati. Nadam se da će metoda CASE pomoći u tome.
Uživajte u unaprijeđenim obavijestima!
Izvor: habr.com
