Dziiiiin! Sú 3 hodiny ráno, snívaš nádherný sen a zrazu ti niekto volá. Tento týždeň ste v službe a zrejme sa niečo stalo. Automatizovaný systém zavolá, aby zistil, čo sa deje. Toto je dôležitý aspekt správy moderných počítačových systémov, ale pozrime sa, ako zlepšiť upozornenia pre ľudí.
Zoznámte sa s filozofiou monitorovania, ktorá sa zrodila počas niekoľkých desaťročí mojich povinností v rôznych monitorovacích tímoch. Do veľkej miery ju ovplyvnila skutočná biblia od Roba Evashchuka (My Notification Philosophy) zahrnuté v knihe o a kniha Johna Alspaugha (Poznámky k nastaveniu upozornení).
, и - ďakujem za pomoc pri úprave príspevku.
Čo je CASE?
Rozhodol som sa vymyslieť krásnu skratku like alebo . ja tomu hovorím metóda CASE. Opisuje štyri body, ktorým treba venovať pozornosť pri práci s automatickým monitorovaním:
- (viazané na kontext)
- (praktická hodnota)
- (dôraz na príznaky)
- (stupeň)
Ak používate CASE, správate sa k notifikáciám so zdravou ľahostajnosťou a nebudíte ľudí v noci. Monitorovanie by sa malo pravidelne hodnotiť z hľadiska užitočnosti a účinnosti. Keď osoba dostane upozornenie, bude mať lepšie mentálne modely a väčšiu sebadôveru.
Aby ste si to ľahšie zapamätali, predstavte si, že potrebujete PRÍPAD [to znamená prípad, dôvod - poznámka prekladateľa] na odôvodnenie každého upozornenia. :slnečné okuliare:
A prečo je to všetko?
. Pre veľa dôvodov. A CASE ich všetky nezlikviduje. S ním sa však v noci zobudíte na lepšie upozornenia. Táto metóda pokrýva rôzne organizačné procesy, ktoré v tejto veci tiež pomôžu.
Krása metód RED a USE je v tom, že s ich pomocou vieme nielen pracovať, ale aj medzi sebou hovoríme rovnakým jazykom. Dúfam, že metóda CASE uľahčí diskusiu o upozorneniach, ktoré chránia naše systémy, ale zamestnávajú našich kolegov.
Ide o to, že musíte vo svojej organizácii vytvoriť kultúru, v ktorej sa k oznámeniam pristupuje so zdravou ľahostajnosťou. Oznámenia môžu byť vytvorené na konkrétny účel, ale nie je pravda, že neskôr nestratí hodnotu. Prečo sme nastavili toto upozornenie? Ako dlho boli jeho kritériá revidované? S CASE môžu byť tieto otázky zodpovedané.
Context-Heavy - kontextová väzba
3:XNUMX nie je najlepší čas na čítanie správ, ktoré obsahujú veľa inteligentných slov. Ak chcete efektívne reagovať, potrebujete informácie. V ideálnom prípade by to mali byť informácie o konkrétnom probléme, pri ktorom je kontext okamžite jasný a notifikácie by mali byť nakonfigurované tak, aby to bolo možné. Toto je "pozorovanie" a "orientácia" z . Nie je hanba tráviť čas týmto nastavením, pretože neustále rozptyľovanie človeka je ešte drahšie. Vážme si jeden druhého.
Problémy majú veľa zdrojov. Najmä duchovia.
Ako môžem pomôcť dôstojníkovi? Prvá vec, ktorú dôstojník vidí, je oznámenie, takže na jeho základe vytvára všetky hypotézy. Potom sa pozrie na pokyny a dashboardy, ale sú tam vždy údaje o konkrétnom upozornení, a nie len všeobecné informácie? Alspaugh odporúča „premýšľať o tom, ako by ste mohli interpretovať alebo reagovať na oznámenie“ (snímka 29). Dobrá notifikácia je zameraná na osobu v službe, nie je len nakonfigurovaná prahom.
Tu je niekoľko nápadov, ako zlepšiť kontext upozornení:
- Ukážte používateľovi niečo užitočné a špeciálne vytvorené, a nie len obyčajný návod alebo dashboard. Predtým sme s chlapcami používali vyšetrovacie panely nakonfigurované pre konkrétne upozornenia. To pomôže, ak sa o probléme vie, ale ostatných to len zmiatne. Tu musíme nájsť rovnováhu.
- Povedzte nám o histórii upozornenia: je nové? Funguje to často? Je to sezónne?
- Zobraziť posledné zmeny stavu systému. Zmenilo sa niečo v poslednej dobe? (Napríklad nasadenie alebo zapnutie/vypnutie funkcií.)
- Ukážte vzťahy a poskytnite informácie pre mentálny model: systémové závislosti by mali byť jasne viditeľné, najlepšie s označením funkčnosti.
- Rýchle spojenie používateľa s tímom: môže vidieť prebiehajúce incidenty alebo môže zistiť, kto ďalší v spoločnosti dostal upozornenie? Program aktivovaný?
V ideálnom prípade program riadenia incidentov poskytne rady, ako zlepšiť kontext oznamovania vyšetrovania incidentov. Vždy je na čom pracovať!
Akčná – praktická hodnota
Mal by služobný úradník niečo urobiť v reakcii na oznámenie? Ak nemusíte nič robiť alebo vám nie je jasné, čo robiť, prečo ste ho zobudili? Musíte sa vyhýbať upozorneniam, ktoré obťažujú tých, ktorí sú v službe, a nevyžadujú zásah.
Čo mám robiť? Čo chceš?
V minulosti, keď boli systémy jednoduché a tímy malé, sme nastavili monitorovanie len preto, aby sme mali prehľad. Upozornenie, že zaťaženie haldy sa zvýšilo, nám poskytne kontext, ak by služba následne zlyhala. Vo veľkom rozsahu takéto upozornenia spôsobia len zmätok, pretože naše systémy vždy fungujú v stave degradácie rôznej závažnosti. To rýchlo vedie k a samozrejme k strate citlivosti. Služobný úradník preto takéto oznámenia ignoruje alebo dokonca filtruje a nie vždy na ne podľa potreby reaguje. Nespadnite do tejto pasce! Nenastavujte všetky upozornenia za sebou a potom ich neposielajte e-mailom do nejakého bohom zabudnutého priečinka.
Oznámenie s praktickou hodnotou vyzerá takto:
- Oznámenie vyžaduje akciu namiesto jednoduchého hlásenia správ.
- Túto akciu je ťažké alebo riskantné zautomatizovať. Ak sa dá akcia zautomatizovať, tak ju zautomatizujte, prestaňte otravovať ľudí!
- Oznámenie obsahuje naliehavé odporúčania vo formulári (SLA) resp (RTO). Služobný dôstojník potom môže aktivovať program riadenia incidentov organizácie.
Chcem objasniť: Nehovorím, že upozornenia by mali prichádzať iba pre najdôležitejšie SLO (ciele na úrovni služieb) pre API. Monitoring SLO je neustále fragmentovaný a rozdelený a vyžaduje rovnaký prístup ku všetkým službám. Je jasné, že budete sledovať najdôležitejšie SLO pre klientov, ktorí vám platia. Ale aj infraštruktúry SLO, ako sú databázy, musia byť monitorované. Čoskoro budete musieť jednať s internými zákazníkmi a podporovať ich. A tak ďalej do nekonečna.
Na základe symptómov – dôraz na symptómy
Či sa vám to páči alebo nie, pracujete v distribuovanom systéme (Kavaj). V dôsledku toho používate rôzne taktiky na izoláciu služieb a ich ochranu pred zlyhaním (Trainor et al.)3. A hoci oneskorený zber odpadu alebo zablokovaný databázový dotaz naznačujú problémy, nie je potrebné sa ponáhľať s ich opravou, ak používatelia nebudú mať problémy v blízkej budúcnosti.
Sú to dôležité signály a môžu mať praktickú hodnotu, ale ak nerušia používateľov, potom to nie je dostatočne naliehavé, aby rozptyľovali obsluhu. Oznámenia založené na príčine sú snímky našich mentálnych modelov o zlyhaní systému. Je lepšie sledovať dôležité príznaky, ako sa snažiť vymenovať všetky možné príčiny zlyhania.
Ak chcete, aby upozornenia mali zmysel, zamerajte sa na , dôležité pre používateľov. Evashchuk to nazýva „monitorovanie pre používateľov“. Pamätajte, že táto filozofia sa musí uplatňovať v celej organizácii. Ak má služba niekde hlboko v infraštruktúre urgentné problémy, príslušný tím sa o ne postará. Ochrana systémov pred takýmito zlyhaniami je úplne samostatná záležitosť (Trainer a kol., časť o stratégiách na minimalizáciu kritických závislostí).
Príznaky nie sú také variabilné
Richard Cook nám pripomína, že zložité systémy sú plné nedostatkov, nedostatkov a problémov. Pokúsiť sa vymenovať všetky možné dôvody je sizyfovská úloha. Snažíte sa opísať problémy, no tie sa neustále menia. Cindy Sridharan verí, že „systémy nemusia byť v perfektnom stave každú sekundu“ a je lepšie použiť ľudskejší prístup ( („Monitorovanie distribuovaných systémov“), 7).
Vyhnite sa upozorneniam po incidente
Zvyčajne sú upozornenia na príčiny nakonfigurované tak, aby opravovali incidenty. A tieto obmedzené upozornenia o skutočnosti, čo sa stalo, vytvárajú falošný pocit bezpečia, pretože systém zakaždým prichádza s novými spôsobmi, ako sa zlomiť.
Nenechajte sa zmiasť upozorneniami na príčinu. Radšej sa zamysli:
- Prečo si upozornenie na základe symptómov nevšimlo problém?
- Bolo by užitočné zlepšiť kontext pre používateľa?
- Ako možno vylepšiť monitorovacie nástroje, aby sa diagnostika robila rýchlejšie, a nie zhromažďovanie upozornení o tom, čo sa stalo?
Monitorovacie nástroje na diagnostiku pomôžu iba vtedy, ak ich budete považovať za spôsob, ako prejsť od symptómu k riešeniu. Bez tejto spätnej väzby budete jednoducho bombardovaní neskorými upozorneniami a grafmi o minulých zlyhaniach – a ani slovo o budúcich. Pre organizáciu je to skvelá príležitosť prejsť z obrany do útoku. A vývojári a produktoví manažéri budú mať rovnaké očakávania a jasné ciele. Prípad - CASE (:wink:) - je jasný pri každom upozornení.
Oznámenia založené na dôvode sú prijateľné s mierou
Niekedy nám náš systém ponecháva malý výber, pokiaľ ide o upozornenia na základe príčin. A niekedy tí, ktorí sú v službe, veľmi dobre chápu, že symptóm určite povedie k zlyhaniu, a preto má praktickú hodnotu. Možno si len nie ste istí, čo sa deje, a pre istotu si nastavujete upozornenia. Dúfajme, že táto akcia je dočasná, kým nebudeme môcť zmeniť systém, aby sme vyriešili problém s výkonom.
Pri riešení týchto situácií majte na pamäti ostatné zložky CASE. Len preto, že je to dočasné, neznamená, že môžete prestať myslieť hlavou.
Vyhodnotené – hodnotenie
Akékoľvek zmeny v systéme (nový kód, nová infraštruktúra, čokoľvek nové) rozširujú rozsah porúch (Cook, 3). Funguje toto upozornenie stále podľa očakávania? Jasné a aktuálne mentálne modely systémov a skúseností reagujúcich na niektoré upozornenia podpory - to sú kľúčové vlastnosti . Chyby v systémoch sa neustále vyvíjajú a my s nimi musíme držať krok.
Musíte neustále vyhodnocovať kvalitu každého oznámenia, aby ste sa uistili, že fungujú podľa očakávania. Vážení vedúci! Pre vaše tímy to bude oveľa jednoduchšie, ak im pomôžete zaviesť tento proces! Tu je niekoľko nápadov na hodnotenie:
- použitie , alebo iné metódy testovania oznamovania. Tím to dokáže sám bez toho, aby sa musel spoliehať na náročný systém správy incidentov!
- Zahrňte zhromažďovanie všetkých upozornení týkajúcich sa incidentov do svojho programu správy incidentov. Označte užitočné, škodlivé, nevhodné, nejasné atď. Použite ich ako spätnú väzbu.
- Správne upozornenia sa spúšťajú zriedkavo a sú starostlivo testované. Uistite sa, že všetky odkazy fungujú, ukazujú na správny kontext atď.
- Ak sa upozornenie nikdy nespustí alebo sa spustí príliš často, niečo s ním nie je v poriadku. Opravte ho alebo odstráňte. Pozor na prílišnú pasivitu či aktivitu!
- Nastavte časové pečiatky upozornení s dátumami vypršania platnosti. Ak dátum vypršania platnosti vypršal, vyhodnoťte oznámenie pomocou metódy CASE a aktualizujte časovú pečiatku. Rovnako ako pri potravinách si pravidelne kontrolujte dátum spotreby.
- Zjednodušte proces zlepšovania upozornení. Použite monitorovanie ako kód a uložte upozornenia v úložisku Git. Stiahnutie žiadostí pomôže zapojiť tím a poskytne vám históriu minulých upozornení. A už sa nebudete báť meniť notifikácie či pýtať si povolenie od tých, ktorí sú za ne zodpovední.
- Nastavte si spätnú väzbu pre upozornenia, aj keď je to jednoduché , aby úradníci označili oznámenia za zbytočné alebo rušivé. Vložte odkaz alebo výzvu na akciu do samotného upozornenia a pravidelne kontrolujte svoju spätnú väzbu.
- Stanovte si v tíme pravidlo – nechajte tých, ktorí sú v službe, aby si zjednodušili prácu, keď je práce málo. Nech je všetko po tebe o niečo lepšie ako predtým.
Záver
Verím, že metóda CASE pomáha vývojárom a organizáciám diskutovať o nastavení a odosielaní automatických upozornení. Jeden vývojár môže začať vyhodnocovať notifikácie pomocou metódy CASE a potom sa celá organizácia spojí s ostatnými vývojármi, manažmentom a programami na správu incidentov, aby notifikácie zostali v dobrom stave. To si nevyžaduje žiadne špeciálne nástroje ani zložité procesy.
Celé odvetvie musí počas služby myslieť na ľudský faktor bez toho, aby obetovalo špičkové služby zákazníkom. Všetky tieto nástroje a postupy môžu a mali by sa zlepšiť. Dúfam, že metóda CASE s tým pomôže.
Užite si vylepšené upozornenia!
Zdroj: hab.com