Dziiiiin! Klokken er tre om morgenen, du har en fantastisk drøm, og plutselig kommer det en oppringning. Du er på vakt denne uken, og det har tydeligvis skjedd noe. Det automatiserte systemet ringer for å finne ut hva som er galt. Dette er et viktig aspekt ved å administrere moderne datasystemer, men la oss se på hvordan du kan gjøre varslinger bedre for folk.
Bli kjent med overvåkingsfilosofien, født over flere tiår av mine oppgaver i forskjellige overvåkingsteam. Hun var i stor grad påvirket av den virkelige bibelen fra Rob Evashchuk (My Notification Philosophy) inkludert i boken om , og bok av John Alspaugh (Merknader om oppsett av varsler).
, и – takk for hjelpen med å redigere innlegget.
Hva er CASE?
Jeg bestemte meg for å komme opp med en vakker forkortelse som eller . Jeg kaller det CASE-metoden. Han beskriver fire punkter man bør være oppmerksom på når man arbeider med automatisk overvåking:
- (kontekstbundet)
- (praktisk verdi)
- (vekt på symptomer)
- (karakter)
Hvis du bruker CASE, behandler du varsler med en sunn likegyldighet og vekker ikke folk om natten. Overvåking bør jevnlig vurderes for nytte og effektivitet. Når en person mottar varselet, vil de ha bedre mentale modeller og mer selvtillit.
For å gjøre det lettere å huske, se for deg at du trenger en CASE [det vil si en sak, en grunn - oversetterens notat] for å rettferdiggjøre hvert varsel. :solbriller:
Og hvorfor er alt dette?
. Av mange grunner. Og CASE vil ikke eliminere dem alle. Men med den vil du våkne om natten til bedre varsler. Denne metoden dekker ulike organisatoriske prosesser som også vil hjelpe i denne saken.
Det fine med RED- og USE-metodene er at vi med deres hjelp ikke bare vet hvordan vi skal jobbe, men også snakker samme språk med hverandre. Mitt håp er at CASE-metoden vil gjøre det lettere å diskutere varsler som beskytter systemene våre, men som holder kollegene våre opptatt.
Poenget er at du må skape en kultur i organisasjonen der varslinger behandles med en sunn likegyldighet. Varsler kan opprettes for et bestemt formål, men det er ikke et faktum at de ikke vil miste verdi senere. Hvorfor satte vi opp dette varselet? Hvor lenge siden har kriteriene blitt revidert? Med CASE kan disse spørsmålene besvares.
Context-Heavy - kontekstbinding
3 er ikke den beste tiden å lese meldinger som inneholder mange smarte ord. For å svare effektivt trenger du informasjon. Ideelt sett bør dette være informasjon om et spesifikt problem, som konteksten umiddelbart er klar for, og varslinger bør konfigureres slik at dette er mulig. Dette er "observasjon" og "orientering" fra . Det er ikke en skam å bruke tid på dette oppsettet, fordi det å stadig distrahere en person er enda dyrere. La oss respektere hverandre.
Problemer har mange kilder. Spesielt spøkelser.
Hvordan kan jeg hjelpe vakthavende? Det første vaktlederen ser er et varsel, så han bygger alle hypoteser på grunnlag av det. Så ser han på instruksjoner og dashboards, men er det alltid data på en spesifikk varsling, og ikke bare generell informasjon? Alspaugh råder «å tenke på hvordan du kan tolke eller svare på varselet» (lysbilde 29). En god varsling er fokusert på personen på vakt, ikke bare konfigurert av en terskel.
Så her er noen ideer om hvordan du kan forbedre varslingskonteksten:
- Vis brukeren noe nyttig og spesiallaget, og ikke bare vanlige instruksjoner eller et dashbord. Tidligere brukte gutta og jeg undersøkende dashboard konfigurert for spesifikke varsler. Dette vil hjelpe hvis problemet er kjent, men vil bare forvirre andre. Vi må finne en balanse her.
- Fortell oss om historien til varselet: er det nytt? Fungerer det ofte? Er det sesongbetont?
- Vis nylige endringer i systemtilstanden. Har noe endret seg i det siste? (For eksempel distribusjon eller aktivering/deaktivering av funksjonalitet.)
- Vis relasjonene og gi informasjon til den mentale modellen: systemavhengigheter skal være godt synlige, gjerne med indikasjon på funksjonalitet.
- Koble brukeren raskt til teamet: kan de se pågående hendelser eller kan de finne ut hvem andre i selskapet som har mottatt et varsel? Program aktivert?
Ideelt sett vil et hendelseshåndteringsprogram gi råd om hvordan man kan forbedre varslingskonteksten for hendelsesundersøkelser. Det er alltid noe å jobbe med!
Handlingsdyktig - praktisk verdi
Bør vakthavende gjøre noe som svar på varselet? Hvis du ikke trenger å gjøre noe eller det er uklart hva du skal gjøre, hvorfor vekket du ham? Du må unngå varsler som irriterer de på vakt og som ikke krever handling.
Hva burde jeg gjøre? Hva vil du?
Tidligere, da systemene var enkle og teamene var små, satte vi opp overvåking bare for å holde deg oppdatert. Varsling om at belastningen på haugen har økt vil gi oss kontekst dersom tjenesten i ettertid svikter. I stor skala vil slike varsler bare skape forvirring fordi systemene våre alltid opererer i en tilstand av forringelse av ulik alvorlighetsgrad. Dette fører raskt til og selvfølgelig tap av følsomhet. Derfor ignorerer eller filtrerer vakthavende slike varsler og svarer ikke alltid på dem etter behov. Ikke gå i denne fellen! Ikke sett opp alle varslene på rad og send dem på e-post til en gudsforlatt mappe.
Slik ser et varsel med praktisk verdi ut:
- Et varsel krever handling i stedet for bare å rapportere nyheter.
- Denne handlingen er vanskelig eller risikabel å automatisere. Hvis en handling kan automatiseres, så automatiser den, slutt å plage folk!
- Innkallingen inneholder hasteanbefalinger i skjemaet (SLA) eller (RTO). Vakthavende kan da aktivere organisasjonens hendelseshåndteringsprogram.
Jeg vil presisere: Jeg sier ikke at varsler kun skal komme for de viktigste SLOene (service-level goals) for API. SLO-overvåking er hele tiden fragmentert og delt og krever samme tilnærming til alle tjenester. Det er klart at du vil spore de viktigste SLOene for kundene som betaler deg. Men SLO-er for infrastruktur, for eksempel databaser, må også overvåkes. Snart må du forholde deg til interne kunder og støtte dem. Og så videre i det uendelige.
Symptombasert - vekt på symptomer
Enten du liker det eller ikke, jobber du i et distribuert system (Kavaj). Som et resultat bruker du forskjellige taktikker for å isolere tjenester og beskytte dem mot feil (Trainor et al.)3. Og selv om en forsinket søppelinnsamling eller en stoppet databasespørring indikerer problemer, er det ingen grunn til å haste med å fikse dem hvis brukerne ikke har problemer i nær fremtid.
Dette er viktige signaler og kan ha praktisk verdi, men hvis de ikke forstyrrer brukerne, så haster det ikke nok å distrahere ledsageren. Årsaksbaserte varsler er øyeblikksbilder av våre mentale modeller om en systemfeil. Det er bedre å spore viktige symptomer enn å prøve å liste opp alle mulige årsaker til en feil.
For å gjøre varsler meningsfulle, fokuser på , viktig for brukerne. Evashchuk kaller dette "overvåking for brukere." Husk at denne filosofien må brukes i hele organisasjonen. Hvis en tjeneste har akutte problemer et sted dypt inne i infrastrukturen, vil det rette teamet ta seg av dem. Å beskytte systemer mot slike feil er en helt egen sak (Trainer et al., avsnitt om strategier for å minimere kritiske avhengigheter).
Symptomene er ikke like varierende
Richard Cook minner oss om at komplekse systemer er fulle av feil, mangler og problemer. Å prøve å liste opp alle mulige årsaker er en sisyfisk oppgave. Du prøver å beskrive problemer, men de endrer seg hele tiden. Cindy Sridharan mener at "systemer ikke trenger å være i perfekt stand hvert sekund", og det er bedre å bruke en mer menneskelig tilnærming ( ("Overvåking av distribuerte systemer"), 7).
Unngå varsler etter en hendelse
Vanligvis er varsler om årsaker konfigurert for å rette opp hendelser. Og disse begrensede varslene om det som skjedde skaper en falsk følelse av sikkerhet, fordi systemet hver gang kommer opp med nye måter å bryte på.
Ikke la deg lure av saksmeldinger. Bedre tenke:
- Hvorfor la ikke det symptombaserte varselet merke til problemet?
- Vil det være nyttig å forbedre konteksten for brukeren?
- Hvordan kan overvåkingsverktøy forbedres for å stille en diagnose raskere, i stedet for å samle varsler om hva som skjedde?
Overvåkingsverktøy for diagnose vil bare hjelpe hvis du tenker på dem som en måte å gå fra symptom til løsning. Uten denne tilbakemeldingen vil du ganske enkelt bli bombardert med sene varsler og diagrammer om tidligere feil – og ikke et ord om fremtidige. Dette er en flott mulighet for en organisasjon til å gå fra forsvar til angrep. Og utviklere og produktledere vil ha de samme forventningene og klare målene. Saken - CASE (:wink:) - er klar for hver melding.
Årsaksbaserte varsler tåles med måte
Noen ganger gir systemet vårt lite valg når det gjelder årsaksbaserte varsler. Og noen ganger forstår de på vakt utmerket godt at et symptom definitivt vil føre til svikt, og derfor inneholder praktisk verdi. Kanskje du bare ikke er sikker på hva som skjer og setter opp varsler for å være på den sikre siden. Forhåpentligvis er denne handlingen midlertidig inntil vi kan endre systemet for å løse ytelsesproblemet.
Ha de andre komponentene i CASE i tankene når du håndterer disse situasjonene. Bare fordi det er midlertidig betyr ikke at du kan slutte å tenke med hodet.
Evaluert - evaluering
Eventuelle endringer i systemet (ny kode, ny infrastruktur, alt nytt) utvider spekteret av feil (Cook, 3). Fungerer dette varselet fortsatt som forventet? Klare og aktuelle mentale modeller av systemer og erfaring med å svare på noen støttevarsler - Dette er nøkkelfunksjonene . Systemfeil er i stadig utvikling, og vi må følge med.
Du må hele tiden evaluere kvaliteten på hver melding for å sikre at de fungerer som forventet. Kjære ledere! Det vil være mye lettere for teamene dine hvis du hjelper dem med å etablere denne prosessen! Her er noen vurderingsideer:
- bruk , eller andre varslingstestingsmetoder. Teamet kan gjøre det selv uten å måtte stole på et tungt hendelseshåndteringssystem!
- Innlemme samlingen av alle hendelsesrelaterte varsler i hendelseshåndteringsprogrammet. Merk nyttige, skadelige, upassende, uklare osv. Bruk dem som tilbakemelding.
- De riktige varslene utløses sjelden og testes nøye. Sørg for at alle lenker fungerer, peker til riktig kontekst osv.
- Hvis et varsel aldri utløses eller avfyres for ofte, er det noe galt med det. Fiks det eller fjern det. Pass deg for overdreven passivitet eller aktivitet!
- Angi varslingstidsstempler med utløpsdatoer. Hvis utløpsdatoen er utløpt, evaluer varselet ved å bruke CASE-metoden og oppdater tidsstemplet. Akkurat som mat, sjekk utløpsdatoen regelmessig.
- Forenkle prosessen med å forbedre varsler. Bruk overvåking som kode og lagre varsler i et Git-depot. Pull-forespørsler hjelper til med å engasjere teamet og gi deg en historie med tidligere varsler. Og du vil ikke lenger være redd for å endre varsler eller be om tillatelse fra de ansvarlige for dem.
- Sett opp tilbakemelding for varsler, selv om det er enkelt , slik at vaktledere merker varsler som ubrukelige eller påtrengende. Bygg inn en lenke eller handlingsfremmende oppfordring i selve varselet og gå gjennom tilbakemeldingen din regelmessig.
- Etabler en regel i teamet – la de på vakt jobbe for å forenkle plikten når det er lite arbeid. Måtte alt etter deg bli litt bedre enn det var før.
Konklusjon
Jeg tror CASE-metoden hjelper utviklere og organisasjoner med å diskutere oppsett og sending av automatiserte varsler. Én utvikler kan begynne å vurdere varslinger ved hjelp av CASE-metoden, og deretter vil hele organisasjonen gå sammen med andre utviklere, ledelse og hendelseshåndteringsprogrammer for å holde varslene i god form. Dette krever ingen spesielle verktøy eller komplekse prosesser.
Hele bransjen må tenke på den menneskelige faktoren mens de er på vakt uten å ofre førsteklasses kundeservice. Alle disse verktøyene og praksisene kan og bør forbedres. Jeg håper CASE-metoden vil hjelpe med dette.
Nyt forbedrede varsler!
Kilde: www.habr.com