Dziiiiin! Hajnali 3 óra van, csodálatos álmod van, és hirtelen hívás érkezik. Ezen a héten szolgálatban vagy, és úgy tűnik, történt valami. Az automatizált rendszer felhív, hogy kiderítse, mi a hiba. Ez a modern számítógépes rendszerek kezelésének fontos szempontja, de nézzük meg, hogyan tehetjük jobbá az értesítéseket az emberek számára.
Ismerkedjen meg a monitorozás filozófiájával, amely több évtizedes, különböző monitoring csapatokban végzett munkám során született. Nagy hatással volt rá Rob Evashchuk valódi bibliája (My Notification Philosophy) című könyvben szerepel , és John Alspaugh könyve (Megjegyzések a riasztások beállításához).
, и - köszönöm a hozzászólás szerkesztésében nyújtott segítségét.
Mi az a CASE?
Úgy döntöttem, hogy kitalálok egy szép rövidítést, mint pl vagy . úgy hívom CASE módszer. Négy pontot ír le, amelyekre figyelni kell, ha automatikus felügyelettel dolgozik:
- (kontextushoz kötött)
- (gyakorlati érték)
- (a hangsúly a tüneteken)
- (fokozat)
Ha a CASE-t használja, egészséges közönnyel kezeli az értesítéseket, és nem ébreszti fel az embereket éjszaka. A monitorozás hasznosságát és hatékonyságát rendszeresen értékelni kell. Amikor egy személy megkapja az értesítést, jobb mentális modellje lesz, és nagyobb önbizalma lesz.
Hogy könnyebben emlékezzen, képzelje el, hogy szüksége van egy CASE-ra [vagyis egy esetre, egy okra - fordítói megjegyzés] az egyes figyelmeztetések indokolásához. :napszemüveg:
És miért van mindez?
. Sok ok miatt. És a CASE nem szünteti meg mindegyiket. De ezzel éjszaka jobb értesítésekre ébred. Ez a módszer különféle szervezeti folyamatokat fed le, amelyek szintén segítenek ebben a kérdésben.
A RED és a USE metódusok szépsége abban rejlik, hogy segítségükkel nem csak dolgozni tudunk, hanem egy nyelvet is beszélünk egymással. Remélem, hogy a CASE módszerrel könnyebb lesz megbeszélni a rendszerünket védő, de munkatársainkat lefoglaló értesítéseket.
A lényeg az, hogy olyan kultúrát kell teremtenie a szervezetében, ahol az értesítéseket egészséges közönnyel kezelik. Az értesítéseket meghatározott célra lehet létrehozni, de nem tény, hogy később nem veszítenek értékükből. Miért állítottuk be ezt az értesítést? Milyen régen módosították a kritériumait? A CASE segítségével ezekre a kérdésekre lehet választ adni.
Context-Heavy – kontextuskötés
Hajnali 3 óra nem a legjobb idő a sok okos szót tartalmazó üzenetek olvasására. A hatékony reagáláshoz információra van szüksége. Ideális esetben ez egy konkrét probléma információja, amelynek a kontextusa azonnal világos, és az értesítéseket úgy kell beállítani, hogy ez lehetséges legyen. Ez a "megfigyelés" és a "tájolás". . Nem szégyen erre a beállításra időt szánni, mert az ember folyamatos elterelése még drágább. Tiszteljük egymást.
A problémáknak sok forrása van. Főleg a szellemek.
Hogyan segíthetek az ügyeletesnek? Az első dolog, amit az ügyeletes lát, az egy értesítés, ezért minden hipotézist ennek alapján állít fel. Ezután megnézi az utasításokat és a műszerfalakat, de mindig vannak adatok egy adott értesítésről, és nem csak általános információk? Alspaugh azt tanácsolja, hogy „gondolja át, hogyan értelmezheti vagy válaszolhatna az értesítésre” (29. dia). A jó értesítés az ügyeletes személyre összpontosul, nem csak egy küszöb által konfigurálva.
Tehát itt van néhány ötlet az értesítési környezet javítására:
- Mutasson a felhasználónak valami hasznosat és speciálisan létrehozott dolgot, és ne csak egyszerű utasításokat vagy műszerfalat. Korábban a srácok és én oknyomozó irányítópultokat használtunk, amelyeket konkrét értesítésekhez konfiguráltak. Ez segít, ha a probléma ismert, de csak összezavar másokat. Itt meg kell találnunk az egyensúlyt.
- Meséljen az értesítés előzményeiről: új? Gyakran működik? Szezonális?
- A rendszerállapot legutóbbi módosításainak megjelenítése. Változott valami mostanában? (Például a telepítés vagy a funkciók engedélyezése/letiltása.)
- Mutassa be az összefüggéseket és adjon információt a mentális modellhez: a rendszerfüggőségeknek jól láthatónak kell lenniük, lehetőleg a funkcionalitás jelzésével.
- Gyorsan kapcsolja össze a felhasználót a csapattal: láthatja a folyamatban lévő incidenseket, vagy megtudhatja, hogy a cégen belül ki kapott még értesítést? Program aktív?
Ideális esetben egy incidenskezelési program tanácsot ad az incidensvizsgálatok értesítési környezetének javítására vonatkozóan. Mindig van min dolgozni!
Cselekvő – gyakorlati érték
Az ügyeletesnek kell tennie valamit az értesítésre? Ha nem kell semmit sem tenned, vagy nem világos, hogy mit tegyél, miért ébresztetted fel? Kerülni kell az olyan értesítéseket, amelyek bosszantanak a szolgálatban lévőket, és nem igényelnek intézkedést.
Mit kellene tennem? Mit akarsz?
Korábban, amikor a rendszerek egyszerűek voltak, és a csapatok kicsik voltak, csak azért állítottuk be a felügyeletet, hogy naprakészek legyünk. Az értesítés, hogy a kupac terhelése megnőtt, kontextust ad számunkra, ha a szolgáltatás később meghibásodik. Az ilyen értesítések nagy léptékben csak zavart keltenek, mivel rendszereink mindig különböző súlyosságú leromlási állapotban működnek. Ez gyorsan oda vezet és természetesen az érzékenység elvesztésére. Ezért az ügyeletes figyelmen kívül hagyja, sőt kiszűri az ilyen értesítéseket, és nem mindig reagál rájuk szükség szerint. Ne ess ebbe a csapdába! Ne állítsa be az összes értesítést egymás után, majd küldje el e-mailben valamelyik isten háta mögötti mappába.
Így néz ki egy gyakorlati értékű értesítés:
- Az értesítéshez cselekvésre van szükség, nem pedig egyszerűen híradásra.
- Ezt a műveletet nehéz vagy kockázatos automatizálni. Ha egy művelet automatizálható, akkor automatizáld, ne zaklatd az embereket!
- A közlemény sürgős ajánlásokat tartalmaz az űrlapon (SLA) ill (RTO). Az ügyeletes ezután aktiválhatja a szervezet incidenskezelési programját.
Szeretném tisztázni: nem azt mondom, hogy az értesítéseknek csak az API legfontosabb SLO-iról (szolgáltatási szintű célkitűzéseiről) kell érkezniük. Az SLO felügyelet folyamatosan töredezett és megosztott, és minden szolgáltatáshoz ugyanazt a megközelítést követeli meg. Egyértelmű, hogy nyomon fogja követni a legfontosabb SLO-kat az Ön számára fizető ügyfelek számára. De az infrastruktúra SLO-kat, például az adatbázisokat is figyelni kell. Hamarosan belső ügyfelekkel kell foglalkoznia és támogatnia kell őket. És így tovább a végtelenségig.
Tünetalapú – a tünetek hangsúlyozása
Akár tetszik, akár nem, elosztott rendszerben dolgozol (Kavaj). Ennek eredményeként Ön különböző taktikákat alkalmaz a szolgáltatások elkülönítésére és a meghibásodások elleni védelmére (Trainor et al.)3. És bár a késedelmes szemétgyűjtés vagy az elakadt adatbázis-lekérdezés problémákat jelez, nem kell sietni a javításukkal, ha a felhasználóknak a közeljövőben nem lesznek problémái.
Ezek fontos jelzések és gyakorlati értékkel bírhatnak, de ha nem zavarják a felhasználókat, akkor nem elég sürgős elterelni a kísérő figyelmét. Az ok-alapú értesítések a rendszerhibával kapcsolatos mentális modelljeink pillanatképei. Jobb nyomon követni a fontos tüneteket, mint megpróbálni felsorolni a hiba összes lehetséges okát.
Az értesítések értelmessé tételéhez összpontosítson a , fontos a felhasználók számára. Evashchuk ezt „felhasználók figyelésének” nevezi. Ne feledje, hogy ezt a filozófiát az egész szervezetben alkalmazni kell. Ha egy szolgáltatásnak sürgős problémái vannak valahol az infrastruktúra mélyén, a megfelelő csapat elintézi azokat. A rendszerek ilyen meghibásodásoktól való védelme teljesen külön kérdés (Trainer et al., a kritikus függőségek minimalizálásának stratégiáiról szóló rész).
A tünetek nem annyira változóak
Richard Cook emlékeztet arra, hogy az összetett rendszerek tele vannak hibákkal, hiányosságokkal és problémákkal. Az összes lehetséges ok felsorolása sziszifuszi feladat. Próbálod leírni a problémákat, de azok folyamatosan változnak. Cindy Sridharan úgy véli, hogy „a rendszereknek nem kell minden másodpercben tökéletes állapotban lenniük”, és jobb egy emberibb megközelítést alkalmazni ( („Elosztott rendszerek figyelése”), 7).
Kerülje el az incidens utáni értesítéseket
Az okokra vonatkozó értesítések általában az események kijavítására vannak beállítva. És ezek a korlátozott értesítések a történtek tényéről hamis biztonságérzetet keltenek, mert a rendszer minden alkalommal új módszerekkel áll elő a megtörésre.
Ne tévesszen meg az okokkal kapcsolatos figyelmeztetések. Inkább gondold át:
- Miért nem vette észre a tünetalapú értesítés a problémát?
- Hasznos lenne a kontextus javítása a felhasználó számára?
- Hogyan lehet javítani a megfigyelő eszközöket, hogy gyorsabban diagnosztizálják, ahelyett, hogy értesítéseket halmoznának fel a történtekről?
A diagnosztikai megfigyelési eszközök csak akkor segítenek, ha úgy gondolja, hogy ezek a tünetről a megoldásra való átlépés módja. E visszajelzés nélkül egyszerűen csak a múltbeli kudarcokról szóló késői értesítések és diagramok bombázzák, a jövőbeli hibákról pedig egy szó sem. Ez egy nagyszerű lehetőség egy szervezet számára, hogy védekezésből támadásba lépjen. A fejlesztőknek és a termékmenedzsereknek pedig ugyanazok az elvárásaik és világos céljaik lesznek. Az eset - CASE (:wink:) - minden értesítésnél egyértelmű.
Az ok-alapú értesítések mértékkel elviselhetők
Néha rendszerünk kevés választási lehetőséget hagy számunkra az ok-alapú értesítések terén. És néha az ügyeletesek tökéletesen megértik, hogy egy tünet mindenképpen meghibásodáshoz vezet, ezért gyakorlati értéket is tartalmaz. Lehet, hogy nem biztos abban, hogy mi történik, és a biztonság kedvéért beállítja az értesítéseket. Remélhetőleg ez a művelet átmeneti, amíg meg nem tudjuk változtatni a rendszert a teljesítményprobléma megoldása érdekében.
E helyzetek kezelésekor tartsa szem előtt a CASE többi összetevőjét. Csak azért, mert ez átmeneti, nem jelenti azt, hogy abbahagyhatod a fejeddel való gondolkodást.
Értékelt - értékelés
A rendszer bármilyen módosítása (új kód, új infrastruktúra, bármi új) kibővíti a hibák körét (Cook, 3). Ez az értesítés továbbra is a várt módon működik? A rendszerek világos és aktuális mentális modelljei és tapasztalatai az egyes támogatási értesítésekre való reagálásban - ezek a legfontosabb jellemzők . A rendszerek hibái folyamatosan fejlődnek, és lépést kell tartanunk velük.
Folyamatosan értékelnie kell az egyes értesítések minőségét annak biztosítása érdekében, hogy az elvárásoknak megfelelően működjenek. Kedves vezetők! Sokkal könnyebb dolguk lesz a csapatoknak, ha segítesz nekik ennek a folyamatnak a kialakításában! Íme néhány értékelési ötlet:
- használat , vagy egyéb értesítési tesztelési módszerek. A csapat saját maga is meg tudja csinálni anélkül, hogy súlyos incidenskezelő rendszerre kellene hagyatkoznia!
- Az összes incidenssel kapcsolatos értesítés gyűjtését építse be incidenskezelési programjába. Jelölje meg hasznosnak, károsnak, nem megfelelő, homályosnak stb. Használja visszajelzésként.
- A megfelelő értesítések ritkán jelennek meg, és gondosan tesztelik. Győződjön meg arról, hogy minden hivatkozás működik, mutasson a megfelelő kontextusra stb.
- Ha egy értesítés soha nem vagy túl gyakran aktiválódik, akkor valami nincs rendben vele. Javítsa meg vagy távolítsa el. Vigyázz a túlzott passzivitásra vagy aktivitásra!
- Állítson be értesítési időbélyegeket lejárati dátummal. Ha a lejárati dátum lejárt, értékelje ki az értesítést a CASE módszerrel, és frissítse az időbélyeget. Az élelmiszerekhez hasonlóan rendszeresen ellenőrizze a lejárati dátumot.
- Egyszerűsítse az értesítések javításának folyamatát. Használja a megfigyelést kódként, és tárolja az értesítéseket egy Git-tárolóban. A lehívási kérések segítik a csapat bevonását, és a korábbi értesítések előzményeit nyújtják. És többé nem fog félni megváltoztatni az értesítéseket, vagy engedélyt kérni az értük felelős személyektől.
- Állítson be visszajelzést az értesítésekhez, még akkor is, ha ez egyszerű , hogy az ügyeletesek haszontalannak vagy tolakodónak jelöljék meg az értesítéseket. Illesszen be egy linket vagy cselekvésre ösztönzést magába az értesítésbe, és rendszeresen tekintse át visszajelzését.
- Alakíts ki egy szabályt a csapatban – hagyd, hogy az ügyeletesek dolgozzanak, hogy leegyszerűsítsék az ügyeletet, ha kevés a munka. Legyen minden utánad egy kicsit jobb, mint azelőtt volt.
Következtetés
Úgy gondolom, hogy a CASE módszer segít a fejlesztőknek és a szervezeteknek megbeszélni az automatikus értesítések beállítását és küldését. Egy fejlesztő elkezdheti értékelni az értesítéseket a CASE módszerrel, majd az egész szervezet csatlakozik a többi fejlesztőhöz, menedzsmenthez és incidenskezelő programhoz, hogy az értesítések jó állapotban legyenek. Ez nem igényel speciális eszközöket vagy összetett folyamatokat.
Az egész iparágnak az emberi tényezőre kell gondolnia szolgálat közben anélkül, hogy feláldozná a kiváló ügyfélszolgálatot. Mindezeket az eszközöket és gyakorlatokat lehet és kell is fejleszteni. Remélem a CASE módszer segít ebben.
Élvezze a továbbfejlesztett értesítéseket!
Forrás: will.com