Gennemgangsprocessen efter hændelsen

7 minutter

En vigtig del af en anmeldelse efter en hændelse er opførelsen af en delt, nøjagtig kronologi, der afspejler en hændelses ikke-lineære karakter.

Af nonlinear, mener vi, at hændelser er næsten aldrig bare "denne ting sker, og så skete det, så bemærkede vi, så gjorde vi noget, og så er vi færdige." Folk kommer ind og ud, forskellige mennesker lægger mærke til og prøver forskellige ting; noget arbejde, andre gør ikke. Og hvis flere personer arbejder på samme tid, kan disse ting også ske på samme tid, så det er lidt mere kompliceret.

Hvis du vil oprette en tidslinje som denne, selv en kompleks, er der altid et vigtigt første trin: Indsaml dataene.

Indsaml dataene

Før du kan foretage en gennemgang efter en hændelse, skal du først indsamle data. Specifikt skal du indsamle så meget af samtalen og konteksten (både teknisk og ikke-teknisk) som muligt omkring begivenheden, så du kan bruge alle de afgørende data, der findes i den. Samtalen mellem teammedlemmer, der fandt sted under afbrydelsen eller hændelsen, vil være en af dine rigeste kilder til oplysninger.

Du bør også indsamle data fra dit overvågningssystem og andre steder, hvor de personer, der er involveret i hændelsen, trak kontekst. Hvilke oplysninger fik de fra dine systemer, da hændelsen foregik?

Og endelig, hvis det er muligt, vil det være nyttigt for dig at få et bedre billede af, hvad der ændrede sig før og under hændelsen, fordi ændringer ofte er medvirkende faktorer, når en hændelse indtræffer.

Vi kan se på denne proces som tre separate dele:

Indsaml samtalen: I andre moduler i dette læringsforløb har vi nævnt, at det er vigtigt at oprette et bestemt sted, hvor personer kan kommunikere under en hændelse. Under hændelsen, ideelt set folk deler, hvad der fungerede, og hvad der mislykkedes, hvad de er tilbageholdende med at prøve, hvad de har prøvet i fortiden. Denne samtale mellem personer, mens de arbejder sig igennem og løser problemet, er din bedste læringskilde.
Fastlæg konteksten: Personerne i en hændelse modtager signaler fra forskellige steder. Et primært sted er dit overvågningssystem. Vi har diskuteret vigtigheden af at have et solidt overvågningssystem i et tidligere modul i dette læringsforløb. Ideelt set bør vi være i stand til at se på overvågningssystemet for at oprette et øjebliksbillede af tidsperioden omkring eller relateret til hændelsen.
Find ændringerne: Du kan gøre dette via aktivitets- og overvågningslogge.

Azure-værktøjer til at hjælpe med at indsamle data

Azure tilbyder en række værktøjer, der kan hjælpe med denne proces:

Azure DevOps til opbevaring af metadata om hændelsen

I et tidligere modul på denne læringsvej diskuterede vi brugen af Azure Boards i Azure DevOps-suiten som ét sted at indsamle al information om en hændelse fra den første respons. Det hjælper os med spørgsmål om, hvornår en hændelse først blev erklæret, hvem der var på opkald, hvem der blev tildelt til hændelsen osv. Du kan også bruge Azure DevOps Wiki som en centraliseret måde at hente nogle af oplysningerne om både selve hændelsen og samtalen, der fandt sted under hændelsen.

Microsoft Graph API til at udtrække samtalen

Microsoft Graph API giver en programmatisk måde at hente den samtale, der blev indsamlet i Teams-kanalen, der er dedikeret til denne specifikke hændelse. De hentede data inkluderer tidsstempler, forfatterskab, redigeringer, svar og nogle systemmeddelelser, som alle kan hjælpe med at konstruere en kronologi.

En nem måde at komme i gang med Microsoft Graph API på er at bruge Microsoft Graph Explorer. Microsoft Graph Explorer er en webbaseret API-browser, der lader dig vælge API-kald fra et Sample queries-panel og prøve dem interaktivt.

Før du kører forespørgslerne, skal du sikre dig, at brugeren eller appen, du bruger, har de nødvendige tilladelser og samtykke til den adgangstilstand, du har valgt. I delegerede scenarier kræver ChannelMessage.Read.Alldet at liste tilsluttede teams , Team.ReadBasic.Allliste kanalanvendelser Channel.ReadBasic.All, og læse kanalbeskeder . Hvis du senere automatiserer arbejdsgangen med kun app-adgang, så brug GET /users/{id | user-principal-name}/joinedTeams i stedet for det delegerede alias /me/joinedTeams applikationstilladelsen Team.ReadBasic.All . For de kanalspecifikke læsetrin er ChannelSettings.Read.Group de mindst privilegerede app-only muligheder til at liste kanaler og ChannelMessage.Read.Group til at læse beskeder, begge med ressource-specifik tilladelse.

Vi gennemgår et sæt Microsoft Graph v1.0 "Microsoft Teams" API-kald for at hente samtalen. (Kanalbeskeder flyttede fra beta til v1.0 for flere år siden, så beta-endpoints er ikke længere nødvendige i dette scenarie.) Hvert trin på vejen vælger vi en forespørgsel, kører forespørgslen og vælger derefter informationen fra svaret, der hjælper os med næste trin. Vi bruger derefter disse oplysninger til at oprette den næste anmodning. For eksempel spørger vi først ind i en liste over hold-ID'er for at vise, hvilke hold vi er en del af. Vi vælger det, vi skal bruge, fra svaret, og indsætter dette id i den næste URL-adresse til forespørgslen for at få vist en liste over kanaler i det pågældende team.

Her er vores trin, vist som Microsoft Graph v1.0 endpoints:

GET /me/joinedTeams (for at finde team-ID'et på det team, vi bruger i et delegeret scenarie) eller GET /users/{id | user-principal-name}/joinedTeams (for at gøre det samme i et app-only scenarie).
GET /teams/{team-id}/channels (for at finde kanal-ID'et på den kanal, vi brugte til den hændelse).
GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (for at hente den trådede samtale).
Følg @odata.nextLink efter replies@odata.nextLink behov, eller ring GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies for at bladre gennem større tråde.

Hvis du brugte en delt kanal, skal du bemærke, at API'en joinedTeams ikke returnerer værtsteamet for en delt kanal, som brugeren er direkte medlem af. Denne forbehold gælder, uanset om du kalder GET /me/joinedTeams eller GET /users/{id | user-principal-name}/joinedTeams. I så fald starter du med de kendte team- og kanalidentifikatorer eller bruger de tilknyttede team-API'er til at finde værtsteamet.

I Graph Explorer kan du enten indtaste disse URL'er direkte eller vælge de tilsvarende poster fra det indbyggede panel Eksempelforespørgsler under Microsoft Teams.

Hvis vi senere ønskede at konstruere et program til at udføre hvert af disse trin (og det gør vi faktisk), er der en kodestykker indstilling i anmodningsvinduet, der præsenterer eksempelkode for den pågældende forespørgsel på en række forskellige programmeringssprog.

Afhængigt af hvordan dit team bruger Teams, kan beskedhistorikken også indeholde systembeskeder, der hjælper med at forklare, hvornår medlemmer blev tilføjet eller fjernet. Hvis du derimod har brug for en autoritativ revisionsspor af kanalmedlemskab eller adgangsændringer, kan du supplere disse data med Microsoft 365 revisionslogs.

Dashboards og arbejdsbøger til kontekstvisning

Azure-dashboards og Azure Monitor-arbejdsbøger kan begge hjælpe med at rekonstruere den kontekst, som operatørerne så under en hændelse. Dashboards er nyttige til et hurtigt operationelt overblik på tværs af Azure-tjenester. Arbejdsbøger er som regel det bedre valg til hændelsesanalyse, fordi de understøtter rigere forespørgsler, parametre, drilldowns og narrativ tekst sammen med diagrammer.

Hvis du allerede har et dashboard eller en arbejdsbog, der fanger de rigtige signaler, så sæt tidsintervallet til perioden omkring hændelsen og brug det til at rekonstruere, hvad folk så på det tidspunkt. Dette kan især være nyttigt, når man korrelerer målinger, logfiler og advarsler på tværs af flere ressourcer.

Delte dashboards er Azure-ressourcer og kan stadig eksporteres som JSON fra portalen. Den eksport-/importsti er nyttig, når du vil version eller skabelonatisere et dashboard. Men for de fleste efter-hændelsesundersøgelser er arbejdsbøger det mere fleksible værktøj, fordi de lader dig kombinere visualiseringer, KQL-forespørgsler og forklarende tekst i et enkelt artefakt.

Aktivitetslogfiler, ressourcelogfiler og Log Analytics til ændringsudforskning

Et Log Analytics-arbejdsområde kan modtage data fra mange kilder, herunder Azure Activity-log, Azure-ressourcelogs og servicespecifikke diagnosticeringer. Først skal du oprette et nyt Log Analytics-arbejdsområde. Derefter åbner Monitor → Aktivitetslog i Azure-portalen og vælger Export Activity Logs øverst i panelet. Dette åbner en diagnostisk indstilling, der lader dig sende aktivitetsloggen for et Azure-abonnement til dit arbejdsområde.

På kort tid kan du bruge Kusto Query Language (KQL) til at hente detaljerede oplysninger om ændringer, der er sket i det abonnement, siden du tilsluttede datakilden.

For eksempel viser følgende forespørgsel information om ressourcer, der er ændret eller slettet. Vi kan indstille tidsintervallet i Logs-oplevelsen for mere præcist at fokusere på perioden kort før hændelsen.

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 forespørgsel er nyttig til ændringer i management-plane, men husk hvad den ikke viser. AzureActivity fanger kontrolplansoperationer såsom oprettelse, opdatering, slet og politikhandlinger. Den fanger ikke ændringer på dataplan eller applikationsniveau inden for en service. For at undersøge disse kan denne forespørgsel kombineres med Azure-ressourcelogs, servicespecifikke revisionslogs, implementeringshistorik og CI/CD- eller kildekontrolposter.

En hurtig bemærkning: når du eksporterer Azure-aktivitetsloggen, begynder informationen at flyde ind i Log Analytics-arbejdsområdet fra det tidspunkt og frem. Du kan ikke forespørge det workspace retroaktivt om begivenheder, der fandt sted før du lavede forbindelsen.

Disse værktøjer bør være i stand til at give dig en god start på indsamlingen af oplysninger, der er nødvendige for, at en kronologi kan bruges i en gennemgang efter en hændelse. Før du dykker lige ned i en anmeldelse efter en hændelse, vil vi gerne advare dig om nogle almindelige fælder. Det er emnet for vores næste enhed.

Feedback

Var denne side nyttig?

Gennemgangsprocessen efter hændelsen

Tjek din viden

Feedback