Dziiiiin! Klokken er 3 om morgenen, du har en vidunderlig drøm, og pludselig er der et opkald. Du er på vagt i denne uge, og der er åbenbart sket noget. Det automatiserede system ringer for at finde ud af, hvad der er galt. Dette er et vigtigt aspekt af styring af moderne computersystemer, men lad os se på, hvordan man gør notifikationer bedre for folk.
Bliv bekendt med overvågningsfilosofien, født over flere årtier af mine opgaver i forskellige overvågningsteams. Hun var i høj grad påvirket af den rigtige bibel fra Rob Evashchuk (My Notification Philosophy) inkluderet i bogen vedr , og bog af John Alspaugh (Bemærkninger om opsætning af advarsler).
, и - tak for din hjælp til at redigere indlægget.
Hvad er CASE?
Jeg besluttede mig for at finde på en smuk forkortelse som eller . Jeg kalder det CASE metode. Han beskriver fire punkter, man skal være opmærksom på, når man arbejder med automatisk overvågning:
- (kontekstbundet)
- (praktisk værdi)
- (vægt på symptomer)
- (karakter)
Hvis du bruger CASE, behandler du notifikationer med en sund ligegyldighed og vækker ikke folk om natten. Overvågning bør regelmæssigt vurderes for nytte og effektivitet. Når en person modtager meddelelsen, vil de have bedre mentale modeller og mere selvtillid.
For at gøre det nemmere at huske, forestil dig, at du har brug for en CASE [det vil sige en sag, en grund - oversætterens notat] for at begrunde hver advarsel. :solbriller:
Og hvorfor er alt dette?
. Af mange grunde. Og CASE vil ikke eliminere dem alle. Men med det vil du vågne op om natten til bedre meddelelser. Denne metode dækker forskellige organisatoriske processer, som også vil hjælpe i denne sag.
Det smukke ved RED og USE metoderne er, at vi med deres hjælp ikke kun ved, hvordan vi skal arbejde, men også taler samme sprog med hinanden. Mit håb er, at CASE-metoden vil gøre det lettere at diskutere notifikationer, der beskytter vores systemer, men som holder vores kolleger beskæftiget.
Pointen er, at du skal skabe en kultur i din organisation, hvor notifikationer behandles med en sund ligegyldighed. Notifikationer kan oprettes til et bestemt formål, men det er ikke et faktum, at de ikke mister værdi senere. Hvorfor konfigurerede vi denne notifikation? Hvor lang tid siden er dens kriterier blevet revideret? Med CASE kan disse spørgsmål besvares.
Context-Heavy - kontekstbinding
3 er ikke det bedste tidspunkt at læse beskeder, der indeholder en masse smarte ord. For at reagere effektivt har du brug for information. Ideelt set bør dette være information om et specifikt problem, hvor konteksten umiddelbart er klar, og notifikationer bør konfigureres, så dette er muligt. Dette er "observation" og "orientering" fra . Det er ikke en skam at bruge tid på dette setup, for konstant at distrahere en person er endnu dyrere. Lad os respektere hinanden.
Problemer har mange kilder. Især spøgelser.
Hvordan kan jeg hjælpe vagthavende? Det første, vagtchefen ser, er en underretning, så han bygger alle hypoteser på dens grundlag. Så kigger han på instruktioner og dashboards, men er der altid data på en specifik notifikation, og ikke kun generel information? Alspaugh råder til "at tænke over, hvordan du kan fortolke eller reagere på underretningen" (slide 29). En god notifikation er fokuseret på den vagthavende, ikke kun konfigureret af en tærskel.
Så her er nogle ideer til, hvordan man kan forbedre underretningskonteksten:
- Vis brugeren noget nyttigt og specielt skabt, og ikke bare almindelige instruktioner eller et dashboard. Tidligere brugte fyrene og jeg efterforsknings-dashboards, der var konfigureret til specifikke meddelelser. Dette vil hjælpe, hvis problemet er kendt, men vil kun forvirre andre. Vi skal finde en balance her.
- Fortæl os om historien om underretningen: er den ny? Virker det ofte? Er det sæsonbestemt?
- Vis seneste ændringer af systemtilstanden. Har noget ændret sig for nylig? (F.eks. implementering eller aktivering/deaktivering af funktionalitet.)
- Vis sammenhængene og giv information til den mentale model: Systemafhængigheder skal være tydeligt synlige, gerne med angivelse af funktionalitet.
- Forbind hurtigt brugeren med teamet: kan de se igangværende hændelser, eller kan de finde ud af, hvem der ellers i virksomheden har modtaget en notifikation? Program aktiveret?
Ideelt set vil et hændelsesstyringsprogram give råd om, hvordan man kan forbedre underretningskonteksten for hændelsesundersøgelser. Der er altid noget at arbejde på!
Handledygtig - praktisk værdi
Skal vagtchefen gøre noget som følge af underretningen? Hvis du ikke behøver at gøre noget, eller det er uklart, hvad du skal gøre, hvorfor vækkede du ham så? Du skal undgå meddelelser, der irriterer dem på vagt og ikke kræver handling.
Hvad skal jeg gøre? Hvad vil du have?
Tidligere, hvor systemerne var enkle og teams var små, satte vi overvågning op for at holde styr på tingene. Meddelelse om, at belastningen på heapen er steget, vil give os kontekst, hvis tjenesten efterfølgende fejler. I stor skala vil sådanne meddelelser kun skabe forvirring, fordi vores systemer altid fungerer i en tilstand af forringelse af varierende sværhedsgrad. Dette fører hurtigt til og selvfølgelig tab af følsomhed. Derfor ignorerer eller filtrerer vagtchefen sådanne meddelelser og reagerer ikke altid på dem efter behov. Gå ikke i denne fælde! Lad være med at opsætte alle notifikationerne i en række og derefter sende dem via e-mail til en gudsforladt mappe.
Sådan ser en meddelelse med praktisk værdi ud:
- En notifikation kræver handling i stedet for blot at rapportere nyheder.
- Denne handling er svær eller risikabel at automatisere. Hvis en handling kan automatiseres, så automatiser den, stop med at plage folk!
- Meddelelsen indeholder presserende anbefalinger i skemaet (SLA) eller (RTO). Vagtchefen kan derefter aktivere organisationens hændelsesstyringsprogram.
Jeg vil gerne præcisere: Jeg siger ikke, at notifikationer kun skal komme for de vigtigste SLO'er (service-level goals) for API'en. SLO-overvågning er konstant fragmenteret og opdelt og kræver samme tilgang til alle services. Det er klart, at du vil spore de vigtigste SLO'er for de kunder, der betaler dig. Men infrastruktur SLO'er, såsom databaser, skal også overvåges. Snart skal du håndtere interne kunder og støtte dem. Og så videre i det uendelige.
Symptombaseret - vægt på symptomer
Uanset om du kan lide det eller ej, arbejder du i et distribueret system (Kavaj). Som et resultat bruger du forskellige taktikker til at isolere tjenester og beskytte dem mod fejl (Trainor et al.)3. Og selvom en forsinket affaldsindsamling eller en stoppet databaseforespørgsel indikerer problemer, er der ingen grund til at skynde sig at rette dem, hvis brugerne ikke har problemer i den nærmeste fremtid.
Det er vigtige signaler og kan have praktisk værdi, men hvis de ikke forstyrrer brugerne, så haster det ikke nok at distrahere ledsageren. Årsagsbaserede meddelelser er øjebliksbilleder af vores mentale modeller om en systemfejl. Det er bedre at spore vigtige symptomer end at prøve at liste alle mulige årsager til en fejl.
For at gøre notifikationer meningsfulde skal du fokusere på , vigtigt for brugerne. Evashchuk kalder dette "overvågning for brugere." Husk, at denne filosofi skal anvendes i hele organisationen. Hvis en tjeneste har akutte problemer et sted dybt i infrastrukturen, vil det rette team tage sig af dem. Beskyttelse af systemer mod sådanne fejl er en helt separat sag (Trainer et al., afsnit om strategier til at minimere kritiske afhængigheder).
Symptomerne er ikke så variable
Richard Cook minder os om, at komplekse systemer er fulde af fejl, mangler og problemer. At prøve at liste alle mulige årsager er en sisyfisk opgave. Du forsøger at beskrive problemer, men de ændrer sig hele tiden. Cindy Sridharan mener, at "systemer ikke behøver at være i perfekt stand hvert sekund", og det er bedre at bruge en mere menneskelig tilgang ( ("Overvågning af distribuerede systemer"), 7).
Undgå meddelelser efter en hændelse
Typisk er meddelelser om årsager konfigureret til at rette hændelser. Og disse begrænsede meddelelser om, hvad der skete, skaber en falsk følelse af sikkerhed, fordi systemet hver gang kommer med nye måder at bryde på.
Lad dig ikke narre af årsagsmeddelelser. Tænk hellere:
- Hvorfor bemærkede den symptombaserede meddelelse ikke problemet?
- Ville det være nyttigt at forbedre konteksten for brugeren?
- Hvordan kan overvågningsværktøjer forbedres for at stille en diagnose hurtigere i stedet for at akkumulere meddelelser om, hvad der skete?
Overvågningsværktøjer til diagnose vil kun hjælpe, hvis du tænker på dem som en måde at gå fra symptom til løsning på. Uden denne feedback vil du simpelthen blive bombarderet med sene meddelelser og diagrammer om tidligere fejl – og ikke et ord om fremtidige. Dette er en fantastisk mulighed for en organisation til at bevæge sig fra forsvar til angreb. Og udviklere og produktchefer vil have de samme forventninger og klare mål. Sagen - CASE (:wink:) - er klar for hver underretning.
Årsagsbaserede meddelelser kan tolereres med moderation
Nogle gange efterlader vores system os kun få valgmuligheder med hensyn til årsagsbaserede meddelelser. Og nogle gange forstår de på vagt udmærket, at et symptom helt sikkert vil føre til en fiasko, og derfor indeholder praktisk værdi. Måske er du bare ikke sikker på, hvad der foregår, og sætter meddelelser op for at være på den sikre side. Forhåbentlig er denne handling midlertidig, indtil vi kan ændre systemet for at løse ydeevneproblemet.
Hold de andre komponenter i CASE i tankerne, når du håndterer disse situationer. Bare fordi det er midlertidigt, betyder det ikke, at du kan stoppe med at tænke med hovedet.
Evalueret - evaluering
Enhver ændring af systemet (ny kode, ny infrastruktur, alt nyt) udvider rækken af fejl (Cook, 3). Fungerer denne notifikation stadig som forventet? Klare og aktuelle mentale modeller af systemer og erfaring med at reagere på nogle supportmeddelelser - disse er nøglefunktionerne . Fejl i systemer er i konstant udvikling, og dem skal vi følge med.
Du skal konstant evaluere kvaliteten af hver enkelt meddelelse for at sikre, at de fungerer som forventet. Kære ledere! Det vil være meget nemmere for dine teams, hvis du hjælper dem med at etablere denne proces! Her er nogle vurderingsideer:
- brug , eller andre meddelelsestestmetoder. Teamet kan gøre det selv uden at skulle stole på et tungt hændelsesstyringssystem!
- Inkorporer samlingen af alle hændelsesrelaterede meddelelser i dit hændelsesstyringsprogram. Markér nyttige, skadelige, upassende, uklare osv. Brug dem som feedback.
- De rigtige notifikationer udløses sjældent og testes nøje. Sørg for, at alle links virker, peger på den rigtige kontekst osv.
- Hvis en notifikation aldrig udløses eller udløses for ofte, er der noget galt med den. Reparer det eller fjern det. Pas på overdreven passivitet eller aktivitet!
- Indstil notifikationstidsstempler med udløbsdatoer. Hvis udløbsdatoen er udløbet, skal du evaluere meddelelsen ved hjælp af CASE-metoden og opdatere tidsstemplet. Ligesom mad skal du tjekke udløbsdatoen regelmæssigt.
- Forenkle processen med at forbedre notifikationer. Brug overvågning som kode og gem meddelelser i et Git-lager. Pull-anmodninger hjælper med at engagere teamet og give dig en historie med tidligere notifikationer. Og du vil ikke længere være bange for at ændre notifikationer eller bede om tilladelse fra de ansvarlige for dem.
- Konfigurer feedback til notifikationer, selvom det er enkelt , så vagtcheferne markerer underretninger som ubrugelige eller påtrængende. Integrer et link eller en opfordring til handling i selve meddelelsen, og gennemgå din feedback regelmæssigt.
- Etabler en regel i teamet – lad dem på vagt arbejde for at forenkle pligten, når der er lidt arbejde. Må alt efter dig blive lidt bedre, end det var før.
Konklusion
Jeg tror på, at CASE-metoden hjælper udviklere og organisationer med at diskutere opsætning og afsendelse af automatiserede meddelelser. Én udvikler kan begynde at vurdere notifikationer ved hjælp af CASE-metoden, og så vil hele organisationen slutte sig til andre udviklere, ledelse og hændelsesstyringsprogrammer for at holde notifikationer i god form. Dette kræver ingen specielle værktøjer eller komplekse processer.
Hele industrien er nødt til at tænke på den menneskelige faktor, mens de er på vagt uden at ofre førsteklasses kundeservice. Alle disse værktøjer og praksis kan og bør forbedres. Jeg håber, at CASE-metoden vil hjælpe med dette.
Nyd forbedrede notifikationer!
Kilde: www.habr.com