Con l'emergere del lavoro ibrido, è diventato fin troppo comune ritrovarsi con un'esperienza utente di scarso livello: utenti che si lamentano di applicazioni lente, interruzioni della rete e arresti anomali dei computer sono ormai all'ordine del giorno. Inoltre, molti di questi problemi vengono considerati risolti perché spariscono, e non perché ne sia stata identificata la causa principale.

La Root Cause Analysis, o analisi delle cause profonde, infatti, richiede che i dati (che devono essere molti) siano acquisiti in maniera allineata dal punto di vista temporale, contestuale e sufficientemente ampia da poter consentire di identificare o escludere potenziali colpevoli. Ma raccogliere e analizzare i dati utilizzando le tecniche di monitoraggio tradizionali non è facile. Inoltre, il fatto che i problemi prestazionali interessino utenti e applicazioni che possono essere ovunque, pone un'ulteriore difficoltà, perché è complesso acquisire i dati giusti nei posti giusti.

Nel mio precedente ruolo di analista presso Gartner, ho notato che la sfida principale che i miei clienti si trovavano ad affrontare non era la mancanza di dati sulle prestazioni, ma l'incapacità di utilizzare più silos di dati non correlati per risolvere i problemi. Gli strumenti di monitoraggio in silo che si concentravano su un'unica area venivano utilizzati dai team per addossare la responsabilità gli uni agli altri; ad esempio, i team che si occupavano di app davano la colpa ai team che si occupavano di rete, che, a loro volta, additavano gli addetti alla sicurezza o al calcolo degli utenti finali. Tutto questo, ammesso e non concesso che gli strumenti esistessero. In alcuni ambienti client, c'era una totale mancanza di visibilità.

Figura 1: il monitoraggio dell'esperienza digitale richiede diversi dati telemetrici sulle prestazioni, che devono essere raccolti, correlati e visualizzati per ottenere informazioni concrete su tutti gli utenti

Qualsiasi esercizio diagnostico completo acquisisce sia le serie temporali, sia i dati relativi agli eventi, in base a tre principali categorie di potenziali cause: l'applicazione, la rete e il dispositivo endpoint. Questo approccio garantisce la raccolta di prove sufficienti che consentono di rivelare con sicurezza dove si trova il problema, in modo che possa essere risolto.

Come sappiamo, i dati possono essere disordinati, ed è raro che il problema sia facilmente individuabile. Ad esempio, alla base di una chiamata Microsoft Teams disturbata o di un'applicazione lenta possono esserci diverse cause. Le soluzioni di monitoraggio dell'esperienza digitale (DEM) sono state sviluppate per risolvere questi problemi, ma, per determinare la causa profonda, devono poter acquisire i dati relativi alla reale esperienza dell'utente finale e scansionare endpoint, rete, applicazioni e sicurezza.

Come si vede nella Figura 2, è fondamentale iniziare con una misura oggettiva dell'esperienza dell'utente finale (caricamento lento della pagina, scarsa qualità delle chiamate). Dopodiché, si prosegue correlando l'esperienza utente di scarsa qualità con le varie potenziali cause.

Figura 2: l'analisi delle cause profonde richiede una vasta gamma di punti di dati per interpretare correttamente il segnale dal rumore

Ad esempio, alcune settimane fa, un dipendente di Zscaler ha improvvisamente iniziato a riscontrare un grave peggioramento delle prestazioni di tutte le app, ma soprattutto di Zoom. Dato che Zoom è un'applicazione in tempo reale, le fluttuazioni della connettività sono particolarmente evidenti. L'analisi con ZDX ha permesso di confermare il problema di Zoom, perché il punteggio associato all'app è diminuito drasticamente e ci sono stati dei cali nel corso della giornata.

Figura 3: calo delle prestazioni di Zoom

Per prima cosa, è stato necessario esaminare i tempi di risoluzione del server e del DNS, per verificare l'eventuale possibilità di correlare i cali. In questo modo, abbiamo escluso che la causa del problema fosse qui.

Figura 4: i tempi di risposta di server e DNS non mostrano fluttuazioni

Successivamente, abbiamo osservato la latenza di rete end-to-end e, sebbene il flusso fosse leggermente intermittente, la latenza totale è risultata inferiore a 25 ms. La causa è dunque da ricercare altrove.

Figura 5: la latenza è relativamente piatta e inferiore a 25 ms per tutto il tempo.

Infine, abbiamo preso in analisi il dispositivo dell'utente finale. Le metriche sullo stato del dispositivo si sono rivelate buone, con CPU, memoria e utilizzo del disco entro limiti accettabili.

Figura 6: in base a CPU, memoria e utilizzo del disco, la valutazione dello stato del dispositivo è buona.

Le metriche sembravano buone, ma gli eventi del dispositivo dell'utente mostravano dei cambiamenti negli attributi del dispositivo. Il Gateway_MAC_Address passava da un valore valido a un valore nullo: un valore nullo significa che, con l'hop successivo, il dispositivo perde temporaneamente la connessione. Questa catena di eventi indica un problema di livello 2 tra endpoint e gateway; l'utente ha quindi riavviato il gateway (che non ha sortito alcun effetto) e alla fine ha sostituito il dispositivo gateway, che ha portato alla risoluzione del problema.

Figura 7: gli eventi del dispositivo evidenziano le modifiche negli attributi del dispositivo, mostrando un problema di livello 2 tra l'endpoint e il gateway.

Quando si tratta di individuare la causa profonda dei problemi prestazionali, è necessario ottenere i dati giusti nei posti giusti.

Per ulteriori informazioni su come Zscaler e ZDX sono in grado di fornire questo livello di visibilità per la Root Cause Analysis, o analisi delle cause profonde, vai qui.

(La figura 2 è ispirata all'eccellente lavoro dell'analista di Gartner Greg Murray, che è disponibile qui. Per consultarlo, è necessario disporre di un abbonamento a Gartner).