Distribuzione e test per carichi di lavoro cruciali in Azure

Le distribuzioni non riuscite e le versioni errate sono cause comuni di interruzioni dell'applicazione. L'approccio alla distribuzione e ai test svolge un ruolo fondamentale nell'affidabilità complessiva di un'applicazione mission-critical.

La distribuzione e i test devono costituire la base per tutte le operazioni dell'applicazione e dell'infrastruttura per garantire risultati coerenti per i carichi di lavoro cruciali. Prepararsi a distribuire settimanalmente, ogni giorno o più spesso. Progettare le pipeline di integrazione continua e distribuzione continua (CI/CD) per supportare tali obiettivi.

La strategia deve implementare:

• Test rigorosi di versioni non definitive. Gli aggiornamenti non devono introdurre difetti, vulnerabilità o altri fattori che potrebbero compromettere l'integrità delle applicazioni.

• Distribuzioni trasparenti. Dovrebbe essere possibile implementare gli aggiornamenti in qualsiasi momento senza influire sugli utenti. Gli utenti devono essere in grado di continuare le interazioni con l'applicazione senza interruzioni.

• Operazioni a disponibilità elevata. I processi e gli strumenti di distribuzione e test devono essere a disponibilità elevata per supportare l'affidabilità complessiva delle applicazioni.

• Processi di distribuzione coerenti. Gli stessi elementi e processi dell'applicazione devono essere usati per distribuire l'infrastruttura e il codice dell'applicazione in ambienti diversi. L'automazione end-to-end è obbligatoria. Gli interventi manuali devono essere evitati perché possono introdurre rischi di affidabilità.

Questa area di progettazione fornisce consigli su come ottimizzare i processi di distribuzione e test con l'obiettivo di ridurre al minimo i tempi di inattività e mantenere l'integrità e la disponibilità delle applicazioni.

Importante

Questo articolo fa parte della serie di carichi di lavoro cruciali di Azure Well-Architected Framework. Se non si ha familiarità con questa serie, è consigliabile iniziare con Che cos'è un carico di lavoro cruciale?.

Distribuzione senza tempi di inattività

Per una panoramica della distribuzione senza tempi di inattività, vedere il video seguente.

Raggiungere distribuzioni senza tempi di inattività è un obiettivo fondamentale per le applicazioni cruciali. L'applicazione deve essere disponibile tutto il giorno, ogni giorno, anche quando vengono implementate nuove versioni durante l'orario di ufficio. Investire gli sforzi iniziali per definire e pianificare i processi di distribuzione per prendere decisioni di progettazione chiave, ad esempio se trattare le risorse come temporanee.

Per ottenere una distribuzione senza tempi di inattività, distribuire una nuova infrastruttura accanto all'infrastruttura esistente, testarla accuratamente, eseguire la transizione del traffico degli utenti finali e quindi rimuovere solo le autorizzazioni dell'infrastruttura precedente. Anche altre procedure, come l'architettura delle unità di scala, sono fondamentali.

Le implementazioni di riferimento Mission-Critical Online e Azure Mission-Critical Connected illustrano questo approccio alla distribuzione, come illustrato in questo diagramma:

Ambienti dell'applicazione

Per una panoramica delle raccomandazioni per gli ambienti dell'applicazione, vedere il video seguente.

Sono necessari vari tipi di ambienti per convalidare e preparare le operazioni di distribuzione. I tipi hanno funzionalità e cicli di vita diversi. Alcuni ambienti potrebbero riflettere l'ambiente di produzione ed essere di lunga durata e altri potrebbero essere di breve durata e avere meno funzionalità rispetto alla produzione. La configurazione di questi ambienti all'inizio del ciclo di sviluppo consente di garantire agilità, separazione degli asset di produzione e preproduzione e test approfonditi delle operazioni prima del rilascio nell'ambiente di produzione. Tutti gli ambienti devono riflettere il più possibile l'ambiente di produzione, anche se è possibile applicare semplificazioni agli ambienti inferiori in base alle esigenze. Questo diagramma mostra un'architettura cruciale:

Esistono alcune considerazioni comuni:

• I componenti non devono essere condivisi tra ambienti. Le possibili eccezioni sono appliance di sicurezza downstream come firewall e posizioni di origine per i dati di test sintetici.

• Tutti gli ambienti devono usare artefatti dell'infrastruttura come codice (IaC) come i modelli Terraform o Azure Resource Manager (ARM).

Ambienti di sviluppo

Per informazioni sugli ambienti di sviluppo temporanei e sulla convalida automatica delle funzionalità, vedere il video seguente.

Considerazioni relative alla progettazione

• Funzionalità. I requisiti più bassi per l'affidabilità, la capacità e la sicurezza sono accettabili per gli ambienti di sviluppo.

• Ciclo di vita. Gli ambienti di sviluppo devono essere creati in base alle esigenze ed esistono per un breve periodo di tempo. I cicli di vita più brevi consentono di evitare la deriva della configurazione dalla codebase e ridurre i costi. Inoltre, gli ambienti di sviluppo spesso condividono il ciclo di vita di un ramo di funzionalità.

• Densità. I team necessitano di più ambienti per supportare lo sviluppo di funzionalità parallele. Possono coesistere all'interno di una singola sottoscrizione.

Suggerimenti per la progettazione

• Mantenere l'ambiente in una sottoscrizione dedicata con il contesto impostato a scopo di sviluppo.

• Usare un processo automatizzato per distribuire il codice da un ramo di funzionalità a un ambiente di sviluppo.

Ambienti di test o gestione temporanea

Questi ambienti vengono usati per il test e la convalida. Vengono eseguiti molti cicli di test per garantire la distribuzione senza bug nell'ambiente di produzione. I test appropriati per un carico di lavoro critico sono descritti nella sezione Convalida e test continui.

Considerazioni relative alla progettazione

• Funzionalità. Questi ambienti devono riflettere l'ambiente di produzione per affidabilità, capacità e sicurezza. In assenza di un carico di produzione, usare un carico utente sintetico per fornire metriche realistiche e prezioso input di modellazione dell'integrità.

• Ciclo di vita. Questi ambienti sono di breve durata. Devono essere eliminati definitivamente dopo il completamento delle convalide dei test.

• Densità. È possibile eseguire molti ambienti indipendenti in una sottoscrizione. È anche consigliabile usare più ambienti, ognuno in una sottoscrizione dedicata.

Nota

Le applicazioni cruciali devono essere sottoposte a test rigorosi.

È possibile eseguire diverse funzioni di test in un singolo ambiente e in alcuni casi sarà necessario. Ad esempio, per il test chaos per ottenere risultati significativi, è prima necessario posizionare l'applicazione sotto carico in modo da poter comprendere in che modo l'applicazione risponde agli errori inseriti. Ecco perché i test di chaos e i test di carico vengono in genere eseguiti in parallelo.

Suggerimenti per la progettazione

• Assicurarsi che almeno un ambiente di staging rifletta completamente la produzione per abilitare test e convalida simili alla produzione. La capacità all'interno di questo ambiente può essere flessibile in base all'esecuzione delle attività di test.

• Generare un carico utente sintetico per fornire un test case realistico per le modifiche in uno degli ambienti.

  Nota

  L'implementazione di riferimento mission critical online fornisce un esempio di generatore di carico utente.

• Definire il numero di ambienti di staging e i relativi scopi all'interno del ciclo di sviluppo e rilascio.

Ambienti di produzione

Considerazioni relative alla progettazione

• Funzionalità. Sono necessari i livelli più elevati di affidabilità, capacità e funzionalità di sicurezza per l'applicazione.

• Ciclo di vita. Anche se il ciclo di vita del carico di lavoro e dell'infrastruttura rimane invariato, tutti i dati, inclusi il monitoraggio e la registrazione, richiedono una gestione speciale. Ad esempio, la gestione è necessaria per il backup e il ripristino.

• Densità. Per alcune applicazioni, è possibile prendere in considerazione l'uso di ambienti di produzione diversi per soddisfare diversi client, utenti o funzionalità aziendali.

Suggerimenti per la progettazione

Avere un limite di governance chiaro per gli ambienti di produzione e inferiore. Inserire ogni tipo di ambiente in una sottoscrizione dedicata per raggiungere tale obiettivo. Questa segmentazione garantisce che l'utilizzo delle risorse in ambienti inferiori non influisca sulle quote di produzione. Le sottoscrizioni dedicate impostano anche i limiti di accesso.

Distribuzioni temporanee blu/verde

Un modello di distribuzione blu/verde richiede almeno due distribuzioni identiche. La distribuzione blu è quella attiva che gestisce il traffico utente nell'ambiente di produzione. La distribuzione verde è la nuova che viene preparata e testata per ricevere il traffico. Al termine e al test della distribuzione verde, il traffico viene gradualmente indirizzato dal blu al verde. Se il trasferimento del carico ha esito positivo, la distribuzione verde diventa la nuova distribuzione attiva. La distribuzione blu precedente può quindi essere rimossa tramite un processo in più fasi. Tuttavia, se si verificano problemi nella nuova distribuzione, può essere interrotto e il traffico può rimanere nella distribuzione blu precedente o essere reindirizzato a esso.

Azure Mission-Critical consiglia un approccio di distribuzione blu/verde in cui l'infrastruttura e le applicazioni vengono distribuite insieme come parte di un timbro di distribuzione. Di conseguenza, l'implementazione di una modifica all'infrastruttura o all'applicazione comporta sempre una distribuzione verde che contiene entrambi i livelli. Questo approccio consente di testare e convalidare completamente l'effetto della modifica rispetto all'infrastruttura e all'applicazione end-to-end prima di reindirizzare il traffico utente a esso. L'approccio aumenta la probabilità di rilasciare le modifiche e consente aggiornamenti senza tempi di inattività perché è possibile convalidare le compatibilità con dipendenze downstream come la piattaforma Azure, i provider di risorse e i moduli IaC.

Considerazioni relative alla progettazione

• Funzionalità tecnologiche. Sfruttare le funzionalità di distribuzione predefinite nei servizi di Azure. Ad esempio, app Azure Servizio fornisce slot di distribuzione secondari che possono essere scambiati dopo una distribuzione. Con servizio Azure Kubernetes (servizio Azure Kubernetes), è possibile usare una distribuzione di pod separata in ogni nodo e aggiornare la definizione del servizio.

• Durata della distribuzione. Il completamento della distribuzione potrebbe richiedere più tempo perché lo stamp contiene l'infrastruttura e l'applicazione anziché solo il componente modificato. Ciò, tuttavia, è accettabile perché il rischio che tutti i componenti non funzionino come previsto sostituiscono i problemi relativi al tempo.

• Impatto dei costi. È previsto un costo aggiuntivo a causa delle due distribuzioni side-by-side, che devono coesistere fino al completamento della distribuzione.

• Transizione del traffico. Dopo la convalida della nuova distribuzione, il traffico deve essere passato dall'ambiente blu a quello verde. Questa transizione richiede l'orchestrazione del traffico utente tra gli ambienti. La transizione deve essere completamente automatizzata.

• Ciclo di vita. I francobolli di distribuzione cruciali devono essere considerati temporanei. L'uso di indicatori di breve durata crea un nuovo inizio ogni volta, prima del provisioning delle risorse.

Suggerimenti per la progettazione

• Adottare un approccio di distribuzione blu/verde per rilasciare tutte le modifiche di produzione. Distribuire ogni volta l'infrastruttura e l'applicazione, per qualsiasi tipo di modifica, per ottenere uno stato coerente e senza tempi di inattività. Anche se è possibile riutilizzare gli ambienti, non è consigliabile per carichi di lavoro cruciali. Considerare ogni stamp di distribuzione a livello di area come temporaneo con un ciclo di vita associato a quello di una singola versione.

• Usare un servizio di bilanciamento del carico globale, ad esempio Frontdoor di Azure, per orchestrare la transizione automatica del traffico utente tra gli ambienti blu e verde.

• Per eseguire la transizione del traffico, aggiungere un endpoint back-end verde che usa un traffico basso per il peso del volume, ad esempio il 10%. Dopo aver verificato che il volume di traffico ridotto nella distribuzione verde funzioni e fornisca l'integrità prevista dell'applicazione, aumentare gradualmente il traffico. In questo caso, applicare un breve periodo di rampa per rilevare gli errori che potrebbero non essere immediatamente evidenti.

  Dopo la transizione di tutto il traffico, rimuovere il back-end blu dalle connessioni esistenti. Ad esempio, rimuovere il back-end dal servizio di bilanciamento del carico globale, svuotare le code e scollegare altre associazioni. In questo modo è possibile ottimizzare i costi di gestione dell'infrastruttura di produzione secondaria e assicurarsi che i nuovi ambienti siano privi di deviazione della configurazione.

  A questo punto, rimuovere il vecchio ambiente blu e ora inattivo. Per la distribuzione successiva, ripetere il processo con blu e verde invertito.

Distribuzione con ambito sottoscrizione

A seconda dei requisiti di scalabilità dell'applicazione, potrebbero essere necessarie più sottoscrizioni di produzione da usare come unità di scala.

Vedere il video seguente per ottenere una panoramica delle raccomandazioni per la definizione dell'ambito delle sottoscrizioni per un'applicazione mission-critical.

Considerazioni relative alla progettazione

• Scalabilità. Per scenari di applicazioni su larga scala con volumi significativi di traffico, progettare la soluzione per la scalabilità tra più sottoscrizioni di Azure in modo che i limiti di scalabilità di una singola sottoscrizione non vincolano la scalabilità.

  Importante

  L'uso di più sottoscrizioni richiede una complessità CI/CD aggiuntiva, che deve essere gestita in modo appropriato. È pertanto consigliabile usare più sottoscrizioni solo in scenari di scalabilità estrema, in cui è probabile che i limiti di una singola sottoscrizione diventino un limite.

• Limiti dell'ambiente. Distribuire ambienti di produzione, sviluppo e test in sottoscrizioni separate. Questa procedura garantisce che gli ambienti inferiori non contribuiscano ai limiti di scalabilità. Riduce inoltre il rischio di aggiornamenti dell'ambiente inferiore che inquinano la produzione fornendo un chiaro limite di gestione e identità.

• Governance. Quando sono necessarie più sottoscrizioni di produzione, è consigliabile usare un gruppo di gestione delle applicazioni dedicato per semplificare l'assegnazione dei criteri tramite un limite di aggregazione dei criteri.

Suggerimenti per la progettazione

• Distribuire ogni stamp di distribuzione a livello di area in una sottoscrizione dedicata per garantire che i limiti della sottoscrizione si applichino solo all'interno del contesto di un singolo stamp di distribuzione e non nell'intera applicazione. Se appropriato, è consigliabile usare più indicatori di distribuzione all'interno di una singola area, ma è consigliabile distribuirli tra sottoscrizioni indipendenti.

• Inserire le risorse condivise globali in una sottoscrizione dedicata per abilitare la distribuzione coerente delle sottoscrizioni a livello di area. Evitare di usare una distribuzione specializzata per l'area primaria.

Convalida e test continui

Il test è un'attività critica che consente di convalidare completamente l'integrità del codice e dell'infrastruttura dell'applicazione. In particolare, i test consentono di soddisfare gli standard per affidabilità, prestazioni, disponibilità, sicurezza, qualità e scalabilità. I test devono essere ben definiti e applicati come parte della progettazione dell'applicazione e della strategia DevOps. Il test è un problema fondamentale durante il processo di sviluppo locale (il ciclo interno) e come parte del ciclo di vita DevOps completo (ciclo esterno), ovvero quando il codice inizia nel percorso dai processi della pipeline di rilascio verso l'ambiente di produzione.

Per una panoramica della convalida e dei test continui, vedere il video seguente.

Questa sezione è incentrata sul test del ciclo esterno. Descrive vari tipi di test.

Test	Descrizione
Testing unità	Conferma che la logica di business dell'applicazione funziona come previsto. Convalida l'effetto complessivo delle modifiche al codice.
Test di fumo	Identifica se i componenti dell'infrastruttura e dell'applicazione sono disponibili e funzionano come previsto. In genere, viene testata solo una singola sessione utente virtuale. Il risultato dovrebbe essere che il sistema risponde con i valori e il comportamento previsti. Gli scenari comuni di smoke testing includono il raggiungimento dell'endpoint HTTPS di un'applicazione Web, l'esecuzione di query su un database e la simulazione di un flusso utente nell'applicazione.
Test dell'interfaccia utente	Verifica che le interfacce utente dell'applicazione vengano distribuite e che le interazioni dell'interfaccia utente funzionino come previsto. È consigliabile usare gli strumenti di automazione interfaccia utente per favorire l'automazione. Durante un test dell'interfaccia utente, uno script deve simulare uno scenario utente realistico e completare una serie di passaggi per eseguire azioni e ottenere un risultato previsto.
Test di carico	Convalida la scalabilità e l'operazione dell'applicazione aumentando rapidamente il carico e/o gradualmente fino a raggiungere una soglia predeterminata. I test di carico vengono in genere progettati intorno a un flusso utente specifico per verificare che i requisiti dell'applicazione siano soddisfatti con un carico definito.
Test di stress	Applica le attività che eseguono l'overload delle risorse esistenti per determinare i limiti della soluzione e verificare la capacità del sistema di recuperare correttamente. L'obiettivo principale è identificare potenziali colli di bottiglia delle prestazioni e limiti di scalabilità. Al contrario, ridurre le risorse di calcolo del sistema e monitorare il comportamento in fase di caricamento e determinare se può essere ripristinato.
Test delle prestazioni	Combina gli aspetti dei test di carico e stress per convalidare le prestazioni sotto carico e stabilire comportamenti di benchmark per l'operazione dell'applicazione.
Test chaos	Inserisce errori artificiali nel sistema per valutare il modo in cui reagisce e per convalidare l'efficacia delle misure di resilienza, delle procedure operative e delle mitigazioni. L'arresto dei componenti dell'infrastruttura, la riduzione delle prestazioni e l'introduzione di errori dell'applicazione sono esempi di test che possono essere usati per verificare che l'applicazione reagisca come previsto quando si verificano effettivamente gli scenari.
Test di penetrazione	Garantisce che un'applicazione e il relativo ambiente soddisfino i requisiti di un comportamento di sicurezza previsto. L'obiettivo è identificare le vulnerabilità di sicurezza. I test di sicurezza possono includere dipendenze end-to-end della supply chain e del pacchetto del software, con analisi e monitoraggio per vulnerabilità ed esposizioni comuni note (CVE).

Considerazioni relative alla progettazione

• Automazione. I test automatizzati sono essenziali per convalidare le modifiche all'applicazione o all'infrastruttura in modo tempestivo e ripetibile.

• Ordine di test. L'ordine in cui vengono eseguiti i test è una considerazione critica a causa di varie dipendenze, ad esempio la necessità di avere un ambiente dell'applicazione in esecuzione. La durata del test influenza anche l'ordine. I test con tempi di esecuzione più brevi devono essere eseguiti in precedenza nel ciclo quando possibile per aumentare l'efficienza dei test.

• Limiti di scalabilità. I servizi di Azure hanno limiti flessibili e rigidi diversi. Provare a usare i test di carico per determinare se un sistema rischia di superarli durante il carico di produzione previsto. Il test di carico può essere utile anche per impostare soglie appropriate per la scalabilità automatica. Per i servizi che non supportano la scalabilità automatica, i test di carico consentono di ottimizzare le procedure operative automatizzate.

  L'impossibilità dei componenti di sistema, ad esempio componenti di rete attivi/passivi o database, di ridimensionare in modo appropriato può essere restrittiva. I test di stress possono aiutare a identificare le limitazioni.

• Analisi della modalità di errore. L'introduzione di errori nell'applicazione e nell'infrastruttura sottostante e la valutazione dell'effetto è essenziale per valutare i meccanismi di ridondanza della soluzione. Durante questa analisi, identificare il rischio, l'impatto e l'ampiezza dell'impatto (interruzione parziale o completa). Per un'analisi di esempio creata per l'implementazione di riferimento mission critical online , vedere Rischi di interruzione dei singoli componenti.

• Monitoraggio. È necessario acquisire e analizzare i risultati dei test singolarmente e aggregarli anche per valutare le tendenze nel tempo. È consigliabile valutare continuamente i risultati dei test per l'accuratezza e la copertura.

Suggerimenti per la progettazione

Vedere il video seguente per vedere come integrare i test di resilienza con le pipeline CI/CD di Azure DevOps.

• Garantire la coerenza automatizzando tutti i test sui componenti dell'infrastruttura e dell'applicazione. Integrare i test nelle pipeline CI/CD per orchestrarli ed eseguirli, se applicabile. Per informazioni sulle opzioni tecnologico, vedere Strumenti DevOps.

• Considerare tutti gli artefatti di test come codice. Devono essere mantenuti e controllati dalla versione insieme ad altri artefatti di codice dell'applicazione.

• Allineare il contratto di servizio dell'infrastruttura di test al contratto di servizio per i cicli di distribuzione e test.

• Eseguire smoke test come parte di ogni distribuzione. Eseguire anche test di carico estesi insieme a test di stress e chaos per verificare che le prestazioni e l'operabilità dell'applicazione vengano mantenute.

  • Usare i profili di caricamento che riflettono i modelli di utilizzo di picco reali.
  • Eseguire esperimenti chaos e test di inserimento degli errori contemporaneamente ai test di carico.

  Suggerimento

  Azure Chaos Studio è una suite nativa di strumenti di sperimentazione chaos. Gli strumenti semplificano l'esecuzione di esperimenti chaos e l'inserimento di errori all'interno di servizi e componenti dell'applicazione di Azure.

  Chaos Studio offre esperimenti chaos predefiniti per scenari di errore comuni e supporta esperimenti personalizzati destinati all'infrastruttura e ai componenti dell'applicazione.

• Se le interazioni del database, come la creazione di record, sono necessarie per i test di carico o fumo, usare account di test con privilegi ridotti e rendere i dati di test separabili dal contenuto utente reale.

• Analizzare e monitorare la catena di approvvigionamento software end-to-end e le dipendenze dei pacchetti per le CVE note.

  • Usare Dependabot per i repository GitHub per assicurarsi che il repository sia aggiornato automaticamente con le versioni più recenti di pacchetti e applicazioni da cui dipende.

Infrastruttura come distribuzioni di codice

L'infrastruttura come codice (IaC) considera le definizioni dell'infrastruttura come codice sorgente controllate insieme ad altri artefatti dell'applicazione. L'uso di IaC promuove la coerenza del codice tra ambienti, elimina il rischio di errori umani durante le distribuzioni automatizzate e offre tracciabilità e rollback. Per le distribuzioni blu/verde, l'uso di IaC con distribuzioni completamente automatizzate è imperativo.

Un repository IaC mission-critical ha due definizioni distinte mappate alle risorse globali e regionali. Per informazioni su questi tipi di risorse, vedere il modello di architettura principale.

Considerazioni relative alla progettazione

• Infrastruttura ripetibile. Distribuire carichi di lavoro cruciali in modo da generare lo stesso ambiente ogni volta. IaC deve essere il modello primario.

• Automazione. Tutte le distribuzioni devono essere completamente automatizzate. I processi umani sono soggetti a errori.

Suggerimenti per la progettazione

• Applicare IaC, assicurandosi che tutte le risorse di Azure siano definite nei modelli dichiarativi e mantenute in un repository di controllo del codice sorgente. I modelli vengono distribuiti e il provisioning delle risorse viene eseguito automaticamente dal controllo del codice sorgente tramite pipeline CI/CD. Non è consigliabile usare script imperativi.

• Impedire operazioni manuali su tutti gli ambienti. L'unica eccezione è ambienti di sviluppo completamente indipendenti.

Strumenti DevOps

L'uso efficace degli strumenti di distribuzione è fondamentale per l'affidabilità complessiva perché i processi DevOps influiscono sulla funzione complessiva e sulla progettazione delle applicazioni. Ad esempio, le operazioni di failover e scalabilità possono dipendere dall'automazione fornita dagli strumenti DevOps. I team di progettazione devono comprendere l'effetto dell'indisponibilità di un servizio di distribuzione rispetto al carico di lavoro complessivo. Gli strumenti di distribuzione devono essere affidabili e a disponibilità elevata.

Microsoft offre due set di strumenti nativi di Azure, GitHub Actions e Azure Pipelines, in grado di distribuire e gestire in modo efficace un'applicazione mission-critical.

Considerazioni relative alla progettazione

• Funzionalità tecnologiche. Le funzionalità di GitHub e Azure DevOps si sovrappongono. È possibile usarli insieme per ottenere il meglio di entrambi. Un approccio comune consiste nell'archiviare i repository di codice in GitHub.com o GitHub AE durante l'uso di Azure Pipelines per la distribuzione.

  Tenere presente la complessità aggiunta quando si usano più tecnologie. Valutare un set di funzionalità avanzato rispetto all'affidabilità complessiva.

• Disponibilità a livello di area. In termini di affidabilità massima, la dipendenza da una singola area di Azure rappresenta un rischio operativo.

  Si supponga, ad esempio, che il traffico venga distribuito in due aree: Area 1 e Area 2. L'area 2 ospita l'istanza degli strumenti di Azure DevOps. Si supponga che si verifichi un'interruzione nell'area 2 e che l'istanza non sia disponibile. L'area 1 gestisce automaticamente tutto il traffico e deve distribuire unità di scala aggiuntive per offrire un'esperienza di failover ottimale. Ma non sarà possibile a causa della dipendenza di Azure DevOps nell'area 2.

• Replica dei dati. I dati, inclusi metadati, pipeline e codice sorgente, devono essere replicati tra aree.

Suggerimenti per la progettazione

• Entrambe le tecnologie sono ospitate in una singola area di Azure, che potrebbe rendere restrittiva la strategia di ripristino di emergenza.

  GitHub Actions è particolarmente adatto per le attività di compilazione (integrazione continua), ma potrebbe non avere funzionalità per attività di distribuzione complesse (distribuzione continua). Dato il set avanzato di funzionalità di Azure DevOps, è consigliabile per le distribuzioni cruciali. Tuttavia, è consigliabile scegliere dopo aver valutato i compromessi.

• Definire un contratto di servizio di disponibilità per gli strumenti di distribuzione e garantire l'allineamento ai requisiti di affidabilità delle applicazioni più ampi.

• Per gli scenari in più aree che usano una configurazione di distribuzione attiva/passiva o attiva/attiva, assicurarsi che le operazioni di orchestrazione e ridimensionamento del failover possano continuare a funzionare anche se l'area primaria che ospita i set di strumenti di distribuzione non è più disponibile.

Strategia di ramificazione

Esistono molti approcci validi per la diramazione. È consigliabile scegliere una strategia che garantisce la massima affidabilità. Una buona strategia consente lo sviluppo parallelo, fornisce un chiaro percorso dallo sviluppo all'ambiente di produzione e supporta le versioni rapide.

Considerazioni relative alla progettazione

• Ridurre al minimo l'accesso. Gli sviluppatori devono svolgere il proprio lavoro in feature/* e fix/* rami. Questi rami diventano punti di ingresso per le modifiche. Le restrizioni basate sui ruoli devono essere applicate ai rami come parte della strategia di diramazione. Ad esempio, consentire agli amministratori di creare rami di versione o applicare convenzioni di denominazione per i rami.

• Processo accelerato per le emergenze. La strategia di diramazione deve consentire l'unione main di hotfix non appena pratico. In questo modo, le versioni future contengono la correzione e la ricorrenza del problema viene evitata. Utilizzare questo processo solo per piccole modifiche che risondono problemi urgenti e usarlo con moderazione.

Suggerimenti per la progettazione

• Classificare in ordine di priorità l'uso di GitHub per il controllo del codice sorgente.

  Importante

  Creare una strategia di diramazione che dettaglia il lavoro e le versioni delle funzionalità come minimo e usare i criteri e le autorizzazioni dei rami per garantire che la strategia venga applicata in modo appropriato.

• Attivare un processo di test automatizzato per convalidare i contributi di modifica del codice prima che vengano accettati. Anche i membri del team devono esaminare le modifiche.

• Considerare il main ramo come un ramo in avanti e stabile continuamente usato principalmente per i test di integrazione.

  • Assicurarsi che le modifiche vengano apportate main solo tramite richieste pull. Usare un criterio di ramo per impedire commit diretti.
  • Ogni volta che una richiesta pull viene unita in main, deve avviare automaticamente una distribuzione in un ambiente di integrazione.
  • Il main ramo deve essere considerato stabile. Dovrebbe essere sicuro creare una versione da main in qualsiasi momento.

• Usare rami dedicati release/* creati dal main ramo e usati per la distribuzione negli ambienti di produzione. release/* i rami devono rimanere nel repository e possono essere usati per applicare patch a una versione.

• Documentare un processo hotfix e usarlo solo quando necessario. Creare hotfix in un fix/* ramo per l'unione successiva nel ramo di rilascio e nella distribuzione nell'ambiente di produzione.

Intelligenza artificiale per DevOps

È possibile applicare metodologie AIOps nelle pipeline CI/CD per integrare gli approcci di test tradizionali. In questo modo è possibile rilevare potenziali regressioni o riduzioni e consentire alle distribuzioni di essere arrestate in modo preemptive per evitare potenziali impatti negativi.

Considerazioni relative alla progettazione

• Volume di dati di telemetria. Le pipeline CI/CD e i processi DevOps generano un'ampia gamma di dati di telemetria per i modelli di Machine Learning. I dati di telemetria vanno dai risultati dei test e dai risultati della distribuzione ai dati operativi sui componenti di test dalle fasi di distribuzione composita.

• Scalabilità. Gli approcci tradizionali per l'elaborazione dei dati, ad esempio Extract, Transform, Load (ETL) potrebbero non essere in grado di ridimensionare la velocità effettiva per mantenere il passo con la crescita dei dati di telemetria della distribuzione e dell'osservabilità delle applicazioni. È possibile usare approcci di analisi moderni che non richiedono ETL e lo spostamento dei dati, ad esempio la virtualizzazione dei dati, per abilitare l'analisi continua da parte dei modelli AIOps.

• Modifiche alla distribuzione. Le modifiche nella distribuzione devono essere archiviate per l'analisi automatizzata e la correlazione ai risultati della distribuzione.

Suggerimenti per la progettazione

• Definire i dati del processo DevOps da raccogliere e come analizzarli. La telemetria, ad esempio le metriche di esecuzione dei test e i dati delle serie temporali delle modifiche all'interno di ogni distribuzione, è importante.

  • Esporre i dati di osservabilità delle applicazioni dagli ambienti di staging, test e produzione per l'analisi e la correlazione all'interno dei modelli AIOps.

• Adottare il flusso di lavoro MLOps.

• Sviluppare modelli analitici con riconoscimento del contesto e con riconoscimento delle dipendenze per fornire stime con progettazione automatizzata delle funzionalità per gestire le modifiche dello schema e del comportamento.

• Rendere operativi i modelli registrando e distribuendo i modelli con training ottimale all'interno delle pipeline di distribuzione.

Passaggio successivo

Esaminare le considerazioni sulla sicurezza.

Sicurezza