Dzinggg! Éppen 3 óra van, csodás álmot látsz, amikor hirtelen csörög a telefon. Ezen a héten te vagy ügyeletes, úgyhogy valami történt. Az automatizált rendszer hív, hogy nézd meg, mi a baj. Ez fontos pillanat napjaink számítógépes rendszerei menedzsmentjében, de nézzük meg, hogyan tehetjük a figyelmeztetéseket kényelmesebbé az emberek számára.
Ismerkedj meg a megfigyelési filozófiával, amely évtizedek során alakult ki az ügyeletek alatt, különböző megfigyelő csapatoknál. Ezt nagymértékben befolyásolta Rob Evarts igazi bibliája (A figyelmeztetések filozófiám), amely benne van a könyvben , és John Allspaw könyve (Figyelembe veendő szempontok a figyelmeztetések tervezésében).
, és — köszönöm a poszt szerkesztésében nyújtott segítséget.
Mi az a CASE?
Kitaláltam egy szép mozaikszót, mint a vagy Ezt úgy hívom, hogy CASE módszer.Ez négy szempontot ír le, amelyre figyelni kell az automatizált megfigyelés során:
- (konteksthöz kötött)
- (gyakorlati érték)
- (tünetalapú)
- (értékelés)
Ha használod a CASE-t, a figyelmeztetéseket egy egészséges közömbösséggel kezeled, és nem ébreszted fel az embereket éjjel. Rendszeresen értékelni kell a megfigyelést a hasznosság és hatékonyság szempontjából. Amikor valaki figyelmeztetést kap, jobban fogja érteni a dolgokat és magabiztosabb lesz.
Hogy könnyebben megjegyezhesd, képzeld el, hogy szükséged van egy CASE-re [vagyis egy okra — ford. megj.], hogy igazold minden figyelmeztetést. :sunglasses:
És miért is?
. Sok okból. A CASE nem szünteti meg az összeset. De vele éjszaka jobb minőségű figyelmeztetések ébresztenek fel. Ez a módszer különböző szervezeti folyamatokat is átölel, amelyek szintén segítenek ebben.
A RED és USE módszerek szépsége abban rejlik, hogy nemcsak tudjuk, hogyan dolgozzunk, hanem egy nyelvet is beszélünk egymással. Remélem, a CASE módszerrel könnyebb lesz megbeszélni a figyelmeztetéseket, amelyek védik rendszereinket, de mégis nyugtalanítják kollégáinkat.
A lényeg az, hogy olyan kultúrát kell létrehozni a szervezeten belül, ahol az értesítéseket egészséges közömbösséggel kezelik. Az értesítések indokoltan keletkezhetnek, de nem biztos, hogy később is megőrzik értéküket. Miért állítottuk be ezt az értesítést? Régóta felülvizsgálták a kritériumait? A CASE segítségével ezekre a kérdésekre találhatók válaszok.
Kontektszűkített — kontextushoz való kötődés
Hajnal 3 — nem a legjobb időpont az összetett szavakkal teli üzenetek elolvasására. A hatékony reagáláshoz információra van szükség. Ideális esetben egy konkrét problémáról kell szólnia, ahol azonnal világos a kontextus, és az értesítéseket úgy kell beállítani, hogy ez lehetséges legyen. Ez a megfigyelés és irányítás a Erre a beállításra érdemes időt szánni, mert az állandó figyelemelterelés még költségesebb. Tiszteljük meg egymást.
A problémáknak sok forrása van. Különösen a szellemek.
Hogyan segíthetünk a diszpécsernek? Először a diszpécser látja az értesítést, ezért minden hipotézist annak alapján épít. Aztán megnézi az utasításokat és a műszerfalakat, de mindig találhatók ott konkrét értesítési adatok, nem csak általános információk? Az Olspo azt tanácsolja, hogy 'gondolkodjunk azon, hogyan lehet értelmezni az értesítést vagy reagálni rá' (29. dia).Egy jó értesítés a diszpécserre van szabva, nem csak a küszöbérték szerint van beállítva.
Ezért itt vannak ötletek, hogyan lehet javítani az értesítések kontextusát:
- Mutasson a felhasználónak valami hasznosat és kifejezetten a célnak megfelelő dolgot, ne csak általános utasításokat vagy műszerfalakat. Régebben a srácokkal a konkrét értesítésekhez beállított műszerfalakat használtuk nyomozás során. Ez segít, ha a probléma ismert, de más esetekben csak zavaró lehet. Meg kell találni az egyensúlyt.
- Meséljen az értesítés történetéről: új? Gyakran aktiválódik? Szezonális?
- Mutassa be a rendszer állapotának legutóbbi változásait. Nemrég változott valami? (Például telepítés vagy funkciók engedélyezése/letiltása.)
- Mutassa be a kapcsolatokat és nyújtson információt a mentális modellhez: a rendszer függőségei legyenek világosan láthatók, lehetőleg működési állapot megadásával.
- Azonnal kapcsolja össze a felhasználót a csapattal: látja a jelenlegi eseményeket, vagy megtudhatja, hogy ki más a cégnél kapott értesítést? A program aktiválva?
Ideális esetben az incidenskezelő program tanácsokat ad arra, hogyan lehet javítani az értesítések kontextusát az incidensek kivizsgálásakor. Mindig van mit fejleszteni!
Actionable — gyakorlati érték
A kezelőnek tennie kell valamit az értesítésre? Ha nincs teendő, vagy nem világos, hogy mit kell tenni, miért zavarták fel? Kerülni kell azokat az értesítéseket, amelyek zavarják a kezelőket, és nem igényelnek intézkedést.
Mit kell tenni? Mi szükséges?
Korábban, amikor a rendszerek egyszerűek voltak és a csapatok kicsik, a megfigyelést úgy állítottuk be, hogy egyszerűen tudatában legyünk a dolgoknak. Az értesítés arról, hogy a terhelés megnőtt, kontextust ad, ha később a szolgáltatás problémákkal működik. Nagy méretben ezek az értesítések csak zűrzavart okoznak, mert a rendszereink mindig fokozatosan romlanak. Ez gyorsan oda vezet, hogy és természetesen érzékenységvesztést okoz. Ezért a kezelők figyelmen kívül hagyják, vagy akár szűrik ezeket az értesítéseket, és nem mindig reagálnak rájuk úgy, ahogy kellene. Ne essetek ebbe a csapdába! Ne állítsd be az összes értesítést csak azért, hogy később egy elfelejtett mappába küldd őket.
Így néz ki egy értesítés gyakorlati értékkel:
- Az értesítés cselekvést igényel, nem csak híreket közöl.
- Ez a cselekvés nehéz vagy kockázatos automatizálni. Ha automatizálható, akkor azok automatikusak legyenek, ne zaklassák az embereket!
- Az értesítés sürgős ajánlásokat tartalmaz (SLA) vagy (RTO). Akkor a kezelő aktiválhatja a szervezet incidenskezelő programját.
Szeretném pontosítani: nem azt mondom, hogy az értesítéseknek csak a legfontosabb SLO-k (service-level objectives, szolgáltatási szintű célok) alapján kell érkezniük az API számára. Az SLO monitorozása folyamatosan szétválasztódik és megosztódik, és az összes szolgáltatás esetében azonos megközelítést igényel. Nyilvánvaló, hogy a legfontosabb SLO-kat figyeli a vállalkozások, akik Önnek fizetnek. De az infrastruktúra SLO-it, például az adatbázisokat is figyelemmel kell kísérni. Hamarosan foglalkoznia kell a belső ügyfelekkel és támogatnia kell őket. És így tovább végtelenségig.
Tünetalapú — fókusz a tüneteken
Tetszik ez vagy sem, de egy elosztott rendszerben dolgozik (Kavadz).. Ennek eredményeként különböző taktikákat használ, hogy elszigetelje a szolgáltatásokat és megvédje őket a leállásoktól (Treynor és társai).3. Bár a hosszan elnyúló garbage collection vagy a megakadt adatbázis-kérés hibára utalhatnak, nem kell azonnal közbeavatkozni, ha a felhasználók nem tapasztalnak problémákat a közeljövőben.
Ezek fontos jelek, és gyakorlati értékkel bírhatnak, de ha nem zavarják a felhasználókat, akkor nem olyan sürgősek, hogy a felügyelőt elvonják. Az ok-okozati alapú értesítések mentális modelljeink pillanatfelvételei a rendszerhibákról. Jobb fontos tüneteket követni, mint megpróbálni felsorolni az összes lehetséges hibaokot.
Ahhoz, hogy az értesítések gyakorlati értéket nyújtsanak, a , a felhasználók számára fontosak. Evashchuk ezt „felhasználói megfigyelésnek” nevezi. Ne felejtsük el, hogy ezt a filozófiát az egész szervezetre alkalmazni kell. Ha gyökérben, az infrastruktúra mélyén sürgős problémák adódnak egy szolgáltatásban, akkor azokkal a megfelelő csapat foglalkozni. A rendszerek védelme az ilyen leállások ellen egy teljesen külön kérdés (Treynor és társai, a kritikus függőségek minimalizálásának stratégiáiról szóló rész)..
A tünetek nem olyan változékonyak.
Richard Cook arra figyelmeztet, hogy a komplex rendszerek tele vannak hibákkal, hiányosságokkal és problémákkal.Minden lehetséges ok felsorolása Sziszüphoszi munka. Ön megpróbálja leírni a problémákat, de azok folyamatosan változnak. Cindy Shridhakaran úgy véli, hogy „a rendszereknek nem szükséges minden másodpercben tökéletes állapotban lenniük”, és jobb emberibb megközelítést alkalmazni ( („Elosztott rendszerek megfigyelése”), 7).
Kerülje az eseményalapú értesítéseket.
Általában az incidensek kijavítása érdekében okok alapján állítanak be értesítéseket. Az esemény tényeihez kapcsolódó korlátozott értesítések hamis biztonságérzetet keltenek, hiszen a rendszer minden alkalommal új módszereket talál arra, hogy összeroppanjon.
Ne áltassa magát az okokkal kapcsolatos értesítésekkel. Inkább gondolkozzon el ezen:
- Miért nem vette észre a probléma a tünetek alapján készült értesítés?
- Hasznos lenne a felhasználó kontextusának javítása?
- Hogyan javíthatók a monitoring eszközök, hogy gyorsabban tudjunk diagnózist felállítani, ahelyett, hogy csak értesítéseket gyűjtenénk a történésekről?
A diagnózishoz szükséges monitoring eszközök csak akkor segítenek, ha arra fognak szolgálni, hogy a tünetekből a megoldásra lépjünk. E visszajelzés nélkül egyszerűen elárasztanak minket a késedelmes értesítések és a múltbeli hibákról szóló diagramok — és egy szó sem a jövőről. Ez egy remek lehetőség a szervezet számára, hogy a védekezésből támadásba forduljon. A fejlesztők és a termékmenedzserek pedig közös elvárásokkal és érthető célokkal rendelkeznek. Az eset — CASE (:wink:) — világos minden értesítés esetében.
A kiváltó okokon alapuló értesítések mérsékelt mennyiségben tolerálhatóak.
Néha a rendszerünk szinte nem ad választási lehetőséget az ok alapú értesítések tekintetében. Máskor a ügyeletesek pontosan tudják, hogy a tünet biztosan meghibásodáshoz vezet, ezért gyakorlati értékkel bír. Lehet, hogy csak nem vagy biztos abban, hogy mi történik, és értesítéseket állítasz be óvatosan. Reméljük, hogy ez az intézkedés átmeneti, amíg nem módosítjuk a rendszert a teljesítménycsökkenés problémájának megoldására.
Ne feledkezz meg a CASE más komponenseiről sem, amikor ezekkel a helyzetekkel foglalkozol. Az, hogy ez átmeneti, nem jelenti azt, hogy nem kell gondolkodnod.
Evaluated — értékelés
Bármilyen változás a rendszeren (új kód, új infrastruktúra, bármi új) szélesíti a meghibásodások skáláját (Cook, 3). Ez az értesítés még mindig pontosan úgy működik, ahogy azt vártuk? Világos és aktuális mentális modellek a rendszerekről és a néhány értesítésre való reagálás tapasztalata a támogatás érdekében — ezek a kulcsfontosságú jellemzők . A hibák a rendszerekben folyamatosan fejlődnek, és nekünk lépést kell tartanunk velük.
Folyamatosan értékelni kell minden értesítés minőségét, hogy azok úgy működjenek, ahogy vártuk. Tisztelt vezetők! A csapataik sokkal könnyebben boldogulnak, ha segítenek neki ennek a folyamatnak a beállításában! Íme néhány ötlet az értékeléshez:
- Használja , vagy más értesítések tesztelésének módszerei. A csapat ezt önállóan is megteheti, anélkül, hogy nehézkes incidenskezelő rendszert vonna be!
- Kapcsolja be az eseményekhez kapcsolódó összes értesítés adatgyűjtését az incidenskezelő programban. Jelölje meg a hasznos, káros, nem megfelelő, félreérthető stb. értesítéseket. Használja őket visszajelzésként.
- A megfelelő értesítések ritkán aktiválódnak és alaposan ellenőrizve vannak. Győződjön meg róla, hogy minden hivatkozás működik, a megfelelő kontextusra mutat stb.
- Ha egy értesítés sosem aktiválódik vagy túl gyakran aktiválódik, akkor valami nincs rendben. Javítsa ki vagy törölje azt. Ügyeljen a túlzott passzivitásra vagy aktivitásra!
- Állítson be lejárati időt az értesítésekhez. Ha a lejárati idő letelt, értékelje az értesítést a CASE módszerével és frissítse a lejárati időt. Rendszeresen ellenőrizze a lejárati időt, mint az élelmiszereknél.
- Egyszerűsítse az értesítések javítási folyamatát. Használjon kód-alapú nyomon követést, és tárolja az értesítéseket egy Git tárolóban. A pull-kérelmek segítenek bevonni a csapatot, és így nyomon követheti a korábbi értesítések történetét. Így megszabadul a félelemétől az értesítések módosításától vagy attól, hogy jóváhagyást kérjen a felelősöktől.
- Alakítson ki visszajelzési rendszert az értesítésekhez, még ha az csak annyi is, hogy , hogy az ügyeletesek megjelölhessék az értesítéseket haszontalanként vagy zavaróként. Építsen az értesítésbe egy linket vagy cselekvésre ösztönző felhívást, és rendszeresen nézze át a visszajelzést.
- Alakítson ki a csapatban egy szabályt - az ügyeletesek dolgozzanak az ügyelet egyszerűsítésén, amikor kevés a munka. Az Ön után minden picit jobb legyen, mint előtte volt.
Zárás
Úgy gondolom, hogy a CASE módszer segít a fejlesztőknek és a szervezeteknek az automatikus értesítések beállításáról és küldéséről való megbeszélésében. Egy fejlesztő elindíthatja az értesítések CASE módszer szerinti értékelését, majd az egész szervezet csatlakozhat más fejlesztőkkel, a vezetéssel és az incidenskezelő programokkal, hogy az értesítések jó állapotban maradjanak. Ehhez nincs szükség különös eszközökre vagy bonyolult folyamatokra.
Az egész iparágnak el kell gondolkodnia az emberi tényezőről az ügyelet során, anélkül, hogy veszélyeztetné a kiváló ügyfélszolgálatot. Mindezeket az eszközöket és gyakorlatokat lehet és kell is tökéletesíteni. Remélem, a CASE módszer segít ebben.
Élvezze a tökéletesített értesítéseket!
Forrás: habr.com
