Granskningsprocessen efter incidenten
- 7 minuter
En viktig del av en granskning efter incident är byggandet av en delad, korrekt kronologi som återspeglar incidentens icke-linjära karaktär.
Med icke-linjär menar vi att incidenter nästan aldrig bara är "det här händer, och sedan hände det där, sedan märkte vi, sedan gjorde vi något, och sedan är vi klara." Människor kommer in och ut, olika människor märker och provar olika saker; vissa fungerar, andra inte. Och om flera personer arbetar samtidigt kan dessa saker hända samtidigt också, så det är lite mer komplicerat.
För att skapa en tidslinje som den här, även en komplex, finns det alltid ett viktigt första steg: samla in data.
Samla in data
Innan du kan utföra en granskning efter incident måste du först samla in data. Mer specifikt behöver du samla in så mycket av konversationen och kontexten (både tekniska och icke-tekniska) som omger händelsen så att du kan använda alla viktiga data i den. Konversationen mellan teammedlemmar som inträffade under avbrottet eller incidenten kommer att vara en av dina rikaste informationskällor.
Du bör också samla in data från ditt övervakningssystem och andra platser där de personer som var inblandade i incidenten drog kontext. Vilken information fick de från dina system när incidenten pågick?
Och slutligen, om möjligt, skulle det vara bra för dig att få en bättre bild av vad som ändrades precis före och under incidenten, eftersom ändringar ofta är bidragande faktorer när en incident inträffar.
Vi kan se den här processen som tre separata delar:
- Samla in konversationen: I andra moduler i den här utbildningsvägen har vi nämnt att det är viktigt att skapa en specifik plats där personer kan kommunicera under en incident. Under incidenten delar människor helst vad som fungerade och vad som misslyckades, vad de tvekar att prova, vad de har provat tidigare. Den här konversationen mellan människor när de arbetar igenom och löser problemet är din bästa utbildningskälla.
- Fastställa kontexten: Personerna i en incident tar emot signaler från olika platser. En primär plats är ditt övervakningssystem. Vi har diskuterat vikten av att ha ett stabilt övervakningssystem i en tidigare modul i den här utbildningsvägen. Helst bör vi kunna titta på övervakningssystemet för att skapa en punktvis ögonblicksbild för tidsperioden runt eller relaterad till incidenten.
- Hitta ändringarna: Du kan göra detta via aktivitets- och granskningsloggar.
Azure-verktyg som hjälper dig att samla in data
Azure erbjuder ett antal verktyg som kan hjälpa dig med den här processen:
Azure DevOps för att lagra metadata om incidenten
I en tidigare modul i den här utbildningsvägen diskuterade vi att använda Azure Boards i Azure DevOps-sviten som en plats för att samla in all information om en incident från det första svaret. Det hjälper oss med frågor om när en incident först deklarerades, vem som var jour, vem som tilldelades incidenten och så vidare och så vidare. Du kan också använda Azure DevOps Wiki som ett centraliserat sätt att hämta in information om både själva incidenten och konversationen som inträffade under incidenten.
Microsoft Graph API för att extrahera konversationen
Microsoft Graph API är ett programmatiskt sätt att hitta, exportera och ta in konversationen som samlades in i Teams-kanalen som ägnas åt den här specifika incidenten. De data som hämtas innehåller även metadata som är användbara när du skapar en kronologi, inklusive vem som anslöt till kanalen (och när) och tidsstämplar för enskilda delar av konversationen.
Ett enkelt sätt att komma igång med Microsoft Graph API är att använda Microsoft Graph Explorer. Microsoft Graph Explorer är en webbaserad API-webbläsare som gör att du kan välja API-anrop genom att välja förifyllda alternativ. Så här ser det ut:
Vi går igenom en uppsättning API-anrop för "Microsoft Teams" och "Microsoft Teams (beta)" för att hämta konversationen. Varje steg på vägen väljer vi en fråga, kör frågan och väljer sedan informationen från svaret som hjälper oss med nästa steg. Sedan använder vi den här informationen för att skapa nästa begäran. Till exempel börjar vi med att begära en lista över team-ID:n för att visa de team som vi är en del av. Vi väljer den vi behöver från svaret och infogar det här ID:t i nästa fråge-URL för att hämta en lista över kanaler i teamet.
Här är våra steg:
- HÄMTA "mina anslutna team" (för att hitta team-ID:t för det team vi använder).
- HÄMTA "kanaler för ett lag som jag är medlem i" (för att hitta kanal-ID:t för kanalen vi använde för incidenten).
- HÄMTA "meddelanden i en kanal" (för att hämta konversationen).
Om vi senare vill skapa ett program för att utföra vart och ett av dessa steg (och det gör vi) finns det ett kodfragment alternativ i begärandefönstret som visar exempelkod för den frågan på ett antal olika programmeringsspråk.
Riktade instrumentpaneler för kontextvisning
Med instrumentpaneler i Azure kan vi samla in information från Azure Monitor som är viktig för oss för driftsmedvetenhet tillsammans på en enda sida. Med användargränssnittet kan vi välja den tidsperiod som ska visas, så det är möjligt att "spola tillbaka tid" och visa instrumentpanelens information för den tidsperiod som är associerad med en incident om vi så väljer (förutsatt att informationen inte är för gammal för att inte längre behållas i Azure Monitor). Det här rekonstruerade användargränssnittet kan vara användbart när du försöker avgöra vad personerna i en incident såg under incidenten, men det kräver att personen som gör incidentgranskningen manuellt söker till rätt tidsperiod.
En funktion i instrumentpaneler i Azure som ofta förbises är deras möjlighet att dumpa en mall för alla instrumentpaneler som visas i en JSON-fil med hjälp av knappen Ladda ned (nedåtpil) och läsa in dem igen med knappen Ladda upp (uppil). Det innebär att vi antingen kan söka manuellt till rätt tidpunkt, ladda ned instrumentpanelen i det tillståndet och dela JSON-filen med andra, eller helt enkelt ladda ned den aktuella instrumentpanelen och ändra JSON enligt vår specifikation. Om du söker efter strängen "time" i en nedladdad JSON-instrumentpanelsfil visas ett avsnitt som ser ut så här:
"metadata": {
"model": {
"timeRange": {
"value": {
"relative": {
"duration": 24,
"timeUnit": 1
}
},
"type": "MsPortalFx.Composition.Configuration.ValueTypes.TimeRange"
},
"filterLocale": {
"value": "en-us"
},
"filters": {
"value": {
"MsPortalFx_TimeRange": {
"model": {
"format": "utc",
"granularity": "auto",
"relative": "24h"
},
"displayCache": {
"name": "UTC Time",
"value": "Past 24 hours"
},
Ändra det här avsnittet efter din specifikation och ladda om. Om du inte är bekant med det format som används kan du ändra instrumentpanelen manuellt, ladda ned den och se det format som krävs.
Granskningsloggar och logganalys för ändringsutforskning
En Log Analytics-arbetsyta kan ta in data från många källor, inklusive Azure-aktivitetsloggen. Skapa först en ny log analytics-arbetsyta. Gå sedan till funktionen Aktivitetslogg i portalen och välj Diagnostikinställningar. Detta ger möjlighet att skicka aktivitetsloggen för en Azure-prenumeration till din nya arbetsyta.
På kort tid kan du använda all kraft i KQL (Kusto Query Language) för att hämta detaljerad information om ändringar som har gjorts i prenumerationen sedan du anslöt datakällan.
Följande fråga visar till exempel information om resurser som har ändrats eller tagits bort. Vi kan ange tidsintervallet för frågan i frågeutforskaren för att mer exakt anpassa tiden strax före incidenten om vi vill.
AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatus, Caller
| order by TimeGenerated nulls first
En snabbkommentar: när du anger Azure-aktivitetsloggen som en datakälla börjar informationen flöda till Log Analytics-arbetsytan från den tidpunkten framåt. Du kommer inte att kunna fråga arbetsytan efter data retroaktivt för händelser som ägde rum innan du gjorde anslutningen.
De här verktygen bör kunna ge dig en bra start på insamlingen av information som krävs för att en kronologi ska kunna användas i en granskning efter incident. Innan du går in på en genomgång efter en incident, vill vi varna dig för några vanliga fallgropar. Det är ämnet för vår nästa lektion.