CASE meetod: inimsõbralik jälgimine

Ziiiiiing! Kell on 3 hommikul, te vaatate imelisi unenägusid ja äkki – heliseb telefon. Sellel nädalal olete vahetuses ja tundub, et midagi on juhtunud. Automatiseeritud süsteem kutsub teid olukorra lahendama. See on oluline hetk kaasaegsete arvutisüsteemide halduses, kuid vaatame, kuidas teha teavitusi inimestele mugavamaks.

Tutvuge jälgimise filosoofiaga, mis on sündinud aastate jooksul minu vahetuste ajal erinevates jälgimismeeskondades. Sellele on palju mõjutanud Robert Evasiuki tõeline piibel. Minu Filosoofia Teavitamisest (Minu teavitamisfilosoofia), mis on kaasatud raamatusse Google SRE, ja John Olspoa raamat Mõjuhinnangud Teavitamise Ahnidusele (Mõjuhinnangud teavitamise väljatöötamisel).

Kelly Dunn, Arijit Mukherjee ja Maksim Petaccioni — tänu postituse redigeerimise abi eest.

Mis on CASE?

Otsustasin välja mõelda ilusa akronüümi nagu Brendan Greggi USE meetod või Tom Wilki RED meetod. Ma nimetasin seda CASE meetodiks.See kirjeldab nelja aspekti, millele tähelepanu pöörata automatiseeritud jälgimise tööde juures:

• Ckonteksti sidumine (context-heavy)
• Ateostatav (actionable)
• Ssümptomi põhine (symptom-based)
• Ehindamine (evaluated)

Kui kasutate CASE-meetodit, suhtute teavitustesse tervisliku ükskõiksusega ja ei ärata inimesi öösel üles. Jälgimist tuleb regulaarselt hinnata kasutegurite ja tõhususe osas. Kui inimene saab teavituse, on tal paremad vaimsed mudelid ja rohkem enesekindlust.

Kergemini meeles pidamiseks kujutage ette, et vajate CASE [st juhtum, põhjus — tõlkija märk.] , et õigustada igat teavitust. :sunglasses:

Ja miks see kõik vajalik on?

Vahetuses olemine võib olla piinav.Paljude põhjuste tõttu. Ja CASE ei eemalda neid kõiki. Kuid selle abil ärkate öösel kvaliteetsemate teavituste tõttu. See meetod katab erinevaid organisatsioonilisi protsesse, mis aitavad samuti sellele kaasa.

RED ja USE meetodite ilu seisneb selles, et nende abil teame mitte ainult, kuidas töötada, vaid räägime ka omavahel ühe ja sama keele. Loodan, et CASE meetodiga on lihtsam arutada teavitusi, mis kaitsevad meie süsteeme, aga ei võimalda kolleegidel rahu.

Oluline on luua organisatsioonis kultuur, kus teated võtavad vastu rahulikult ja teadmisega. Teateid võib koostada põhjendatult, kuid see ei tähenda, et nad hiljem oma väärtust ei kaota. Miks me selle teate seadistame? Kas selle kriteeriumid on hiljuti üle vaadatud? Nendele küsimustele saa vastuseid CASE'iga.

Kontextile orienteeritud — konteksti sidumine

Kell 3 öösel ei ole parim aeg lugeda sõnumeid, mis sisaldavad palju keerulisi sõnu. Efektiivseks reageerimiseks on vajalik teave. Ideaalis peaks see olema teave konkreetse probleemi kohta, kus kontekst oleks kohe selge, ja teated tuleks seadistada nii, et see oleks võimalik. See on "vaatlemine" ja "suunamine" NORDi tsüklist. Selles seadistamisse tasub aega kulutada, sest pidev inimese segamine on veel kallim. Austagem üksteist.

Probleemidel on palju allikaid. Eriti varjatud.

Kuidas aidata valvepersonalil? Esimesena näeb valvepersonal teadet, mistõttu kõik hüpoteesid põhinevad sellel. Siis vaatab ta juhiseid ja juhtpaneele, kuid kas seal on alati konkreetse teate kohta andmeid, mitte ainult üldine teave? Olsp soovitab "mõelda, kuidas teavet tõlgendada või sellele reageerida" (slaid 29)1. Hea teade on suunatud valvepersonali poole, mitte lihtsalt seadistatud künnise põhjal.

Siin on ideed, kuidas parandada teate konteksti:

• Kasutajale tuleks näidata midagi kasulikku ja spetsiaalselt loodud, mitte lihtsalt tavalisi juhiseid või juhtpaneeli. Varem kasutasime koos kaaslastega konkreetsete teadete jaoks seadistatud juhtpaneele uurimiseks. See aitab, kui probleem on tuntud, kuid segab teisi juhtudel. Siin tuleb leida tasakaal.
• Rääkige teate ajaloost: kas see on uus? Kas see aktiviseerub sageli? Kas see on hooajaline?
• Näidake süsteemi oleku viimaseid muudatusi. Kas hiljuti midagi muutus? (Näiteks juurutus või funktsionaalsuse sisse-/väljalülitamine.)
• Kuvage seosed ja andke teavet vaimse mudeli jaoks: süsteemi sõltuvused peaksid olema selgelt nähtavad, eelistatavalt tähistades töökindlust.
• Siduge kasutaja kiiresti meeskonnaga: kas ta näeb käimasolevaid intsidente või saab teada, kes veel ettevõttes teate sai? Programmi intsidentide haldamine aktiveeritud?

Ideaalis annab intsidentide haldamise programm nõuandeid, kuidas parandada teavituste konteksti intsidentide uurimisel. Alati on, mille kallal töötada!

Tegevusväärtus — praktiline väärtus

Kas valveisik peab midagi tegema teavituse peale? Kui ei pea midagi tegema või pole selge, mida teha, miks siis äratada? Tuleb vältida teateid, mis häirivad valveisikuid, kuid ei nõua tegevust.

Vaata postitust imgur.com-is

Mida teha siis? Mida on vaja?

Varem, kui süsteemid olid lihtsad ja meeskonnad väikesed, seadistasime jälgimise, et lihtsalt kursis olla. Teave selle kohta, et koormus on tõusnud, annab meile konteksti, kui teenus hakkab hiljem tõrkuma. Suures ulatuses segavad sellised teated ainult segadust, sest meie süsteemid töötavad alati erineva raskusastmega degradeerimise seisundis. See viib kiiresti teate väsimuseni ja, muidugi, tundlikkuse kadumiseni. Seetõttu ignoreerib valveisik või isegi filtreerib selliseid teateid ja reageerib neile mitte alati, nagu vajalik. Ärge jääge sellesse lõksu! Ärge seadistage kõiki teateid järjest, et saata need seejärel e-postiga mingisse jumala unustatud kausta.

Nii näeb välja teade, millel on praktiline väärtus:

• Teade nõuab tegevust, mitte lihtsalt ei edasta uudiseid.
• See tegevus on keeruline või riskantne automatiseerida. Kui tegevust saab automatiseerida, siis tehke seda ja lõpetage inimeste tüütamine!
• Teade sisaldab kiireid soovitusi kujul teenuse taseme kokkulepe (SLA) või eesmärgilisest taastamisaeg (RTO). Siis saab valveisik rakendada intsidentide haldamise programmi organisatsioonis.

Tahaksin täpsustada: ma ei ütle, et teated peaksid tulema ainult kõige olulisemate SLO-de (teenuse taseme eesmärkide) kohta API-de jaoks. SLO-de jälgimine jaguneb pidevalt ja nõuab samasugust lähenemist kõigile teenustele. Loomulikult jälgite kõige olulisemaid SLO-sid klientide jaoks, kes teid toetavad. Kuid ka infrastruktuuri SLO-sid, näiteks andmebaase, tuleb jälgida. Varsti peate tegelema siseklientidega ja neid toeks olema. Ja nii lõputult.

Sümptomipõhine — rõhk sümptomitele

Meeldib see teile või mitte, kuid te töötate jaotatud süsteemis (Kavadž)2. Seetõttu kasutate erinevaid taktikaid teenuste isolatsiooniks ja nende kaitsmiseks häirete eest (Treinor jt). Ja kuigi veniv prügikogumine või mõtlema jääv päring andmebaasi viitab probleemidele, ei pea te neid kohe lahendama, kui kasutajatel ei ole lähitulevikus probleeme.

Need on olulised signaalid, ja nad võivad olla praktilise väärtusega, kuid kui need ei sega kasutajaid, siis pole need piisavalt kiireloomulised, et häirida vahetuses olevat töötajat. Põhjusepõhised teavitused on meie vaimsete mudelite peegeldused süsteemi tõrkest. Olulisem on jälgida olulisi sümptomeid, kui proovida loetleda kõiki võimalikke tõrke põhjuseid.

Kuna teavitustel on praktiline väärtus, keskenduge tulemuste näitajaile, mis on kasutajatele olulised. Evashchuk nimetab seda "kasutajate jälgimiseks". Pea meeles, et seda filosoofiat tuleb rakendada kogu organisatsioonis. Kui teenusel tekivad kusagil infrastruktuuri sügavustes kiireloomulised probleemid, tegeleb nendega vastav meeskond. Süsteemide kaitsmine selliste tõrkete eest on täiesti eraldi küsimus (Treiner jt, peatükk kriitiliste sõltuvuste vähendamise strateegiate kohta)3.

Sümptomid ei ole nii muutlikud

Richard Cook meenutab, et keerulistes süsteemides on palju vigu, puudusi ja probleeme4. Proovida loetleda kõiki võimalikke põhjuseid on Sisyphos' töö. Te proovite kirjeldada probleeme, kuid need muutuvad kogu aeg. Cindy Shridharan peab seda, et "süsteemid ei pea olema iga sekund ideaalsetes tingimustes" ja on parem kasutada inimlikumat lähenemist ("jaotatud süsteemide jälgimine" ("Distributed Systems Observability"), 7)5.

Vältige teavitusi tõrke fakti kohta

Tavaliselt käivitatakse tõrgete parandamiseks teavitused põhjuste osas. Ja need piiratud teavitused juhtumist loovad vale enesekindluse, kuna süsteem leiutab iga kord uusi viise purunemiseks.

Ärge petke end põhjuste teavitustega. Mõelge pigem:

• Miks ei märganud sümptomite põhjalik teavitus probleemi?
• Kas konteksti parandamine kasutaja jaoks oleks kasulik?
• Kuidas parandada jälgimisriistu, et kiiremini diagnoose panna, mitte tekitada teateid toimunud juhtumitest?

Jälgimisriistad diagnoosimiseks on abiks vaid siis, kui te käsitlete neid viisina, kuidas liikuda sümptomist lahenduse poole. Ilma tagasisideta jääte lihtsalt hilinenud teatega ja diagrammidega möödunud tõrgetest — ja tulevikust ei ole sõnagi. See on suurepärane võimalus organisatsioonile liikuda kaitsepositsioonilt rünnaku positsioonile. Arendajatel ja tootetegevuse juhtidel on selged ootused ja arusaadavad eesmärgid. Iga teate juhtum — CASE (:wink:) — on selge.

Põhjusel põhinevad teated on mõõdukas koguses talutavad

Mõnikord ei jäta meie süsteem meile peaaegu üldse valikut põhjusel põhinevate teadete osas. Mõnikord mõistavad valvepersonalid hästi, et sümptom viib kindlasti tõrkedeni, seega sisaldab see praktilist väärtust. Võib-olla te lihtsalt ei ole kindel, mis toimub, ja kohandate teateid ettevaatusabinõuna. Lootkem, et see tegevus on ajutine, kuni te saame süsteemi muuta, et lahendada jõudluse langemise probleem.
Pidage meeles teisi CASE komponente, kui te tegelete selliste olukordadega. Kui see on ajutine, ei tähenda see, et peaksite mõtlema vähem.

Evaluated — hindamine

Iga muudatus süsteemis (uus kood, uus infrastruktuur, mis tahes uus) laiendab tõrkede valikut (Kuk, 3).4 Kas see teade töötab endiselt ootuspäraselt? Selged ja ajakohased vaimsed mudelid süsteemidest ja kogemused teatud teadete vastu reageerimisel toetavad ennetavat lähenemist — need on võtmeomadused õppimist toetavas organisatsioonis. Süsteemide defektid arenevad pidevalt ja me peame nendega sammu pidama.

On vajalik pidevalt hinnata iga teate kvaliteeti, et need töötaksid vastavalt ootustele. Head juhid! Teie meeskondadel on palju lihtsam, kui aitate neil selle protsessi korraldada! Siin on mõned ideed hindamiseks:

• Kasutage kaose inseneri, mängupäevad või muud teadete testimise meetodid. Meeskond võib seda teha iseseisvalt, ilma kohusta süsteemi haldamise kaasamiseta!
• Käivita teavituste andmete kogumine kõikidest intsidentidega seotud teavitustest intsidentide juhtimise programmides. Märgi need, mis on kasulikud, kahjulikud, sobimatud, arusaamatud jne. Kasuta neid tagasiside jaoks.
• Õiged teavitused aktiveeruvad harva ja on hoolikalt kontrollitud. Veendu, et kõik lingid töötavad, suunates õigesse konteksti jne.
• Kui teavitus ei aktiveeru kunagi või aktiveerub liiga tihti, pole kõik korras. Paranda see või eemalda. Ole ettevaatlik liigse passiivsuse või aktiivsuse eest!
• Seadista teavitustele aegumiskuupäevadega ajatempleid. Kui aegumine on möödas, hinda teavitust CASE meetodi järgi ja uuenda ajatemplit. Kontrolli aegumiskuupäevi regulaarselt, nagu toidu puhul.
• Lihtsusta teavituste täiendamise protsessi. Kasuta koodiga jälgimist ja hoia teavitusi Git'i hoidlas. Pull-request'id aitavad meeskonda kaasata ning sul on olemas eelmiste teavituste ajalugu. Sa ei pea enam kartma teavitusi muuta või küsima luba neile, kes nende eest vastutavad.
• Käivita tagasiside teavituste jaoks, isegi kui see on lihtsalt Google'i vorm, et vahetused märkiksid teavitusi kui kasulikke või tüütuid. Sisesta teavituse sisse link või tegevuskutse ja vaata tagasisidet regulaarselt.
• Seadke meeskonnas reegel — las vahetused töötavad vahetuste lihtsustamise nimel, kui tööd on vähe. Las järgmisel inimesel oleks kõik natuke parem kui eelnevalt.

Kokkuvõte

Ma usun, et CASE meetod aitab arendajatel ja organisatsioonidel arutada automaatsete teavituste seadistamist ja saatmist. Üks arendaja võib alustada teavituste hindamist CASE meetodi järgi ning hiljem liitub kogu organisatsioon teiste arendajate, juhtkonna ja intsidentide juhtimise programmidega, et hoida teavitused heas seisukorras. Selleks ei ole vaja mingeid erilisi tööriistu ega keerulisi protsesse.

Kogu tööstus peaks kaaluma inimfaktorit vahetuses, ilma et see mõjutaks esmaklassilist klienditeenindust. Kõiki neid tööriistu ja praktikaid saab ja tuleb täiustada. Loodan, et CASE meetod aitab selle saavutada.

Naudi täiustunud teavitusi!

Allikas: habr.com