Raccomandazioni per la definizione degli obiettivi di affidabilità
Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:
| RE:04 | Definire obiettivi di affidabilità e ripristino per i componenti, i flussi e la soluzione complessiva. Visualizzare le destinazioni per negoziare, ottenere il consenso, impostare le aspettative e guidare le azioni per ottenere 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. È consigliabile derivare obiettivi di affidabilità dagli esercizi di workshop con gli stakeholder aziendali. Perfezionare quindi tali destinazioni 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 l'errore (MOUNTAINF) | 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 le destinazioni 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 i contratti di servizio 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.
Le destinazioni di correttezza assicurano che il carico di lavoro esegua correttamente le 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. Mirare a una soluzione pratica e conveniente invece di overengineering.
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 del carico di lavoro prendere molte decisioni tecniche in base ai contratti di servizio. I contratti di servizio possono:
Fungere da input critico nelle decisioni relative all'architettura quando si considerano altre dipendenze.
Fornire una visualizzazione quasi in tempo reale e una comprensione condivisa dell'integrità di un carico di lavoro per consentire discussioni obiettivo. 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 contratti di servizio e contratti di servizio. Anche se i contratti di servizio e i contratti di servizio 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 i contratti di servizio per valutare se il tempo di inattività potenziale rientra nei limiti tollerabili.
I contratti di servizio e i contratti di servizio condividono una relazione aziendale e devono essere controllati in modo indipendente. 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, i contratti 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, i contratti di servizio 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 contratto 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 i contratti di servizio comuni e influenzare i fattori
Ogni SLO è destinato a criteri di qualità specifici. Considerare questi contratti di servizio comuni per l'affidabilità. Questo elenco non è esaustivo. Aggiungere contratti di servizio in base ai 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 sulla limitazione.
La disponibilità misura il tempo di attività 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? - Include API di query? - Si tratta di un componente di calcolo ? - È un componente di elaborazione del processo ? |
- Piano di controllo e accesso al piano di gestione per i servizi di Azure pubblici. - Accesso al piano dati, ad esempio operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD). |
- Il 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à? Sono state fattorite nelle dipendenze dei partner? - Il personale è sufficiente per supportare una rotazione costante delle chiamate di emergenza e 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 i contratti di servizio a vari livelli, ad esempio per ogni applicazione, carico di lavoro o un flusso specifico, nel sistema. Impostare contratti di servizio specifici del livello in modo da poter personalizzare gli obiettivi di servizio in base all'importanza di ogni componente.
Nelle soluzioni SaaS (Software as a Service) misurare i contratti di servizio per cliente per ottimizzare l'esperienza di ogni 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. Misurare invece i contratti di servizio allineati al contesto specifico di ogni cliente. Per altre informazioni, vedere Modelli tenancy per una soluzione multi-tenant.
Definire destinazioni SLO composite
Gli obiettivi di servizio devono essere misurabili e misurati all'interno di una finestra di osservabilità.
Gli obiettivi di servizio sono spesso percentuali come il 99,90%, ma possono anche essere istruzioni. Usare entrambi i metodi per ottenere un valore numerico che include tutti i fattori.
Un SLO è costituito da contratti di servizio misurabili che definiscono fattori accettabili. I contratti di servizio sono metriche con una soglia impostata che può essere avvisata. È possibile raccoglierli da una piattaforma o da un'applicazione. I diversi componenti generano contratti di servizio pertinenti. Quando si scelgono i contratti di servizio, prendere in considerazione i fattori che influenzano lo 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 le proprie destinazioni SLO.
Un buon SLI mostra quando si potrebbe violare 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à alla settimana | Non conformità al mese | Non conformità all'anno |
|---|---|---|---|
| 99% | 1,68 ore | 7,20 ore | 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 contratti di servizio compositi per flussi diversi, prendere in considerazione la criticità e la pertinenza 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 contratti di servizio e contratti di servizio, vedere la sezione Esempio .
Valutare l'impatto dei contratti di servizio Microsoft
Un contratto di servizio Microsoft fornisce informazioni dettagliate sulla disponibilità delle aree a cui Microsoft esegue il commit. I contratti di servizio non garantiscono un'offerta nel suo complesso. Quando si valutano i contratti di servizio, 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 prendere in considerazione le aree che non sono menzionate in modo esplicito nel contratto come disponibile dal miglior sforzo della piattaforma.
Pertanto, se il carico di lavoro si basa sugli slot di distribuzione, non è possibile derivare lo SLO esclusivamente dal contratto di servizio servizio app. In qualità di team del carico di lavoro, è necessario coprire e prevedere la disponibilità del tempo di attività. 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 i contratti 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.
Modello di intestazione bulk, in cui si limitano i clienti a aree specifiche per segmentarle. In questi casi, considerare le distribuzioni di più aree come distribuzioni separate o timbri in ogni area. Misurare l'integrità di ogni stamp separatamente, con i contratti di servizio appropriati per il carico di lavoro. Prendere in considerazione l'SLO del carico di lavoro complessivo in base all'integrità di ogni stamp. Se è possibile eseguire il failover tra indicatori, l'SLO del carico di lavoro complessivo è superiore perché un errore in un timbro è recuperabile tramite un failover a un altro timbro.
Prestare attenzione alla ridondanza necessaria per soddisfare i contratti di servizio elevati. 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 destinazioni di ripristino realistiche, ad esempio RTO, RPO, MTTR e METRIche MOUNTAINF, si basano sull'analisi della modalità di errore e sui piani e sui test per la continuità aziendale e il ripristino di emergenza. 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, 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 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
MOUNTAINF può essere difficile da definire e garantire. I modelli PaaS (Platform as a Service) o SaaS possono non riuscire 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 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 le destinazioni
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. Quando lo stato cambia, il modello deve avvisare le parti responsabili. Per considerazioni dettagliate sulla progettazione e consigli, vedere Linee guida per la modellazione dell'integrità.
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
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 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 criterio di imposizione.
Esplorare i dashboard di Monitoraggio di Azure per il sistema di visualizzazione.
Esempio
Contoso, Ltd. sta progettando una nuova esperienza mobile per il sistema di ticket di eventi. Ecco l'architettura generale.
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.
App Azure Container è l'ambiente proprietario e usato dal team del carico di lavoro per eseguire la logica di business per l'applicazione.
Istanza gestita di SQL è di proprietà e gestita da un altro team ed è una dipendenza critica del carico di lavoro.
collegamento privato di Azure offre connettività privata tra frontdoor di Azure e distribuzioni di app contenitore. Istanza gestita di SQL viene esposto anche all'applicazione 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 i contratti 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 regole 99.98% App contenitore 99,95% in base alle app distribuite raggiungibili dal traffico in ingresso 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 dalla promessa del team del carico di lavoro ai propri obiettivi. Un fattore potrebbe essere la fiducia nella funzionalità della piattaforma in base all'esperienza precedente. Ad esempio, per App contenitore e collegamento privato, il team si sente a proprio agio a prendere il valore del contratto di servizio così come è.
Ci sono anche 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 scalabilità automatica, la distribuzione delle regole del gruppo di sicurezza di rete e la selezione delle dimensioni corrette degli SKU. Per tenere conto degli errori di configurazione, il budget è di 10 minuti di tempo di inattività mensile, 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é può 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. Hanno un budget totale di 20 minuti di tempo 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
La destinazione SLO composita complessiva è impostata al 99,45%, che equivale a circa quattro ore di inattività al mese.
Per soddisfare la destinazione SLO di soli quattro ore di indisponibilità al mese, il team del carico di lavoro stabilisce una rotazione su chiamata. 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 il contratto di servizio del carico di lavoro
Il contratto di servizio per il carico di lavoro è disponibile al 99,90% 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 usabilmente, o anche competitivi, reattivi. 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.