Availability delle applicazioni, 5 passi per ridurre i rischi di downtime

Lo scorso 8 giugno un’indisponibilità massiva di internet ha reso irraggiungibili alcuni tra i siti web più visitati del mondo, tra cui Amazon, Reddit e New York Times: un guasto che come altri simili è stato provocato da modifiche di configurazione di un singolo cliente di un piccolo provider di servizi internet.

Questo è un esempio significativo di quanto sia complicato assicurare alti livelli di application availability, ossia disponibilità delle applicazioni web, soprattutto quando queste scalano velocemente seguendo la crescita del business. Spesso il problema di disponibilità emerge solo quando è già a livelli critici, e altrettanto spesso è difficilissimo prevedere quando si manifesterà.

Come limitare e controllare i problemi di application availability? Come far evolvere l’applicazione man mano che scala in modo da non deludere le aspettative di utenti e clienti con down-time che costano tantissimo in termini di immagine e risultati di business?

ADV

Il perimetro aziendale oggi passa dalla casa dei dipendenti

HP Wolf Security - (Sponsor)

Metà dei dipendenti usa il PC anche per scopi personali e il 30% lascia che venga utilizzato da altri famigliari. La tua cybersecurity è pronta per le sfide del lavoro remoto? LEGGI TUTTO >>

Non è affatto facile. La application availability non dipende tanto dalla qualità dello sviluppo, quanto dalla capacità di migliorare i processi operativi di tutta la vostra organizzazione. Vediamo 5 passi suggeriti da Infoworld per migliorare l’application availability e ridurre i rischi di indisponibilità.

1) Dimensionate il rischio

Il primo passo è capire quanto è grande il rischio che l’applicazione scenda sotto un livello di disponibilità accettabile. Molto di questo rischio è legato al “debito tecnico” nel processo di sviluppo, ma una componente importante nasce anche dai comportamenti inaspettati (unknown) dell’applicazione.

Il Risk Management permette di minimizzare i problemi inaspettati: si individuano le possibli criticità, si definiscono e si “etichettano”, si quantificano, e si classificano in ordine di priorità, creando poi dei meccanismi di risposta per quelle a maggiore impatto potenziale sul business.

Tutto questo si fa costruendo e aggiornando una matrice dei rischi. A ogni potenziale criticità vengono associati due numeri: l’importanza o “severity” (che quantifica l’impatto sul business che ha la criticità se si concretizza), e la probabilità o “likelihood”, che quantifica appunto la probabilità che la criticità si concretizzi.

I rischi più preoccupanti chiaramente sono quelli che hanno alta importanza e alta probabilità. La matrice dei rischi è un prezioso strumento per dare la giusta priorità ai possibili interventi dei team di application management, per allocare le relative risorse, e per migliorare la comunicazione tra i team operativi e il management.

2) Analizzate il funzionamento delle vostre applicazioni

Gli strumenti di application e infrastructure analytics sono fondamentali per capire come le applicazioni si stanno comportando in ogni momento, ottimizzare l’ambiente operativo, individuare e risolvere problemi di performance prima che diventino problemi di disponibilità, e sapere chi sta usando il vostro software e per fare cosa.

Esistono molti sistemi a pagamento e gratuiti di application e infrastructure analytics. Tutti hanno i loro vantaggi e svantaggi, e come sempre quelli a pagamento richiedono significativi investimenti, ma sono più personalizzabili, e molti comprendono funzioni di AI che analizzano nel dettaglio il comportamento delle vostre applicazioni e forniscono segnali anticipatori di problemi di application availability che un essere umano difficilmente può individuare nel mare di possibili dati da analizzare.

Un sistema completo di analytics deve comprendere la possibilità di:

– monitorare il vostro sistema in continuazione evidenziando come sta funzionando;

– evidenziare cambiamenti di comportamento problematici in casi di interventi di riparazione o aggiornamenti;

– notificare anomalie oltre soglie predeterminate per dare la possibilità di fare approfondimenti mirati;

– assistere nel caso di incidenti e malfunzionamenti, fornendo dati che aiutano a capire il problema.

– monitorare l’andamento dei parametri che definiscono i SLA (service-level agreements).

3) Riducete il “debito tecnico”

Una volta configurato e messo in funzione il sistema di analytics, e definita l’entità del “debito tecnico” attraverso la matrice dei rischi, occorre valutare e ridimensionare i potenziali problemi di application availability a maggiore impatto.

Ovviamente i rischi a grande impatto potenziale e grande probabilità sono quelli da affrontare immediatamente. Ma affrontare non significa necessariamente riscrivere il codice: si può lavorare sulla riduzione del potenziale impatto, o della probabilità di accadimento.

Spesso questo si ottiene lavorando sul debito tecnico. Ovviamente questo non si può azzerare: occorre trovare un compromesso tra il costo dell’intervento e il beneficio. Esagerare sul perfezionamento del software significa sempre rinunciare a qualche opportunità.

4) Automatizzate il più possibile la soluzione del problema

Quando si verifica un problema di application availability, il tempo di risoluzione è determinante, ma altrettanto determinante è la corretta diagnosi del problema perché esso non si ripeta.

Di solito la risoluzione richiede le seguenti fasi: scoperta del problema, analisi delle cause, intervento di soluzione temporaneo, soluzione definitiva, recap e sintesi del problema.

È un processo che richiede tempo. Il tempo tra la scoperta e la soluzione si dice mean time to repair (MTTR), e va minimizzato, ma se una o più fasi richiedono un intervento umano, il MTTR può essere lungo, e influire sulla customer satisfaction.

Fortunatamente però alcuni problemi di availability possono essere risolti da processi interamente automatici. Per esempio quando una istanza di elaborazione va offline, il problema può essere software, di rete, o altro ancora, ma il sistema di monitoraggio può evidenziare che l’istanza ha smesso di rispondere, e un meccanismo appositamente preposto può riavviarla immediatamente, o terminarla e rimpiazzarla con una nuova istanza. Siccome non sono coinvolti umani in questo processo, il MTTR si abbassa drasticamente e la disponibilità migliora nella stessa misura.

5) Cercate di far crashare l’applicazione

Il miglior modo di mantenere altissima l’application availability è cercare regolarmente di farla crashare. Avete capito bene: il concetto di base è che comunque il vostro software prima o poi crollerà, quindi meglio che accada in un momento che scegliete voi, in cui la vostra capacità di risposta è al massimo e le possibilità di deludere i clienti minime. E poi comunque questi test consentono di capire meglio come l’applicazione funziona realmente.

Ci sono due modi per provocare un “crash” controllato. Una si chiama “game days”, e prevede dei momenti pianificati in cui si inseriscono criticità specifiche nel sistema per vedere come il problema si manifesta e quanto velocemente lo si scopre e lo si risolve. Un classico esempio è rendere indisponibile un data center per testare la procedura di disaster recovery che trasferisce l’applicazione a un data center di backup.

Il secondo metodo di production operation testing si chiama “chaos testing” e si basa su un software che in modo casuale e imprevedibile rende indisponibile un componente della vostra infrastruttura – un server, un link di rete, un load balancer – per mettere alla prova i vostri meccanismi e processi di recovery.

In entrambi i casi l’obiettivo è individuare i problemi in modo controllato, imparare dagli errori, e migliorare la capacità della vostra applicazione e del vostro sistema di “auto-risolvere” indisponibilità e malfunzionamenti.

Migliorare l’availability significa migliorare i processi

Tirando le somme, per migliorare la application availability non occorre inseguire la perfezione o eliminare tutti i rischi. È più una questione di migliorare i vostri processi operativi, lavorando alla riduzione del potenziale impatto e della probabilità dei problemi, monitorando attentamente applicazioni e infrastrutture, tenendo sotto controllo il debito tecnico, automatizzando e testando regolarmente i meccanismi di risoluzione.

Seguite questo percorso in cinque fasi, e la disponibilità delle vostre applicazioni migliorerà notevolmente, rendendo i vostri clienti più soddisfatti e portando grandi benefici al vostro business.