Åtgärder
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 faserna för svarsåtgärder och reparation ofta suddas ut. Detta gäller särskilt om åtgärder som är avsedda att lösa eller förbättra situationen har motsatt verkan. I det här fallet överlappar svarsåtgärder och reparation eller växlar 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 faktiskt redan har en tillgänglig checklista för reparation så är det ofta en indikation på att det är dags att börja använda automatisering. 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.
Här börjar du
Du har lärt dig hur viktigt det är att snabbt hantera en incident. Nu ska vi titta på några saker som kan hjälpa dig att göra reparationsprocessen snabbare eller att lösa 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 inte en enda väg till bra resultat.
Det hjälper dock att ge personer sammanhang och vägledning för vart de ska gå och vad de ska titta på.
Hur och till vem som saker ska eskaleras
En viktig fråga att svara på när du utformar startpunkten för reparationer är – vem kan du ringa för att eskalera problemet när du kör fast? Du bör försöka lägga mer av jouransvaret på teamet i allmänhet, inte bara driftteamet eller webbplatsens tillförlitlighetsteam. 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 utryckningspersonalen?
Nästa övervägande är att fastställa vilka saker som utryckningspersonalen kan använda för att komma igång med processen. De kan omfatta relevanta mått, loggar, frågor och så vidare. De bör anges i en arbetsbok/felsökningsguide för Azure om det går. 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 målet är att hantera och åtgärda problemet så snabbt som möjligt så går processen snabbare om du hjälper användare hitta svar på frågor utan att behöva söka efter rätt dokument eller webbadress.
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 information 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 med intressenter är enkel:
- Det här är det 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 enkel redigerbar statuswebbsida som den vi nämnde i den senaste enheten. 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änd arbetsböcker och felsökningsguider för Azure Monitor
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 följande 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 våra egna frågor för att hämta 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 du i felsökningsguiden inte bara kan säga ”Se till att du kontrollerar felfrekvensen på webbservern”, utan även kan visa en aktuell graf för den felfrekvensen precis bredvid instruktionerna. Du kan använda en länk, t.ex. "här är webbserverns omstartsdokumentation" som dirigerar utryckningspersonalen till exakt den dokumentation som de behöver.
Azure innehåller också några befintliga mallar som hjälper dig komma igång med att skapa dina egna dokument. Här är en skärmbild av några av de fördefinierade mallar som du kan erbjudas:
Det finns en avancerad redigeringsfunktion 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 för att gå med en ny tjänst när tjänsten etableras.
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 den på din instrumentpanel så att du kan kontrollera om problemet beror på dina system eller på 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 felaktig webbadress).
- 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.