Dziiiiin! Klukkan er 3 að morgni, þig dreymir yndislegan draum og allt í einu er hringt. Þú ert á vakt þessa vikuna og greinilega hefur eitthvað gerst. Sjálfvirka kerfið hringir til að komast að því hvað er að. Þetta er mikilvægur þáttur í stjórnun nútíma tölvukerfa, en við skulum skoða hvernig hægt er að gera tilkynningar betri fyrir fólk.
Kynntu þér eftirlitsheimspeki, fædd í nokkra áratugi af störfum mínum í mismunandi eftirlitsteymum. Hún var að miklu leyti undir áhrifum frá alvöru biblíunni frá Rob Evashchuk (My Notification Philosophy) innifalinn í bókinni um , og bók eftir John Alspaugh (Athugasemdir um að setja upp viðvaranir).
, и - takk fyrir hjálpina við að breyta færslunni.
Hvað er CASE?
Ég ákvað að koma með fallega skammstöfun eins og eða . Ég kalla það CASE aðferð. Hann lýsir fjórum atriðum sem þarf að huga að þegar unnið er með sjálfvirkt eftirlit:
- (samhengi bundið)
- (praktískt gildi)
- (áhersla á einkenni)
- (einkunn)
Ef þú notar CASE, meðhöndlar þú tilkynningar af heilbrigðu afskiptaleysi og vekur fólk ekki á nóttunni. Reglulega skal meta eftirlit með tilliti til gagnsemi og skilvirkni. Þegar einstaklingur fær tilkynninguna mun hann hafa betri andlegar fyrirmyndir og meira sjálfstraust.
Til að gera það auðveldara að muna, ímyndaðu þér að þú þurfir CASE [það er, tilfelli, ástæða - athugasemd þýðanda] til að réttlæta hverja viðvörun. :sólgleraugu:
Og hvers vegna er þetta allt?
. Af mörgum ástæðum. Og CASE mun ekki útrýma þeim öllum. En með því muntu vakna á nóttunni við betri tilkynningar. Þessi aðferð tekur til ýmissa skipulagsferla sem munu einnig hjálpa í þessu efni.
Fegurðin við RED og USE aðferðirnar er að með hjálp þeirra kunnum við ekki aðeins að vinna, heldur tölum líka sama tungumál hvert við annað. Von mín er sú að CASE aðferðin muni gera það auðveldara að ræða tilkynningar sem vernda kerfi okkar en halda samstarfsfólki okkar uppteknum.
Málið er að þú þarft að búa til menningu í fyrirtækinu þínu þar sem tilkynningar eru meðhöndlaðar af heilbrigðu afskiptaleysi. Hægt er að búa til tilkynningar í ákveðnum tilgangi, en það er ekki staðreynd að þær tapi ekki gildi síðar. Hvers vegna settum við upp þessa tilkynningu? Hversu langt er síðan viðmið þess hafa verið endurskoðuð? Með CASE er hægt að svara þessum spurningum.
Context-Heavy - samhengisbinding
3:XNUMX er ekki besti tíminn til að lesa skilaboð sem innihalda mikið af gáfulegum orðum. Til að bregðast við á áhrifaríkan hátt þarftu upplýsingar. Helst ætti þetta að vera upplýsingar um tiltekið mál, þar sem samhengið er strax ljóst, og tilkynningar ættu að vera stilltar þannig að það sé mögulegt. Þetta er "athugun" og "stefnumörkun" frá . Það er ekki synd að eyða tíma í þessa uppsetningu, því það er enn dýrara að afvegaleiða mann stöðugt. Berum virðingu hvert fyrir öðru.
Vandamál eiga sér margar heimildir. Sérstaklega draugar.
Hvernig get ég hjálpað vaktstjóranum? Það fyrsta sem vaktstjóri sér er tilkynning, þannig að hann byggir allar tilgátur á grundvelli hennar. Svo skoðar hann leiðbeiningar og mælaborð, en eru alltaf gögn um ákveðna tilkynningu en ekki bara almennar upplýsingar? Alspaugh ráðleggur „að hugsa um hvernig þú gætir túlkað eða brugðist við tilkynningunni“ (skygga 29). Góð tilkynning beinist að þeim sem er á vakt, ekki bara stillt af þröskuldi.
Svo hér eru nokkrar hugmyndir um hvernig á að bæta tilkynningasamhengið:
- Sýndu notandanum eitthvað gagnlegt og sérstaklega búið til, en ekki bara venjulegar leiðbeiningar eða mælaborð. Áður notuðum við strákarnir rannsóknarmælaborð sem voru stillt fyrir sérstakar tilkynningar. Þetta mun hjálpa ef vandamálið er þekkt, en mun aðeins rugla aðra. Við þurfum að finna jafnvægi hér.
- Segðu okkur frá sögu tilkynningarinnar: er hún ný? Virkar það oft? Er það árstíðabundið?
- Sýna nýlegar breytingar á kerfisstöðu. Hefur eitthvað breyst nýlega? (Til dæmis, dreifing eða kveikja/slökkva á virkni.)
- Sýndu tengslin og gefðu upplýsingar fyrir hugarlíkanið: kerfisfíkn ætti að vera greinilega sýnileg, helst með vísbendingu um virkni.
- Tengdu notandann fljótt við teymið: getur hann séð yfirstandandi atvik eða getur hann fundið út hverjir aðrir í fyrirtækinu hafa fengið tilkynningu? Forrit virkjaður?
Helst mun atvikastjórnunaráætlun veita ráðgjöf um hvernig bæta megi tilkynningasamhengi atviksrannsókna. Það er alltaf eitthvað til að vinna í!
Aðgerðarhæft - hagnýtt gildi
Ætti vaktstjóri að gera eitthvað til að bregðast við tilkynningunni? Ef þú þarft ekki að gera neitt eða það er óljóst hvað þú átt að gera, hvers vegna vaktir þú hann? Þú þarft að forðast tilkynningar sem pirra þá sem eru á vakt og krefjast ekki aðgerða.
Hvað ætti ég að gera? Hvað viltu?
Áður fyrr, þegar kerfi voru einföld og teymi lítil, settum við upp eftirlit bara til að fylgjast með hlutunum. Tilkynning um að álag á hauginn hafi aukist mun gefa okkur samhengi ef þjónustan bilar í kjölfarið. Í stórum stíl munu slíkar tilkynningar aðeins valda ruglingi vegna þess að kerfi okkar starfa alltaf í niðurbrotsástandi af mismunandi alvarleika. Þetta leiðir fljótt til og auðvitað tap á næmni. Því hunsar vaktstjórinn eða síar jafnvel slíkar tilkynningar og bregst ekki alltaf við þeim eftir þörfum. Ekki falla í þessa gryfju! Ekki setja allar tilkynningarnar upp í röð og senda þær síðan með tölvupósti í einhverja guðforláta möppu.
Svona lítur tilkynning með hagnýtt gildi út:
- Tilkynning krefst aðgerða frekar en að tilkynna bara fréttir.
- Það er erfitt eða áhættusamt að gera þessa aðgerð sjálfvirkan. Ef hægt er að gera aðgerð sjálfvirkan, gerðu hana sjálfvirkan, hættu að plága fólk!
- Í tilkynningunni eru brýn ábendingar á forminu (SLA) eða (RTO). Vaktstjóri getur síðan virkjað atvikastjórnunarkerfi stofnunarinnar.
Ég vil skýra: Ég er ekki að segja að tilkynningar ættu aðeins að koma fyrir mikilvægustu SLOs (þjónustustigsmarkmið) fyrir API. SLO vöktun er stöðugt sundurleitt og tvískipt og krefst sömu nálgunar á alla þjónustu. Það er ljóst að þú munt fylgjast með mikilvægustu SLO fyrir viðskiptavinina sem greiða þér. En innviða SLOs, svo sem gagnagrunna, þarf líka að fylgjast með. Brátt verður þú að eiga við innri viðskiptavini og styðja þá. Og svo framvegis ad infinitum.
Byggt á einkennum - áhersla á einkenni
Hvort sem þér líkar það eða verr, þá ertu að vinna í dreifðu kerfi (Kavaj). Þar af leiðandi notar þú mismunandi aðferðir til að einangra þjónustu og vernda hana gegn bilun (Trainor o.fl.)3. Og þó að seinkun á sorphirðu eða stöðvuð gagnagrunnsfyrirspurn bendi til vandamála, þá er engin þörf á að flýta sér til að laga þau ef notendur lenda ekki í vandræðum í náinni framtíð.
Þetta eru mikilvæg merki og geta haft hagnýtt gildi, en ef þau trufla ekki notendur, þá er ekki nógu brýnt að afvegaleiða þjóninn. Tilkynningar byggðar á orsökum eru skyndimyndir af hugrænum líkönum okkar um kerfisbilun. Það er betra að fylgjast með mikilvægum einkennum en að reyna að skrá allar mögulegar orsakir bilunar.
Til að gera tilkynningar marktækar skaltu einblína á , mikilvægt fyrir notendur. Evashchuk kallar þetta „eftirlit með notendum. Mundu að þessari hugmyndafræði verður að beita um alla stofnunina. Ef þjónusta lendir í brýnum vandamálum einhvers staðar djúpt í innviðunum mun viðeigandi teymi sjá um þau. Að vernda kerfi fyrir slíkum bilunum er algjörlega sérstakt mál (Trainer o.fl., kafli um aðferðir til að lágmarka mikilvægar ósjálfstæði).
Einkenni eru ekki eins breytileg
Richard Cook minnir okkur á að flókin kerfi eru full af göllum, göllum og vandamálum. Að reyna að telja upp allar mögulegar ástæður er sisýphean verkefni. Þú reynir að lýsa vandamálum en þau breytast alltaf. Cindy Sridharan telur að „kerfi þurfa ekki að vera í fullkomnu ástandi á hverri sekúndu“ og það sé betra að nota mannlegri nálgun ( ("Vöktun dreifðra kerfa"), 7).
Forðastu tilkynningar eftir atvik
Venjulega eru tilkynningar um orsakir stilltar til að leiðrétta atvik. Og þessar takmarkaðu tilkynningar um staðreyndina um hvað gerðist skapa falska öryggistilfinningu, því kerfið kemur í hvert skipti með nýjar leiðir til að brjóta.
Ekki láta blekkjast af orsök tilkynningar. Hugsaðu betur:
- Af hverju tók tilkynningin sem byggir á einkennum ekki eftir vandamálinu?
- Væri það gagnlegt að bæta samhengið fyrir notandann?
- Hvernig er hægt að bæta eftirlitstæki til að gera greiningu hraðari, frekar en að safna tilkynningum um hvað gerðist?
Vöktunartæki til greiningar munu aðeins hjálpa ef þú hugsar um þau sem leið til að fara frá einkennum til lausnar. Án þessara viðbragða muntu einfaldlega verða fyrir sprengjum af seintengdum tilkynningum og töflum um fyrri mistök - og ekki orð um framtíðar. Þetta er frábært tækifæri fyrir samtök til að fara úr vörn í sókn. Og þróunaraðilar og vörustjórar munu hafa sömu væntingar og skýr markmið. Málið - CASE (:wink:) - er skýrt fyrir hverja tilkynningu.
Tilkynningar byggðar á ástæðu eru þolanlegar í hófi
Stundum skilur kerfið okkar okkur lítið eftir hvað varðar tilkynningar byggðar á orsökum. Og stundum skilja þeir sem eru á vakt fullkomlega að einkenni mun örugglega leiða til bilunar og hefur því hagnýtt gildi. Kannski ertu bara ekki viss um hvað er að gerast og ert að setja upp tilkynningar til að vera á örygginu. Vonandi er þessi aðgerð tímabundin þar til við getum breytt kerfinu til að leysa árangursvandamálið.
Hafðu aðra þætti CASE í huga þegar þú tekur á þessum aðstæðum. Þó það sé tímabundið þýðir það ekki að þú getir hætt að hugsa með höfðinu.
Metið - mat
Allar breytingar á kerfinu (nýr kóði, ný innviði, eitthvað nýtt) auka bilanasviðið (Cook, 3). Virkar þessi tilkynning enn eins og búist var við? Skýr og núverandi hugræn líkön af kerfum og reynsla við að bregðast við einhverjum stuðningstilkynningum - þetta eru lykilatriðin . Gallar í kerfum eru í stöðugri þróun og við verðum að halda í við þá.
Þú þarft stöðugt að meta gæði hverrar tilkynningar til að tryggja að þær virki eins og búist er við. Kæru leiðtogar! Það verður miklu auðveldara fyrir liðin þín ef þú hjálpar þeim að koma þessu ferli á fót! Hér eru nokkrar hugmyndir um mat:
- Используйте , eða aðrar tilkynningarprófunaraðferðir. Liðið getur gert það sjálft án þess að þurfa að reiða sig á þungt atvikastjórnunarkerfi!
- Settu söfnun allra tilkynninga sem tengjast atvikum inn í atviksstjórnunarkerfið þitt. Merktu gagnlegt, skaðlegt, óviðeigandi, óljóst osfrv. Notaðu þau sem endurgjöf.
- Réttu tilkynningarnar birtast sjaldan og eru vandlega prófaðar. Gakktu úr skugga um að allir tenglar virki, benda á rétt samhengi o.s.frv.
- Ef tilkynning kviknar aldrei eða of oft, þá er eitthvað að henni. Lagaðu það eða fjarlægðu það. Varist óhóflega aðgerðaleysi eða virkni!
- Stilltu tilkynningartímastimpla með gildistíma. Ef fyrningardagsetningin er útrunnin skaltu meta tilkynninguna með CASE aðferðinni og uppfæra tímastimpilinn. Rétt eins og matur, athugaðu fyrningardagsetninguna reglulega.
- Einfaldaðu ferlið við að bæta tilkynningar. Notaðu eftirlit sem kóða og geymdu tilkynningar í Git geymslu. Dragabeiðnir hjálpa til við að taka þátt í liðinu og gefa þér sögu um fyrri tilkynningar. Og þú munt ekki lengur vera hræddur við að breyta tilkynningum eða biðja um leyfi frá þeim sem bera ábyrgð á þeim.
- Settu upp endurgjöf fyrir tilkynningar, jafnvel þótt það sé einfalt , þannig að vaktmenn merki tilkynningar sem gagnslausar eða uppáþrengjandi. Fella tengil eða ákall til aðgerða í tilkynninguna sjálfa og skoðaðu ábendingar þínar reglulega.
- Settu reglu í teymið - láttu þá sem eru á vakt vinna til að einfalda skylduna þegar lítið er um vinnu. Megi allt eftir þig verða aðeins betra en það var áður.
Ályktun
Ég tel að CASE aðferðin hjálpi forriturum og stofnunum að ræða um uppsetningu og sendingu sjálfvirkra tilkynninga. Einn þróunaraðili getur byrjað að meta tilkynningar með CASE-aðferðinni og þá mun öll stofnunin taka þátt í öðrum forriturum, stjórnendum og atvikastjórnunarforritum til að halda tilkynningum í góðu formi. Þetta krefst ekki sérstakra verkfæra eða flókinna ferla.
Allur iðnaðurinn þarf að hugsa um mannlega þáttinn meðan á vakt stendur án þess að fórna framúrskarandi þjónustu við viðskiptavini. Öll þessi verkfæri og aðferðir má og ætti að bæta. Ég vona að CASE aðferðin hjálpi við þetta.
Njóttu bættra tilkynninga!
Heimild: www.habr.com