Dziiiiin! Jsou 3 hodiny ráno, zdá se ti nádherný sen a najednou ti někdo volá. Tento týden jste ve službě a zřejmě se něco stalo. Automatizovaný systém volá, aby zjistil, co je špatně. Toto je důležitý aspekt správy moderních počítačových systémů, ale pojďme se podívat na to, jak zlepšit oznámení pro lidi.
Seznamte se s filozofií monitorování, která se zrodila během několika desetiletí mých povinností v různých monitorovacích týmech. Byla do značné míry ovlivněna skutečnou biblí od Roba Evashchuka (My Notification Philosophy) zahrnuta v knize o a kniha Johna Alspaugha (Poznámky k nastavení upozornění).
, и - děkuji za pomoc s úpravou příspěvku.
Co je CASE?
Rozhodl jsem se vymyslet krásnou zkratku like nebo . já tomu říkám CASE metoda. Popisuje čtyři body, kterým je třeba věnovat pozornost při práci s automatickým monitorováním:
- (vázáno na kontext)
- (praktická hodnota)
- (důraz na příznaky)
- (školní známka)
Pokud používáte CASE, zacházíte s notifikacemi se zdravou lhostejností a nebudíte lidi v noci. Monitorování by mělo být pravidelně vyhodnocováno z hlediska užitečnosti a účinnosti. Když člověk obdrží oznámení, bude mít lepší mentální modely a větší sebevědomí.
Abyste si to lépe zapamatovali, představte si, že potřebujete PŘÍPAD [to znamená případ, důvod - poznámka překladatele] k odůvodnění každého upozornění. :sluneční brýle:
A proč to všechno je?
. Z mnoha důvodů. A CASE je všechny nezlikviduje. S ním se ale budete v noci probouzet na lepší notifikace. Tato metoda pokrývá různé organizační procesy, které v této věci také pomohou.
Krása metod RED a USE spočívá v tom, že s jejich pomocí nejen umíme pracovat, ale také spolu mluvíme stejným jazykem. Doufám, že metoda CASE usnadní diskusi o oznámeních, která chrání naše systémy, ale zaměstnávají naše kolegy.
Jde o to, že musíte ve své organizaci vytvořit kulturu, kde se s oznámeními zachází se zdravou lhostejností. Oznámení mohou být vytvořena pro konkrétní účel, ale není pravda, že později neztratí hodnotu. Proč jsme nastavili toto upozornění? Jak dlouho byla jeho kritéria revidována? S CASE lze na tyto otázky odpovědět.
Context-Heavy - kontextová vazba
3 hodiny ráno není nejlepší čas na čtení zpráv, které obsahují spoustu chytrých slov. Abyste mohli efektivně reagovat, potřebujete informace. V ideálním případě by to měly být informace o konkrétním problému, u kterého je kontext okamžitě jasný a upozornění by měla být nastavena tak, aby to bylo možné. To je "pozorování" a "orientace" z . Není ostuda věnovat tomuto nastavení čas, protože neustálé rozptylování člověka je ještě dražší. Respektujme se navzájem.
Problémy mají mnoho zdrojů. Hlavně duchové.
Jak mohu pomoct důstojníkovi? První věc, kterou strážník vidí, je oznámení, takže na jeho základě staví všechny hypotézy. Pak se podívá na pokyny a dashboardy, ale jsou tam vždy údaje o konkrétním upozornění, a nejen obecné informace? Alspaugh radí „přemýšlejte o tom, jak byste mohli oznámení interpretovat nebo na něj reagovat“ (snímek 29). Dobré oznámení je zaměřeno na osobu ve službě, nejen nakonfigurováno prahem.
Zde je několik nápadů, jak zlepšit kontext oznámení:
- Ukažte uživateli něco užitečného a speciálně vytvořeného, a ne jen obyčejný návod nebo dashboard. Dříve jsme s chlapci používali vyšetřovací řídicí panely nakonfigurované pro konkrétní oznámení. To pomůže, pokud je problém znám, ale pouze zmátne ostatní. Musíme zde najít rovnováhu.
- Řekněte nám o historii oznámení: je nové? Funguje to často? Je to sezónní?
- Zobrazit poslední změny stavu systému. Změnilo se něco v poslední době? (Například nasazení nebo aktivace/deaktivace funkcí.)
- Ukažte vztahy a poskytněte informace pro mentální model: systémové závislosti by měly být jasně viditelné, nejlépe s uvedením funkčnosti.
- Rychle spojte uživatele s týmem: mohou vidět probíhající incidenty nebo mohou zjistit, kdo další ve společnosti obdržel upozornění? Program aktivováno?
V ideálním případě program řízení incidentů poskytne rady, jak zlepšit oznamovací kontext vyšetřování incidentů. Vždy je na čem pracovat!
Akční – praktická hodnota
Měl by služebník v reakci na oznámení něco udělat? Pokud nemusíte nic dělat nebo vám není jasné, co dělat, proč jste ho vzbudili? Musíte se vyhnout oznámením, která obtěžují zaměstnance ve službě a nevyžadují akci.
Co bych měl dělat? Co chceš?
V minulosti, kdy byly systémy jednoduché a týmy malé, jsme nastavili monitorování, abychom zůstali nad věcí. Oznámení, že se zatížení haldy zvýšilo, nám poskytne kontext, pokud by služba následně selhala. Ve velkém měřítku taková oznámení způsobí pouze zmatek, protože naše systémy vždy fungují ve stavu degradace různé závažnosti. To rychle vede k a samozřejmě ke ztrátě citlivosti. Služebník proto taková upozornění ignoruje nebo dokonce filtruje a ne vždy na ně reaguje podle potřeby. Nespadněte do této pasti! Nenastavujte všechna oznámení za sebou a poté je neposílejte e-mailem do nějaké bohem zapomenuté složky.
Takto vypadá oznámení s praktickou hodnotou:
- Oznámení vyžaduje akci spíše než pouhé hlášení novinek.
- Tuto akci je obtížné nebo riskantní automatizovat. Pokud lze akci zautomatizovat, zautomatizujte ji, přestaňte otravovat lidi!
- Oznámení obsahuje naléhavá doporučení ve formuláři (SLA) popř (RTO). Důstojník pak může aktivovat program řízení incidentů organizace.
Chci objasnit: Neříkám, že oznámení by měla přicházet pouze pro nejdůležitější SLO (cíle na úrovni služeb) pro API. Monitoring SLO je neustále fragmentovaný a rozdělený a vyžaduje stejný přístup ke všem službám. Je jasné, že budete sledovat nejdůležitější SLO u klientů, kteří vám platí. Ale infrastruktura SLO, jako jsou databáze, musí být také monitorována. Brzy budete muset jednat s interními zákazníky a podporovat je. A tak dále do nekonečna.
Symptom-based - důraz na symptomy
Ať se vám to líbí nebo ne, pracujete v distribuovaném systému (Kavaj). V důsledku toho používáte různé taktiky k izolaci služeb a jejich ochraně před selháním (Trainor et al.)3. A přestože opožděný sběr odpadu nebo zablokovaný databázový dotaz signalizují problémy, není třeba spěchat s jejich opravou, pokud uživatelé nebudou mít problémy v blízké budoucnosti.
Jsou to důležité signály a mohou mít praktickou hodnotu, ale pokud neruší uživatele, pak to není dostatečně naléhavé, aby odvádělo pozornost obsluhy. Oznámení založená na příčinách jsou snímky našich mentálních modelů o selhání systému. Je lepší sledovat důležité příznaky, než se snažit vyjmenovat všechny možné příčiny selhání.
Aby měla oznámení smysl, zaměřte se na , důležité pro uživatele. Evashchuk tomu říká „monitorování pro uživatele“. Pamatujte, že tato filozofie musí být aplikována v celé organizaci. Pokud má služba někde hluboko v infrastruktuře naléhavé problémy, postará se o ně příslušný tým. Ochrana systémů před takovými poruchami je zcela samostatná záležitost (Trainer et al., část o strategiích pro minimalizaci kritických závislostí).
Příznaky nejsou tak variabilní
Richard Cook nám připomíná, že složité systémy jsou plné nedostatků, nedostatků a problémů. Pokusit se vyjmenovat všechny možné důvody je sisyfovský úkol. Snažíte se popsat problémy, ale ty se neustále mění. Cindy Sridharan věří, že „systémy nemusí být v perfektním stavu každou sekundu“ a je lepší použít lidštější přístup ( („Monitorování distribuovaných systémů“), 7).
Vyhněte se upozorněním po incidentu
Obvykle jsou oznámení o příčinách nakonfigurována tak, aby opravovala incidenty. A tato omezená upozornění na skutečnost, co se stalo, vytvářejí falešný pocit bezpečí, protože systém pokaždé přichází s novými způsoby, jak se zlomit.
Nenechte se zmást upozorněním na příčinu. Raději se zamyslete:
- Proč si upozornění na základě příznaků nevšimlo problému?
- Bylo by užitečné zlepšit kontext pro uživatele?
- Jak lze vylepšit monitorovací nástroje, aby byla diagnostika rychlejší než shromažďování oznámení o tom, co se stalo?
Monitorovací nástroje pro diagnostiku vám pomohou pouze tehdy, pokud je budete považovat za způsob, jak přejít od symptomu k řešení. Bez této zpětné vazby budete jednoduše bombardováni pozdními oznámeními a tabulkami o minulých selháních – a ani slovo o těch budoucích. To je skvělá příležitost pro organizaci přejít z obrany do útoku. A vývojáři a produktoví manažeři budou mít stejná očekávání a jasné cíle. Případ - CASE (:wink:) - je u každého upozornění jasný.
Oznámení na základě důvodu jsou tolerována s mírou
Někdy nám náš systém nechává malý výběr, pokud jde o oznámení na základě příčiny. A někdy ti, kteří jsou ve službě, naprosto dobře chápou, že symptom rozhodně povede k selhání, a proto má praktickou hodnotu. Možná si jen nejste jisti, co se děje, a pro jistotu si nastavujete upozornění. Doufejme, že tato akce je dočasná, dokud nebudeme moci změnit systém, abychom problém s výkonem vyřešili.
Při řešení těchto situací mějte na paměti ostatní součásti CASE. To, že je to dočasné, neznamená, že můžete přestat myslet hlavou.
Hodnoceno - hodnocení
Jakékoli změny v systému (nový kód, nová infrastruktura, cokoliv nového) rozšiřují rozsah poruch (Cook, 3). Funguje toto oznámení stále podle očekávání? Jasné a aktuální mentální modely systémů a zkušeností reagujících na některá upozornění podpory - to jsou klíčové vlastnosti . Závady v systémech se neustále vyvíjejí a my s nimi musíme držet krok.
Musíte neustále vyhodnocovat kvalitu každého oznámení, abyste zajistili, že bude fungovat podle očekávání. Vážení vedoucí! Pro vaše týmy to bude mnohem jednodušší, když jim pomůžete tento proces zavést! Zde je několik nápadů na hodnocení:
- použití , nebo jiné metody testování oznámení. Tým to zvládne sám, aniž by se musel spoléhat na náročný systém správy incidentů!
- Zahrňte shromažďování všech oznámení souvisejících s incidenty do svého programu správy incidentů. Označte užitečné, škodlivé, nevhodné, nejasné atd. Použijte je jako zpětnou vazbu.
- Správná oznámení se spouštějí zřídka a jsou pečlivě testována. Ujistěte se, že všechny odkazy fungují, ukazují na správný kontext atd.
- Pokud se oznámení nikdy nespustí nebo se spouští příliš často, je s ním něco špatně. Opravte nebo odstraňte. Pozor na přílišnou pasivitu nebo aktivitu!
- Nastavte časová razítka oznámení s daty vypršení platnosti. Pokud vypršelo datum vypršení platnosti, vyhodnoťte oznámení pomocí metody CASE a aktualizujte časové razítko. Stejně jako u potravin pravidelně kontrolujte datum spotřeby.
- Zjednodušte proces vylepšování oznámení. Použijte monitorování jako kód a ukládejte oznámení v úložišti Git. Pull žádosti pomáhají zapojit tým a poskytují vám historii minulých oznámení. A už se nebudete bát měnit oznámení nebo žádat o povolení od odpovědných osob.
- Nastavte zpětnou vazbu pro oznámení, i když je to jednoduché , aby strážníci označovali oznámení jako zbytečná nebo obtěžující. Vložte odkaz nebo výzvu k akci do samotného oznámení a pravidelně kontrolujte svou zpětnou vazbu.
- Stanovte si v týmu pravidlo – nechejte pracovat ty ve službě, abyste si zjednodušili povinnost, když je práce málo. Ať je po tobě všechno o něco lepší, než bylo předtím.
Závěr
Věřím, že metoda CASE pomáhá vývojářům a organizacím diskutovat o nastavení a zasílání automatických oznámení. Jeden vývojář může začít vyhodnocovat oznámení pomocí metody CASE a poté se celá organizace připojí k ostatním vývojářům, programům pro správu a správu incidentů, aby byla oznámení v dobrém stavu. To nevyžaduje žádné speciální nástroje nebo složité procesy.
Celé odvětví musí ve službě myslet na lidský faktor, aniž by obětovalo špičkové služby zákazníkům. Všechny tyto nástroje a postupy mohou a měly by být zlepšeny. Doufám, že metoda CASE s tím pomůže.
Užijte si vylepšená upozornění!
Zdroj: www.habr.com