Raccomandazioni per la definizione degli obiettivi di affidabilità

Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:

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à vengono ottenuti derivati tramite esercizi di workshop con gli stakeholder aziendali. Gli obiettivi vengono perfezionati mediante monitoraggio e test.

Con gli stakeholder interni, stabilire aspettative realistiche in merito all'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.

Prendere in considerazione l'uso delle metriche seguenti per quantificare i requisiti aziendali.

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 un punteggio ai flussi in base al livello di criticità dei requisiti. 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. Gli stakeholder aziendali devono invece concentrarsi sui clienti quando definiscono i requisiti di un carico di lavoro. Gli esperti tecnici aiutano gli stakeholder ad 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 dollaro viene confrontato con il costo stimato di progettazione di un flusso con un SLO di disponibilità pari al 99,95% anziché al 99,9%. I decision maker devono discutere se il rischio di tale perdita di ricavi supera i costi aggiuntivi e il carico di gestione necessari 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 il 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 di livello più elevato e le metriche correlate possono includere, ad esempio, una disponibilità dell'applicazione del 99,9% per tutte le aree o un obiettivo RTO 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 sovraccaricare la soluzione, provare ad avvicinarla in modo economico ma significativo.

Metriche di disponibilità

Contratti di servizio e contratti di servizio

Uno SLO è una misura delle prestazioni e dell'affidabilità di un carico di lavoro o di un'applicazione. Uno SLO è una destinazione specifica e misurabile impostata per interazioni specifiche con i clienti. Si tratta di una destinazione impostata per il carico di lavoro o l'applicazione sulla qualità del servizio che gli utenti dovrebbero ricevere.

Un SLO può essere definito in termini di un'ampia gamma di metriche, ad esempio disponibilità, tempo di risposta, velocità effettiva, frequenza di successo e altri. Ad esempio, un SLO per un servizio Web potrebbe essere che sarà disponibile per gli utenti il 99,9% del tempo in un determinato mese o che risponderà al 95% delle richieste entro 500 millisecondi.

Prima di definire i contratti di servizio per l'applicazione o il carico di lavoro, esaminare i contratti di servizio pubblicati da Microsoft per i servizi sottostanti in cui è ospitata l'applicazione o il carico di lavoro.

Quando si esamina il contratto di servizio per ogni servizio, 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.

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 allo 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.

I contratti di servizio compositi prevedono più servizi che supportano un'applicazione, con livelli di disponibilità diversi. Si consideri, ad esempio, un'app Web del servizio app Azure che scrive in database SQL di Azure. 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 come i clienti chiave usano l'app. Devono anche comprendere la tolleranza all'affidabilità. Questo feedback dovrebbe informare le destinazioni.

Valori del contratto di servizio

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

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 creano contratti di servizio compositi. I flussi non critici potrebbero avere componenti da omettere dai calcoli perché non influiscono sull'esperienza del cliente se sono brevemente non disponibili.

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 degli errori 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. Obiettivo di tre contratti di servizio per flusso, se possibile.

Metriche di ripristino

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

Le definizioni per obiettivi di ripristino realistici 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 non testati accuratamente per le metriche di ripristino non dovrebbero 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 ridurre le metriche di ripristino.

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 per le 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 verde per integro, giallo per degradato e rosso per il non integro. Un modello di integrità garantisce che si sappia quando lo stato di un flusso passa da integro a danneggiato o non integro.

La modalità di definizione di 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 al 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 dell'archiviazione.

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

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 consigli per un modello di integrità delle applicazioni a più livelli, vedere le linee guida per la modellazione dell'integrità disponibili nelle aree di progettazione del carico di lavoro cruciali. Per indicazioni dettagliate sul monitoraggio e sulle configurazioni 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 le soluzioni di visualizzazione con gli stakeholder per assicurarsi di fornire le informazioni che hanno valore e che sia facile da usare. Possono anche voler visualizzare i report generati ogni settimana, mensile o trimestrale.

Facilitazione di Azure

I contratti di servizio di Azure forniscono gli impegni Microsoft per il tempo di attività e la connettività. 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 di servizio per Servizi online.

Il contratto di servizio di Azure include procedure per ottenere un credito del 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

• Linee guida cruciali per il framework ben progettato per la modellazione dell'integrità: modellazione dell'integrità e osservabilità dei carichi di lavoro cruciali in Azure

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.