Così come il software ha ‘invaso’ tutte le aree di business, la velocità con cui ci si attende dai team di sviluppo il rilascio di nuovi servizi è cresciuta in modo esponenziale, sia per via della pressione competitiva sia in virtù di processi di innovazione decisamente più rapidi, abilitati soprattutto da interazioni veloci. Le applicazioni, in effetti, sono sempre più sviluppate secondo metodologie Agile che consentono di ‘governare’ la domanda basandosi su rapidi feedback, interazione e collaborazione tra le operation It che lavorano sulle applicazioni e coloro che operano sulle performance infrastrutturali. E dato che il software è la parte ‘più visibile’ del servizio digitale, ‘ambasciatore’ del ‘marchio’ 24×7 attraverso il quale sempre più spesso un brand cerca riconoscibilità sul mercato, assicurarsi che tale servizio incontri le aspettative degli utenti è diventato forse l’aspetto più business critical di tutta l’azienda. Tuttavia, numerosi fattori, a partire dalla crescente complessità dell’It, hanno reso molto più difficoltoso rispetto al passato il monitoraggio e la misurazione della customer experience.
Rischi e sfide ancora da affrontare
Misurare il livello di qualità di un servizio It basandosi sulla customer experience di fatto non è mai stato semplice. In passato parametri come il tempo di attività, la latenza o il tempo di risposta erano considerati appropriati e sufficienti nell’erogazione di servizi sia interni sia esterni. Oggi le metriche di controllo sono decisamente più complesse perché compositi sono i servizi stessi, ‘costruiti’ attraverso infrastrutture eterogenee non più residenti solo all’interno del datacenter aziendale. I parametri che incidono sulla qualità del servizio sono cresciuti e, spesso, non possono essere sotto il diretto controllo dell’It aziendale. Lo stesso vale per lo strato tecnologico delle architetture applicative; sono finiti i tempi dei ‘monoliti’ e delle configurazioni client-server, oggi l’approccio prevalente è quello dei ‘microservizi’ attraverso il quale ogni processo è supportato da varie suite di piccoli servizi software che interagiscono e comunicano attraverso le Api. Ogni servizio oggi può essere scritto attraverso linguaggi di programmazione differenti e tecnologie di accesso, utilizzo ed archiviazione dei dati diversificate sfruttando fonti di dati non necessariamente interne all’azienda.
Tutto ciò, amplificato dal fatto che il consumatore del servizio è cambiato, ha aspettative più elevate in termini di facilità d’uso e pretende un’esperienza ‘impeccabile’ dal punto di vista della qualità, non esitando a rivolgersi altrove se le sue aspettative non vengono soddisfatte.
Secondo l’eBook ‘Agile Operations’ di CA Technologies dedicato proprio all’analisi di questi aspetti, un monitoraggio ‘completo’ della customer experience incontra dunque numerose difficoltà, che potremmo così riassumere:
- punti ciechi: negli ambienti a silos il monitoraggio dei cosiddetti ‘punti ciechi’ avviene solo quando una transazione si muove attraverso diverse componenti di servizio ma molti team delle operation It non hanno la visibilità completa su queste componenti, ancor meno se gli ambienti che ospitano il servizio provengono a ‘terze parti’ (microservizi, Api, Xaas, ecc.). Situazioni che generano delle ‘lacune informative’ all’interno delle quali può diventare complesso risalire alle cause di un disservizio;
- colli di bottiglia: in questo caso si tratta più che altro di un rischio che può aumentare, paradossalmente, dall’intensa diffusione della metodologia Agile che spinge i team delle operation It a fornire analytics e insight durante le fasi di pre-produzione per influenzare i processi di ‘code & design’ delle continue release applicative. La sfida è riuscire a stabilire i ritmi corretti dello sviluppo, partendo però sempre dall’aspettativa dell’utente che, come abbiamo visto, si attende rilasci e migliorie continue;
- war-room: in contesti di sviluppo dove ogni gruppo di lavoro ha i propri dati prestazionali, quando accade un evento critico ognuno di questi viene convocato nella ‘war-room’ per poter andare alla radice del problema. Se in passato, dati i tempi più lunghi di sviluppo e rilascio, questo tutto sommato era un approccio valido, oggi è una via non percorribile: i dati risiedono in aree diverse dell’It (magari anche fuori dal datacenter) ed è difficile capire qual è il team ‘proprietario’. Uno scenario che complica le cose dal punto di vista del Mttr, il tempo medio di riparazione di un disservizio;
- sovraccarico di dati: il volume di dati provenienti da innumerevoli fonti, compresi vari tool di monitoraggio delle prestazioni, deve essere raccolto, razionalizzato e valutato prima di poter essere utilizzato da chi sviluppa, un processo che aggiunge ulteriore complessità.
Gli elementi dell’Agile Operation
Dopo aver analizzato in dettaglio gli scenari entro i quali si stanno muovendo oggi le aziende e le ripercussioni che tali percorsi generano in termini di rischi e sfide per l’It, l’eBook ‘Agile Operations’ dedica il terzo ed il quarto capitolo alla metodologia DevOps, in particolare all’impatto che tale approccio genera in termini di miglioramento dell’Agile Operations inteso come insieme di ‘nuovo pensiero’, processi e tool nell’ambito del performance monitoring. Di seguito forniamo solo una brevissima panoramica di quelli che sono i tre elementi di base di questa nuova ‘filosofia’ (rimandando il lettore allo scaricamento dell’eBook per tutti gli approfondimenti):
- scalabilità e ambienti elastici: ci si riferisce al modellamento di ambienti di controllo e monitoraggio delle performance non solo in grado di fornire una vista unica su tutte le componenti It che incidono sulla qualità del servizio ma anche in grado di scalare dinamicamente in funzione dei cambiamenti degli ambienti applicativi e infrastrutturali;
- miglioramento della qualità attraverso la collaboration: il concetto di Agile Operations non si esaurisce attraverso una vista unica e complessiva del servizio e delle componenti che incidono su di esso ma anche di tutte le ‘operazioni’ e dei processi che determinano il servizio stesso; questo significa adottare un approccio di collaboration che consenta a sviluppatori e operations di lavorare congiuntamente in un ciclo continuo di interazioni;
- rapidi rilasci e veloce risoluzione dei problemi: è un po’ il risultato dei due precedenti ‘step’, a patto però, si legge nell’eBook, che dal punto di vista tecnologico si siano effettuate le scelte corrette in termini di automazione dei processi e ottimizzazione delle risorse, indispensabili per evitare quei rischi di ‘punti ciechi’, ‘colli di bottiglia’ o ‘inefficienza nell’analisi sui dati’ che dovrebbero appartenere al passato e non certo ad un approccio Agile.
Per maggiori informazioni: Devops e agile nello sviluppo software
