Elementi consigliati per la definizione degli obiettivi di affidabilità
Si applica a questa raccomandazione dell'elenco di controllo di affidabilità Well-Architected Power Platform:
| RE:04 | Definisci gli obiettivi di affidabilità e ripristino per i componenti, i flussi e la soluzione complessiva. Visualizza gli obiettivi per negoziare, ottenere consenso, definire aspettative e guidare le azioni per raggiungere lo stato ideale. Utilizza gli obiettivi definiti per creare il modello di integrità. Il modello di integrità definisce come appaiono gli stati integro, degradato e non integro. |
|---|
Questa guida descrive gli elementi consigliati per definire le metriche di disponibilità e destinazione del ripristino per i carichi di lavoro critici. Gli obiettivi di affidabilità vengono ricavati attraverso esercitazioni di workshop con le parti interessate aziendali.
Gli obiettivi vengono migliorati attraverso il monitoraggio e i test. Collabora con i tuoi stakeholder interni per stabilire aspettative realistiche di affidabilità. Questo esercizio aiuterà inoltre le parti interessate a supportare le tue scelte di progettazione architettonica e a comprendere che stai progettando per raggiungere al meglio gli obiettivi concordati.
Microsoft Power Platform gestisce la maggior parte dei problemi di disponibilità e affidabilità a livello di infrastruttura. Tuttavia, la disponibilità dei carichi di lavoro creati è una responsabilità condivisa. È importante capirlo anche con l'impegno per l'alta disponibilità di Microsoft, il rischio di tempi di inattività del sistema non è mai pari a zero.
È 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 del livello di servizio (SLI) | Metrica generata da un servizio. Le metriche SLI vengono aggregate per quantificare un valore SLO. |
| Contratto di servizio | Accordo contrattuale tra il provider di servizi e il cliente del servizio. Il contratto definisce gli SLO. 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 un punteggio a tali flussiin base alla loro criticità. Usa 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.
Consideriamo 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.
Segui questo modello mentre esamini i flussi e compili un elenco completo di destinazioni.
Tieni 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à, inizia definendo i requisiti più ampi e quindi definisci 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 geografiche o un RTO di destinazione di 5 ore per l'area geografica delle Americhe. 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.
Metriche di disponibilità
Gli obiettivi di disponibilità corrispondono alle metriche SLO, SLA e SLI.
Obiettivi di livello 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.
Per stabilire gli obiettivi di livello di servizio:
Requisiti non funzionali del carico di lavoro (ad esempio, tassi di richiesta di punta, utenti simultanei) nei prossimi 1-2 anni.
Metriche disponibili su ciò che puoi misurare, in un periodo di tempo specifico. Questi dati informeranno quali SLI specificare.
Dopo aver raccolto i contratti di servizio per i singoli componenti del carico di lavoro, calcola contratto di servizio composito. Il contratto di servizio composito deve corrispondere alla destinazione dell'obiettivo di livello di servizio del carico di lavoro. Il calcolo di un contratto di servizio composito comporta diversi fattori, a seconda della progettazione dell'architettura.
La definizione di obiettivi di livello di servizio impiega tempo e un'attenta considerazione. Gli stakeholder aziendali dovrebbero 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.
| SLA | 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 pensi ai contratti di servizio compositi nel contesto dei flussi, tieni presente che i diversi flussi hanno definizioni di criticità diverse. Considera queste differenze quando crei i tuoi 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.
SLI
Pensa agli SLI come a parametri a livello di componente che contribuiscono a un obiettivo di livello di servizio. Gli SLI più significativi sono quelli che influenzano i flussi critici dal punto di vista dei clienti. Per molti flussi, gli SLI includono latenza, velocità effettiva, tasso di errore e disponibilità. Un buon SLI consente di identificare quando un SLO è a rischio di violazione. Correlare lo SLI a clienti specifici quando possibile.
Per evitare di raccogliere parametri inutili, limita il numero di SLI per ciascun flusso. Se possibile, punta a tre SLI per flusso.
Metriche di ripristino
Le destinazioni di ripristino corrispondono alle metriche RTO, RPO, MTTR e MTBF. Al contrario delle destinazioni di disponibilità, le destinazioni di ripristino per queste misurazioni non dipendono fortemente dai contratti di servizio Microsoft. Microsoft pubblica RTO e RPO solo per alcuni prodotti, ad esempio Database SQL.
Le definizioni per le 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, discuti obiettivi aspirazioni con gli stakeholder e assicurati che la progettazione dell'architettura supporti gli obiettivi di ripristino al meglio della comprensione. Comunicare chiaramente agli stakeholder che qualsiasi flusso o intero carico di lavoro che non sia accuratamente testato per le metriche di ripristino non dovrebbe avere contratti di servizio garantiti. Assicurati che gli stakeholder comprendano che gli obiettivi 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 si adottano nuove tecnologie per migliorare l'esperienza dell'utente. Queste modifiche possono aumentare o ridurre le metriche di ripristino.
Nota
MTBF può essere difficile da definire e garantire. Le piattaforme come servizio (PaaS) o software come servizio (SaaS) possono avere esito negativo e ripristinare senza alcuna notifica dal provider cloud e il processo può essere completamente trasparente per l'utente o i clienti. Se definisci le destinazioni per questa metrica, copri solo i componenti che sono sotto il controllo.
Generazione di un modello di integrità
Utilizza i dati raccolti per le destinazioni di affidabilità per creare il modello di integrità per ogni carico di lavoro e flussi critici associati. Un modello di integrità definisce gli stati integro, degradato e non integro* per i flussi e i carichi di lavoro. Gli stati garantiscono la priorità operativa appropriata. Questo modello è noto anche come modello a semaforo. Il modello assegna il colore verde per integro, giallo per degradato e rosso per non integro Un modello di integrità garantisce che lo stato di un flusso cambi da integro a danneggiato o non integro.
La 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 sano indica che i requisiti non funzionali chiave e le destinazioni sono completamente soddisfatti e che le risorse vengono usate in modo ottimale.
Uno stato giallo o degradato indica che uno o più componenti del flusso stanno avvisando 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 il degrado è stato persistente più lungo di quanto consentito dalle destinazioni di affidabilità o che il flusso non sia stato disponibile.
Nota
Il modello di integrità non deve trattare tutti gli errori uguali. Il modello di integrità deve distinguere tra errori temporanei enontransienti. 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 di miglioramento continuo. Man mano che i carichi di lavoro si evolvono, i modelli di integrità devono evolversi con loro.
Per indicazioni dettagliate sul monitoraggio e sulle configurazioni degli avvisi, vedi la guida al Monitoraggio dello stato.
Visualizzazione
Per mantenere i team operativi e gli stakeholder del carico di lavoro informati sullo stato in tempo reale e sulle tendenze complessive del modello di integrità del carico di lavoro, prendere in considerazione la creazione di dashboard nella soluzione di monitoraggio. Discuti le soluzioni di visualizzazione con gli stakeholder per garantire che le informazioni che siano di valore e che siano facili da usare. Potrebbero anche voler visualizzare report generati settimanalmente, mensilmente o trimestralmente.
Facilitazione di Power Platform
I contratti di servizio di Power Platform forniscono gli impegni di Microsoft in termini di tempo di attività e connettività. Servizi diversi hanno contratti di servizio diversi e talvolta gli SKU in un servizio hanno contratti di servizio diversi. Per ulteriori informazioni, vedi Contratti di servizio per servizi online.
Il contratto di servizio di Power Platform include le procedure per ottenere un credito di servizio se il contratto di servizio non viene soddisfatto, insieme alle definizioni di disponibilità per ciascun servizio. Questo aspetto del contratto di servizio funge da criteri di applicazione.
Microsoft Business Applications fornisce funzionalità di continuità aziendale e ripristino di emergenza (BCDR) a tutti gli ambienti di tipo di produzione in Dynamics 365 e alle applicazioni Power Platform SaaS. Scopri come Microsoft garantisce la resilienza dei tuoi dati di produzione durante le interruzioni regionali.
Allineamento organizzativo
Cloud Adoption Framework fornisce indicazioni per elementi consigliati per gli obiettivi di livello di servizio e gli SLI relativi al monitoraggio all'interno dell'organizzazione.
Per ulteriori informazioni, vedi Obiettivi di livello di servizio del monitoraggio cloud.
Elenco di controllo per l'affidabilità
Fai riferimento alla serie completa di elementi consigliati.