Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Fase 1: fissare gli obiettivi

Capire quale livello di resilienza è necessario e come lo si misurerà è la base per la fase degli obiettivi prefissati. È difficile migliorare qualcosa se non si ha un obiettivo e non si può misurarlo.

Non tutte le applicazioni richiedono lo stesso livello di resilienza. Quando stabilite degli obiettivi, considerate il livello richiesto per effettuare gli investimenti e i compromessi corretti. Una buona analogia è quella di un'auto: ha quattro pneumatici ma ne trasporta solo una di scorta. La possibilità di avere più pneumatici sgonfi durante una corsa è bassa e disporre di pezzi di ricambio aggiuntivi potrebbe compromettere altre caratteristiche, come lo spazio di carico o il risparmio di carburante, quindi si tratta di un compromesso ragionevole.

Dopo aver definito gli obiettivi, si implementano i controlli di osservabilità nelle fasi successive (Fase 2: progettazione e implementazione e Fase 4: Operazione) per capire se gli obiettivi vengono raggiunti.

Mappatura delle applicazioni critiche

La definizione degli obiettivi di resilienza non dovrebbe essere esclusivamente una conversazione tecnica. Iniziate invece con un approccio orientato al business per capire cosa dovrebbe offrire l'applicazione e le conseguenze di un eventuale deterioramento. Questa comprensione degli obiettivi aziendali si estende quindi a cascata ad aree come l'architettura, l'ingegneria e le operazioni. Qualsiasi obiettivo di resilienza definito potrebbe essere applicato a tutte le applicazioni, ma il modo in cui gli obiettivi vengono misurati spesso varia a seconda della funzione dell'applicazione. È possibile che stiate eseguendo un'applicazione fondamentale per l'azienda e, in caso di danneggiamento di tale applicazione, l'organizzazione potrebbe perdere entrate significative o subire danni alla reputazione. In alternativa, potresti avere un'altra applicazione che non è altrettanto importante e in grado di tollerare alcuni tempi di inattività senza influire negativamente sulla capacità aziendale dell'organizzazione.

Ad esempio, si pensi a un'applicazione di gestione degli ordini per un'azienda di vendita al dettaglio. Se i componenti dell'applicazione di gestione degli ordini sono danneggiati e non funzionano correttamente, le nuove vendite non verranno effettuate. Questa società di vendita al dettaglio ha anche una caffetteria per i suoi dipendenti che si trova in uno dei suoi edifici. La caffetteria dispone di un menu online a cui i dipendenti possono accedere su una pagina Web statica. Se questa pagina Web non è più disponibile, alcuni dipendenti potrebbero lamentarsi, ma ciò non causerà necessariamente danni finanziari all'azienda. Sulla base di questo esempio, l'azienda probabilmente sceglierebbe di avere obiettivi di resilienza più aggressivi per l'applicazione di gestione degli ordini, ma non effettuerà un investimento significativo per garantire la resilienza dell'applicazione web.

Identificare le applicazioni più critiche, dove dedicare il massimo impegno e dove trovare i compromessi è importante tanto quanto poter misurare la resilienza di un'applicazione in produzione. Per comprendere meglio l'impatto della compromissione, è possibile eseguire un'analisi dell'impatto aziendale (BIA). Una BIA fornisce un approccio strutturato e sistematico per identificare e assegnare priorità alle applicazioni aziendali critiche, valutare potenziali rischi e impatti e identificare le dipendenze di supporto. La BIA aiuta a quantificare il costo dei tempi di inattività per le applicazioni più importanti dell'organizzazione. Questa metrica aiuta a delineare quanto costerà se un'applicazione specifica è danneggiata e non è in grado di completare la sua funzione. Nell'esempio precedente, se l'applicazione di gestione degli ordini è compromessa, l'attività di vendita al dettaglio potrebbe perdere entrate significative.

Mappatura delle storie degli utenti

Durante il processo di BIA, è possibile scoprire che un'applicazione è responsabile di più di una funzione aziendale o che una funzione aziendale richiede più applicazioni. Utilizzando il precedente esempio di una società di vendita al dettaglio, la funzione di gestione degli ordini potrebbe richiedere applicazioni separate per il checkout, la promozione e la determinazione dei prezzi. Se un'applicazione si guasta, l'impatto potrebbe essere avvertito dall'azienda e dagli utenti che interagiscono con l'azienda. Ad esempio, l'azienda potrebbe non essere in grado di aggiungere nuovi ordini, fornire l'accesso a promozioni e sconti o aggiornare il prezzo dei propri prodotti. Queste diverse funzioni richieste dalla funzione di gestione degli ordini potrebbero fare affidamento su più applicazioni. Queste funzioni potrebbero anche avere più dipendenze esterne, il che rende troppo complesso il processo di raggiungimento di una resilienza puramente incentrata sui componenti. Un modo migliore per gestire questo scenario consiste nel concentrarsi sulle storie degli utenti, che descrivono l'esperienza che gli utenti si aspettano quando interagiscono con un'applicazione o un insieme di applicazioni.

Concentrarsi sulle storie degli utenti aiuta a capire quali aspetti dell'esperienza del cliente sono più importanti, in modo da poter creare meccanismi di protezione da minacce specifiche. Nell'esempio precedente, una storia utente potrebbe essere checkout, che coinvolge l'applicazione di checkout e dipende dall'applicazione di determinazione dei prezzi. Un'altra storia utente potrebbe riguardare la visualizzazione di promozioni, che riguarda l'applicazione di promozione. Dopo aver mappato le applicazioni più importanti e le relative storie utente, puoi iniziare a definire le metriche da utilizzare per misurare la resilienza di queste storie utente. Queste metriche possono essere applicate a un intero portfolio o a singole storie utente.

Definizione delle misurazioni

Gli obiettivi dei punti di ripristino (RPO), gli obiettivi dei tempi di ripristino (RTO) e gli obiettivi a livello di servizio (SLO) sono misure standard del settore utilizzate per valutare la resilienza di un determinato sistema. L'RPO si riferisce alla quantità di perdita di dati che l'azienda può tollerare in caso di guasto, mentre l'RTO misura la velocità con cui un'applicazione deve essere nuovamente disponibile dopo un'interruzione. Queste due metriche vengono misurate in unità di tempo: secondi, minuti e ore. È inoltre possibile misurare il periodo di tempo durante il quale l'applicazione funziona correttamente, ovvero esegue le sue funzioni come previsto ed è accessibile ai suoi utenti. Questi SLO descrivono in dettaglio il livello di servizio previsto che i clienti riceveranno e vengono misurati mediante parametri quali la percentuale (%) di richieste soddisfatte senza errori entro un tempo di risposta inferiore a un secondo (ad esempio, il 99,99% delle richieste riceverà una risposta ogni mese).  RPO e RTO sono correlati alle strategie di disaster recovery, presupponendo che si verifichino interruzioni nel funzionamento delle applicazioni e nei processi di ripristino che vanno dal ripristino dei backup al reindirizzamento del traffico degli utenti. Gli SLO vengono risolti implementando controlli ad alta disponibilità, che tendono a ridurre i tempi di inattività di un'applicazione.

Le metriche SLO sono comunemente utilizzate nella definizione degli accordi sul livello di servizio (SLA), che sono contratti tra fornitori di servizi e utenti finali. Gli SLA di solito prevedono impegni finanziari e definiscono le sanzioni che devono essere pagate dal fornitore se questi accordi non vengono rispettati. Tuttavia, uno SLA non è una misura del vostro livello di resilienza e un aumento di uno SLA non rende l'applicazione più resiliente.

Puoi iniziare a definire i tuoi obiettivi in base a SLO, RPO e RTO. Dopo aver definito gli obiettivi di resilienza e aver acquisito una chiara comprensione degli obiettivi RPO e RTO, è possibile eseguire una valutazione dell'architettura AWS Resilience Hubper scoprire potenziali punti deboli legati alla resilienza. AWS Resilience Hub valuta un'architettura applicativa rispetto alle best practice di AWS Well-Architected Framework e condivide le linee guida per la correzione nel contesto di ciò che deve essere specificamente migliorato per soddisfare gli obiettivi RTO e RPO definiti.

Creazione di misurazioni aggiuntive

RPO, RTO e SLO sono buoni indicatori di resilienza, ma puoi anche pensare agli obiettivi da una prospettiva aziendale e definire obiettivi relativi alle funzioni dell'applicazione. Ad esempio, il vostro obiettivo potrebbe essere: gli ordini al minuto andati a buon fine rimarranno superiori al 98% se la latenza tra il mio frontend e il backend aumenta del 40%.Oppure: gli stream avviati al secondo rimarranno entro una deviazione standard dalla media anche in caso di perdita di un componente specifico. È inoltre possibile creare obiettivi per ottenere una riduzione del tempo medio di ripristino (MTTR) per tutti i tipi di errore noti; ad esempio: i tempi di ripristino verranno ridotti del x% se si verifica uno di questi problemi noti. La creazione di obiettivi in linea con le esigenze aziendali consente di anticipare i tipi di guasti che l'applicazione dovrebbe tollerare. Inoltre, consente di identificare gli approcci per ridurre la probabilità di compromissione dell'applicazione.

Se pensate all'obiettivo di continuare a funzionare se perdete il 5% delle istanze che alimentano l'applicazione, potreste decidere che l'applicazione debba essere prescalata o avere la capacità di scalare abbastanza velocemente da supportare il traffico aggiuntivo causato durante quell'evento. In alternativa, potreste decidere di sfruttare diversi modelli architettonici, come descritto nella sezione Fase 2: Progettazione e implementazione.

È inoltre necessario implementare misure di osservabilità per i propri obiettivi aziendali specifici. Ad esempio, puoi monitorare il tasso medio degli ordini, il prezzo medio degli ordini, il numero medio di abbonamenti o altre metriche che possono fornire informazioni sullo stato di salute dell'azienda in base al comportamento dell'applicazione. Implementando funzionalità di osservabilità per la tua applicazione, puoi creare allarmi e intervenire se queste metriche superano i limiti definiti. L'osservabilità è trattata più dettagliatamente nella sezione Stage 4: Operate.