ProHoster > Blog > Administrimi > Metoda CASE: monitorimi human

Metoda CASE: monitorimi human

Metoda CASE: monitorimi human
Bzzz! ËshtĂ« 3 nĂ« mĂ«ngjes, ju jeni duke Ă«ndĂ«rruar njĂ« gjumĂ« tĂ« bukur, dhe papritmas - njĂ« telefonatĂ«. KĂ«tĂ« javĂ« keni rolin dhe pĂ«r sa duket ka ndodhur diçka. Sistemi automatizuar ju thĂ«rret tĂ« shpĂ«rndani njĂ« shqetĂ«sim. Ky Ă«shtĂ« njĂ« moment i rĂ«ndĂ«sishĂ«m pĂ«r menaxhimin e sistemeve moderne kompjuterike, por le tĂ« shohim se si t'i bĂ«jmĂ« njoftimet mĂ« tĂ« pĂ«rshtatshme pĂ«r njerĂ«zit.

Njoftohuni me filozofinë e monitorimit, e cila ka lindur gjatë disa dekadave të roli tim në ekipe të ndryshme të monitorimit. Kjo është ndikuar shumë nga bibla e vërtetë e Robit Evatsuk My Philosophy on Alerting (Filozofia ime për njoftimet), e përfshirë në librin mbi Google SRE, dhe libri i John Olspoo Considerations for Alert Design (Konsideratat për dizajnin e njoftimeve).

Kelly Dunn, Arijit Mukherjee dhe Maxim Petazzoni — faleminderit pĂ«r ndihmĂ«n nĂ« redaktimin e postit.

ÇfarĂ« Ă«shtĂ« CASE?

Unë vendosa të krijoj një akronim të bukur, ashtu si metoda USE e Brendan Gregg ose metoda RED e Tom Wilkie.Unë e quaj këtë metoda CASE.Ai përshkruan katër pika që duhen marrë parasysh kur punoni me monitorimin automatike:

Nëse po përdorni CASE, keni një qasje të shëndetshme ndaj njoftimeve dhe nuk i zgjoni njerëzit natën. Duhet të vlerësoni rregullisht monitorimin për dobishmërinë dhe efikasitetin e tij. Kur dikush merr një njoftim, ai do të ketë modele më të mira mendore dhe më shumë siguri.

PĂ«r ta bĂ«rĂ« mĂ« tĂ« lehtĂ« pĂ«r t'u mbajtur mend, imagjinoni se ju nevojitet njĂ« CASE [domethĂ«nĂ«, njĂ« rast, arsyetim — shĂ«nimi i pĂ«rkthyesit], pĂ«r tĂ« justifikuar çdo njoftim. :sunglasses:

Dhe pse e gjithë kjo?

Shërbimi mund të jetë torturues. Për shumë arsye. Dhe CASE nuk do t'i eliminojë të gjitha ato. Por me të, natën do të zgjoheni nga njoftime më cilësore. Kjo metodë mbulon procese të ndryshme organizative që gjithashtu do të ndihmojnë në këtë çështje.

E bukura e metodave RED dhe USE është se me to ne jo vetëm që dimë si të punojmë, por flasim gjithashtu në një gjuhë të përbashkët. Shpresoj se me metodën CASE do të jetë më e lehtë të diskutojmë njoftimet që mbrojnë sistemet tona, por që nuk i japin paqe kolegëve.

The essence is to create a culture within the organization where notifications are treated with a healthy indifference. Notifications can be created for a reason, but it’s not certain that they won't lose their value later. Why did we set up this notification? Have its criteria been reviewed recently? You can find answers to these questions with CASE.

Context-Heavy — context binding

3 AM is not the best time to read messages filled with complex vocabulary. To react effectively, specific 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 this. This is about 'observation' and 'orientation' from the NORD cycle. This configuration is worth spending time on because constantly distracting a person is even more costly. Let’s respect each other.

Metoda CASE: monitorimi human
Problems have many sources. Especially ghosts.

Si te ndihmojmë turnit? Së pari, turni sheh njoftimin, kështu që të gjitha hipotezat ai i ndan në bazë të tij. Pastaj ai shikon udhëzimet dhe panelin, por a ka gjithmonë të dhëna për njoftimin përkatës, e jo thjesht informacion të përgjithshëm? Olspo rekomandon "të mendoni se si mund të interpretojmë njoftimin ose të reagojmë ndaj tij" (slajdi 29)1. Një njoftim i mirë është i orientuar në turn, dhe jo thjesht i vendosur sipas një vlere prag.

Prandaj, ja disa ide se si të përmirësojmë kontekstin e njoftimeve:

  • Tregoni pĂ«rdoruesit diçka tĂ« dobishme dhe tĂ« krijuar veçmas, e jo thjesht udhĂ«zime tĂ« zakonshme ose njĂ« panel. MĂ« parĂ« kemi pĂ«rdorur panelet pĂ«r hetim, tĂ« vendosura pĂ«r njoftimet specifike. Kjo do tĂ« ndihmojĂ« nĂ«se problemi Ă«shtĂ« i njohur, dhe vetĂ«m do tĂ« ngatĂ«rronte nĂ« raste tĂ« tjera. KĂ«tu duhet tĂ« gjendet njĂ« balancĂ«.
  • Tregoni historinĂ« e njoftimit: a Ă«shtĂ« i ri? A ndodh shpesh? A Ă«shtĂ« sezonale?
  • Tregoni ndryshimet e fundit nĂ« gjendjen e sistemit. A Ă«shtĂ« ndryshuar diçka kohĂ«t e fundit? (PĂ«r shembull, njĂ« deploy apo aktivizim/çaktivizim funksional.)
  • Trego marrĂ«dhĂ«niet dhe ofroni informacion pĂ«r modelin mental: varĂ«sitĂ« e sistemit duhet tĂ« jenĂ« tĂ« qarta, preferohet tĂ« tregohet funksionaliteti.
  • Shpejt lidheni pĂ«rdoruesin me ekipin: a sheh ai incidentet aktuale apo mund tĂ« mĂ«sojĂ« se kush tjetĂ«r nĂ« kompani ka marrĂ« njoftim? A Ă«shtĂ« programi i menaxhimit tĂ« incidenteve aktivizuar?

Idealisht, programi i menaxhimit të incidenteve ofron këshilla se si të përmirësohet konteksti i njoftimit gjatë hetimit të incidenteve. gjithmonë ka diçka që mund të punoni!

Veprues — vlerĂ« praktike

A duhet që ndihmës të bëjë diçka në përgjigje të njoftimit? Nëse nuk ka asgjë për të bërë ose është e paqartë se çfarë duhet bërë, pse e alarmuat? Duhet shmangur njoftimet që irritojnë ndihmësin dhe nuk kërkojnë veprim.

Shihni postimin në imgur.com

ÇfarĂ« duhet tĂ« bĂ«j? ÇfarĂ« Ă«shtĂ« e nevojshme?

Në të kaluarën, kur sistemet ishin të thjeshta dhe ekipet të vogla, ne vendosnim monitorimin thjesht për të qenë në dijeni. Një njoftim që ngarkesa në grup ka rritur, do të na japë kontekst nëse shërbimi fillon të punojë me defekte më vonë. Në shkallë të madhe, njoftimet e tilla vetëm do të na konfuzojnë, sepse sistemet tona gjithmonë punojnë në një gjendje degraduese të ndryshme. Kjo shpejt çon në lodhjen nga njoftimet dhe, sigurisht, në humbjen e ndjeshmërisë. Prandaj, personi që ndjek nuk i përgjigjet ose madje i filtrin këto njoftime dhe nuk reagon gjithmonë si duhet. Mos bie në këtë grackë! Mos vendos njoftime në çdo rast dhe pastaj dërgojini ato në një dosje të harruar në postë.

Këtu është si duket një njoftim me vlerë praktike:

  • Njoftimi kĂ«rkon veprim, e jo thjesht njofton lajme.
  • Ky veprim Ă«shtĂ« i komplikuar ose i rrezikshĂ«m pĂ«r t'u automatizuar. NĂ«se veprimi mund tĂ« automatizohet, atĂ«herĂ« bĂ«je dhe automatizoje, mjafton tĂ« shqetĂ«sosh njerĂ«zit!
  • Njoftimi pĂ«rmban rekomandime urgjente nĂ« formĂ«n e marrĂ«veshjes pĂ«r nivelin e shĂ«rbimit (SLA) ose kohĂ« rikuperimi tĂ« caktuar (RTO). NĂ« kĂ«tĂ« rast, operatori 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 mĂ« tĂ« rĂ«ndĂ«sishme (objeektivat e nivelit tĂ« shĂ«rbimit) pĂ«r API. Monitorimi i SLO vazhdimisht copĂ«tohet dhe ndahet dhe kĂ«rkon qasje tĂ« njĂ«jtĂ« pĂ«r tĂ« gjitha shĂ«rbimet. ËshtĂ« e qartĂ« se do tĂ« monitoroni SLO mĂ« tĂ« rĂ«ndĂ«sishme pĂ«r klientĂ«t qĂ« ju paguajnĂ«. Por SLO pĂ«r infrastrukturĂ«n, pĂ«r shembull bazat e tĂ« dhĂ«nave, gjithashtu duhet tĂ« monitorohen. 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 Ă«shtĂ« te simptomat

PĂ«lqen kjo apo jo, por ju punoni nĂ« njĂ« sistem tĂ« shpĂ«rndarĂ« (Kavaj)2. Si rezultat, pĂ«rdorni taktika tĂ« ndryshme pĂ«r tĂ« izoluar shĂ«rbimet dhe pĂ«r t’i mbrojtur ato nga dĂ«shtimet (Treynor et al.)3. Dhe megjithĂ«se njĂ« mbledhje e gjatĂ« garbage ose njĂ« kĂ«rkesĂ« e ngadalshme ndaj bazĂ«s sĂ« tĂ« dhĂ«nave tregon pĂ«r defekte, nuk duhet tĂ« shpejtoni pĂ«r t’i eliminuar ato, nĂ«se pĂ«rdoruesit nuk do tĂ« kenĂ« probleme sĂ« shpejti.

KĂ«to janĂ« sinjale tĂ« rĂ«ndĂ«sishme dhe ato mund tĂ« kenĂ« vlerĂ« praktike, por nĂ«se nuk pengojnĂ« pĂ«rdoruesit, nuk janĂ« aq urgjente sa tĂ« shpĂ«rqendrojnĂ« rojet. Njoftimet e bazuara nĂ« arsye janĂ« imazhe tĂ« modeleve tona mendore pĂ«r njĂ« dĂ«shtim sistematik. ËshtĂ« mĂ« mirĂ« tĂ« ndjekim simptomat e rĂ«ndĂ«sishme sesa tĂ« pĂ«rpiqemi tĂ« numĂ«rojmĂ« tĂ« gjitha arsyet e mundshme tĂ« dĂ«shtimit.

Për të pasur vlerë praktike, njoftimet duhet të përqendrohen në indikatorët e performancës, të rëndësishëm për përdoruesit. Evashuk e quajti këtë "monitorim për përdoruesit". Mbani mend se kjo filozofi duhet të aplikohet në të gjithë organizatën. Nëse shërbimi do të ketë ndonjë problem të menjëhershëm në thellësi të infrastrukturës, një ekip përkatës do të merret me të. Mbrojtja e sistemeve nga këto dështime është një çështje krejtësisht e ndryshme (Trainer et al., seksioni mbi strategjitë për minimizimin e varësive kritike).3.

Simptomat nuk janë kaq të ndryshueshme

Richard Cook kujton se në sistemet komplekse ka shumë të meta, mangësi dhe probleme.4. Duke të përpiqeni të listoni të gjitha arsyet e mundshme - është një punë Sisyphus. Po përpiqeni të përshkruani problemet, ndërsa ato ndryshojnë vazhdimisht. Cindy Shridharan beson se "sistemet nuk duhet domosdoshmërisht të jenë në një gjendje të pëperfect çdo sekondë" dhe është më mirë të përdoret një qasje më njerëzore («Distributed Systems Observability» («Vëzhgimi i Sistemeve të Distribuara»), 7)5.

Shmangni njoftimet në rast incidenti

Zakoni për të vendosur njoftime për arsyet për të riparuar incidentet. Këto njoftime të kufizuara që Informojnë për faktin e ndodhisë krijojnë një ndjenjë të rreme besimi, pasi sistemi gjithmonë gjen metoda të reja për të dështuar.

Mos u mashtoni nga njoftimet për arsyet. Më mirë mendoni:

  • Pse njoftimi i bazuar nĂ« simptoma nuk e zbuloi problemin?
  • A do tĂ« ishte e dobishme tĂ« pĂ«rmirĂ«sohej konteksti pĂ«r pĂ«rdoruesin?
  • Si tĂ« pĂ«rmirĂ«sojmĂ« mjetet e monitorimit pĂ«r tĂ« vendosur diagnoza mĂ« shpejt, nĂ« vend qĂ« tĂ« grumbullojmĂ« njoftime pĂ«r atĂ« qĂ« ka ndodhur?

Mjetet e monitorimit pĂ«r diagnozĂ«n do tĂ« ndihmojnĂ«, vetĂ«m nĂ«se i perceptoni ato si njĂ« mĂ«nyrĂ« pĂ«r tĂ« kaluar nga simptoma nĂ« zgjidhje. Pa kĂ«tĂ« feedback, ju thjesht do tĂ« mbuloheni me njoftime dhe grafikĂ« tĂ« vonuara mbi defektet e kaluar — pa asnjĂ« fjalĂ« pĂ«r tĂ« ardhmen. PĂ«r organizatĂ«n, kjo Ă«shtĂ« njĂ« mundĂ«si e shkĂ«lqyer pĂ«r tĂ« kaluar nga mbrojtja nĂ« sulm. Dhe zhvilluesit dhe menaxherĂ«t e produkteve do tĂ« kenĂ« tĂ« njĂ«jtat pritshmĂ«ri dhe qĂ«llime tĂ« qarta. Rastin — CASE (:wink:) — pĂ«r secilĂ«n njoftim Ă«shtĂ« tĂ« qartĂ«.

Njoftimet e bazuara në shkakun janë të tolerueshme në një numër të moderuar.

Ndonjëherë sistemi ynë gati nuk na len asnjë zgjedhje për njoftimet e bazuara në shkakun. Ndërsa ndonjëherë, rojet e natës e kuptojnë shumë mirë se simptoma patjetër do të çojë në një defekt, prandaj ka vlerë praktike. Ndoshta thjesht nuk jeni të sigurt se çfarë po ndodh, dhe po konfiguroni njoftimet si një masë mbrojtëse. Shpresojmë se ky veprim është përkohësor, derisa të ndryshojmë sistemin për të adresuar çështjen e uljes së performancës.
Kujtoni komponentët e tjerë të CASE, kur merret me situata të tilla. Nëse është përkohësore, nuk do të thotë se nuk duhet të mendoni logjikisht.

E vlerĂ«suar — vlerĂ«sim

Çdo ndryshim nĂ« sistem (kod i ri, infrastrukturĂ« e re, çfarĂ«do tĂ« re) zgjeron gamĂ«n e defekteve (Kuk, 3).4 A po funksionon ende kjo njoftim siç pritej? Modelet e qarta dhe aktuale mendore tĂ« sistemeve dhe pĂ«rvoja e reagimit ndaj disa njoftimeve pĂ«r mbĂ«shtetje. qasje parandaluese — janĂ« veçoritĂ« kyçe tĂ« njĂ« organizate tĂ« orientuar drejt mĂ«simit.. Defektet nĂ« sisteme zhvillohen vazhdimisht, dhe ne duhet tĂ« pĂ«rpiqemi tĂ« mbajmĂ« ritmin me to.

Duhet tĂ« vlerĂ«sohet vazhdimisht cilĂ«sia e çdo njoftimi, qĂ« tĂ« funksionojĂ« siç pritet. MenaxherĂ« tĂ« nderuar! Ekipet tuaja do tĂ« kishin shumĂ« mĂ« lehtĂ« nĂ«se do t’i ndihmoni tĂ« krijojnĂ« kĂ«tĂ« proces! KĂ«tu janĂ« disa ide pĂ«r vlerĂ«sim:

  • PĂ«rdorni Inxhinieria e kaosit, ditĂ« lojĂ«ra ose metoda tĂ« tjera pĂ«r testimin e njoftimeve. Ekipi mund ta bĂ«jĂ« kĂ«tĂ« vetĂ«, pa pĂ«rfshirjen e njĂ« sistemi tĂ« rĂ«ndĂ« pĂ«r menaxhimin e incidenteve!
  • PĂ«rfshini mbledhjen e tĂ« dhĂ«nave pĂ«r tĂ« gjitha njoftimet e lidhura 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 ato si feedback.
  • Njoftimet e sakta ndodhin rrallĂ« dhe kontrollohen me kujdes. Sigurohuni qĂ« tĂ« gjitha lidhjet tĂ« funksionojnĂ« dhe tĂ« tregojnĂ« kontekstin e duhuru.
  • NĂ«se njoftimi nuk ndodh kurrĂ« ose ndodh shumĂ« shpesh, ndodhi diçka e gabuar me tĂ«. Rregullojeni ose hiqeni. Keni kujdes nga pasiviteti ose aktiviteti i tepruar!
  • Konfiguroni etiketat e kohĂ«s pĂ«r njoftimet me afat skadimi. NĂ«se afati skadon, vlerĂ«soni njoftimin nĂ« bazĂ« tĂ« metodĂ«s CASE dhe pĂ«rditĂ«soni etiketĂ«n e kohĂ«s. Kontrolloni rregullisht afatin e skadimit, ashtu si bĂ«ni me ushqimin.
  • Thjeshtoni procesin e pĂ«rmirĂ«simit tĂ« njoftimeve. PĂ«rdorni monitorimin nĂ« formĂ« kodi dhe ruani njoftimet nĂ« njĂ« depo Git. KĂ«rkesat e tĂ«rheqjes ndihmojnĂ« pĂ«r tĂ« angazhuar ekipin, dhe do tĂ« keni njĂ« histori tĂ« njoftimeve tĂ« kaluar. KĂ«shtu do tĂ« ndiheni mĂ« tĂ« sigurt pĂ«r tĂ« ndryshuar njoftimet ose pĂ«r tĂ« kĂ«rkuar leje nga ata qĂ« janĂ« pĂ«rgjegjĂ«s pĂ«r to.
  • Siguroni feedback pĂ«r njoftimet, edhe nĂ«se Ă«shtĂ« vetĂ«m forma Google, nĂ« mĂ«nyrĂ« qĂ« ekuipazhi tĂ« markojĂ« njoftimet si tĂ« padobishme ose tĂ« bezdisshme. Futni njĂ« lidhje ose thirrje pĂ«r veprim nĂ« vetĂ« njoftimin dhe rregullisht kontrolloni feedback-un.
  • Vendosni njĂ« rregull nĂ« ekip — lejoni qĂ« ata nĂ« turn tĂ« punojnĂ« pĂ«r thjeshtimin e turneve kur ka pak punĂ«. Le tĂ« bĂ«het gjithçka njĂ« pak mĂ« mirĂ« pas jush se sa ishte para.

PĂ«rfundimi

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 përmes metodës CASE, dhe më pas të bashkohet me të gjithë organizatën, duke përfshirë zhvillues të tjerë, menaxhment dhe programe menaxhimi të incidenteve, për të mbajtur njoftimet në një gjendje të mirë. Nuk janë të nevojshme asnjë vegël e veçantë ose procese të komplikuara për këtë.

I gjithë sektori duhet të mendojë për faktorët njerëzorë gjatë turneve pa e kompromentuar shërbimin e shkëlqyer për klientët. Të gjitha këto vegla dhe praktika mund dhe duhet të përmirësohen. Shpresoj që metoda CASE të ndihmojë në këtë.

Gëzohuni me njoftimet e përmirësuara!
Metoda CASE: monitorimi human

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster