Ding! Është ora 3 e mëngjesit, po shihni një ëndërr të mrekullueshme dhe papritmas – një telefonatë. Këtë javë jeni në rolin e ndihmësit dhe duket se ka ndodhur diçka. Sistemi automatizuar po thërret për të sqaruar çfarë ka ndodhur. Ky është një moment i rëndësishëm në menaxhimin e sistemeve të kompjuterëve modernë, por le të shohim se si t’i bëjmë njoftimet më të rehatshme për njerëzit.
Njoftohuni me filozofinë e monitorimit, e lindur nga disa dekada ndihme në ekipet e ndryshme të monitorimit. Ajo është ndikuar shumë nga bibla e vërtetë e Rob Evashukut (Filozofia ime mbi njoftimet), e përfshirë në librin mbi , dhe libri i Jon Olshpës (Konsiderata për konfigurimin e njoftimeve).
, dhe — faleminderit për ndihmën në redaktimin e postit.
Çfarë është CASE?
Kam vendosur të krijoj një akronim të bukur, si ose . E quaj këtë metoda CASE. Ajo përshkruan katër pika që duhet të kenë parasysh kur punoni me monitorimin automatizuar:
- (ngjitur me kontekstin)
- (vlera praktike)
- (theksi në simptoma)
- (vlerësim)
Nëse përdorni CASE, e shikoni njoftimin me një cinizëm të shëndoshë dhe nuk i zgjoheni njerëzit në mes të natës. Duhet të vlerësoni rregullisht monitorimin për dobishmëri dhe efikasitet. Kur një person merr një njoftim, ai do të ketë modele mendore më të mira dhe më shumë besim.
Për ta bërë më të lehtë për t'u mbajtur mend, imagjinoni se ju nevojitet një CASE [dmth, një rast, arsye — shqip. përkthyesi], për të justifikuar çdo njoftim. :sunglasses:
Dhe përse e gjithë kjo?
. Për shumë arsye. Dhe CASE nuk do të eliminojë të gjitha ato. Por me të, gjatë natës do të zgjohemi nga njoftime më të mira. Kjo metodë përfshin procese të ndryshme organizative që gjithashtu do të ndihmojnë në këtë çështje.
Kënga e metodave RED dhe USE është se me ndihmën e tyre ne jo vetëm që dimë se si të punojmë, por gjithashtu flasim me njëri-tjetrin në një gjuhë të përbashkët. Shpresoj se me metodën CASE do të jetë më e lehtë të diskutojmë për njoftimet që mbrojnë sistemet tona, por që nuk e lënë qetësinë kolegëve.
The essence is that we need to create a culture in the organization where notifications are treated with a healthy indifference. Notifications may be created for a reason, but it's not guaranteed that they won't lose their value later. Why did we set up this notification? How long has its criteria been reviewed? With CASE, answers to these questions can be found.
Context-Heavy — context binding
3 a.m. is not the best time to read messages filled with complex vocabulary. To respond effectively, information is needed. Ideally, this should be information about a specific problem where the context is immediately clear, and notifications should be configured to allow for that. This is the "observation" and "orientation" from . This configuration is worth the time spent because constantly distracting a person is even more costly. Let's respect each other.
Problems have many sources. Especially ghosts.
How can we assist the on-duty staff? First of all, the on-duty staff sees the notification, so they base all their hypotheses on it. Then they look at instructions and dashboards, but is there always data regarding the specific notification, rather than just general information? Olspo advises to 'think about how to interpret the notification or react to it' (slide 29). A good notification is focused on the on-duty staff, not just set by a threshold value.
Therefore, here are some ideas on how to improve the context of notifications:
- Show the user something useful and purposefully created, not just generic instructions or a dashboard. Previously, we used dashboards for investigations that were tailored to specific notifications. This helps if the problem is known and only confuses in other cases. Finding a balance here is essential.
- Provide the history of the notification: is it new? Does it trigger frequently? Is it seasonal?
- Show recent changes in system status. Has anything changed recently? (For example, a deployment or enabling/disabling functionality.)
- Provide relationships and give information for a mental model: system dependencies should be clearly visible, ideally indicating their operability.
- Quickly connect the user to the team: do they see current incidents or can they find out who else in the company received the notification? The program aktiva?
Idealisht, një program menaxhimi incidentesh ofron këshilla se si të përmirësohet konteksti i njoftimit gjatë hetimit të incidenteve. Gjithmonë ka hapësirë për përmirësim!
Veprues — vlera praktike
A duhet që kujdestari të bëjë diçka në përgjigje të njoftimit? Nëse nuk ka asgjë për të bërë ose nuk është e qartë se çfarë të bëhet, pse e shkaktuat zgjimin? Duhet të shmangim njoftimet që shqetësojnë kujdestarët dhe nuk kërkojnë veprime.
Çfarë duhet bërë? Çfarë nevojitet?
Dikur, kur sistemet ishin të thjeshta dhe ekipet të vogla, ne e konfiguronnim monitorimin vetëm për të qenë në dijeni të ngjarjeve. Një njoftim se ngarkesa e grumbullit është rritur do të na japë kontekst nëse shërbimi ka filluar të ketë defekte. Në një shkallë më të madhe, njoftimet e tilla vetëm do të na ngathtësojnë, sepse sistemet tona gjithmonë punojnë në një gjendje të degraduar të ndryshme. Kjo shpejt çon në dhe, natyrisht, në humbjen e ndjeshmërisë. Prandaj, kujdestari i injoron ose madje filtrin këto njoftime dhe nuk përgjigjet gjithmonë siç duhet. Mos bini në këtë kurth! Mos e konfiguroni çdo njoftim për t'i dërguar më pas në postën elektronike në ndonjë dosje të harruar.
Kjo është si duket një njoftim me vlerë praktike:
- Njoftimi kërkon veprim, jo thjesht njoftim të lajmeve.
- Ky veprim është i vështirë ose i rrezikshëm për t'u automatizuar. Nëse veprimi mund të automatizohet, atëherë thjesht automatizojeni, mjafton të shqetësoni njerëzit!
- Njoftimi përmban rekomandime urgjente në formën e (SLA) ose (RTO). Atëherë kujdestari mund të aktivizojë programin e menaxhimit të incidenteve në organizatë.
Dua të sqaroj: nuk po them se njoftimet duhet të vijnë vetëm për SLO (objektivat e nivelit të shërbimit) më të rëndësishme për API. Monitorimi i SLO është vazhdimisht i ndarë dhe e kërkon një qasje të njëjtë për të gjitha shërbimet. E qartë, do të ndjekësh SLO më të rëndësishme për klientët që paguajnë. Por SLO e infrastrukturës, siç janë bazat e të dhënave, gjithashtu duhet ndjekur. Shpejt do t'ju duhet të merret me klientët e brendshëm dhe t'i mbani ata. Dhe kështu deri në pafundësi.
Të bazuar në simptoma — theksi në simptoma
Të pëlqen apo jo, por ti punon në një sistem të shpërndarë (Kavaxhs). Si rezultat, përdorni taktika të ndryshme për të izoluar shërbimet dhe për t'i mbrojtur ato nga dështimet (Trejnor et al.) 3. Dhe megjithëse mbledhja e mbeturinave e zgjatur ose një kërkesë e menduar për bazën e të dhënave tregon për probleme, nuk është e nevojshme të nxitoni t'i eliminoni ato, nëse përdoruesit nuk do të kenë probleme në afat të shkurtër.
Këto janë sinjale të rëndësishme, dhe ato mund të kenë vlerë praktike, por nëse nuk i pengojnë përdoruesit, atëherë nuk është aq urgjente sa të hidhni vëmendjen e ndihmësit. Njoftimet e bazuara në shkakun janë pamje të modeleve tona mendore për dështimin sistemor. Është më mirë të ndiqni simptomat e rëndësishme sesa të provoni të listoni të gjitha shkaktarët e mundshëm të dështimit.
Për të pasur vlerë praktike, njoftimet duhet të përqendrohen në , të rëndësishëm për përdoruesit. Evashuq e quan këtë "monitorim për përdoruesit". Mbani mend se kjo filozofi duhet të aplikohet në të gjithë organizatën. Nëse një shërbim ka ndonjë problem të menjëhershëm në thellësi të infrastrukturës, ekipi i duhur do ta trajtojë atë. Mbrojtja e sistemeve nga këto dështime është një çështje krejtësisht e ndarë (Trejnor et al., seksioni mbi strategjitë për minimizimin e varësive kritike).
Simptomat nuk janë të tillë të ndryshueshme
Richard Cook përkujton se në sistemet e ndërlikuara ka shumë defekte, mangësi dhe probleme. Të provosh të listosh të gjitha shkaktarët e mundshëm është një punë e Siziit. Po përpiqesh të përshkruash problemet, dhe ato gjithmonë ndryshojnë. Cindy Shridharan mendon se "sistemet nuk duhet të jenë domosdoshmërisht në një gjendje të përsosur çdo sekondë" dhe është më mirë të përdorim një qasje më njerëzore ( ("Distributed Systems Observability"), 7).
Shmangni njoftimet për ndodhjen e ngjarjeve
Zakonisht njoftimet për shkaktarët vendosen për të rregulluar incidentet. Dhe këto njoftime të kufizuara për ndodhjen e një ngjarje krijojnë një ndjenjë të rreme të sigurisë, sepse sistemi gjithmonë gjen mënyra të reja për të dështuar.
Mos e mashtro veten me njoftime për shkaktarët. Më mirë mendoni:
- Pse njoftimi mbi simptomat nuk e vuri re problemin?
- A do të ishte e dobishme të përmirësohej konteksti për përdoruesin?
- Si të përmirësoni mjetet e monitorimit për të vendosur diagnozën më shpejt, dhe jo për të grumbulluar njoftime për ngjarjet e kaluar?
Mjetet e monitorimit për diagnozën do të ndihmojnë, vetëm nëse i shihni ato si një mënyrë për të kaluar nga simptoma në zgjidhje. Pa këtë feedback, do të përfundoni të mbingarkuar me njoftime të vonuara dhe diagrame për defektet e kaluara — e asnjë fjalë për ato të ardhshme. Kjo është një mundësi e shkëlqyer për organizatën për t'u kaluar nga mbrojtja në sulm. Po ashtu, zhvilluesit dhe menaxherët e produkteve do të kenë pritshmëri të njëjta dhe objektiva të qarta. Rastet — CASE (:wink:) — për çdo njoftim janë të qarta.
Njoftimet e bazuara në shkakun e ngjarjeve janë të pranueshme në një numër të moderuar.
Ndonjëherë sistemi ynë gati nuk na lë asnjë zgjedhje në lidhje me njoftimet bazuar në shkakun e ngjarjeve. Ndërsa ndonjëherë turni e kupton mirë se simptoma do të çojë patjetër në një defekt, dhe kështu ka vlerë praktike. Ndoshta ju thjesht nuk jeni të sigurt se çfarë po ndodh, dhe po konfiguroni njoftimet për t'u mbrojtur. Le të shpresojmë se kjo është një veprim që nevojitet përkohësisht, derisa të ndryshojmë sistemin për të trajtuar çështjen e performancës.
Merrni parasysh komponentët e tjerë të CASE, kur trajtoni situata të tilla. Nëse është përkohësore, nuk do të thotë se nuk duhet të mendoni me kokë.
Evaluated — evaluimi
Çdo ndryshim në sistem (kod i ri, infrastrukturë e re, çfarëdo gjëje të re) zgjeron gamën e defekteve (Kuk, 3). A funksionon akoma ky njoftim siç pritej? Modelet e qarta dhe të aktualizuara të mendjes për sistemet dhe përvoja në përgjigjen ndaj disa njoftimeve për mbështetje — janë karakteristika kyçe . Defektet në sisteme vazhdojnë të evoluojnë, dhe ne duhet të mbanim ritmin pas tyre.
Duhet të vlerësojmë përherë cilësinë e çdo njoftimi, që të funksionojnë siç pritej. Të nderuar menaxherë! Ekipet tuaja do ta kenë shumë më të lehtë nëse i ndihmoni të rregullojnë këtë proces! Këtu janë disa ide për vlerësim:
- Përdorni , ose metoda të tjera të testimit të njoftimeve. Ekipi mund ta bëjë këtë vetë, pa angazhuar një sistem të rëndë menaxhimi të incidentëve!
- Aktivizoni mbledhjen e të dhënave për të gjitha njoftimet që lidhen me incidentet në programin e menaxhimit të incidenteve. Shënoni ato që janë të dobishme, të dëmshme, të papërshtatshme, të paqartë etj. Përdorini si feedback.
- Njoftimet e sakta ndodhin rrallë dhe janë verifikuar me kujdes. Sigurohuni që të gjitha lidhjet të funksionojnë, të tregojnë kontekstin e duhur etj.
- Nëse një njoftim nuk ndodh kurrë ose ndodh shumë shpesh, ka diçka të gabuar me të. Riparojeni ose fshini atë. Tregohuni të kujdesshëm për pasivitetin ose aktivizmin e tepërt!
- Konfiguroni për njoftimet etiketat e kohës me afat skadimi. Nëse afati skadon, vlerësoni njoftimin sipas metodës CASE dhe përditësoni etiketën e kohës. Kontrolloni rregullisht afatin, siç bëni me ushqimin.
- Thjeshtoni procesin e përmirësimit të njoftimeve. Përdorni monitorimin si kod dhe ruani njoftimet në një repository Git. Kërkesat për tërheqje ndihmojnë në përfshirjen e ekipit, dhe do të keni një histori të njoftimeve të kaluara. Dhe do të ndaloni së frikësuari nga ndryshimi i njoftimeve ose nga kërkesa e lejes nga ata që janë përgjegjës për to.
- Krijoni feedback për njoftimet, madje edhe nëse është thjesht , që rojet të shënojnë njoftimet si të padobishme ose të bezdisshme. Inkludoni një lidhje ose thirrje në veprim brenda vetë njoftimit dhe shikoni rregullisht feedback-un.
- Vendosni në ekip rregullin që rojet të punojnë për thjeshtimin e detyrës kur ka pak punë. Lejoni që pas jush gjithçka të bëhet pak më e mirë se sa ishte më parë.
Përfundim
Unë besoj se metoda CASE ndihmon zhvilluesit dhe organizatat të diskutojnë konfigurimin dhe dërgimin e njoftimeve automatike. Një zhvillues mund të fillojë vlerësimin e njoftimeve sipas metodës CASE dhe pastaj organizata e gjithë të tjerë me zhvillues të tjerë, menaxhment dhe programe të menaxhimit të incidenteve mund t'i mbajnë njoftimet në një gjendje të mirë. Nuk janë të nevojshme asnjë mjet të veçantë apo procese komplekse.
E gjithë industria duhet të mendojë për faktorët njerëzorë gjatë detyrës pa sakrifikuar shërbimin e shkëlqyer për klientët. Të gjitha këto mjete dhe praktika mund dhe duhet të përmirësohen. Shpresoj se metoda CASE do të ndihmojë në këtë.
Shijoni njoftimet e përmirësuara!
Burimi: habr.com
