La revisione post-evento imprevisto
Un aspetto fondamentale dell'analisi successiva a eventi imprevisti è la costruzione di una cronologia condivisa e accurata che riflette la natura non lineare di un evento imprevisto.
Il termine non lineare indica che gli eventi imprevisti non si sviluppano quasi mai in questa sequenza: si verifica un evento, poi un altro evento, si notano degli aspetti, si interviene e il problema viene risolto. Entrano in gioco diverse persone, che notano cose diverse e intervengono in modo diverso, alcune lavorano attivamente, altre no. Se più persone lavorano contemporaneamente, anche gli eventi possono verificarsi in modo contemporaneo, quindi è un po' più complicato.
Per creare una sequenza temporale come questa, anche se complessa, va fatto sempre un primo passaggio importante: raccogliere i dati.
Raccogliere i dati
Prima di poter eseguire un'analisi successiva a eventi imprevisti, è necessario raccogliere i dati. In particolare, è necessario raccogliere quanti più dati possibili sulle conversazioni e i contesti, sia tecnici che non tecnici, che riguardano l'evento, in modo da poter usare tutti i dati cruciali contenuti in esso. Le conversazioni tra i membri del team che si sono verificate durante l'interruzione o l'evento imprevisto saranno tra le fonti di informazioni più ricche.
È consigliabile anche raccogliere i dati del sistema di monitoraggio e di altri sistemi usati dal personale coinvolto che consentono di delineare il contesto dell'evento imprevisto. Quali informazioni venivano estratte dai sistemi quando si è verificato l'evento imprevisto?
Infine, se possibile, sarebbe utile capire meglio cosa è cambiato immediatamente prima e durante l'evento imprevisto, perché i cambiamenti sono spesso fattori determinanti quando si verifica un evento imprevisto.
Questo processo può essere considerato come composto da tre parti separate:
- Raccogliere le conversazioni: Negli altri moduli di questo percorso di apprendimento è stato detto che è importante individuare un luogo in cui il personale può comunicare durante un evento imprevisto. In quel momento, idealmente, le persone coinvolte condividono gli aspetti che hanno funzionato e quelli che non hanno funzionato, quali azioni preferiscono evitare e quali hanno attuato nel passato. La conversazione che avviene mentre si affronta e si risolve il problema è la miglior fonte di apprendimento.
- Determinare il contesto: Durante un evento imprevisto si ricevono segnali da diverse fonti. Quella più importante è il sistema di monitoraggio. In un modulo precedente di questo percorso di apprendimento è stata evidenziata l'importanza di avere un sistema di monitoraggio solido. Idealmente il sistema di monitoraggio deve consentire la creazione di uno snapshot temporizzato per il periodo di tempo in cui si è verificato l'evento imprevisto.
- Individuare le modifiche: Questa operazione può essere eseguita tramite i log attività e i log di controllo.
Strumenti di Azure che consentono di raccogliere i dati
Azure offre una serie di strumenti che possono essere utili in 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 in Azure DevOps Suite come unico riferimento per raccogliere tutte le informazioni su un evento imprevisto a partire dalla risposta iniziale. Esso consente di rispondere alle domande relative al momento in cui l'evento imprevisto è stato dichiarato per la prima volta, chi era in servizio, chi era assegnato all'evento imprevisto e così via. È anche possibile usare la wiki di Azure DevOps in modo centralizzato per inserire parti di informazioni sull'evento imprevisto stesso e sulla conversazione che si è verificata durante l'evento imprevisto.
API Graph di Microsoft per estrarre la conversazione
API Graph di Microsoft consente di trovare, esportare e usare in modo programmatico la conversazione raccolta all'interno del canale Teams dedicato a questo evento imprevisto specifico. I dati recuperati includono anche i metadati che saranno utili per la creazione della cronologia, tra cui le persone che hanno partecipato alla conversazione, il momento in cui è avvenuta e i timestamp per le singole parti della conversazione.
Per iniziare a usare API Graph di Microsoft in modo semplice, usare Graph explorer di Microsoft. Graph explorer di Microsoft è un browser API basato sul Web che consente di recuperare le chiamate API scegliendo le opzioni pre-popolate. Di seguito è riportata un'immagine di tale finestra:
Per recuperare la conversazione, viene esaminata una serie di chiamate API di "Microsoft Teams" e "Microsoft Teams (versione beta)". In ogni passaggio della procedura si sceglierà una query, questa verrà eseguita e quindi verranno selezionate le informazioni della risposta utili per il passaggio successivo. Queste informazioni vengono quindi usate per costruire la richiesta successiva. Ad esempio, innanzitutto viene eseguita una query su un elenco di ID del team per visualizzare i team di cui l'utente fa parte. Si sceglie quello adeguato dalla risposta e si inserisce l'ID nell'URL della query successiva per ottenere un elenco di canali in quel team.
Questi sono i passaggi:
- GET "my joined teams" (per trovare l'ID del team in uso).
- GET "channels of a team which I am member of" (per trovare l'ID del canale usato per l'evento imprevisto).
- GET "messages in a channel" (per recuperare la conversazione).
Se in un secondo momento si desidera costruire un programma per eseguire ognuno di questi passaggi, come effettivamente è accaduto, nella finestra della richiesta c'è l'opzione frammenti di codice che contiene il codice di esempio per la query in una serie di linguaggi di programmazione diversi.
Dashboard specifici per la visualizzazione del contesto
I dashboard di Azure consentono di raccogliere in un'unica pagina le informazioni di Monitoraggio di Azure importanti ai fini operativi. L'interfaccia utente consente di scegliere il periodo di tempo visualizzato, in modo da poter "tornare indietro" e visualizzare le informazioni sul dashboard per il periodo di tempo associato a un evento imprevisto, se lo si desidera, purché le informazioni non siano troppo vecchie e quindi non conservate in Monitoraggio di Azure. Questa interfaccia utente ricostruita può essere utile quando si tenta di determinare le informazioni visualizzate dall'utente coinvolto durante l'evento imprevisto, ma è necessario che la persona che esegue la revisione dell'evento imprevisto cerchi manualmente il giusto periodo di tempo.
Una funzionalità dei dashboard in Azure che spesso viene trascurata è la possibilità di eseguire il dump di un modello di un qualsiasi dashboard visualizzato in un file JSON usando il pulsante di download, ovvero la freccia GIÙ, e di eseguire di nuovo l'upload con il pulsante di caricamento, ovvero la freccia SU. Ciò significa che è possibile cercare manualmente l'ora precisa, scaricare il dashboard in quello stato e condividere il file JSON con altri utenti o semplicemente scaricare il dashboard corrente e modificare il JSON in base alle esigenze. Se si cerca la stringa "ora" in un file JSON del dashboard scaricato, viene visualizzata una sezione simile alla seguente:
"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"
},
Modificare la sezione in base alle esigenze e ricaricarla. Se non si ha familiarità con il formato in uso, è possibile modificare il dashboard manualmente, scaricarlo e visualizzarlo nel formato desiderato.
Log di controllo e Log Analytics per l'analisi delle modifiche
Un'area di lavoro Log Analytics può prelevare i dati da molte origini, tra cui il log attività di Azure. Creare innanzitutto una nuova area di lavoro Log Analytics. Passare quindi alla funzionalità Log attività nel portale e scegliere Impostazioni di diagnostica. Questa opzione consente di inviare il log attività per una sottoscrizione di Azure alla nuova area di lavoro.
In breve tempo si potranno usare tutte le potenzialità del linguaggio di query Kusto per recuperare informazioni dettagliate sulle modifiche apportate nella sottoscrizione a partire dalla connessione dell'origine dati.
Ad esempio, la query seguente mostra informazioni sulle risorse modificate o eliminate. Se lo si desidera, è possibile impostare l'intervallo di tempo per la query in Esplora query per determinare con precisione il periodo di tempo immediatamente prima dell'evento imprevisto.
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
Una nota rapida: quando si imposta il log attività di Azure come origine dati, le informazioni passano nell'area di lavoro Log Analytics a partire da quel momento. Non sarà possibile eseguire query di dati sull'area di lavoro in modo retroattivo per gli eventi che si sono verificati prima di effettuare la connessione.
Questi strumenti sono utili per iniziare a raccogliere le informazioni necessarie per la cronologia da usare in un'analisi successiva a eventi imprevisti. Prima di approfondire la revisione post-evento imprevisto, verranno illustrate alcuni trappole comuni. Questo è l'argomento della prossima unità.