Gjennomgangsprosessen etter hendelsen

7 minutter

En viktig del av en gjennomgang etter hendelsen er byggingen av en delt, nøyaktig kronologi som gjenspeiler den ikke-lineære karakteren til en hendelse.

Med ikke-lineær mener vi at hendelser nesten aldri bare "dette skjer, og så skjedde det, så la vi merke til, så gjorde vi noe, og så er vi ferdige." Folk kommer inn og ut, forskjellige personer legger merke til og prøver forskjellige ting; noe arbeid, noen gjør det ikke. Og hvis flere personer jobber samtidig, kan disse tingene skje samtidig, så det er litt mer komplisert.

Hvis du vil opprette en tidslinje som dette, selv en kompleks en, er det alltid et viktig første trinn: samle inn dataene.

Samle inn dataene

Før du kan foreta en gjennomgang etter hendelsen, må du først samle inn data. Spesifikt må du samle så mye av samtalen og konteksten (både teknisk og ikke-teknisk) rundt arrangementet som mulig, slik at du kan bruke all den viktige informasjonen som finnes i den. Samtalen mellom teammedlemmer som skjedde under strømbruddet eller hendelsen, vil være en av dine rikeste informasjonskilder.

Du bør også samle inn data fra overvåkingssystemet og andre steder personene som var involvert i hendelsen, trakk kontekst. Hvilken informasjon fikk de fra systemene dine da hendelsen foregikk?

Og til slutt, hvis mulig, vil det være nyttig for deg å få et bedre bilde av hva som endret seg før og under hendelsen, fordi endringer ofte er medvirkende faktorer når en hendelse inntreffer.

Vi kan se på denne prosessen som tre separate deler:

Samle samtalen: I andre moduler i dette læreprogrammet har vi nevnt at det er viktig å lage et bestemt sted der personer kan kommunisere under en hendelse. Under hendelsen deler ideelt sett folk hva som fungerte og hva som mislyktes, hva de nøler med å prøve, hva de har prøvd tidligere. Denne samtalen mellom personer mens de arbeider gjennom og løser problemet, er den beste kilden til læring.
Fastslå konteksten: Personene i en hendelse mottar signaler fra forskjellige steder. Et primært sted er overvåkingssystemet. Vi har diskutert viktigheten av å ha et solid overvåkingssystem i en tidligere modul i dette læreprogrammet. Ideelt sett bør vi kunne se på overvåkingssystemet for å bygge et øyeblikksbilde for tidsperioden rundt eller relatert til hendelsen.
Finn endringene: Du kan gjøre dette gjennom aktivitets- og overvåkingslogger.

Azure-verktøy for å hjelpe til med å samle inn dataene

Azure tilbyr en rekke verktøy som kan hjelpe med denne prosessen:

Azure DevOps for oppbevaring av metadata om hendelsen

I en tidligere modul i denne læringsveien diskuterte vi bruk av Azure Boards i Azure DevOps-suiten som ett sted for å samle all informasjon om en hendelse fra den første responsen. Det hjelper oss med spørsmål om når en hendelse først ble erklært, hvem som var på vakt, hvem som ble tildelt hendelsen, og så videre. Du kan også bruke Azure DevOps Wiki som en sentralisert måte å hente inn noen av opplysningene om både selve hendelsen og samtalen som fant sted under hendelsen.

Microsoft Graph API for å hente ut samtalen

Microsoft Graph API gir en programmatisk måte å hente samtalen som ble samlet inn i Teams-kanalen viet denne spesifikke hendelsen. Dataene som hentes inkluderer tidsstempler, forfatterskap, redigeringer, svar og noen systemmeldinger, som alle kan hjelpe med å konstruere en kronologi.

En enkel måte å komme i gang med Microsoft Graph API på, er å bruke Microsoft Graph Explorer. Microsoft Graph Explorer er en nettbasert API-nettleser som lar deg velge API-kall fra et Sample queries panel og prøve dem interaktivt.

Før du kjører spørringene, sørg for at brukeren eller appen du bruker har de nødvendige tillatelsene og samtykket for tilgangsmodusen du har valgt. I delegerte scenarier krever ChannelMessage.Read.Alldet å liste sammen team-bruk, Team.ReadBasic.Allliste kanal-bruk, Channel.ReadBasic.Allog lese kanalmeldinger . Hvis du senere automatiserer arbeidsflyten med kun app-tilgang, bruk GET /users/{id | user-principal-name}/joinedTeams i stedet for det delegerte aliaset /me/joinedTeams applikasjonstillatelsen Team.ReadBasic.All . For de kanalspesifikke lesetrinnene er ChannelSettings.Read.Group de minst privilegerte appen-only alternativene for å liste opp kanaler og ChannelMessage.Read.Group for å lese meldinger, begge med ressurs-spesifikt samtykke.

Vi går gjennom et sett med Microsoft Graph v1.0 "Microsoft Teams" API-kall for å hente samtalen. (Kanalmeldinger ble flyttet fra beta til v1.0 for flere år siden, så beta-endepunktene er ikke lenger nødvendige for dette scenariet.) Hvert steg på veien velger vi en forespørsel, kjører den, og velger deretter informasjonen fra svaret som hjelper oss med neste steg. Vi bruker deretter denne informasjonen til å konstruere neste forespørsel. For eksempel spør vi først i en liste med lag-IDer for å vise hvilke lag vi er en del av. Vi velger den vi trenger fra svaret, og setter inn denne ID-en i den neste nettadressen for spørringen for å få en liste over kanaler i dette teamet.

Her er våre ste, vist som Microsoft Graph v1.0-endepunkter:

GET /me/joinedTeams (for å finne team-ID-en til teamet vi bruker i et delegert scenario) eller GET /users/{id | user-principal-name}/joinedTeams (for å gjøre det samme i et app-only scenario).
GET /teams/{team-id}/channels (for å finne kanal-ID-en til kanalen vi brukte til den hendelsen).
GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (for å hente den trådede samtalen).
Følg @odata.nextLink etter replies@odata.nextLink behov, eller ring GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies for å bla gjennom større tråder.

Hvis du brukte en delt kanal, merk joinedTeams at API-et ikke returnerer vertsteamet for en delt kanal brukeren er direkte medlem av. Dette forbeholdet gjelder uansett om du kaller GET /me/joinedTeams eller GET /users/{id | user-principal-name}/joinedTeams. I så fall, start med kjente team- og kanalidentifikatorer, eller bruk de tilhørende team-API-ene for å finne vertsteamet.

I Graph Explorer kan du enten skrive inn disse URL-ene direkte eller velge tilsvarende oppføringer fra det innebygde panelet Sample queries under Microsoft Teams.

Hvis vi senere ønsket å konstruere et program for å utføre hver av disse trinnene (og faktisk gjør vi det), er det en kodesnutter alternativet i forespørselsvinduet som presenterer eksempelkode for denne spørringen på en rekke forskjellige programmeringsspråk.

Avhengig av hvordan teamet ditt bruker Teams, kan meldingshistorikken også inneholde systemmeldinger som forklarer når medlemmer ble lagt til eller fjernet. Men hvis du trenger en autoritativ revisjonsspor av kanalmedlemskap eller tilgangsendringer, kan du supplere disse dataene med Microsoft 365-revisjonslogger.

Dashbord og arbeidsbøker for kontekstvisning

Azure-dashbord og Azure Monitor-arbeidsbøker kan begge hjelpe med å rekonstruere konteksten operatørene så under en hendelse. Dashbord er nyttige for en rask oversikt over driften på tvers av Azure-tjenester. Arbeidsbøker passer vanligvis bedre for hendelsesanalyse fordi de støtter rikere spørringer, parametere, drilldowns og narrativ tekst sammen med diagrammer.

Hvis du allerede har et dashbord eller arbeidsbok som fanger opp de riktige signalene, sett tidsintervallet til perioden rundt hendelsen og bruk det til å rekonstruere hva folk så på det tidspunktet. Dette kan være spesielt nyttig når man skal korrelere måleparametere, logger og varsler på tvers av flere ressurser.

Delte dashbord er Azure-ressurser og kan fortsatt eksporteres som JSON fra portalen. Den eksport-/importstien er nyttig når du vil versjonere eller malatisere et dashbord. For de fleste etterforskningsscenarier etter hendelser er imidlertid arbeidsbøker det mer fleksible verktøyet fordi de lar deg kombinere visualiseringer, KQL-spørringer og forklarende tekst i ett enkelt artefakt.

Aktivitetslogger, ressurslogger og Log Analytics for endringsutforskning

Et Log Analytics-arbeidsområde kan ta inn data fra mange kilder, inkludert Azure Activity-logg, Azure-ressurslogger og tjenestespesifikke diagnostikk. Først, lag et nytt arbeidsområde for Log Analytics. Deretter, i Azure-portalen, åpne Monitor → Aktivitetslogg og velg Export Activity Loggs øverst i panelet. Dette åpner en diagnostisk innstilling som lar deg sende aktivitetsloggen for et Azure-abonnement til arbeidsområdet ditt.

På kort tid kan du bruke Kusto Query Language (KQL) for å hente detaljert informasjon om endringer som har skjedd i det abonnementet siden du koblet datakilden.

For eksempel viser følgende spørring informasjon om ressurser som er endret eller slettet. Vi kan sette tidsintervallet i Logs-opplevelsen for å fokusere mer presist på perioden like før hendelsen.

AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated desc

Denne spørringen er nyttig for endringer i management-plane, men husk hva den ikke viser. AzureActivity fanger kontrollplanoperasjoner som opprettelse, oppdatering, sletting og policy-handlinger. Den fanger ikke opp endringer på dataplan eller applikasjonsnivå inne i en tjeneste. For å undersøke disse, kombiner denne spørringen med Azure-ressurslogger, tjenestespesifikke revisjonslogger, distribusjonshistorikk og CI/CD- eller kildekontrollposter.

En rask merknad: når du eksporterer Azure-aktivitetsloggen, begynner informasjonen å flyte inn i Log Analytics-arbeidsområdet fra det tidspunktet og fremover. Du vil ikke kunne spørre i det arbeidsområdet retroaktivt etter hendelser som fant sted før du opprettet tilkoblingen.

Disse verktøyene skal kunne gi deg en god start på innsamling av informasjon som er nødvendig for at en kronologi skal kunne brukes i en gjennomgang etter hendelsen. Før du går rett inn i en gjennomgang etter hendelsen, vil vi gjerne advare deg om noen vanlige feller. Det er temaet for vår neste enhet.

Tilbakemeldinger

Var denne siden nyttig?

Gjennomgangsprosessen etter hendelsen

Kontroller kunnskapen din

Tilbakemeldinger