Dziiiiin! Është ora 3 e mëngjesit, po shihni një ëndërr të mrekullueshme dhe befas ka një telefonatë. Ju jeni në detyrë këtë javë dhe me sa duket diçka ka ndodhur. Sistemi i automatizuar telefonon për të zbuluar se çfarë nuk shkon. Ky është një aspekt i rëndësishëm i menaxhimit të sistemeve kompjuterike moderne, por le të shohim se si t'i bëjmë njoftimet më të mira për njerëzit.
Njihuni me filozofinë e monitorimit, e lindur gjatë disa dekadave të detyrave të mia në ekipe të ndryshme monitorimi. Ajo u ndikua kryesisht nga bibla e vërtetë nga Rob Evashchuk (My Notification Filosophy) përfshirë në librin mbi , dhe libër nga John Alspaugh (Shënime për konfigurimin e sinjalizimeve).
, и — faleminderit për ndihmën tuaj në redaktimin e postimit.
Çfarë është CASE?
Vendosa të krijoj një shkurtesë të bukur si ose . Unë e quaj atë Metoda CASE. Ai përshkruan katër pika që duhet t'i kushtoni vëmendje kur punoni me monitorimin automatik:
- (i lidhur me kontekstin)
- (vlera praktike)
- (theksi tek simptomat)
- (gradë)
Nëse përdorni CASE, ju i trajtoni njoftimet me një indiferencë të shëndetshme dhe nuk i zgjoni njerëzit gjatë natës. Monitorimi duhet të vlerësohet rregullisht për dobinë dhe efektivitetin. Kur një person merr njoftimin, ai do të ketë modele më të mira mendore dhe më shumë besim.
Për ta bërë më të lehtë të mbani mend, imagjinoni se keni nevojë për një RAST [d.m.th., një rast, një arsye - shënimi i përkthyesit] për të justifikuar çdo alarm. :syze dielli:
Dhe pse është e gjithë kjo?
. Për shumë arsye. Dhe CASE nuk do t'i eliminojë të gjitha. Por me të, do të zgjoheni natën për njoftime më të mira. Kjo metodë mbulon procese të ndryshme organizative që do të ndihmojnë gjithashtu në këtë çështje.
E bukura e metodave RED dhe USE është se me ndihmën e tyre jo vetëm dimë të punojmë, por flasim edhe të njëjtën gjuhë me njëri-tjetrin. Shpresoj se metoda CASE do ta bëjë më të lehtë diskutimin e njoftimeve që mbrojnë sistemet tona, por që i mbajnë të zënë kolegët tanë.
Çështja është se ju duhet të krijoni një kulturë në organizatën tuaj ku njoftimet trajtohen me një indiferencë të shëndetshme. Njoftimet mund të krijohen për një qëllim të caktuar, por nuk është fakt që ato nuk do të humbasin vlerën më vonë. Pse e konfiguruam këtë njoftim? Sa kohë më parë janë rishikuar kriteret e saj? Me CASE, këto pyetje mund të marrin përgjigje.
Context-Heavy - lidhje e kontekstit
Ora 3 e mëngjesit nuk është koha më e mirë për të lexuar mesazhe që përmbajnë shumë fjalë të zgjuara. Për t'u përgjigjur në mënyrë efektive, keni nevojë për informacion. Idealisht, ky duhet të jetë informacion për një çështje specifike, për të cilën konteksti është menjëherë i qartë dhe njoftimet duhet të konfigurohen në mënyrë që kjo të jetë e mundur. Ky është "vëzhgim" dhe "orientim" nga . Nuk është turp të shpenzosh kohë në këtë organizim, sepse shpërqendrimi i vazhdueshëm i një personi është edhe më i shtrenjtë. Le të respektojmë njëri-tjetrin.
Problemet kanë shumë burime. Sidomos fantazmat.
Si mund ta ndihmoj oficerin e shërbimit? Gjëja e parë që sheh nëpunësi është një njoftim, kështu që ai ndërton të gjitha hipotezat mbi bazën e tij. Pastaj ai shikon udhëzimet dhe tabelat, por a ka gjithmonë të dhëna për një njoftim specifik, dhe jo vetëm informacione të përgjithshme? Alspaugh këshillon "të mendoni se si mund ta interpretoni ose t'i përgjigjeni njoftimit" (rrëshqitje 29). Një njoftim i mirë përqendrohet te personi në detyrë, jo vetëm i konfiguruar nga një prag.
Pra, këtu janë disa ide se si të përmirësoni kontekstin e njoftimeve:
- Tregoji përdoruesit diçka të dobishme dhe të krijuar posaçërisht, dhe jo thjesht udhëzime të zakonshme ose një panel. Më parë, djemtë dhe unë përdorëm panele hetimore të konfiguruara për njoftime specifike. Kjo do të ndihmojë nëse problemi dihet, por vetëm do t'i ngatërrojë të tjerët. Këtu duhet të gjejmë një ekuilibër.
- Na tregoni për historinë e njoftimit: a është i ri? A funksionon shpesh? A është sezonale?
- Trego ndryshimet e fundit në gjendjen e sistemit. A ka ndryshuar ndonjë gjë kohët e fundit? (Për shembull, vendosja ose aktivizimi/çaktivizimi i funksionalitetit.)
- Tregoni marrëdhëniet dhe jepni informacion për modelin mendor: varësitë e sistemit duhet të jenë qartë të dukshme, mundësisht me një tregues të funksionalitetit.
- Lidhni shpejt përdoruesin me ekipin: a mund të shohin incidente në vazhdim apo mund të zbulojnë se kush tjetër në kompani ka marrë një njoftim? Programi aktivizuar?
Në mënyrë ideale, një program i menaxhimit të incidentit do të ofrojë këshilla se si të përmirësohet konteksti i njoftimit të hetimeve të incidentit. Gjithmonë ka diçka për të punuar!
Vepruese - vlerë praktike
A duhet të bëjë oficeri i detyrës diçka në përgjigje të njoftimit? Nëse nuk keni nevojë të bëni asgjë ose nuk është e qartë se çfarë të bëni, pse e zgjuat atë? Duhet të shmangni njoftimet që i bezdisin ata që janë në detyrë dhe nuk kërkojnë veprim.
Cfare duhet te bej? cfare deshironi?
Në të kaluarën, kur sistemet ishin të thjeshta dhe ekipet ishin të vogla, ne vendosëm monitorimin vetëm për të qëndruar në krye të gjërave. Njoftimi se ngarkesa në grumbull është rritur do të na japë kontekst nëse shërbimi më pas keqfunksionon. Në një shkallë të gjerë, njoftime të tilla do të krijojnë vetëm konfuzion sepse sistemet tona funksionojnë gjithmonë në një gjendje degradimi me ashpërsi të ndryshme. Kjo shpejt çon në dhe, natyrisht, në humbjen e ndjeshmërisë. Prandaj, punonjësi i shërbimit injoron apo edhe filtron njoftime të tilla dhe jo gjithmonë u përgjigjet atyre sipas nevojës. Mos bini në këtë kurth! Mos i konfiguroni të gjitha njoftimet me radhë dhe më pas dërgojini ato me email në ndonjë dosje të braktisur.
Ja se si duket një njoftim me vlerë praktike:
- Një njoftim kërkon veprim dhe jo thjesht raportim të lajmeve.
- Ky veprim është i vështirë ose i rrezikshëm për t'u automatizuar. Nëse një veprim mund të automatizohet, atëherë automatizoni atë, ndaloni të bezdisni njerëzit!
- Njoftimi përmban rekomandime urgjente në formular (SLA) ose (RTO). Oficeri i detyrës më pas mund të aktivizojë programin e menaxhimit të incidenteve të organizatës.
Dua të sqaroj: nuk po them që njoftimet duhet të vijnë vetëm për SLO-të më të rëndësishme (objektivat e nivelit të shërbimit) për API-në. Monitorimi i SLO është vazhdimisht i fragmentuar dhe i ndarë dhe kërkon të njëjtën qasje për të gjitha shërbimet. Është e qartë se ju do të gjurmoni SLO-të më të rëndësishme për klientët që ju paguajnë. Por SLO-të e infrastrukturës, të tilla si bazat e të dhënave, gjithashtu duhet të monitorohen. Së shpejti do t'ju duhet të merreni me klientët e brendshëm dhe t'i mbështesni ata. Dhe kështu me radhë ad infinitum.
Bazuar në simptoma - theksi mbi simptomat
Ju pëlqen apo s’dueni, jeni duke punuar në një sistem të shpërndarë (Kavaj). Si rezultat, ju përdorni taktika të ndryshme për të izoluar shërbimet dhe për t'i mbrojtur ato nga dështimi (Trainor et al.)3. Dhe megjithëse një mbledhje e vonuar e mbeturinave ose një pyetje e ngecur në bazën e të dhënave tregon probleme, nuk ka nevojë të nxitoni për t'i rregulluar ato nëse përdoruesit nuk kanë probleme në të ardhmen e afërt.
Këto janë sinjale të rëndësishme dhe mund të kenë vlerë praktike, por nëse nuk shqetësojnë përdoruesit, atëherë nuk është mjaft urgjente për të shpërqendruar shoqëruesin. Njoftimet e bazuara në shkak janë fotografi të modeleve tona mendore për një dështim të sistemit. Është më mirë të gjurmoni simptoma të rëndësishme sesa të përpiqeni të renditni të gjitha shkaqet e mundshme të një dështimi.
Për t'i bërë njoftimet kuptimplote, përqendrohuni te , e rëndësishme për përdoruesit. Evashchuk e quan këtë "monitorim për përdoruesit". Mos harroni se kjo filozofi duhet të zbatohet në të gjithë organizatën. Nëse një shërbim ka probleme urgjente diku thellë në infrastrukturë, ekipi përkatës do të kujdeset për to. Mbrojtja e sistemeve nga dështime të tilla është një çështje krejtësisht e veçantë (Trainer et al., seksioni mbi strategjitë për minimizimin e varësive kritike).
Simptomat nuk janë aq të ndryshueshme
Richard Cook na kujton se sistemet komplekse janë plot me të meta, mangësi dhe probleme. Përpjekja për të renditur të gjitha arsyet e mundshme është një detyrë sizifiane. Ju përpiqeni të përshkruani problemet, por ato ndryshojnë gjatë gjithë kohës. Cindy Sridharan beson se "sistemet nuk duhet të jenë në gjendje të përsosur çdo sekondë" dhe është më mirë të përdoret një qasje më njerëzore ( ("Monitorimi i sistemeve të shpërndara"), 7).
Shmangni njoftimet pas një incidenti
Në mënyrë tipike, njoftimet për shkaqet konfigurohen për të korrigjuar incidentet. Dhe këto njoftime të kufizuara për faktin e asaj që ndodhi krijojnë një ndjenjë të rreme sigurie, sepse sistemi çdo herë del me mënyra të reja për t'u thyer.
Mos u mashtroni nga njoftimet për shkak. Më mirë mendoni:
- Pse njoftimi i bazuar në simptoma nuk e vuri re problemin?
- A do të ishte e dobishme të përmirësohej konteksti për përdoruesin?
- Si mund të përmirësohen mjetet e monitorimit për të bërë një diagnozë më të shpejtë, në vend që të grumbullojnë njoftime për atë që ka ndodhur?
Mjetet e monitorimit për diagnozën do të ndihmojnë vetëm nëse i mendoni ato si një mënyrë për të kaluar nga simptoma në zgjidhje. Pa këtë reagim, thjesht do të bombardoheni me njoftime të vonuara dhe tabela për dështimet e kaluara - dhe asnjë fjalë për dështimet e së ardhmes. Kjo është një mundësi e shkëlqyer për një organizatë që të kalojë nga mbrojtja në sulm. Dhe zhvilluesit dhe menaxherët e produkteve do të kenë të njëjtat pritshmëri dhe qëllime të qarta. Rasti - RAST (:wink:) - është i qartë për çdo njoftim.
Njoftimet e bazuara në arsye janë të tolerueshme në moderim
Ndonjëherë sistemi ynë na lë pak zgjedhje për sa i përket njoftimeve të bazuara në shkak. Dhe ndonjëherë ata që janë në detyrë e kuptojnë shumë mirë se një simptomë do të çojë patjetër në një dështim, dhe për këtë arsye përmban vlerë praktike. Ndoshta thjesht nuk jeni i sigurt se çfarë po ndodh dhe po konfiguroni njoftimet për të qenë në anën e sigurt. Shpresojmë që ky veprim të jetë i përkohshëm derisa të mund ta ndryshojmë sistemin për të zgjidhur problemin e performancës.
Mbani parasysh komponentët e tjerë të CASE kur merreni me këto situata. Vetëm për shkak se është e përkohshme nuk do të thotë që ju mund të ndaloni së menduari me kokën tuaj.
Vlerësuar - vlerësim
Çdo ndryshim në sistem (kodi i ri, infrastrukturë e re, çdo gjë e re) zgjeron gamën e dështimeve (Cook, 3). A funksionon ende ky njoftim siç pritej? Modele të qarta dhe aktuale mendore të sistemeve dhe përvojë për t'iu përgjigjur disa njoftimeve mbështetëse - këto janë karakteristikat kryesore . Defektet në sisteme janë vazhdimisht në zhvillim, dhe ne duhet të vazhdojmë me to.
Ju duhet të vlerësoni vazhdimisht cilësinë e çdo njoftimi për t'u siguruar që ato funksionojnë siç pritej. Të dashur udhëheqës! Do të jetë shumë më e lehtë për ekipet tuaja nëse i ndihmoni të vendosin këtë proces! Këtu janë disa ide vlerësimi:
- përdorim , ose metoda të tjera të testimit të njoftimit. Ekipi mund ta bëjë vetë pa pasur nevojë të mbështetet në një sistem të rëndë të menaxhimit të incidenteve!
- Përfshini koleksionin e të gjitha njoftimeve të lidhura me incidentin në programin tuaj të menaxhimit të incidentit. Shënoni të dobishme, të dëmshme, të papërshtatshme, të paqarta, etj. Përdorini ato si reagime.
- Njoftimet e duhura aktivizohen rrallë dhe testohen me kujdes. Sigurohuni që të gjitha lidhjet të funksionojnë, të tregojnë kontekstin e duhur, etj.
- Nëse një njoftim nuk ndizet kurrë ose ndizet shumë shpesh, ka diçka që nuk shkon me të. Rregulloni ose hiqni atë. Kujdes nga pasiviteti apo aktiviteti i tepruar!
- Vendosni vulat kohore të njoftimeve me datat e skadimit. Nëse data e skadimit ka skaduar, vlerësoni njoftimin duke përdorur metodën CASE dhe përditësoni vulën kohore. Ashtu si ushqimi, kontrolloni rregullisht datën e skadencës.
- Thjeshtoni procesin e përmirësimit të njoftimeve. Përdorni monitorimin si kod dhe ruani njoftimet në një depo Git. Kërkesat e tërheqjes ndihmojnë në angazhimin e ekipit dhe ju japin një histori të njoftimeve të kaluara. Dhe nuk do të keni më frikë të ndryshoni njoftimet ose të kërkoni leje nga ata që janë përgjegjës për to.
- Konfiguro komentet për njoftimet, edhe nëse është e thjeshtë , në mënyrë që oficerët e shërbimit të shënojnë njoftimet si të padobishme ose ndërhyrëse. Vendosni një lidhje ose thirrje për veprim në vetë njoftimin dhe rishikoni rregullisht komentet tuaja.
- Vendosni një rregull në ekip - lërini ata që janë në detyrë të punojnë për të thjeshtuar detyrën kur ka pak punë. Çdo gjë pas teje le të jetë pak më mirë se më parë.
Përfundim
Unë besoj se metoda CASE i ndihmon zhvilluesit dhe organizatat të diskutojnë konfigurimin dhe dërgimin e njoftimeve të automatizuara. Një zhvillues mund të fillojë të vlerësojë njoftimet duke përdorur metodën CASE dhe më pas e gjithë organizata do të bashkohet me zhvilluesit e tjerë, programet e menaxhimit dhe menaxhimit të incidenteve për t'i mbajtur njoftimet në gjendje të mirë. Kjo nuk kërkon ndonjë mjet të veçantë ose procese komplekse.
E gjithë industria duhet të mendojë për faktorin njerëzor gjatë detyrës pa sakrifikuar shërbimin e nivelit të lartë ndaj klientit. Të gjitha këto mjete dhe praktika mund dhe duhet të përmirësohen. Shpresoj se metoda CASE do të ndihmojë me këtë.
Shijoni njoftimet e përmirësuara!
Burimi: www.habr.com