Che cos'è la resilienza delle applicazioni?

Le applicazioni alimentano praticamente ogni aspetto del business moderno, dall'elaborazione delle transazioni con i clienti e la gestione della supply chain alla collaborazione dei dipendenti e all'analisi dei dati in tempo reale.

Quando queste applicazioni falliscono, l'impatto può essere grave. I tempi di inattività - periodi in cui un'applicazione non è disponibile o non è in grado di funzionare correttamente - possono causare danni alla reputazione, un peggioramento dell'esperienza utente e perdite finanziarie significative.

Infatti, il 98% delle organizzazioni riferisce che i costi dei tempi di inattività superano i 100.000 dollari all'ora e un terzo stima perdite tra 1 e 5 milioni di dollari.

Progettando e implementando applicazioni resilienti, le organizzazioni possono evitare e mitigare queste interruzioni.

La resilienza delle applicazioni si basa su due principi fondamentali:

• Tolleranza ai guasti: la capacità di un'applicazione di continuare a funzionare quando parte di essa si guasta.

• Alta disponibilità: capacità di un sistema di essere accessibile e affidabile per quasi il 100% del tempo. 

Le applicazioni resilienti  aiutano a ridurre le vulnerabilità nell'architettura delle applicazioni, a migliorare l'efficienza operativa e a garantire un'esperienza coerente anche di fronte a interruzioni impreviste.

Per creare e implementare applicazioni resilienti, gli sviluppatori e i team IT possono utilizzare diversi strumenti e pratiche durante tutto il ciclo di vita dell'applicazione.

I componenti comuni delle applicazioni resilienti includono:

• Ridondanza
• Bilanciamento del carico
• Contenimento dei guasti
• Observability
• Automation
• Degradazione graduale
• Scalabilità

Ridondanza significa disporre di versioni di backup dei sistemi critici. In caso di guasto di un sistema, il backup subentra, contribuendo a garantire che il sistema continui a funzionare.

Ad esempio, è probabile che un servizio di elaborazione dei pagamenti disponga di più copie del servizio in esecuzione su server diversi. Se un server si blocca, le copie su altri server possono assumere automaticamente il workload in modo che i clienti non notino alcun problema.

Le organizzazioni spesso creano ridondanza in aree chiave:

• Database: memorizzare copie multiple dei dati in luoghi diversi per garantire che nulla vada perso in caso di guasto di un sistema.

• Data center: hosting di applicazione su più siti fisici in modo che le operazioni possano continuare anche se una sede non funziona.

• Ambienti cloud: distribuzione delle applicazioni tra regioni o provider, come Amazon Web Services (AWS), Microsoft Azure e IBM® Cloud, per eliminare i singoli punti di errore.

• Connessioni di rete: sfruttare più fornitori di Internet o di telecomunicazioni per mantenere la connettività durante le interruzioni.

Il bilanciamento del carico implica la distribuzione efficiente del traffico di rete tra più server per contribuire a ottimizzare la disponibilità delle applicazioni. È critico per la resilienza delle applicazioni perché consente ai sistemi di mantenere prestazioni e disponibilità anche quando i singoli componenti si guastano o si sovraccaricano.

Ad esempio, se un server non risponde, il load balancer può reindirizzare automaticamente il traffico verso altri server integri, mantenendo l'applicazione online.

Il contenimento dei guasti è una pratica di progettazione che isola i componenti critici all'interno di un sistema distribuito, evitando che i problemi localizzati si trasformino in interruzioni a livello di sistema.

Il contenimento è particolarmente importante nelle architetture di microservizi, dove un guasto in un servizio può avere un impatto rapido su molte altre dipendenze se non viene contenuto correttamente.

Le mesh di servizi sono particolarmente utili per contenere gli errori. Questi livelli di infrastruttura aiutano a gestire la comunicazione tra microservizi nelle applicazioni distribuite, fornendo:

• Ritentativi automatici: quando una richiesta fallisce a causa di un problema temporaneo (come un breve problema di rete), la mesh riprova automaticamente invece di arrendersi immediatamente.

• Interruzione del circuito: la mesh monitora lo stato di salute e interrompe temporaneamente l'invio di richieste ai servizi in difficoltà, dando loro il tempo di riprendersi e prevenendo arresti anomali a livello di sistema.

• Tracciamento distribuito: la rete traccia le richieste mentre si spostano tra i diversi servizi, aiutando i team a individuare i rallentamenti e a localizzare esattamente i problemi.

Insieme, queste funzionalità consentono di garantire che gli errori in un servizio non si diffondano ad altri. Supponiamo, ad esempio, che un motore di raccomandazione di prodotti non funzioni su un sito di e-commerce. Una rete di servizi può rilevare questo errore, impedire alle richieste di raggiungere il servizio interrotto e reindirizzare il traffico di conseguenza. Gli utenti possono continuare a navigare e acquistare senza interruzioni.

L'osservabilità consente ai team di monitorare lo stato di salute del sistema in tempo reale utilizzando tre tipi chiave di dati: metriche (prestazioni come i tempi di risposta), registri (record di eventi come errori o crash) e tracce (il percorso completo che una richiesta compie attraverso un sistema).

Acquisendo e analizzando questi segnali, i team possono rilevare anomalie, diagnosticare rapidamente i problemi e ridurre i tempi di inattività. Ad esempio, se un cliente segnala una pagina web a caricamento lento, gli strumenti di observability possono aiutare gli ingegneri a rintracciare la richiesta al servizio che ha causato il ritardo e risolvere il problema prima che riguardi più utenti.

L'automazione svolge un ruolo critico nella resilienza dell'applicazione consentendo ai sistemi di rispondere ai problemi senza richiedere un intervento manuale.

Ad esempio, gli strumenti di observability rilevano i problemi e la ridondanza fornisce risorse di backup. L'automazione è ciò che collega queste funzionalità, orchestrandole nel processo di ripristino. Un'automazione efficace può ridurre significativamente i tempi di ripristino, trasformando quelle che potrebbero essere ore di risoluzione manuale dei problemi in secondi di risposta automatica.

Alcune risposte automatizzate chiave nella resilienza delle applicazioni includono:

• Failover con script: sequenze di azioni predeterminate che trasferiscono automaticamente le operazioni da un sistema guasto ai sistemi di backup identificati tramite la pianificazione della ridondanza. Ad esempio, se il database principale si blocca, il sistema passa automaticamente a un database di backup e reindirizza tutto il traffico lì in pochi secondi.

• Riapprovvigionamento delle risorse: provisioning automatico di nuove istanze o riallocazione delle risorse in caso di guasto dei componenti, ad esempio creando nuove macchine virtuali per sostituire quelle danneggiate senza che nessuno debba intervenire.

• Workflow con ingegneria della piattaforma: coordinamento tra gli avvisi di monitoraggio e le azioni di ripristino per ripristinare il servizio senza il coinvolgimento umano. Ad esempio, se un'app inizia a utilizzare troppa memoria, il sistema la riavvia automaticamente prima che gli utenti notino un rallentamento.

Strumenti come Kubernetes, un sistema open source per la gestione di applicazioni containerizzate, dimostrano come l'automazione unisca i componenti di resilienza. Kubernetes può rilevare i guasti tramite controlli di stato di salute integrati, riprogrammare workload su nodi sani e mantenere la continuità del servizio attraverso workflow automatizzati.

La degradazione graduale comporta il mantenimento della funzionalità principale, eliminando le caratteristiche non essenziali durante le fasi di stress. Ad esempio, durante i picchi di traffico del Black Friday, un rivenditore potrebbe disattivare temporaneamente le recensioni dei clienti e le liste dei desideri per garantire che il carrello e il pagamento rimangano funzionanti.

Le applicazioni scalabili possono adattare automaticamente le risorse secondo le esigenze del workload. Questa funzionalità aiuta a garantire prestazioni e disponibilità anche in caso di fluttuazioni del traffico.

La scalabilità può essere ottenuta in molti modi. Ad esempio, le piattaforme basate sul cloud offrono scalabilità grazie a funzionalità come i bilanciatori di carico integrati, l'autoscaling e la replica multiregionale, ossia la copia di dati e servizi in più località geografiche per migliorare le prestazioni e l'affidabilità. Queste funzionalità consentono ai servizi di distribuire in modo intelligente il traffico, di mantenere il tempo di attività e di minimizzare il tempo di recupero in risposta a condizioni mutevoli.

Ad esempio, una piattaforma di streaming ospitata nel cloud potrebbe funzionare in genere su 100 server. Tuttavia, durante un evento globale dal vivo, può scalare automaticamente fino a 10.000 server in più aree, garantendo una riproduzione fluida per milioni di spettatori simultanei.

Poiché le applicazioni software sono diventate essenziali sia per le operazioni aziendali che per la vita quotidiana dei consumatori, è fondamentale che queste applicazioni resistano a interruzioni impreviste e rimangano funzionali in quasi tutte le condizioni.

Quattro fattori in particolare guidano la crescente enfasi sulla resilienza delle applicazioni.

• Elevate aspettative dei consumatori
• Il costo dei tempi di inattività
• Complessità architettonica
• Pressione normativa

I clienti si aspettano che i servizi digitali funzionino sempre. Secondo Google, il 53% dei visitatori abbandona una pagina mobile se il caricamento richiede più di tre secondi.

Che si tratti di un'app bancaria, di una piattaforma di e-commerce o di un portale sanitario, i tempi di inattività possono provocare defezioni dei clienti, contraccolpi sui social media e danni permanenti al marchio. La disponibilità dell'applicazione non è solo una metrica tecnica, ma un requisito aziendale fondamentale.

Le interruzioni delle applicazioni possono essere costose per le organizzazioni di tutte le dimensioni. Consideriamo uno scenario comune: un marchio retail lancia un evento di vendita ad alto traffico, ma il servizio di checkout non riesce a far fronte alla domanda aggiuntiva. In pochi minuti, migliaia di transazioni si bloccano, i clienti si sentono frustrati e l'azienda perde entrate.

Oltre alla perdita di vendite, le interruzioni possono innescare una serie di costi secondari, dalle spese di correzione e dalle violazioni degli accordi sul livello di servizio (SLA) alle sanzioni normative, al risarcimento dei clienti e ai danni al marchio a lungo termine.

Recenti incidenti di alto profilo dimostrano quanto possa essere significativo l'impatto:

• Trasporti: nel 2016, un'interruzione dei data center ha bloccato 2.000 voli ed è costato a una grande compagnia aerea circa 150 milioni di dollari di perdite.

• E-commerce: durante un evento di picco delle vendite del 2018, le interruzioni tecniche costano a un rivenditore online circa 72-99 milioni di dollari di mancati ricavi.

• Social media: nel 2021, un'interruzione del servizio di sei ore è costata a un gigante di internet circa 100 milioni di dollari in mancati ricavi pubblicitari.
  

Le moderne architetture applicative hanno molte parti mobili: microservizi, ambienti multicloud, librerie di codici e altro ancora. Sebbene questi componenti modulari migliorino la scalabilità, aumentano anche il numero di potenziali punti di errore.  

Senza una progettazione e un'implementazione resiliente, anche i problemi minori possono aggravarsi. Un singolo guasto del microservizio può ripercuotersi su dozzine di dipendenze. Ad esempio, se un servizio di database che memorizza le informazioni sui prodotti smette di funzionare, può interrompere altre caratteristiche, come la ricerca, i consigli o il pagamento.

Le interruzioni di rete tra le regioni cloud possono anche frammentare i servizi e causare incoerenze nei dati. A differenza di un guasto di un microservizio in cui un componente smette di funzionare completamente, questi problemi di connettività creano uno scenario " split-brain ": parti diverse dell'applicazione continuano a funzionare, ma non possono comunicare tra loro.

Ad esempio, il sistema di ordini di un'app di trading finanziario potrebbe essere disconnesso dai dati sui prezzi in tempo reale, causando la visualizzazione di quotazioni errate o l'esperienza di operazioni non riuscite.

Le interruzioni dell'application programming interface (API) possono inoltre interrompere funzionalità critiche. Mentre i guasti dei microservizi influiscono sui componenti interni controllati dall'organizzazione, le interruzioni delle API coinvolgono servizi di terze parti da cui un'applicazione dipende ma su cui non può effettuare correzioni direttamente. Ad esempio, se il servizio di mappatura di un'app di consegna si interrompe, gli utenti non possono tracciare i conducenti e i conducenti non riescono a trovare i percorsi, interrompendo l'esperienza anche se l'applicazione principale rimane in esecuzione.

In determinati settori e località, le autorità di regolamentazione hanno stabilito requisiti rigorosi per la disponibilità dei dati, le funzionalità di ripristino app, la mitigazione della perdita di dati e il tempo di attività. Questi requisiti elevano la resilienza delle applicazioni da obiettivo tecnico a problema di conformità.

Alcune leggi sulla protezione dei dati e sulla privacy ora includono standard di disponibilità insieme a obblighi di sicurezza. Ad esempio, il Regolamento generale sulla protezione dei dati (GDPR) richiede che i dati personali rimangano protetti e accessibili. In caso di guasto del sistema, le organizzazioni sono tenute a recuperare i dati persi.

I settori altamente regolamentati, in particolare, devono rispettare alcuni degli standard più rigorosi. 

Sebbene il Sarbanes-Oxley Act (SOX) non imponga esplicitamente dei piani di disaster recovery, molte organizzazioni mantengono sistemi di backup e procedure di ripristino formali per contribuire a rispettare e dimostrare la conformità alla legge.

Gli istituti finanziari devono inoltre far fronte a normative e raccomandazioni specifiche per settore, emanate da enti come il Federal Financial Institutions Examination Council (FFIEC), che fornisce indicazioni dettagliate sulla pianificazione della continuità aziendale e sugli obiettivi a livello di tempi di ripristino.

Ai sensi dell'Health Insurance Portability and Accountability ACT (HIPAA), le entità coperte devono implementare misure di sicurezza amministrative, fisiche e tecniche per contribuire a garantire la disponibilità e l'integrità delle informazioni sanitarie protette in formato elettronico (ePHI). Sebbene l'HIPAA non imponga l'accesso 24 ore su 24, 7 giorni su 7, richiede alle organizzazioni sanitarie di mantenere l'accesso ai dati dei pazienti quando necessario per le cure.

La HIPAA Security Rule richiede piani di backup dei dati, procedure di disaster recovery e operazioni in modalità di emergenza, spingendo molte organizzazioni a investire in strategie avanzate di failover e data replication.

Per contribuire a garantire che i sistemi siano in grado di resistere alle interruzioni del mondo reale, le organizzazioni convalidano la resilienza delle applicazioni attraverso una combinazione di misurazioni continue e test proattivi. Questi approcci consentono ai team di monitorare le prestazioni, identificare le vulnerabilità e confermare se le applicazioni possono essere ripristinate in modo rapido ed efficace.

I teamDevOps, in particolare, integrano spesso le pratiche di resilienza nelle pipeline diIntegrazione continua/Delivery Pipeline (pipeline CI/CD). Ciò consente loro di automatizzare il test delle procedure di failover, convalidare le modifiche di configurazione e ripristinare le implementazioni instabili per individuare precocemente i problemi ed evitare che le interruzioni raggiungano gli utenti.

Le organizzazioni si affidano a diverse metriche chiave per valutare la resilienza delle applicazioni. 

Le organizzazioni si rivolgono sempre più ai test per una prospettiva più realistica. Laddove le metriche possono fornire una base, i test possono aiutare le organizzazioni a passare dalla prontezza teorica alla resilienza comprovata. 

L'intelligenza artificiale (AI) e il machine learning (ML) stanno rimodellando il modo in cui le organizzazioni si approcciano alla resilienza. Queste tecnologie offrono nuovi e potenti strumenti per prevenire i tempi di inattività, ma introducono anche sfide uniche.

Una delle maggiori sfide è che i carichi di lavoro dell'AI richiedono una grande quantità di risorse. Molti modelli si basano su unità di elaborazione grafica (GPU), che sono sia costose che difficili da duplicare tra le regioni cloud. Ciò rende la ridondanza, una parte essenziale della resilienza, più difficile da raggiungere.

I sistemi di intelligenza artificiale possono anche fallire in modi inaspettati. Nel tempo, la loro precisione potrebbe peggiorare, un problema noto come deriva del modello. Oppure potrebbero ricevere input contraddittori, dati dannosi progettati per ingannare il sistema. Questi tipi di errori possono essere più difficili da prevedere e contenere.

Inoltre, quando le caratteristiche di AI rallentano o smettono di funzionare—un problema comune negli ambienti cloud a causa dei vincoli delle risorse o della latenza—il resto dell'applicazione deve comunque funzionare in modo affidabile, esercitando una maggiore pressione sulle strategie di degradazione.

Allo stesso tempo, l'AI offre importanti casi d'uso per migliorare la resilienza:

• L'analytics predittiva prevede i fallimenti futuri analizzando modelli e tendenze storici. Questo aiuta i team a sostituire in modo proattivo l'hardware o ad adeguare le risorse prima che si verifichino problemi, ad esempio prevedendo i guasti del disco con giorni di anticipo in base all'andamento della temperatura e del tasso di errore.

• La correzione intelligente utilizza l'AI per prendere decisioni di ripristino più intelligenti. Mentre i sistemi automatizzati tradizionali potrebbero semplicemente riavviare un servizio non funzionante, la correzione basata sull'AI può analizzare i modelli per scegliere la strategia di ripristino ottimale, ad esempio reindirizzando il traffico verso regioni meno cariche o ridimensionando le risorse in base alla domanda prevista.

• Il rilevamento delle anomalie consente all'AI di identificare in tempo reale che il monitoraggio basato su regole potrebbe non notare, come ad esempio combinazioni insolite di metriche che segnalano un problema emergente anche quando le singole metriche sembrano normali.

• I test basati sull'AI consentono ai team DevOps di utilizzare l'AI per simulare scenari di errore più complessi nelle fasi iniziali del processo di sviluppo del software.

In breve, sebbene l'AI introduca nuove complessità, allo stesso tempo può consentire un recupero più veloce, un monitoraggio più intelligente e applicazioni complessivamente più resilienti, soprattutto se integrate in ambienti cloud-native e pipeline DevOps.