Processen för granskning efter incident
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, sedan märkte vi, sedan gjorde vi något, och sedan är vi klara." Personer komma in och ut, märker olika människor 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.
När vi skapar en tidslinje, inklusive om den är komplex, finns det alltid ett viktigt första steg: samla in data.
Samla in data
Innan du kan genomföra en granskning efter incident behöver du först samla in data. Närmare bestämt behöver du samla in så mycket av konversationen och kontexten (både teknisk och icke-teknisk) runt händelsen som möjligt så att du kan använda alla viktiga data som finns däri. Den konversation med teamets medlemmar som hölls under avbrottet eller incidenten är en av de största informationskällorna.
Du bör även samla data från ditt övervakningssystem och andra ställen som de personer som var inblandade i incidenten fick kontext från. Vilken information fick de från dina system när incidenten skedde?
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 betrakta 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äll kontexten: Personerna i en incident tar emot signaler från olika platser. Ett viktigt sådant ställe är övervakningssystemet. Vi har diskuterat vikten av att ha ett robust övervakningssystem i en tidigare modul i den här utbildningsvägen. Helst bör vi kunna titta på övervakningssystemet för att skapa en ögonblicksbild vid tidpunkt för tidsperioden runt eller som är relaterad till incidenten.
- Hitta ändringarna: Du kan göra detta via aktivitets- och granskningsloggar.
Azure-verktyg som hjälper till med datainsamling
Azure erbjuder flera verktyg som kan underlätta den här processen:
Azure DevOps lagrar 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 incidenten först anmäldes, vem som var på plats, vem som var tilldelad till incidenten och så vidare. Du kan även använda Azure DevOps Wiki som ett centraliserat sätt att hämta in viss information om både själva incidenten och om den konversation som ägde rum under incidenten.
Microsoft Graph API extraherar konversationen
Microsoft Graph API tillhandahåller ett programmatiskt sätt att hitta, exportera och hämta den konversation som samlades in i den Teams-kanal som handlade om denna specifika incident. 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 informationen för att skapa nästa begäran. Exempelvis kör vi frågor mot en lista över team-ID:n för att visa de team som vi ingår i. Vi väljer det vi behöver från svaret och infogar detta ID i nästa fråge-URL för att få en lista över kanaler i det teamet.
Här är stegen:
- 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 team som jag är medlem i" (för att hitta kanal-ID:t för den kanal som vi använde för den 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 faktiskt) finns det ett kodfragmentalternativ i begärandefönstret som visar exempelkod för den frågan i 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 till hjälp när vi försöker fastställa vad personer i en incident såg under incidenten, men det kräver att den person som genomfö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 (uppåtpil). 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 enligt din specifikation och ladda upp igen. 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.
Spårningsloggar och Log Analytics 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 Kusto-frågespråk (KQL) för att hämta detaljerad information om ändringar som har gjorts i den 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 frågans tidsintervall i frågeutforskaren för att precisera tiden kort före incidenten om så önskas.
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.
Dessa verktyg bör kunna ge dig en bra start med att samla in nödvändig information för en kronologi som ska användas i en granskning efter incident. Innan du kör igång med en granskning efter incident vill vi varna om några vanliga fallgropar. Det är ämnet i nästa lektion.