Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La metodologia di progettazione cruciale è sostenuta da cinque principi chiave di progettazione che fungono da bussola per le successive decisioni di progettazione nelle aree di progettazione critiche. Consigliamo vivamente di acquisire familiarità con questi principi per comprendere meglio il loro impatto e i compromessi associati alla mancata conformità.
Affidabilità
| Principio di progettazione | Considerazioni |
|---|---|
| Progettazione attiva/attiva | Per ottimizzare la disponibilità e ottenere la tolleranza di errore a livello di area, i componenti della soluzione devono essere distribuiti tra più zone di disponibilità e aree di Azure usando un modello di distribuzione attivo/attivo, dove possibile. |
| Riduzione del raggio di esplosione e isolamento degli errori | L'errore è impossibile da evitare in un ambiente cloud iperscalabile altamente distribuito, ad esempio Azure. Anticipando gli errori e l'impatto correlato, dai singoli componenti a intere aree di Azure, è possibile progettare e sviluppare una soluzione in modo resiliente. |
| Osservare l'integrità dell'applicazione | Prima di attenuare i problemi che influiscono sull'affidabilità delle applicazioni, è necessario prima rilevare e comprendere. Monitorando l'operazione di un'applicazione rispetto a uno stato integro noto, diventa possibile rilevare o persino stimare i problemi di affidabilità, consentendo l'esecuzione di azioni correttive rapide. |
| Automazione della guida | Una delle cause principali del tempo di inattività dell'applicazione è l'errore umano, indipendentemente dal fatto che ciò sia dovuto alla distribuzione di software testato in modo insufficiente o a errori di configurazione. Per ridurre al minimo la possibilità e l'impatto degli errori umani, è fondamentale cercare l'automazione in tutti gli aspetti di una soluzione cloud per migliorare l'affidabilità; test automatizzati, distribuzione e gestione. |
| Progettazione per la riparazione automatica | La riparazione automatica descrive la capacità di un sistema di gestire automaticamente gli errori tramite protocolli di correzione predefiniti connessi alle modalità di errore all'interno della soluzione. Si tratta di un concetto avanzato che richiede un elevato livello di maturità del sistema con monitoraggio e automazione, ma deve essere un'aspirazione fin dall'inizio per massimizzare l'affidabilità. |
| Evitare la complessità | Evitare inutili complessità durante la progettazione della soluzione e di tutti i processi operativi per favorire l'efficienza di affidabilità e gestione, riducendo al minimo la probabilità di errori. |
Efficienza delle prestazioni
| Principio di progettazione | Considerazioni |
|---|---|
| Progettazione per la scalabilità orizzontale | La scalabilità orizzontale è un concetto incentrato sulla capacità di un sistema di rispondere alla domanda attraverso la crescita orizzontale. Ciò significa che man mano che il traffico aumenta, vengono aggiunte più unità di risorsa in parallelo invece di aumentare le dimensioni delle risorse esistenti. La capacità dei sistemi di gestire il traffico previsto e imprevisto attraverso le unità di scala è essenziale per le prestazioni complessive e l'affidabilità, riducendo ulteriormente l'impatto di un singolo errore di risorsa. |
| Automazione per iperscalabilità | Le operazioni di scalabilità in tutta la soluzione devono essere completamente automatizzate per ridurre al minimo l'impatto sulle prestazioni e sulla disponibilità derivanti da aumenti imprevisti o previsti del traffico, assicurando che il tempo necessario per eseguire operazioni di scalabilità sia compreso e allineato a un modello per l'integrità dell'applicazione. |
| Convalida e test continui | I test automatizzati devono essere eseguiti all'interno dei processi CI/CD per eseguire la convalida continua per ogni modifica dell'applicazione. I test di carico in base a una baseline di prestazioni con la sperimentazione chaos sincronizzata devono essere inclusi per convalidare soglie, obiettivi e presupposti esistenti, oltre a contribuire a identificare rapidamente i rischi per la resilienza e la disponibilità. Tali test devono essere eseguiti all'interno di ambienti di staging e test, ma anche facoltativamente all'interno degli ambienti di sviluppo. Può anche essere utile eseguire un sottoinsieme di test sull'ambiente di produzione, in particolare in combinazione con un modello di distribuzione blu/verde per convalidare i nuovi marchi di distribuzione prima di ricevere il traffico di produzione. |
| Ridurre il sovraccarico con i servizi di calcolo gestiti | L'uso di servizi di calcolo gestiti e architetture in contenitori riduce significativamente il sovraccarico amministrativo e operativo in corso della progettazione, del funzionamento e della scalabilità delle applicazioni spostando la distribuzione e la manutenzione dell'infrastruttura al provider di servizi gestiti. |
| Stabilire il livello prestazionale iniziale e identificare le strozzature | I test delle prestazioni con dati di telemetria dettagliati da ogni componente di sistema consentono l'identificazione di colli di bottiglia all'interno del sistema, inclusi i componenti che devono essere ridimensionati in relazione ad altri componenti e queste informazioni devono essere incorporate in un modello di capacità. |
| Capacità del modello | Un modello di capacità consente di pianificare i livelli di scalabilità delle risorse per un determinato profilo di carico ed espone inoltre il modo in cui i componenti di sistema vengono eseguiti l'uno rispetto all'altro, consentendo quindi la pianificazione dell'allocazione della capacità a livello di sistema. |
Eccellenza operativa
| Principio di progettazione | Considerazioni |
|---|---|
| Componenti ad accoppiamento libero | L'accoppiamento libero consente test, distribuzioni e aggiornamenti indipendenti e su richiesta ai componenti dell'applicazione riducendo al minimo le dipendenze tra team per supporto, servizi, risorse o approvazioni. |
| Automatizzare i processi di compilazione e rilascio | I processi di compilazione e rilascio completamente automatizzati riducono l'attrito e aumentano la velocità di distribuzione degli aggiornamenti, portando la ripetibilità e la coerenza tra gli ambienti. L'automazione riduce il ciclo di feedback degli sviluppatori che eseviano modifiche per ottenere informazioni dettagliate sulla qualità del codice, sulla copertura dei test, sulla resilienza, sulla sicurezza e sulle prestazioni, aumentando la produttività degli sviluppatori. |
| Agilità per gli sviluppatori | L'automazione di integrazione continua e distribuzione continua (CI/CD) consente l'uso di ambienti di sviluppo di breve durata con cicli di vita legati a quello di un ramo di funzionalità associato, che promuove l'agilità degli sviluppatori e guida la convalida il prima possibile all'interno del ciclo di progettazione per ridurre al minimo il costo di progettazione dei bug. |
| Quantificare la salute operativa | La strumentazione diagnostica completa di tutti i componenti e le risorse consente l'osservabilità continua di log, metriche e tracce, ma facilita anche la modellazione dell'integrità per quantificare l'integrità delle applicazioni nel contesto in base ai requisiti di disponibilità e prestazioni. |
| Provare il ripristino e gestire il fallimento | La pianificazione e la pratica di continuità aziendale (BC) e ripristino di emergenza (DR) sono essenziali e devono essere eseguite frequentemente, poiché le informazioni possono migliorare in modo iterativo piani e procedure per ottimizzare la resilienza in caso di tempi di inattività non pianificati. |
| Adottare un miglioramento operativo continuo | Classificare in ordine di priorità il miglioramento di routine dell'esperienza utente e del sistema, usando un modello di integrità per comprendere e misurare l'efficienza operativa con meccanismi di feedback per consentire ai team dell'applicazione di comprendere e risolvere i gap in modo iterativo. |
Sicurezza
| Principio di progettazione | Considerazioni |
|---|---|
| Monitorare la sicurezza dell'intera soluzione e pianificare le risposte agli eventi imprevisti | Correlare gli eventi di sicurezza e controllo per modellare l'integrità delle applicazioni e identificare le minacce attive. Stabilire procedure automatizzate e manuali per rispondere agli eventi imprevisti usando gli strumenti SIEM (Security Information and Event Management) per il rilevamento. |
| Modellare e testare le potenziali minacce | Assicurarsi che venga assicurata una protezione adeguata delle risorse e stabilire procedure appropriate per identificare e attenuare le minacce note, utilizzando test di penetrazione per verificare la mitigazione delle minacce, oltre all'analisi statica del codice e alla scansione del codice. |
| Identificare e proteggere gli endpoint | Monitora e proteggi l'integrità di rete degli endpoint interni ed esterni tramite funzionalità e appliance di sicurezza, come firewall o Web application firewall. Usare approcci standard del settore per proteggersi da vettori di attacco comuni, ad esempio attacchi DDoS (Distributed Denial-Of-Service), ad esempio SlowLoris. |
| Protezione da vulnerabilità a livello di codice | Identificare e attenuare le vulnerabilità a livello di codice, come lo scripting intersito o l'SQL injection, e incorporare l'applicazione di patch di sicurezza nei cicli di vita operativi per tutte le componenti della codebase, comprese le dipendenze. |
| Automatizzare e usare privilegi minimi | Favorire l'automazione per ridurre al minimo la necessità di interazione umana e implementare privilegi minimi sia nell'applicazione che nel piano di controllo per proteggersi da scenari di esfiltrazione di dati e attori malintenzionati. |
| Classificare e crittografare i dati | Classificare i dati in base al rischio e applicare la crittografia standard del settore a riposo e in transito, assicurando che le chiavi e i certificati vengano conservati in modo sicuro e gestiti correttamente. |
Ottimizzazione dei costi
Esistono ovvi compromessi sui costi associati all'introduzione di maggiore affidabilità, che devono essere considerati attentamente nel contesto dei requisiti del carico di lavoro.
L'ottimizzazione dell'affidabilità può influire sul costo finanziario complessivo della soluzione. Ad esempio, la duplicazione delle risorse e la distribuzione delle risorse tra aree per ottenere una disponibilità elevata ha implicazioni chiare sui costi. Per evitare costi in eccesso, non progettare in maniera eccessiva o approvvigionare in eccesso al di là dei reali bisogni aziendali.
Inoltre, è previsto un costo aggiuntivo associato all'investimento di progettazione in concetti di affidabilità fondamentali, ad esempio l'adozione dell'infrastruttura come codice, automazione della distribuzione e automazione dei test. Ciò comporta un costo sia in termini di tempo che di impegno, che potrebbero essere investiti altrove per offrire nuove funzionalità e funzionalità dell'applicazione.
Passo successivo
Le aree di progettazione sono interconnesse, quindi le modifiche in un'area possono influire sugli altri. Iniziare con l'area più critica per l'azienda, quindi esaminare le considerazioni e le raccomandazioni per comprendere come le scelte creano compromessi nell'architettura.