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

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.