ProHoster > Blogs > Administrācija > CASE metode: humāna uzraudzība

CASE metode: humāna uzraudzība

CASE metode: humāna uzraudzība
Dziiiiin! Ir 3 naktÄ«, jÅ«s redzat brÄ«niŔķīgu sapni, un pēkŔņi atskan zvans. JÅ«s Å”onedēļ dežurējat, un acÄ«mredzot kaut kas noticis. Automātiskā sistēma zvana, lai noskaidrotu, kas ir nepareizi. Tas ir svarÄ«gs mÅ«sdienu datorsistēmu pārvaldÄ«bas aspekts, taču apskatÄ«sim, kā padarÄ«t paziņojumus cilvēkiem labākus.

IepazÄ«stieties ar monitoringa filozofiju, kas radusies vairāku gadu desmitu laikā, pildot savus pienākumus dažādās uzraudzÄ«bas komandās. Viņu lielā mērā ietekmēja Ä«stā Roba EvaŔčuka BÄ«bele Mana brÄ«dināŔanas filozofija (Mana paziņojumu filozofija), kas iekļauta grāmatā par Google SRE, un Džona Alspauga grāmata BrÄ«dinājumu dizaina apsvērumi (PiezÄ«mes par brÄ«dinājumu iestatÄ«Å”anu).

Kellija Danna, Arijits Mukherijs Šø Maksims Petazoni ā€” paldies par palÄ«dzÄ«bu ziņas rediģēŔanā.

Kas ir CASE?

Es nolēmu izdomāt skaistu saÄ«sinājumu, piemēram, Brendana Grega USE metode vai Toma Vilkija RED metode. Es to saucu CASE metode. ViņŔ apraksta četrus punktus, kuriem jāpievērÅ” uzmanÄ«ba, strādājot ar automātisko uzraudzÄ«bu:

Ja izmantojat CASE, jūs izturaties pret paziņojumiem ar veselīgu vienaldzību un nemodināt cilvēkus naktī. Uzraudzības lietderība un efektivitāte ir regulāri jānovērtē. Kad persona saņems paziņojumu, viņam būs labāki garīgie modeļi un lielāka pārliecība.

Lai to bÅ«tu vieglāk atcerēties, iedomājieties, ka jums ir nepiecieÅ”ams CASE [tas ir, gadÄ«jums, iemesls - tulka piezÄ«me], lai pamatotu katru brÄ«dinājumu. :saulesbrilles:

Un kāpēc tas viss?

Dežūras var bÅ«t sāpes. Daudzu iemeslu dēļ. Un CASE tos visus nenovērsÄ«s. Bet ar to jÅ«s naktÄ« pamodÄ«sities, lai saņemtu labākus paziņojumus. Å Ä« metode aptver dažādus organizatoriskos procesus, kas arÄ« palÄ«dzēs Å”ajā jautājumā.

RED un USE metožu skaistums ir tāds, ka ar to palÄ«dzÄ«bu mēs ne tikai zinām, kā strādāt, bet arÄ« runājam vienā valodā. Es ceru, ka CASE metode atvieglos tādu paziņojumu apsprieÅ”anu, kas aizsargā mÅ«su sistēmas, bet noslogo mÅ«su kolēģus.

Lieta ir tāda, ka jums savā organizācijā ir jārada kultÅ«ra, kurā paziņojumi tiek izturēti ar veselÄ«gu vienaldzÄ«bu. Paziņojumus var izveidot konkrētam mērÄ·im, taču tas nav fakts, ka tie vēlāk nezaudēs vērtÄ«bu. Kāpēc mēs iestatÄ«jām Å”o paziņojumu? Cik sen tā kritēriji ir pārskatÄ«ti? Izmantojot CASE, uz Å”iem jautājumiem var atbildēt.

Context-Heavy ā€” konteksta saistÄ«Å”ana

3:XNUMX nav labākais laiks, lai lasÄ«tu ziņas, kurās ir daudz gudru vārdu. Lai reaģētu efektÄ«vi, jums ir nepiecieÅ”ama informācija. Ideālā gadÄ«jumā tai vajadzētu bÅ«t informācijai par konkrētu problēmu, kuras konteksts ir uzreiz skaidrs, un paziņojumi ir jākonfigurē tā, lai tas bÅ«tu iespējams. Tas ir "novēroÅ”ana" un "orientācija" no OODA cilpa. Nav kauns tērēt laiku Å”im iestatÄ«jumam, jo ā€‹ā€‹pastāvÄ«ga cilvēka uzmanÄ«bas novērÅ”ana ir vēl dārgāka. CienÄ«sim viens otru.

CASE metode: humāna uzraudzība
Problēmām ir daudz avotu. ÄŖpaÅ”i spokos.

Kā es varu palÄ«dzēt dežurantam? Pirmais, ko dežurants redz, ir paziņojums, tāpēc uz tā pamata viņŔ izvirza visas hipotēzes. Pēc tam viņŔ aplÅ«ko instrukcijas un informācijas paneļus, bet vai vienmēr ir dati par konkrētu paziņojumu, nevis tikai vispārÄ«ga informācija? Alspaugh iesaka "padomāt par to, kā jÅ«s varētu interpretēt paziņojumu vai atbildēt uz to" (29. slaids)1. Labs paziņojums ir vērsts uz dežurējoÅ”u personu, nevis tikai konfigurētu pēc sliekŔņa.

Šeit ir dažas idejas, kā uzlabot paziņojumu kontekstu.

  • Parādiet lietotājam kaut ko noderÄ«gu un Ä«paÅ”i izveidotu, nevis tikai parastās instrukcijas vai informācijas paneli. IepriekÅ” mēs ar puiÅ”iem izmantojām izmeklÄ“Å”anas informācijas paneļus, kas bija konfigurēti konkrētiem paziņojumiem. Tas palÄ«dzēs, ja problēma ir zināma, bet tikai mulsinās citus. Å eit mums jāatrod lÄ«dzsvars.
  • Pastāstiet mums par paziņojuma vēsturi: vai tas ir jauns? Vai tas bieži darbojas? Vai tas ir sezonāls?
  • RādÄ«t jaunākās izmaiņas sistēmas stāvoklÄ«. Vai pēdējā laikā kaut kas ir mainÄ«jies? (Piemēram, izvietoÅ”ana vai funkcionalitātes iespējoÅ”ana/atspējoÅ”ana.)
  • Parādiet attiecÄ«bas un sniedziet informāciju garÄ«gajam modelim: sistēmas atkarÄ«bām jābÅ«t skaidri redzamām, vēlams ar norādi par funkcionalitāti.
  • Ātri savienojiet lietotāju ar komandu: vai viņŔ var redzēt notiekoÅ”os incidentus vai uzzināt, kurÅ” vēl uzņēmumā ir saņēmis paziņojumu? Programma incidentu vadÄ«ba aktivizēts?

Ideālā gadÄ«jumā incidentu pārvaldÄ«bas programma sniegs padomus par to, kā uzlabot incidentu izmeklÄ“Å”anas paziņoÅ”anas kontekstu. Vienmēr ir pie kā strādāt!

RÄ«cÄ«ba ā€“ praktiska vērtÄ«ba

Vai dežurantam būtu kaut kas jādara, reaģējot uz paziņojumu? Ja jums nekas nav jādara vai nav skaidrs, ko darīt, kāpēc jūs viņu pamodinājāt? Jums ir jāizvairās no paziņojumiem, kas kaitina dežurantus un neprasa nekādas darbības.

View post par imgur.com

Ko man darīt? Ko tu gribi?

Agrāk, kad sistēmas bija vienkārÅ”as un komandas bija mazas, mēs izveidojām uzraudzÄ«bu, lai bÅ«tu lietas kursā. Paziņojums, ka kaudzes slodze ir palielinājusies, sniegs mums kontekstu, ja pakalpojums vēlāk nedarbosies. PlaŔā mērogā Ŕādi paziņojumi tikai radÄ«s neskaidrÄ«bas, jo mÅ«su sistēmas vienmēr darbojas dažāda smaguma degradācijas stāvoklÄ«. Tas ātri noved pie nogurums no paziņojumiem un, protams, jutÄ«bas zudums. Tāpēc dežurants Ŕādus paziņojumus ignorē vai pat filtrē un ne vienmēr atbild uz tiem pēc vajadzÄ«bas. NeiekrÄ«ti Å”ajā slazdā! Neiestatiet visus paziņojumus pēc kārtas un pēc tam nesÅ«tiet tos pa e-pastu uz kādu dieva pamestu mapi.

Lūk, kā izskatās paziņojums ar praktisku vērtību:

  • Lai saņemtu paziņojumu, ir jārÄ«kojas, nevis vienkārÅ”i jāziņo par jaunumiem.
  • Å o darbÄ«bu ir grÅ«ti vai riskanti automatizēt. Ja darbÄ«bu var automatizēt, tad automatizējiet, beidziet mocÄ«t cilvēkus!
  • Paziņojuma veidlapā ir iekļauti steidzami ieteikumi pakalpojumu lÄ«meņa lÄ«gumi (SLA) vai atveseļoÅ”anās laika mērÄ·is (RTO). Pēc tam dežurants var aktivizēt organizācijas incidentu pārvaldÄ«bas programmu.

Es vēlos precizēt: es nesaku, ka paziņojumiem ir jānāk tikai par vissvarÄ«gākajiem API SLO (pakalpojuma lÄ«meņa mērÄ·iem). SLO uzraudzÄ«ba ir pastāvÄ«gi sadrumstalota un sadalÄ«ta, un tai ir nepiecieÅ”ama vienāda pieeja visiem pakalpojumiem. Ir skaidrs, ka jÅ«s izsekosit svarÄ«gākajiem SLO klientiem, kuri jums maksā. Taču ir jāuzrauga arÄ« infrastruktÅ«ras SLO, piemēram, datu bāzes. DrÄ«zumā bÅ«s jātiek galā ar iekŔējiem klientiem un jāatbalsta tie. Un tā tālāk bezgalÄ«gi.

Pamatojoties uz simptomiem ā€“ uzsvars uz simptomiem

NeatkarÄ«gi no tā, vai jums tas patÄ«k vai nē, jÅ«s strādājat sadalÄ«tā sistēmā (Kavaj)2. Rezultātā jÅ«s izmantojat dažādas taktikas, lai izolētu pakalpojumus un pasargātu tos no neveiksmēm (Trainor et al.)3. Un, lai gan aizkavēta atkritumu savākÅ”ana vai apstājies datu bāzes vaicājums norāda uz problēmām, nav jāsteidzas ar to novērÅ”anu, ja lietotājiem tuvākajā nākotnē nebÅ«s problēmu.

Tie ir svarīgi signāli, un tiem var būt praktiska vērtība, taču, ja tie netraucē lietotājus, tad nav pietiekami steidzami novērst apkalpotāja uzmanību. Uz cēloņiem balstīti paziņojumi ir mūsu garīgo modeļu momentuzņēmumi par sistēmas kļūmi. Labāk ir izsekot svarīgiem simptomiem, nevis mēģināt uzskaitīt visus iespējamos neveiksmes cēloņus.

Lai paziņojumi bÅ«tu jēgpilni, koncentrējieties uz darbÄ«bas rādÄ«tāji, kas ir svarÄ«gi lietotājiem. EvaŔčuks to sauc par "lietotāju uzraudzÄ«bu". Atcerieties, ka Ŕī filozofija ir jāpiemēro visā organizācijā. Ja kādam dienestam radÄ«sies steidzamas problēmas kaut kur dziļi infrastruktÅ«rā, attiecÄ«gā komanda tos nokārtos. Sistēmu aizsardzÄ«ba pret Ŕādām kļūmēm ir pilnÄ«gi atseviŔķs jautājums (Trainer et al., sadaļa par stratēģijām kritisko atkarÄ«bu samazināŔanai).3.

Simptomi nav tik mainīgi

Ričards Kuks atgādina, ka sarežģītas sistēmas ir pilnas ar trÅ«kumiem, nepilnÄ«bām un problēmām4. Mēģinājums uzskaitÄ«t visus iespējamos iemeslus ir SÄ«zifa uzdevums. JÅ«s mēģināt aprakstÄ«t problēmas, bet tās visu laiku mainās. Sindija Å ridharana uzskata, ka "sistēmām nav jābÅ«t ideālā stāvoklÄ« katru sekundi" un labāk ir izmantot cilvēcÄ«gāku pieeju ("SadalÄ«to sistēmu novērojamÄ«ba" (ā€œSadalÄ«to sistēmu uzraudzÄ«baā€), 7)5.

Izvairieties no paziņojumiem pēc incidenta

Parasti paziņojumi par cēloņiem tiek konfigurēti, lai novērstu incidentus. Un Å”ie ierobežotie paziņojumi par notikuÅ”o rada maldÄ«gu droŔības sajÅ«tu, jo sistēma katru reizi nāk klajā ar jauniem veidiem, kā izlauzties.

Neļaujiet sevi apmānīt ar paziņojumiem par iemeslu. Labāk padomājiet:

  • Kāpēc uz simptomiem balstÄ«tais paziņojums nepamanÄ«ja problēmu?
  • Vai bÅ«tu noderÄ«gi uzlabot kontekstu lietotājam?
  • Kā uzlabot uzraudzÄ«bas rÄ«kus, lai ātrāk noteiktu diagnozi, nevis uzkrātu paziņojumus par notikuÅ”o?

Diagnozes uzraudzÄ«bas rÄ«ki palÄ«dzēs tikai tad, ja jÅ«s domājat par tiem kā veidu, kā pāriet no simptoma uz risinājumu. Bez Ŕīm atsauksmēm jÅ«s vienkārÅ”i saņemsit vēlu paziņojumus un diagrammas par pagātnes neveiksmēm un ne vārda par nākamajām. Å Ä« ir lieliska iespēja organizācijai pāriet no aizsardzÄ«bas uz uzbrukumu. Un izstrādātājiem un produktu vadÄ«tājiem bÅ«s tādas paÅ”as cerÄ«bas un skaidri mērÄ·i. Lieta - CASE (:wink:) - ir skaidrs katram paziņojumam.

Paziņojumi, kuru pamatā ir iemesls, ir pieļaujami mērenībā

Dažkārt mÅ«su sistēma mums atstāj maz izvēles saistÄ«bā ar paziņojumiem, kuru pamatā ir iemesls. Un dažreiz dežurējoÅ”ie lieliski saprot, ka simptoms noteikti novedÄ«s pie neveiksmes, un tāpēc tam ir praktiska vērtÄ«ba. VarbÅ«t jÅ«s vienkārÅ”i nezināt, kas notiek, un iestatāt paziņojumus, lai bÅ«tu droŔībā. Cerams, ka Ŕī darbÄ«ba ir Ä«slaicÄ«ga, lÄ«dz mēs varēsim mainÄ«t sistēmu, lai atrisinātu veiktspējas problēmu.
Risinot Ŕīs situācijas, paturiet prātā citus CASE komponentus. Tas, ka tas ir Ä«slaicÄ«gi, nenozÄ«mē, ka varat beigt domāt ar galvu.

Novērtēts - vērtējums

Jebkādas izmaiņas sistēmā (jauns kods, jauna infrastruktÅ«ra, jebkas jauns) paplaÅ”ina kļūdu loku (Kuks, 3).4 Vai Å”is paziņojums joprojām darbojas, kā paredzēts? Skaidri un aktuāli sistēmu mentālie modeļi un pieredze, reaģējot uz dažiem atbalsta paziņojumiem preventÄ«va pieeja - Ŕīs ir galvenās iezÄ«mes uz mācÄ«Å”anos orientēta organizācija. Sistēmu defekti nepārtraukti attÄ«stās, un mums tiem ir jāseko lÄ«dzi.

Jums pastāvÄ«gi jānovērtē katra paziņojuma kvalitāte, lai nodroÅ”inātu, ka tie darbojas, kā paredzēts. CienÄ«jamie vadÄ«tāji! JÅ«su komandām bÅ«s daudz vieglāk, ja palÄ«dzēsiet izveidot Å”o procesu! Å eit ir dažas novērtÄ“Å”anas idejas:

  • Izmantojiet haosa inženierija, spēļu dienas vai citas paziņojumu pārbaudes metodes. Komanda to var izdarÄ«t pati, nepaļaujoties uz smagu incidentu pārvaldÄ«bas sistēmu!
  • Iekļaujiet savā incidentu pārvaldÄ«bas programmā visu ar incidentiem saistÄ«to paziņojumu apkopoÅ”anu. AtzÄ«mējiet kā noderÄ«gus, kaitÄ«gus, nepiemērotus, neskaidrus utt. Izmantojiet tos kā atsauksmes.
  • Pareizie paziņojumi tiek aktivizēti reti un tiek rÅ«pÄ«gi pārbaudÄ«ti. Pārliecinieties, vai visas saites darbojas, norāda uz pareizo kontekstu utt.
  • Ja paziņojums nekad netiek aktivizēts vai tiek aktivizēts pārāk bieži, kaut kas ar to nav kārtÄ«bā. Labojiet vai noņemiet to. Uzmanieties no pārmērÄ«gas pasivitātes vai aktivitātes!
  • Iestatiet paziņojumu laikspiedolus ar derÄ«guma termiņu. Ja derÄ«guma termiņŔ ir beidzies, novērtējiet paziņojumu, izmantojot CASE metodi, un atjauniniet laika zÄ«mogu. Tāpat kā pārtikai, regulāri pārbaudiet derÄ«guma termiņu.
  • VienkārÅ”ojiet paziņojumu uzlaboÅ”anas procesu. Izmantojiet uzraudzÄ«bu kā kodu un uzglabājiet paziņojumus Git repozitorijā. IzvilkÅ”anas pieprasÄ«jumi palÄ«dz piesaistÄ«t komandu un sniegt jums iepriekŔējo paziņojumu vēsturi. Un jÅ«s vairs nebaidÄ«sities mainÄ«t paziņojumus vai lÅ«gt atļauju tiem, kas par tiem ir atbildÄ«gi.
  • Iestatiet atsauksmes par paziņojumiem, pat ja tas ir vienkārÅ”i Google veidlapa, lai dežuranti atzÄ«mētu paziņojumus kā nederÄ«gus vai uzmācÄ«gus. Ievietojiet saiti vai aicinājumu uz darbÄ«bu paŔā paziņojumā un regulāri pārskatiet savas atsauksmes.
  • Ieviesiet kolektÄ«vā noteikumu ā€“ ļaujiet dežurējoÅ”ajiem strādāt, lai atvieglotu pienākumu veikÅ”anu, kad darba ir maz. Lai viss pēc tevis ir mazliet labāks nekā bija iepriekÅ”.

Secinājums

Es uzskatu, ka CASE metode palÄ«dz izstrādātājiem un organizācijām apspriest automatizētu paziņojumu iestatÄ«Å”anu un nosÅ«tÄ«Å”anu. Viens izstrādātājs var sākt novērtēt paziņojumus, izmantojot CASE metodi, un pēc tam visa organizācija pievienosies citiem izstrādātājiem, pārvaldÄ«bas un incidentu pārvaldÄ«bas programmām, lai paziņojumi bÅ«tu labā formā. Tam nav nepiecieÅ”ami Ä«paÅ”i instrumenti vai sarežģīti procesi.

Visai nozarei dežūras laikā ir jādomā par cilvēcisko faktoru, nezaudējot visaugstāko klientu apkalpoÅ”anu. Visus Å”os rÄ«kus un prakses var un vajadzētu uzlabot. Es ceru, ka CASE metode palÄ«dzēs Å”ajā jautājumā.

Izbaudiet uzlabotus paziņojumus!
CASE metode: humāna uzraudzība

Avots: www.habr.com

Pievieno komentāru