Utföra pågående justering för att minska meningslösa aviseringar

  • 6 minuter

I den här lektionen får du lära dig mer om processer som du kan implementera för att övervaka webbplatsens tillförlitlighet. Du lär dig också om pågående justering av dina aviseringar för att minska meningslösa aviseringar.

Övervakning och avisering

Övervakning och avisering gör det möjligt för ett system att berätta för personer när det är trasigt, eller kanske berätta för dem vad som är på väg att brytas. Om någon behöver undersöka problemet bör aviseringen ge relevant information så att personen vet var han eller hon ska börja.

När du granskar befintliga aviseringar eller skriver nya aviseringsregler bör du överväga dessa riktlinjer för att hålla dina aviseringar relevanta och din jourrotation lyckligare:

  • Aviseringar som utlöser en människas uppmärksamhet bör vara brådskande, viktiga, åtgärdsinriktade och verkliga.
  • Aviseringar bör representera antingen pågående eller överhängande problem med din tjänst.
  • Ta bort bullriga aviseringar. Överövervakning är ett svårare problem att lösa än underövervakning.
  • Klassificera problemet i någon av följande kategorier:
    • Tillgänglighet och grundläggande funktioner.
    • Latens.
    • Korrekthet.
    • Funktionsspecifika problem.
  • Symtom är ett bättre sätt att fånga problem omfattande och robust med mindre ansträngning.
  • Inkludera orsaksbaserad information på symptombaserade sidor eller på instrumentpaneler, men undvik att avisera direkt om orsaker.
  • Ju längre upp din serveringsstack du går, desto mer distinkta problem får du i en enda regel. Men gå inte så långt att du inte kan skilja tillräckligt från vad som händer.
  • Om du vill ha en tyst jourrotation kan du ha ett system för att hantera problem som behöver ett snabbt svar men som inte är omedelbart kritiska.

Övervaka för dina användare

Övervakning för dina användare kallas även symptombaserad övervakning. Detta står i kontrast till orsaksbaserad övervakning. Användarna bryr sig inte om data push-överföring misslyckas, de bryr sig om huruvida deras resultat är nya.

I allmänhet bryr sig användarna om:

  • Grundläggande tillgänglighet och korrekthet: Allt som bryter kärntjänsten på något sätt bör kategoriseras som otillgängligt.
  • Svarstid: Sidorna bör läsas in snabbt.
  • Fullständighet, färskhet och hållbarhet: Användarnas data bör vara säkra, bör komma tillbaka snabbt och sökindex bör vara uppdaterade.
  • Drifttid: Även om tjänsten är tillfälligt otillgänglig bör användarna ha fullständig tro på att tjänsten snart kommer att säkerhetskopieras.
  • Funktioner: Användarna bryr sig om att alla funktioner i tjänsten fungerar. Övervaka allt som är en viktig aspekt av din tjänst, även om det inte är kärnfunktioner.

Det finns en diskret men viktig skillnad mellan att databasservrar inte är tillgängliga och att användardata inte är tillgängliga. Den förstnämnda är en omedelbar orsak, den senare är ett symptom.

Orsaksbaserade aviseringar har sin plats

Ibland finns det inget symptom att avisera om, men du måste ändå få aviseringar om en situation. Ett exempel börjar få ont om minne. Du vill att regler ska meddela dig om problem som kan bli ett problem innan de orsakar ett symptom. I det här fallet kan du skriva en regel för att avisera om det här villkoret.

Skriv dock inte orsaksbaserade regler som utlöser anropsaviseringar för symtom som du kan fånga annars.

Biljetter, rapporter och e-post

Aviseringar som behöver uppmärksamhet snart, men inte direkt, är subkritiska aviseringar. Här följer några förslag på hur du loggar underkritiska aviseringar som ska följas upp senare:

  • Fel- eller biljettspårningssystem kan vara användbara för den här typen av avisering: En avisering kan öppna en bugg, så länge samma avisering placeras korrekt i en enda biljett eller bugg. Dessa buggar kan sedan gå igenom en sorteringsprocess som ska tilldelas någon att följa upp. Det är viktigt att den här typen av problem åtgärdas innan de blir kritiska. Ta hänsyn till hur mycket av dina teammedlemmars tid som kan ägnas åt att åtgärda buggar.
  • En daglig rapport (eller oftare) kan vara användbar: Skriva subkritiska aviseringar som är långlivade, till exempel databasen är över 90 % full, till en rapport som visar alla aktiva aviseringar. Tilldela någon att sortera den här rapporten dagligen.
  • Varje avisering bör spåras via ett arbetsflödessystem: Detta säkerställer att de visas och åtgärdas.

I allmänhet skapar du ett system som främjar ansvar för svarstider, men som inte har de höga kostnaderna för omedelbara mänskliga ingripanden.

Spelböcker

Spelböcker, som ibland kallas runbooks, är en viktig del av ett aviseringssystem. Ha en post i spelboken som förklarar vad du ska göra för varje avisering eller familj av aviseringar som får ett symptom.

Spårning och ansvarsskyldighet

Om någon får en avisering och fastställer att det inte är något fel är det ett tecken på att du måste ta bort regeln, degradera den eller samla in data på något annat sätt. Aviseringar som är mindre än 50 % korrekta anses vara brutna. Även de som utlöser falska positiva identifieringar 10 % av tiden förtjänar omvärdering.

En veckovis granskning av alla utlösta jouraviseringar och analys av kvartalsvis aviseringsstatistik kan hjälpa dig att se mönster som går förlorade när du fokuserar på enskilda aviseringar.

När ska du söka efter undantaget från regeln?

Här följer några orsaker till att du kan bryta mot riktlinjerna ovan:

  • Du har en känd orsak som faktiskt ligger under bruset i dina symtom: Om tjänsten till exempel har 99,99 % tillgänglighet, men du har en vanlig händelse som gör att 0,001 % av begäranden misslyckas, kan du inte avisera om det som ett symptom eftersom det är i bruset, men du kan fånga den kausativa händelsen.

  • Du kan inte övervaka vid startpunkten eftersom du förlorar datamatchning: Du tolererar till exempel att vissa slutpunkter är långsamma, till exempel validering av kreditkort. Vid dina lastbalanserare kan den här skillnaden gå förlorad. Du måste gå ner i stacken och aviseringen från den högsta platsen där du har skillnaden.

  • Symptomen visas inte förrän det är för sent: Till exempel har kvoten tagit slut. Du måste varna någon innan det är för sent, och ibland innebär det att hitta en orsak att avisera om. Din användning är till exempel större än 80 % och tar slut på mindre än fyra timmar med den senaste timmens ökningstakt.

    Men du bör också kunna hitta en liknande orsak som är mindre brådskande. Din kvot är till exempel större än 90 % och tar slut på mindre än fyra dagar med den senaste dagens tillväxttakt. Den uppsättningen omständigheter kommer att fånga de flesta fall. Du kan sedan hantera problemet som ett ärende eller en e-postavisering eller en daglig problemrapport i stället för den senaste eskalering som en avisering representerar.

  • Aviseringskonfigurationen är mer komplex än de problem som den försöker identifiera: Målet bör vara att gå mot enkla, robusta, självskyddande system.