Raccomandazioni per la definizione degli obiettivi di affidabilità
Si applica alla seguente raccomandazione della check-list di Affidabilità del framework Azure Well-Architected:
| RE:04 | Definire obiettivi di affidabilità e ripristino per il carico di lavoro. Usare gli obiettivi per informare la progettazione e come base del modello di salute. |
|---|
Questa guida descrive le raccomandazioni per la definizione delle metriche di destinazione di disponibilità e ripristino per carichi di lavoro e flussi critici. È consigliabile derivare obiettivi di affidabilità dagli esercizi di workshop con gli stakeholder aziendali. Quindi perfeziona tali obiettivi monitorando e testando i carichi di lavoro.
Impostare aspettative realistiche con gli stakeholder interni sull'affidabilità del carico di lavoro. Possono quindi usare contratti contrattuali per comunicare tali aspettative ai clienti. Le aspettative realistiche consentono anche agli stakeholder di comprendere e supportare le decisioni di progettazione dell'architettura e di sapere che si sta progettando per soddisfare in modo ottimale gli obiettivi concordati.
Valutare la possibilità di usare le metriche seguenti per quantificare i requisiti aziendali.
| Termine | Definizione |
|---|---|
| Obiettivo del livello di servizio (SLO) | 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 in base alla qualità del servizio che i clienti si aspettano di ricevere. |
| Indicatore a livello di servizio (SLI) | Misurazione quantitativa di un particolare aspetto delle prestazioni di un servizio. È possibile usare un SLI per misurare la conformità del carico di lavoro a un SLO. |
| Contratto di servizio | Contratto contrattuale tra il provider di servizi e il cliente del servizio. Il mancato rispetto del contratto potrebbe avere conseguenze finanziarie per il provider di servizi. |
| Tempo medio di recupero (MTTR) | Tempo impiegato per ripristinare un componente dopo il rilevamento di un errore. |
| Tempo medio tra i guasti (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. |
Strategie di progettazione chiave
Gli obiettivi di affidabilità rappresentano l'obiettivo di qualità desiderato di un carico di lavoro, come promesso agli utenti e agli stakeholder aziendali. Questo obiettivo include sia la disponibilità che la recuperabilità del carico di lavoro. Tenere presente che gli obiettivi di affidabilità differiscono dagli obiettivi di prestazioni, ma è consigliabile includere obiettivi di prestazioni negli obiettivi di affidabilità. Considerare gli obiettivi di affidabilità seguenti:
Gli obiettivi di disponibilità definiscono gli standard di qualità per un sistema in modo che rimangano accessibili e funzionali. Se non soddisfa questi standard, il sistema viene considerato inaffidabile. Usare gli SLOs per verificare se il sistema soddisfa questi standard. Gli stakeholder aziendali e tecnici collaborano per impostare contratti di servizio realistici e prendere in considerazione fattori come l'analisi comparativa, l'esperienza utente e il profilo del carico di lavoro.
Gli obiettivi di correttezza assicurano che il workload esegua correttamente le sue funzioni con una qualità coerente. Per misurare la correttezza, quantificare gli indicatori del carico di lavoro in modo da poterli combinare in un punteggio obiettivo unificato.
Gli obiettivi di ripristino corrispondono alle metriche RTO, RPO, MTTR e MOUNTAINF, che quantificano l'efficacia dei piani e dei test per la continuità aziendale e il ripristino di emergenza.
Per impostare obiettivi di affidabilità, gli stakeholder aziendali definiscono requisiti generali. Quindi, gli esperti tecnici valutano lo stato corrente del carico di lavoro e lavorano per raggiungere e mantenere gli obiettivi attraverso il monitoraggio e gli avvisi. Entrambe le parti devono concordare obiettivi realistici.
Identificare e assegnare punteggi ai flussi utente e di sistema in base alla loro importanza per i requisiti aziendali. Usare questi punteggi per guidare la progettazione, la revisione, il test e la gestione degli eventi imprevisti del carico di lavoro. Impostare obiettivi di affidabilità per questi flussi e comprendere che il mancato rispetto di tali obiettivi può influire significativamente sull'azienda.
Compromesso: è possibile che si verifichi un divario tra i limiti tecnici del sistema e l'impatto aziendale, ad esempio la velocità effettiva rispetto alle transazioni al secondo. Colmare questo divario può essere difficile. Puntare a una soluzione pratica ed economica invece di eccedere in ingegneria.
Impostare gli obiettivi di disponibilità
L'SLO complessivo di un carico di lavoro riflette la qualità olistica, incluse tutte le relative dipendenze. Una dichiarazione matura dell'SLO deve indicare la destinazione aziendale complessiva per tale carico di lavoro, non solo una composizione di tali dipendenze. Ad esempio, se i clienti prevedono una disponibilità del 99,99%, lo SLO complessivo dovrebbe mirare a tale obiettivo, anche se una parte raggiunge solo il 99,80%.
Gli stakeholder valutano l'esperienza del cliente e valutano il modo in cui il tempo di inattività influisce sui ricavi. Confrontano questa perdita con il costo di progettazione e gestione del flusso aziendale. I decision maker decidono quindi se devono spendere più denaro sull'affidabilità per evitare perdite di ricavi e mantenere la loro reputazione.
I proprietari del carico di lavoro usano gli obiettivi finanziari per determinare gli obiettivi. I requisiti aziendali sono mappati alle metriche misurabili. L'obiettivo è identificare un set di fattori che influenzano la qualità dell'esperienza del cliente.
Gli architetti dei carichi di lavoro prendono molte decisioni tecniche in base agli SLO. Gli SLO possono:
Fungere da input critico nelle decisioni relative all'architettura quando si considerano altre dipendenze.
Fornire una visione quasi in tempo reale e una comprensione condivisa dello stato di salute di un carico di lavoro per favorire discussioni obiettive. Consentono inoltre al team del carico di lavoro di assegnare priorità agli sforzi per migliorare l'affidabilità e sviluppare nuove funzionalità.
Fungere da segnale principale per le operazioni di distribuzione, che determina il rollback automatico in caso di problemi e fornisce la convalida che le modifiche ottengono i miglioramenti previsti all'esperienza del cliente.
Velocizzare la correzione e il ripristino concentrandosi sugli obiettivi, guidare la notifica automatizzata dei problemi ai clienti e creare fiducia tra i team dell'organizzazione.
Importante
È necessario conoscere la differenza tra Accordi sul Livello di Servizio e Obiettivi sul Livello di Servizio. Anche se i contratti di servizio (SLA) e gli obiettivi di livello di servizio (SLO) possono usare o persino presentare dati simili, la loro finalità è diversa. Un contratto di servizio è un contratto formale tra un'organizzazione e i suoi clienti e ha implicazioni finanziarie e legali dirette se l'organizzazione non riesce a mantenere la promessa. Le organizzazioni usano gli SLO per valutare se il potenziale tempo di inattività rientra nei limiti tollerabili.
Gli SLO e gli SLA condividono una relazione aziendale e dovrebbero essere gestiti indipendentemente. Se il contratto di servizio funge da tattica aziendale, l'organizzazione potrebbe impostarla intenzionalmente su un valore elevato in base agli obiettivi del proprietario dell'azienda. Viceversa, gli obiettivi di livello di servizio possono essere superiori. Si considerino carichi di lavoro cruciali come esempio. Questa classe di carico di lavoro non può permettersi tempi di inattività lunghi perché gli effetti, incluse le perdite finanziarie e persino le minacce alla sicurezza umana, sono significativi. Pertanto, gli obiettivi di livello di servizio (SLO) hanno in genere come obiettivo il 99,999% del tempo di attività, comunemente indicato come i cinque nove. Se i contratti di servizio non soddisfano tali obiettivi, le organizzazioni devono reagire rapidamente per attenuare gli errori e prevenire i risultati di un contratto di servizio non riuscito.
L'esempio in questo articolo imposta un Accordo sul Livello di Servizio elevato per supportare gli obiettivi aziendali.
I provider di piattaforme cloud e tecnologie pubblicano contratti di servizio nelle offerte. È consigliabile considerare i contratti di servizio come parte del calcolo SLO, ma non è consigliabile usarli così come è senza comprendere l'ambito di copertura del contratto di servizio. Per altre informazioni, vedere Valutare l'impatto dei contratti di servizio Microsoft.
Considerare gli SLO comuni e i fattori che li influenzano
Ogni SLO mira a un criterio di qualità specifico. Considerare questi contratti di servizio comuni per l'affidabilità. Questo elenco non è esaustivo. Aggiungi SLO sulla base dei requisiti aziendali.
La percentuale di successo misura l'esito positivo delle richieste e dei processi rispetto a quelli che restituiscono un errore o non riescono a eseguire l'attività.
La latenza misura il tempo tra l'avvio di una richiesta per un'operazione e la disponibilità del risultato o il completamento del processo.
La capacità misura l'utilizzo simultaneo, ad esempio il numero di risposte basate sul throttling.
La disponibilità misura la disponibilità operativa dal punto di vista dei clienti.
La velocità effettiva misura la velocità di trasferimento dei dati minima durante un determinato periodo di tempo. La velocità effettiva viene misurata come unità di frequenza dei dati, ad esempio transazioni al secondo (TPS) o richieste al secondo (RPS).
Comprendere gli scenari e le tolleranze per il carico di lavoro in Azure. Sia i servizi di Azure che i componenti dell'applicazione influiscono sull'SLO del carico di lavoro. Combinare le risposte dalla tabella seguente per derivare l'SLO complessivo. Usare queste domande come esempi per valutare l'utilità del componente del carico di lavoro.
| Caratteristiche dei componenti | Interazione del cliente | Altri fattori |
|---|---|---|
| - Espone le API di richiesta o risposta? Ha le API di query? - Si tratta di un componente di calcolo ? - È un componente di elaborazione di lavoro? |
-
Piano di controllo e accesso al piano di gestione per i servizi di Azure pubblici. - Accesso al livello dati, ad esempio operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD). |
- Il tuo processo di rilascio comporta tempi di inattività? - Qual è la probabilità di introdurre bug? Se il carico di lavoro si integra con altri sistemi, potrebbe essere necessario prendere in considerazione i bug di integrazione. - In che modo le operazioni di routine come l'applicazione di patch influiscono sulla destinazione di disponibilità? Hai tenuto in considerazione le dipendenze del partner? - Il tuo personale è sufficiente per supportare una rotazione costante delle chiamate di emergenza e del servizio di backup di emergenza? - L'applicazione ha vicini rumorosi al di fuori dell'ambito di controllo che può potenzialmente causare interruzioni? |
Determinare l'ambito SLO
È possibile impostare gli SLO a vari livelli, ad esempio per ogni applicazione, carico di lavoro o un flusso specifico, nel tuo sistema. Impostare obiettivi di livello di servizio specifici per livello in modo da poter personalizzare gli SLOs in base all'importanza di ogni componente.
Nelle soluzioni SaaS (Software as a Service), misurare gli obiettivi di livello di servizio per cliente per ottimizzare l'esperienza di ciascun cliente. I clienti potrebbero avere risorse di infrastruttura diverse nei loro segmenti. In questi casi, un SLO a livello di sistema che aggrega tutte le risorse tra segmenti di clienti potrebbe non avere senso. Misura gli SLO che si allineano al contesto specifico di ogni cliente. Per ulteriori informazioni, vedere Modelli di affitto per una soluzione multitenant.
Definire obiettivi SLO compositi
Gli obiettivi di servizio devono essere misurabili e misurati nell'ambito di una finestra di osservabilità.
Gli obiettivi di servizio sono spesso percentuali come il 99,90%, ma possono anche essere dichiarazioni. Usare entrambi i metodi per ottenere un valore numerico che include tutti i fattori.
Un SLO è costituito da indicatori di livello di servizio misurabili che definiscono fattori accettabili. Gli SLI sono indicatori di livello di servizio con una soglia impostata che può generare un avviso. È possibile raccoglierli da una piattaforma o da un'applicazione. I diversi componenti emettono indicatori di livello di servizio pertinenti. Quando si scelgono gli indicatori di livello di servizio (SLIs), prendere in considerazione i fattori che influenzano l'SLO.
Ad esempio, per calcolare lo SLO per un flusso che usa una risposta e un'API di richiesta, misurare la latenza del server e il tempo di elaborazione delle richieste. La velocità effettiva e le percentuali di errore non si applicano ad ambienti di calcolo continui, ad esempio macchine virtuali (VM), set di scalabilità o Azure Batch.
Per l'accesso al piano di controllo, prendere in considerazione la frequenza di errore e la latenza per le risposte api e le operazioni a esecuzione prolungata, ad esempio la creazione di risorse. L'accesso al piano dati dipende dalle API usate, ognuna con i propri obiettivi SLO.
Un buon SLI segnala quando potresti superare un SLO. In genere viene misurato in percentili. Ecco alcuni percentili di uso comune e il tempo stimato di non conformità alla disponibilità prevista.
| Obiettivo | Non conformità per settimana | Non conformità al mese | Non conformità all'anno |
|---|---|---|---|
| 99% | 1,68 ore | 7 ore e 20 minuti | 3,65 giorni |
| 99,90% | 10,10 minuti | 43,20 minuti | 8,76 ore |
| 99,95% | 5 minuti | 21,60 minuti | 4,38 ore |
| 99,99% | 1,01 minuti | 4,32 minuti | 52,56 minuti |
| 99,999% | 6 secondi | 25,90 secondi | 5,26 minuti |
Importante
Un valore SLO composito è una distribuzione del prodotto dei fattori che contribuiscono.
Un esempio di SLO composito è pari al 99,95% × 99,99999% = ~99,95%.
Quando si creano SLO compositi per flussi diversi, considerate la loro criticità e rilevanza variabili. I flussi potrebbero avere componenti ritenuti non critici e omessi dai calcoli. È possibile giustificare l'omissione in base al fatto che la loro breve indisponibilità influisca sull'esperienza del cliente. In alcuni casi, un componente potrebbe non essere rilevante per il caso d'uso che si prende in considerazione per lo SLO. È possibile omettere anche questi componenti dal calcolo.
Lo stesso principio si applica alle operazioni. Alcune operazioni possono introdurre rischi o influire sull'SLO e altre sono insignificanti. La decisione deve essere esplicita e basata sul consenso.
Per un esempio illustrativo di come definire e misurare SLO e SLI, vedere la Sezione Esempio.
Valutare l'impatto dei contratti di servizio Microsoft
Un contratto di servizio Microsoft fornisce informazioni dettagliate sulla disponibilità delle aree di cui Microsoft si impegna a garantire la disponibilità. I contratti di servizio non garantiscono un'offerta nel suo complesso. Quando si valutano gli Accordi sul Livello di Servizio, è importante avere una buona conoscenza della copertura fornita intorno al percentile pubblicato.
Si consideri App Web, una funzionalità del servizio app Azure. La funzionalità viene considerata disponibile quando restituisce uno stato 200 OK in un determinato caso d'uso. All'interno di tale contesto e intervallo di tempo specifico, non copre una garanzia finanziariamente supportata sulla disponibilità di funzionalità come easy Auth o cambio di slot. È consigliabile considerare le aree che non sono menzionate esplicitamente nel contratto come disponibili secondo il miglior impegno possibile della piattaforma.
Pertanto, se il carico di lavoro si basa sugli slot di distribuzione, non è possibile derivare lo SLO esclusivamente dal contratto di servizio App Service. In qualità di team di gestione, è necessario gestire e prevedere la disponibilità operativa. Tuttavia, questa stima può essere incerta, motivo per cui il legamento stretto dell'SLO al contratto di servizio della piattaforma può essere problematico.
Si consideri un altro esempio. Se Frontdoor di Azure ha disponibilità del 99,99%, la progettazione deve rispettare criteri specifici pubblicati nel contratto. Ad esempio, il back-end deve includere l'archiviazione, è necessaria un'operazione GET in grado di recuperare un file di dimensioni di almeno 50 KB ed è necessario distribuire gli agenti in più posizioni in almeno cinque posizioni geograficamente diverse. Questo caso d'uso ristretto di Frontdoor di Azure non garantisce funzionalità come la memorizzazione nella cache, le regole di routing o un web application firewall. Questi aspetti non rientrano nell'ambito del contratto di servizio.
Implementare destinazioni multiregione
Dal punto di vista dell'affidabilità, la distribuzione di più aree è un'implementazione del principio di ridondanza. L'obiettivo è ridurre il rischio di interruzioni a livello di area o prestazioni ridotte. Questa strategia, se progettata correttamente, può migliorare gli obiettivi di livello di servizio perché aggiunge un'area secondaria a scopo di failover.
Esistono due casi d'uso principali:
Modello di disponibilità elevata, in cui si distribuisce un carico tra aree per una maggiore capacità. La disponibilità elevata non limita gli utenti del carico di lavoro a un'area e le prestazioni dell'intero sistema contribuiscono allo SLO.
Schema bulkhead, in cui si limitano i clienti a regioni specifiche. In questi casi, considerate le distribuzioni multiregionali come distribuzioni separate o unità in ogni area. Misurare la salute di ciascun francobollo separatamente, utilizzando gli SLIs appropriati per il carico di lavoro. Considera l'SLO del carico di lavoro complessivo in base allo stato di salute di ogni timbro. Se è possibile eseguire il failover tra timbri, l'SLO complessivo del carico di lavoro aumenta perché un errore in un timbro è recuperabile tramite un failover a un altro timbro.
Prestare attenzione a quanta ridondanza è necessaria per soddisfare gli elevati obiettivi del livello di servizio. Ad esempio, Microsoft garantisce contratti di servizio più elevati per le distribuzioni con più aree di Azure Cosmos DB rispetto a quanto garantisce per le distribuzioni a singola area.
Definire le metriche di ripristino
Le definizioni per obiettivi realistici di ripristino, come le metriche RTO, RPO, MTTR e MTBF, si basano sulla tua analisi della modalità di guasto e sui piani e test per la continuità aziendale e il recupero da disastri. Quando si definiscono queste destinazioni, tenere conto delle garanzie di ripristino fornite dalla piattaforma. Microsoft pubblica le garanzie RTO e RPO solo per alcuni prodotti, ad esempio database SQL di Azure.
Prima di completare questo lavoro, discuti degli obiettivi aspirazionali con gli stakeholder e assicurati che la progettazione dell'architettura supporti gli obiettivi di ripristino secondo la migliore delle tue conoscenze. 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 si aggiungono clienti o quando si adottano nuove tecnologie per migliorare l'esperienza dei clienti. Queste modifiche possono aumentare o ridurre le metriche di ripristino.
Nota
MTBF può essere difficile da definire e garantire. I modelli PaaS (Platform as a Service) o SaaS possono fallire ed essere ripristinati senza alcuna notifica dal provider cloud, e il processo può essere completamente trasparente per gli utenti o i clienti. Se definisci gli obiettivi per questa metrica, copri solo i componenti sotto il tuo controllo.
Quando si definiscono le destinazioni di ripristino, definire le soglie per avviare un ripristino. Ad esempio, se un nodo Web non è disponibile per più di cinque minuti, aggiungere automaticamente un nuovo nodo al pool. Definire le soglie per tutti i componenti e prendere in considerazione 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, ad esempio la perdita di dati o le interruzioni di sessione per i clienti, delle operazioni di ripristino.
Monitorare e visualizzare gli obiettivi
Usa i dati raccolti per i tuoi obiettivi di affidabilità per costruire il modello di salute 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. Quando lo stato cambia, il modello deve avvisare le parti responsabili. Per considerazioni dettagliate sulla progettazione e consigli, vedere Linee guida per la modellazione sanitaria.
Per mantenere informati i team operativi e gli stakeholder del carico di lavoro, creare una visualizzazione che rifletta lo stato in tempo reale e le tendenze complessive del modello di integrità del carico di lavoro. Illustrare le soluzioni di visualizzazione con gli stakeholder per garantire che vengano fornite informazioni utili e facili da usare. Possono anche voler visualizzare i report generati ogni settimana, mensile o trimestrale.
Facilitazione di Azure
Gli SLA di Azure forniscono gli impegni di Microsoft per la disponibilità operativa e la connettività. Diversi servizi hanno contratti di servizio diversi e a volte i prodotti 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 carico di lavoro non soddisfa il contratto di servizio, insieme alle definizioni di disponibilità per ogni servizio. Questo aspetto del contratto di servizio funge da politica di applicazione.
Esplora i dashboard di Azure Monitor per il sistema di visualizzazione.
Esempio
Contoso, Ltd. sta progettando una nuova esperienza mobile per il sistema di ticket di eventi. Ecco l'architettura di alto livello.
Il logo di Grafana è un marchio della rispettiva azienda. Nessuna verifica dell'autenticità è implicita nell'uso di questo marchio.
Componenti
Ecco alcuni componenti che illustrano il concetto di definizione SLO. In questa architettura sono presenti componenti che non sono inclusi nell'elenco seguente. Ad esempio, anche se Key Vault fa parte del flusso di richiesta critico, non fa parte del caso d'uso della risposta. Se Key Vault non è disponibile, l'applicazione continua a funzionare usando i segreti caricati durante l'avvio. Tuttavia, se l'applicazione deve essere ridimensionata, la disponibilità di Key Vault diventa fondamentale perché i nuovi nodi devono essere caricati con segreti. In questo esempio le operazioni di ridimensionamento non vengono considerate. Altri componenti vengono omessi per brevità.
Frontdoor di Azure è il singolo punto di ingresso che espone un'API usata dai clienti per inviare richieste.
Azure Container Apps è l'ambiente di cui il team del carico di lavoro è proprietario e che utilizza per eseguire la logica aziendale per l'applicazione.
Istanza gestita di SQL è di proprietà e gestita da un altro team ed è una dipendenza critica del carico di lavoro.
Azure Private Link offre connettività privata tra Azure Front Door e distribuzioni di Container Apps. L'istanza gestita di SQL è esposta all'applicazione anche tramite un endpoint privato.
In questa architettura, il team api definisce una destinazione SLO iniziale per i flussi critici nell'applicazione. Adottano la strategia descritta in Fattori che influenzano gli obiettivi di livello di servizio. Mirano a definire gli obiettivi che coprono le funzionalità di base senza enfatizzare eccessivamente le caratteristiche supplementari. Misurano l'integrità di tre flussi utente critici, che coinvolgono tutte le funzionalità cloud di base ed eseguono codice tra le distribuzioni. Tuttavia, questi flussi non coprono tutto il codice o l'accesso ai dati. Ecco i fattori che influenzano.
Calcolare un SLO composito
SLO di disponibilità di Azure: il contratto di servizio finanziario per Azure funge da proxy per valutare l'affidabilità della piattaforma.
Componente di Azure Copertura del contratto di servizio applicabile Non coperto dal contratto di servizio SLO modificato Frontdoor di Azure 99,99% per operazioni HTTP GETriusciteMemorizzazione nella cache, motore di regole 99.98% App contenitore 99,95% in base alle app distribuite raggiungibili dall'ingresso integrato predefinito Scalabilità automatica, funzionalità dell'archivio token 99,95% Istanza gestita di SQL 99,99% in base alla connessione all'istanza di SQL Server Prestazioni, conservazione dei dati 99.80% Collegamento privato 99,99% in base a minuti interi quando la rete endpoint privata non accetta il traffico o quando il traffico non passa tra l'endpoint e il servizio collegamento privato Singoli errori che durano meno di un minuto 99,99% La regolazione si basa su diversi fattori che dipendono dall'impegno del team di lavoro nei confronti dei propri obiettivi. Un fattore potrebbe essere la fiducia nella funzionalità della piattaforma in base all'esperienza precedente. Ad esempio, per Container Apps e Collegamento Privato, il team si sente a proprio agio a prendere il valore dell'SLA così com'è.
Esistono anche dei fattori sfumati. Ad esempio, il team riduce il valore SLO per Istanza gestita di SQL al 99,80% per tenere conto di potenziali errori nelle operazioni sui dati, ad esempio le modifiche dello schema e l'esecuzione di backup.
Il team imposta l'SLO composito calcolando l'impatto dei singoli valori SLO modificati. Questo valore è 99,72%.
Ci sono altri fattori che contribuiscono. L'architettura si basa su componenti di rete di Azure come reti virtuali e gruppi di sicurezza di rete (NSG) che non hanno un contratto di servizio pubblicato. Il team del carico di lavoro decide di prendere in considerazione questi fattori con disponibilità del 99,99% per ogni componente.
SLO composito basato sulla disponibilità stimata della piattaforma: 99,68% al mese.
SLO del codice dell'applicazione: il team riconosce che i bug nel codice dell'applicazione o nelle stored procedure possono influire sulla disponibilità del sistema e allocano un'ora di tempo di inattività mensile per tenere conto degli errori correlati al codice.
Usano percentili di tempo di inattività comuni per stimare lo SLO per singoli fattori, ad esempio difetti del codice, problemi di ridimensionamento e altre considerazioni relative al codice.
SLO composito basato su codice e disponibilità dei dati: 99,86% al mese.
SLO di configurazione delle risorse e delle applicazioni: il team riconosce che le risorse cloud e il codice dell'applicazione devono essere configurati correttamente. Questa destinazione include la configurazione delle regole di autoscaling, la distribuzione delle regole NSG e la selezione delle dimensioni corrette degli SKU. Per tenere conto degli errori di configurazione, si prevedono 10 minuti di inattività al mese, ovvero circa il 99,98% di disponibilità.
SLO composito basato sulla disponibilità della configurazione: 99,95% al mese.
Operations SLO: il team del carico di lavoro sviluppa una buona cultura devOps seguendo i principi del framework ben progettato per l'eccellenza operativa. Distribuiscono risorse cloud, configurazione e codice ogni sprint.
Il team considera le distribuzioni un rischio perché possono destabilizzare un sistema in esecuzione. Potrebbero verificarsi errori a causa di aggiornamenti del certificato TLS, modifiche DNS o errori degli strumenti. Il team considera anche potenziali tempi di inattività causati da correzioni di emergenza. Prevedono un totale di 20 minuti di inattività mensile, che è circa il 99,95% di disponibilità.
Le finestre di manutenzione sono periodi di tempo designati durante i quali si verificano la manutenzione o gli aggiornamenti del sistema. L'API è principalmente inutilizzata per circa quattro ore ogni giorno. Per ridurre il rischio di indisponibilità, il team può pianificare le attività di manutenzione durante tali ore meno attive. Questo approccio porta a uno SLO superiore, ma il team decide di non includere la finestra di manutenzione come parte del proprio SLO.
SLO composito basato sulla disponibilità delle operazioni: 99,95% al mese.
Dipendenze esterne SLO: il team considera Istanza gestita di SQL come dipendenza primaria, che ha già un fattore di disponibilità del 99,80% nella disponibilità complessiva della piattaforma. Non vengono considerate altre dipendenze esterne.
SLO composito basato su dipendenze esterne: non applicabile.
Determinare il risultato SLO composito complessivo
L'obiettivo SLO composito complessivo è impostato al 99,45%, che equivale a circa quattro ore di inattività al mese.
Per soddisfare l'obiettivo SLO di sole quattro ore di indisponibilità al mese, il team responsabile del carico di lavoro stabilisce una turnazione di reperibilità. Sia il supporto tecnico che il monitoraggio delle transazioni sintetiche possono richiamare il supporto SRE (On-Call Site Reliability Engineering) per avviare tempestivamente i passaggi di ripristino per risolvere i problemi di SLO.
Impostare l'SLA del carico di lavoro
L'Accordo sul livello di servizio (SLA) per il carico di lavoro garantisce il 99,90% di disponibilità al mese.
I reparti legali e finanziari del team del carico di lavoro impostano il contratto di servizio per il carico di lavoro al 99,90% di disponibilità al mese, che supera l'obiettivo SLO del 99,45%. Questa decisione viene presa dopo l'analisi dei proventi finanziari rispetto alla crescita prevista dei clienti in base a un contratto di servizio interessante. Il contratto di servizio copre due flussi utente principali e include considerazioni sulle prestazioni, non solo la disponibilità. Si tratta di un rischio calcolato assunto dal team aziendale per trarre vantaggio dall'azienda e il team di progettazione è consapevole dell'impegno.
Impostare lo SLO di correttezza
I flussi utente principali dell'applicazione devono essere disponibili e facilmente usabili, o persino reattivi in modo competitivo. Il team imposta un SLO del tempo di risposta specifico per l'API, escluso il tempo di elaborazione client e l'attraversamento della rete Internet. Valutano questo SLO solo durante i periodi di disponibilità. Scelgono il 75° percentile sia come destinazione SLO che come misurazione delle prestazioni, che acquisisce l'esperienza tipica del cliente ed esclude scenari peggiori.
Collegamenti correlati
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.