L’uptime del servizio è tutto

Proprio così: la creazione, l'implementazione e l'esecuzione di programmi software sono ormai priorità strategiche per le aziende in quasi tutti i settori.

A volte si tratta della necessità di rimanere competitivi in risposta alle aspettative sempre crescenti dei clienti. In altri casi, l'obiettivo è rivoluzionare mercati in rapido cambiamento, bersagliati da nuovi protagonisti.

Indipendentemente dal settore di attività, il software oggi definisce e fornisce la customer experience a quasi tutti i livelli, dalle prime impressioni alle interazioni più dettagliate.

È essenziale quindi assicurare un servizio disponibile, online e ad alta prestazione.

Il software non rimane operativo da sè.

Soprattutto quando si eseguono aggiornamenti e miglioramenti continui, è inevitabile incappare in periodi di downtime.

La sfida per i team tecnici e DevOps è rappresentata dalla complessa rete di sistemi e infrastrutture che mantiene operativo tutto quel software. Per non parlare della rete ancor più complessa e distribuita di agenti che tengono sotto controllo tutte le parti dello stack tecnologico.

Pertanto, quando qualcosa va storto e il software è lento, non risponde o, peggio ancora, non funziona proprio, ogni minuto dedicato a diagnosticare e risolvere accuratamente i problemi è un minuto sprecato.

E non basta sapere che cosa è andato storto; bisogna conoscerne le cause e sapere come porvi rimedio. A tal fine, è necessario disporre dei record completi di ciò che è accaduto e di come i diversi sistemi interagiscono l'uno con l'altro. Ma come?

Serve il contesto giusto

Ci vuole una singola visualizzazione di tutti i dati di telemetria, che permetta di vedere le correlazioni a ritroso tra le esperienze dei clienti e le applicazioni, tra le applicazioni e l'infrastruttura, e tra l'infrastruttura e gli altri sistemi collegati.

Quando si è in grado di fare queste correlazioni, si può iniziare a individuare i problemi che potrebbero verificarsi, quelli che si sono effettivamente verificati, perché e come risolverli.

In questa guida, guarderemo ai motivi per cui questo tipo di osservabilità contestuale è così importante per le aziende di oggi e quali sono gli ostacoli al suo conseguimento.

È relativamente facile calcolare i costi immediati dei tempi di inattività.

Basta moltiplicare il costo medio al minuto del downtime per il numero di minuti di mancato servizio.

Ad esempio, l'arresto del sito web di Costco per diverse ore nel Giorno del Ringraziamento del 2019 è costato alla società 11 milioni di dollari in vendite mancate, secondo alcuni esperti.

Naturalmente, il costo medio dei periodi di inattività varia anche in base al settore di attività ed è diverso per ogni azienda. Tuttavia, alcuni elementi comuni possono essere usati come guida.

Secondo Gartner, il costo medio dei periodi di downtime è di $5.600 al minuto, ma può fluttuare tra $140.000 e $540.000 per ogni ora. Vi sono quindi grosse variazioni.

Infatti, il 98% delle organizzazioni segnala costi superiori a $100.000 l'ora, l'81% stima cifre oltre $300.000 l'ora e il 33% di queste aziende ammette che un'ora di mancato servizio può arrivare a costare tra 1 e 5 milioni di dollari.

I costi quantificabili

Nella migliore delle situazioni, i tecnici rilevano il problema prima che abbia un impatto sui clienti. Nella peggiore, il problema rimane nascosto per secondi, minuti o persino ore, finché un cliente ne subisce le conseguenze e lo segnala all'azienda.

Immaginiamo un'azienda di e-commerce la cui pagina dei pagamenti rimane inattiva per cinque minuti.

Se cinque tecnici lavorano per due ore all'analisi dell'incidente e alla ricerca della soluzione, il costo dal momento dell'arresto al recupero dell'operatività sarà pari alla paga oraria di un tecnico moltiplicata per 10.

E questo non include le mancate vendite.

Immaginiamo che l'azienda di e-commerce concluda 24.000 vendite al minuto per un fatturato medio di $280.000 al minuto. La perdita quantificabile di ricavi durante il periodo di inattività sarà di $280.000 al minuto, ma si deve tenere in considerazione anche l'insoddisfazione di 24.000 clienti.

A questo si deve aggiungere, inoltre, il costo dell'acquisizione iniziale dei clienti, gli effetti negativi scatenati dalle recensioni dei clienti insoddisfatti e il costo delle attività volte a riconquistare i clienti che hanno optato per soluzioni diverse.

I costi più ingenti

Poi si deve calcolare il costo umano dei disservizi e del downtime. Le levatacce alle 3 di mattina, il rientro anticipato dalle vacanze o persino la perdita del lavoro, ma anche la frustrazione dei colleghi e le continue sollecitazioni da parte degli utenti sono solo alcuni degli effetti collaterali subiti dallo staff durante l'individuazione e la soluzione dei problemi, che possono portare ad attriti all'interno del team.

Per non parlare della perdita di produttività del personale IT e DevOps, che deve occuparsi di indagare, esaminare e riportare disservizi e problemi prestazionali, anziché dedicarsi a progetti strategici.

Questo è forse il costo maggiore per l'azienda e il più difficile da valutare.

Il calcolo del costo rappresentato dalla perdita di produttività dipende dalla strategia di crescita dell'impresa, dal ruolo del software nell'ambito di tale strategia e dal valore dell'infrastruttura all'interno dell'azienda.

Indipendentemente dalle cifre effettive, il prezzo è alto e gli effetti indiretti del calo di produttività hanno conseguenze importanti, come la perdita di terreno rispetto alla concorrenza, le opportunità di mercato mancate e un possibile inizio di stagnazione.

Le interruzioni del servizio hanno costi elevati, ma ancor più elevato è il costo rappresentato dalla mancanza di contesto, che porta a interruzioni ricorrenti. Questo provoca analisi prolungate alla ricerca della causa del problema e una crescente insoddisfazione da parte dei clienti.

Senza il giusto contesto che rivela i motivi dell'arresto del sistema, la ripresa delle attività, seppur rapida, non è definitiva e non porta alla necessaria resilienza.

Perché è così difficile ottenere il giusto contesto?

1. Applicazioni, infrastruttura e servizi sempre più complessi

Gli strumenti di monitoraggio e rilevamento dei problemi delle tradizionali applicazioni monolitiche e delle infrastrutture fisse e statiche mal si adattano alla complessità dell'infrastruttura di oggi.

La moderna infrastruttura basata sui contenuti e distribuita in ambienti ibridi e multicloud è per definizione allargata ed effimera, e richiede approcci operativi completamente nuovi.

Automazione, pipeline di continuous integration/ continuous delivery (CI/CD) e superfici di computazione basate su Kubernetes cambiano le topologie e provocano la costante migrazione delle risorse.

Le applicazioni modulari sono composte da varie tecnologie open source e proprietarie, scritte in una varietà di linguaggi e in framework che cambiano rapidamente.

La complessità è davvero considerevole.

2. Gap tra applicazioni e infrastruttura

Senza una visione integrata e correlata tra le applicazioni (tra cui i servizi di terzi accessibili tramite API) e l'infrastruttura, non è possibile avere un quadro completo, necessario per prendere decisioni informate.

E poiché le applicazioni e l'infrastruttura sono diverse per ciascuna azienda, non è sufficiente affidarsi a dashboard statiche e preconfezionate.

Le dashboard possono mostrare la potenza di computazione di ogni specifico server, ma se si vuole analizzare la salute del sistema nel contesto di un workflow multicloud, è necessario sviluppare un'applicazione mirata all'osservabilità.

3. La diffusione degli strumenti

Quando si usano molteplici strumenti per monitorare le diverse parti dello stack tecnologico, è inevitabile tralasciare qualcosa. Ed è ancor più difficile ottenere una visione olistica di come tutti i sistemi interagiscono l'uno con l'altro.

Di conseguenza, risulta molto complicato analizzare gli incidenti. Inoltre, gli strumenti di monitoraggio open source gratuiti alla fine non sono privi di costi.

Le organizzazioni pagano il prezzo in ore e risorse per gestire questi strumenti, che sono anche poco affidabili.

Ogni secondo che un addetto DevOps spreca per passare da uno strumento a un altro rappresenta un ulteriore secondo di inattività che l'azienda non può permettersi.

Per ottenere il tipo di osservabilità contestuale che aiuta a impedire il verificarsi di problemi e a risolvere gli inconvenienti in modo più intelligente, è necessario usare una piattaforma di osservabilità con queste tre caratteristiche imprescindibili:

1. Aperta: Per monitorare ogni sistema e fonte di dati sulle prestazioni che l'azienda impiega oggi e che utilizzerà domani.

2. Connessa: Per monitorare le prestazioni dell'intero percorso, dall'esperienza dei clienti nel browser o sul dispositivo mobile fino all'infrastruttura di base, che sia nel cloud, on premise o in un ambiente ibrido.

3. Programmabile: Per creare dashboard personalizzate, visualizzazioni e workflow che rappresentino il contesto specifico e i dati più rilevanti per l'azienda.

La combinazione di queste tre caratteristiche aiuterà l'azienda a mantenere l'operatività e la disponibilità del servizio, permettendo al tempo stesso al team di evitare proattivamente futuri incidenti.

Questo è l'approccio che consente di andare oltre il semplice monitoraggio per conseguire la vera osservabilità.

In un mondo alimentato dal software, l'osservabilità è essenziale.

Il software è il fulcro delle interazioni tra l'azienda e i clienti. Pertanto, l'operatività, la disponibilità e le prestazioni del software vanno oltre la tematica dei costi.

Si tratta di mantenere le promesse aziendali.

La chiave per garantire l'operatività, la disponibilità e le prestazioni sta nell'abilità di raccogliere, correlare e contestualizzare i dati relativi al software.

Il giusto contesto è essenziale per poter gestire i tempi di inattività con il vantaggio competitivo delle migliori società di software.

Il risultato sarà un minore spreco di tempo e di denaro. I team dell'infrastruttura e DevOps non dovranno lavorare di notte e durante i weekend.

Ma soprattutto i clienti sapranno che possono contare su un'azienda che fa ciò che promette di fare.

Noi di New Relic abbiamo scritto questo per voi

New Relic One è una piattaforma aperta, connessa e programmabile che fornisce osservabilità contestuale totale sull'intero stack tecnologico. Offre una visione consolidata di tutti i dati, dall'esperienza dei clienti nel browser o sul dispositivo mobile fino alle applicazioni e all'infrastruttura, indipendentemente dall'ambiente in cui opera. Questo riduce la possibilità di tralasciare elementi importanti, e fornisce contesto e dati fruibili, oltrepassando i confini artificiali dell'organizzazione, in modo da trovare e risolvere i problemi rapidamente.

Scopri come possiamo aiutare a mantenere disponibilità e uptime.