Dziiiiin! Et ass 3 moies, Dir hutt e wonnerschéinen Dram, an op eemol gëtt et en Uruff. Dir sidd dës Woch op der Pflicht, an anscheinend ass eppes geschitt. Den automatiséierte System rifft fir erauszefannen wat falsch ass. Dëst ass e wichtegen Aspekt vun der Gestioun vun modernen Computersystemer, awer loosst eis kucken wéi Dir Notifikatioune fir d'Leit besser maache kënnt.
Bekannt mat der Iwwerwaachungsphilosophie, gebuer iwwer e puer Joerzéngte vu menge Flichten a verschiddenen Iwwerwaachungsteams. Si war gréisstendeels vun der real Bibel vum Rob Evashchuk beaflosst (Meng Notifikatioun Philosophie) am Buch abegraff op , a Buch vum John Alspaugh (Notiz iwwer d'Astellung vun Alarmer).
, и - Merci fir Är Hëllef beim Änneren vum Post.
Wat ass CASE?
Ech hu beschloss mat enger schéiner Ofkierzung ze kommen wéi oder . Ech nennen et CASE Method. Hie beschreift véier Punkte fir opzepassen wann Dir mat automatescher Iwwerwaachung schafft:
- (Kontext gebonnen)
- (praktesche Wäert)
- (Schonen op Symptomer)
- (grad)
Wann Dir CASE benotzt, behandelt Dir Notifikatiounen mat enger gesonder Gläichgültegkeet an erwächt d'Leit net an der Nuecht. D'Iwwerwaachung soll regelméisseg fir Nëtzlechkeet an Effizienz bewäert ginn. Wann eng Persoun d'Notifikatioun kritt, si wäerte besser mental Modeller a méi Vertrauen hunn.
Fir et méi einfach ze erënneren, stellt Iech vir datt Dir e CASE brauch [dat ass e Fall, e Grond - Iwwersetzer Notiz] fir all Alarm ze justifiéieren. :sonnebrille:
A firwat ass dat alles?
. Aus ville Grënn. A CASE wäert se net all eliminéieren. Awer domat erwächt Dir nuets fir besser Notifikatiounen. Dës Method deckt verschidde organisatoresch Prozesser déi och an dëser Matière hëllefen.
D'Schéinheet vun de Methoden RED an USE ass datt mir mat hirer Hëllef net nëmme wësse wéi mir schaffen, mee och déiselwecht Sprooch matenee schwätzen. Meng Hoffnung ass datt d'CASE Method et méi einfach mécht Notifikatiounen ze diskutéieren déi eis Systemer schützen awer eis Kollegen beschäftegt halen.
De Punkt ass datt Dir eng Kultur an Ärer Organisatioun muss kreéieren wou Notifikatiounen mat enger gesonder Gläichgültegkeet behandelt ginn. Notifikatioune kënne fir e spezifeschen Zweck erstallt ginn, awer et ass net e Fakt datt se spéider kee Wäert verléieren. Firwat hu mir dës Notifikatioun ageriicht? Wéi laang sinn hir Critèren iwwerschafft ginn? Mat CASE kënnen dës Froen beäntwert ginn.
Kontext-Heavy - Kontext bindend
3 Auer ass net déi bescht Zäit fir Messagen ze liesen déi vill Smart Wierder enthalen. Fir effektiv ze reagéieren, braucht Dir Informatioun. Idealerweis sollt et Informatioun iwwer e spezifescht Thema sinn, fir deen de Kontext direkt kloer ass, an Notifikatioune solle sou konfiguréiert sinn datt dat méiglech ass. Dëst ass "Observatioun" an "Orientéierung" aus . Et ass net schued Zäit op dësem Setup ze verbréngen, well eng Persoun stänneg oflenken ass nach méi deier. Loosst eis all aner respektéieren.
Problemer hu vill Quellen. Besonnesch Geeschter.
Wéi kann ech dem Duty Offizéier hëllefen? Dat éischt wat den Duty Offizéier gesäit ass eng Notifikatioun, also baut hien all Hypothesen op senger Basis. Da kuckt hien op Instruktiounen an Dashboards, awer ginn et ëmmer Daten iwwer eng spezifesch Notifikatioun, an net nëmmen allgemeng Informatioun? Alspaugh beréit "iwwerdenken wéi Dir d'Notifikatioun interpretéiere kënnt oder reagéieren" (Slide 29). Eng gutt Notifikatioun konzentréiert sech op d'Persoun am Flicht, net nëmmen duerch eng Schwell konfiguréiert.
Also hei sinn e puer Iddien wéi Dir den Notifikatiounskontext verbessert:
- Weist dem Benotzer eppes nëtzlech a speziell erstallt, an net nëmmen gewéinlech Instruktiounen oder en Dashboard. Virdrun hunn d'Jongen an ech investigativ Dashboards benotzt fir spezifesch Notifikatiounen konfiguréiert. Dëst hëlleft wann de Problem bekannt ass, awer nëmmen anerer duercherneen bréngen. Mir mussen hei e Gläichgewiicht fannen.
- Sot eis iwwer d'Geschicht vun der Notifikatioun: ass et nei? Wierkt et dacks? Ass et saisonal?
- Weist rezent Ännerungen am System Staat. Huet sech viru kuerzem eppes geännert? (Zum Beispill deployment oder aktivéieren / deaktivéieren Funktionalitéit.)
- Weist d'Relatiounen a gitt Informatioun fir de mentale Modell: Systemabhängegkeete solle kloer sichtbar sinn, am léifsten mat enger Indikatioun vu Funktionalitéit.
- Verbindt de Benotzer séier mam Team: kënne se lafend Tëschefäll gesinn oder kënne se erausfannen, wien soss an der Firma eng Notifikatioun kritt huet? Programm aktivéiert?
Idealerweis gëtt en Tëschefallmanagementprogramm Berodung iwwer wéi een den Notifikatiounskontext vun Tëschefallenquêten verbessert. Et gëtt ëmmer eppes ze schaffen!
Actionable - praktesch Wäert
Soll de Flichtebeamten eppes als Äntwert op d'Notifikatioun maachen? Wann Dir näischt maache musst oder et ass net kloer wat ze maachen, firwat hutt Dir him erwächt? Dir musst Notifikatiounen vermeiden déi déi am Flicht nerven an keng Handlung erfuerderen.
Wat sollt ech maachen? Wat wëlls du?
An der Vergaangenheet, wann d'Systemer einfach waren an d'Teamen kleng waren, hu mir d'Iwwerwaachung opgestallt just fir um Top vun de Saachen ze bleiwen. Notifikatioun datt d'Laascht op de Koup eropgaang ass wäert eis Kontext ginn wann de Service duerno Feelfunktioune mécht. Op enger grousser Skala wäerten esou Notifikatiounen nëmmen Duercherneen entstoen, well eis Systemer ëmmer an engem Zoustand vun der Degradatioun vu variéierter Gravitéit funktionnéieren. Dëst féiert séier zu an, natierlech, zu Verloscht vun Empfindlechkeet. Dofir ignoréiert oder filtert den Duty Offizéier esou Notifikatiounen an äntwert net ëmmer op se wéi néideg. Falt net an dës Fal! Setzt net all Notifikatiounen an enger Zeil a schéckt se dann per E-Mail an e puer Gottesdéngscht.
Hei ass wéi eng Notiz mat praktesche Wäert ausgesäit:
- Eng Notifikatioun erfuerdert Handlung anstatt just Neiegkeeten ze berichten.
- Dës Aktioun ass schwéier oder riskant ze automatiséieren. Wann eng Handlung automatiséiert ka ginn, da automatiséiert se, stoppt d'Leit ze pesten!
- D'Avis enthält dréngend Empfehlungen an der Form (SLA) oder (RTO). Den Duty Offizéier kann dann den Incident Management Programm vun der Organisatioun aktivéieren.
Ech wëll klären: Ech soen net datt Notifikatiounen nëmme fir déi wichtegst SLOs (Service-Level Ziler) fir d'API solle kommen. SLO Iwwerwachung ass stänneg fragmentéiert a gedeelt a erfuerdert déiselwecht Approche fir all Servicer. Et ass kloer datt Dir déi wichtegst SLOs verfollegt fir d'Clienten déi Iech bezuelen. Awer Infrastruktur SLOs, wéi Datenbanken, mussen och iwwerwaacht ginn. Geschwënn musst Dir mat interne Clienten ëmgoen an se ënnerstëtzen. An esou weider ad infinitum.
Symptombaséiert - Schwéierpunkt op Symptomer
Egal ob Dir et gär hutt oder net, Dir schafft an engem verdeelte System (Kavaj). Als Resultat benotzt Dir verschidde Taktike fir Servicer ze isoléieren an se vu Feeler ze schützen (Trainor et al.)3. An och wann eng verspéiten Drecksversammlung oder eng gestoppt Datebank Ufro Problemer beweist, ass et net néideg ze presséieren fir se ze fixéieren wann d'Benotzer keng Problemer an der nächster Zukunft hunn.
Dëst si wichteg Signaler a kënne praktesche Wäert hunn, awer wann se d'Benotzer net stéieren, dann ass et net dréngend genuch fir de Begleeder ze distractéieren. Ursaach-baséiert Notifikatiounen sinn Schnappschëss vun eise mentale Modeller iwwer e Systemfehler. Et ass besser wichteg Symptomer ze verfolgen wéi ze probéieren all méiglech Ursaachen vun engem Echec ze lëschten.
Fir Notifikatiounen sënnvoll ze maachen, fokusséiert op , wichteg fir Benotzer. Evashchuk nennt dëst "Iwwerwaachung fir Benotzer." Denkt drun datt dës Philosophie an der ganzer Organisatioun applizéiert muss ginn. Wann e Service dréngend Problemer iergendwou déif an der Infrastruktur huet, këmmert sech dat entspriechend Team ëm si. Systemer vu sou Feeler ze schützen ass eng ganz separat Saach (Trainer et al., Sektioun iwwer Strategien fir kritesch Ofhängegkeeten ze minimiséieren).
Symptomer sinn net esou variabel
De Richard Cook erënnert eis datt komplex Systemer voller Mängel, Mängel a Probleemer sinn. Probéieren all méiglech Grënn ze Lëscht ass eng Sisyphean Aufgab. Dir probéiert Problemer ze beschreiwen, awer si änneren déi ganzen Zäit. D'Cindy Sridharan mengt datt "Systemer net all Sekonn an engem perfekte Zoustand musse sinn" an et ass besser eng méi mënschlech Approche ze benotzen ( ("Verdeelte Systemer iwwerwaachen"), 7).
Vermeiden Notifikatiounen no engem Tëschefall
Typesch sinn Notifikatiounen fir Ursaachen konfiguréiert fir Tëschefäll ze korrigéieren. An dës limitéiert Notifikatiounen iwwer d'Tatsaach, wat geschitt ass, kreéieren e falscht Sécherheetsgefill, well de System all Kéier mat neie Weeër kënnt fir ze briechen.
Loosst Iech net duerch Ursaach Notifikatiounen täuschen. Besser denken:
- Firwat huet d'Symptom-baséiert Notifikatioun de Problem net gemierkt?
- Wär et hëllefräich de Kontext fir de Benotzer ze verbesseren?
- Wéi kënne Iwwerwaachungsinstrumenter verbessert ginn fir eng Diagnos méi séier ze maachen, anstatt Notifikatiounen ze sammelen iwwer wat geschitt ass?
Iwwerwaachungsinstrumenter fir Diagnos hëlleft nëmmen wann Dir un se denkt als e Wee fir vu Symptom op Léisung ze plënneren. Ouni dëse Feedback wäert Dir einfach mat spéiden Notifikatiounen an Charts iwwer vergaange Feeler bombardéiert ginn - an net e Wuert iwwer zukünfteg. Dëst ass eng super Geleeënheet fir eng Organisatioun vu Verteidegung op Attack ze plënneren. An Entwéckler a Produktmanager wäerten déiselwecht Erwaardungen a kloer Ziler hunn. De Fall - CASE (:wink:) - ass kloer fir all Notifikatioun.
Grond-baséiert Notifikatiounen sinn a Moderatioun tolerabel
Heiansdo léisst eise System eis wéineg Wiel a punkto Ursaach-baséiert Notifikatiounen. An heiansdo verstinn déi am Flicht ganz gutt datt e Symptom definitiv zu engem Echec féiert, an dofir praktesch Wäert enthält. Vläicht sidd Dir just net sécher wat lass ass a stellt Notifikatiounen op fir op der sécherer Säit ze sinn. Hoffentlech ass dës Aktioun temporär bis mir de System änneren kënnen fir d'Leeschtungsprobleem ze léisen.
Bleift déi aner Komponente vu CASE am Kapp wann Dir mat dëse Situatiounen handelt. Just well et temporär ass heescht net datt Dir ophale kënnt mat Ärem Kapp ze denken.
Evaluéiert - Evaluatioun
All Ännerungen am System (neie Code, nei Infrastruktur, eppes Neies) erweidert d'Gamme vu Feeler (Cook, 3). Wierkt dës Notifikatioun nach ëmmer wéi erwaart? Kloer an aktuell mental Modeller vu Systemer an Erfahrung äntweren op e puer Support Notifikatiounen - dëst sinn d'Schlësselfunktiounen . Mängel an de Systemer entwéckelen sech permanent, a mir musse mat hinnen halen.
Dir musst dauernd d'Qualitéit vun all Notifikatioun evaluéieren fir sécherzestellen datt se funktionnéieren wéi erwaart. Léif Leadere! Et wäert vill méi einfach fir Är Teams sinn wann Dir hinnen hëlleft dëse Prozess opzebauen! Hei sinn e puer Bewäertung Iddien:
- Benotzt , oder aner Notifikatiounstestmethoden. D'Equipe kann et selwer maachen ouni op e schwéieren Incident Management System ze vertrauen!
- Integréiert d'Sammlung vun all Incident-relatéierten Notifikatiounen an Ärem Incident Management Programm. Mark nëtzlech, schiedlech, onpassend, onkloer, etc.. Benotzt se als Feedback.
- Déi richteg Notifikatioune ginn selten ausgeléist a gi suergfälteg getest. Gitt sécher datt all Linken funktionnéieren, op de richtege Kontext weisen, asw.
- Wann eng Notifikatioun ni brennt oder ze dacks brennt, ass et eppes falsch. Fixéieren oder ewechhuelen. Opgepasst op exzessiv Passivitéit oder Aktivitéit!
- Setzt Notifikatiounszäitstempel mat Verfallsdatum. Wann den Verfallsdatum ofgelaf ass, evaluéiert d'Notifikatioun mat der CASE Method an aktualiséieren den Zäitstempel. Just wéi Iessen, kontrolléiert den Verfallsdatum regelméisseg.
- Vereinfacht de Prozess fir Notifikatiounen ze verbesseren. Benotzt Iwwerwaachung als Code a späichert Notifikatiounen an engem Git Repository. Pull Ufroen hëllefen d'Team ze engagéieren an Iech eng Geschicht vu vergaangenen Notifikatiounen ze ginn. An Dir wäert net méi Angscht hunn Notifikatiounen z'änneren oder Erlaabnis vun de Responsabelen ze froen.
- Ariichten Feedback fir Notifikatiounen, och wann et einfach ass , sou datt Flicht Offizéier Notifikatiounen als nëtzlos oder opdrénglech markéieren. Embed e Link oder Call to Action an d'Notifikatioun selwer an iwwerpréift Äre Feedback regelméisseg.
- Etabléiert eng Regel am Team - loosst déi am Flicht schaffen fir d'Pflicht ze vereinfachen wann et wéineg Aarbecht ass. Kann alles no Dir e bësse besser sinn wéi et virdru war.
Konklusioun
Ech gleewen, datt d'CASE Method Entwéckler an Organisatiounen hëlleft fir d'Opstellung an d'Schécken vun automatiséierten Notifikatiounen ze diskutéieren. Een Entwéckler kann ufänken Notifikatiounen mat der CASE Method ze bewäerten, an da wäert d'ganz Organisatioun mat aneren Entwéckler, Gestioun an Incident Management Programmer matmaachen fir Notifikatiounen a gudder Form ze halen. Dëst erfuerdert keng speziell Tools oder komplexe Prozesser.
Déi ganz Industrie muss iwwer de mënschleche Faktor nodenken wärend Dir op der Pflicht sidd ouni den Top-Notch Clientsservice ofzeginn. All dës Tools a Praktike kënnen a solle verbessert ginn. Ech hoffen, datt d'CASE Method mat dësem hëlleft.
Genéisst verbessert Notifikatiounen!
Source: will.com