Come mantenere i tuoi servizi digitali al top, anche in situazioni impreviste

Cybersecurity

A cura di Antonie Ferte, Technical Director of Southern Europe, Dynatrace

La recente pandemia di Covid-19 ha trasformato le abitudini dei consumatori e portato a un aumento senza precedenti dell’uso dei servizi digitali, che ha aumentato la pressione sui sistemi IT e sulle applicazioni aziendali. La buona notizia è che esistono strategie comprovate e best practice per aiutare le aziende a gestire questa situazione.

La pandemia da COVID-19 ha aumentato significativamente l’attività digitale. Alcune aziende stanno cercando di compensare le revenue perse cambiando in tutto o in parte il loro business online, mentre altre stanno cercando di far fronte al massiccio aumento del numero dei loro utenti online. La maggior parte delle organizzazioni offre servizi digitali e il traffico attuale, in particolare sui servizi essenziali per l’occupazione, la salute e il commercio, ha effettivamente raggiunto volumi senza precedenti, che le organizzazioni non avevano mai sperimentato prima.

Quest’ultime devono quindi essere in grado non solo di rispondere alla domanda attesa e se possibile anticipandola, ma anche a una domanda imprevedibile e improvvisa, sia per i servizi esistenti sia per quelli che saranno sviluppati domani. Esistono strategie comprovate e valide practice per capire e superare la situazione attuale, ma anche per preparare applicazioni e infrastrutture ad affrontare una situazione simile nel futuro. Qui di seguito ve ne illustro alcune:

Primo step: comprendere i modelli di traffico e i potenziali picchi; rimuovere i silos tra i team

Per comprendere l’impatto dei picchi di traffico, prendi l’esempio dei siti di e-commerce durante il Black Friday. Un massiccio aumento degli utenti in un periodo di tempo molto breve comporta sistemi più lenti e un aumento del tasso di errori. I siti di e-commerce sono generalmente ben preparati per questo, poiché sanno quando accadranno.

Tuttavia, la situazione vissuta da molti siti Web all’inizio della pandemia era tutt’altro che prevedibile, con aumenti massicci e improvvisi del traffico, senza schemi chiari o visibilità sui picchi successivi.

Il modo migliore per le organizzazioni di non essere sorpresi da questi inaspettati aumenti delle attività online è ripensare la struttura dei loro team IT, tenendo conto delle esperienze passate e integrando queste conoscenze. I team di business e tecnici devono quindi essere sul pezzo, comunicare tra loro e organizzarsi. Questa è chiamata la strategia BizDevOps.

Per sviluppare un approccio BizDevOps, le organizzazioni devono stabilire una più stretta collaborazione tra i loro team, stabilendo un modello di comunicazione integrato, basato sui dati degli utenti finali. I team devono incontrarsi per rivedere gli eventi del giorno precedente, pianificare il giorno corrente e anticipare quelli seguenti. Se tutti condividono le stesse informazioni, diventa molto più semplice lavorare su un obiettivo comune. E quando tutti hanno accesso agli stessi dati, le organizzazioni sono in grado di agire rapidamente quando accade qualcosa di inaspettato.

Secondo step: capire a cosa prepararsi

Non si tratta di essere in grado di vedere o prevedere un picco nel traffico, perché questo non impedirà il sovraccarico dei sistemi e i problemi che colpiscono gli utenti. Si tratta di capire quando il sistema si arresterà in modo anomalo.

Come sai a cosa prepararti?

Difficile da valutare in una situazione come la pandemia, situazione senza precedenti nell’era digitale. Ma spesso la migliore strategia è quella di eseguire uno stress test. Si tratta di sottoporre la propria infrastruttura a un volume crescente di traffico fino a quando non si inizia a vedere un impatto negativo sui tempi di risposta e / o altri errori.

Idealmente, è necessario un ambiente dedicato per questo. In caso contrario, utilizzare il sistema di produzione quando l’impatto è minimo per gli utenti. Una volta noti i limiti di ciò che il tuo sistema è in grado di gestire, sei pronto per il passaggio successivo.

Terzo step: capire perché il sistema non funziona

Conoscere i limiti del sistema non fornirà un servizio migliore ai vostri utenti e, a seconda del tipo di sistema in uso, le correzioni potrebbero non essere evidenti. Possono essere importanti, come l’aggiunta di nuovi server o più complessi come la modifica del comportamento di un’applicazione specifica, ad esempio passando dal contenuto dinamico al contenuto statico o disattivando determinate funzionalità in caso di carico eccessivo.

Quando si inizia a raggiungere il punto di interruzione identificato attraverso gli stress test (secondo step), bisogna utilizzare l’analisi automatizzata della causa principale per identificare i componenti coinvolti e il motivo esatto del loro malfunzionamento. Questo consentirà ai vostri team di capire come correggere i problemi.

Quarto step: convalidare le correzioni in tempo reale

Dopo aver compreso l’origine dei problemi, i team dovranno lavorare sulle loro correzioni, per implementarle rapidamente in produzione. È quindi essenziale monitorare in tempo reale l’impatto delle correzioni sul funzionamento generale del sistema. A volte correggere un problema da un lato può portarne ad altri in altri ambiti, il che richiede quindi il rollback o la correzione dei nuovi problemi.

È tuttavia importante concentrarsi su un problema alla volta e convalidare l’impatto delle correzioni apportate. I team dovrebbero iniziare con piccoli problemi e, se necessario, combinare le correzioni anziché cercare di correggere processi complessi che coinvolgono molte interdipendenze.

Quinto step: automatizzare le correzioni e renderle riproducibili

Dopo il quarto step, avrai quindi un elenco di piccole correzioni che possono essere applicate separatamente. Potresti essere tentato di documentare come eseguirli. Va bene, ma un’implementazione riproducibile è molto più efficiente della documentazione.

Fornire patch negli script ha dei vantaggi, soprattutto se devi reagire rapidamente a qualcosa di inaspettato. In effetti, chiunque può lanciarli all’istante senza dover apprendere i dettagli. L’esecuzione automatica di uno script è sempre più rapida e soprattutto più sicura rispetto all’esecuzione manuale.

Sesto step: automatizzare il flusso di lavoro

Se i passaggi di questo processo richiedono che qualcuno partecipi, non ti prepareranno per qualcosa di inaspettato che si verifica al di fuori degli orari di ufficio. Fortunatamente, ora hai tutti gli ingredienti per automatizzare questi processi e portarti a ciò che è noto come NoOps. Con un approccio NoOps, non sono più necessarie attività manuali per eseguire operation chiaramente definite. Si tratta quindi di collegare l’analisi della causa principale all’azione correttiva appropriata. Ciò consente di attivare automaticamente le diverse azioni quando necessario.

Da qui la domanda “perché non configurare semplicemente i sistemi in modo che siano sempre alla massima capacità o attivare tutte le fasi e le funzioni di correzione”?

Innanzitutto, perché la gestione di un’infrastruttura è costosa e la maggior parte dei siti è soggetta a periodi di picco molto brevi (in media da 30 a 60 minuti). Il funzionamento continuo a piena capacità comporterebbe un aumento irrazionale dei costi.

In secondo luogo, perché le azioni di mitigazione non sono gratuite e possono avere gravi conseguenze per l’azienda. Prendi l’esempio dei siti multimediali. I servizi di terze parti, come gli annunci pubblicitari visualizzati lì, possono rallentare il sistema durante il traffico di punta. Un’azione di mitigazione potrebbe consistere nel rimuovere temporaneamente questi componenti dal sito, il che provocherebbe una perdita di entrate pubblicitarie, mentre queste entrate potrebbero, ad esempio, finanziare il ridimensionamento dell’infrastruttura, che potrebbe avere un impatto ancora maggiore sull’esperienza dell’utente.

La chiave è identificare e comprendere rapidamente le cause di un rallentamento del sistema, in modo da poter concentrare gli sforzi del team sui componenti che hanno il maggiore impatto sull’azienda.