Quando l’APM indaga, trova il responsabile e aiuta a far crescere il fatturato

“Elementare Watson”: come scoprire il colpevole dei malfunzionamenti

Lavorare nel campo dell’APM significa spesso essere sotto i riflettori quando le applicazioni hanno dei problemi. Nel nostro campo, molti seguono un approccio standard “a fasi” con poche differenze a seconda di come il ciclo di vita dell’applicazione viene implementato nei processi che nella strumentazione.

Questa, invece, è la storia di un’indagine approfondita realizzata presso un cliente che ha dimostrato non solo il valore dell’APM in produzione, ma anche nei test di verifica, oltre al ruolo della collaborazione tra i responsabili del ciclo di vita delle applicazioni (dev, test e prod).

I primi sospetti

L’area commerciale di una grande compagnia di assicurazioni nel nord Europa aveva notato un calo nel business online legato alle proprie assicurazioni private. Contattato, il reparto IT, non era in grado di comprendere quale fosse la causa né addirittura di confermare l’esistenza di un problema!

Tutto sembrava tranquillo dal loro punto di vista. La unit commerciale ha deciso di indagare meglio e testare la pagina manualmente con un cronometro scoprendo che i tempi di risposta di alcune funzionalità erano molto lenti. A quel punto, sono stati quindi contattati i team responsabili dell’ecommerce della pagina web mostrandogli i dubbi e le ricerche condotte manualmente.

Alla fine, la conferma è arrivata: “Purtroppo è così, ci vuole un sacco di tempo, ma ci sono tante cose che devono essere fatte durante la transazione!” La risposta non era sufficiente; l’area  commerciale voleva capire quale fosse l’impatto del problema: si trattava solo della lentezza per gli utenti finali reali? Chi era interessato da questo malfunzionamento: tutti o solo specifiche aree geografiche? riguardava determinati periodi dell’anno, quando ad esempio avvenivano picchi nell’utilizzo, o accadeva sempre?

Sospetti confermati: l’indagine viene avviata

La strategia investigativa è stata condurre un monitoraggio sintetico per scoprire se il problema era visibile in Internet e da quali aree geografiche. Così è arrivata la prima conferma ufficiale dei sospetti: il tempo di risposta per la transazione di business più importante – volta a fornire il costo dell’assicurazione scelta – era molto alto, circa 12 secondi. Personalmente, avrei effettuato un refresh della pagina già dopo 5 secondi, e le ricerche mostrano che di solito la maggior parte degli utenti fa altrettanto. In questa situazione, tra l’altro, non solo gli utenti sono frustrati ma il sistema stesso è sovraccaricato.

Finalmente era chiaro a tutti: c’era una criticità. Il passo successivo era capire se e quanti utenti finali fossero effettivamente coinvolti.  Per fare questo l’Application Aware Network monitoring è stato distribuito sul front end dell’applicazione. La scoperta è stata “elementare”, gli utenti finali reali erano stati pesantemente colpiti dal malfunzionamento.

La situazione non era ammissibile. Trattandosi di un mercato estremamente competitivo, nel quale anche un singolo click fa la differenza, tempi di risposta crescenti di questo tipo non erano accettabili. Inoltre, la compagnia di assicurazioni aveva in essere un accordo di partnership con una banca che riteneva che le transazioni volte a fornire il costo del servizio assicurativo non dovessero richiedere più di 4 secondi.  Dal momento che l’adempimento a tale SLA non era mai stato misurato, nessuno sapeva di non essere in regola.

L’APM indaga: ecco il colpevole e com’è stato scovato

Il fornitore dei servizi non ha permesso di estendere ulteriormente l’indagine dell’applicazione utilizzando l’Application Aware Network Monitoring all’interno del data center e quindi ha di fatto fermato la possibilità di isolare il dominio di errore che stavano utilizzando per altre applicazioni.

Dynatrace Application Monitoring ha localizzato il problema prendendo il posto della soluzione di APM utilizzata in precedenza e abbandonata dal cliente perché non è stata capace di portare avanti l’indagine. Dopo essere stata implementata, in poche ore la soluzione Dynatrace Application Monitoring ha identificato 7 azioni da portare avanti, tra le quali l’aggiornamento XML Parser, l’ottimizzazione di Garbage Collection e l’impostazione dei Load Balancer Settings. Abbastanza facile intuire che tra questi punti, uno doveva richiamare maggiormente l’attenzione in quanto, una volta postovi rimedio, avrebbe permesso di diminuire in modo sostanziale i tempi di risposta. La funzionalità di analisi Transaction Response Hotspot ha evidenziato che molto tempo andava perso nella fase “Reflection and XML processing api”, ma chi stava sottraendo il tempo?

Il cerchio si chiuse: dalla produzione allo sviluppo e poi di nuovo in produzione

L’informazione è stata estratta dal sistema di produzione e mostrata a uno sviluppatore in grado di metterla rapidamente in relazione con la funzione caching che avevano implementato.
Le informazioni fornite da Dynatrace Application Monitoring dalla produzione erano sufficienti per trovare il problema e contenevano tutti i dati necessari allo sviluppatore per risolverlo. Il fatto di disporre di un numero sufficiente di dati con sufficiente granularità si è rivelato fondamentale in questo caso.

Una soluzione APM che non è capace di arrivare in profondità (come quella adottata in precedenza) non avrebbe portato nella giusta direzione nel capire la causa principale effettiva. Ricordate che la singola transazione analizzata all’inizio sembrava perfetta! 

Avere sotto controllo tutte le transazioni aiuta molto quando non si ricerca semplicemente un errore ma dei veri e propri colli di bottiglia.

Una volta sistemato il problema, la transazione è stata provata nell’ambiente di test monitorato da Dynatrace Application Monitoring mostrando un miglioramento significativo grazie alla comparazione dei risultati fatta dalla soluzione Dynatrace analizzando le cpu. Tutto questo dimostrato che la nuova release era pronta per passare in produzione, dove fin da subito ha mostrato come era in grado di ripercuotersi sui risultati. Ecco come i miglioramenti apparivano dal punto di vista degli utenti reali finali:

Caso risolto. La conclusione: le indagini non possono essere superficiali se l’obiettivo è la crescita del fatturato

Il caso si è chiuso ottenendo un successo clamoroso: un tempo di risposta per la transazione commerciale più importante ridotto da 13,3 secondi e circa 4 secondi, con transazioni aderenti agli SLA nella misura del 90%, rispetto al precedente 11,8%.

Tutti hanno visto concretamente qual è stata la ripercussione ed è possibile anche stabilire una stima corretta dei costi che il problema ha causato (confrontando i guadagni attuali a quelli precedenti). Per questo la compagnia ha scelto di continuare a promuovere e mantenere attivi i processi di APM e ora sta pensando a estendere il monitoraggio delle transazioni dal distribuito fino al mainframe e alle call DB2 con Dynatrace APM4MF, aggiungendo semplicemente un agent z/OS.

Il caso ci lascia un insegnamento importante: se siete alle prese con problemi di prestazioni, non passare il tempo a giocare a indovinare. Avviate le indagini.

Potete partire semplicemente da un check dello stato di salute dei vostri siti web con uno strumento gratuito come il Performance Center Test di Dynatrace. Una volta raccolte le prime prove, verificando che una delle vostre pagine ha un malfunzionamento, chiamate un investigatore più esperto in grado di scavare a fondo con strumenti quali Dynatrace Application Monitoring.

A cura di Anders Lundin, Solution Specialist di Dynatrace