Sanering
Genom att dela upp livscykeln för incidenthantering i fem faser som du har sett i den här modulen kan du förstå processen, men faserna är inte alltid så distinkta som de visas i diagrammet. I synnerhet börjar linjen mellan svars- och reparationsfaserna ofta suddas ut. Detta gäller särskilt när åtgärder som är avsedda att minimera eller förbättra situationen har motsatt effekt. I det här fallet tenderar svar och reparation att överlappa eller gå fram och tillbaka mellan de två.
I den här lektionen får du lära dig mer om reparation och de steg som utgör den här fasen, samt några användbara tips och verktyg. En viktig sak att tänka på: du bör inte vidta de åtgärder som beskrivs här som en normativ checklista.
Om du verkligen redan har en checklista för reparation är det ofta en indikator på att det är dags att ta med automatisering i bilden. När du kan beskriva exakt vad som behöver göras och i vilken ordning du kan åtgärda ett problem är det den perfekta tiden att lära ut de här stegen till en dator så att systemet kan göra det åt dig.
Var du ska börja
Du har lärt dig hur viktigt det är att minska den tid det tar att svara på en incident. Nu ska vi titta på några saker som kan hjälpa till att påskynda processen med att åtgärda eller åtgärda problemet.
Olika teammedlemmar kan ha olika mentala modeller för hur saker fungerar och olika idéer om vad det första steget ska vara. Man kan först titta på loggarna, medan en annan kanske först kör frågor och tittar på måtten. Det finns ingen enda korrekt sökväg till framgång.
Det hjälper dock till att ge människor sammanhang och vägledning om vart de ska gå och vad de bör titta på.
Hur och till vem man ska eskalera
En viktig fråga att besvara när du formulerar din reparationsstartpunkt är: vem kan du ringa för att eskalera problemet när du fastnar? Du bör försöka avlasta mer av ansvaret för jour till teamet i allmänhet, inte bara drift- eller platstillförlitlighetsteknik. Det bör vara alla teammedlemmars ansvar att ha systemen igång för att uppfylla dina tillförlitlighetsmål.
Vilka resurser är användbara för de första som svarar?
Nästa övervägande är att fastställa de saker som de första svarande kan använda för att komma igång med processen. Detta kan omfatta relevanta mått, loggar, frågor och så vidare. Dessa bör anges i en Azure-arbetsbok/felsökningsguide om möjligt. Vi pratar om dem om bara ett ögonblick.
Det är också användbart att tillhandahålla enkla länkar till resurser (ofta i en felsökningsguide). Om ditt mål är att svara och åtgärda problemet så snabbt som möjligt, kommer det att påskynda processen att hjälpa människor att hitta svar på frågor utan att behöva söka efter rätt dokument eller URL.
Uppdatera intressenter
Du kan bli så fokuserad på att åtgärda problemet att du kanske glömmer att det finns många personer som inte är direkt inblandade i svaret på incidenten, men som vill och behöver veta vad som händer.
Det är viktigt att kommunicera med andra interna team och hålla dem underrättade om vad som händer när en incident inträffar. Om du inte ger dem konsekventa uppdateringar kommer de förmodligen att be om en statusuppdatering. De har all rätt till den här informationen, men du behöver ett bättre sätt att göra dem medvetna om problemet och vad som görs åt det.
Du måste vara tydlig med bekräftelsen till dina interna team. Var tydlig med att presentera vad du vet och vad som görs och ange förväntningar när det gäller när de kommer att höra tillbaka från dig.
Formeln för din kommunikation till intressenter är enkel:
- Det här är vad vi vet.
- Det här är vad vi gör.
- Vi återkommer till dig om X tid.
Detta hjälper till att förhindra att intressenter kommer till dig och avbryter dig när du är mitt uppe i att försöka åtgärda problemen.
Ett sätt att distribuera den här informationen är att använda en lätt redigerbar statuswebbsida som den vi nämnde i den senaste lektionen. I många fall kanske du vill ha en separat, mer detaljerad statussida för interna intressenter och en extern sida för dina kunder. Föregående formel fungerar för båda fallen.
Använda Azure Monitor-arbetsböcker och felsökningsguider
Azure har två nära relaterade funktioner som kan vara till stor hjälp för ett team i reparationsfasen: Felsökningsguider för Azure Monitor-arbetsböcker och Application Insights. I den här modulen är de utbytbara, inklusive att ha samma användargränssnitt. Du hittar Azure Monitor-arbetsböcker i Azure-portalen under Azure Monitor. Du hittar Felsökningsguider för Azure Insights i Azure-portalen när en Application Insight-instans har valts.
Du kan se arbetsböcker och felsökningsguider som "livedokument" som du kan skapa med hjälp av ett gränssnitt för sidskapande. När du skapar en ny kan du lägga till på sidan:
- Godtycklig text, till exempel en punktlista med objekt att göra eller annan användbar information för någon som konsulterar sidan
- Länkar till andra system, till exempel länkar till andra instrumentpaneler eller dokumentation
- KQL-frågor (Kusto Query Language)
Det är det sista objektet som gör dokumentet "live". I en tidigare modul i den här utbildningsvägen utforskade vi KQL-frågespråket inbyggt i Log Analytics och andra delar av Azure Monitor. Med det här språket kan vi skriva egna frågor för att returnera och visa diagnostikinformation från vår program- och Azure-infrastruktur. När en KQL-fråga infogas i en arbetsbok eller felsökningsguide visas de aktuella resultaten av frågan live för dokumentets läsare. Det innebär att felsökningsguiden inte bara kan säga "Se till att kontrollera felfrekvensen på webbservern" utan också kan visa ett aktuellt diagram för den felfrekvensen precis där bredvid instruktionerna. Den kan ha en länk som "här är dokumentationen om omstart av webbservern" som tar den första svararen direkt till den dokumentation de behöver.
Azure tillhandahåller även några befintliga mallar som hjälper dig att komma igång med att redigera dina egna dokument. Här är en skärmbild av några av de färdiga mallar som du kan erbjudas:
Det finns en avancerad redigerare funktion för arbetsböcker och felsökningsguider som gör att du kan komma åt och infoga antingen en JSON- eller en Azure Resource Manager-mallrepresentation av dokumentet. Det innebär att du kan spåra och distribuera dessa dokument med det källkontrollsystem du väljer. Du kan också automatisera etableringen av arbetsböcker eller felsökningsguider, vilket är användbart när du etablerar annan infrastruktur. Det blir enkelt att skapa en uppsättning anpassade felsökningsdokument som följer med en ny tjänst när tjänsten etableras genom att använda denna bästa praxis.
Andra användbara tips och verktyg
I den här modulen har du lärt dig om de olika verktyg och genvägar som du kan använda för att öka effektiviteten och minska din incidenthanteringstid. När vi avslutar den här sista lektionen gör vi en kort översikt över några verktyg och tekniker som är användbara för att diagnostisera problem i dina system.
- Du kan använda länken Programinstrumentpanel i Application Insights för att automatiskt generera en instrumentpanel som har de flesta viktiga objekt som du behöver som utgångspunkt. Observera att den inte innehåller Azure Service Health. Du bör fästa detta på instrumentpanelen så att du kan kontrollera om problemet är med dina system eller med själva molntjänsten.
- Du kan använda programkartan i Application Insights för att undersöka exakt vad som händer för att orsaka problemen. Du kan följa spåren för att hitta orsaken till felet (till exempel en felaktigt formaterad URL).
- Du kan använda Log Analytics för att fråga vilken del av systemet som helst.
Alla föregående verktyg är ovärderliga för att åtgärda problem.