CASE meetod: inimlik järelevalve

Dziiiiiiiin! Kell on 3 hommikul, te vaatate ilusat und ja äkki — kõne. Sellel nädalal olete dežuuris ja tundub, et midagi juhtus. Automaatsüsteem kutsub välja selgitama, mis on juhtunud. See on oluline aspekt kaasaegsete arvutisüsteemide haldamisel, kuid vaatame, kuidas teha teavitused inimestele mugavamaks.

Tutvuge järelevalve filosoofiaga, mis on loodud pärast mitmeid aastate pikkuseid dežuurimisi erinevates järelevalvemeeskondades. Sellele mõjutas väga Rob Evashtuki tõeline piibel. Minu filosoofia teavitamisel (Minu teavituse filosoofia), mis on kaasatud raamatust Google SRE, ja John Olspoe raamatust Teavituste kujundamise kaalutlused (Teavituste seadistamise märkused).

Kelly Dunn, Aridjit Mukherjee ja Massimo Petazzoni — aitäh abi eest postituse toimetamisel.

Mis on CASE?

Otsustasin välja mõelda kena lühendi, nagu Brendan Greggi USE meetod või Tom Wilke RED meetod. Ma kutsun seda CASE meetodiks. See kirjeldab nelja aspekti, millele tuleb tähelepanu pöörata automaatse järelevalve korral:

• Ckontext-tugev (kontexthõng)
• Ategevusväärne (praktiline väärtus)
• Ssümptomipõhine (fookus sümptomitel)
• Ehindamine (hindamine)

Kui kasutate CASE'i, suhtub te häiretesse rahulikult ja ei ärata inimesi öösel. Regulaarne hindamine on oluline, et kindlaks teha, kui kasulikud ja efektiivsed need on. Kui inimene saab häire, on tal paremad vaimsed mudelid ja rohkem enesekindlust.

Kergemini meeldejätmiseks kujutage ette, et vajate CASE'i [ehk juhtumit, põhjust — tõlkija märk.], et õigustada iga teavitust. 😎

Ja miks see kõik?

Vahtimine võib olla piinav. Paljusid põhjuseid. Ja CASE ei suuda neid kõiki kõrvaldada. Kuid öösel ärkate te kvaliteetsemate häirete tõttu. See meetod hõlmab erinevaid organisatsioonilisi protsesse, mis aitavad samuti selles küsimuses.

Meetodite RED ja USE ilu seisneb selles, et nende abil teame, kuidas töötada, ja suhtleme omavahel ühes keeles. Loodan, et CASE meetodiga on hõlpsam rääkida häiretest, mis kaitsevad meie süsteeme, kuid ei lase kolleegidel rahu saada.

Küsimus on selles, et organisatsioonis tuleb luua selline kultuur, kus teavitustele suhtub tervet mõistust kasutades. Teavitusi võib luua olulistel põhjustel, kuid ei ole kindel, et need hiljem väärtust ei kaota. Miks me selle teavituse sättisime? Kas selle kriteeriume on hiljuti üle vaadatud? CASE annab vastuseid nendele küsimustele.

Kontekstitundlik — konteksti sidumine

Kell 3 öösel pole parim aeg lugeda teateid, kus on palju keerulisi sõnu. Efektiivseks reageerimiseks on vajalik teave. Ideaalses olukorras peaks see olema teave konkreetse probleemi kohta, mille puhul on kohe selge kontekst, ning teavitusi tuleb seadistada nii, et see oleks võimalik. See on "tähelepanu" ja "suunamine" NORDi tsüklisse. Selle seadistamise jaoks ei ole kahju aega kulutada, sest pidev inimese segamine on veel kallim. Austagem üksteist.

Probleemide allikaid on palju. Eriti vaimud.

Kuidas aidata vahetust? Esmalt märkab vahetus teadet, seega põhinevad kõik hüpoteesid sellel. Siis vaatab ta juhiseid ja juhtpaneele, kuid kas seal on alati konkreetse teate kohta andmeid, mitte ainult üldine teave? Olspo soovitab "mõelda, kuidas teadet tõlgendada või sellele reageerida" (slaid 29)1. Hea teade on suunatud vahetusele, mitte lihtsalt seadistatud künnise põhjal.

Seega siin on ideed, kuidas parandada teadete konteksti:

• Näidake kasutajale midagi kasulikku ja spetsiaalselt loodud, mitte lihtsalt tavalisi juhiseid või juhtpaneeli. Varem kasutasime koos tiimiga juhtpaneele uurimiseks, mis olid seadistatud konkreetsete teadete jaoks. See aitab, kui probleem on tuntud, ja segab teistes olukordades. Siin tuleb leida tasakaal.
• Rääkige teate ajaloost: kas see on uus? Kas see aktiveerub sageli? Kas see on hooaegadega seotud?
• Näidake hiljutisi muudatusi süsteemi seisundis. Kas midagi on hiljuti muutunud? (Näiteks juurutamine või funktsiooni aktiveerimine/deaktiveerimine.)
• Kuvaa suhteet ja tarjoa tietoa mielikuvamallille: järjestelmän riippuvuudet tulisi olla selkeästi näkyvissä, mieluiten toimintakyvystä kertomalla.
• Yhdistä käyttäjä nopeasti tiimiin: näkeekö hän nykyiset häiriöt tai voiko hän selvittää, kuka muu yrityksessä on saanut ilmoituksen? Onko ohjelma häiriöiden hallinta käynnissä?

Ihanteellisesti häiriöhallintaohjelma antaa neuvoja siitä, kuinka parantaa ilmoituksen kontekstia häiriöiden tutkimisessa. Tässä on aina parannettavaa!

Toimintavalmius — käytännön arvo

Onko päivystävän tehtävä reagoida ilmoitukseen? Jos mitään ei tarvitse tehdä tai ei ole selvää, mitä tehdä, miksi herätettiin? On vältettävä ilmoituksia, jotka häiritsevät päivystäjiä eivätkä vaadi toimia.

Vaata postitust imgur.com-is

Mitä tehdä? Mitä tarvitaan?

Varem, kui süsteemid olid lihtsad ja meeskonnad väikesed, seadistasime jälgimise, et lihtsalt kursis olla. Teade kogumise koormuse suurenemisest annab meile konteksti, kui teenus hiljem hakkab tõrkuma. Suures ulatuses segavad sellised teated ainult, kuna meie süsteemid töötavad alati erineva tõsidusega degratsiooni seisundis. See toob kiiresti kaasa teadete väsimuse ja muidugi tundlikkuse kadumise. Seetõttu ignoreerib valvepersonal selliseid teateid või isegi filtreerib need, mistõttu nad ei reageeri alati õigesti. Ärge lonkige sellisesse lõksu! Ärge seadistage kõiki teadetäit, et hiljem saata need mõnda unustatud kausta.

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

• Teade nõuab tegevust, mitte lihtsalt ei jagab uudiseid.
• See tegevus on keeruline või riskantne automatiseerida. Kui tegevust saab automatiseerida, siis automatiseerige see ja ärge segage inimesi!
• Teade sisaldab kiireid soovitusi teenusetaseme kokkuleppest (SLA) või sihtotstarvestusaja (RTO). Sel juhul saab vahetusjuht kasutusele võtta organisatsiooni intsidentide juhtimise programmi.

Soovin täpsustada: ma ei ütle, et teavitused peaksid tulema ainult kõige olulisemate SLO-de (teenuse taseme eesmärkide) järgi API-le. SLO-de jälgimine jaguneb pidevalt ja nõuab kõigi teenuste suhtes ühtset lähenemist. Loomulikult jälgite kõige olulisemaid SLO-sid klientide jaoks, kes teile maksavad. Kuid taas on ka infrastruktuuri SLO-sid, näiteks andmebaaside, samuti oluline jälgida. Varsti peate tegelema siseklientidega ja toetama neid. Ja nii edasi lõputult.

Sümptomipõhine — keskendutakse sümptomitele

Kas see meeldib teile või mitte, kuid te tööteilte jaotatud süsteemis (Kavadh)2. Seetõttu kasutate teenuste isoleerimiseks ja nende rikke kaitsmiseks erinevaid taktikaid (Treynor jt). Ja kuigi veniv garbage collection või andmebaasi järelemõtlik päring viitavad probleemidele, ei pea neid koheselt lahendama, kui kasutajatel ei ole lähitulevikus probleeme.

Need on olulised signaalid, mis võivad omada praktilist väärtust, kuid kui need ei sega kasutajaid, siis ei ole need nii äärmiselt hädavajalikud, et tähelepanu hajutada. Põhjuse põhjalikud teated on meie vaimsed mudelid süsteemi rikete kohta. Paremini on jälgida olulisi sümptomeid kui proovida loetleda kõiki võimalikke rikkeid.

Kuna teated omaksid praktilist väärtust, keskenduge tulemuste näitajatele, mis on kasutajatele olulised. Evashchuk nimetab seda „kasutajatele suunatud jälgimiseks“. Peate meeles pidama, et seda filosoofiat tuleks rakendada kogu organisatsioonis. Kui teenusel tekivad sügaval infrastruktuuris äärmuslikud probleemid, siis tegeleb nendega vastav meeskond. Süsteemide kaitsmine selliste rikete eest on täiesti eraldi teema (Trainer jt, jaotis kriitiliste sõltuvuste minimeerimise strateegiate kohta).3.

Sümptomid ei ole nii muutlikud

Richard Cook meenutab, et keerulistes süsteemides on hulk puudusi, vigu ja probleeme.4. Kõikide võimalike põhjuste loetlemine on Sisyphose töö. Te üritate kirjeldada probleeme, kuid need muutuvad pidevalt. Cindy Shridharan usub, et „süsteemid ei pea iga sekundi jooksul olema ideaalses seisundis“ ja parem on kasutada inimlikumat lähenemist („Jaotatud süsteemide jälgimine“ („Distributed Systems Observability“), 7)5.

Vältige teavitusi sündmuse kohta

Tavaliselt seadistatakse sündmuste korrigeerimiseks teavitused põhjuste kohta. Need piiratud teavitused sündmuse toimumisest loovad vale enesekindluse, kuna süsteem leiutab pidevalt uusi viise katki minna.

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

• Miks ei tuvastanud sümptomite põhjal teavitamine probleemi?
• Kas kasutaja konteksti parandamine oleks kasulik?
• Kuidas parandada jälgimistööriistu, et diagnoosi kiiremini seadistada, mitte akumuleerida teavitusi sündmuse kohta?

Jälgimisriistad diagnoosimiseks on abiks ainult siis, kui te näete neid kui viisi sümptomist lahenduseni jõudmiseks. Ilma tagasisideta saadetakse teile ainult hilinenud teated ja mineviku tõrgete diagrammid — tuleviku kohta ei öelda sõnagi. Organisatsiooni jaoks on see suurepärane võimalus liikuda kaitsepositsioonilt rünnakule. Samuti saavad arendajad ja toodete juhid samad ootused ja arusaadavad eesmärgid. Iga teate juhtum — CASE (:wink:) — on selge.

Põhjuse põhjalik teavitamine on mõõdukas koguses talutav.

Mõnikord ei jäta meie süsteem meile peaaegu üldse valikut põhjuse põhjaliku teavitamise osas. Ja vahel mõistavad vahetuses olevad inimesed suurepäraselt, et sümptom viib kindlasti tõrkeni, mis tähendab, et sellel on praktiline väärtus. Võib-olla te ei ole lihtsalt kindel, mis toimub, ja seetõttu seadistate teavitusi ettevaatlikkuse eesmärgil. Loodame, et see tegevus on ajutine, kuni me muudame süsteemi, et lahendada jõudluse langemise probleem.
Pidage meeles teisi CASE komponente, kui tegelete selliste olukordadega. Kui see on ajutine, ei tähenda see et peaksite mõtlema saamatusselt.

Hinnatud — hindamine

Mistahes süsteemis toimuvad muutused (uus kood, uus infrastruktuur, mis tahes uus) suurendavad tõrkeid (Cook, 3).4 Kas see teade töötab endiselt oodatud viisil? Selged ja ajakohased vaimsed mudelid süsteemide kohta ning kogemused teatud teatistega toimetulemisel toetavad ennetavat lähenemist — need on võtmeomadused õppimisele orienteeritud organisatsioonis. Tõrked süsteemides arenevad pidevalt ja me peame need ära tabama.

Peame pidevalt hindama iga teate kvaliteeti, et need töötaksid oodatud viisil. Lugupeetud juhid! Teie meeskondadel on seda kergem teha, kui aitaksite neil selle protsessiga toime tulla! Siin on mõned ideed hindamiseks:

• Kasutage kaosetehnika, mängupäevad või muud teatiste testimise meetodid. Meeskond saab seda ise teha, ilma et oleks vaja keerulist intsidentide haldamise süsteemi!
• Lisage kõik incidenititega seotud teatiste andmete kogumine intsidentide haldamise programmi. Märkige kasulikud, kahjulikud, asjakohatud, arusaamatud jne. Kasutage neid tagasisidena.
• Õiged teavitused aktiveeruvad harva ja on põhjalikult kontrollitud. Veenduge, et kõik lingid töötavad, viitavad soovitud kontekstile jne.
• Kui teavitus ei aktiveeru kunagi või aktiveerub liiga sageli, on midagi valesti. Parandage see või kustutage. Olge ettevaatlikud liialdava passiivsuse või aktiivsuse suhtes!
• Seadistage teavitustele aegumise märgistus. Kui aegumine on möödas, vaadake teavitus üle CASE meetodi järgi ja värskendage aegumismärget. Kontrollige aegumistähtaegu regulaarselt, nagu toidu puhul.
• Lihtsustage teavituste täiustamise protsessi. Kasutage koodimonitorimist ja talletage teavitused Git'i hoidlas. Pull-avalduse kaudu saate kaasata meeskonna ning teil on varasemate teavituste ajalugu. Te lõpetate teavituste muutmist või nende osas loa küsimise kartmise.
• Luua tagasiside teavituste kohta, isegi kui see on lihtsalt Google'i vorm, et vahetused saaksid teavitusi mahakandmiseks või tüütuks märgistada. Lisage teavituse sisse link või kutse tegevusele ning vaadake tagasisidet regulaarselt üle.
• Kasutage meeskonnas reeglit — las puhkpäevade töötajad keskenduvad teenuse lihtsustamisele, kui töö on vähe. Las järgmistel läheb veidi paremini kui eelmised.

Kokkuvõte

Usun, et CASE meetod aitab arendajatel ja organisatsioonidel arutada automaatsete teadete seadistamist ja saatmist. Üks arendaja võib alustada teadete hindamist CASE meetodi kaudu, seejärel liitub tema juurde kogu organisatsioon koos teiste arendajate, juhtide ja juhtimisprogrammidega, et hoida teateid heas korras. Selleks pole vaja mingeid erilisi tööriistu või keerulisi protsesse.

Kogu tööstus peaks kaaluma inimfaktorit vahetuste ajal, kahjustamata kvaliteetset klienditeenindust. Kõiki neid tööriistu ja tavasid saab ja tuleb täiustada. Loodan, et CASE meetod aitab selles.

Naudi täiustatud teadetega!

Allikas: habr.com