Dziiiiin! Klockan är 3 på morgonen, du har en underbar dröm, och plötsligt kommer ett samtal. Du är i tjänst den här veckan, och det har tydligen hänt något. Det automatiserade systemet ringer för att ta reda på vad som är fel. Detta är en viktig aspekt av att hantera moderna datorsystem, men låt oss titta på hur man gör aviseringar bättre för människor.
Bekanta dig med övervakningsfilosofin, född under flera decennier av mina arbetsuppgifter i olika övervakningsteam. Hon var till stor del influerad av den riktiga bibeln från Rob Evashchuk (My Notification Philosophy) ingår i boken om , och bok av John Alspaugh (Anmärkningar om att ställa in varningar).
, и – tack för hjälpen med att redigera inlägget.
Vad är CASE?
Jag bestämde mig för att komma på en vacker förkortning som eller . jag kallar det CASE-metod. Han beskriver fyra punkter att vara uppmärksam på när man arbetar med automatisk övervakning:
- (sammanhangsbunden)
- (praktiskt värde)
- (betoning på symtom)
- (kvalitet)
Om du använder CASE behandlar du aviseringar med en sund likgiltighet och väcker inte människor på natten. Övervakningen bör regelbundet utvärderas med avseende på användbarhet och effektivitet. När en person får beskedet kommer de att ha bättre mentala modeller och mer självförtroende.
För att göra det lättare att komma ihåg, föreställ dig att du behöver ett CASE [det vill säga ett fall, en anledning - översättarens anteckning] för att motivera varje varning. :solglasögon:
Och varför är allt detta?
. Av många anledningar. Och CASE kommer inte att eliminera dem alla. Men med det kommer du att vakna på natten till bättre aviseringar. Denna metod täcker olika organisatoriska processer som också kommer att hjälpa i denna fråga.
Det fina med RED- och USE-metoderna är att vi med deras hjälp inte bara vet hur man arbetar, utan också talar samma språk med varandra. Min förhoppning är att CASE-metoden ska göra det lättare att diskutera meddelanden som skyddar våra system men håller våra kollegor sysselsatta.
Poängen är att du behöver skapa en kultur i din organisation där aviseringar behandlas med en sund likgiltighet. Aviseringar kan skapas för ett specifikt syfte, men det är inte ett faktum att de inte kommer att tappa värde senare. Varför skapade vi det här meddelandet? Hur länge sedan har dess kriterier reviderats? Med CASE kan dessa frågor besvaras.
Context-Heavy - kontextbindning
3 är inte den bästa tiden att läsa meddelanden som innehåller många smarta ord. För att svara effektivt behöver du information. Helst bör detta vara information om en specifik fråga, för vilken sammanhanget är omedelbart klart, och aviseringar bör konfigureras så att detta är möjligt. Detta är "observation" och "orientering" från . Det är inte fy skam att lägga tid på den här installationen, för att ständigt distrahera en person är ännu dyrare. Låt oss respektera varandra.
Problem har många källor. Speciellt spöken.
Hur kan jag hjälpa vakthavaren? Det första som vakthavande befäl ser är en underrättelse, så han bygger alla hypoteser på den. Sedan tittar han på instruktioner och instrumentpaneler, men finns det alltid uppgifter om en specifik anmälan, och inte bara allmän information? Alspaugh råder att "tänka på hur du kan tolka eller svara på meddelandet" (bild 29). En bra avisering är fokuserad på personen i tjänst, inte bara konfigurerad av en tröskel.
Så här är några idéer om hur du kan förbättra meddelandekontexten:
- Visa användaren något användbart och speciellt skapat, och inte bara vanliga instruktioner eller en instrumentpanel. Tidigare använde killarna och jag undersökande instrumentpaneler konfigurerade för specifika meddelanden. Detta kommer att hjälpa om problemet är känt, men kommer bara att förvirra andra. Vi måste hitta en balans här.
- Berätta för oss om historiken för meddelandet: är det nytt? Fungerar det ofta? Är det säsongsbetonat?
- Visa de senaste ändringarna av systemtillståndet. Har något förändrats nyligen? (Till exempel distribution eller aktivera/inaktivera funktionalitet.)
- Visa sambanden och ge information till den mentala modellen: systemberoenden ska vara tydligt synliga, gärna med indikation på funktionalitet.
- Koppla snabbt ihop användaren med teamet: kan de se pågående incidenter eller kan de få reda på vem mer i företaget som har fått en avisering? Program aktiverad?
Helst ger ett incidenthanteringsprogram råd om hur man kan förbättra meddelandekontexten för incidentutredningar. Det finns alltid något att jobba på!
Handlingsbar - praktiskt värde
Ska vakthavande befäl göra något som svar på anmälan? Om du inte behöver göra något eller det är oklart vad du ska göra, varför väckte du honom? Du måste undvika meddelanden som irriterar de i tjänst och som inte kräver åtgärder.
Vad ska jag göra? Vad vill du?
Tidigare, när systemen var enkla och teamen var små, satte vi upp övervakning bara för att hålla koll på saker och ting. Meddelande om att belastningen på högen har ökat kommer att ge oss sammanhang om tjänsten efteråt inte fungerar. I stor skala kommer sådana meddelanden bara att skapa förvirring eftersom våra system alltid arbetar i ett tillstånd av försämring av varierande svårighetsgrad. Detta leder snabbt till och, naturligtvis, förlust av känslighet. Därför ignorerar eller till och med filtrerar vakthavaren sådana meddelanden och svarar inte alltid på dem vid behov. Gå inte i den här fällan! Ställ inte in alla aviseringar i rad och skicka dem sedan via e-post till någon gudsförgäten mapp.
Så här ser ett meddelande med praktiskt värde ut:
- Ett meddelande kräver åtgärd snarare än att bara rapportera nyheter.
- Denna åtgärd är svår eller riskabel att automatisera. Om en åtgärd kan automatiseras, automatisera den, sluta plåga människor!
- Kallelsen innehåller brådskande rekommendationer i formuläret (SLA) eller (RTO). Jourhavaren kan sedan aktivera organisationens incidenthanteringsprogram.
Jag vill förtydliga: Jag säger inte att meddelanden endast ska komma för de viktigaste SLO:erna (service-level goals) för API:et. SLO-övervakningen är ständigt fragmenterad och delad och kräver samma inställning till alla tjänster. Det är tydligt att du kommer att spåra de viktigaste SLO:erna för de kunder som betalar dig. Men SLO:er för infrastruktur, såsom databaser, måste också övervakas. Snart måste du ta itu med interna kunder och stötta dem. Och så vidare i det oändliga.
Symtombaserat - betoning på symtom
Oavsett om du gillar det eller inte, arbetar du i ett distribuerat system (Kavaj). Som ett resultat använder du olika taktiker för att isolera tjänster och skydda dem från misslyckanden (Trainor et al.)3. Och även om en försenad sophämtning eller en avstängd databasfråga indikerar problem, finns det ingen anledning att skynda sig att fixa dem om användarna inte har problem inom en snar framtid.
Det är viktiga signaler och kan ha praktiskt värde, men om de inte stör användarna är det inte tillräckligt brådskande att distrahera skötaren. Orsaksbaserade meddelanden är ögonblicksbilder av våra mentala modeller om ett systemfel. Det är bättre att spåra viktiga symtom än att försöka lista alla möjliga orsaker till ett misslyckande.
För att göra aviseringar meningsfulla, fokusera på , viktigt för användarna. Evashchuk kallar detta "övervakning för användare." Kom ihåg att denna filosofi måste tillämpas i hela organisationen. Om en tjänst har akuta problem någonstans djupt inne i infrastrukturen kommer lämpligt team att ta hand om dem. Att skydda system från sådana fel är en helt separat fråga (Trainer et al., avsnitt om strategier för att minimera kritiska beroenden).
Symtomen är inte lika varierande
Richard Cook påminner oss om att komplexa system är fulla av brister, brister och problem. Att försöka lista alla möjliga orsaker är en sisyfisk uppgift. Du försöker beskriva problem, men de förändras hela tiden. Cindy Sridharan anser att "system behöver inte vara i perfekt skick varje sekund" och det är bättre att använda ett mer mänskligt tillvägagångssätt ( ("Övervaka distribuerade system"), 7).
Undvik meddelanden efter en incident
Vanligtvis är meddelanden om orsaker konfigurerade för att korrigera incidenter. Och dessa begränsade meddelanden om det som hände skapar en falsk känsla av säkerhet, eftersom systemet varje gång kommer med nya sätt att bryta.
Låt dig inte luras av orsaksmeddelanden. Bättre tänka:
- Varför märkte inte det symptombaserade meddelandet problemet?
- Skulle det vara till hjälp att förbättra sammanhanget för användaren?
- Hur kan övervakningsverktygen förbättras för att göra en diagnos snabbare, snarare än att samla på sig meddelanden om vad som hände?
Övervakningsverktyg för diagnos hjälper bara om du tänker på dem som ett sätt att gå från symptom till lösning. Utan denna feedback kommer du helt enkelt att bombarderas med sena meddelanden och diagram om tidigare misslyckanden – och inte ett ord om framtida. Det här är en fantastisk möjlighet för en organisation att gå från försvar till anfall. Och utvecklare och produktchefer kommer att ha samma förväntningar och tydliga mål. Fallet - CASE (:wink:) - är tydligt för varje meddelande.
Anledningsbaserade meddelanden kan tolereras med måtta
Ibland lämnar vårt system oss lite val när det gäller orsaksbaserade meddelanden. Och ibland förstår de i tjänst mycket väl att ett symptom definitivt kommer att leda till ett misslyckande och därför innehåller praktiskt värde. Kanske är du helt enkelt inte säker på vad som händer och ställer in aviseringar för att vara på den säkra sidan. Förhoppningsvis är den här åtgärden tillfällig tills vi kan ändra systemet för att lösa prestandaproblemet.
Ha de andra komponenterna i CASE i åtanke när du hanterar dessa situationer. Bara för att det är tillfälligt betyder det inte att du kan sluta tänka med huvudet.
Utvärderad - utvärdering
Alla ändringar i systemet (ny kod, ny infrastruktur, allt nytt) utökar antalet fel (Cook, 3). Fungerar detta meddelande fortfarande som förväntat? Tydliga och aktuella mentala modeller av system och erfarenhet av att svara på vissa supportmeddelanden - det här är nyckelfunktionerna . Defekter i system utvecklas ständigt, och vi måste hänga med dem.
Du måste hela tiden utvärdera kvaliteten på varje meddelande för att säkerställa att de fungerar som förväntat. Kära ledare! Det blir mycket lättare för dina team om du hjälper dem att etablera denna process! Här är några bedömningsidéer:
- användning , eller andra testmetoder för anmälan. Teamet kan göra det själva utan att behöva förlita sig på ett tungt incidenthanteringssystem!
- Inkludera insamlingen av alla incidentrelaterade meddelanden i ditt incidenthanteringsprogram. Markera användbara, skadliga, olämpliga, otydliga etc. Använd dem som feedback.
- Rätt aviseringar triggas sällan och testas noggrant. Se till att alla länkar fungerar, pekar på rätt sammanhang osv.
- Om en avisering aldrig avfyras eller avfyras för ofta är det något fel med den. Fixa det eller ta bort det. Akta dig för överdriven passivitet eller aktivitet!
- Ställ in meddelandetidsstämplar med utgångsdatum. Om utgångsdatumet har gått ut, utvärdera meddelandet med CASE-metoden och uppdatera tidsstämpeln. Precis som mat, kontrollera utgångsdatumet regelbundet.
- Förenkla processen för att förbättra aviseringar. Använd övervakning som kod och lagra aviseringar i ett Git-förråd. Pull-förfrågningar hjälper till att engagera teamet och ge dig en historik över tidigare aviseringar. Och du kommer inte längre att vara rädd för att ändra aviseringar eller be om tillstånd från de ansvariga för dem.
- Ställ in feedback för aviseringar, även om det är enkelt , så att vakthavande befäl markerar anmälningar som värdelösa eller påträngande. Bädda in en länk eller en uppmaning i själva meddelandet och granska din feedback regelbundet.
- Upprätta en regel i teamet – låt de som har tjänstgöring arbeta för att förenkla tjänsten när det är lite jobb. Må allt efter dig bli lite bättre än det var innan.
Slutsats
Jag tror att CASE-metoden hjälper utvecklare och organisationer att diskutera hur man ställer in och skickar automatiska aviseringar. En utvecklare kan börja bedöma aviseringar med CASE-metoden, och sedan kommer hela organisationen att gå med i andra utvecklare, lednings- och incidenthanteringsprogram för att hålla aviseringarna i gott skick. Detta kräver inga speciella verktyg eller komplicerade processer.
Hela branschen måste tänka på den mänskliga faktorn när de är i tjänst utan att offra förstklassig kundservice. Alla dessa verktyg och metoder kan och bör förbättras. Jag hoppas att CASE-metoden hjälper till med detta.
Njut av förbättrade aviseringar!
Källa: will.com