Dziiiiin! Alas-tres na ng umaga, nananaginip ka, at biglang may tumawag. Naka-duty ka ngayong linggo, at tila may nangyari. Tumatawag ang automated system para malaman kung ano ang mali. Ito ay isang mahalagang aspeto ng pamamahala ng mga modernong computer system, ngunit tingnan natin kung paano gawing mas mahusay ang mga notification para sa mga tao.
Kilalanin ang pilosopiya sa pagsubaybay, na ipinanganak sa loob ng ilang dekada ng aking mga tungkulin sa iba't ibang mga koponan sa pagsubaybay. Siya ay higit na naimpluwensyahan ng totoong bibliya mula kay Rob Evashchuk (My Notification Philosophy) na kasama sa libro sa , at aklat ni John Alspaugh (Mga tala sa pag-set up ng mga alerto).
, ΠΈ β salamat sa iyong tulong sa pag-edit ng post.
Ano ang CASE?
Nagpasya akong magkaroon ng magandang abbreviation tulad ng o . tawag ko dito CASE paraan. Inilalarawan niya ang apat na puntos na dapat bigyang pansin kapag nagtatrabaho sa awtomatikong pagsubaybay:
- (nakatali sa konteksto)
- (praktikal na halaga)
- (diin sa mga sintomas)
- (grado)
Kung gumagamit ka ng CASE, tinatrato mo ang mga notification nang may malusog na pagwawalang-bahala at hindi ginigising ang mga tao sa gabi. Ang pagsubaybay ay dapat na regular na tasahin para sa pagiging kapaki-pakinabang at pagiging epektibo. Kapag natanggap ng isang tao ang abiso, magkakaroon sila ng mas mahusay na mga modelo ng pag-iisip at higit na kumpiyansa.
Para mas madaling matandaan, isipin na kailangan mo ng CASE [iyon ay, isang kaso, isang dahilan - tala ng tagasalin] upang bigyang-katwiran ang bawat alerto. :salaming pang-araw:
At bakit ganito ang lahat?
. Sa maraming dahilan. At hindi aalisin lahat ng CASE. Ngunit kasama nito, gigising ka sa gabi para sa mas magagandang notification. Sinasaklaw ng pamamaraang ito ang iba't ibang proseso ng organisasyon na makakatulong din sa bagay na ito.
Ang kagandahan ng RED at USE na pamamaraan ay na sa kanilang tulong hindi lamang natin alam kung paano magtrabaho, ngunit nagsasalita din ng parehong wika sa bawat isa. Ang aking pag-asa ay ang paraan ng CASE ay gawing mas madali ang pagtalakay sa mga abiso na nagpoprotekta sa aming mga system ngunit nagpapanatiling abala sa aming mga kasamahan.
Ang punto ay kailangan mong lumikha ng isang kultura sa iyong organisasyon kung saan ang mga notification ay tinatrato nang may malusog na pagwawalang-bahala. Maaaring gumawa ng mga notification para sa isang partikular na layunin, ngunit hindi isang katotohanan na hindi mawawalan ng halaga ang mga ito sa ibang pagkakataon. Bakit namin na-set up ang notification na ito? Gaano katagal na na-rebisa ang pamantayan nito? Sa CASE, masasagot ang mga tanong na ito.
Konteksto-Mabigat - konteksto na nagbubuklod
Ang 3 am ay hindi ang pinakamagandang oras para magbasa ng mga mensahe na naglalaman ng maraming matatalinong salita. Upang mabisang tumugon, kailangan mo ng impormasyon. Sa isip, ito ay dapat na impormasyon tungkol sa isang partikular na isyu, kung saan ang konteksto ay agad na malinaw, at ang mga notification ay dapat na i-configure upang ito ay posible. Ito ay "obserbasyon" at "orientation" mula sa . Hindi isang kahihiyan na gumugol ng oras sa setup na ito, dahil ang patuloy na nakakagambala sa isang tao ay mas mahal. Igalang natin ang isa't isa.
Maraming pinagmumulan ang mga problema. Lalo na ang mga multo.
Paano ko matutulungan ang duty officer? Ang unang bagay na nakikita ng opisyal ng tungkulin ay isang abiso, kaya binubuo niya ang lahat ng mga hypotheses batay dito. Pagkatapos ay tumitingin siya sa mga tagubilin at dashboard, ngunit palaging may data sa isang partikular na notification, at hindi lang pangkalahatang impormasyon? Pinapayuhan ni Alspaugh ang "pag-iisip tungkol sa kung paano mo maaaring bigyang-kahulugan o tumugon sa abiso" (slide 29). Ang isang magandang notification ay nakatuon sa taong naka-duty, hindi lamang na-configure ng isang threshold.
Kaya narito ang ilang ideya kung paano pahusayin ang konteksto ng notification:
- Ipakita sa user ang isang bagay na kapaki-pakinabang at espesyal na nilikha, at hindi lamang ordinaryong mga tagubilin o isang dashboard. Dati, kami ng mga lalaki ay gumamit ng mga investigative dashboard na na-configure para sa mga partikular na notification. Makakatulong ito kung alam ang problema, ngunit malito lamang ang iba. Kailangan nating makahanap ng balanse dito.
- Sabihin sa amin ang tungkol sa kasaysayan ng notification: bago ba ito? Madalas ba itong gumagana? seasonal ba?
- Ipakita ang mga kamakailang pagbabago sa estado ng system. May nagbago ba kamakailan? (Halimbawa, pag-deploy o pagpapagana/pag-disable ng functionality.)
- Ipakita ang mga relasyon at magbigay ng impormasyon para sa mental model: ang mga dependency ng system ay dapat na malinaw na nakikita, mas mabuti na may indikasyon ng functionality.
- Mabilis na ikonekta ang user sa team: nakakakita ba sila ng mga nangyayaring insidente o maaari nilang malaman kung sino pa sa kumpanya ang nakatanggap ng notification? Programa activated?
Sa isip, ang isang programa sa pamamahala ng insidente ay magbibigay ng payo kung paano pagbutihin ang konteksto ng notification ng mga pagsisiyasat sa insidente. Palaging may dapat gawin!
Naaaksyunan - praktikal na halaga
Dapat bang gumawa ng isang bagay ang opisyal ng tungkulin bilang tugon sa abiso? Kung wala kang kailangang gawin o hindi malinaw kung ano ang gagawin, bakit mo siya ginising? Kailangan mong iwasan ang mga abiso na nakakainis sa mga naka-duty at hindi nangangailangan ng aksyon.
Anong gagawin ko? Anong gusto mo?
Noong nakaraan, kapag ang mga system ay simple at ang mga koponan ay maliit, nag-set up kami ng pagsubaybay para lang manatili sa itaas ng mga bagay. Ang abiso na ang pag-load sa heap ay tumaas ay magbibigay sa amin ng konteksto kung ang serbisyo ay magkakasunod na hindi gumagana. Sa malaking sukat, lilikha lamang ng kalituhan ang mga naturang notification dahil palaging tumatakbo ang aming mga system sa isang estado ng pagkasira ng iba't ibang kalubhaan. Mabilis itong humahantong sa at, siyempre, sa pagkawala ng sensitivity. Samakatuwid, binabalewala o sinasala ng opisyal ng tungkulin ang mga naturang notification at hindi palaging tumutugon sa mga ito kung kinakailangan. Huwag mahulog sa bitag na ito! Huwag i-set up ang lahat ng notification nang sunud-sunod at pagkatapos ay ipadala ang mga ito sa pamamagitan ng email sa ilang folder na pinabayaan ng Diyos.
Ganito ang hitsura ng notice na may praktikal na halaga:
- Ang isang abiso ay nangangailangan ng pagkilos sa halip na mag-ulat lamang ng balita.
- Ang pagkilos na ito ay mahirap o mapanganib na i-automate. Kung ang isang aksyon ay maaaring awtomatiko, pagkatapos ay i-automate ito, itigil ang pang-aapi sa mga tao!
- Ang paunawa ay naglalaman ng mga kagyat na rekomendasyon sa form (SLA) o (RTO). Pagkatapos ay maaaring i-activate ng opisyal ng tungkulin ang programa ng pamamahala ng insidente ng organisasyon.
Nais kong linawin: Hindi ko sinasabi na ang mga abiso ay dapat lamang dumating para sa pinakamahalagang SLO (mga layunin sa antas ng serbisyo) para sa API. Ang pagsubaybay sa SLO ay patuloy na pira-piraso at nahahati at nangangailangan ng parehong diskarte sa lahat ng mga serbisyo. Malinaw na susubaybayan mo ang pinakamahalagang SLO para sa mga kliyenteng nagbabayad sa iyo. Ngunit ang mga SLO ng imprastraktura, tulad ng mga database, ay kailangan ding subaybayan. Sa lalong madaling panahon kailangan mong harapin ang mga panloob na customer at suportahan sila. At iba pa ang ad infinitum.
Batay sa sintomas - diin sa mga sintomas
Gustuhin mo man o hindi, nagtatrabaho ka sa isang distributed system (Kavaj). Bilang resulta, gumamit ka ng iba't ibang taktika upang ihiwalay ang mga serbisyo at protektahan ang mga ito mula sa pagkabigo (Trainor et al.)3. At kahit na ang isang naantalang koleksyon ng basura o isang natigil na query sa database ay nagpapahiwatig ng mga problema, hindi na kailangang magmadali upang ayusin ang mga ito kung ang mga gumagamit ay walang mga problema sa malapit na hinaharap.
Ang mga ito ay mahalagang mga senyales at maaaring may praktikal na halaga, ngunit kung hindi sila nakakaabala sa mga gumagamit, kung gayon ito ay hindi sapat na kagyat upang makagambala sa attendant. Ang mga notification na nakabatay sa sanhi ay mga snapshot ng aming mga mental model tungkol sa isang pagkabigo ng system. Mas mainam na subaybayan ang mahahalagang sintomas kaysa subukang ilista ang lahat ng posibleng dahilan ng pagkabigo.
Para gawing makabuluhan ang mga notification, tumuon sa , mahalaga sa mga gumagamit. Tinatawag ito ni Evashchuk na "pagsubaybay para sa mga gumagamit." Tandaan na ang pilosopiyang ito ay dapat ilapat sa buong organisasyon. Kung ang isang serbisyo ay may mga kagyat na problema sa isang lugar na malalim sa imprastraktura, ang naaangkop na pangkat ang bahala sa kanila. Ang pagprotekta sa mga system mula sa gayong mga pagkabigo ay isang ganap na hiwalay na bagay (Trainer et al., seksyon sa mga estratehiya para sa pagliit ng mga kritikal na dependency).
Ang mga sintomas ay hindi nagbabago
Pinapaalalahanan tayo ni Richard Cook na ang mga kumplikadong sistema ay puno ng mga bahid, pagkukulang at problema. Ang pagsisikap na ilista ang lahat ng posibleng dahilan ay isang gawaing Sisyphean. Sinusubukan mong ilarawan ang mga problema, ngunit nagbabago ang mga ito sa lahat ng oras. Naniniwala si Cindy Sridharan na "hindi kailangang nasa perpektong kondisyon ang mga sistema bawat segundo" at mas mabuting gumamit ng mas makatao na diskarte ( (βPagsubaybay sa Ibinahagi na Sistemaβ), 7).
Iwasan ang mga abiso pagkatapos ng isang insidente
Karaniwan, ang mga abiso para sa mga sanhi ay naka-configure upang iwasto ang mga insidente. At ang mga limitadong notification na ito tungkol sa katotohanan ng nangyari ay lumilikha ng isang maling pakiramdam ng seguridad, dahil ang system sa bawat oras ay may mga bagong paraan upang masira.
Huwag magpalinlang sa mga abiso ng dahilan. Mas mabuting isipin:
- Bakit hindi napansin ng notification na batay sa sintomas ang problema?
- Makakatulong ba na mapabuti ang konteksto para sa user?
- Paano mapapabuti ang mga tool sa pagsubaybay upang makagawa ng diagnosis nang mas mabilis, sa halip na makaipon ng mga abiso tungkol sa nangyari?
Ang mga tool sa pagsubaybay para sa diagnosis ay makakatulong lamang kung iisipin mo ang mga ito bilang isang paraan upang lumipat mula sa sintomas patungo sa solusyon. Kung wala ang feedback na ito, mabobomba ka lang ng mga late notification at chart tungkol sa mga nakaraang pagkabigoβat hindi isang salita tungkol sa mga hinaharap. Ito ay isang magandang pagkakataon para sa isang organisasyon na lumipat mula sa depensa patungo sa pag-atake. At magkakaroon ng parehong mga inaasahan at malinaw na layunin ang mga developer at product manager. Ang kaso - CASE (:wink:) - ay malinaw para sa bawat notification.
Ang mga notification na nakabatay sa dahilan ay matitiis sa katamtaman
Minsan ang aming system ay nagbibigay sa amin ng kaunting pagpipilian sa mga tuntunin ng mga abiso na batay sa sanhi. At kung minsan ang mga nasa tungkulin ay lubos na nauunawaan na ang isang sintomas ay tiyak na hahantong sa isang pagkabigo, at samakatuwid ay naglalaman ng praktikal na halaga. Baka hindi ka lang sigurado kung ano ang nangyayari at nagse-set up ka ng mga notification para maging ligtas. Sana ay pansamantala lang ang pagkilos na ito hanggang sa mabago natin ang system para maresolba ang isyu sa performance.
Isaisip ang iba pang bahagi ng CASE kapag nakikitungo sa mga sitwasyong ito. Hindi nangangahulugan na ito ay pansamantala lamang na maaari mong ihinto ang pag-iisip gamit ang iyong ulo.
Nasusuri - pagsusuri
Anumang mga pagbabago sa system (bagong code, bagong imprastraktura, anumang bago) ay nagpapalawak ng hanay ng mga pagkabigo (Cook, 3). Gumagana pa rin ba ang notification na ito gaya ng inaasahan? Malinaw at kasalukuyang mga mental na modelo ng mga system at karanasan sa pagtugon sa ilang mga notification sa suporta - ito ang mga pangunahing tampok . Ang mga depekto sa mga sistema ay patuloy na umuunlad, at dapat nating sundin ang mga ito.
Kailangan mong patuloy na suriin ang kalidad ng bawat notification upang matiyak na gumagana ang mga ito gaya ng inaasahan. Mahal na mga pinuno! Magiging mas madali para sa iyong mga koponan kung tutulungan mo silang itatag ang prosesong ito! Narito ang ilang ideya sa pagtatasa:
- Gamitin , o iba pang paraan ng pagsubok sa notification. Magagawa ito mismo ng team nang hindi umaasa sa isang mabigat na sistema ng pamamahala ng insidente!
- Isama ang koleksyon ng lahat ng notification na nauugnay sa insidente sa iyong programa sa pamamahala ng insidente. Markahan ang kapaki-pakinabang, nakakapinsala, hindi naaangkop, hindi malinaw, atbp. Gamitin ang mga ito bilang feedback.
- Ang mga tamang notification ay madalang na na-trigger at maingat na sinusuri. Tiyaking gumagana ang lahat ng link, tumuturo sa tamang konteksto, atbp.
- Kung ang isang abiso ay hindi kailanman magpapagana o gumagana nang masyadong madalas, may mali dito. Ayusin ito o tanggalin ito. Mag-ingat sa labis na pagiging pasibo o aktibidad!
- Magtakda ng mga timestamp ng notification na may mga petsa ng pag-expire. Kung nag-expire na ang expiration date, suriin ang notification gamit ang CASE method at i-update ang timestamp. Tulad ng pagkain, regular na suriin ang petsa ng pag-expire.
- Pasimplehin ang proseso ng pagpapabuti ng mga notification. Gamitin ang pagsubaybay bilang code at mga notification sa store sa isang Git repository. Ang mga kahilingan sa pull ay nakakatulong sa pakikipag-ugnayan sa team at nagbibigay sa iyo ng kasaysayan ng mga nakaraang notification. At hindi ka na matatakot na baguhin ang mga notification o humingi ng pahintulot mula sa mga responsable para sa kanila.
- Mag-set up ng feedback para sa mga notification, kahit na simple lang ito , upang markahan ng mga opisyal ng tungkulin ang mga abiso bilang walang silbi o mapanghimasok. Mag-embed ng link o call to action sa mismong notification at regular na suriin ang iyong feedback.
- Magtatag ng panuntunan sa pangkat - hayaan ang mga naka-duty na magtrabaho upang pasimplehin ang tungkulin kapag kakaunti ang trabaho. Nawa'y maging mas mabuti ang lahat pagkatapos mo kaysa sa dati.
Konklusyon
Naniniwala ako na ang paraan ng CASE ay nakakatulong sa mga developer at organisasyon na talakayin ang pag-set up at pagpapadala ng mga awtomatikong notification. Maaaring magsimulang mag-assess ng mga notification ang isang developer gamit ang paraan ng CASE, at pagkatapos ay sasali ang buong organisasyon sa iba pang mga developer, pamamahala, at mga programa sa pamamahala ng insidente upang panatilihing nasa mabuting kalagayan ang mga notification. Hindi ito nangangailangan ng anumang mga espesyal na tool o kumplikadong proseso.
Ang buong industriya ay kailangang mag-isip tungkol sa kadahilanan ng tao habang nasa tungkulin nang hindi sinasakripisyo ang nangungunang serbisyo sa customer. Ang lahat ng mga tool at kasanayang ito ay maaari at dapat pagbutihin. Umaasa ako na ang pamamaraan ng CASE ay makakatulong dito.
I-enjoy ang mga pinahusay na notification!
Pinagmulan: www.habr.com