Consapevolezza operativa
Per iniziare a lavorare sul monitoraggio per l'affidabilità, è necessario eseguire un passaggio preliminare. Innanzitutto, è necessario assicurarsi di avere un livello ragionevole di consapevolezza operativa.
In poche parole, per migliorare l'affidabilità dei sistemi di produzione, è necessario avere prima di tutto una buona conoscenza di questi sistemi e di come funzionano nell'ambiente di produzione.
Raccogliere informazioni sulla configurazione corrente
Anche se può sembrare strano, in molti ambienti la prima domanda a cui rispondere è la seguente: "Che cosa esattamente è in esecuzione nell'ambiente di produzione?" Gli attuali ambienti di produzione e i percorsi per la distribuzione di software sono sufficientemente complessi e non risulta quindi insolito eseguire per prima cosa alcune attività di individuazione. Data un'applicazione specifica, quali sono le sue parti componenti? Quali parti comunicano con altre parti? Quali sono le dipendenze evidenti (e meno evidenti) per questa applicazione?
Raccogliere informazioni sulle prestazioni normali e precedenti
Una volta ottenute tali informazioni, è possibile tentare di definire una baseline per le prestazioni e il comportamento "normale" del sistema. I motivi per cui potrebbero essere necessarie queste informazioni sono diversi, non ultimo è la possibilità di agevolare la valutazione di un problema dell'applicazione. Nel pieno di un'interruzione non è certo il momento ideale per stabilire se un uso della CPU all'80% durante l'esecuzione dei server di database rappresenti un aspetto positivo o negativo.
Nell'ambito del processo di definizione della baseline, è utile esaminare le prestazioni precedenti. Anche se è vero che le prestazioni precedenti non garantiscono i risultati futuri, talvolta possono aiutarci a calibrare le nostre aspettative. Analogamente, avendo accesso a informazioni sulle interruzioni o sui problemi precedenti di un servizio, è possibile almeno acquisire una certa comprensione delle potenziali modalità di errore, che dovranno essere incorporate nella riflessione in merito all'affidabilità.
Raccogliere informazioni sul contesto
Infine, è utile ottenere alcune informazioni contestuali in relazione a un sistema. Il contesto può rientrare in un'ampia gamma di categorie, molte delle quali di tipo tecnico o sociale. Ad esempio, sul lato sociale è opportuno raccogliere informazioni sugli stakeholder associati a un servizio o a un'applicazione.
Si potrebbe pensare È ovvio chi è il proprietario o chi si occupa di un'app o un servizio specifico, ma nelle grandi imprese o in altre organizzazioni complesse, questo può essere molto più difficile di quanto sembri.
È necessario accettare IL FATTO CHE non è possibile fare progressi rispetto all'affidabilità di un sistema senza una chiara idea di chi sono gli stakeholder, per motivi che diventeranno chiari in seguito, durante la descrizione degli indicatori SLI e degli obiettivi SLO.
Per quanto riguarda il lato tecnico della domanda sul contesto, sarà molto utile prestare attenzione a domande tecniche quali: Come è stata introdotta l'applicazione in produzione? È stata distribuita manualmente durante una distribuzione "epica" o è stata distribuita tramite una pipeline CI/CD automatizzata con una serie di unit test?
Queste informazioni possono avere numerose ramificazioni, tra cui la facilità con cui il processo può essere iterato se e quando è necessario apportare aggiornamenti per il miglioramento dell'affidabilità. Può anche trattarsi di un indicatore molto utile delle attività da svolgere per fare davvero la differenza.
Strumenti di Azure per la consapevolezza operativa
Acquisire una consapevolezza operativa spesso non è semplice, ma verranno qui presentati alcuni strumenti offerti da Azure che possono agevolare il processo. Si tratterà di una descrizione molto superficiale: al termine di questo modulo verranno inclusi riferimenti ad altri moduli e documentazione di Microsoft Learn, che consentono di affrontare questi argomenti in modo più approfondito.
Application Insights
Il primo strumento che verrà esaminato può essere utile per rispondere alla domanda "quali sistemi sono effettivamente in esecuzione?". A chi si occupa delle operazioni spesso viene richiesto di lavorare con un'applicazione che è già in esecuzione nell'ambiente di produzione. Anche se, in una situazione ideale, sarebbe opportuno far parte dell'intero ciclo di vita del software, sin dalla fase di progettazione, non sempre è così. Anzi, spesso avviene il contrario. In tal caso, soprattutto con le applicazioni complesse a più livelli o basate su microservizi, può essere impegnativo anche solo comprendere tutte le varie parti che interagiscono.
Uno strumento che può semplificare questo impegno e fornire informazioni sul comportamento dell'applicazione in produzione è Application Insights. Con un impegno minimo, gli sviluppatori possono instrumentare l'applicazione in modo che invii automaticamente informazioni di telemetria agli agenti di raccolta in esecuzione in Azure. Con queste informazioni, Application Insights può creare una mappa visiva dei componenti dell'applicazione e delle comunicazioni tra questi componenti.
Ecco un esempio:
Nell'immagine precedente è possibile vedere non solo i componenti dell'applicazione, ma anche le comunicazioni fra tali componenti. Se si ingrandisce una delle connessioni tra i componenti, è possibile visualizzare il numero di chiamate effettuate tra i componenti e la latenza media per queste chiamate. È anche possibile visualizzare una rappresentazione del numero di chiamate riuscite e del numero di chiamate non riuscite. Se uno di questi elementi della mappa viene selezionato, Application Insights consente di approfondire le informazioni, visualizzando statistiche dettagliate sulle prestazioni e sulle metriche relative alle operazioni riuscite e non riuscite per tali chiamate. Questo può essere un ottimo modo per avere un'idea del quadro più ampio dei componenti dell'applicazione e del relativo funzionamento come baseline. Come promemoria, è importante assicurarsi di esplorare la mappa delle applicazioni e tutte le informazioni che Application Insights è in grado di offrire prima che si verifichi un'interruzione.
Azure Resource Graph
Application Insights è un'ottima soluzione per acquisire una certa consapevolezza operativa per un'applicazione, ma cosa accade se si vuole ottenere una visione ancora più generale e visualizzare tutte le risorse disponibili in Azure per una sottoscrizione? In passato, per raccogliere queste informazioni era necessario scaricare report o scrivere codice PowerShell, ma ora esiste un sistema molto più semplice.
Azure Resource Graph Explorer fornisce un ambiente di query interattivo direttamente dal portale di Azure per ottenere i dati necessari. Consente di eseguire query arbitrarie che restituiscono risposte in tempo reale basate sulle risorse attualmente in uso. Ad esempio, per visualizzare tutte le macchine virtuali attualmente in esecuzione, è possibile eseguire la query seguente:
Verrà restituito un elenco dettagliato completo delle macchine virtuali usate nella sottoscrizione:
Il linguaggio di query usato in questo ambiente è il linguaggio di query Kusto (KQL). Sarà esaminato più in dettaglio più avanti in questo modulo, quando verrà descritta la funzionalità Log Analytics di Monitoraggio di Azure.
Dashboard
Lo strumento operativo più tradizionale per la consapevolezza operativa è il dashboard. Spesso, quando pensiamo ai responsabili delle operazioni, immaginiamo persone sedute davanti a monitor di grandi dimensioni, intente a fissare dashboard pieni di grafici, diagrammi e contatori. In questo modulo non verrà illustrato come costruire, modificare e usare i dashboard. Queste operazioni possono essere eseguite principalmente aggiungendo contenuti da altre posizioni nel portale e spostandoli in base alle esigenze.
Di seguito vengono esaminate due funzionalità dei dashboard meno diffuse, ma che possono risultare realmente vantaggiose. Queste funzionalità sono disponibili nella parte superiore di ogni dashboard.
Le due frecce evidenziate consentono di caricare ed esportare le rappresentazioni JSON dei dashboard.
La prima funzionalità esaminata sarà la funzionalità di esportazione. Selezionando Esporta e quindi Scarica, nel computer viene scaricato un file JSON che rappresenta il dashboard corrente. Per provare a eseguire questa operazione, accedere al portale, scegliere Dashboard dal menu dei prodotti, quindi selezionare Esporta>Scarica.
Esistono almeno due operazioni utili che è possibile eseguire con questo file:
È possibile archiviare il file nel sistema di controllo del codice sorgente. In questo modo, è possibile tenere traccia delle diverse versioni dei dashboard e consentire ad altri utenti di accedervi se desiderano usare il dashboard. Potremmo definirli "dashboard in formato di codice".
È possibile usare questo file come base per un nuovo dashboard. Ecco un esempio concreto su cui torneremo più avanti in questo percorso di apprendimento: si supponga di dover mostrare a un collega l'aspetto che ha assunto un particolare dashboard per un'ora durante un'interruzione che si è verificata la settimana scorsa. Si potrebbe pubblicare il dashboard e chiedere al collega di selezionare l'ora e il periodo di tempo esatti. In alternativa, con una procedura molto più semplice e meno soggetta a errori, si potrebbe scaricare il dashboard configurato esattamente nel modo necessario e condividere il file JSON. Per evidenziare un secondo periodo nello stesso dashboard, ad esempio un'ora nel futuro, è possibile modificare facilmente il codice JSON.
Questa è la funzionalità di esportazione. verranno illustrati di seguito gli usi della funzionalità di caricamento. Oltre che per caricare file con controllo della versione o modificati dopo l'ultima sezione, è possibile usare la funzionalità di caricamento per trarre vantaggio dal lavoro di altri utenti durante la creazione dei dashboard.
Esaminiamo l'esempio finale di questa sezione, che combina due delle idee illustrate in questa unità. Se si scarica nel computer il file JSON
nel computer e quindi lo si carica in un dashboard, verrà visualizzato un risultato simile al seguente:
È ora disponibile un dashboard in tempo reale che mostra un inventario facilmente comprensibile delle risorse in uso in una sottoscrizione. I dati di questo dashboard provengono dalla stessa origine di Azure Resource Graph Explorer esaminata in precedenza. Di fatto, selezionando uno dei riquadri, è possibile visualizzare (e modificare, se necessario) la query esatta eseguita per generare le informazioni visualizzate nel riquadro. Ottimo, no?
Con questo supporto per la consapevolezza operativa, inizieremo a esplorare solo ciò che vogliamo monitorare per ottenere le informazioni necessarie per migliorare l'affidabilità.