Dziiiiin! It is 3 yn 'e moarntiid, do hast in prachtige dream, en ynienen is der in oprop. Jo binne dizze wike op plicht, en der is blykber wat bard. It automatisearre systeem ropt om út te finen wat der mis is. Dit is in wichtich aspekt fan it behearen fan moderne kompjûtersystemen, mar litte wy sjen hoe't jo notifikaasjes better meitsje kinne foar minsken.
Kom yn 'e kunde mei de monitoaringfilosofy, berne oer ferskate desennia fan myn taken yn ferskate monitoaringteams. Se waard foar in grut part beynfloede troch de echte bibel fan Rob Evashchuk (Myn Notifikaasje Filosofy) opnommen yn it boek oer , en boek fan John Alspaugh (Opmerkingen oer it ynstellen fan warskôgings).
, и - tank foar jo help by it bewurkjen fan de post.
Wat is CASE?
Ik besleat om te kommen mei in moaie ôfkoarting lykas of . Ik neam it CASE metoade. Hy beskriuwt fjouwer punten om op te letten by it wurkjen mei automatyske tafersjoch:
- (kontekst ferbûn)
- (praktyske wearde)
- (klam op symptomen)
- (klasse)
As jo CASE brûke, behannelje jo notifikaasjes mei in sûne ûnferskilligens en meitsje minsken nachts net wekker. Tafersjoch moat regelmjittich beoardiele wurde op nut en effektiviteit. As in persoan de notifikaasje ûntfangt, sille se bettere mentale modellen en mear fertrouwen hawwe.
Om it makliker te meitsjen om te ûnthâlden, stel jo foar dat jo in CASE nedich binne [dat is, in saak, in reden - oersetter syn notysje] om elke warskôging te rjochtfeardigjen. :sinnebril:
En wêrom is dit alles?
. Foar in soad redenen. En CASE sil se net allegear eliminearje. Mar dêrmei wurde jo nachts wekker mei bettere notifikaasjes. Dizze metoade omfettet ferskate organisatoaryske prosessen dy't ek sille helpe yn dizze saak.
De skientme fan 'e metoaden RED en USE is dat wy mei har help net allinich witte hoe't wy wurkje moatte, mar ek deselde taal mei elkoar prate. Myn hope is dat de CASE-metoade it makliker meitsje sil om notifikaasjes te besprekken dy't ús systemen beskermje, mar ús kollega's dwaande hâlde.
It punt is dat jo in kultuer moatte meitsje yn jo organisaasje wêr't notifikaasjes wurde behannele mei in sûne ûnferskilligens. Notifikaasjes kinne makke wurde foar in spesifyk doel, mar it is gjin feit dat se letter net sille ferlieze wearde. Wêrom hawwe wy dizze notifikaasje ynsteld? Hoe lang lyn binne har kritearia herzien? Mei CASE kinne dizze fragen beantwurde wurde.
Kontekst-Swier - kontekst binding
3 oere is net de bêste tiid om berjochten te lêzen dy't in protte tûke wurden befetsje. Om effektyf te reagearjen hawwe jo ynformaasje nedich. Ideal soe dit ynformaasje wêze moatte oer in spesifyk probleem, wêrfoar't de kontekst fuortendaliks dúdlik is, en notifikaasjes moatte wurde konfigureare sadat dit mooglik is. Dit is "observaasje" en "oriïntaasje" fan . It is gjin skande om tiid te besteegjen oan dizze opset, om't it konstant ôfliede fan in persoan noch djoerder is. Litte wy inoar respektearje.
Problemen hawwe in protte boarnen. Benammen spoeken.
Hoe kin ik de tsjinstoffisier helpe? It earste wat de tsjinstoffisier sjocht is in notifikaasje, sadat hy alle hypotezen op basis dêrfan bout. Dan sjocht er nei ynstruksjes en dashboards, mar binne der altyd gegevens oer in spesifike notifikaasje, en net allinnich algemiene ynformaasje? Alspaugh advisearret "tinken oer hoe't jo de notifikaasje kinne ynterpretearje of reagearje" (slide 29). In goede notifikaasje is rjochte op 'e persoan yn tsjinst, net allinich konfigureare troch in drompel.
Dat hjir binne wat ideeën oer hoe't jo de notifikaasjekontekst kinne ferbetterje:
- Lit de brûker wat nuttichs en spesjaal makke sjen, en net allinich gewoane ynstruksjes as in dashboard. Earder brûkten de jonges en ik ûndersyksdashboards konfigureare foar spesifike notifikaasjes. Dit sil helpe as it probleem is bekend, mar sil allinne betize oaren. Wy moatte hjir in lykwicht fine.
- Fertel ús oer de skiednis fan 'e notifikaasje: is it nij? Wurket it faak? Is it seasonal?
- Lit resinte feroarings oan de systeem tastân. Is der koartlyn wat feroare? (Bygelyks ynset of funksjonaliteit ynskeakelje/útskeakelje.)
- Lit de relaasjes sjen en jouwe ynformaasje foar it mentale model: systeemôfhinklikens moatte dúdlik sichtber wêze, leafst mei in yndikaasje fan funksjonaliteit.
- Ferbine de brûker fluch mei it team: kinne se trochgeande ynsidinten sjen of kinne se útfine wa't oars yn it bedriuw in notifikaasje krigen hat? Programma aktivearre?
Ideaallik sil in programma foar ynsidintbehear advys jaan oer hoe't de notifikaasjekontekst fan ynsidintûndersiken kinne ferbetterje. Der is altyd wat om oan te wurkjen!
Aksjeber - praktyske wearde
Moat de tsjinstoffisier wat dwaan nei oanlieding fan de melding? As jo neat hoege te dwaan of it is ûndúdlik wat te dwaan, wêrom hawwe jo him wekker? Jo moatte notifikaasjes foarkomme dy't de tsjinstanners irritearje en gjin aksje nedich binne.
Wat moat ik dwaan? Wat wolle jo?
Yn it ferline, doe't systemen ienfâldich wiene en teams lyts wiene, sette wy tafersjoch op gewoan om op 'e hichte te bliuwen. Notifikaasje dat de lading op 'e heap is tanommen sil ús kontekst jaan as de tsjinst dêrnei falt. Op grutte skaal sille sokke notifikaasjes allinich betizing meitsje, om't ús systemen altyd wurkje yn in steat fan degradaasje fan ferskate earnst. Dit gau liedt ta en, fansels, ta ferlies fan gefoelichheid. Dêrom negearret of filtert de tsjinstoffisier sokke notifikaasjes en reagearret der net altyd op as nedich. Fal net yn dizze fal! Stel net alle notifikaasjes op in rige yn en stjoer se dan per e-post nei ien of oare godferlitten map.
Hjir is hoe't in meidieling mei praktyske wearde derút sjocht:
- In notifikaasje fereasket aksje ynstee fan gewoan nijs te rapportearjen.
- Dizze aksje is lestich of riskant om te automatisearjen. As in aksje kin wurde automatisearre, automatisearje it dan, stopje minsken te pesten!
- De meidieling befettet driuwende oanbefellings yn it formulier (SLA) of (RTO). De tsjinstoffisier kin dan it programma foar incidentbehear fan 'e organisaasje aktivearje.
Ik wol dúdlik meitsje: ik sis net dat notifikaasjes allinich komme moatte foar de wichtichste SLO's (doelen op tsjinstnivo) foar de API. SLO-monitoring wurdt konstant fragminteare en ferdield en fereasket deselde oanpak foar alle tsjinsten. It is dúdlik dat jo de wichtichste SLO's sille folgje foar de kliïnten dy't jo betelje. Mar ynfrastruktuer SLO's, lykas databases, moatte ek kontrolearre wurde. Meikoarten sille jo mei ynterne klanten omgean moatte en har stypje. En sa fierder ad infinitum.
Symptom-basearre - klam op symptomen
Oft jo it leuk fine of net, jo wurkje yn in ferspraat systeem (Kavaj). As gefolch brûke jo ferskate taktyk om tsjinsten te isolearjen en te beskermjen tsjin mislearring (Trainor et al.)3. En hoewol in fertrage jiskefetsammeljen of in stilsteande databankfraach problemen oanjout, is d'r gjin need nedich om se te reparearjen as brûkers yn 'e heine takomst gjin problemen hawwe.
Dit binne wichtige sinjalen en kinne praktyske wearde hawwe, mar as se brûkers net steure, dan is it net driuwend genôch om de begelieder ôf te lieden. Cause-basearre notifikaasjes binne snapshots fan ús mentale modellen oer in systeemflater. It is better om wichtige symptomen te folgjen dan om te besykjen om alle mooglike oarsaken fan in mislearring op te listjen.
Om notifikaasjes sinfol te meitsjen, fokusje op , wichtich foar brûkers. Evashchuk neamt dit "monitoring foar brûkers." Unthâld dat dizze filosofy yn 'e hiele organisaasje moat wurde tapast. As in tsjinst earne djip yn 'e ynfrastruktuer driuwende problemen hat, sil it passende team har soargje. It beskermjen fan systemen tsjin sokke flaters is in folslein aparte saak (Trainer et al., seksje oer strategyen foar it minimalisearjen fan krityske ôfhinklikens).
Symptomen binne net sa fariabel
Richard Cook herinnert ús dat komplekse systemen fol binne mei gebreken, tekoartkommingen en problemen. It besykjen om alle mooglike redenen op te listjen is in Sisyphean taak. Jo besykje problemen te beskriuwen, mar se feroarje de hiele tiid. Cindy Sridharan is fan betinken dat "systemen net elke sekonde yn perfekte steat hoege te wêzen" en it is better om in mear minsklike oanpak te brûken ( ("Distribuearre systemen kontrolearje"), 7).
Mije notifikaasjes nei in ynsidint
Typysk wurde notifikaasjes foar oarsaken konfigureare om ynsidinten te korrigearjen. En dizze beheinde notifikaasjes oer it feit fan wat barde meitsje in falsk gefoel fan feiligens, om't it systeem elke kear nije manieren komt om te brekken.
Wês net ferrifelje troch oarsaak meidielings. Better tinke:
- Wêrom hat de symptoom-basearre notifikaasje it probleem net opmurken?
- Soe it nuttich wêze om de kontekst foar de brûker te ferbetterjen?
- Hoe kinne tafersjochynstruminten wurde ferbettere om in diagnoaze rapper te meitsjen, ynstee fan notifikaasjes te sammeljen oer wat der bard is?
Tafersjochynstruminten foar diagnoaze sille allinich helpe as jo se tinke as in manier om fan symptoom nei oplossing te gean. Sûnder dizze feedback sille jo gewoan bombardearre wurde mei lette notifikaasjes en diagrammen oer mislearrings yn it ferline - en gjin wurd oer takomstige. Dit is in geweldige kâns foar in organisaasje om fan definsje nei oanfal te gean. En ûntwikkelders en produktbehearders sille deselde ferwachtings en dúdlike doelen hawwe. De saak - CASE (:wink:) - is dúdlik foar elke notifikaasje.
Reden-basearre notifikaasjes binne tolerabel yn moderaasje
Soms lit ús systeem ús in bytsje kar yn termen fan oarsaak-basearre notifikaasjes. En soms begripe de tsjinstfeinten hiel goed dat in symptoom definityf sil liede ta in mislearring, en dêrom praktyske wearde befettet. Miskien binne jo gewoan net wis wat der bart en stelle jo notifikaasjes op om oan 'e feilige kant te wêzen. Hooplik is dizze aksje tydlik oant wy it systeem kinne feroarje om it prestaasjeprobleem op te lossen.
Hâld de oare komponinten fan CASE yn gedachten by it omgean mei dizze situaasjes. Krekt om't it tydlik is, betsjut net dat jo kinne stopje mei tinken mei jo holle.
Evaluearre - evaluaasje
Alle feroarings oan it systeem (nije koade, nije ynfrastruktuer, alles nij) wreidzje it oanbod fan mislearrings (Cook, 3). Wurket dizze notifikaasje noch lykas ferwachte? Dúdlike en aktuele mentale modellen fan systemen en ûnderfining dy't reagearje op guon stipe-notifikaasjes - dit binne de wichtichste funksjes . Defekten yn systemen binne konstant yn ûntwikkeling, en wy moatte byhâlde mei harren.
Jo moatte de kwaliteit fan elke notifikaasje konstant evaluearje om te soargjen dat se wurkje lykas ferwachte. Beste lieders! It sil folle makliker wêze foar jo teams as jo har helpe om dit proses te fêstigjen! Hjir binne wat beoardielingsideeën:
- Gebrûk , of oare notifikaasjetestmetoaden. It team kin it sels dwaan sûnder te fertrouwe op in swier ynsidintbehearsysteem!
- Meitsje de kolleksje fan alle ynsidinten-relatearre notifikaasjes yn jo programma foar ynsidintbehear. Markearje nuttich, skealik, net geskikt, ûndúdlik, ensfh. Brûk se as feedback.
- De juste notifikaasjes wurde selden trigger en wurde soarchfâldich hifke. Soargje derfoar dat alle keppelings wurkje, wize nei de juste kontekst, ensfh.
- As in notifikaasje nea fjoer of te faak fjoer, dan is der wat mis mei. Fix it of fuortsmite. Pas op foar oermjittige passiviteit of aktiviteit!
- Stel notifikaasjetiidstempels yn mei ferfaldatums. As de ferfaldatum is ferrûn, evaluearje de notifikaasje mei de CASE-metoade en aktualisearje it tiidstempel. Krekt as iten, kontrolearje de ferfaldatum regelmjittich.
- Ienfâldigje it proses foar it ferbetterjen fan notifikaasjes. Brûk tafersjoch as koade en bewarje notifikaasjes yn in Git-repository. Pull-oanfragen helpe it team te belûken en jouwe jo in skiednis fan eardere notifikaasjes. En jo sille net langer bang wêze om notifikaasjes te feroarjen of tastimming te freegjen fan de ferantwurdliken foar har.
- Stel feedback yn foar notifikaasjes, sels as it ienfâldich is , sadat tsjinstoffisieren notifikaasjes markearje as nutteloos of opdringerig. Foegje in keppeling of oprop ta aksje yn 'e notifikaasje sels en besjoch jo feedback regelmjittich.
- Stel in regel yn it team - lit de tsjinstfeinten wurkje om de plicht te ferienfâldigjen as der net folle wurk is. Mei alles nei jo in bytsje better wêze as it earder wie.
konklúzje
Ik leau dat de CASE-metoade ûntwikkelders en organisaasjes helpt te besprekken oer it opsetten en ferstjoeren fan automatisearre notifikaasjes. Ien ûntwikkelder kin begjinne mei it beoardieljen fan notifikaasjes mei de CASE-metoade, en dan sil de heule organisaasje gearwurkje mei oare programma's foar ûntwikkelders, behear en ynsidintbehear om notifikaasjes yn goede foarm te hâlden. Dit fereasket gjin spesjale ark of komplekse prosessen.
De heule sektor moat tinke oer de minsklike faktor wylst se yn plicht binne sûnder de top-notch klanttsjinst op te offerjen. Al dizze ark en praktiken kinne en moatte wurde ferbettere. Ik hoopje dat de CASE-metoade hjirmei sil helpe.
Genietsje fan ferbettere notifikaasjes!
Boarne: www.habr.com