Ystyr geiriau: Dziiiiin! Mae'n 3 yn y bore, rydych chi'n cael breuddwyd hyfryd, ac yn sydyn mae galwad. Rydych chi ar ddyletswydd yr wythnos hon, ac mae'n debyg bod rhywbeth wedi digwydd. Mae'r system awtomataidd yn galw i ddarganfod beth sydd o'i le. Mae hon yn agwedd bwysig ar reoli systemau cyfrifiadurol modern, ond gadewch i ni edrych ar sut i wneud hysbysiadau yn well i bobl.
Dewch yn gyfarwydd â'r athroniaeth fonitro, a anwyd dros sawl degawd o'm dyletswyddau mewn gwahanol dimau monitro. Cafodd ei dylanwadu i raddau helaeth gan y Beibl go iawn gan Rob Evashchuk (Fy Notification Philosophy) yn gynwysedig yn y llyfr ar , a llyfr gan John Alspaugh (Nodiadau ar osod rhybuddion).
, и — diolch am eich help i olygu'r post.
Beth yw CASE?
Penderfynais ddod o hyd i dalfyriad hardd fel neu . Rwy'n ei alw dull ACHOS. Disgrifia bedwar pwynt i roi sylw iddynt wrth weithio gyda monitro awtomatig:
- (cyd-destun wedi'i rwymo)
- (gwerth ymarferol)
- (pwyslais ar symptomau)
- (gradd)
Os ydych chi'n defnyddio CASE, rydych chi'n trin hysbysiadau â difaterwch iach ac nid ydych chi'n deffro pobl yn y nos. Dylid asesu defnyddioldeb ac effeithiolrwydd monitro yn rheolaidd. Pan fydd person yn derbyn yr hysbysiad, bydd ganddo fodelau meddyliol gwell a mwy o hyder.
Er mwyn ei gwneud hi'n haws cofio, dychmygwch fod angen ACHOS [hynny yw, achos, rheswm - nodyn y cyfieithydd] i gyfiawnhau pob rhybudd. : sbectol haul:
A pham hyn i gyd?
. Am lawer o resymau. Ac ni fydd CASE yn eu dileu i gyd. Ond ag ef, byddwch yn deffro yn y nos i hysbysiadau gwell. Mae'r dull hwn yn cwmpasu amrywiol brosesau sefydliadol a fydd hefyd yn helpu yn y mater hwn.
Harddwch y dulliau COCH a DEFNYDDIO yw ein bod, gyda'u cymorth, nid yn unig yn gwybod sut i weithio, ond hefyd yn siarad yr un iaith â'n gilydd. Fy ngobaith yw y bydd y dull CASE yn ei gwneud yn haws i drafod hysbysiadau sy'n diogelu ein systemau ond yn cadw ein cydweithwyr yn brysur.
Y pwynt yw bod angen i chi greu diwylliant yn eich sefydliad lle mae hysbysiadau'n cael eu trin â difaterwch iach. Gellir creu hysbysiadau at ddiben penodol, ond nid yw'n ffaith na fyddant yn colli gwerth yn ddiweddarach. Pam wnaethon ni sefydlu'r hysbysiad hwn? Pa mor bell yn ôl y mae ei feini prawf wedi'u diwygio? Gydag CASE, gellir ateb y cwestiynau hyn.
Cyd-destun-Trwm - rhwymo cyd-destun
Nid 3 am yw'r amser gorau i ddarllen negeseuon sy'n cynnwys llawer o eiriau craff. Er mwyn ymateb yn effeithiol, mae angen gwybodaeth arnoch. Yn ddelfrydol, dylai hyn fod yn wybodaeth am fater penodol, y mae'r cyd-destun yn glir ar ei gyfer ar unwaith, a dylid ffurfweddu hysbysiadau fel bod hyn yn bosibl. Dyma "sylw" a "cyfeiriadedd" o . Nid yw'n drueni treulio amser ar y gosodiad hwn, oherwydd mae tynnu sylw person yn gyson hyd yn oed yn ddrytach. Gadewch i ni barchu ein gilydd.
Mae gan broblemau lawer o ffynonellau. Yn enwedig ysbrydion.
Sut gallaf helpu'r swyddog ar ddyletswydd? Y peth cyntaf y mae'r swyddog ar ddyletswydd yn ei weld yw hysbysiad, felly mae'n adeiladu pob rhagdybiaeth ar ei sail. Yna mae'n edrych ar gyfarwyddiadau a dangosfyrddau, ond a oes data bob amser ar hysbysiad penodol, ac nid gwybodaeth gyffredinol yn unig? Mae Alspaugh yn cynghori “meddwl sut y gallech ddehongli neu ymateb i’r hysbysiad” (sleid 29). Mae hysbysiad da yn canolbwyntio ar y person ar ddyletswydd, nid dim ond wedi'i ffurfweddu gan drothwy.
Felly dyma rai syniadau ar sut i wella'r cyd-destun hysbysu:
- Dangoswch rywbeth defnyddiol a grëwyd yn arbennig i'r defnyddiwr, ac nid dim ond cyfarwyddiadau cyffredin neu ddangosfwrdd. Yn flaenorol, roedd y dynion a minnau'n defnyddio dangosfyrddau ymchwiliol wedi'u ffurfweddu ar gyfer hysbysiadau penodol. Bydd hyn yn helpu os yw'r broblem yn hysbys, ond bydd ond yn drysu pobl eraill. Mae angen inni ddod o hyd i gydbwysedd yma.
- Dywedwch wrthym am hanes yr hysbysiad: a yw'n newydd? A yw'n gweithio'n aml? A yw'n dymhorol?
- Dangos newidiadau diweddar i gyflwr y system. Oes unrhyw beth wedi newid yn ddiweddar? (Er enghraifft, defnydd neu ymarferoldeb galluogi/anablu.)
- Dangoswch y perthnasoedd a rhowch wybodaeth ar gyfer y model meddyliol: dylai dibyniaethau system fod yn amlwg, gydag arwydd o ymarferoldeb yn ddelfrydol.
- Cysylltwch y defnyddiwr â'r tîm yn gyflym: a allant weld digwyddiadau parhaus neu a allant ddarganfod pwy arall yn y cwmni sydd wedi derbyn hysbysiad? Rhaglen actifadu?
Yn ddelfrydol, bydd rhaglen rheoli digwyddiad yn rhoi cyngor ar sut i wella cyd-destun hysbysu ymchwiliadau i ddigwyddiadau. Mae rhywbeth i weithio arno bob amser!
Gweithredadwy - gwerth ymarferol
A ddylai'r swyddog ar ddyletswydd wneud rhywbeth mewn ymateb i'r hysbysiad? Os nad oes angen i chi wneud unrhyw beth neu os yw'n aneglur beth i'w wneud, pam wnaethoch chi ei ddeffro? Mae angen i chi osgoi hysbysiadau sy'n cythruddo'r rhai sydd ar ddyletswydd ac nad oes angen gweithredu arnynt.
Beth ddylwn i ei wneud? Beth wyt ti eisiau?
Yn y gorffennol, pan oedd systemau'n syml a thimau'n fach, fe wnaethom sefydlu monitro dim ond i gadw ar ben pethau. Bydd hysbysiad bod y llwyth ar y domen wedi cynyddu yn rhoi cyd-destun i ni os bydd y gwasanaeth yn camweithio wedyn. Ar raddfa fawr, bydd hysbysiadau o'r fath ond yn creu dryswch oherwydd bod ein systemau bob amser yn gweithredu mewn cyflwr o ddirywiad o ddifrifoldeb amrywiol. Mae hyn yn arwain yn gyflym at ac, wrth gwrs, i golli sensitifrwydd. Felly, mae'r swyddog ar ddyletswydd yn anwybyddu neu hyd yn oed yn hidlo hysbysiadau o'r fath ac nid yw bob amser yn ymateb iddynt yn ôl yr angen. Peidiwch â syrthio i'r trap hwn! Peidiwch â gosod yr holl hysbysiadau yn olynol ac yna eu hanfon trwy e-bost i ffolder duwiol.
Dyma sut olwg sydd ar hysbysiad gyda gwerth ymarferol:
- Mae hysbysiad yn gofyn am weithredu yn hytrach na dim ond adrodd newyddion.
- Mae'r cam hwn yn anodd neu'n beryglus i'w awtomeiddio. Os gellir awtomeiddio gweithred, yna ei hawtomeiddio, peidiwch â phoeni pobl!
- Mae'r hysbysiad yn cynnwys argymhellion brys ar y ffurflen (CLG) neu (RTO). Yna gall y swyddog ar ddyletswydd roi rhaglen rheoli digwyddiadau'r sefydliad ar waith.
Rwyf am egluro: nid wyf yn dweud y dylai hysbysiadau ddod yn unig ar gyfer yr SLOs pwysicaf (amcanion lefel gwasanaeth) ar gyfer yr API. Mae monitro SLO yn dameidiog ac yn rhanedig yn gyson ac mae angen yr un ymagwedd at bob gwasanaeth. Mae'n amlwg y byddwch chi'n olrhain yr SLOs pwysicaf ar gyfer y cleientiaid sy'n eich talu. Ond mae angen monitro SLOs seilwaith, megis cronfeydd data, hefyd. Cyn bo hir bydd yn rhaid i chi ddelio â chwsmeriaid mewnol a'u cefnogi. Ac yn y blaen ad infinitum.
Seiliedig ar symptomau - pwyslais ar symptomau
P'un a ydych chi'n ei hoffi ai peidio, rydych chi'n gweithio mewn system ddosbarthedig (Kavaj). O ganlyniad, rydych yn defnyddio gwahanol dactegau i ynysu gwasanaethau a’u hamddiffyn rhag methiant (Trainor et al.)3. Ac er bod oedi wrth gasglu sbwriel neu ymholiad cronfa ddata sydd wedi'i oedi yn awgrymu problemau, nid oes angen rhuthro i'w trwsio os na fydd defnyddwyr yn cael problemau yn y dyfodol agos.
Mae'r rhain yn arwyddion pwysig a gall fod ganddynt werth ymarferol, ond os nad ydynt yn tarfu ar ddefnyddwyr, yna nid yw'n ddigon brys i dynnu sylw'r cynorthwyydd. Mae hysbysiadau sy'n seiliedig ar achosion yn gipluniau o'n modelau meddwl am fethiant system. Mae'n well olrhain symptomau pwysig na cheisio rhestru holl achosion posibl methiant.
I wneud hysbysiadau yn ystyrlon, canolbwyntiwch ar , yn bwysig i ddefnyddwyr. Mae Evashchuk yn galw hyn yn “fonitro ar gyfer defnyddwyr.” Cofiwch fod yn rhaid cymhwyso'r athroniaeth hon trwy'r sefydliad cyfan. Os oes gan wasanaeth broblemau brys rhywle dwfn yn y seilwaith, bydd y tîm priodol yn gofalu amdanynt. Mae amddiffyn systemau rhag methiannau o’r fath yn fater cwbl ar wahân (Trainer et al., adran ar strategaethau ar gyfer lleihau dibyniaethau critigol).
Nid yw'r symptomau mor amrywiol
Mae Richard Cook yn ein hatgoffa bod systemau cymhleth yn llawn diffygion, diffygion a phroblemau. Mae ceisio rhestru pob rheswm posibl yn dasg Sisyffaidd. Rydych chi'n ceisio disgrifio problemau, ond maen nhw'n newid drwy'r amser. Mae Cindy Sridharan yn credu “nad oes rhaid i systemau fod mewn cyflwr perffaith bob eiliad” ac mae’n well defnyddio dull mwy dynol ( (“Monitro Systemau Dosbarthedig”), 7).
Osgoi hysbysiadau ar ôl digwyddiad
Yn nodweddiadol, mae hysbysiadau am achosion yn cael eu ffurfweddu i gywiro digwyddiadau. Ac mae'r hysbysiadau cyfyngedig hyn am yr hyn a ddigwyddodd yn creu ymdeimlad ffug o ddiogelwch, oherwydd mae'r system bob tro yn dod o hyd i ffyrdd newydd o dorri.
Peidiwch â chael eich twyllo gan hysbysiadau achos. Gwell meddwl:
- Pam na sylwodd yr hysbysiad yn seiliedig ar symptomau ar y broblem?
- A fyddai'n ddefnyddiol gwella'r cyd-destun ar gyfer y defnyddiwr?
- Sut y gellir gwella offer monitro i wneud diagnosis yn gyflymach, yn hytrach na chronni hysbysiadau am yr hyn a ddigwyddodd?
Dim ond os ydych chi'n meddwl amdanyn nhw fel ffordd o symud o symptom i ddatrysiad y bydd offer monitro diagnosis yn helpu. Heb yr adborth hwn, byddwch yn cael eich peledu â hysbysiadau hwyr a siartiau am fethiannau'r gorffennol - ac nid gair am rai yn y dyfodol. Mae hwn yn gyfle gwych i sefydliad symud o amddiffyn i ymosodiad. A bydd gan ddatblygwyr a rheolwyr cynnyrch yr un disgwyliadau a nodau clir. Mae'r achos - ACHOS (:wink:) - yn glir ar gyfer pob hysbysiad.
Mae hysbysiadau ar sail rheswm yn oddefadwy yn gymedrol
Weithiau mae ein system yn gadael ychydig o ddewis i ni o ran hysbysiadau ar sail achos. Ac weithiau mae'r rhai sydd ar ddyletswydd yn deall yn iawn y bydd symptom yn bendant yn arwain at fethiant, ac felly'n cynnwys gwerth ymarferol. Efallai nad ydych chi'n siŵr beth sy'n digwydd ac yn sefydlu hysbysiadau i fod ar yr ochr ddiogel. Gobeithio mai cam dros dro yw hwn hyd nes y gallwn newid y system i ddatrys y mater perfformiad.
Cadwch gydrannau eraill CASE mewn cof wrth ddelio â'r sefyllfaoedd hyn. Nid yw'r ffaith ei fod yn rhywbeth dros dro yn golygu y gallwch chi roi'r gorau i feddwl â'ch pen.
Wedi'i werthuso - gwerthuso
Mae unrhyw newidiadau i'r system (cod newydd, seilwaith newydd, unrhyw beth newydd) yn ehangu'r ystod o fethiannau (Cook, 3). A yw'r hysbysiad hwn yn dal i weithio yn ôl y disgwyl? Modelau meddwl clir a chyfredol o systemau a phrofiad yn ymateb i rai hysbysiadau cymorth - dyma'r nodweddion allweddol . Mae diffygion mewn systemau yn esblygu'n gyson, a rhaid inni gadw i fyny â nhw.
Mae angen i chi werthuso ansawdd pob hysbysiad yn gyson i sicrhau eu bod yn gweithio yn ôl y disgwyl. Annwyl arweinwyr! Bydd yn llawer haws i'ch timau os byddwch yn eu helpu i sefydlu'r broses hon! Dyma rai syniadau asesu:
- Defnyddiwch , neu ddulliau profi hysbysu eraill. Gall y tîm ei wneud eu hunain heb orfod dibynnu ar system rheoli digwyddiadau trwm!
- Ymgorffori'r casgliad o'r holl hysbysiadau sy'n ymwneud â digwyddiadau yn eich rhaglen rheoli digwyddiadau. Marcio defnyddiol, niweidiol, amhriodol, aneglur, ac ati. Defnyddiwch nhw fel adborth.
- Mae'r hysbysiadau cywir yn cael eu sbarduno'n anaml ac yn cael eu profi'n ofalus. Sicrhewch fod pob dolen yn gweithio, pwyntiwch at y cyd-destun cywir, ac ati.
- Os nad yw hysbysiad byth yn tanio neu'n tanio'n rhy aml, mae rhywbeth o'i le. Trwsiwch ef neu ei dynnu. Gwyliwch rhag goddefedd neu weithgaredd gormodol!
- Gosodwch stampiau amser hysbysu gyda dyddiadau dod i ben. Os yw'r dyddiad dod i ben wedi dod i ben, gwerthuswch yr hysbysiad gan ddefnyddio'r dull CASE a diweddarwch y stamp amser. Yn union fel bwyd, gwiriwch y dyddiad dod i ben yn rheolaidd.
- Symleiddio'r broses o wella hysbysiadau. Defnyddiwch fonitro fel cod a storio hysbysiadau mewn ystorfa Git. Mae ceisiadau tynnu yn helpu i ymgysylltu â'r tîm a rhoi hanes hysbysiadau blaenorol i chi. Ac ni fyddwch yn ofni newid hysbysiadau na gofyn caniatâd y rhai sy'n gyfrifol amdanynt mwyach.
- Sefydlu adborth ar gyfer hysbysiadau, hyd yn oed os yw'n syml , fel bod swyddogion dyletswydd yn nodi bod hysbysiadau yn ddiwerth neu'n ymwthiol. Mewnosod dolen neu alwad i weithredu yn yr hysbysiad ei hun ac adolygu eich adborth yn rheolaidd.
- Sefydlwch reol yn y tîm – gadewch i’r rhai sydd ar ddyletswydd weithio i symleiddio’r ddyletswydd pan nad oes llawer o waith. Boed i bopeth ar ôl i chi fod ychydig yn well nag yr oedd o'r blaen.
Casgliad
Rwy'n credu bod y dull CASE yn helpu datblygwyr a sefydliadau i drafod sefydlu ac anfon hysbysiadau awtomataidd. Gall un datblygwr ddechrau asesu hysbysiadau gan ddefnyddio'r dull CASE, ac yna bydd y sefydliad cyfan yn ymuno â datblygwyr, rheolwyr a rhaglenni rheoli digwyddiadau eraill i gadw hysbysiadau mewn cyflwr da. Nid oes angen unrhyw offer arbennig na phrosesau cymhleth ar gyfer hyn.
Mae angen i'r diwydiant cyfan feddwl am y ffactor dynol tra ar ddyletswydd heb aberthu gwasanaeth cwsmeriaid o'r radd flaenaf. Gellir a dylid gwella'r holl offer a'r arferion hyn. Rwy'n gobeithio y bydd y dull CASE yn helpu gyda hyn.
Mwynhewch hysbysiadau gwell!
Ffynhonnell: hab.com
