Dziiiiin! Dit is 3 in die oggend, jy droom 'n wonderlike droom, en skielik is daar 'n oproep. Jy is hierdie week aan diens, en blykbaar het iets gebeur. Die outomatiese stelsel bel om uit te vind wat fout is. Dit is 'n belangrike aspek van die bestuur van moderne rekenaarstelsels, maar kom ons kyk hoe om kennisgewings vir mense beter te maak.
Maak kennis met die moniteringsfilosofie, gebore oor etlike dekades van my pligte in verskillende moniteringspanne. Sy is grootliks beïnvloed deur die regte bybel van Rob Evashchuk (My Kennisgewingsfilosofie) ingesluit in die boek oor , en boek deur John Alspaugh (Notas oor die opstel van waarskuwings).
, и - dankie vir jou hulp met die redigering van die pos.
Wat is CASE?
Ek het besluit om met 'n pragtige afkorting vorendag te kom soos of . Ek noem dit CASE metode. Hy beskryf vier punte waaraan aandag gegee moet word wanneer met outomatiese monitering gewerk word:
- (konteks gebonde)
- (praktiese waarde)
- (klem op simptome)
- (graad)
As jy CASE gebruik, behandel jy kennisgewings met 'n gesonde onverskilligheid en maak jy nie mense in die nag wakker nie. Monitering moet gereeld geassesseer word vir bruikbaarheid en doeltreffendheid. Wanneer 'n persoon die kennisgewing ontvang, sal hulle beter geestelike modelle en meer selfvertroue hê.
Om dit makliker te maak om te onthou, stel jou voor dat jy 'n GEVAL nodig het [dit is 'n geval, 'n rede - vertaler se nota] om elke waarskuwing te regverdig. :sonbril:
En hoekom is dit alles?
. Om baie redes. En CASE sal hulle nie almal uitskakel nie. Maar daarmee sal jy snags wakker word met beter kennisgewings. Hierdie metode dek verskeie organisatoriese prosesse wat ook in hierdie saak sal help.
Die skoonheid van die ROOI en GEBRUIK metodes is dat ons met hulle hulp nie net weet hoe om te werk nie, maar ook dieselfde taal met mekaar praat. My hoop is dat die CASE-metode dit makliker sal maak om kennisgewings te bespreek wat ons stelsels beskerm maar ons kollegas besig hou.
Die punt is dat jy 'n kultuur in jou organisasie moet skep waar kennisgewings met 'n gesonde onverskilligheid hanteer word. Kennisgewings kan vir 'n spesifieke doel geskep word, maar dit is nie 'n feit dat dit nie later waarde sal verloor nie. Hoekom het ons hierdie kennisgewing opgestel? Hoe lank gelede is sy kriteria hersien? Met CASE kan hierdie vrae beantwoord word.
Konteks-Swaar - konteks binding
3:XNUMX is nie die beste tyd om boodskappe te lees wat baie slim woorde bevat nie. Om effektief te reageer, het jy inligting nodig. Ideaal gesproke moet dit inligting oor 'n spesifieke kwessie wees, waarvoor die konteks onmiddellik duidelik is, en kennisgewings moet so gekonfigureer word dat dit moontlik is. Dit is "waarneming" en "oriëntasie" van . Dit is nie 'n skande om tyd aan hierdie opstelling te spandeer nie, want om voortdurend 'n persoon se aandag af te lei, is selfs duurder. Kom ons respekteer mekaar.
Probleme het baie bronne. Veral spoke.
Hoe kan ek die diensbeampte help? Die eerste ding wat die diensbeampte sien is 'n kennisgewing, so hy bou alle hipoteses op die basis daarvan. Dan kyk hy na instruksies en dashboards, maar is daar altyd data op 'n spesifieke kennisgewing, en nie net algemene inligting nie? Alspaugh beveel aan "om te dink oor hoe jy die kennisgewing kan interpreteer of daarop reageer" (skyfie 29). 'n Goeie kennisgewing is gefokus op die persoon aan diens, nie net gekonfigureer deur 'n drempel nie.
Hier is dus 'n paar idees oor hoe om die kennisgewingkonteks te verbeter:
- Wys die gebruiker iets nuttig en spesiaal geskep, en nie net gewone instruksies of 'n dashboard nie. Voorheen het ek en die ouens ondersoekende dashboards gebruik wat vir spesifieke kennisgewings opgestel is. Dit sal help as die probleem bekend is, maar sal net ander verwar. Ons moet hier 'n balans vind.
- Vertel ons van die geskiedenis van die kennisgewing: is dit nuut? Werk dit dikwels? Is dit seisoenaal?
- Wys onlangse veranderinge aan die stelselstatus. Het enigiets onlangs verander? (Byvoorbeeld, ontplooiing of aktiveer/deaktiveer funksionaliteit.)
- Wys die verwantskappe en verskaf inligting vir die verstandelike model: sisteemafhanklikhede moet duidelik sigbaar wees, verkieslik met funksionaliteit aangedui.
- Koppel die gebruiker vinnig met die span: kan hulle voortdurende voorvalle sien of kan hulle uitvind wie anders in die maatskappy 'n kennisgewing ontvang het? Program geaktiveer?
Ideaal gesproke sal 'n voorvalbestuursprogram advies verskaf oor hoe om die kennisgewingkonteks van voorvalondersoeke te verbeter. Daar is altyd iets om aan te werk!
Aksiebaar - praktiese waarde
Moet die diensbeampte iets doen in reaksie op die kennisgewing? As jy niks hoef te doen nie of dit is onduidelik wat om te doen, hoekom het jy hom wakker gemaak? Jy moet kennisgewings vermy wat diegene aan diens irriteer en nie aksie vereis nie.
Wat moet ek doen? Wat wil jy hê?
In die verlede, toe stelsels eenvoudig was en spanne klein was, het ons monitering opgestel net om op hoogte te bly van dinge. Kennisgewing dat die las op die hoop toegeneem het, sal ons konteks gee as die diens daarna wanfunksioneer. Op groot skaal sal sulke kennisgewings net verwarring skep omdat ons stelsels altyd in 'n toestand van agteruitgang van verskillende erns werk. Dit lei vinnig tot en natuurlik tot verlies aan sensitiwiteit. Daarom ignoreer of filtreer die diensbeampte sulke kennisgewings en reageer nie altyd daarop soos nodig nie. Moenie in hierdie strik trap nie! Moenie al die kennisgewings in 'n ry opstel en dit dan per e-pos na een of ander godverlate vouer stuur nie.
Hier is hoe 'n kennisgewing met praktiese waarde lyk:
- 'n Kennisgewing vereis optrede eerder as om bloot nuus te rapporteer.
- Hierdie aksie is moeilik of riskant om te outomatiseer. As 'n aksie geoutomatiseer kan word, outomatiseer dit dan, hou op om mense te pla!
- Die kennisgewing bevat dringende aanbevelings in die vorm (SLA) of (RTO). Die diensbeampte kan dan die organisasie se insidentbestuursprogram aktiveer.
Ek wil dit duidelik maak: Ek sê nie dat kennisgewings net vir die belangrikste SLO's (diensvlakdoelwitte) vir die API moet kom nie. SLO-monitering is voortdurend gefragmenteer en verdeel en vereis dieselfde benadering tot alle dienste. Dit is duidelik dat jy die belangrikste SLO's sal dophou vir die kliënte wat jou betaal. Maar infrastruktuur SLO's, soos databasisse, moet ook gemonitor word. Binnekort sal jy met interne kliënte te doen kry en hulle moet ondersteun. En so aan ad infinitum.
Simptoomgebaseer - klem op simptome
Of jy daarvan hou of nie, jy werk in 'n verspreide stelsel (Kavaj). As gevolg hiervan gebruik jy verskillende taktieke om dienste te isoleer en teen mislukking te beskerm (Trainor et al.)3. En alhoewel 'n vertraagde vullisversameling of 'n vasgeloopte databasisnavraag probleme aandui, is dit nie nodig om te haas om dit reg te stel as gebruikers nie probleme in die nabye toekoms het nie.
Dit is belangrike seine en kan praktiese waarde hê, maar as dit nie gebruikers steur nie, is dit nie dringend genoeg om die aandag van die bediende af te lei nie. Oorsaak-gebaseerde kennisgewings is momentopnames van ons verstandelike modelle oor 'n stelselfout. Dit is beter om belangrike simptome op te spoor as om al die moontlike oorsake van 'n mislukking te probeer lys.
Om kennisgewings sinvol te maak, fokus op , belangrik vir gebruikers. Evashchuk noem dit "monitering vir gebruikers." Onthou dat hierdie filosofie regdeur die organisasie toegepas moet word. As 'n diens iewers diep in die infrastruktuur dringende probleme het, sal die toepaslike span daarvoor sorg. Die beskerming van stelsels teen sulke mislukkings is 'n heeltemal aparte saak (Trainer et al., afdeling oor strategieë om kritieke afhanklikhede te verminder).
Simptome is nie so veranderlik nie
Richard Cook herinner ons daaraan dat komplekse stelsels vol foute, tekortkominge en probleme is. Om al die moontlike redes te probeer lys, is 'n Sisifiese taak. Jy probeer probleme beskryf, maar hulle verander heeltyd. Cindy Sridharan glo dat "stelsels nie elke sekonde in perfekte toestand hoef te wees nie" en dit is beter om 'n meer menslike benadering te gebruik ( ("Monitering van verspreide stelsels"), 7).
Vermy kennisgewings na 'n voorval
Tipies word kennisgewings vir oorsake opgestel om voorvalle reg te stel. En hierdie beperkte kennisgewings oor die feit van wat gebeur het, skep 'n valse gevoel van sekuriteit, want die stelsel kom elke keer met nuwe maniere om te breek.
Moenie deur saakkennisgewings mislei word nie. Beter dink:
- Waarom het die simptoomgebaseerde kennisgewing nie die probleem opgemerk nie?
- Sal dit nuttig wees om die konteks vir die gebruiker te verbeter?
- Hoe kan moniteringsinstrumente verbeter word om 'n diagnose vinniger te maak, eerder as om kennisgewings te versamel oor wat gebeur het?
Moniteringsinstrumente vir diagnose sal slegs help as jy daaraan dink as 'n manier om van simptoom na oplossing te beweeg. Sonder hierdie terugvoer sal jy eenvoudig gebombardeer word met laat kennisgewings en kaarte oor vorige mislukkings - en nie 'n woord oor toekomstige nie. Dit is 'n wonderlike geleentheid vir 'n organisasie om van verdediging na aanval te beweeg. En ontwikkelaars en produkbestuurders sal dieselfde verwagtinge en duidelike doelwitte hê. Die saak - CASE (:wink:) - is duidelik vir elke kennisgewing.
Rede-gebaseerde kennisgewings is aanvaarbaar in moderering
Soms laat ons stelsel ons min keuse in terme van oorsaak-gebaseerde kennisgewings. En soms verstaan diegene aan diens heeltemal goed dat 'n simptoom beslis tot 'n mislukking sal lei, en dus praktiese waarde inhou. Miskien is jy net nie seker wat aangaan nie en stel jy kennisgewings op om aan die veilige kant te wees. Hopelik is hierdie aksie tydelik totdat ons die stelsel kan verander om die prestasieprobleem op te los.
Hou die ander komponente van CASE in gedagte wanneer u hierdie situasies hanteer. Net omdat dit tydelik is, beteken dit nie dat jy kan ophou dink met jou kop nie.
Evalueer - evaluasie
Enige veranderinge aan die stelsel (nuwe kode, nuwe infrastruktuur, enigiets nuuts) brei die reeks mislukkings uit (Cook, 3). Werk hierdie kennisgewing steeds soos verwag? Duidelike en huidige geestelike modelle van stelsels en ervaring wat reageer op sommige ondersteuningskennisgewings - dit is die belangrikste kenmerke . Defekte in stelsels ontwikkel voortdurend, en ons moet daarmee tred hou.
Jy moet voortdurend die kwaliteit van elke kennisgewing evalueer om te verseker dat hulle werk soos verwag. Liewe leiers! Dit sal baie makliker vir jou spanne wees as jy hulle help om hierdie proses te vestig! Hier is 'n paar assesseringsidees:
- Gebruik , of ander kennisgewingtoetsmetodes. Die span kan dit self doen sonder om op 'n swaar voorvalbestuurstelsel staat te maak!
- Inkorporeer die versameling van alle voorvalverwante kennisgewings in jou voorvalbestuursprogram. Merk nuttig, skadelik, onvanpas, onduidelik, ens. Gebruik dit as terugvoer.
- Die regte kennisgewings word selde geaktiveer en word noukeurig getoets. Maak seker dat alle skakels werk, wys na die regte konteks, ens.
- As 'n kennisgewing nooit vuur of te dikwels brand nie, is daar iets fout daarmee. Maak dit reg of verwyder dit. Pasop vir oormatige passiwiteit of aktiwiteit!
- Stel kennisgewingtydstempels met vervaldatums. As die vervaldatum verval het, evalueer die kennisgewing deur die CASE-metode te gebruik en werk die tydstempel op. Net soos kos, gaan die vervaldatum gereeld na.
- Vereenvoudig die proses om kennisgewings te verbeter. Gebruik monitering as kode en stoor kennisgewings in 'n Git-bewaarplek. Trek-versoeke help om die span te betrek en gee jou 'n geskiedenis van vorige kennisgewings. En jy sal nie meer bang wees om kennisgewings te verander of toestemming te vra van diegene wat daarvoor verantwoordelik is nie.
- Stel terugvoer vir kennisgewings op, al is dit eenvoudig , sodat diensbeamptes kennisgewings as nutteloos of indringend merk. Sluit 'n skakel of oproep tot aksie in in die kennisgewing self en hersien jou terugvoer gereeld.
- Stel 'n reël in die span vas - laat diegene wat aan diens is werk om die plig te vereenvoudig wanneer daar min werk is. Mag alles na jou 'n bietjie beter wees as wat dit voorheen was.
Gevolgtrekking
Ek glo die CASE-metode help ontwikkelaars en organisasies om die opstel en stuur van outomatiese kennisgewings te bespreek. Een ontwikkelaar kan kennisgewings begin assesseer deur die CASE-metode te gebruik, en dan sal die hele organisasie by ander ontwikkelaars, bestuur en voorvalbestuursprogramme aansluit om kennisgewings in goeie toestand te hou. Dit vereis geen spesiale gereedskap of komplekse prosesse nie.
Die hele bedryf moet aan die menslike faktor dink terwyl hulle aan diens is sonder om die beste kliëntediens in te boet. Al hierdie gereedskap en praktyke kan en moet verbeter word. Ek hoop die CASE-metode sal hiermee help.
Geniet verbeterde kennisgewings!
Bron: will.com