Processo di revisione post-evento imprevisto

7 minuti

Una parte fondamentale di una revisione post-evento imprevisto è la costruzione di una cronologia condivisa e accurata che riflette la natura non lineare di un evento imprevisto.

Per non lineare intendiamo che gli incidenti non sono quasi mai solo "questa cosa succede, e poi quello è successo, poi abbiamo notato, poi abbiamo fatto qualcosa, e poi abbiamo finito." Le persone entrano ed escono, persone diverse notano e provano cose diverse; alcuni funzionano, altri no. E se più persone lavorano contemporaneamente, queste cose possono accadere contemporaneamente, quindi è un po' più complicato.

Per creare una sequenza temporale come questa, anche una complessa, è sempre necessario un primo passaggio importante: raccogliere i dati.

Raccogliere i dati

Prima di poter eseguire una revisione post-evento imprevisto, è prima necessario raccogliere i dati. In particolare, è necessario raccogliere tutta la conversazione e il contesto (sia tecnici che non tecnici) che circondano l'evento, in modo da poter usare tutti i dati cruciali contenuti in esso. La conversazione tra i membri del team che si è verificata durante l'interruzione o l'incidente sarà una delle fonti di informazioni più ricche.

È anche necessario raccogliere dati dal sistema di monitoraggio e da altri luoghi da cui le persone coinvolte nell'incidente hanno ottenuto il contesto. Quali informazioni venivano ottenute dai sistemi quando l'incidente stava succedendo?

Infine, se possibile, sarebbe utile ottenere una migliore immagine di ciò che è cambiato prima e durante l'evento imprevisto, perché le modifiche sono spesso fattori che contribuiscono quando si verifica un evento imprevisto.

È possibile esaminare questo processo come tre parti separate:

Raccogliere la conversazione: in altri moduli di questo percorso di apprendimento è stato accennato che è importante ritagliare un luogo specifico in cui le persone comunichino durante un evento imprevisto. Durante l'incidente, idealmente le persone condividono ciò che ha funzionato e ciò che non è riuscito, quello che sono esitanti da provare, quello che hanno provato in passato. Questa conversazione tra le persone mentre lavorano e risolvono il problema è la migliore fonte di apprendimento.
Determinare il contesto: le persone in un evento imprevisto ricevono segnali da diverse posizioni. Quella più importante è il sistema di monitoraggio. In questo percorso di apprendimento è stata illustrata l'importanza di avere un solido sistema di monitoraggio in un modulo precedente. Idealmente, dovremmo essere in grado di esaminare il sistema di monitoraggio per creare uno snapshot temporizzato per il periodo di tempo intorno o correlato all'evento imprevisto.
Trovare le modifiche: è possibile eseguire questa operazione tramite i log attività e i log di controllo.

Azure strumenti per raccogliere i dati

Azure offre numerosi strumenti che possono essere utili per questo processo:

Azure DevOps per contenere i metadati relativi all'evento imprevisto

In un modulo precedente di questo percorso di apprendimento è stato illustrato l'uso di Azure Boards nella suite di Azure DevOps come unica posizione per raccogliere tutte le informazioni su un evento imprevisto a partire dalla risposta iniziale. Ci aiuta a porre domande su quando un evento imprevisto è stato dichiarato per la prima volta, chi era in chiamata, chi è stato assegnato all'incidente e così via. È anche possibile usare il wiki Azure DevOps come modo centralizzato per estrarre alcune delle informazioni relative all'evento imprevisto stesso e alla conversazione che si è verificata durante l'evento imprevisto.

Microsoft Graph API per estrarre la conversazione

Microsoft Graph API offre un modo programmatico per recuperare la conversazione raccolta all'interno del canale di Teams dedicato a questo evento imprevisto specifico. I dati recuperati includono timestamp, autore, modifiche, risposte e alcuni messaggi di sistema, che possono essere utili per la creazione di una cronologia.

Un modo semplice per iniziare a usare Microsoft Graph API consiste nell'usare Microsoft Graph Explorer. Microsoft Graph Explorer è un browser API basato sul Web che consente di scegliere le chiamate API da un pannello di query Sample e provarle in modo interattivo.

Prima di eseguire le query, assicurarsi che l'utente o l'app in uso disponga delle autorizzazioni e del consenso necessari per la modalità di accesso scelta. Negli scenari delegati, l'elenco dei team uniti usa Team.ReadBasic.All, l'elenco dei canali usa Channel.ReadBasic.All, e la lettura dei messaggi del canale richiede ChannelMessage.Read.All. Se successivamente si automatizza il flusso di lavoro con accesso solo tramite app, utilizzare GET /users/{id | user-principal-name}/joinedTeams anziché l'alias solo delegato /me/joinedTeams, utilizzando l'autorizzazione applicativa Team.ReadBasic.All. Per i passaggi di lettura specifici del canale, le opzioni di sola app con privilegi minimi sono ChannelSettings.Read.Group per elencare i canali e ChannelMessage.Read.Group per la lettura dei messaggi, entrambe con il consenso specifico della risorsa.

Verrà illustrato un set di chiamate API Microsoft Graph v1.0 "Microsoft Teams" per recuperare la conversazione. I messaggi del canale sono stati spostati da beta a v1.0 diversi anni fa, quindi gli endpoint beta non sono più necessari per questo scenario. In ogni fase, scegliamo una query, eseguiamo la query e poi selezioniamo le informazioni dalla risposta che ci aiutano con il passaggio successivo. Queste informazioni verranno quindi usate per costruire la richiesta successiva. Si supponga, ad esempio, di eseguire una query su un elenco di ID team per visualizzare i team di cui si fa parte. Scegliamo quello di cui abbiamo bisogno dalla risposta e inseriamo questo ID nell'URL della prossima query per ottenere un elenco di canali in quel team.

Ecco i nostri passaggi, mostrati come endpoint di Microsoft Graph v1.0:

GET /me/joinedTeams (per trovare l'ID del team che usiamo in uno scenario delegato) o GET /users/{id | user-principal-name}/joinedTeams (per eseguire la stessa operazione in uno scenario solo applicazione).
GET /teams/{team-id}/channels (per trovare l'ID canale del canale usato per quell'incidente).
GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (per recuperare la conversazione threadata).
Seguire @odata.nextLink e replies@odata.nextLink in base alle esigenze oppure utilizzare GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies per scorrere thread più grandi.

Se è stato usato un canale condiviso, si noti che l'API joinedTeams non restituisce il team host per un canale condiviso di cui l'utente è membro diretto. Questa avvertenza si applica se si chiama GET /me/joinedTeams o GET /users/{id | user-principal-name}/joinedTeams. In tal caso, iniziare dal team noto e dagli identificatori di canale o usare le API del team associate per individuare il team host.

In Graph Explorer è possibile immettere questi URL direttamente o selezionare le voci equivalenti dal pannello Sample query nel pannello Microsoft Teams.

Se in un secondo momento si vuole costruire un programma per eseguire ognuno di questi passaggi (e in effetti si esegue questa operazione), è disponibile un'opzione frammenti di codice nella finestra della richiesta che presenta il codice di esempio per tale query in diversi linguaggi di programmazione.

A seconda del modo in cui il team usa Teams, la cronologia dei messaggi può contenere anche messaggi di sistema che spiegano quando i membri sono stati aggiunti o rimossi. Tuttavia, se è necessario un audit trail autorevole di appartenenza al canale o di modifiche di accesso, si dovrebbe integrare questi dati con i log di controllo di Microsoft 365.

Dashboard e cartelle di lavoro per la visualizzazione del contesto

Azure dashboard e cartelle di lavoro Azure Monitor consentono di ricostruire il contesto rilevato dagli operatori durante un evento imprevisto. I dashboard sono utili per una panoramica operativa immediata dei servizi di Azure. Le cartelle di lavoro sono in genere più adatte per l'analisi degli eventi imprevisti perché supportano query, parametri, drill-down e testo narrativo più avanzati insieme ai grafici.

Se si dispone già di un dashboard o di una cartella di lavoro che acquisisce i segnali corretti, impostarne l'intervallo di tempo sul periodo intorno all'evento imprevisto e usarli per ricostruire ciò che gli utenti hanno visto al momento. Ciò può risultare particolarmente utile per correlare metriche, log e avvisi tra diverse risorse.

I dashboard condivisi sono Azure risorse e possono comunque essere esportati come JSON dal portale. Questo percorso di esportazione/importazione è utile quando si vogliono gestire le versioni o si desidera creare un modello del dashboard. Tuttavia, per la maggior parte degli scenari di indagine post-evento imprevisto, le cartelle di lavoro sono lo strumento più flessibile perché consentono di combinare visualizzazioni, query KQL e testo esplicativo in un singolo artefatto.

Log delle attività, log delle risorse e Analisi dei log per l'esplorazione delle modifiche

Un'area di lavoro Log Analytics può accettare dati da molte origini, tra cui i Log attività di Azure, i Log delle risorse di Azure e la diagnostica specifica del servizio. Creare prima di tutto una nuova area di lavoro Log Analytics. Nel portale di Azure aprire quindi Monitora → log attività e selezionare Export Activity Logs nella parte superiore del riquadro. Verrà aperta un'impostazione di diagnostica che consente di inviare il log attività per una sottoscrizione Azure all'area di lavoro.

In breve tempo, è possibile usare il linguaggio di query Kusto (KQL) per recuperare informazioni dettagliate sulle modifiche apportate in tale sottoscrizione dopo aver connesso l'origine dati.

Ad esempio, la query seguente mostra informazioni sulle risorse modificate o eliminate. È possibile impostare l'intervallo di tempo nell'esperienza dei Log per affinare più precisamente il periodo poco prima dell'incidente.

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

Questa query è utile per le modifiche del piano di gestione, ma è opportuno ricordare cosa non viene visualizzato. AzureActivity acquisisce le operazioni del control plane, ad esempio azioni quali creazione, aggiornamento, eliminazione e gestione delle politiche. Non acquisisce modifiche a livello di piano dati o a livello di applicazione all'interno di un servizio. Per esaminarli, associare questa query ai log delle risorse Azure, ai log di controllo specifici del servizio, alla cronologia di distribuzione e ai record CI/CD o di controllo del codice sorgente.

Una nota rapida: quando si esporta il log attività Azure, le informazioni iniziano a fluire nell'area di lavoro Log Analytics da quel momento in avanti. Non sarà possibile eseguire una query sull'area di lavoro in modo retroattivo per gli eventi che si sono verificati prima di stabilire la connessione.

Questi strumenti dovrebbero essere in grado di dare un buon inizio alla raccolta di informazioni necessarie per una cronologia da usare in una revisione post-evento imprevisto. Prima di immergerti direttamente in una revisione post-evento imprevisto, ti consigliamo di avvisarti di alcune trappole comuni. Questo è l'argomento della prossima unità.

Commenti e suggerimenti

Questa pagina è stata utile?

Processo di revisione post-evento imprevisto

Verificare le proprie conoscenze

Commenti e suggerimenti