Suggerimenti per la definizione degli obiettivi di affidabilità

Si applica a questa raccomandazione per l'affidabilità di Azure Well-Architected Framework:

RE:04	Definire obiettivi di affidabilità e ripristino per i componenti, i flussi e la soluzione complessiva. Visualizzare gli obiettivi per negoziare, ottenere il consenso, impostare le aspettative e guidare le azioni per raggiungere lo stato ideale. Usare le destinazioni definite per compilare il modello di integrità. Il modello di integrità definisce gli stati integri, degradati e non integri.

Questa guida descrive le raccomandazioni per la definizione delle metriche di destinazione di disponibilità e ripristino per carichi di lavoro e flussi critici. Gli obiettivi di affidabilità sono derivati tramite esercizi di workshop con gli stakeholder aziendali. Le destinazioni vengono perfezionate tramite il monitoraggio e il test.

Con gli stakeholder interni, impostare aspettative realistiche per l'affidabilità del carico di lavoro in modo che gli stakeholder possano comunicare tali aspettative ai clienti tramite accordi contrattuali. Le aspettative realistiche aiutano anche gli stakeholder a comprendere e supportare le decisioni di progettazione dell'architettura e sanno che si sta progettando per soddisfare in modo ottimale gli obiettivi concordati.

È consigliabile usare le metriche seguenti per quantificare i requisiti aziendali.

Termine	Definizione
Obiettivo del livello di servizio (SLO)	Destinazione percentuale che rappresenta l'integrità del componente e del livello di affidabilità. Maggiore è il livello, più affidabile è il componente. L'SLO composito rappresenta la destinazione aggregata dell'intero carico di lavoro e degli account per i contratti di servizio dei componenti.
Indicatore a livello di servizio (SLI)	Metrica generata da un servizio. Le metriche SLI vengono aggregate per quantificare un valore SLO.
Contratto di servizio	Contratto contrattuale tra il provider di servizi e il cliente del servizio. Il contratto definisce i contratti di servizio. Il mancato rispetto del contratto potrebbe avere conseguenze finanziarie per il provider di servizi.
Tempo medio di ripristino (MTTR)	Tempo impiegato per ripristinare un componente dopo il rilevamento di un errore.
Tempo medio tra errore (MTBF)	Durata per cui il carico di lavoro può eseguire la funzione prevista senza interruzioni, fino a quando non ha esito negativo.
Obiettivo del tempo di ripristino (RTO)	Il tempo massimo accettabile in cui un'applicazione può rimanere non disponibile dopo un evento imprevisto.
Obiettivo del punto di ripristino (RPO)	Durata massima accettabile della perdita di dati durante un evento imprevisto.

Definire i valori di destinazione del carico di lavoro per queste metriche nel contesto dei flussi utente e dei flussi di sistema. Identificare e assegnare punteggi ai flussi in base alla loro criticità. Usare i valori per guidare la progettazione del carico di lavoro in termini di architettura, revisione, test e operazioni di gestione degli eventi imprevisti. Il mancato rispetto degli obiettivi influirà sull'azienda oltre il livello di tolleranza.

Strategie di progettazione chiave

Le discussioni tecniche non dovrebbero guidare la definizione degli obiettivi di affidabilità per i flussi critici. Al contrario, gli stakeholder aziendali devono concentrarsi sui clienti quando definiscono i requisiti di un carico di lavoro. Gli esperti tecnici consentono agli stakeholder di assegnare valori numerici realistici correlati a tali requisiti. Mentre condividono conoscenze, gli esperti tecnici consentono la negoziazione e il consenso reciproco sui contratti di servizio realistici.

Si consideri un esempio di come eseguire il mapping dei requisiti ai valori numerici misurabili. Gli stakeholder stimano che per un flusso utente critico, un'ora di inattività durante l'orario di ufficio regolare comporta una perdita di X dollari in ricavi mensili. Tale importo in dollari viene confrontato con il costo stimato di progettazione di un flusso con un valore SLO di disponibilità pari al 99,95% anziché al 99,9%. I decisori devono discutere se il rischio di perdita di ricavi supera i costi aggiuntivi e il carico di gestione necessario per proteggerlo. Seguire questo modello mentre si esaminano i flussi e si compila un elenco completo di destinazioni.

Tenere presente che gli obiettivi di affidabilità differiscono dagli obiettivi di prestazioni. Gli obiettivi di affidabilità sono incentrati sulla disponibilità e sul ripristino. Per impostare gli obiettivi di affidabilità, iniziare definendo i requisiti più ampi e quindi definire metriche più specifiche per soddisfare i requisiti di alto livello.

I requisiti di affidabilità e ripristino più elevati e le metriche correlate possono includere, ad esempio, una disponibilità dell'applicazione del 99,9% per tutte le aree o un RTO di destinazione di 5 ore per l'area Americas. La definizione di questi tipi di destinazioni consente di identificare quali flussi critici sono coinvolti in tali destinazioni. È quindi possibile considerare le destinazioni a livello di componente.

Compromesso: potrebbe esistere un divario concettuale tra le limitazioni tecniche dei componenti del carico di lavoro e ciò che significa per l'azienda, ad esempio la velocità effettiva in megabit al secondo rispetto alle transazioni al secondo. La creazione di un modello tra queste due visualizzazioni potrebbe risultare complessa. Invece di sovraprogegnere la soluzione, provare ad avvicinarla in modo economico ma significativo.

Metriche di disponibilità

Contratti di servizio e contratti di servizio

Le metriche di disponibilità sono correlate ai contratti di servizio usati per definire i contratti di servizio. L'SLO del carico di lavoro determina la quantità di tempo di inattività tollerabile in un determinato periodo, ad esempio meno di 1 ora al mese. Per assicurarsi di poter soddisfare la destinazione SLO, esaminare i contratti di servizio Microsoft per ogni componente. Prestare attenzione alla ridondanza necessaria per soddisfare contratti di servizio elevati. Ad esempio, Microsoft garantisce contratti di servizio più elevati per le distribuzioni in più aree di Azure Cosmos DB rispetto a quanto garantisce per le distribuzioni a singola area.

Nota

I contratti di servizio di Azure non coprono sempre tutti gli aspetti di un servizio. Ad esempio, gateway applicazione di Azure ha un contratto di servizio di disponibilità, ma la funzionalità di Web application firewall di Azure non garantisce che il traffico dannoso passi attraverso. Prendere in considerazione questa limitazione quando si sviluppano contratti di servizio e contratti di servizio.

Dopo aver raccolto i contratti di servizio per i singoli componenti del carico di lavoro, calcolare un contratto di servizio composito. Il contratto di servizio composito deve corrispondere all'SLO di destinazione del carico di lavoro. Il calcolo di un contratto di servizio composito comporta diversi fattori, a seconda della progettazione dell'architettura. Si considerino gli esempi seguenti.

Nota

I valori del contratto di servizio negli esempi seguenti sono ipotetici e sono solo a scopo dimostrativo.Non sono progettati per rappresentare i valori correnti supportati da Microsoft.

I contratti di servizio compositi prevedono più servizi che supportano un'applicazione, con livelli di disponibilità diversi. Si consideri ad esempio un'app Web Servizio app di Azure che scrive in Azure SQL Database. Ipoteticamente, questi contratti di servizio potrebbero essere:

• servizio app app Web = 99,95%
• database SQL = 99,99%

Qual è il tempo di inattività massimo previsto per questa applicazione? Se il servizio presenta errori, di conseguenza l'intera applicazione presenterà errori. La probabilità che ogni servizio non riesca sia indipendente, quindi il contratto di servizio composito per questa applicazione è del 99,95% × 99,99% = 99,94%. Tale valore è inferiore ai singoli contratti di servizio. Questa conclusione non è sorprendente perché un'applicazione che si basa su più servizi ha più potenziali punti di errore.

È possibile migliorare il contratto di servizio composito creando percorsi di fallback indipendenti. Ad esempio, se il database SQL non è disponibile, inserire le transazioni in una coda, in modo tale che vengano elaborate successivamente:

In questa progettazione l'applicazione è ancora disponibile anche se non riesce a connettersi al database. Tuttavia, ha esito negativo se il database e la coda hanno esito negativo contemporaneamente. La percentuale di tempo prevista per un errore simultaneo è 0,0001 × 0,001, quindi ecco il contratto di servizio composito per questo percorso combinato:

Database o coda = 1,0 − (0,0001 × 0,001) = 99,99999%

Contratto di servizio composito totale:

App Web e (database o coda) = 99,95% × 99,99999% = ~99,95%

Questo approccio pone compromessi:

• La logica dell'applicazione è più complessa.
• Si paga per la coda.
• È necessario considerare i problemi di coerenza dei dati.

Per le distribuzioni in più aree, il contratto di servizio composito viene calcolato come segue:

• N è il contratto di servizio composito per l'applicazione distribuita in un'area.

• R è il numero di aree in cui viene distribuita l'applicazione.

La probabilità prevista che l'applicazione si interrompa contemporaneamente in tutte le aree è data dalla formula ((1 - N) ^ R). Ad esempio, se il contratto di servizio ipotetico a singola area è pari al 99,95%:

• Contratto di servizio combinato per due aree = (1 − (1 − 0,9995) ^ 2) = 99,999975%

• Contratto di servizio combinato per quattro aree = (1 − (1 − 0,9995) ^ 4) = 99,999999%

La definizione di contratti di servizio appropriati richiede tempo e attenzione. Gli stakeholder aziendali devono comprendere in che modo i clienti chiave usano l'app. Devono anche comprendere la tolleranza all'affidabilità. Questo feedback deve informare le destinazioni.

Valori del contratto di servizio

La tabella seguente definisce i valori comuni del contratto di servizio.

Contratto di servizio	Tempo di inattività settimanale	Tempo di inattività mensile	Tempo di inattività annuale
99%	1,68 ore	7,2 ore	3,65 giorni
99,9%	10,1 minuti	43,2 minuti	8,76 ore
99,95%	5 minuti	21,6 minuti	4,38 ore
99,99%	1,01 minuti	4,32 minuti	52,56 minuti
99,999%	6 secondi	25,9 secondi	5,26 minuti

Quando si pensa ai contratti di servizio compositi nel contesto dei flussi, tenere presente che i diversi flussi hanno definizioni di criticità diverse. Prendere in considerazione queste differenze quando si compilano i contratti di servizio compositi. I flussi non critici potrebbero avere componenti che è necessario omettere dai calcoli perché non influiscono sull'esperienza del cliente se sono brevemente non disponibili.

Nota

I carichi di lavoro per i clienti e i carichi di lavoro interni hanno contratti di servizio diversi. In genere, i carichi di lavoro con uso interno possono avere contratti di servizio di disponibilità molto meno restrittivi rispetto ai carichi di lavoro rivolti ai clienti.

Contratti di servizio

Si pensi ai contratti di servizio come metriche a livello di componente che contribuiscono a un SLO. I contratti di servizio più significativi sono quelli che influiscono sui flussi critici dal punto di vista dei clienti. Per molti flussi, i contratti di servizio includono latenza, velocità effettiva, frequenza di errore e disponibilità. Un buon SLI consente di identificare quando un SLO è a rischio di violazione. Correlare l'SLI a clienti specifici, quando possibile.

Per evitare di raccogliere metriche inutili, limitare il numero di contratti di servizio per ogni flusso. Se possibile, mirare a tre contratti di servizio per flusso.

Metriche di ripristino

Le destinazioni di ripristino corrispondono alle metriche RTO, RPO, MTTR e MTBF. A differenza degli obiettivi di disponibilità, gli obiettivi di ripristino per queste misurazioni non dipendono in larga misura dai contratti di servizio Microsoft. Microsoft pubblica RTO e RPO garantisce solo per alcuni prodotti, ad esempio database SQL.

Le definizioni per destinazioni di ripristino realistiche si basano sull'analisi della modalità di errore e sui piani e sui test per la continuità aziendale e il ripristino di emergenza. Prima di completare questo lavoro, discutere gli obiettivi aspirazioni con gli stakeholder e assicurarsi che la progettazione dell'architettura supporti gli obiettivi di ripristino al meglio della comprensione. Comunicare chiaramente agli stakeholder che tutti i flussi o interi carichi di lavoro che non sono stati testati accuratamente per le metriche di ripristino non devono avere contratti di servizio garantiti. Assicurarsi che gli stakeholder comprendano che le destinazioni di ripristino possono cambiare nel tempo man mano che i carichi di lavoro vengono aggiornati. Il carico di lavoro può diventare più complesso man mano che i clienti vengono aggiunti o quando si adottano nuove tecnologie per migliorare l'esperienza dei clienti. Queste modifiche possono aumentare o diminuire le metriche di ripristino.

Nota

MOUNTAINF può essere difficile da definire e garantire. Le piattaforme distribuita come servizio (PaaS) o software come servizio (SaaS) possono avere esito negativo e ripristinare senza alcuna notifica dal provider di servizi cloud e il processo può essere completamente trasparente per l'utente o i clienti. Se si definiscono le destinazioni per questa metrica, coprire solo i componenti sotto il controllo.

Quando si definiscono le destinazioni di ripristino, definire le soglie per l'avvio di un ripristino. Ad esempio, se un nodo Web non è disponibile per più di 5 minuti, un nuovo nodo viene aggiunto automaticamente al pool. Definire le soglie per tutti i componenti, considerando il ripristino per un componente specifico, incluso l'effetto su altri componenti e dipendenze. Le soglie devono anche tenere conto degli errori temporanei per assicurarsi di non avviare le azioni di ripristino troppo rapidamente. Documentare e condividere con gli stakeholder i potenziali rischi delle operazioni di ripristino, ad esempio la perdita di dati o le interruzioni di sessione per i clienti.

Creazione di un modello di integrità

Usare i dati raccolti per le destinazioni di affidabilità per creare il modello di integrità per ogni carico di lavoro e i flussi critici associati. Un modello di integrità definisce stati integri, degradati e non integri per i flussi e i carichi di lavoro. Gli stati garantiscono la priorità operativa appropriata. Questo modello è noto anche come modello di semaforo del traffico. Il modello assegna il verde per integrità, giallo per degradato e rosso per l'integrità. Un modello di integrità garantisce che si sappia quando lo stato di un flusso passa da integro a danneggiato o non integro.

Il modo in cui si definiscono stati integri, degradati e non integri dipende dalle destinazioni di affidabilità. Ecco alcuni esempi di modi per definire gli stati:

• Uno stato verde o integro indica che i requisiti e le destinazioni chiave non funzionali sono completamente soddisfatti e che le risorse vengono usate in modo ottimale. Ad esempio, il 95% delle richieste viene elaborato in <=500 ms con il nodo servizio Azure Kubernetes (servizio Azure Kubernetes) usato in percentuale X.

• Uno stato giallo o danneggiato indica che uno o più componenti del flusso segnalano la soglia definita, ma il flusso è operativo. Ad esempio, è stata rilevata la limitazione delle risorse di archiviazione.

• Uno stato rosso o non integro indica che la riduzione delle prestazioni è persistente più lunga del consentito dalle destinazioni di affidabilità o che il flusso non è più disponibile.

Nota

Il modello di integrità non deve trattare tutti gli errori uguali. Il modello di integrità deve distinguere tra errori temporanei e non transazioni. Deve distinguere chiaramente tra errori temporanei previsti ma ripristinabili e uno stato di emergenza effettivo.

Questo modello funziona usando una strategia di monitoraggio e avviso sviluppata e gestita sui principi del miglioramento continuo. Man mano che i carichi di lavoro si evolvono, i modelli di integrità devono evolversi con essi.

Per considerazioni dettagliate sulla progettazione e raccomandazioni per un modello di integrità delle applicazioni a più livelli, vedere le linee guida per la modellazione dell'integrità disponibili nelle aree di progettazione dei carichi di lavoro cruciali. Per indicazioni dettagliate sul monitoraggio e sulla configurazione degli avvisi, vedere la guida al monitoraggio dell'integrità .

Visualizzazione

Per mantenere informati i team operativi e gli stakeholder del carico di lavoro sullo stato in tempo reale e sulle tendenze complessive del modello di integrità del carico di lavoro, è consigliabile creare dashboard nella soluzione di monitoraggio. Discutere delle soluzioni di visualizzazione con gli stakeholder per assicurarsi di fornire le informazioni che hanno valore ed è facile da usare. Possono anche voler visualizzare report generati settimanalmente, mensilmente o trimestrali.

Facilitazione di Azure

I contratti di servizio di Azure forniscono gli impegni Microsoft per il tempo di attività e la connettività. I diversi servizi hanno contratti di servizio diversi e talvolta SKU all'interno di un servizio hanno contratti di servizio diversi. Per altre informazioni, vedere Contratti a livello di servizio per Servizi online.

Il contratto di servizio di Azure include procedure per ottenere un credito di servizio se il contratto di servizio non viene soddisfatto, insieme alle definizioni di disponibilità per ogni servizio. Questo aspetto del contratto di servizio funge da criterio di imposizione.

Collegamenti correlati

• Well-Architected Framework linee guida cruciali per la modellazione dell'integrità: modellazione dell'integrità e osservabilità dei carichi di lavoro cruciali in Azure

Elenco di controllo affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo affidabilità