Åtgärdsinriktade aviseringar
I den här modulen hittills har vi utforskat olika sätt att tänka på, mäta och interagera med våra systems tillförlitlighet. Men det finns också ett sätt som tillförlitlighet interagerar med oss: aviseringar. Det är enkelt att konfigurera Azure Monitor och andra verktyg för att skicka aviseringar baserat på olika mått och signaler, inklusive de SLO:er och SLO:er som vi har sett tidigare. Azure kan också skicka aviseringar baserat på tjänstproblem via Azure Service Health-funktionen .
Med kraften att enkelt skicka ut aviseringar kommer en potentiell risk. Det är här ordet hållbar kommer in i bilden från SRE-definitionen som vi har sett tidigare:
Site Reliability Engineering är ett teknikområde som ägnar sig åt att hjälpa organisationer att uppnå lämplig tillförlitlighetsnivå i sina system, tjänster och produkter.
Aviseringar är utformade för att meddela dig när det är problem med dina system. Men när aviseringar är felaktigt konfigurerade kan det undergräva ditt mål att skapa en hållbar driftspraxis. Det är möjligt att spåra ur allt arbete du har lagt på att föra in SLO:er och SLO:er i din organisation om det leder till en hagelstorm av aviseringar för din personal. Varningströtthet är en välkänd sjukdom i driftcommunityn. Målet med den här enheten är att hjälpa dig att förhindra att det inträffar i din organisation.
En viktig deltagare för aviseringströtthet är aviseringar som inte kan åtgärdas. Nu ska vi lära oss hur du undviker att skapa dem.
Vilka aviseringar är (och är inte)
För att förstå varför dåliga aviseringar kan skapa problem måste du tänka på syftet med aviseringar och hur de skiljer sig från andra driftsignaler.
Åtgärdsinriktade aviseringar är inte:
Loggar: Aviseringar är inte poster för händelser, det är ett jobb för loggar. Om du bara försöker registrera att en händelse har inträffat skriver du den till en loggfil, inte en sidsökare.
Meddelanden: Aviseringar är inte avsedda att meddela icke-kritiska förekomster, till exempel slutförandet av en programvaruversion. Du ska inte behöva avbryta någon, och förstöra personens koncentration och fokus, bara för att leverera en nyhet.
Pulsslag: Aviseringar ska inte användas som en påminnelse om att systemet fortfarande körs. Vi har sett situationer där folk säger "Åh, om jag inte får minst en sida från det systemet varje timme, vet jag att något är fel och jag måste ta itu med det." Det här är en hemsk idé.
Åtgärdsinriktade aviseringar används i situationer där du behöver en människa som undersöker och ingriper för att åtgärda problemet. Aviseringar bör vara kommunikation om att något ovanligt eller oväntat har hänt som kräver någons uppmärksamhet.
Om händelsen är något som systemet kan hantera via automatiserade processer, till exempel skalning av resurser inom en förinställd gräns, behövs ingen avisering. Systemet ska helt enkelt hantera det och skriva en rad i en logg. Det bör inte se dig klockan 02.00 för att berätta att det fanns en situation som den hanterade.
Skapa åtgärdsinriktade aviseringar
För att en avisering ska vara åtgärdsbar måste den ha:
Enkelhet: Du vill inte göra en avisering som kräver att mottagaren måste förbryllas över den innan de vet vad de ska göra. Om varningen är för komplex kommer den stackars person som just har vaknat mitt i natten att förlora värdefull tid bara för att försöka ta reda på vad det betyder.
Omfattning: En av de första saker som en person som tar emot meddelandet måste göra för att kunna sortera det effektivt är att fastställa problemets omfattning. Är problemet med en enskild server? En tjänst? En hel region? Över hela världen? Om du vill göra det enklare för mottagaren lägger du den här informationen i aviseringen.
Kontext: Vad behöver den person som ska ta emot aviseringen veta för att komma igång med att hantera den? Vi ska gå in närmare på den här delen.
Ange kontext i aviseringen
Nu ska vi titta på några element som en åtgärdsinriktad avisering alltid ska innehålla så att mottagarna har den kontext de behöver:
Var kommer aviseringen ifrån? Många organisationer har flera övervakningssystem som används vid ett och samma tillfälle och ett stort antal sammankopplade system. Det kan spara mycket tid om aviseringen säger "Den här aviseringen för lönesystemet THX-1138 kommer från "prod" Azure Monitor-prenumerationen."
Vilken förväntning bröts? En avisering som bara beskriver det aktuella tillståndet är inte alls så bra som den kunde vara. Jämför "databasservern körs vid 80 % belastning" med "databasservern har körts med 80 % belastning under de senaste två timmarna när den ska köras med 60 % belastning eller lägre."
Varför är det här ett problem (för kunden)? Information om den effekt eller inverkan som situationen har haft eller potentiellt kommer att ha på kunden ger oss ett sätt att fastställa betydelse och på lämpligt sätt mäta vår reaktion.
Vilka är nästa steg att vidta? Om möjligt bör aviseringen inkludera vad personen som svarar ska göra härnäst, även om det är en pekare till en felsökningsguide eller någon annan dokumentation för att hitta hjälp med att diagnostisera och åtgärda det här problemet.
Om du tar med den här användbara kontexten och arbetar på att göra aviseringar som kan åtgärdas kan du göra driftsmetoder mer hållbara och göra det enklare att reagera på aviseringarna.