Compromessi di affidabilità per Power Platform carichi di lavoro
Un carico di lavoro affidabile soddisfa costantemente i relativi obiettivi di affidabilità definiti. Deve raggiungere obiettivi di resilienza stabiliti, idealmente eludendo gli eventi che influiscono sull’affidabilità. Realisticamente, tuttavia, un carico di lavoro deve tollerare e controllare l'impatto di tali eventi e mantenere le operazioni a un livello predeterminato durante il malfunzionamento attivo. Anche durante un disastro, un carico di lavoro affidabile deve essere ripristinato a uno stato specifico entro un determinato periodo di tempo, entrambi concordati tra gli stakeholder. Un piano di risposta agli incidenti che consenta di ottenere un rilevamento e un ripristino rapidi è fondamentale.
Durante la fase di progettazione di un carico di lavoro, devi considerare come le decisioni basate sui principi di progettazione dell'affidabilità e le raccomandazioni nell'elenco di controllo di revisione della progettazione per Affidabilità potrebbe influenzare obiettivi e ottimizzazioni di altri pilastri. Alcune decisioni potrebbero avvantaggiare alcuni pilastri ma costituire un compromesso per altri. Questo articolo descrive alcuni esempi di compromessi che un team del carico di lavoro potrebbe riscontrare durante la progettazione dell'architettura e delle operazioni del carico di lavoro per l'affidabilità.
Compromessi Affidabilità con Sicurezza
Compromesso: maggiore superficie del carico di lavoro. Il pilastro Sicurezza privilegia una superficie ridotta e contenuta per minimizzare i vettori di attacco e ridurre la gestione dei controlli di sicurezza.
L'affidabilità è spesso ottenuta attraverso la replica. La replica può avvenire a livello di componente, di dati o anche a livello geografico. Le repliche, per impostazione predefinita, aumentano la superficie di un carico di lavoro. Dal punto di vista della sicurezza è preferibile una superficie ridotta e contenuta per ridurre al minimo i potenziali vettori di attacco e snellire la gestione dei controlli di sicurezza.
Allo stesso modo, le soluzioni di ripristino di emergenza, come i backup, aumentano la superficie del carico di lavoro. Tuttavia, sono spesso isolati dal runtime del carico di lavoro. Ciò richiede l'implementazione di controlli di sicurezza aggiuntivi, che potrebbero essere specifici della soluzione di ripristino di emergenza.
Per motivi di affidabilità, potrebbero essere necessari componenti aggiuntivi per l'architettura, che aumentano la superficie. Questa maggiore complessità aumenta la superficie del carico di lavoro aggiungendo nuovi componenti che devono essere protetti, possibilmente in modi che non sono già utilizzati nel sistema. In genere, questi componenti sono accompagnati da codice aggiuntivo per supportarne l'uso o modelli di affidabilità generali, che aumentano anche la superficie dell'applicazione.
Quando in un carico di lavoro si verifica un evento di affidabilità che viene affrontato nell'ambito della risposta attiva agli incidenti, l'urgenza potrebbe creare pressione sui team del carico di lavoro affinché ignorino i controlli di sicurezza ottimizzati per l'accesso di routine.
Le attività di risoluzione dei problemi possono indurre il team a disabilitare temporaneamente i protocolli di sicurezza, lasciando un sistema già stressato potenzialmente esposto a ulteriori rischi per la sicurezza. C'è anche il rischio che i protocolli di sicurezza non vengano ripristinati tempestivamente.
Le implementazioni granulari dei controlli di sicurezza, come le assegnazioni di controllo degli accessi basati sui ruoli o le regole del firewall, introducono complessità e importanza nella configurazione, aumentando la possibilità di errori di configurazione. Mitigare questo potenziale impatto sull’affidabilità mediante regole ampie erode tutti e tre i principi dell’architettura Zero Trust.
L'applicazione degli aggiornamenti dei cicli di rilascio o degli aggiornamenti a librerie di fornitori, come componenti o soluzioni di terze parti, può potenzialmente interrompere il componente di destinazione, causando l'indisponibilità durante la modifica. Ritardare o evitare l'applicazione delle patch potrebbe evitare potenziali rischi per l'affidabilità, ma lascia il sistema non protetto contro l'evoluzione delle minacce.
La considerazione precedente si applica anche al codice del carico di lavoro. Si applica, ad esempio, al codice dell'applicazione che utilizza librerie e componenti obsoleti. Se l'aggiornamento e la distribuzione del codice dell'applicazione vengono considerati un rischio assoluto per l'affidabilità, l'applicazione è esposta nel tempo a ulteriori rischi per la sicurezza.
Compromessi Affidabilità con Eccellenza operativa
Avere una strategia di monitoraggio completa per un carico di lavoro è una parte fondamentale dell'eccellenza operativa. L'introduzione di componenti aggiuntivi in un'architettura per implementare modelli di progettazione dell'affidabilità comporta un numero maggiore di origini dati da gestire, aumentando la complessità dell'implementazione della tracciabilità e dell'osservabilità distribuite.
L'utilizzo di più aree per superare vincoli di capacità delle risorse di una singola regione e/o implementare un'architettura attiva/attiva aumenta la complessità della gestione operativa del carico di lavoro. Questa complessità è introdotta dalla necessità di gestire più aree e dalla necessità di gestire la replica dei dati tra di esse.
Man mano che un carico di lavoro diventa più robusto grazie all'aggiunta di componenti e modelli di affidabilità, è necessario più tempo per gestire le procedure operative e la documentazione degli artefatti.
La formazione diventa più complessa man mano che aumenta il numero di componenti nel carico di lavoro. Questa complessità influisce sul tempo necessario per l'onboarding e aumenta la conoscenza necessaria per tenere traccia delle roadmap dei prodotti e delle indicazioni sui livelli di servizio.
Compromessi Affidabilità con Ottimizzazione dell'esperienza
Enfatizzare test rigorosi può ritardare il rilascio di funzionalità per l'esperienza essenziali per l'adozione.
L'ottimizzazione dell'affidabilità può sovraindicizzare la riduzione al minimo della complessità, riducendo la priorità delle funzionalità per esperienze utente più coinvolgenti, come integrazioni e componenti personalizzati.
Compromessi tra affidabilità ed efficienza prestazionale
I modelli di affidabilità spesso incorporano la replica dei dati per sopravvivere al malfunzionamento della replica. La replica introduce una latenza aggiuntiva per operazioni di scrittura dati affidabili, che consuma una parte del budget prestazionale per un utente o un flusso di dati specifico.
L'affidabilità a volte impiega varie forme di bilanciamento delle risorse per distribuire o ridistribuire il carico su repliche integre. Un componente dedicato utilizzato per il bilanciamento in genere influisce sulle prestazioni della richiesta o del processo da bilanciare.
La distribuzione dei componenti oltre i confini geografici o le zone di disponibilità per sopravvivere a un impatto con ambito introduce la latenza di rete nella comunicazione tra i componenti che superano tali limiti di disponibilità.
Vengono utilizzati processi estesi per osservare lo stato di un carico di lavoro. Sebbene il monitoraggio sia fondamentale per l'affidabilità, la strumentazione può influire sulle prestazioni del sistema. All’aumentare dell’osservabilità, le prestazioni potrebbero diminuire.
Le operazioni di ridimensionamento automatico non sono istantanee e pertanto non possono gestire in modo affidabile un picco improvviso e drammatico della domanda che non può essere modellato o attenuato. Pertanto, il provisioning eccessivo tramite istanze più grandi o più istanze è una tattica di affidabilità fondamentale per tenere conto del ritardo tra il segnale della domanda e la creazione dell'offerta. La capacità inutilizzata contrasta con gli obiettivi di efficienza prestazionale.
A volte un componente non può essere ridimensionato in risposta alla domanda e tale domanda non è completamente prevedibile. L'utilizzo di istanze di grandi dimensioni per coprire il caso peggiore porta a uno spreco eccessivo in situazioni che esulano da quel caso d'uso.